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

From: Hector Santos <[email-masked]>
Date: Fri, 02 Apr 2021 11:09:42 -0400

Affair?   Nice!!  <g>

As a SMTP developer, I have designed my DNS resolver to resolve CNAME 
even if it came during a MX query simply because they do exist in the 
wild and who I am to argue with a customer when it came to delivering 
mail,  "Oh I'm sorry but you can't sent mail because the destination 
is not following the rules."   CNAME is expanded as part of the IP 
expansion process to get a sorted list and all that before a Round 
Robin outbound session login begins. RFC2181 does suggest this can be 
expensive and I will say, that is probably mostly true back in 1997 
where even a PTR was expensive -- it is accepted today, if fact, 
increasingly required by many mail host.

I don't follow RFC8461 so I have no generated no rules or a higher bar 
for MX-TST technical protocol requirements.  I don't know how it works 
(didn't read it).  But overall, administrators applying 8461 believing 
using a CNAME for MX as is reason for rejecting a transaction is a 
local policy concept.   It can happen. Even the ietf.org, a SDO, has 
applied SPAM associations with mail clients using legal EHLO 
[ip-literal] SMTP usage.  I am not going to change my SMTP compliance 
because the ietf.org mail administrators has refused to follow the 
RFC2821/5321 SMTP specs first and subjectively apply an general 
ip-literal usage restriction.  Its a local policy.  In our SMTP 
client, we send public DNS host name first, fallback to an ip-literal 
and/or an local site override is used. Doing a CBV check, an 
ip-literal is used to optimized CBV preparation.  We white listed the 
ietf.org site to stopped the CBV check on them.

Overall, Postel's law!!

"Be conservative in what you send, be liberal in what you accept"

If the receiver administrative policy is causing a pain and they don't 
see that you may not be the only one with MX->CNAME records and they 
do exist, they won't make an exception, then you're only left with one 
thing - comply with the 2181 specification.

Good luck with your affair!! <g>

On 3/31/2021 5:44 PM, Kristijonas Lukas Bukauskas wrote:
>
> Hello,
>
> I'm having an affair with one of the vendors as a sending MTA, 
> honoring MTA-STS (RFC 8461). Their response:
>
>      1. Our TDS validation shows MX lookup for n0.lt returns
>         *n0.lt* instead of*mx.n0.lt*. It is consistent with what we
>         are seeing with production.
>
>         /remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS
>         validation.)' 3/24/2021 3:36:19 PM - Server at n0.lt
>         (0.0.0.0) returned '450 4.4.317 Cannot connect to remote
>         server [Message=451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS
>         validation.] [LastAttemptedServerName=*n0.lt]*/
>      2. We can confirm that customer is not RFC compliant with MX
>         pointing to a CNAME and we don't think it is worth to change
>         the logic to accommodate that.
>      3. Customer does have an easy fix on their side, just to modify
>         their STS Policy to include n0.lt as one of the supported MX
>         record.
>
>
>
> My objections:
>
>
>> I'm familiar with a general prohibition, pursuant to RFC 2181 § 
>> 10.3 <https://tools.ietf.org/html/rfc2181#section-10.3>, for MX 
>> records to point to CNAMEs. Despite that, I do not believe that it 
>> should affect MX host validation in accordance with RFC 8 
>> <https://tools.ietf.org/html/rfc8461#section-4.1>461§4.1 
>> <https://tools.ietf.org/html/rfc8461#section-4.1>when selecting a 
>> target MX host, for the reasons of:
>>
>> 1.
>>
>>     RFC 2181 is an RFC on Clarifications to the DNS Specification,
>>     not SMTP.
>>
>> 2.
>>
>>     Selecting an MX target host is regulated in a different RFC,
>>     namely and specifically in RFC 5321 §5.1
>>     <https://tools.ietf.org/html/rfc5321#section-5.1>:
>>
>>
>>>     If MX records are present, but none of them are usable, this
>>>     situation MUST be reported as an error.<...> When a domain
>>>     name associated with an MX RR is looked up and the associated
>>>     data field obtained, the data field of that response *MUST
>>>     contain a domain name*. That domain name, when queried, MUST
>>>     return at least one address record (e.g., A or AAAA RR) that
>>>     gives the IP address of the SMTP server to which the message
>>>     should be directed. _*Any other response, specifically
>>>     including a value that will return a CNAME record when
>>>     queried, lies outside the scope of this Standard*_. The
>>>     prohibition on labels in the data that resolve to CNAMEs is
>>>     discussed in more detail in RFC 2181, Section 10.3 [38]
>>
>>
>> 2.
>>
>>     Thus, the prohibition of CNAMEs is *NOT* an SMTP or MTA-STS
>>     issue. As per the RFC 5321 §5.1, which is used to select an MX
>>     target host, pursuant to RFC 8461 §4.1 (MX Host validation),
>>     vendors are *NOT* allowed to choose a different host name (in
>>     my scenario, n0.lt instead of mx.n0.lt which is found in MX
>>     record). The situation MUST be reported as an error, if none of
>>     the found records are usuable. That MUST happened even if the
>>     target domain has not deployed MTA-STS. And this doesn’t seem
>>     to be the case. When MTA-STS is not deployed, Microsoft, as a
>>     sending MTA doesn’t return any errors.
>>
>> 3.
>>
>>     No major providers (including, but not limited to Gmail) nor
>>     publicly available MTA-STS tests (including, but not limited to
>>     My Email Communications Security Assessment (MECSA) by European
>>     Commission’s Joint Research Center) doesn’t select n0.lt
>>     instead of mx.n0.lt which is found in MX record nor does it
>>     show any errors, suggesting my interpretation of different RFCs
>>     is most likely correct.
>>
>
>
> As advised by one of the authors of RFC 8461, I'm reaching out to 
> the IETF SMTP list for your opinions, namely if MTA-STS, in theory, 
> should fail to validate if an MX points to a CNAME.
>
> Any insights would be much appreciated and thanked in advance. :)
>
> --
> Regards,
> Kristijonas
>
>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Fri, 02 Apr 2021 19:00:05 +0300

