Lately, a lot more spam/scam emails seem to be getting through the Spamassassin installation on my mail server. Which finally made me go “eurhm… how long has it been since I upgraded that thing?” And, d’oh! It’s been a few years.
I mean, it’s automatically upgraded with security fixes, but it was on Debian oldoldstable, so that’s pretty old. Last week I got my act together and upgraded it to the current Debian stable, and after poking at it for a few days, I got the other stuff that was running on it working.
But back to spam: I was shocked to find that I’m getting almost no spam now, so I started worrying that it was rejecting legitimate mail… but looking at the logs, I don’t see anything suspicious, and I’m getting everything I’m usually getting. But virtually no spam.
Previously, about ten spam/scam messages per day were getting through, and in the week since I updated, it’s about one. That’s, like, fantastic. So I wondered whether there was anything interesting to see statistically in the logs, and I got the chart above. Which looks dramatic — it’s like they’ve almost stopped spamming me!
I have my MTA reject spam on delivery, so that could theoretically be an effect: Addresses that reject spam could theoretically lead to spammers removing those addresses from their lists, but I’ve always thought that sounded unlikely. Sending spam costs nothing, so why bother to keep lists updated? And besides, while I’ve seen a 90% reduction of spam that gets through, that’s just 9 messages extra, so it’s insignificant.
And the period is really too short to draw any conclusions. I mean, I’m no scientist.
So I remembered that I have a backup server that keeps all old versions of old files, even mainlog.gz, so looking back two years:
There’s basically no major change, and the data is really noisy on a day-to-day basis. (Well, there’s a development in the amount of ham I’m getting, but that’s because I withdrew from Emacs co-maintainership late 2022.)
If you squint, you can kinda make the argument that spams are declining a bit, I guess.
So I guess… I didn’t find out anything of interest here other than that an updated Spamassassin is nice? It works?
Sorry for making you read this!
But while I’m typing away, I might as well bitch a bit about something!
I noticed that there’s a number of RBL tests based on the Validity provider, and they all “pass”. So there’s this in the logs:
-2.5 RCVD_IN_VALIDITY_CERTIFIED RBL: Sender in Validity Certification -
Contact certification@validity.com
[Excessive Number of Queries | ] These RBLs commonly have rate limiting, and that rate limiting is based on the IP address of the DNS resolver. The usual solution to this is to run a resolving name server locally — but I already do that, and still it’s rate limited:
host 242.101.89.167.bl.score.senderscore.com 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: 242.101.89.167.bl.score.senderscore.com has address 127.255.255.255
And that means “pass, but because of rate limiting”. And:
For other DNSBLs, SpamAssassin does have rules in place to ignore such checks when this happens, but since this is likely new, it’s not accounted for yet.
I even created an account on Validity and whitelisted my IP address, and it still fails, so eh, I just disabled the tests.
The exiting world of running your own MTA…