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
<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 ). 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  have somewhat more flexibility) and
intermediate (relay) SMTP servers MUST NOT make them.
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
</techie hat off>