ietf-smtp
[Top] [All Lists]

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

2007-12-12 17:49:27


Sounds to me like this is a great opportunity to get this resolved once
and for all. If the intent of 2821 was never to override the provisions
of 2181, then Mr. Klensin could state this specifically within the RFC.

I have already explained why I believe this to be a bad idea.

I believe that the confusion lies around the CNAME provision dealing the
left hand side of the MX record, not the right hand side. This is where
people get confused. The following paragraph can be interpreted to allow
CNAMES as the result of an MX lookup; this paragraph may need to be
clarified:

5.1.  Locating the Target Host
 ..... 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.  If no MX records are found,
but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA RR, or
their successors) is found, the address RR is treated as if it was
associated with an implicit MX RR, with a preference of 0, pointing to
that host....

That is the section that is confusing people. You can read it to say
"When you do an MX record lookup, and the result is a CNAME, then ...
blah blah blah.."

That might be the case if the sentence didn't end with "as it it were the
initial name". Given that clause there's no way to read it as applying to the
MX result and have the resulting operation make sense. THis reading would
effectively allow an MX to refer to another MX through a CNAME, which is
clearly not the intent and I believe is in fact banned elsewhere.

To the folks that I've talked to, they say that this
one statement allows an MX record to point to a CNAME. Again, if is this
not the case nor the intention, I'd love to see this latest revision
updated to categorically state that.

John will have to speak to the intention, but I have to say that the examples
provided thus far (and I note that the Trend Micro did not in fact cite this
particular section in their attempt to justify their behavior) are a long way
from making the case that it is reasonable to read 2821 this way.

As for updating the specification, I have no problem with adding a statement
that the result of an MX lookup MUST NOT be a CNAME if there is consensus to do
so. I strongly object, however, to adding statements along the lines of "this
document doesn't update this other RFC". That's a path to madness.

                                Ned