Re: not delivering, and History of fallback to A

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