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

[Hector Santos <[e-mail]>]

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
>     [e-mail]
> 
> 
> 




_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf