Re: Registration model, 2821bis-06

On Wed, 2 Apr 2008, John C Klensin wrote:

> --On Wednesday, April 02, 2008 11:01 AM -0700
> ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>
> > > Connectivity to/from AAAA-only mail servers will suck
> > > terribly for many decades to come, but no 2821bis
> > > wordsmithing can avoid that. Only an arrangement with a
> > > dual-stack relay can improve connectivity, and that
> > > practically requires an MX RR or more.
> > This is certainly true for the Internet email service. But not
> > all use of
> > standardized email protocols (including usage on the open
> > Internet) is in
> > futherance of this service. It is entirely possible that at
> > some point
> > an alternate service offering will emerge that's IPv6-only. I
> > have no idea
> > how likely this is but it is not beyond the realm of
> > possibility.
> And, in addition and FWIW, the claim that a dual stack setup
> "practically requires" an MX setup is false, as has been pointed
> out before.   The following setup, with no MX record, is all
> that is necessary under the current 2821 standard:
>
>    destination.example.com. IN A ...
>                             IN AAAA ....
The only reference in the current 2821 standard about IPv6 is for address
literals. I cannot find a reference to an AAAA RR. Therefore I assume the
above statement is wrong. 2821 only defines the semantics for IPv4,
semantics about IPv6 are undefined. This is a subtle distinction, but
nevertheless it is one. 2821bis just begins to define semantics for IPv6
(beside the address literal).

At the moment, when an AAAA RR appears, the problem is resolved by "common
sense", what mostly mean do the same thing as if it would be an A RR. This
is a reasonable thing to do, if there are no explicit statements in the
standard.

However, if you extend a standard, you have to carefully balance the pros
and cons of the existing semantics when you try to carry them over.

At the moment I see two positions:

- use AAAA RRs in synthesizing MX RRs
- do not use AAAA RRs in synthesizing MX RRs

Reasoning about first position:
- it carries over the semantics of IPv4
- it will maximize email connectivity

Reasoning about second position:
- it will reduce server load and ressources, because emails with
  * "recipient-AAAA-domains" without an MX RR will be immediately
    rejected
  * "originator-AAAA-domains" without an MX RR will not be accepted

In the end this means: has the majority of email servers to pay for
the connectivity of a minority of email servers?

Is there any other reason I forgot? Otherwise we could just try to find
consensus which position we prefer.

Michael Storz