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.