Mar 3, 2011

How Blocklist Operators Think

Some interesting stuff from Ken Magill.

If you’re interested in anti-spam topics, and you enjoy reading long technical documents composed in the courier font inside very tight margins (like I do), be sure to read this article about a best practices document that some blocklist operators have been working on since 2004:

"In any case, for those who choose to slog through it, BCP 07 offers insight into the way the major blacklist operators think"

I don’t handle our abuse or deliverability stuff anymore at MailChimp (much smarter people have taken over) but I remember the early days, when the behavior of just one MailChimp user would get our entire IP range blocked somewhere, and we’d have to jump into public forums and beg forgiveness (then endure all the ridicule) before getting delisted. It’s matured so much since then.

I also remember dealing with blocklists that banned MailChimp, but they were mysteriously also blocking the entire Internet too. So I found this interesting:

"A number of DNSBLs have shut down operations in such a way as to list the entire Internet, sometimes without warning.  These were usually done this way to force DNSBL users (mail administrators) to adjust their DNSBL client configurations to omit the now inoperative DNSBL and to shed the DNS query load from the registered domain name servers for the DNSBL. "

There are also guidelines in the document for DNSBL users, which make my imagination run wild about what incidents prompted the need for them.

This one, for example:

The DNSBL user MUST ensure that they understand the intended use of the DNSBL.  For example, some IP address-based DNSBLs are appropriate only for assessment of the peer IP address of the machine connecting to the DNSBL user’s mail server, and not other IP addresses appearing in an email (such as header Received lines or web links), or IRCconnections etc.  While a DNSBL user may choose to ignore the intent of the DNSBL, they SHOULD implement any variance in compliance with the DNSBL usage instructions.

For example, one of the requirements of some DNSBLs is that if the DNSBL is used contrary to the usage instructions, then the DNSBL user should not identify the DNSBL being used.  Furthermore, it is the DNSBL user’s responsibility to mitigate the effect of the listing locally.

and this one:
Any system manager that uses DNSBLs is entrusting part of his or her server management to the parties that run the lists.  A DNSBL manager that decided to list 0/0 (which has actually happened) could cause every server that uses the DNSBL to reject all mail.
I loved the "which has actually happened" part.