On Thu, May 12, 2016 at 09:48:36AM -0400, John R Levine wrote:
> My original point which I thought, perhaps wrongly, was obvious, is that all
> of these MTAs already have TLS support, so if we define a way to receive
> failure reports that doesn't need MTA changes, they can start collecting
> reports now and fixing their configuration errors.
This means a strong asymmetry in the protection of the SMTP traffic.
The MTAs with just existing TLS support will not support outbound
STS or DANE, and will continue to do opportunistic TLS. The only
direction in which SMTP would be protected with such sites would
be outbound from the early adopters of STS like Google/Yahoo/...
Perhaps that's somewhat useful, but with email flowing back and
forth, if either direction is easy to MiTM, we're not gaining that
much.
> Of course there's lots of spying, but I hope we all remember the maxim never
> to attribute to evil what can be explained by incompetence. For every TLS
> session broken by malicious spying, there will be many more broken by
> misconfigured TLS in the MTA, or a firewall in the wrong place, or any of
> the other reasons we all know. The sooner people can start collecting info
> about the failures, the sooner they can start fixing the screwups that cause
> them.
On this we're in strong agreement.
> So we should try and understand what are the reasons that TLS fails, and
> start with approaches that can address the most common ones.
Indeed.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
