[Top] [All Lists]

Re: Registration model, 2821bis-06

2008-04-03 10:14:43

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
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: 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

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
  * "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.


Hector Santos, CTO

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