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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
