ietf-smtp
[Top] [All Lists]

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

2021-03-31 20:03:54
On Thu, Apr 01, 2021 at 12:44:43AM +0300, Kristijonas Lukas Bukauskas wrote:

* 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.

[ Congratulations by the way on your working DANE deployment:
    https://stats.dnssec-tools.org/explore/?n0.lt

    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 
60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
    _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

  I should perhaps mention that the first "2 1 1" record above, matching
  the "X3" CA is obsolete and should now be dropped:
    http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html ]

_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]_

Indeed their implementation is flawed.  They should either streadfastly
refuse to deliver email to all domains where the the MX is a CNAME, and
so outside the interoperability scope of RFC5321.  Or, if like most
MTAs, they're pragmatic and allow CNAMEs, the CNAME should not affect
the logical MX host name used with MTA-STS, just as would be the case
with web browsers, etc.

With MTA-STS, the CNAME is just an indirect means of finding the MX
host's address records, and given that is generally not securely
obtained (though DNSSEC-signed in your case).  It should not change
the sender's notion of the logical nexthop relay hostname.

However, all that said, 8461 is silent on CNAMEs in MX hostnames, and so
there is no definitive guidance on this question.  The above is just my
personal viewpoint, based on extrapolation from similar contexts and
some handwaving logic.

* 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.

An even better solution is to AVOID the CNAME, and publish the
underlying A/AAAA records directly for mx.n0.lt.  That would be
by far the most sensible approach, given that CNAME-valued MX
RRs lie outside the scope of interoperable behaviour defined
in RFC5321, and are comparatively rare.

Using a biased sample of 14,552,195 DNSSEC-signed domains, only 58,451
of them (0.4%) have CNAMEs for their MX records.

Another sample is ~102k domains reported in Google email transparency
reports over the past month.  These have a total of 240,182 MX records
of which 690 (or ~0.28%) resolve to CNAMEs.

So my best guess is that ~0.3% +/- 0.1% of MX records are CNAMEs.  As
noted by others, if this is causing you some issues, avoid use of
CNAMEs.

-- 
    Viktor.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp