--On Friday, 22 February, 2008 10:25 -0500 John Leslie
<john(_at_)jlc(_dot_)net> wrote:
John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
--On Thursday, 21 February, 2008 16:20 -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Unless I am missing something, it isn't just better to say
something to the effect?
"SMTP DNS Administration MUST|SHOULD NOT include CNAME
resource records when creating email domain MX records
for the SMTP server setup."
John K doesn't seem to have responded to this particular
text.
I mean, I don't think it is reasonable to discourage DNS
CLIENT software to ignore the very good possibility that a
query might historically return a CNAME which needs to
resolve as well for the final expansion.
To the extent to which we consider such CNAMEs to be a
problem, the _only_ way to get rid of them is precisely to
encourage client software to complain. If we don't care, this
should be a SHOULD at most (and a SHOULD here will be taken
as license to use CNAMEs there).
Huh? The comment quoted above _was_ my response. What would
you like to convince you I have responded?
Personally, I think this battle is long since lost;
however...
The audience for this document is not, for better or worse,
domain administrators.
... which is why, IMHO, we need to be especially clear if we
wish to restrict what they do. They _may_ read a paragraph or
two when somebody points out "the error of their ways" -- but
they will _not_ read for context.
The text in question, IMHO, is not sufficiently clear:
"
" The result of an MX lookup MUST NOT be a CNAME.
could mean a number of things -- one of the most logical being
that the SMTP client software is _obligated_ to resolve any
CNAME it encounters. (The DNS administrators reading this text
would know there are any number of middlemen between what they
configure and what the system code called by client software
may return.)
At some level, we don't care what you do that goes beyond the
bounds of the standard to deal with a case that the standard
prohibits. If you come to the conclusion that you should
handle these things, then you should do it -- you are still
conforming wrt the specified behavior. The only thing that
would make you non-conforming would be an explicit statement
that says that you MUST reject such a thing. And it rather
carefully doesn't say that.
... but it could be read to mean you MUST NOT reject such a
thing...
I just do not see how it could be read that way, but bow to your
obviously more creative imagination.
And, if you think that concept needs to be explained better in
the text, please suggest words.
If we're trying in any way to control what DNS
administrators do, we should have text like:
"
" DNS administrators MUST NOT configure DNS servers for zones
" they control to return a CNAME for an MX lookup.
If we're trying to control what (some) SMTP client software
does, we should have text like:
"
" SMTP client software SHOULD return an error if it receives a
CNAME RR in response to an MX lookup.
... or, of course, "MAY return an error..." -- I have no horse
in this race. We could include both, or neither, for all I
care. I just think the current text is not helpful.
Let me repeat what I tried to say to Hector. The question
isn't what we tell the client, it is what we tell server
operators and, by extension --but _only_ by extension-- those
who set up DNS configurations.
Option 1: If you put a string associated with a CNAME
record in the DATA field of an MX record, you are
violating the SMTP standard and all bets are off. The
client system can use its own imagination about what to
do with your mail traffic but certainly isn't obligated
to process it.
Option 2: If you put a string associated with a CNAME
record in the DATA field of an MX record, the client
system is expected to process it. Note that "is
expected to" can be expressed as either a MUST or SHOULD
requirement on the client -- the sender has the right to
assume that it will probably work.
Option 3: If you put a string associated with a CNAME in
the DATA field of an MX record, the client is required
to reject it. I.e., that form will not work with any
conforming client.
Option 4: If you put a string associated with a CNAME
record in the DATA field of an MX records, the client
system may process it or may not; you are engaging in a
guessing game.
I suggest that option 4 makes no sense at all in a standard. We
shouldn't do guessing games. Option 2, however worded, is the
option we have rejected, i.e., that data strings that identify
CNAMEs are fully valid and one can expect (by invoking the
robustness principle if necessary) that they will be looked up
and resolved.
And that leaves us with Option 1. Note that, while we decided
in DRUMS to leave the problem to the DNS specs and so 2821
doesn't say anything about it (at least that I could find
quickly), this is exactly the same way we handle the broken
practice of putting IP addresses, rather than domain names, in
the data fields of MX records -- it is outside the standard, we
don't comment on it, but we don't _require_ that clients reject
such things. That gives Hector (and others) the flexibility
they want without either (i) making them non-conformant or (ii)
requiring that everyone, in practice, support CNAME resolution
out of MX records.
Certainly, if we stick with Option 1 and the language isn't
clear enough, the relevant sentence can be supplemented with an
explicit statement to the effect that any values that point to
CNAMEs that appear are nonconformant and out of the scope of the
standard.
Now, all of that said, the historical reason for the prohibition
on names that point to CNAME RRs in the data field of MX RR was,
I believe, to reduce the risk of looping within the DNS. That
decision was made before there were NAPTR records (or the
newly-proposed URI record), which provide such ample
opportunities for loops that any sensible DNS resolver software
must, of necessity, take precautions against the general case.
If we believe that knowledge is sufficient protection, then the
instructions to clients can sensibly to changed to "MAY" (or, if
it were not for the "no new features" rule and
interoperability/implementation testing, "SHOULD")-- it leaves
things tad unpredictable but doesn't cause significant
conformance issues.
john