ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue

2008-04-15 11:02:14

Tony, John,

I appreciate the hard work (and time) you guys put into this. I also support the "least surprise" principle and feel this is the best decision at this time related to this issue.

I can only hope someone can take the lead or be the point behind a new *consolidated* SMTP IPv6/4 technical spec effort.

Thanks

--
Sincerely

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


Tony Hansen wrote:

<shepherd hat on>

During the second last call for rfc2821bis, there has been much
discussion of how the "implicit MX" handling is to be handled in an
IPv6-capable and IPv6-only environment.

This has generated much heat, as well as numerous proposals that were
both productive and counter-productive, and that were both in scope and
out of scope.

I came at this question with an open mind, trying to weigh each of the
arguments being made both for and against different stances. My
measuring stick in each case against has been: How does this measure
against what is required to advance 2821bis to Draft Standard? What is
the current usage? What do the implementation reports have to say on
this issue?

The SMTP implementations that have made the transition to support IPv6
appear to already have done it in a way that supports AAAA records for
the implicit MX case. In some cases they are following RFC 3974, and
other cases they are just using getaddrinfo() and letting it do the
rest. Note that RFC 3974 itself was supposedly "based on experience in
deploying IPv6". At least one of these MTAs is in common use around the
network in the IPv4 world.

In essence, these implementations are following the RFC 821 and RFC 974
(sans WKS) rules of looking for address records. They've ignored the
A-only wording of RFC 2821 and are acting like we specify currently in
2821bis-09.

In my queries I haven't yet found any IPv6-capable SMTP server that
doesn't do it.

I've seen examples of sites that are in regular use that mail would
break in an IPv6-only world if implicit MX to AAAA did not work.

 From this viewpoint, running code wins.

I'm also swayed by the principle of "least surprise". Some of the
responses I've gotten have been along the lines of "Why's this a
question? Of course you do AAAA lookup". One person who had a site set
up with an IPv6-only connection and no MX record told me "I wanted to
forward my e-mail to an account on that machine. It worked the first
time, so I didn't see a need to change it." As mentioned above, at least
one of the IPv6-capable MTAs is in common use around the network in the
IPv4 world, and turning on IPv6 on those boxes should not cause surprises.

Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
archive search around the question of what led to the wording change in
2821bis saying explicitly to do A lookups. These indicate that the
intent of adding the A record description was to be descriptive, not
prescriptive nor proscriptive.

So the bottom line is that I see sufficient support for including AAAA
lookups when implicit MX comes into play.

It's been suggested that 2821bis revert back to either the implicit MX
description found in RFC 821 or RFC 974, although Glen Anderson had some
suggested improvements to that latter's description that do make it
clearer. Any of these three would satisfy this decision, and I'll let
John choose the wording he prefers.

</shepherd hat off>

    Tony Hansen
    tony(_at_)att(_dot_)com