ietf-smtp
[Top] [All Lists]

Re: not delivering, and History of fallback to A

2008-03-31 20:18:20

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

So let me postulate a world in which IPv4 is
gone, A records are gone, and IPv6 reins over the planet, and we have
switched to requiring MX for any inbound mail hosts.

That's somewhat uninteresting to me because I don't think it will happen in any sort of time frame frame we're concerned with. What we might get to is a situation where it is feasible to run a server with only IPv6 and not IPv4. But even that isn't going to happen any time soon.

I remember that during the MIME discussions many of us thought that BITNET and affiliated NJE-based academic networks would be with us for a very long time. And indeed, BITNET kept growing for awhile, if slowly. Then when it died, it happened almost overnight. Similar observations could be made for uucp, and gopher.

Mail will be one of the last two global applications for which IPv4 is a practical necessity (http being the other). Once mail and http no longer need IPv4, neither will anything else that runs globally. When enterprise networks no longer need IPv4 and the hair-pulling that comes with it, they'll pull the plugs quite rapidly. ISPs will follow soon afterward.

Again, this is about 2821bis, not about getting anyone's, let alone everyone's,
favorite spam fighting mechanism onto the standards track. And I have yet to
hear a convincing explanation for how AAAA fallback changes the situation for
bad guys in any appreciable way.

I agree on that point, though I think the AAAA fallback fix is justified on other grounds. And to me this kind of fix seems very much in line with why we started the DRUMS effort in the first place, and why we made other changes between 821/822 and 2821/2822.

However, I am sympathetic to the argument that we can't keep revising 2821bis forever, and that we need to push it out the door even if we immediately start working on one or more fixes to 2821bis. Maybe we should just accept that the "core" email specifications will never be entirely current, even at the time they are published.

I'd certainly support publication of a short RFC that deprecated AAAA fallback.

Keith