ietf-smtp
[Top] [All Lists]

Re: MX to CNAME and (mis)interpretation of 2821

2008-02-24 11:23:06

Folks,

This has been an interesting discussion. However, the problem remains a DNS one and it is covered quite clearly in RFC 2181 (something I didn't fully realize when I wrote my previous note on the subject).

The tentative text in 2821bis-08 now reads as follows, in the hope of being tediously clear (thanks go to John Leslie for the core of this and to several others for convincing me that even more clarification was needed):

# When a domain name associated with an MX RR is looked up and
# the associated data field obtained, the data field of that
# response MUST contain a domain-name.  That domain-name, when
# queried, MUST return at least one address record (e.g., A or
# AAAA RR) that gives the IP address of the SMTP server to
# which the message should be directed.  Any other response,
# specifically including a value that will return a CNAME
# record when queried, lies outside the scope of this
# standard.  Such responses could, in principle, be covered by
# an SMTP extension in the future.  The prohibition on labels
# in the data that resolve to CNAMEs is discussed in more
# detail in RFC 2181, Section 10.3 [29].

Please note that this does not forbid CNAMEs except by example. It forbids literal addresses and any label that points to a non-address record type. That is consistent with 2181. I am a little dubious about the practical likelihood of the sentence starting with "Such responses...", but don't see it as harmful. Any such extension would, of course, have to update 2181 or equivalent as well as extending SMTP.

Now, while I would welcome suggestions for additional improvements, I don't believe that it is worth spending a lot more time on the subject, especially since these are post-last-call changes. So, if you make comments, please explicitly indicate whether or not you can live with the current text. If you can, I'll apply editorial judgment. If you cannot, it becomes Tony's problem to create a formal issue and manage a discussion of it.

     john

<Prev in Thread] Current Thread [Next in Thread>