[Top] [All Lists]

Re: MX to CNAME and (mis)interpretation of 2821

2008-02-24 07:02:38

SM wrote:
At 02:15 23-02-2008, Alessandro Vesely wrote:
An MTA learns if it is part of the MX-list retrieved for delivering a given message by either comparing MX names to its own canonical name or checking if an MX IP number belongs to one of its local interfaces. However, the latter method doesn't work across NATs or split DNSes. Thus, setting the canonical name in the MX records is required for reliable operations of backup MXes.

Setting the canonical name in the MX records is not required as you can always add the domain name to the MTA configuration.

IMHO, that name in the MTA configuration is what one should call "canonical". Besides using CNAME, one can also fool a backup MX by setting several vanity names all having equal A (or AAAA) records. An MTA may fail when it discovers that the IP it is about to deliver is local. Thus, a backup MX won't work even through the DNS is apparently compliant, as no CNAMEs are being used and each host on the MX list has a corresponding address record.

The situation is cumbersome, since rfc1035 says nothing on MX semantics, referring to rfc974. Indeed, the algorithm is explained in rfc974, but it is "Obsoleted by: 2821", the SMTP being updated. However, rfc2181 updates rfc1035 and has a section 10.3 "MX and NS records" where it says

 The domain name used as the value of a NS resource record, or part of
 the value of a MX resource record must not be an alias.  Not only is
 the specification clear on this point, but using an alias in either
 of these positions neither works as well as might be hoped, nor well
 fulfills the ambition that may have led to this approach.  This
 domain name must have as its value one or more address records.

Thus, it seems it is up to rfc2821bis to be "clear on this point."

Even if backup MXes are not widely used today [...]

The MX to CNAME restriction is not about a ban on backup MXes.

On the opposite, backup MXes are the only reason for that restriction, AFAIK.