2005-06-27
Some quick CBL stats
Last night I shuffled our antispam rules to put checking the CBL before everything, including our per-IP-address greylisting.
Since 3:20am this morning, 83% of the connect-time SMTP rejections were due to the CBL, for 88% of the IP addresses (4,180 out of 5,000 rejections from 3,038 different IP addresses out of 3,455).
So the simple recommendation seems to be: if you can only deploy one DNS blocklist, use the CBL. (Better yet, use the XBL, since that includes the CBL as well as a few others.)
It's also a depressing testament to just how much of our SMTP load is from compromised zombie machines. Over roughly the same time period, we had successful SMTP connections from only 271 different IP addresses, which means that around 82% of the IP addresses that tried to talk to us were zombies. (And probably still are zombies.)
Some of the zombies were pretty persistent about it; the top honors goes to 213.176.122.12, with 22 connection attempts refused.
2005-06-26
Some spam stats at June 25th, 2005
Another Saturday, another set of spam statistics. This week I stopped putting in IP-level blocks for high-rate connection sources so that I could gather more accurate statistics on the various DNS blocklists that we use here.
Most of the statistics are from about 3:20 am Sunday the 19th, when logs rolled over; some are from about 6:10 am that Sunday, when the system rebooted. (Note that many figures are somewhat rounded off.)
The basic statistics are stark:
- 132,000 SMTP connection attempts since 6am Sunday, from 42,000 different IP addresses.
- 43,771 connections rejected immediately since 3:20 am Sunday, from
13,256 IP addresses.
- 50% rejected because they looked too much like dynamically assigned addresses. (22,179 connections from 6,965 IP addresses)
- 29.5% rejected because they failed our requirements for good reverse DNS. (12,955 connections from 4,485 IP addresses)
- 15% rejected because of a DNSbl listing. (6,783 connections from 1,721 IP addresses)
- 33,000 SMTP sessions that were allowed to talk
to our actual mailer, from 1,600 IP addresses.
(That's only 25% of the connections, from 3.8% of the IP addresses.) - 6,200 unresolvable HELO names, from 148 IP addresses.
- 1,800 attempts to send mail to nonexistent local users.
- 14,000 email messages delivered, from only 220 different IP addresses.
That's right: less than one percent of all IP addresses that connected to our SMTP port sent us any mail. Even if you count only mailers that got through IP-based greylisting and other filtering, only 13.75% actually successfully sent mail.
We do per-IP-address greylisting, so it's probably the cause of the 27,000 IP addresses gap between how many total different IP addresses connected and how many IP addresses were either rejected immediately or went on to connect to our real mailer. Such IP addresses are almost certainly compromised 'zombie' machines.
Rejection count by DNS blocklist:
| DNSBl | Count | IPs |
| CBL | 3508 | 1319 |
| Spews | 1039 | 47 |
| SBL | 935 | 94 |
| list.dsbl.org | 464 | 83 |
| dnsbl.njabl.org | 362 | 8 |
| dul.dnsbl.sorbs.net | 254 | 138 |
| relays.ordb.org | 154 | 10 |
| opm.blitzed.org | 67 | 45 |
The people blocked by njabl and Spews are clearly the most persistent.
Almost all of the njabl rejections were of smtpout.terra.es, which along
with most of the persistent Spews sources figured in
our firewall rejects last week.
(Fortunately, not all of last week's top 20 put in return engagements.)
Our specific filtering of a lot of dynamic addresses before we check DNSbls means that the CBL and the Sorbs DUL are somewhat under-counted, since dynamic addresses are big contributors to the CBL and the only thing that's supposed to be in the DUL.
(Updated: We check DNSbls in the following order, stopping at the first match: SBL, CBL, relays.ordb.org, opm.blitzed.org, list.dsbl.org, Spews, Sorbs DUL, and then dnsbl.njabl.org.)
More stats:
2005-06-24
An open letter to free webmail providers
Dear free webmail providers: I have a simple request for you that will help the spam problem. Please stop allowing people to send out mail through your systems from IP addresses that are well known as heavy spam sources, especially of things such as advance fee fraud.
I got yet another '419' advance fee fraud spam today, sent through a free webmail provider. Selected headers are:
Received: from dbmail-mx1.orcon.net.nz ([219.88.242.3]) [...] Received: from webmail.orcon.net.nz ([172.16.100.200]) by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) [...] [...] From: Ed Bahir <edbahir@orcon.net.nz> Subject: Your Kind Attention Required Please! X-DBMAIL-Originating-IP: 81.199.85.121
The IP address 81.199.85.121 is in the CBL, in the SBL, in SORBS, in Spews, in the AHBL, indeed it's somewhat hard to find a DNSbl that it's not in. One its two SBL listings is from January 2004, more than a year old by now.
Yet orcon.net.nz didn't bother to do anything, and blithely let this spammers send his email out. As a result, I (and likely a bunch of other people) got spammed. Also as a result, orcon.net.nz will not be able to send us any email any time soon.
Orcon.net.nz is far from alone in behaving with such little regard for other people. Major webmail providers also blithely allow CBL and SBL listed IP addresses to send out email through them, to the extent that I've made our antispam system do the checks for them. (Amazingly, all of it is advance fee fraud spam. Who would have thought?)
It's really past time that this stopped. That it doesn't stop makes me feel rather angry, and also feel that free webmail providers don't actually give much of a rat's ass about spam (whatever their public statements).
Dear free webmail software authors:
A lot of people just installed your webmail software without thinking about it. Maybe they haven't gotten '419' spam from free webmail providers themselves and can be excused for not thinking about it, but frankly I can't imagine that you have that excuse.
So please make your webmail software default to refusing to send out mail from IP addresses on the CBL and the SBL at least. You can do it with one DNS query to the XBL, so it's real easy. You can make it only a default, so someone who wants to can turn it off. But that way, at least your software would put some obstacles in the way of '419' spammers by default.
2005-06-18
SMTP IP firewall stats at June 18th, 2005
We maintain a filter list of bad hosts and network areas that can't talk to our SMTP port at all; their SMTP packets are silently discarded. The filter list is reinitialized each time the server reboots, currently once a week. During the week we add various spam sources and high volume sources of other rejections to the filters on a dynamic basis.
As the server does its weekly reboot at 6 AM Sunday morning, right now is a great time to pull a top-N summary from the kernel's firewall statistics. So, here are the top 20 sources of rejected packets to this server over the past nearly 7 days:
Host/Mask Packets Bytes 213.4.129.48 7768 356K [a] [njabl] 192.35.251.3 4539 218K [a] [bad-helo] 61.128.0.0/10 4356 215K 216.7.201.43 4169 200K [a] [bad-helo] 220.160.0.0/11 3313 161K 195.46.148.28 2955 177K [a] [baddns] 65.194.220.21 2696 129K [a] [cbl] 24.156.64.52 2683 129K [a] [dialup] [cbl] 218.0.0.0/11 2577 126K 213.29.7.174 2492 150K [a] [njabl] 219.128.0.0/12 2435 123K 65.214.61.100 2425 116K 66.18.69.6 2359 142K [a] [spews] 24.222.77.233 2088 125K [a] [flushot] 62.219.46.43 1949 93552 [a] [dialup] [cbl] 193.70.192.0/24 1893 85360 212.47.15.29 1824 109K [a] [flushot] 12.31.56.73 1719 82512 [a] [bad-helo] 212.216.176.0/24 1654 86576 221.216.0.0/13 1584 78068
The key:
[a]: entry was added during the week as a high-count rejection source.[baddns]: IP lacks a good PTR record.[bad-helo]: tried to say hi with a bad SMTPHELOname.[cbl]: IP incbl.abuseat.org.[dialup]: IP seems to be in a dynamic/dialup address range.[flushot]: IP address sent email to our spamtraps.[njabl]: IP indnsbl.njabl.org.[spews]: IP in the SPEWS DNSbl.
This isn't a particularly active server for mail in general; we usually get about 1,000 to 2,000 incoming real mail messages a day (mostly from mailing lists).
I believe that 213.4.129.48 (smtpout.terra.es), 213.29.7.174 (mail1002.centrum.cz), and 66.18.69.6 (mailout06.infosat.net) are all involved in providing free email. And apparently doing a bad job of stopping spammers from using it. Both 213.29.7.174 and 66.18.69.6 would have been rejected by later blocks as well, blocks we set up due to them sending us spam.
Due to a long-term spam problem, we have a number of Chinese netblocks that we aren't interested in accepting email from. In this listing, that's 61.128.0.0/10, 220.160.0.0/11, 218.0.0.0/11, 219.128.0.0/12, and 221.216.0.0/13.
212.216.176.0/24 is tin.it, an Italian ISP that had yet to get
HELO greetings correct by the time I gave up and firewalled them.
193.70.192.0/24 is liberato.it, another Italian ISP with a
significant spam problem that we've just stopped talking to. (On a
quick spot check it seems to also be iol.it; they may have merged,
been bought out, or renamed since I put them in our filter list.)
65.214.61.100 kept trying to send us email from the blocked origin address of 'info@salesrecruits.imakenews.net', week after week after week. At some point I just put them in our core filter list instead of adding them every week. I don't consider their continued attempts to send us email despite everything bouncing for months to be a good sign.
Note: because we drop incoming packets from these IP addresses on the floor and don't reply to them in any way, this is not an accurate count of even SMTP connection attempts. (One SMTP connection attempt will produce a number of packets to our SMTP port, depending on how much their OS retries TCP connection attempts.)
Disclaimer
By the time you read this, some of these IP addresses may no longer be in the DNSbls listed. Because this is IP level firewalling, we can't say anything definite about whether what these places are trying to send us is spam; we've just decided that we don't want to talk to them at all.
(Some of the SMTP connection attempts are probably for bounce
backscatter from spammers forging our domain as the MAIL FROM of
their spam runs.)