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 19:02, John R Levine wrote:

>> {"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?
> It's probably just giving you the wrong error message.
> 
> Here's a radical idea: fix your MX entry and see if the errors go away.

The errors do go away. But I'm not trying to fix the individual issue 
here, rather to better understand what exactly they're are complaining 
about, and if their errors and logic are compliant with the policy 
validation and application, set in RFC 8461.

They started off by pointing at their roadmap which still up until now 
says that the feature is in development, rather than rolled out, or 
launched; then seemingly tried to confuse me with:

> From reviewing your issue, we can see that your externally hosted 
> domain n0.lt is set to only accept emails using secure and encrypted 
> connections. When sending emails, by default they are unencrypted. By 
> default Office 365 sends emails unencrypted which is why your n0.lt 
> server is rejecting them.
> 
> To resolve this you need to set up a send connector in Office 365 to 
> send encrypted and TLS secured emails to n0.lt. Depending on the 
> configuration of your n0.lt mail server, you may also need a receive 
> connector to match the receiving SMTP FQDN madin.ga* with a TLS 
> certificate, however, we cannot confirm this as your mail server is not 
> hosted by Microsoft.

* - the domain I have with them for testing purposes.

Viktor Dukhovi and Sam Varshavchik have already provided their detailed 
viewpoints which will help me a lot to continue working with the support 
of this sending MTA.

Thanks!

--

Best wishes,
Kristijonas