In the EAI case, it turns out that there is no plausible
"downgrade" path corresponding to "give up and send clear text"
in historic STARTTLS so "required extension" is the only game in
town and messages either go through or they don't. However,
the strongest critique of EAI -- IMO an entirely valid one at
least until the protocol extensions are widely deployed -- is
that it basically divides the email world into two communities
who can't talk with each other. You risk the same type of
Only sort of. In this case, the downgrade path is obvious, you
ignore the TLS flag and send the message along.
Upon slightly more reflection, I think I see why this isn't likely to
be useful. Any MTA that understands the REQUIRETLS flag will almost
certainly do opportunistic TLS anyway, so you haven't gained much
there. In the absence of DNSSEC, you still have the attack where a
bad guy sends you a fake MX, so you deliver 100% securely to the wrong
place, so you have yet another steel door on a cardboard box.
If you do have DNSSEC, you can use RFC 7672 TLSA to be sure you're
delivering to the right place. So what does this buy you in practice?
Speaking of RFC 7672, see its section 1.3 which looks to me like it
contemplates an approach like this and describes its problems.
ietf-smtp mailing list