Well then, problem solved!

For my situation, I do not want to allow unsecure connections, so the separate port is the ideal solution. But for your situation stunnel 3.22, which is what I'm using, has native support for pop3 STLS negotiations.

     -n proto
          Negotiate SSL with specified protocol

          currently supported: smtp, pop3, nntp

And if you apply the patch from these two messages:

http://marc.theaimsgroup.com/?l=stunnel-users&m=102552939328714&w=2
http://marc.theaimsgroup.com/?l=stunnel-users&m=102553961008071&w=2

it will have imap server support as well.

David Meador wrote:

While the stunnel connection wrapper is a quick solution to secure
connection problem, it has one major problem.

It lacks TLS secure connection negotiation (imap:STARTTLS, pop3:STLS)
which allows you to upgrade connections to ports imap and pop3 to be
secure connections by issuing the command to start TLS connection
negotiation.  This cannot be achieved with a stunnel wrapper because
stunnel requires a secure connection before making the subsequent
connection to dedicated SSL pop3s(995) and imaps(993) ports.  You need
to be able to connect directly to imap(143) or pop3(110) ports directly
and issue a STARTTLS/STLS command to trigger secure connection upgrade.
This forces the SSL capability to be embedded into the imapd and pop3d
daemons in order to support this feature.


Reply via email to