I think it is time to put an end to specious arguments. These standards get used for decades. I don't think it's appropriate to cripple them because of some arrangement that happens to exist now from a few dysfunctional DNS providers. Providers will get more flexible as the need becomes apparent, and domain owners who have problems with their DNS providers can change providers. It's not difficult.
And as has been said many times, we don't have a backward compatibility problem here, because as a practical matter any domain is going to have to provide an IPv4 path for inbound mail until IPv6 is ubiquitous. The existing model is based on the assumption that most computers on the network are large general purpose timesharing machines that support significant user communities that wish to receive email on those computers. That assumption has been incorrect for at least the past 10 years, and it's getting more and more incorrect all the time. Keith Dave Crocker wrote: > > Ned Freed wrote: >>> Indeed, if you asked >>> a random sampling of those groups --remembering that there are a >>> huge number of SMTP servers in the world, only a tiny fraction >>> of which are professional operations and with an even smaller >>> fraction being large-scale, carefully-managed production ones, >>> you might discover that many of them had forgotten that there >>> was such a thing as an MX record and how to set it up. >> And even if they know MX records exist they may not be able to use them. Some >> DNS provisioning arrangements allow users to set up MX records but there are >> others that do not. > > > This observation moves the proposed AAAA-only mode into one of high risk. > Rather than the benefit of reducing complexity, it becomes the danger of > threatening interoperability. > > Let's note that the proposal is a change from a model that has worked solidly > for 20 years and has not been a source of problems. While the proposal is > for a > mode that is appealing, it is not necessary. > > Methinks it is therefore time to respectfully retire the proposal. > > d/ > _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf