[Top] [All Lists]

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

2021-03-31 19:08:01
Kristijonas Lukas Bukauskas writes:


I'm having an affair with one of the vendors as a sending MTA, honoring MTA- STS (RFC 8461). Their response:

   • Our TDS validation shows MX lookup for returns instead of It is consistent with what we are seeing with production. 

MX lookup for returns                  269     IN      MX      10

The CNAME comes from A and AAAA lookups on That's my understanding of how DNS works. If you look up a record, and there's a CNAME for it, you get the CNAME then the record for the alias (if trusted, else the onus is on you to rerun the query). If you look up a record and it exists, you get it. Whether the name is another hostname, and that hostname has a CNAME alias, that's not the road that's been traveled, yet.

Selecting an MX target host is regulated in a different RFC, namely and specifically in <URL:>RFC 5321 §5.1:

I don't see this as an MX selection issue but as an STS validation issue. My stack agrees that the STS policy is valid.

$ testmxlookup --dnssec
STS: enforcing
Relay:, Priority: 10, Address: ::ffff: (DNSSEC)
Relay:, Priority: 10, Address: 2a03:b0c0:2:d0::d1b:a001 (DNSSEC)

CNAME here involves the resolution of the hostname. The resolves to Everything here passes my interpretation of STS verification rules.

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. 

I see nothing in RFC 8461 that seems to disallow it. In fact, this statement seems rather unambiguous to me:

4.1.  MX Host Validation

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

The "MX" record here is:                  300     IN      MX      10

That's the DNS record.

And it squares up with the policy file. And the "Server Identify Check" portion in rfc6125 seems to prohibit using CNAME aliases for hostname validation:

2.4.  Server Identity Check

  During the TLS negotiation, the client MUST check its understanding
  of the server hostname against the server's identity as presented in
  the server Certificate message, in order to prevent man-in-the-middle
  attacks.  Matching is performed according to these rules:

  o  The client MUST use the server hostname it used to open the
     connection as the value to compare against the server name as
     expressed in the server certificate.  The client MUST NOT use any
     form of the server hostname derived from an insecure remote source
     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

This seems to be consistent with traditional certificate validation rules:          60      IN      CNAME

My browser is happy to load, and validate the certificate for the CN of, instead of this alphabet soup.

An alternative interpretation here would have the result of the STS policy file validating, but a TLS connection will need to validate a certificate for In this case it wouldn't matter, the same cert works for both, but that doesn't quite add together, for me.

Attachment: pgpsPsF3R4_W1.pgp
Description: PGP signature

ietf-smtp mailing list