This is the their recent response:

> As my colleagues who investigated this issued communicated, our 
> position is that this is primarily due
> to what we believe to be a non-RFC compliant MX record.
> Regardless of the liberal acceptance of this for regular mail, in this 
> case, our implementation of MTA-
> STS is not as liberal.
> Treating this as a feature request to support such behaviour leads us 
> to evaluate the importance of such work. Viktor's numbers (~0.3% +/- 
> 0.1% of MX records are CNAMEs) clearly shows this is not an urgent or 
> critical matter threatening the ecosystem and deployment of MTA-STS and 
> therefore we have rejected the
> request.
> I urge you to fix your MX record.

I still have a concern regarding an error returned in their aggregated 
TLS report:

> {"organization-name":"Microsoft 
> Corporation","date-range":{"start-datetime":"2021-03-31T00:00:00Z","end-
> datetime":"2021-03-31T23:59:59Z"},"contact-info":"[email-masked]","report-
> id":"132617776923269755+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":36},"failure-details":[{"result-
> type":"certificate-host-mismatch","failed-session-count":36}]}]}

Is this a correct error to return, even if with CNAME/MX? (SANs are 
n0.lt and *.n0.lt in my cert.)

> "certificate-host-mismatch": This indicates that the certificate
> presented did not adhere to the constraints specified in the MTA-
> STS or DANE policy, e.g., if the MX hostname does not match any
> identities listed in the subject alternative name (SAN) [RFC5280]
  [https://tools.ietf.org/html/rfc8460#section-4.3.1]

> Good luck with your affair!! <g>

Thank you! :)

--
Regards,
Kristijonas

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Apr 2021 14:54:21 -0400

On Fri, Apr 02, 2021 at 07:00:05PM +0300, Kristijonas Lukas Bukauskas wrote:

> {
>   "organization-name": "Microsoft Corporation",
>   "date-range": {
>     "start-datetime": "2021-03-31T00:00:00Z",
>     "end-datetime": "2021-03-31T23:59:59Z"
>   },
>   "contact-info": "[email-masked]",
>   "report-id": "132617776923269755+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": 36
>       },
>       "failure-details": [
>         {
>           "result-type": "certificate-host-mismatch",
>           "failed-session-count": 36
>         }
>       ]
>     }
>   ]
> }
>
> 

The error indicated is indeed misleading, since the problem appears
to rather be a mismatch between the CNAME-expanded MX hostname and
the "mx: " field of the MTA-STS policy.  The certificate matches
either name, so isn't plausibly the problem:

    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32

Mind you, I do think that the sender should (in due course) change their
MTA-STS implementation to process MX CNAMEs in a manner that does not
change the logical MX host that is compared against the STS policy.

Sure, given the RFC5321 language, and the relatively low impact, they
can choose to give the fix low priority, but inevitably this issue will
crop up from time to time, and it simpler to address it at some point
than to steadfastly point out that the receiving system is somewhat
outside the spec.

The reason to be lenient here, is that MTA-STS aside, RFC5321
notwithstanding, MTAs, including theirs, generally allow CNAMEs in the
MX record, and it is a nuisance if enabling MTA-STS, ... suddenly
breaks that, for non-obvious reasons.

However, as a receiving system, in the meantime, you can do yourself and
everyone else a favour by changing your DNS to avoid the CNAME.

Since you're also using DANE:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

that would be either:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN A 188.166.32.32
    mx.n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

or alternatively:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

You can use CNAMEs in TLSA RRs if you like:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN CNAME _25._dane.n0.lt.
    _25._dane.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._dane.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._dane.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._dane.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._dane.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

-- 
    Viktor.

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Fri, 02 Apr 2021 23:50:04 +0300

> n0.lt. IN A 188.166.32.32

So that's the failed MX Host Validation, as described in [RFC8461], 
section 4.1, that sending MTA seems to claim to be the problem. Correct?

> A receiving candidate MX host is valid according to an applied MTA-
> STS Policy if the *MX record name* matches one or more of the "mx"
> fields in the applied policy.  Matching is identical to the rules
> given in [RFC6125], with the restriction that the wildcard character
> '*' may only be used to match the entire left-most label in the
> presented identifier.  Thus, the mx pattern "*.example.com" matches
> "mail.example.com" but not "example.com" or "foo.bar.example.com".

If so, what error should the reporter use, as per [RFC8460], in an 
aggregated TLS report?

validation-failure?

> everyone else a favour by changing your DNS to avoid the CNAME.

Will do, immediately after the sending MTA finishes their testing (a few 
support teams at the sending MTA still work on my support tickets).

Please accept my deepest thanks for your professionalism and guidance.

--
Regards,
Kristijonas

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Apr 2021 19:13:42 -0400

> section 4.1, that sending MTA seems to claim to be the problem. Correct?

Yes, that's my interpretation of the outcome.  Their MTA-STS validator
detected a mismatch between the MTA-STS policy MX hostname and the
CNAME-expanded MX hostname.

You can test this by updating the MTA-STS policy to include both forms
of the MX hostname (and sunsequently change the "id" field of the
MTA-STS TXT record).  If the problems go away, that'll confirm the
hypothesis.

> If so, what error should the reporter use, as per [RFC8460], in an 

You'd have to look at RFC8460, where I don't actually see a good fit
for this case... :-(

> validation-failure?

That seems about the closest.

-- 
    Viktor.