Howdy Kind Folks,
I've hit a snag trying to support M$ Outlook Express (OE), under Win XP Home,
using both encryption and authentication. The objective is to *require*
encryption *prior* to authentication.
Per previous discussions on the topic, I have set:
auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}
tls_advertise_hosts = *
At the bottom of acl_smtp_rcpt ACL I have:
accept authenticated = *
deny message = authentication required
And finally, the entire acl_smtp_auth ACL is:
accept encrypted = *
deny message = TLS encryption required before AUTH
Now, on an old Win98 box, OE behaves "correctly." (And for once, the OE
smtp.log was useful). On first EHLO to port 25, Exim advertises TLS but not
AUTH. OE does STARTTLS; this succeeds, then OE does a 2nd EHLO. Now, since
the connection is encrypted, Exim advertises AUTH. OE obliges, and message is
accepted for relay. Great. But could M$ leave well enough alone? Oh no...
OE under Win XP can't handle this. (Haven't found the smtp logging feature, I
suspect there isn't one in XP home edition). If I have it connect to port 25
directly, Exim never logs a thing; OE fails to send, leaves message in outbox,
with an error like: '(0x800CCC64) ...failed to send... blah blah'.
I know that under Win98, OE would try TLS on port 25, and smtps on all other
ports, if one checked the "use encryption" box. It looks like OE under Win XP
Home does NOT support TLS on port 25 anymore (as it did under Win98). I would
bet that it is attempting SMTPS on port 25 (and probably ANY port). Can
anyone confirm this?
I've always had my wife's XP box connect to port 465, where I have
Xinetd/Stunnel listening, decrypting, and forwarding to Exim on port 25.
These are now rejected with '550 authentication required'. DOH! Of course...
since I no longer advertise AUTH unless the connection is encrypted. Exim
cannot know that Stunnel already handled the decryption! Thus OE never sees
AUTH advertised, does not try to authenticate, and is rejected.
OK, that was a long story.
I see three possible solutions:
(1) upgrade from Exim 4.02 so I can use --tls-on-connect on port 465, instead
of going through Stunnel. If I do this, will $tls_cipher be non-blank? Or is
there another way to validate that the connection is encrypted, when using
smtps?
(2) modify my tls_advertise_hosts code, to make it evaluate to '*' if EITHER
"$tls_cipher is not blank" OR "$interface_port is 465".
(3) modify my auth ACL to accept non-encrypted, but only if the connection is
from localhost (which Stunnel appears, to Exim, to be).
OK, here is my attempt at writing what I need for option (2):
auth_advertise_hosts = ${if \
and{{!eq{$tls_cipher}{}}\
{!eq{$interface_port}{465}}\
{*}{}}
And here is my attempt at writing the auth ACL for option (3):
accept encrypted = *
accept hosts = localhost
deny message = TLS encryption required before AUTH
It looks like option (3) is the easiest one (not necessarily best in the long
run, just the easiest).
I just realized that option (2) will not work, because the port number 465 is
probably "lost" by the Stunnel process, just like the remote host IP is
"lost." It looks like a connection to port 25, from localhost. (Can one test
the REMOTE port number? If so, would 465 be the actual remote port number for
this configuration? That's probably a Stunnel question...)
My request to you kind folks is simply to evaluate my 3 proposed solutions,
and critique/correct them. And provide option (4) if one exists! (Sorry, I
already ruled out "murder M$ upper management" as this is, sadly, against the
law).
I've also considered returning to "auth_advertise_hosts = *", but this can
cause some clients to attempt AUTH before TLS, resulting in failing the auth
ACL. Sigh.
Regards,
Jim Roberts
Punster Productions, Inc.
