Weekly spam summary on Janury 6th, 2007
This week, we:
- got 12,487 messages from 217 different IP addresses.
- handled 16,802 sessions from 997 different IP addresses.
- received 224,173 connections from at least 71,302 different IP addresses.
- hit a highwater of 23 connections being checked at once.
The university came back from vacation this past Thursday, and of course the spammers never went on much of one to start with. I suspect that volume is up somewhat from last week, but given that this is the first time in a couple of weeks that we have full stats it's hard to be sure.
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 184.108.40.206 24349 1266K 220.127.116.11/24 11208 505K 18.104.22.168/24 10387 623K 22.214.171.124 7857 367K 126.96.36.199 7615 418K 188.8.131.52 4040 205K 184.108.40.206 3383 203K 220.127.116.11 3252 156K 18.104.22.168 2470 148K 22.214.171.124 2289 110K
- 126.96.36.199, 188.8.131.52, and 184.108.40.206 all return from last week, although they've shuffled their order this time around.
- 220.127.116.11/24 is iol.it aka tin.it, who we haven't talked to for a long time.
- 18.104.22.168/24 is centrum.cz, with their volume surging back up from last week's temporary drop.
- 22.214.171.124 and 126.96.36.199 (last heard from in September) had too many bad
- 188.8.131.52 is in the NJABL.
- 184.108.40.206 kept trying to send us phish spam that had already hit our spamtraps.
- 220.127.116.11 reappears from October and still has no reverse DNS information.
Overall volume here is up somewhat from last week.
Connection time rejection stats:
61627 total 38124 dynamic IP 17309 bad or no reverse DNS 4543 class bl-cbl 378 class bl-dsbl 316 class bl-sdul 166 class bl-sbl 84 cuttingedgemedia.com 49 class bl-njabl 24 class bl-spews 21 'fairgamemail.us'
Only one out of the top 30 most rejected IP addresses was rejected
100 times or more: 18.104.22.168 (941 times, a Pacbell DSL line).
20 of the top 30 are currently in the CBL, 10 are currently in
bl.spamcop.net, and one is in the SBL:
22.214.171.124, which also did this last week.
The leading actual SBL rejections this week are:
|97||SBL43537||a /19 escalation listing against SWIFT VENTURES Inc for spammer hosting (31-Dec-2006)|
|19||SBL42599||a /24 ROKSO listing for Brian Kramer / Expedite Media Group (08-Dec-2006)|
|14||SBL49046, SBL37655, SBL38413||an escalating series of listings for ServerFlo, which Spamhaus suspects is a spammer front (23-Nov-2006 for the SBL38413 /20 listing)|
This week Hotmail brought us:
- 4 messages accepted.
- no messages rejected because they came from non-Hotmail email addresses.
- 19 messages sent to our spamtraps.
- 2 messages refused because their sender addresses had already hit our spamtraps.
- 1 message refused due to its origin IP address being inside telkom.co.za.
And the final numbers:
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
Now that's the kind of change I like to see compared to last week.
As you might expect, there are no really big sources of bad
there are so few bad bounces that I can put the usernames in a handy
This is pretty atypical; four of these are actual usernames that used to exist here, and only one is an alphabetical jumble.
For some reason, rpm in Fedora Core 6 (and I believe Fedora Core 5 too)
has become overly twitchy about replacing configuration files; a lot of
the time it will write
.rpmnew files instead of just replacing the old
version of the file even if the old file is unchanged and the new and
the old file are completely identical.
While I think this is multiarch stuff in action, I still have to clean it up every so often. I use a little scriptlet for this, usually typed at the command line:
for i in *.rpmnew; do n=$(basename $i .rpmnew) if cmp -s $i $n; then mv -f $i $n else diff -u $n $i fi done
(Yes, this can be done on one line if you're crazy enough. I admit that
I usually turn the if block into either '
diff -u $n $i' or, once
that's shown me nothing important, '
cmp -s $i $n && mv -f $i $n'.
And if it was an actual script, I would have to start making it more
elaborate, with features like a dryrun option.)
At first I thought I had an idea why this was happening, but the more I
look at the
rpm source code and the RPMs involved in my most recent
case, the more confused I get. As far as I can decode from the
source code, this can't happen unless either the actual file on disk
has been changed (which it hasn't), or there's an existing config file
before the package is installed for the first time (not applicable for
package upgrades). It does seem to only involve things that have RPMs
for more than one architecture installed, though, although I haven't
tested that extensively.