== 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: .pn prewrap on > 220 hisokusa.cs.toronto.edu go-smtpd > HELO smelektronik.de > 250 hisokusa.cs.toronto.edu Hello 86.34.202.208 > MAIL FROM: > 250 Okay, I'll believe you for now > RCPT TO: > 250 Okay, I'll believe you for now > RCPT TO: > 250 Okay, I'll believe you for now > RCPT TO: > 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.)