Yes, I didn't explicitly mention that.
I worded like this.
Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if
STARTTLS command not found in the EHLO response or certificate is invalid,
then drop the connection”.
Certificate becomes invalid when the protected MX target not found in the
certificate presented.
On Mon, Oct 7, 2019 at 6:06 PM Keith Moore
<moore(_at_)network-heretics(_dot_)com>
wrote:
On 10/7/19 5:11 AM, Daniel Margolis wrote:
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?
I didn't see this explicitly specified in the proposal, but IMO the
server certificate should match the target of the MX record.
And depending on DNSSEC probably does impair the ability of this to be
deployed. But if DoT can be used instead of DNSSEC, it seems to me
that this might be easier to deploy than MTA-STS.
Granted, MTA-STS exists already and enjoys some support. A new
proposal thus has a high bar to clear in order to be accepted as a
standard. But I don't think it's wrong to discuss other ideas.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp