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":"tlsrpt-noreply(_at_)microsoft(_dot_)com","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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp