spam/SpamSummary-2007-01-20 written at 23:28:55; Add Comment
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:
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 220.127.116.11 21316 1101K 18.104.22.168/24 18080 1081K 22.214.171.124/24 12078 544K 126.96.36.199 4945 231K 188.8.131.52 4683 225K 184.108.40.206 4208 202K 220.127.116.11 4149 248K 18.104.22.168 4058 195K 22.214.171.124 3513 169K 126.96.36.199 3360 161K
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:
And the final numbers:
I can't say that this looks good compared to last week. There is
a clear winner of the bad
Germany remained a major source of our bad rejections, sprinkled with
Italy, Japan, Australia, and other places around the globe. '
web/ValidatingBrowsers written at 00:29:18; Add Comment
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.)
* * *
Atom feeds are available; see the bottom of most pages.