>
> I don't think that stunnel solution is entirely correct as a result of some
> issues arising from masking the incoming IP. Since however I and other users
> on my system are the only folk that use it it doesn't actually have any
> practical bearing that I'm aware of.
>
The problem with using stunnel is that all your SSL connections will look
like they come from 127.0.0.1 - none of your IP based policies will have
any effect. This means that you are basically an open relay, anyone who
connects to your server via SSL can relay through you, whether they are
local or not (and who knows, spammers may someday evolve brains enough
to try using SSL ports).
I am using stunnel here, but with a twist. I force all SSL connections
to authenticate before relaying. Here's how:
NOTE: I've only had this in place for 24 hours. Although it seems to
work just fine it's entirely possible I'm overlooking something.
First make sure you are set up to do SMTP AUTH properly (see the new
entry in the FAQ about this).
Then add MUSTAUTH to the auth_hosts line in your configure file. If you
don't already have a list of IPs there, it will look like this:
auth_hosts = MUSTAUTH
If you have some IPs you want to authenticate, add them like this:
auth_hosts = MUSTAUTH:10.1.1.1:10.1.1.2
Then invoke stunnel like this:
/usr/local/sbin/stunnel -d 465 -l /usr/exim/bin/exim \
-p /usr/local/ssl/certs/exim.pem -- \
exim -bs -DMUSTAUTH=127.0.0.1
Whenever an SSL connection is established, Exim is invoked with the
macro MUSTAUTH defined as 127.0.0.1, which forces that one particular
instance to authenticate without disrupting normal 127.0.0.1 operations
via non-SSL sessions.
This is working great with (cough) Outlook Express, which as far as I
know is the only mailer that does SSL correctly. We also use stunnel
with our POP server, which Outlook also supports.
Mark
