For those of you that have the same problem I had - a large increase in spam, where each email has a very low number of spamassasin rule matches (and the few matches are mostly benign), the topic is not consistent, and the source domain name is not consistent (and so spamassassin score tuning and blacklisting are useless).
Depending on your particular situation, I may have a solution...
If you've analyzed the headers of the spam that gets through, you *may* notice that much of it is coming not from just one specific IP address, but from a *range* of similar addresses.
If you know how to do the lookup (using tools like whois, etc), you may also find that those ranges in aggregate are from a specific CIDR block, set of CIDR blocks and possibly even all under a single ASN.
In my particular case, almost all the spam was coming from 1 specific ASN ( AS21788 - Network Operations, Inc. ), which has a reputation as a hosting provider for spammers. I've also noticed another spam-happy ASN, but most of their spam is already getting caught by spamassassin.
I don't advise jumping to any conclusions about which ASNs are mostly spam sources, since we're talking about hosting providers which may innocently be in a pyramid of reselling hosting providers, and unknowing about the spammers in their midst. In my case, I did the research and it appears to be a valid conclusion... the ASN in question ( AS21788 ) has historically been friendly to (or are themselves) spammers.
In any case...
It's helpful to be armed with information about the spam source's larger network before deciding what and how to filter, and if there's a broader spam source at work.
It would be great if Sonic already provided this in their email processing and spam filtering tools,
but they don't so...
I've got working procmail recipe that will add X-* headers to all incoming mail (i.e. using .procmailrc-first) containing info useful for identifying the sender beyond the simple domain name and IP address:
X-SENDERIP
X-CIDR
X-NetHandle
X-NetName
X-ASN
Once these headers are inserted into all your incoming email, you can start to easily ID and eventually filter out (using a separate .procmailrc recipe for typical filtering actions) spam by a larger range of IP addresses if warranted.
If anyone is interested, speak up and I'll post the procmail recipe(s).
Depending on your particular situation, I may have a solution...
If you've analyzed the headers of the spam that gets through, you *may* notice that much of it is coming not from just one specific IP address, but from a *range* of similar addresses.
If you know how to do the lookup (using tools like whois, etc), you may also find that those ranges in aggregate are from a specific CIDR block, set of CIDR blocks and possibly even all under a single ASN.
In my particular case, almost all the spam was coming from 1 specific ASN ( AS21788 - Network Operations, Inc. ), which has a reputation as a hosting provider for spammers. I've also noticed another spam-happy ASN, but most of their spam is already getting caught by spamassassin.
I don't advise jumping to any conclusions about which ASNs are mostly spam sources, since we're talking about hosting providers which may innocently be in a pyramid of reselling hosting providers, and unknowing about the spammers in their midst. In my case, I did the research and it appears to be a valid conclusion... the ASN in question ( AS21788 ) has historically been friendly to (or are themselves) spammers.
In any case...
It's helpful to be armed with information about the spam source's larger network before deciding what and how to filter, and if there's a broader spam source at work.
It would be great if Sonic already provided this in their email processing and spam filtering tools,
but they don't so...
I've got working procmail recipe that will add X-* headers to all incoming mail (i.e. using .procmailrc-first) containing info useful for identifying the sender beyond the simple domain name and IP address:
X-SENDERIP
X-CIDR
X-NetHandle
X-NetName
X-ASN
Once these headers are inserted into all your incoming email, you can start to easily ID and eventually filter out (using a separate .procmailrc recipe for typical filtering actions) spam by a larger range of IP addresses if warranted.
If anyone is interested, speak up and I'll post the procmail recipe(s).
