John Leslie wrote:
Let me apologize up front for taking Keith seriously; but he has taken
me seriously on several occasions, and I feel an obligation to return the
favor:
gee thanks. I think.
That pseudocode deserves to be read; though I'd pay more attention
to the difference between "permanent_failure" and "temporary_failure".
And if you're writing code to do this in an IPv4-only world, it's
tempting to put a special case in the "get mx records" routine of the
form "if there are no MX records, return a single "implicit" pseudo-MX
record that points to that domain".
Actually, I wouldn't have tended to program it that way. I think the
point is it looked to be easier to _specify_ it that way.
That's just a hypothesis on my part. I may be reading more into the RFC
974 than is justified.
My point is that we're getting tripped up by an artifact of the way that
RFCs 974 was worded - and in the process we're making inferences about
the interpretation of those words that probably weren't intended by the
author. If RFC 974 had said
It is possible that the list of MXs in the response to the query will
be empty. This is a special case. If the list is empty, mailers
should simply attempt to deliver the message to REMOTE. The idea
here is that if a domain fails to advertise any information about a
particular name we will give it the benefit of the doubt and attempt
delivery.
instead of
It is possible that the list of MXs in the response to the query will
be empty. This is a special case. If the list is empty, mailers
should treat it as if it contained one RR, an MX RR with a preference
value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
MX). In addition, the mailer should do no further processing on the
list, but should attempt to deliver the message to REMOTE. The idea
here is that if a domain fails to advertise any information about a
particular name we will give it the benefit of the doubt and attempt
delivery.
...then I think we'd be paying attention to the salient issue in our
discussions today - which is that "give it the benefit of the doubt" is
no longer the right idea. (granted we still have the backward
compatibility issue, but that's less important for v6 than for v4).
In an IPv4+IPv6 world this becomes even a bit more important.
Let's see if Keith can make this case...
Well, my point was that we're making inferences based on the "implicit
MX" idea that might not really be warranted. As I said above, I might
be reading too much into the intent behind the RFC 974 wording. If the
only purpose of that code analysis is to support my assumptions about
the motivation for the wording in RFC 974, it might not be worth the
trouble to try to explain it. (but if you're really curious, see the
postscript below)
Keith
p.s. Before sending this reply, I considered how I'd write the code in
both cases - one where the "get MX records" routine returned an implicit
MX in the case of no explicit MX records, and the other where it did
not. Mostly the differences seem to be
(a) if you get NXDOMAIN when trying to find addresses from an explicit
MX record, this need not cause delivery failure - you just skip to the
next MX record. It's only a problem when you get NXDOMAIN for all of
the MX records - and then it's still a subtly different error from the
case where you get NXDOMAIN on the domain name that appears in the email
address (and in the "implicit MX" record).
(b) similar to (a) but instead of NXDOMAIN errors you get a response
with no answers to your query for address records. again, for an
ordinary MX record this isn't fatal, but for an "implicit MX" record it
is fatal. (but it's a slightly different case than (a) in that you
probably want to issue a different error message).
(c) if the "get MX records" routine doesn't return an implicit MX
record, you can avoid a few unnecessary DNS queries. but if you have an
internal DNS cache in your MTA this might not matter much.