At 4:55 pm -0400 7/4/2008, John C Klensin wrote:
I believe, that I shifted away from (i) at the behest of one of
the folks on the DNS side of the issue to make sure that the
second lookup was not required if there were no DNS records at
all for the name first looked up.
RFC 974 is quite clear about this, under "Issuing a Query":
Certain responses to the query are considered errors:
...
Getting a response in which the response code is non-zero.
Mailers are expected to do something reasonable in the face of an
error. The behaviour for each type of error is not specified here,
but implementors should note that different types of errors should
probably be treated differently. For example, a response code of
"non-existent domain" should probably cause the message to be
returned to the sender as invalid, while a response code of "server
failure" should probably cause the message to be retried later.
RFC 2821 (and 2821bis) on the other hand do not appear to clearly
state that a "non-existent domain" error should cause a message to be
returned to the sender as invalid.
For the case where the domain name does exist, but an empty list of
MX records is returned, it is always going to require additional DNS
lookups to ascertain that there are address records, so there is no
gain in specifying that a check for address records is done before
proceeding with an implicit MX.
I think the "No MX records found/present" wording for the choice to
use an implicit MX is rather ambiguous, I think it would be better to
use the "empty list" wording of RFC 974.
I propose something like this for the second half of the first
paragraph of section 5.1:
The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found, the resulting name is processed as
if it were the initial name. If a non-existent domain error is
returned, this situation MUST be reported as an error. If a temporary
error is returned, the message MUST be queued and retried later
(refer to sending strategy section?). If an empty list of MXs is
returned, the address is treated as if it was associated with an
implicit MX RR, with a preference of 0, pointing to that host. If MX
records are present, but none of them are usable, or the implicit MX
is unusable, this situation MUST be reported as an error.
Glenn.