Spam/virus stats for September 2004
I hereby declare my experiment a success.
- The ratio of good/bad email here in September changed from the August low point of 33% good vs. 67% blocked/filtered to 45% good vs. 55% blocked/filtered.
- The improvement is entirely due to one action - that of not listening on the high preference number MX, though that high preference MX is obviously still advertised in DNS.
The lesson is clear. A very good spam avoidance tactic that will cause no false positives or inconvenience for real users is one of:
- Stop listening on port 25 of your high preference number mail exchanger, or
- Add a new highest preference number mail exchanger in your domain's DNS and do not listen on port 25 of that.
Read that earlier story here to find out why this is.
Some additional commentary
The above graph shows absolute volume. Here is the same graph normalised to 100%.
How individual MXes fared
First the preferred (lowest preference number) MX.
Note that the overall volume of email and the ratios of the different categories are similar to July (spam is slightly increased but good email is the same). Good email volume was slightly down in August due to holidays.
Now the non-preferred MX (highest preference number):
This MX was switched off on 6 September, so what you see (which is almost all DNSBL rejections) occurred between 1 September and 6 September. The resulting decrease in overall DNSBL activity is clearly visible in this chart:
There are big drops in the number of hits on DSBL, SORBS and our local list in particular.
Categories exploded
Whitelists:
DNSBL:
Policy:
- Non-existent sender domain
- Bogus HELO/EHLO
- No such user
- Rejected sender or recipient
- Third party relay
Content violations:
- Reported spam
- Trapped spam
- Viruses (including virus bounces and bogus warnings)
Category: Spam Statistics
Technorati: Spam Statistics
1. Eric Parsons01/10/2004 17:10:03
Homepage: http://www.startingblockcomputing.com
Do you see any issue with putting in a bogus record? That is, a high MX where there is no server at all?
For all that matters, what about using a 10-net address? Would senders (potentially) attempt to send mail inside, causing rouing loops, etc.?
2. Chris Linfoot02/10/2004 10:12:10
MX points to the FQHN of the mail exchanger so that FQHN should resolve (have a PTR). You could resolve it to an IP allocated to you that you use for something else and which is not listening on port 25.
I don't think you can publish PTR for an RFC1918 address.
3. Miles Rochford06/10/2004 01:20:21
It would be interesting to try setting the high preference MX to use a different domain to the low preference MX. This would make it look a lot more like an ISP backup mail server, and may act as a slightly stickier honeypot. :)
- Miles.
4. Chris Linfoot06/10/2004 08:21:12
Nice idea. Not sure how you would measure its effect though.
Unable to post a comment? Please read this for a possible explanation...
-