Re: Registration model, 2821bis-06

Michael Storz wrote:
> 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

Overall, we can't neglect the basic requirements for compatibility.

If anything will be added, I prefer text in 2821bis that will help 
prepare us for the future, possibly outlining the current issues, 
current methods, and more importantly what technologies or possible 
changes will be important or a consideration in a successful migration.
Information that will increase awareness.

Also, if the text is going to include terms such as "synthesize", this 
needs to be clearly defined as to what that means.  Who is doing the 
synthesis?   The DNA client?  The MTA?  The DNA Server?  A dual stack 
protocol logic?  I see this is a important design question because if a 
MTA is going to do a MX lookup, does the result include the synthesis of 
a fallback?  Of is the MTA still responsible to do the fallback itself?
Also, keep in mind the availability of new technology will act as 
helpers for the new generation receivers. Such as DKIM which will raise 
the bar (new non-legacy expectations) on senders.  IOW, new mail 
indicators will suggest senders *should* be up-to-par with expected DNS 
mail setup procedures.
--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com