Re: Last Call: draft-klensin-rfc2821bis

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