I've only quickly skimmed the original thread, but it seems like the
argument is about this magic DNS prefix for MX records that would indicate
"this MX should offer STARTTLS", right?
As John says, the new proposal also requires DNSSEC, no? It seems like the
primary difference is that the new proposal is simpler by indicating only
that the server supports TLS, but not what identity it presents? Why is
that desirable?
On Mon, Oct 7, 2019 at 3:56 AM John Levine <johnl(_at_)taugh(_dot_)com> wrote:
In article <20191007002348(_dot_)GA23742(_at_)x2(_dot_)esmtp(_dot_)org> you
write:
What's wrong with MTS-STS defined in RFC 8461?
It requires an HTTPS server, thus adding an extra service and moving
the "trust" problem to CAs (AFAICT).
I was there when we were defining MTA-STS and the people involved,
who work for companies that probably handle the majority of all of
the mail in the world, did not want it to depend on DNSSEC for
deployment reasons.
See sections 2 and 10 of RFC 8461.
If you like DNSSEC, you can publish a DANE TLSA record for your SMTP
server, and systems like Comcast that pay attention to DNSSEC will use
it to check that you support TLS and have the right cert.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
How's my emailing? http://go/dan-email-slo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp