--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."
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.
I'm mostly in agreement with Hector here.
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.
Exactly what form is this "encouragement" supposed to take? From a client
operator's point of view you have three options when you encounter an MX that
resolves to a CNAME:
(1) Resolve the CNAMEs and use the results if they make sense, bounce if they
do not.
(2) Same as (1), but send a warning somewhere.
(3) Reject the mail unconditionally.
The main concern of client operators is always to insure mail is successfully
relayed off their system. In the present climate of filtering, blacklisting,
feedback loops, and other assorted fallout of the fight against spam, this has
become increasingly difficult and time-consuming, especially if you're dealing
with a large volume of messages.
So where's the incentive to be picky about MXes resolving to CNAMEs? If a
client operator rejects mail on this basis it preumably gets reported to the
originator, who is (a) Not in a position to fix the problem and (b) Is then
likely to contact the client operator and complain. Support calls are a
significant expense for many client operators and ones which the client
operator is not going to be able to fix the problem anyway are a resounding
lose all around.
I therefore assert that option (3) makes absolutely no sense operationally.
As for option (2), the question then becomes who to alert about the problem.
Sending mail about it to, say, postmaster(_at_)problemdomain is pretty much
guaranteed to be a waste of time. And even if it it manages to find someone
who cares, engaging in a dialogue with someone who doesn't know how
to set up MX records is not helping the client operator any.
I therefore claim that option (2) is, at the very best, "mostly harmless" and
makes little if any operational sense.
Now, from an implementor's perspective, depending on the APIs you use it can
actually be difficult to turn off CNAME resolution, and even more difficult to
detect that an address lookup went through CNAME redirection. So here we
have something that is hard to implement and makes no operational sense.
So I repeat: What encouragement are we able to provide to get people to
implement and operate things this way? We are now light years past the point
where people do stuff simply because they get warm fuzzies from conforming to
sometihng a specification recommends.
(Of course none of this applies if the CNAME causes a loop - that has to be
dealt with. And if enforcing this restriction prevented all such loops that
would be ample justification for it. But it doesn't do that: There are many
other ways MX records and MTAs can be misconfigured to cause a loop without
using CNAMEs.)
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). The audience for this document is not, for
better or worse, domain administrators.
Frankly, I think we're being awfully kind to ourselves if we think whatever we
say is going to give license, or prevent for that matter, this behavior. As you
say, domain administrators aren't going to read this no matter what it says.
The reality is that having MXes point at CNAMEs mostly works and this is
unlikely to change. And that means people will on occasion set it up, find it
works, and go with it.
In other words, am I suppose to remove the logic from my DNS
client based on the idea that they should never be a CNAME in
a MX query? Sure, its the other guys fault, but I don't think
any implication to abort, abend or stop a transaction because
of it is reasonable.
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.
This ignores the fact that in many cases it is actually more work to prohibit
CNAME resolution than to allow it. You might get some traction if it was mostly
the other way around and client vendors had to go to some effort to handle
CNAME, but that's not how it is.
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.
Which IMO is the only reasonable course. Although I think the continued
prohibition of MXes pointing to CNAMEs is a little silly I have no problem
retaining it as long as it doesn't recommend, let alone require, clients check
for and reject or warn in this case.
To paraphrase Postel's Law:
Be conservative with what you do (define proper MX record setup),
be liberal in what you receiver. (CNAME might appear in MX
expansions)
Sigh. Without going into a long rant, if this type of
interpretation of the robustness principle were widely applied,
we wouldn't have an interoperable email fabric today because
various extensions and other changes would have been impossible
and everything would have long ago descended to some least
common denominator (or below it).
Taken to an extreme, perhaps - but anything taken to an extreme tends to be
bad. However, email actually affords us some opportunity to observe the merits
of this approach to the robustness principle in an operational context. We have
essentially four protocols here: RFC2822/MIME, SMTP/SUBMIT, POP3, and IMAP4.
SMTP and RFC2822/MIME are in many ways the embodiment of the robustness
principle: The specifications are fairly loose syntactically and allow for lots
of variability plus Implementations tend to be very forgiving and will in many
cases attempt to make sense out of complete crap. (And wonder of wonders, they
even succeed sometimes.)
IMAP4 and to a lesser extent POP3 is the exact opposite. The specifications are
syntactically pretty tight and implementations tend to follow suit. Slight
deviations from the specifications tend to give rise to errors.
So what has this accomplished? The SMTP relay fabric, despite haveing taken
numerous hits in recent times from various well-meaning but misguided attempts
to combat spam, is operationally very robust and achieves an extremely high
degree of interoperability. Indeed, we're now at a point where reports of SMTP
interop problem reports are now pretty rare (for us at least).
The same cannot be said for IMAP4 and to a lesser extent POP3. Problems abound.
We have have vendors who insist on reading those tightly written specifications
in very wierd ways, we have vendors who cut corners left and right on
compliance to those specifications, we have clients that insist on certain
extensions being present when they could easily do without, and so on. It's
gotten to the point where longtime implementors like Mark Crispin are publicly
pessimistic about what the future holds. (Mark, feel free to correct me if you
feel I've misstated your position here.)
Of course this is a far from perfect comparison, for several reasons. One is
that IMAP4 is a lot more complex than SMTP and therefore easier to screw up.
OTOH, the interplay between state changes and error handling in SMTP is
surprisingly complex in practice, especially in the pipelining case. And both
protocols have tons of extensions defined, which adds sigifnicant complexity to
both.
There are also differences in usage patterns that arguably make it easier for
problems to creep into IMAP4 setups and stay.
But even taking all the equities into account, I think there's still a case to
be made that laxity taken in moderation has helped SMTP more than it has hurt.
(Note, however, that there's a very big difference between tightening down a
loosely specified protocol versus loosening up a tightly specified protocol.
I'm arguing that the former is bad, not that the latter is good.)
Indeed, the one problem with SMTP interoperability we still encounter from time
to time is the direct result of a tightening of the rules in RFC 2821: The
requirement that bare CR and LF not be interpreted as a line break. When RFC
2821 came out with this change we changed our default behavior and it has
caused nothing but problems. (We no longer get reports of this very often
because we have now advised many customrs to revert to the old way of doing
things, standards compliance be damned. I should also add that I can count the
number of times tightening things down actually helped us solve an interop
problem in this area using just my index fingers.)
The current text precisely
permits you to apply the intent of that principle because it
doesn't prohibit you from accepting and interpreting something
that is non-conforming to the standard. It just doesn't require
you to do that, which would effectively allow CNAME in all cases.
Which is why I have no objection to the current language. After the experience
with bare CR and LF I would strongly object to any similar change.
My apology if I missed something here. I certainly don't wish
to waste anyone's time.
No, I think your question is quite reasonable. But this is very
much one of the reasons why neither 2821bis nor its predecessors
make unqualified references to 2119.
And, if you think that concept needs to be explained better in
the text, please suggest words.
I don't especially care what the words say as long as clients are
free to handle this case as they see fit.
Ned