On Sun, 1 Jun 2025, John Curran wrote:
Thanks, John – while cast in DNS-based lists, the RFC definitely includes quite a bit of best practice about blocklist management in general.
You make an excellent point about the difficulty of running a useful blocklist; unlike some other areas of Internet infrastructure (e.g., routing with routing table entries, route objects, etc. as visible artifacts), it’s nowhere near as evident whether a blocklist is behaving appropriately – the list and/or individual entries may be visible, but the information feeds that drive such listings are far more opaque.
It's a problem we've been thinking about for literal decades. The bad guys can read anything that's public, and I can assure you that if there were a spec that said we'll block anything that's more than 5% bad traffic, they'd figure out how to send 4.9999% bad traffic and then bulk up the denominator with traffic that is useless but doesn't provoke complaints. So the rules have to be opaque. There are hundreds of blocklists, viz. the list at multirbl.valli.org but in practice there's only a handful that are widely used. Spamhaus is clearly the leader, then perhaps Trend Micro which is the descendent of Vixie's MAPS RBL. Spamhaus' lists are mostly intended for mail and similar messaging but they do have DROP, Don't Route Or Peer, which is a list of networks from which they suggest you accept no traffic at all. DROP is very conservatively managed, never had reason to think it blocked traffic I want. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly