Timo Sirainen wrote:
I've been considering an SMTP client extension (especially for submission clients) where
they can require that the mail be delivered via TLS, and have the server reject/bounce it
if that's not possible. The main problem I see is relay servers that can accept the mail
via TLS and then happily forward the mail over plaintext connection to the other side of
the world.. Then again, there may be other ways to handle this, for example Germany has
already started something like this with their "Email made in Germany" project.
Other countries have expressed similar interests. Maybe something more standard could be
developed..
It's an appealing idea, and several vendors already have proprietary
implementations to do this. Obviously it only works end-to-end when
every hop uses the same vendor; but in the case of cloud vendors that's
all they feel they need. I wanted to publish a standard around it, but
my employer at the time totally killed the idea, in part (I suspect)
because they wanted to claim it as a competitive advantage.
The "must use TLS" flag does not, however, add that much in the way of
real security. The message is still exposed in the clear at the relays,
DSNs create all kinds of opportunities for leakage, and most SMTP hops
are still trivially hijackable. My customers that actually were serious
about using TLS for Email security essentially created Email VPNs, with
rigorous certificate checking on every hop and regular probes that
verified all paths were still secure. They viewed the "must use TLS"
flag is one more layer on the onion, not a solution of itself.
Perhaps this is the time to revive Chris Newman's idea for combining
S/MIME or PGP with the Batch SMTP content type. That technique encrypted
the envelope as well as the message content. I think the patent troll
that was in this space has finally gone away.
<csg>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp