Post by Tekkie©I use Microplanet Gravity and it posts to groups fine. But emailing is
a problem. Pouring over the docs it seems that I need to run stunnel
or OpenSSL for it to connect through to the mail server. Can anyone
guide me through this?
MP Gravity supports e-mail protocols? I didn't see e-mail mentioned at
its Sourceforge project site (sourceforge.net/projects/mpgravity).
Assuming it does ...
You sure you want to combine your e-mail and newsreader clients into one
program? Such users have accidentally submitted their e-mails,
sometimes containing personal or embarrassing content, into newsgroups
where it remains forever for all to see. Cancels are honored at so few
NNTP servers that I've never encountered one that supported cancels.
Those that claim they honor cancels may fail. I cannot tell if
EasyNews, your Usenet provider, supports cancels. When I searched on
"cancel" on their help site, all I got were articles about cancelling
your account with them.
Microplanet Gravity runs on Windows platforms (XP, Vista, and 7, and
perhaps later). By adding another link in the chain (e-mail client ->
sTunnel -> AV proxy -> mail server), you make it more difficult to
isolate which component is causing a problem when you can no longer send
or receive e-mails. Since your current choice of e-mail client doesn't
support TLS which your current choice of e-mail provider now requires,
you cannot remove sTunnel to see if it causes problems with e-mail,
because removing sTunnel means it also incapacitates your e-mail client.
There are several good choices for e-mail clients on Windows, like
Thunderbird, eM Client (free with max of 2 accounts), plus most (not
all) versions of Windows come with a bundled e-mail client. Another
freebie is Claws Mail, but get ready to see something reminiscent of
GUIs dating back to Windows 3.x; however, not all plug-ins have yet to
get ported to Windows (https://www.claws-mail.org/win32/). The Bat! is
free, but be careful with this choice since it is heavily [ab]used by
spammers, so it can run afoul of anti-spam filtering at the server. Be
careful with some "free" e-mail clients that are really just trialware
or [highly] crippleware; i.e., they're lureware.
If you are intent on using sTunnel with any e-mail client, the overview
is you configure your e-mail client to send or listen on ports for
sTunnel, not for ports on your e-mail provider's servers. Typically
sTunnel runs as localhost, so that's the server you specify in your
e-mail client. That has your e-mail client connect to sTunnel. You
configure sTunnel to use ports for sending and receiving from your
e-mail client. Typically you use the standard ports for POP, IMAP, and
SMTP for sTunnel to listen to for connects from your e-mail client.
Then you configure sTunnel to connect to the ports and host for your
e-mail provider.
e-mail client --> SMTP --> sTunnel --> AV --> provider's SMTP server
<-- POP <-- sTunnel <-- AV <-- provider's POP server
<-- IMAP <-- sTunnel <-- AV <-- provider's IMAP server
Whether your AV (antivirus) is interrogating your e-mail traffic depends
on if you configure it to do so. It is superfluous, but it adds bloat
to the AV's feature set for marketing purposes, and some users want the
warm comfy feeling that there is somehow more protection by having their
e-mails scanned (but that's false since the same on-access scanner is
used for the AV's real-time detection as used for their e-mail scanner).
If you use non-standard ports on sTunnel's output side (from it to the
e-mail servers), an AV could interfere by blocking that traffic, or not
scan it at all (which is also another reason it is superfluous). Most
AVs run as a transparent proxy, but they still default to monitoring
just the standard e-mail ports. If you don't have your AV do its
superfluous monitoring of e-mail traffic, that eliminate a link in the
e-mail chain. Using an e-mail client that supports TLS eliminates
another link in the e-mail chain. The longer the chain, the more
fragile it becomes, and the harder to troubleshoot.
In sTunnel's configuration, you use a different listening port (from the
e-mail client) to identify to which server that sTunnel will connect.
You define mapping from an input port on sTunnel to an output port on
sTunnel. For multiple accounts, you configure your e-mail client to use
a different port to sTunnel where each port is associated with a
different e-mail service. So, you end up defining listening ports in
sTunnel for each type of service at an e-mail provider, like having one
port listen for SMTP connect from your e-mail client to connect to
provider #1's SMTP server, another port at sTunnel listening to IMAP
connects from your e-mail client to connect to your provider #1's IMAP
server, and a 3rd port at sTunnel listening to connects from your e-mail
provider to go to your provider #1's POP server. Usually you only use
POP or IMAP at an e-mail provider, not both. So, for N e-mail services,
you'll end up defining N*2 ports at sTunnel to listen for connects from
your e-mail client. Mapping is defined by you editing a text config
file for sTunnel. There is no GUI for defining the mapping, especially
since that would make more difficult the cross-platform capability by
requiring different graphical code for each platform. You might want to
draw out the mapping from your e-mail client to sTunnel, from sTunnel to
the e-mail servers, and the internal mapping inside sTunnel to know
which input port goes to which output port. For sTunnel, editing its
text config file will look something like their example at:
https://www.stunnel.org/config_windows.html
You'll need to know which ports your e-mail provider uses for SMTP,
IMAP, and POP to know how to configure sTunnel's outward ports. Last I
tried sTunnel, it has no database of e-mail providers for it to
automatically configure its in/out port assignments. It's all up to
know to find out that information. I've not heard that sTunnel will
support Exchange or Gmail API for access to those type of mail servers.
sTunnel runs as a local proxy which performs a MITM (Man-In-The-Middle)
interception of your e-mail traffic. You might get lucky when first
setting up and configuring sTunnel, along with redefining your e-mail
accounts in your local e-mail client, to get it all working on the first
try. Else, you'll have to spend some time troubleshooting your setup to
see if the config in your e-mail client (that now has to point at
sTunnel) or sTunnel (which needs port assignments on its input side from
your client and port assignments on its output side to the e-mail
servers) that is causing the problem. Much easier to move to a local
e-mail client that already supports TLS for secure connects to whomever
are your e-mail providers, some of which afford automatic configuration
just by entering your e-mail address at each e-mail provider.