ietf-smtp
[Top] [All Lists]

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

2007-12-12 17:06:19

I'm currently at odds with a few folks regarding the interpretation of
RFC 2821 and the case of MX records that resolve to CNAMEs. I'm hoping
that those here, who are authoritative when it comes to this RFC, can
shed some light.

First of all, as a practical matter, people set things up this way on a regular
basis. Additionally, the strategy a lot of software uses to process the results
of MX lookups (i.e., call some external resolver library) not only will allow
CNAMEs to be used and may even be incapable of detecting that a CNAME was used.

As such, such  setups "mostly work" irrespective of their standards status. And
even if you're technically in the right when arguing such a point, it can be
difficult to rebut the "but it works with everyone's else's system so why not
yours?" argument.

According to RFC 2181, this is invalid. You cannot have an MX record
that resolves to a CNAME.

Correct. And you should also note that RFC 2181 is conspicuous by its absence
from the list of RFCs that RFC 2821 updates. That provides a fairly strong
indication that the rules it establishes are still in force.

However, in talking to TrendMicro, they say that this syntax is
perfectly valid and that RFC 2821 overrides the MX to CNAME limitation.
The following website is their stance on this:
http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&i
d=EN-1035667

However, in talking to others, they say that TrendMicro is
misinterpreting the RFC. I'll admit after reading 2821, I could
interpret things both ways.

I don't think TrendMicro's reading is sensible. They quote sections  2.3.5 and
5 of RFC 2821 as supporting their claim. The relevant text is:
        
  "Domain names are used as names of hosts and of other entities in the domain
  name hierarchy. For example, a domain may refer to an alias (label of a CNAME
  RR) or the label of Mail exchanger records to be used to deliver mail instead
  of representing a host name."
         
and:

  "Once an SMTP client lexically identifies a domain to which mail will be
  delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup
  MUST be performed to resolve the domain name [22]. The names are expected to 
be
  fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from
  partial names or local aliases are outside of this specification and, due to a
  history of problems, are generally discouraged. The lookup first attempts to
  locate an MX record associated with the name. If a CNAME record is found
  instead, the resulting name is processed as if it were the initial name." 

In both of these paragraphs it is quite clear that the CNAME being referred to
is one associated with the initial lookup of the domain extracted from the
email address. This text is entirely silent about CNAMEs produced by an MX
lookup. And since it is silent on this point the rules of RFC 2181 remain in
force.

This is why I come to you folks who are responsible for this RFC. Who is
right? Is MX -> CNAME now allowed by 2821, or is TrendMicro in the
wrong?

Would it also be possible to state directly within the next revision of
the RFC where or not this RFC overrides the provision 10.3 of RFC 2181.
I don't want to leave things left to misinterpretation.

It's possible but IMO not a good idea. Sure, we could state that this condition
remains in force, but what does that then mean if there were a revision to RFC
2181 that changed the requirement in some way? Additionally, there's a
slippery slope we're getting close to: If we start listing all the stuff
that a given RFC doesn't override where do we draw the line?

No, the way this is supposed to work - and IMO should work - is that when an
RFC overrides a condition imposed by another that RFCs says explicitly that it
is doing exactly that and lists the RFC it is overriding in the Updated: list.

Now, some may point out that there have been cases where one RFC updated
another but didn't say so. If that's found to be the case we have this thing
called an RFC errata process and I see no reason why it couldn't be used in
such cases.

                                Ned