Weekly spam summary on January 20th, 2007
Our SMTP frontend crashed a lot this week, so the connection volume number is a lot more approximated than usual. Having said that, this week we:
- got 14,060 messages from 292 different IP addresses.
- handled 21,260 sessions from 1,496 different IP addresses.
- received over 183,239 connections; I'm not going to try to guess at the minimum number of different IP addresses.
- probably hit a highwater of 6 connections being checked at once.
It seems likely that volume was around that of last week or maybe a bit lower, but it's very hard to tell.
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 188.8.131.52 21316 1101K 184.108.40.206/24 18080 1081K 220.127.116.11/24 12078 544K 18.104.22.168 4945 231K 22.214.171.124 4683 225K 126.96.36.199 4208 202K 188.8.131.52 4149 248K 184.108.40.206 4058 195K 220.127.116.11 3513 169K 18.104.22.168 3360 161K
- 22.214.171.124 returns from last week and many previous appearances.
- 126.96.36.199 was on the NJABL when we blocked it, but no longer is.
- 188.8.131.52 is a Pacbell DSL line in the SORBS DUL list.
- 184.108.40.206 and 220.127.116.11 kept trying bad
- 18.104.22.168 kept trying to send us stuff that had already tripped our spamtraps.
- 22.214.171.124 and 126.96.36.199 are both things that we consider dialups.
The overall volume is clearly up from last week, although only one IP address is one that's made the lists before. (And that one is terra.es's mail server, which we haven't wanted to talk to for ages.)
Connection time rejection stats:
48728 total 32588 dynamic IP 12796 bad or no reverse DNS 2058 class bl-cbl 206 class bl-sdul 143 class bl-dsbl 98 class bl-pbl 58 class bl-njabl 50 class bl-sbl
As you can see, we've added the Spamhaus PBL to our list of blocklists. It hasn't hit much because it comes after the CBL and our extensive hand-maintained list of dialups and other dynamic IPs.
Only one out of the top 30 most rejected IPs was rejected 100 times or
more this week; 188.8.131.52, a wanadoo.fr dialup, was rejected 422
times. 13 of the top 30 are currently in the CBL, and 5 are currently in
Half of our SBL rejections came from 184.108.40.206 (25 rejections, SBL50181), a compromised web server being abused to send advance fee fraud spam for some time. After that is 220.127.116.11 (7 rejections, SBL50211), labeled as an opt-out spammer, and 18.104.22.168 (4 rejections, SBL49046), more advance fee fraud spamming.
This week Hotmail brought us:
- no messages accepted.
- no messages rejected because they came from non-Hotmail email addresses.
- 30 messages sent to our spamtraps.
- no messages refused because their sender addresses had already hit our spamtraps.
- 2 messages refused due to their origin IP address (one from saix.net, one from Burkina Faso).
And the final numbers:
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
I can't say that this looks good compared to last week. There is
a clear winner of the bad
HELO sweepstakes; 22.214.171.124 tried 494
times. Fortunately, that's the only really active bad
and everyone else was down in what I consider acceptable territory
with only double-digit rejections.
Germany remained a major source of our bad rejections, sprinkled with
Italy, Japan, Australia, and other places around the globe. '
was the most popular single username to try to send bounces to, but the
most popular thing in general was random alphabetical usernames like
'shxonbnjy'. Bad bounces were sent to 425 different bad usernames this
Browsers are the wrong place to report HTML validation errors
A popular idea for dealing with 'malformed' HTML is to have the browsers warn users about it (the most recent example I've run across is in comments here), on the theory that this will cause authors to make their HTML validate. Unfortunately, doing this is about as useful as showing error pukes to website visitors, and for the same reason: it is reporting the problem to the wrong person.
Almost everyone visiting your site is a visitor, not the site's author. It follows that almost every time this hypothetical 'page is malformed' error would go off it would go off to a visitor, who can't do anything about the problem, instead of to the site's author (who can).
The usual retort is that the site's author can visit the page as the final step in publishing and see the warning and do something about it. This is a marvelous theory, but (I argue) incorrect in fact, in part because it assumes that site authors actually bother to check their work, and in part because it assumes that site authors are going to notice a little status notice any more than they notice any of the other little broken things that they let slip by now.
(And if site authors do care about validated HTML they are probably already using one of the validation tools to check their pages, and this feature would not be a particularly big bonus to them.)
This is also a terrible feature from a pragmatic user interface point of view: on today's Internet, it would be the boy who screams wolf all the time, because a rather large number of the pages out there do not pass validation. Such a warning notice would be on a lot; if it is intrusive it gets in your face almost all the time (about something you can't do anything about), and if it's not intrusive it's pretty much a noisy waste of space. This is not a winning user interface element.
(But if you really want it, you can get Firefox extensions that do this.)