Wandering Thoughts archives

Sometimes 'unsubscribing' does seem to reduce spam activity

There is one particular email sending place that has for some time been the most prolific source of sending attempts to some of my old addresses. I put them in IP-level blocks literally years ago (which means that nothing they've sent me for years has been delivered) and ever since then I could count on their relatively small netblock to be either the very top blocked traffic source or at least one of them. They have in the past been SBL-listed, although they may not be right now, and there are plenty of reports all over the net of bad behavior. If you had asked me to pick someone who would never, ever stop spamming me they would have been at the top of the list.

When I started my sinkhole SMTP server experiment, of course they were one of the people who sent me email basically immediately (within a few minutes of the service starting). So I tried out their unsubscribe link to see what would happen. To my surprise I have gotten no email from them in the 20 days or so since then, when normally I would expect to be awash in it.

This is not a definitive test by any means, for many reasons (including that it's early yet). But it's at least an interesting and surprising result for me. Given that these people have ignored what is probably a half a decade worth of bounces, they were about the last people I'd have expected an unsubscribe to work on.

(I think I'm going to avoid speculating about why they might totally ignore years of bounces and non-delivery reports yet respond apparently instantly to an unsubscribe attempt, mostly because it would all just be complete speculation and guesswork.)

Weird spammer behavior: a non-relaying relay attempt

One of the the interesting things about running a sinkhole SMTP server that accepts everything and basically serves as a spamtrap is that I get to see all sorts of odd and crazy spammer behavior. Take the following SMTP transaction log:

220 hisokusa.cs.toronto.edu go-smtpd
HELO smelektronik.de
250 hisokusa.cs.toronto.edu Hello 86.34.202.208
MAIL FROM: <jhbrrhf@smelektronik.de>
250 Okay, I'll believe you for now
RCPT TO: <XXXX@hawkwind.utcs.utoronto.ca>
250 Okay, I'll believe you for now
RCPT TO: <betty@hawkwindbase.f9.co.uk>
250 Okay, I'll believe you for now
RCPT TO: <mail@hawkwise.fsbusiness.co.uk>
250 Okay, I'll believe you for now
DATA
....

This is a CBL-listed IP address and the spaces after the ':' in MAIL FROM and RCPT TO is typical of badly implemented spamware (it's not RFC-compliant, although many mailers will accept it). The interesting thing is the second and third RCPT TO addresses. My sinkhole here is not the MX target for any of them (of course).

Sometimes you'll see deliberate relay attempt probes, but this doesn't seem to be one of them. Instead it looks like the spammer's software is just clumping lexically similar domains together and then dumping N addresses one the MX target of the first one, regardless of whether the additional addresses will ever get accepted (almost no MTA will, because almost all are configured to not relay these days).

About all I can guess is that someone wrote software that either has a bug or that is simply extremely sloppy and wrong, and the authors either never tested it or don't care. Perhaps they make their money from selling it to people who simply don't notice that an appreciable amount of their delivery attempts can never succeed. I suppose the customers are probably not in a position to really notice this behavior.

(My logs shows three such attempts so far in a few days, from two different IPs in total. It all appears to be the same spam run.)