Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

[Kristijonas Lukas Bukauskas <[e-mail]>]

On 2021-04-01 04:41, John R Levine wrote:

> IETF standards tell you what to do to interoperate.  They generally
> don't tell you what to do when some part of a system doesn't follow
> the spec.

Thank you for your clarification.

>> By the way, from the last TLSRPT:
>> 
>> {"organization-name":"Microsoft 
>> Corporation","date-range":{"start-datetime":"2021-03-30T00:00:00Z","end-datetime":"2021-03-30T23:59:59Z"},"contact-info":"[e-mail]","report-id":"132616914860181612+n0.lt","policies":[{"policy":{"policy-type":"sts","policy-string":["version: 
>> STSv1","mode: enforce","mx: mx.n0.lt","max_age: 
>> 84600"],"policy-domain":"n0.lt"},"summary":{"total-successful-session-count":0,"total-failure-session-count":492},"failure-details":[{"result-type":"certificate-host-mismatch","failed-session-count":492}]}]}
>> Do they complain about the certificate which includes both n0.lt and 
>> *.n0.lt anyways?
> 
> Even without the CNAME error, why would it do that?  The cert matches
> the name of the MX.

So certificate-host-mismatch here should be understood that EITHER §4.1 
[1] (MX Host Validation) OR §4.2 [2] (Recipient MTA Certificate 
Validation) failed and not that, according to the report, the 
certificate hostname mismatched? Or what exactly?

--
Regards,
Kristijonas

Links:
------
[1] https://tools.ietf.org/html/rfc8461#section-4.1
[2] https://tools.ietf.org/html/rfc8461#section-4.2