2007-01-06
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.
Day | Connections | different IPs |
Sunday | 31,473 | +11,976 |
Monday | 30,086 | +10,263 |
Tuesday | 36,900 | +11,800 |
Wednesday | 33,074 | +10,070 |
Thursday | 33,327 | +9,978 |
Friday | 34,889 | +9,865 |
Saturday | 24,424 | +7,350 |
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 213.4.149.12 24349 1266K 193.70.192.0/24 11208 505K 213.29.7.0/24 10387 623K 69.15.68.98 7857 367K 212.43.241.13 7615 418K 66.7.28.46 4040 205K 193.252.22.158 3383 203K 69.15.6.139 3252 156K 212.175.13.129 2470 148K 212.184.12.130 2289 110K
- 213.4.149.12, 212.43.241.13, and 193.252.22.158 all return from last week, although they've shuffled their order this time around.
- 193.70.192.0/24 is iol.it aka tin.it, who we haven't talked to for a long time.
- 213.29.7.0/24 is centrum.cz, with their volume surging back up from last week's temporary drop.
- 69.15.68.98 and 212.175.13.129 (last heard from in September) had too many bad
HELO
s. - 66.7.28.46 is in the NJABL.
- 69.15.6.139 kept trying to send us phish spam that had already hit our spamtraps.
- 212.184.12.130 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: 64.166.14.222 (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:
209.205.236.245, 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) |
Bad HELO s |
332 | 130 | 594 | 87 |
Bad bounces | 16 | 11 | 72 | 60 |
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 HELO
s, and
there are so few bad bounces that I can put the usernames in a handy
table:
4 | markf |
4 | ijiefuurmcl |
3 | wtn-editors |
2 | noreply |
1 | user |
1 | morgaine |
1 | ctn-editors |
This is pretty atypical; four of these are actual usernames that used to exist here, and only one is an alphabetical jumble.
Fixing up .rpmnew
files
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 rpm
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.