BigTech email hosting companies AND many large ESPs - have 1/2 ruined email over the past several years - and have somewhat run a wrecking ball through many of the best DNSBLs *** (see note at the end) Why? Because why would a spammer want to setup their own domain name or their own server or their own IP space - when they can just send SO MUCH spam from either Google or Microsoft or a large ESP - and as long as it isn't clearly criminal spam - and as long as they're very good at list-washing the spam traps and loudest complainers - none of these large entities seem to care that much about stopping that outbound spam. And even if it is criminal - many of them STILL don't seem to do that much about this (e.g. criminal spear-phishing spammers being able to keep sending from their free-mail acct for many months or even years after first being reported - that happens OFTEN!). And so then, besides not using their own sending-IPs, why would the spammer use their own domain anymore in the clickable links if they can instead use an ESP's tracking domain for that? So not only does this reduce the effectiveness of DNSBLs, it also harms spam filtering since so much more spam is now sent from servers that also send much legit email - we've always had that - but just not nearly THIS much. (Meanwhile, for the "boutique" email hosting side of my business, about 30% of every email that comes from a Google email server is a spam, and that number is about 15% for Microsoft. And then there are those criminal phishing scam spams - as well as totally unsolicited spam emails - sent via large ESPs - that's also out of control too.) So forgive me if I'm "rolling my eyes" when yet another large BigTech company (Amazon) - in this case - thinks they're good at being their own DNSBL - but actually are NOT (at least, according to some on this thread) - and then other/better DNSBLs get blamed? Seriously? *** At invaluement - to deal with these changes - we've been developing new types of anti-spam data - that we've been working on over the past several years - which are now slowing being rolled out to existing customers - but not yet officially launched - all of that to counteract these changes in the email industry. But that required 10s of thousands of hours of "unbillable overhead" development time - half re-engineering our system - meanwhile these other large ESPs and hosters were "laughing their way to the bank" these past few years, in many of these situations, getting paid by the spammers themselves - but then ya' know - "anti-abuse" is such a pesky expense for them. So then that cost-shifts these entities' lack of outbound spam prevention - such that everyone else's inbound filtering pays the price for this (+ cost shifting to innocent victims for the spams that get through and either steal their time and/or scam them.) IOW - DNSBLs are NOT nearly the largest problem we have here! And it seems like the better DNSBLs - shouldn't be associated with whatever Amazon isn't doing well. Rob McEwen, invaluement ------ Original Message ------ From "John Curran via NANOG" <nanog@lists.nanog.org> To "John R. Levine" <johnl@iecc.com> Cc "North American Network Operators Group" <nanog@lists.nanog.org>; "John Curran" <jcurran@istaff.org> Date 6/1/2025 11:30:07 AM Subject Re: blocklists Amazon AWS cloudfront WAF block
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 kind of a shame, because our track record for Internet infrastructure would suggest that public visibility and transparency in an area tend to drive improvements in operational coordination – sometimes that’s the result of Internet researchers studying the data and making suggestions, other times it’s industry joint initiatives (e.g., MANRS), and worst case, it’s calling out the bad cases publicly; hard to do any of that given the murky nature of blocklist management…
/John
On Jun 1, 2025, at 9:41 AM, John R. Levine <johnl@iecc.com> wrote:
On Sun, 1 Jun 2025, John Curran wrote:
Out of curiosity, is there a reasonably clear document somewhere that describes how such network-level block lists should be operated from the view of network operators; i.e., a “best practice” statement ...
Sort of. See RFC 6471, Overview of Best Email DNS-Based List (DNSBL) Operational Practices.
Running a useful blocklist is very hard. Everyone who's listed insists that it's a mistake. Sometimes they have odd ideas of their responsibility ("we have no control over the customer, we just take their money and route their packets".) Sometimes they are sure they are special so the regular rules don't apply. Sometimes they are confused. Often they just lie. Occasionally, there really is a mistake but recoginizing it in the noise is not easy.
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
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/PM7BXG4K...