Writing

Software, technology, sysadmin war stories, and more. Feed
Sunday, January 29, 2012

Looping SMTP connections to detect open relays

Back in the days when open SMTP relays were a huge problem, there was something of a war going on between spammers and sysadmins. One of the techniques used to make life miserable for the people who abused an open relay was to "blacklist" it. There were lists you could query via DNS to see if a host was marked as bad.

The problem with these lists is that they tended to come and go, and had variable quality. The ones which worked really well would frequently come under attack, not surprisingly. Others would be left alone but they would miss a bunch of garbage. It was hard to find that sweet spot.

I decided I wanted my own way to find open relays for my own filtering purposes without performing scans of arbitrary hosts. I came up with a simple position that wouldn't be impossible to defend if someone decided to challenge what I was doing. I thought of it as a "golden rule".

Basically, if you connected to my port 25, I tried to connect right back to your port 25. If it failed, then I hung up on you. Otherwise, I took whatever your port 25 sent to me and sent it right back to you. Likewise, anything your client-side sent to me was sent to your server.

In other words, if you did "telnet my.mx.host 25", you'd eventually see something like "220 evil.open.relay SMTP ready". If you sent a HELO to me, you'd really be sending a HELO to yourself, and whatever your mail server's response was would go right back to you. This included the MAIL, RCPT, and even DATA phases. I passed it all straight through.

Naturally, I kept logs of this stuff. Just a casual glance at the activity would show which hosts had clueless or nonexistent admins and deserved to be blackholed forever.

There were some interesting discoveries from all of this. First, sendmail systems would usually notice their own banner coming back at them and would flip out, bounce the mail, and that would be it. It didn't matter that they were getting it from me. Just a hostname match was enough to trip it.

Next, some hosts actually had a top-end limiter on Received: lines. After 30 or so hops, they'd give up. I knew this because the mail would spin around and around through dozens of connections and then would curiously vanish after the Received list got up to a certain point.

Of course, those hosts which didn't implement loop-killer logic were the best. They'd loop that mail through me hundreds or thousands of times. I loved the fact that it was burning disk space on their end, since they had to store the growing messages and log entries. All it cost me was a tiny bit of CPU time and bandwidth.

This only worked because I had at least one host.domain.name which was a complete loss to spam. It had been used by a bunch of people on Usenet once upon a time, and those addresses had been spread far and wide. I suspect a number of them were baked into those "millions" lists of e-mail addresses you could buy on CD at the time.

I also had a whole IP address which wasn't doing anything meaningful in terms of TCP port 25 traffic. It was no big deal to just park my smtplooper program on there and let it mess with people who talked to it. By definition, anyone connecting there was either mailing my spamtrap namespace or they were just probing for SMTP servers. Neither of them would ever be a real message, so doing this was safe.

Technically, you could say that I was pushing mail through those open relays. Well, I was, but I was only sending to them exactly what they sent to me first. That's what I mean by the "golden rule" and a potentially defensible position.

As it turned out, nobody ever complained to me or my upstream provider, so it all worked out in the end. I got a lot of useful data and random amusement, and a bunch of bad systems choked on their own garbage.