keld(_at_)keldix(_dot_)com writes:
I am all for better security, but my main aim was to get TLS employed,
and that seems hard enough to get consesnsus on in this group. My main
aim is to maintain interoperability, so if we can employ . better
security without hurting interoperability, that would be fine. Using
DNSSEC could be an option then.
I have a little bit of operational experience with STARTTLS with SMTP
(probably not as much as many people here), since I use opportunistic TLS
on all my own servers and Stanford enforces TLS for mail exchanges with
some sites. The current state of play with interoperability is not
particularly great in my experience, which will probably not come as a
surprise to people who run large mail environments. Interoperability for
SMTP in general is kind of a mess; there are a lot of very substandard
implementations out there.
For a very small personal mail server that only does STARTTLS when the
other side explicitly requests it, I see about one error message logged
per day, ranging from clients sending the wrong TLS version number to
weird invalid certificates to various other protocol problems.
It mostly works or can be made to work with large institutions who have an
incentive (such as our policy to require STARTTLS for all email exchanges
with anyone who is a partner of the Stanford Medical Center). Where that
institutional will is not present, the quality of existing implementations
seems to vary wildly.
This is for transit connections. The end-user clients in general are much
better at doing STARTTLS, probably because more ISPs have been requiring
TLS for end-user mail submission for much longer.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp