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
expansions)
My apology if I missed something here. I certainly don't wish to waste
anyone's time.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
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.
john
--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
fully-
qualified domain names (FQDNs): mechanisms for inferring
FQDNs from
partial names or local aliases are outside of this
specification.
Due to a history of problems, SMTP servers used for initial
submission of messages SHOULD NOT make such inferences
(Message
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
was
associated with an implicit MX RR, with a preference of 0,
pointing
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
MUST be
reported as an error. The result of an MX lookup MUST NOT
be a
CNAME.
</techie hat off>
Tony Hansen
tony(_at_)att(_dot_)com
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Closing out the comments, Tony Hansen
- rfc2821bis-07 (was: Re: Closing out the comments), John C Klensin
- Re: rfc2821bis-07, Tony Hansen
- Re: rfc2821bis-07, John C Klensin
- Re: rfc2821bis-07,
Hector Santos <=
- Re: rfc2821bis-07, John C Klensin
- Re: rfc2821bis-07, Hector Santos
- Re: rfc2821bis-07, John Leslie
- Re: rfc2821bis-07, John C Klensin
- MX to CNAME and (mis)interpretation of 2821 (was: rfc2821bis-07), Frank Ellermann
- Re: MX to CNAME and (mis)interpretation of 2821 (was: rfc2821bis-07), John C Klensin
- Re: MX to CNAME and (mis)interpretation of 2821, Alessandro Vesely
- Re: MX to CNAME and (mis)interpretation of 2821, SM
- Re: MX to CNAME and (mis)interpretation of 2821, Alessandro Vesely
- Re: MX to CNAME and (mis)interpretation of 2821, Hector Santos
|
|
|