[Top] [All Lists]

Re: I-D Action:draft-klensin-rfc2821bis-10.txt

2008-04-17 13:01:10

   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

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
    else if status == permanent_failure
    else if status == temporary_failure

   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!


   Or is there?

John Leslie <john(_at_)jlc(_dot_)net>