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@xxxxxxx > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf