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].
This seems fine to me.
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.
Agreed.
Any such extension would, of course, have to update 2181 or
equivalent as well as extending SMTP.
Seems fairly unlikely, but as you say, it's harmless.
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.
This doesn't constrain client handling of invalid cases so I'm good with
it.
Ned