Our SMTP listener died on Tuesday evening and was restarted, so some of this week's statistics are incomplete. This week, we:

• got 12,614 messages from 245 different IP addresses.
• handled 17,611 sessions from 882 different IP addresses.
• received 95,812 connections from at least 38,234 different IP addresses since 21:10 Tuesday. (And about 43,000 connections from at least 16,000 different IP addresses up to Tuesday morning at 4am.)
• hit a highwater of 10 connections being checked at once since 21:10 Tuesday.

At a rough guess, this makes the volume about the same as last week, maybe up a bit. The per-day information is unfortunately completely useless, but seems more or less flat from what I can reconstruct.

(It's possible that a significant volume surge on Tuesday took down the SMTP listener; it generally dies on an internal error deep in the depths of the C library. I assume something is getting messed up between threading and other fun issues.)

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
61.128.0.0/10          7354    378K
66.58.176.187          5961    303K
218.254.83.47          5753    276K
220.229.62.220         5694    290K
205.206.60.232         5666    272K
218.0.0.0/11           5192    260K
220.160.0.0/11         4331    216K
193.74.71.23           4209    253K
82.225.205.16          4206    202K
65.214.61.113          4189    201K

This time, pride of place goes to a large aggregate bit of China. It was there last week, but not that high. Of the individual IP addresses:

• 66.58.176.187 and 218.254.83.47 return yet again from last week; at this rate they may earn themselves permanent blocks.
• 220.229.62.220 is part of a Taiwanese netblock, and can't be successfully resolved to a hostname. Since it claims to be something with 'adsl' in the name, we probably don't want to talk to it anyways. (It also appears to be 'dns.maze.com.tw'.)
• 205.206.60.232 is a generic Telus IP address that we reject as a 'dialup'; it's also listed in dsbl.org as an open relay.
• 205.206.60.232 mailed a spamtrap address and then kept trying to send us more mail with the same MAIL FROM.
• 82.225.205.16 is a generic proxad.net IP address. Uh, no. It's also on a pile of DNSbls, including bl.spamcop.net at the moment.
• 65.214.61.113 is another server that mailed a spamtrap address and then kept trying to send; however, they stand out because they've been trying and trying since May 23rd.

Connection time rejection stats:

  41600 total
  19791 bad or no reverse DNS
  16897 dynamic IP
   2579 class bl-cbl
    544 class bl-dsbl
    244 class bl-sdul
    216 class bl-ordb
    179 class bl-njabl
    133 class bl-sbl
    113 class bl-spews

This is down a bit from last week, which may just be the effects of the Tuesday evening SMTP listener restart (since it restarts the greylisting process for everyone).

Out of the top 30 most rejected IP addresses, 18 had more than 100 rejections; the champion was our friend 218.254.83.47 (587 times), with second place going to 210.50.131.218 (only 234, and rejected due to being on the DSBL). 22 of the top 30 are currently in the CBL, and only 7 are currently in bl.spamcop.net.

Hotmail stats are looking quite good:

• 3 messages accepted.
• 1 message rejected because it came from a non-Hotmail email address.
• no messages sent to our spamtraps.
• 1 message refused because its sender address had already hit our spamtraps.
• 1 message refused due to its origin IP address being in the CBL.

On the other hand, the one rejected non-Hotmail email address was from the domain 'mail2agent.net', with Microsoft DNS servers but registered with the contact email of 'eurolottowinner@mail2agent.net'. This looks alarmingly like Hotmail backsliding into the whole original problem.

And the final set of numbers:

what	# this week	(distinct IPs)	# last week	(distinct IPs)
Bad HELOs	727	47	288	69
Bad bounces	34	18	27	23

Surprisingly (to me) there is no single huge spike source of bad HELO names; there's only four that had 50 or more rejections, in fact.

There were another four bounces to the 38-digit hex string, a bunch of bounces to plausible login names (many of which used to exist here), but only unlike last week, only one bounce to an all-digit username.