Thanks Vincent & Nathan for your quick replies.
The bit I was missing was that even when you specify ssl_listen, you
need to specify the real server port as 143. I tcpdumped headers from
the perdition box to the back-end server, and when I saw it going to
port 993, I assumed it was still trying SSL to the back-end server when
I had specified ssl_listen.
On Vincent's comment that ssl on the backend shouldn't really matter, I
agree- this isn't the 90s, and I've got very beefy hardware. On the
other hand, the servers are both on a protected subnet which no user can
plug into, so there's not even a possibility of arp-spoofing MITM
attacks.. so why waste resources which are totally unnecessary? Also,
you can then avoid the extra work of configuring & maintaining multiple
SSL certificates.
Cheers
Ross
-----Original Message-----
From: Vincent Fox [mailto:vbfox@ucdavis.edu]
Sent: Wednesday, December 12, 2007 1:28 PM
To: Ross Becker
Cc: perdition-users(a)vergenet.net
Subject: Re: [PERDITION-USERS] Perdition config question
Ross Becker wrote:
Looking at the ssl_mode options, there doesn't
appear to be a
none_outgoing, which is what I believe I want.
Read the man page again.
If you specify ssl_listen only, then outoing is unencrypted by default.
We fine-grain each protcol, with 4 config files:
perdition.imap4.conf
perdition.imaps.conf
perdition.pop3.conf
perdition.pop3s.conf
Our setup is actually the reverse, we enforce all backend
connections to the server to SSL. The penalty of encryption
to backends is IMO overstated and a waste of time to pursue.
Setting up a private network to keep all your passwords from
being sniffed sniffed blah blah is a common solution, but it's
spending dollars worth of man-hours to save a few pennies.
SSL imposes at most a 20% overhead on CPU these days.
This is not the 90's unless you are trying to run 10K users on
a Pentium III you will not run out of CPU.