[Top] [All Lists]

Re: What is the history of 2821 and implict MX?

2008-04-07 17:29:49

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.