ietf-smtp
[Top] [All Lists]

Re: What is the history of 2821 and implict MX?

2008-04-07 14:15:22



--On Monday, 07 April, 2008 11:39 -0700 Pete Resnick
<presnick(_at_)qualcomm(_dot_)com> wrote:


On 4/7/08 at 9:54 AM -0700, Dave Crocker wrote:

John C Klensin wrote:

Someone would need to check with Craig Partridge...

A side discussion about history might be interesting, but
I'll  suggest that it should not really be a factor for the
current  discussion.

So, I want to disagree with Dave and wish to consider some
history, though Dave may have only been referring to the
history leading up to 974. I think the history leading up to
2821 might be important:

1. 974 did *not* have an "A fallback" rule at all. 974 is
quite clear that the rule is, "If you can't find an MX, you
should treat that as if you *did* find an MX where the
preference was 0 and the name in the response was identical to
the name queried. (That is, if you get back no MXs for
a.example.org, then it should be equivalent to getting back a
single MX of "a.example.org IN MX 0 a.example.org".) If this
rule were in effect today, you *would* connect to a mail
host's IPv6 address even if it had no MX records.

Since this, and the statement in 974, has already confused at
least one person, let me repeat what Pete says above before
commenting.  The rule in 974 is that a mail client makes a query
for an MX record.  If it doesn't find it, it synthesizes one and
pretends.  That synthesis is _not_ dependent on finding an A RR
or anything else.   If, having found or invented the MX, its
data field contains a name that doesn't resolve to anything
useful, the failure occurs at that point, not in generating the
MX (or not).

It is perhaps also worth noting in this context that RFC 1123
talks exclusively about "address records" and not about "A
records" in the context of MX.    It does not discuss what we
are now calling the implicit MX rule at all.

2. 2821 changed the rule and made explicit claims about
looking for fallback A records. The question is, was that
intentional? Did DRUMS intend to change the 974 rule in this
regard, or was it trying to explain what the 974 rule entailed
by using examples? So far, I can find nothing in the DRUMS
archive to support the position that 2821 intentionally
changed the 974 rules.

I can find nothing in my personal notes either, which suggests
that the explanation in 2821 --which did attempt to merge the
974 and 1123 rules and explain them in less space-- was chosen
because it seemed more clear.  Note that 2821 could have picked
three options, all consistent with the understanding of 974 at
the time:

        (i) Reproduce exactly the operation of 974, i.e., if a
        lookup with Type=MX fails, generate an implicit MX
        regardless of the presence or absence of any other
        records.  Note that, if taken literally, this requires a
        second lookup if the Type=MX fails, even if the failure
        is NXDOMAIN.
        
        (ii) Use the model of 2821, which requires synthesis of
        an MX only if an A RR is found.
        
        (iii)  Use the model of 2821, but using the "address
        record" language of 1123.  That, of course, produces
        exactly what is in the 2821bis-09 draft.

I believe, that I shifted away from (i) at the behest of one of
the folks on the DNS side of the issue to make sure that the
second lookup was not required if there were no DNS records at
all for the name first looked up.   While I can't prove that
from my notes, I do have a note (quite cryptic in retrospect)
about a DNS issue that reinforces my vague memory.  I imagine
that the choice of "A RR" over "address record" was chosen with
almost no thought and no on-list discussion.

If 2821 had preserved the 974 MX rule, we would not be having
this discussion at all. The rule would be clear that the lack
of the MX got you an implicit MX, and then you'd look up A and
AAAA records as normal.

And a review of 1123 just now makes it clear to me that, if a
name had exactly two RRs, one A and the other AAAA, with an MX
pointing to it (implicit or explicit), an argument that one
should look at one of those records and not the other is
untenable except as a significant change to established
standards.

This entire argument reduces (for me) to answering this
question: Did 2821 intend to preserve the 974 rule? If DRUMS
did *not* intend to change the 974 rule, then 2821's current
text is an errant interpretation of 974 and should be fixed
back to the 974 rule. If DRUMS *did* intend to change the rule
to make it clear that 974 was all about
backwards-compatibility for hosts that didn't have MX records,
then there is a reasonable argument to be made for not doing
so for AAAA.

I can find no record of a DRUMS decision to change the 974 rule.
If there was any explicit decision at all, it was made just to
clarify that the second DNS lookup was not required if there was
no address information present.   I assume that the lack of any
mention in my note of the choice between "A RR" and "address
record" terminology in 2821 means that the decision was made
with no thought of discussion.  Blame the stupid editor for
getting it wrong.

My current feeling is that 2821bis should clarify that it
intended the 974 rule. Yes, that gets us implicit MXs that
point to AAAA hosts. Such is life.

Reserving further comment at this time.    But that
clarification can occur either as option (i) or option (iii)
above, possibly plus some explanatory text.   Or one could do
option (i) and put in a sentence or two indicating that the
second lookup can be omitted if the SMTP client knows that there
are no address records present.

     john