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:
Keith Moore <moore(_at_)network-heretics(_dot_)com> wrote:
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.
This was indeed needed, back when RFC821 was written.
It's not clear what else may have been needed then, but arguably
that would have been sufficient -- then.
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
}
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.
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.
I agree with Keith here, and would implement it that way. There's
nothing in 821 or 2821 to stop me...
In an IPv4+IPv6 world this becomes even a bit more important.
Let's see if Keith can make this case...
John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:
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.
... be patient...
(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...
True, but surely there's more to Keith's case than that!
Keith
Or is there?
--
John Leslie <john(_at_)jlc(_dot_)net>