> On Sat, 15 Feb 2003, James P. Roberts wrote:
>
> > What you want simply will NOT work with a Microsoft client, because
it
> > is stupid software that ASSUMES you must not want to use STARTTLS if
you
> > are connecting to a port other than 25. Instead, it reverts to
smtps,
> > WITHOUT bothering to tell you about it.
>
> Right. Thanks for spelling this out so clearly. I think there must be
a
> lot of confusion about exactly what STARTTLS and SMTPS actually mean.
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
>
Yes. I had a lot of confusion myself when I first encountered this. As
discovered by sniffing packets:
STARTTLS begins with a normal, clear-text session, during which the
server usually advertises support for STARTTLS. After a clear-text
"STARTTLS" command from the client, server and client negotiate
encryption (everything from here on out looks scrambled), which persists
for the remainder of the connection. It is important to make sure any
AUTH occurs after TLS encryption has begun, in order to protect user
passwords from sniffers.
SMTPS was rather more difficult to understand, as the very first command
from the client is not clear-text. It looks garbled to anything except
a server listening specifically for encrypted SMTPS traffic.
Anyway, STARTTLS and SMTPS are quite different. And it appears, from
discussions in this thread, that M$ is not the only client to assume
STARTTLS only happens on port 25. Sigh. And just to make it more
annoying, those same clients will not use SMTPS on port 25. They appear
to be hard-coded to use different schemes on different ports.
So, if you want to enforce encryption before AUTH, you are forced to
either limit the choice of clients, or run at least two daemons. (At
least two methods of arranging dual daemons have been posted in this
thread already.)
Philip, I know you said it would probably never happen, but I would like
to add this to the Exim Wish List anyway. The ability to handle both
STARTTLS and SMTPS, from a single Exim, on different ports. I know,
this is really to compensate for bad coding on the part of clients, but
it seems to be a universal problem that isn't going to be fixed on the
client end. It is certainly the case that work-arounds exist
(two-daemon solutions). But this is not quite satisfying.
My suggestion for a "standard" configuration:
Port 25 ("smtp" port): plaintext and STARTTLS
Port 465 ("smtps" port): SMTPS
Port 587 ("submission" port): plaintext and STARTTLS
This allows all the protocols, on at least one port other than 25, to
get around the ISP port 25 hi-jacking problem. Any given client can
then be configured to talk to the server. Because there is a risk that
ISPs will begin hi-jacking other ports as well, it would be important
for Exim to be able to specify the protocol for each port being listened
on (at least, whether or not to use smtps on each port).
I don't think we ever need both STARTTLS and SMTPS on the same port?
Maybe just mask out tls_advertise on ports designated as smtps ports? I
think the only change needed in Exim config would be a new "smtps_ports"
option? Just check that it matches only port(s) being listened on.
It's a "Wish", not a "Must Have." :)
Jim Roberts
Punster Productions, Inc.
