[Top] [All Lists]

Re: rfc2821bis-07

2008-02-21 14:47:14

Unless I am missing something, it isn't just better to say something to the effect?

   "SMTP DNS Administration MUST|SHOULD NOT include CNAME resource
    records when creating email domain MX records for the SMTP
    server setup."

I mean, I don't think it is reasonable to discourage DNS CLIENT software to ignore the very good possibility that a query might historically return a CNAME which needs to resolve as well for the final expansion.

In other words, am I suppose to remove the logic from my DNS client based on the idea that they should never be a CNAME in a MX query? Sure, its the other guys fault, but I don't think any implication to abort, abend or stop a transaction because of it is reasonable.

To paraphrase Postel's Law:

   Be conservative with what you do (define proper MX record setup),
   be liberal in what you receiver. (CNAME might appear in MX

My apology if I missed something here. I certainly don't wish to waste anyone's time.


Hector Santos, CTO

John C Klensin wrote:
This (reparagraphing) change has been tentatively made to -08.
I can also change the final sentence to read "The DNS DATA field
associated with the lookup of an MX record must not contain a
domain that, in turn, is associated with a CNAME record" or
something to that general effect if people are convinced it
would be more clear rather than more confusing.


--On Thursday, 21 February, 2008 11:16 -0500 Tony Hansen
<tony(_at_)att(_dot_)com> wrote:

Alessandro Vesely wrote:
 > Derek J. Balling wrote:
 >> I know this may be a dead horse, but...
 >> "The result of an MX lookup MUST NOT be a CNAME."
 >> Can this *please* be slightly reworded? "The RR value of
an MX
 >> lookup..." perhaps?
It is the compound "MX lookup" that generates ambiguity, as
it is used to indicate the initial lookup of the domain name.
Actually, that's what the whole first paragraph in 5.1 is
talking about. If it were considered a minor change, I'd
propose moving that sentence to the end of the next
paragraph, where its rationale can be grasped more easily.
<techie hat on>

I'm thinking that the problem really lies in the paragraph
being so long and covering multiple steps. If it were split
apart like this, I think it would be more obvious where each
statement applies in the flow:

    Once an SMTP client lexically identifies a domain to which
mail will
    be delivered for processing (as described in sections
Section 2.3.5
    and Section 3.6), a DNS lookup MUST be performed to
resolve the
    domain name (RFC1035 [6]).  The names are expected to be
    qualified domain names (FQDNs): mechanisms for inferring
FQDNs from
    partial names or local aliases are outside of this
    Due to a history of problems, SMTP servers used for initial
    submission of messages SHOULD NOT make such inferences
    Submission Servers [41] have somewhat more flexibility) and
    intermediate (relay) SMTP servers MUST NOT make them.

    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
    associated with an implicit MX RR, with a preference of 0,
    to that host.

    If one or more MX RRs are found for a given name, SMTP
    systems MUST NOT utilize any address RRs associated with
that name
    unless they are located using the MX RRs; the "implicit
MX" rule
    above applies only if there are no MX records present.  If
MX records
    are present, but none of them are usable, this situation
    reported as an error.  The result of an MX lookup MUST NOT
be a

</techie hat off>

        Tony Hansen