[Top] [All Lists]

Implicit MXs - asking the question more clearly (was: Re: Scope Creep)

2008-04-05 00:51:44

I'm going to make another attempt at getting clearly focus on
the question here...

--On Wednesday, 02 April, 2008 12:38 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
John C Klensin wrote:
 > --On Wednesday, April 02, 2008 11:25 AM -0700 Lisa
Dusseault wrote:
 >> WWTHD (What Would Ted Hardie Do): be blunt.   "After much
 >> discussion on the topic, this specification does not extend
 >> the A rule to AAAA records, but neither does it preclude a
 >> parallel treatment."

That leaves an ambiguity about behavior from which neither
SMTP clients  nor domain administrators can figure out what
to do. To me, that  ambiguity is the one case that is a
showstopper. It also, IMO, creates a  "known technical
defect" and that would exclude even publishing  something as
Proposed, much less Draft.

I see no way to avoid making a choice.

I think I and several others have said this before, but I can
live with  anything that (i) does not create an ambiguity and
(ii) does not  deprecate the existing (back to 974) behavior.
I'm sorry to say that I see a way to deal with v6, without
dealing with it.

Unfortunately, I see Lisa's language as too specific as well
as too varied. "does not neither does it
precludes" is, I believe, semantically equivalent to saying
"is out of scope".  That's language that is more typical in
IETF specifications.

So I think the choice is between

1. The current draft language, which treats "direct" addresses
as a list and names two entries, A and AAAA, explicilty, versus

2. Language which cites A but declares all other details out
of scope, using language like:

     "In the absence of indirect addressing, via a DNS MX
record, this specification provides for use of direct
addressing via IPv4 DNS A records.  Use of other direct
addresses is out of scope."

FWIW, I vote for 1.  v6 is too real to ignore.

I also suspect a diligent IESG would enforce including it as a


While I agree with your vote for (1) -- somewhat more strongly
now than before reading and following the various threads in
this overheated and confused conversation --  I don't see (2) as
plausible.  If I'm going to configure DNS records for a host
that is IPv6-only, and that host might receive mail (or even
send it and receive bounce messages), I have to know whether, if
I simply put in an AAAA record, a mail client will find the
host.   There really are no "maybe" cases, whether stated as
MAY, as optional behavior,  or as outside the scope of the
standard, because, in practice, they are all equivalent to "no
implicit MX when AAAA is present without A; if you want mail and
want that to be predictable, the MX record MUST be there".

Although some variations in wording are possible, there is only
one way to say "one can reliably find and send mail to an
IPv6-only host without an explicit MX record" and that text is
in 2821bis-09 today.  All of the other statements amount to
"explicit MX required for IPv6-only hosts".

The sources of confusion in these discussions are issues that
may shed light on how the decision should be made about
IPv6-only hosts, but they are, themselves, out of scope for the
2821bis discussion, at least IMO.  Those discussions include the
question of whether it is time to deprecate implicit MXs
entirely, how to use the DNS to indicate that a host does not
want to receive mail, and what can be done in the absence of MX
records (and even DNS address records) if the sender has
preconfigured out of band information.

It is clear, at least to me, that none of the discussion applies
to dual-stack hosts that are shown in the DNS as dual-stack,
i.e., with both A and AAAA records associated with the same DNS
node.  If  there is no MX record at that node, the implicit MX
record will be generated because the A RR is there; the AAAA
record is irrelevant to its generation.  And if the MX record,
explicit or implicit, points to a node that has multiple address
records (A alone, AAAA alone, or mixed) the selection rules are
well-define elsewhere are well understood... even if they are
understood to permit more client choices and variations than
some people might like.


<Prev in Thread] Current Thread [Next in Thread>