Speaking for myself and not presuming to speak for "many
people", I think the following statements are both true and that
they are perfectly consistent with each other.
(i) It would be a fairly bad idea for the protocol to require an
MX record for AAAA but not for A. Part of my reasoning is that
some of the arguments for prohibiting implicit MX generation on
AAAA fall apart for hosts that also have IPv4 addresses, since
those addresses will cause the the MXs to be generated anyway.
I've always thought the "implicit MX generation" language was a bit
contrived. Really what was needed was not an "implicit MX" per se, but
rather, backward compatibility with the pre-MX behavior that if you
wanted to send mail to user(_at_)domain and you had an IP address for that
domain, you opened up a connection to port 25 at that IP address and
started talking SMTP to it.
If you're a programmer and writing code to handle this, it's pretty
natural to want a routine that gets you an ordered list of MX records.
That way you can say something like:
mxlist = get_mx_records_in_order (domain)
for each mx in mxlist {
status = try to deliver mail to mx;
if status == success
break
else if status == permanent_failure
bounce_message()
break
else if status == temporary_failure
continue
}
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". Then the code that calls this
routine will "do the right thing"...more or less. (I say "more or less"
because there are subtly different error conditions for the "real MX"
case than for the "implicit pseudo-MX" case that might require more
special-casing to handle errors correctly under all conditions.)
But what is really happening here is that the special-casing is being
done in the wrong place. Even in an IPv4-only world it is better to
treat the "MX" and "no MX" cases separately in the delivery routine
rather than to try to hide the differences in the mx lookup routine. In
an IPv4+IPv6 world this becomes even a bit more important.
And I believe that "interpret some MXs as applying only to the A
records associated with the target host while interpreting
others as applying to all address records" as leading us into a
world of confusion and harm.
I agree with that, but because I don't think the "implicit MX record"
was a good way to describe the algorithm, I don't see a problem here.
If you get real MX records and they point to domains that have A and/or
AAAA records you should assume that all of those records are valid.
It's only the "implicit MX" record that causes a problem.
(ii) It would be mildly insane operationally (or at least
stupidly careless) for someone to configure the DNS records for
an IPv6-only host without MX records that specify IPv4 access to
that host.
In the near term, yes. Though perhaps this might be reasonable by the
time RFC 2822bis gets revised again...
Keith