[Top] [All Lists]

Re: [ietf-smtp] guidance on how to secure against sniffing and paid backdoors

2013-09-13 22:33:53
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 

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.

ietf-smtp mailing list