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" <[email protected]>
To "John R. Levine" <[email protected]>
Cc "North American Network Operators Group" <[email protected]>;
"John Curran" <[email protected]>
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 <[email protected]> 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, [email protected], 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/[email protected]/message/PM7BXG4K3GJJRFGEDT24WYZNFQ5M5Z4G/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/KHC6WZSCMWQJWSY3JSF7ZEPRAP7CDCIP/
