--On Wednesday, 26 March, 2008 00:27 -0700 Bill Manning
what this daft is trying to do is force the presumptive
existance of an MX in a zone into an explict rule that
forces the existance of an MX, else SMTP fails.
While several people have suggested that, it is not what the
draft says and would be a significantly incompatible change.
What the draft basically says is that, if there is no MX record
present, one should go looking for the same domain name with an
address record type and, if such a thing is found, construe the
address record as if it were associated with an MX record with
preference of zero.
With one qualification, that has been the rule ever since RFC
974 was written. That rule was reaffirmed in RFC 1123. There
was no change to it in 2821.
At the time 974 and 1123 were written, the only sort of address
record in Class=IN was an A RR, and those documents used "A RR"
terminology. The change in 2821bis essentially substituted the
phrase "address record" (or "address RR") for "A record" because
(i) that seemed to be consensus on the list at that time and
(ii) there is significant, although not universal, existing
practice that is consistent with treating IPv4 (A) and IPv6
(AAAA) RRs the same way, at least with regard to SMTP.
With that change to "address record", if no MX record is found,
the SMTP client is required to look for DNS names with either A
or AAAA RRs, rather than A RRs only.
As far as I can tell, the _only_ real question here is whether
that "either type of address record can be used as an implicit
mail destination if no MX record is present" rule, which is now
in the text, is the correct one. If it is not, then the only
other option is to try to keep the implicit destination rule to
A (IPv4) records only, which would essentially require that an
MX record be present if one wanted to deliver mail to an IPv6
The questions of whether MX records should be generally
required, what happens when an application chooses to ignore the
MUST NOT rule in Section 5.1 and use address records when an MX
record is present, and a number of other issues are, it seems to
me, very interesting but not relevant here... if only because
they would constitute very significant and incompatible changes
from 2821 and to the installed base. There is, separately, some
language in Section 2.3.5 about the types of domain names that
can be used as FQDNs in mail sessions; I don't believe those
rules are affected by this discussion either.
We could look at the question by asking whether the fallback
MX behavior should be an operational decision. But then we
would be treating IPv4 and IPv6 differently.
IPv4 and IPv6 are different.
Bill, I don't know what you are advocating any more. It seems
to me that, by saying that you want to be able to run a mail
server without MX records and with IPv6 only (I think you said
that, but maybe I understood), you are asking for exactly the
behavior that is now in the specification, i.e., that either A
or AAAA RRs can be used to form an implicit MX. For this
purpose, that makes IPv6 and IPv4-related DNS records pretty
much the same, no matter what the differences are between the
In addition, the applications area has been told, repeatedly,
that its protocols should, by default, treat IPv6 like IPv4,
keeping any differences in treatment to a minimum. So, saying
"IPv4 and IPv6 are different" at this stage, while true, does
not seem sufficiently explanatory to be a useful contribution to
IETF mailing list