ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: DNSBL BCP v.2.0

2007-02-15 12:20:42
Hello all,

I'm new to the list. A lot of familiar names here. If you don't know
me, I've created a few different DNSBLs, mostly back they were
lovingly crafted out of shell scripts using stone knives and
bearskins. Lately I've started cataloging dead DNSBLs and writing up
DNSBL reviews on www.dnsbl.com, a site of mine.

Forgive me if I'm rehashing something already talked about; didn't
seem that way to me from my cursory research.

One thing that strikes me as missing from the BCP is some guidance on
usage and implementation in spam filtering and blocking applications.
In particular, technical guidance regarding whether or not a DNSBL
actually exists and can be queried. As I am learning from diving back
in to the thick of DNSBL-related things lately, I see
- Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
years after the RBL moved away from that FQDN.
- Other lists randomly vanishing with no warning and continuing to get
DNSBL traffic for years
- Blars, for example, vanished in December and now lists the world.
- LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
hits years later, resorting to listing the world.
- The occasional ignorant sod who queries something like
random.dnsbl.maps.com which causes unwanted traffic (and potential
unwanted mail blocking) from various sites. (You'll note that maps.com
has a wildcard, for example.)

Maybe this is outside of the scope, and if so, I apologize. But if
appropriate, it seems wise to have some guidance included about how to
avoid these situations, preferably recommended that checks be
implemented in software to confirm that a list an application is
checking actually exists and really is a DNSBL. It not only protects
ignorant DNSBL users from themselves (which I grant some folks
probably don't care much about), but it helps reduce pain for anyone
who gracefully shuts down a DNSBL (and their upstream, and the root
zones, depending on how it's done).

In the future, I'd love to be able to point to something RFC-like that
says what best practice is in this area, and be able to point that out
to companies who try to build a marketing strategy around selling
fancy rackmount anti-spam devices that are actually just linux boxes
with SpamAssassin and DNSBL support on them.

Would love to hear your thoughts and feedback.

Regards,
Al Iverson
--
Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>