SORBS on autopilot?

Tue Jan 12 21:09:27 UTC 2010

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