On Tue, Jan 12, 2010 at 10:48:31AM -0800, Brian Keefer wrote:
I wouldn't say that necessarily accurate. I could be considered part of the "anti-spam crowd", seeing as that's my line of work.
I think DULs are a really dumb way to block spam. Making a binary decision off of information that's wrong as often as it's right it's a great way to create collateral damage and just generally cause more headaches for everyone.
I've done a little bit of work in the anti-spam area as well (starting around 1983) and I can tell you that your viewpoint about DULs is roughly half a decade out of date. With the rise of 100M+ zombies, it has long since become a best practice to block outright anything that looks like, smells like, feels like it's not a real live mail server. (And many things that are.) One of the best ways to do that is to reject all mail from anything without a PTR, and a lot of things *with* PTRs matching certain well-known/well-understood patterns. Hence the work of various DULs, the EnemiesList project, and others. They have long since proven their marked superiority to other methods in terms of accuracy, resource cost, maintainability, scalability, resistance to countermeasures, and other applicable metrics. They're some of the very best tools we have, and anyone with even a little bit of clue is using them for all they're worth. Default-permit mail system policies which don't implement these are years behind best current practices. PTR allocation policies which pretend that this doesn't work or shouldn't work or won't work are years behind best current practices. As an aside, there is no such thing as "collateral damage" in this context, because there is no such thing as "damage". This point was discussed extensively on the IRTF-ASRG mailing list nearly two years ago in the discussion over Chris Lewis's RFC on DNSBL operational procedures, and I believe I presented a clinching set of arguments there as to why that's the case -- certainly enough to get that language removed from the draft. You might want to read that list's archives to see why that phrase has absolutely no place in any anti-spam discussion. I suggest that further discussion of this move to spam-l, where it's probably much more appropriate than NANOG. ---Rsk