marka> Or we could stop debating whether we should maintain it and marka> assume that if we give people tools that will allow it to be marka> automatically maintained they will eventually deploy them. [...] marka> Document what a node should do to register itself in the reverse marka> tree and to cleanup when its address changes. Write some code to marka> do it.
To put things another way, I think you're trying to optimize for a problem most folks don't want solved. Anti-spam folks *like* it that it's not trivial to get "correct" rDNS/PTRs. It's easy to find consumer connections based on the ISP doing bulk/lazy PTR generation and just reject SMTP traffic from them. Large ISPs don't care about clean PTRs as long as no customers complain and they don't care if end customers can't do SMTP without having to ask for it in some special way. They do care about and probably don't want complicated automated systems with all sorts of complicated behavior when autogen'ed PTRs solve most customer problems. While I as an individual may find it annoying to have to go to a web page to get a port 25 block removed and I may have to find someone better connected than me to get my email to "real" folks like google, I'm not most of the internet. Not even a teeny weeny fraction of it. And while I admit that I tend to disable auto-update on most of my devices and do updates by hand, at $DAYJOB, it's a feature when we can push new versions out to fix things and not wait for consumer gear to spout smoke and get replaced in 3-5 years. So for a large chunk of the providers out there, the recommendations in this draft solve a real problem in a mostly non-painful way and I think it's done a decent job of laying out the tradeoffs. There have been some comments about making it clear that providers that do bulk $GENERATE equivs in IPv6 will find that those addrs won't be able to send email. Seems like a fine thing to point out. What else in the way of tradeoffs is missing? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
