On 1/5/19 8:55 PM, Grant Taylor wrote:
On 1/5/19 8:05 PM, Alice Wonder wrote:
Also I seem to recall talk of an e-mail header clients can add that
tell a MTA not to forward it without encryption.
I'd be curious to know what said header is, and what MTAs support /
honor it.
What the HTTPS server in MTA-STS really does is give some limited
protection against DNS MX record spoofing for zones that do not have
DNSSEC and/or for MTA clients that do not validate DNSSEC.
What‽ That's contrary to my understanding of what MTA-STS is.
My understanding of MTA-STS is that it's a way for receiving domains to
indicate that they support and want connections to their receiving MTAs
to use STARTTLS encryption. Thus sending MTAs can deduce that there is
a problem if they don't see STARTTLS as an extension when connecting to
said receiving MTAs.
The https part contains a list of MX hosts (or regex of them).
The MTA client is suppose to only use a MX host that is in both the MX
record and the mta-sts https delivered policy.
Yes it also then requires TLS (and I believe TLS 1.2+ but not positive)
with a PKI validating certificate, but (assuming enforce mode) it is
only suppose to communicate with MX hosts that are an intersection of
what is in the MX record and the https delivered policy.
So the https delivered policy is a 2FA for the MX record that is secured
by TLS via PKI validation.
TLS is then used to mitigate MITM attacks but if it was just to turn on
TLS all that would be needed is the MTA-STS DNS record.
The web server component secures the MX record.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
