SSL tunneliing via stunnel worked fine on my XP system - thanks for the head's up.

This is a much simpler solution than interposing Mercury in the path for our home

network, although I must admit I was also curious about possible advantages

and uses of Mercury in this environment - but that is a bigger project..

Thanks again for the quick advice.

I ask this because Verizon may soon require SSL POP3/SMTP connections,
but our active SPAM/AV protection by NIS2012 requires email traffic
to be locally visible via port 110 and port 25 connections. We
have multiple home systems,all using NIS2012, and switching
is not practical.

My thought was that the port 25 & 110 paths could be maintained
locally by having the email client connect to Mercury on the same
system via ports 110/25, but with Mercury in turn interacting
with the ISP's POP3/SMTP hosts over SSLconnections.  This would allow normal
SPAM/AV scanning to occur as it does now while using SSL connections
to the ISP's mail hosts.

Documentation suggests that this might not work because MercuryC
would appear to the ISP to be a relay and therefore be blocked, despite
the fact it is only associated with system local clients. I'm also
concerned, given the flexibility and configuration options for Mercury,
that the home-system's configuration and management requirements could be excessive.

Does anybody know if using Mercury as a simple email proxy client
in the manner suggested above is workable?

> My thought was that the port 25 & 110 paths could be maintained
> locally by having the email client connect to Mercury on the same
> system via ports 110/25, but with Mercury in turn interacting
> with the ISP's POP3/SMTP hosts over SSLconnections.  This would allow normal
> SPAM/AV scanning to occur as it does now while using SSL connections
> to the ISP's mail hosts.

You might try SSL tunneling to do this.  Mercury would keep the normal addresses and the SSL connections to the SSL ports would be forwarded to Mercury and your anti-spam/virus software.

Mercury would act as an email server and receive and send messages on behalf of your local users, using their credentials. In the LAN you would set your email clients to connect to Mercury instead of the servers provided by your ISP. I've no experience with Verizon so I couldn't say for sure if there is some special problem with using MercuryC and MercuryD to authenticate to their servers, but it's a free download so you can simply test it.

/Rolf