Open Relay

Relaying Denied

I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things

Fun with new mailservers

I’m building a new set of mailservers for wordtothewise.com – our existing mailserver was “I’ll repurpose this test box for a week” about four years ago, so it’s long past time.
I tested our new smarthost by sending a test mail to gmail. This is the very first email this IP address has sent in at least three or four years, possibly forever:

Open relays

Spamhaus wrote about the return of open relays yesterday. What they’re seeing today matches what I see: there is fairly consistent abuse of open relays to send spam. As spam problems go it’s not as serious as compromised machines or abuse-tolerant ESPs / ISPs/ freemail providers – either in terms of volume or user inbox experience – but it’s definitely part of the problem.
I’m not sure how much of a new problem it is, though.
Spammers scan the ‘net for mailservers and attempt to relay email through them back to email addresses they control. Any mail that’s delivered is a sign of an open relay. They typically put the IP address of the mailserver they connected to in the subject line of the email, making it easy for them to mechanically extract a list of open relays.
We run some honeypots that will accept and log any transaction, which looks just like an open relay to spammers other than not actually relaying any email. They let us see what’s going on. Here’s a fairly typical recent relay attempt:

Maybe the sky is only falling a little bit

There was quite a bit of breathless reporting last week about the DoS against Spamhaus and how it was large enough to break the Internet. As the postmortem has gone on, a few things are becoming clear.

Open Relays and Mail Sinks

Email is a “store and forward” protocol. The sender doesn’t connect directly to the recipient to send the mail with just one network hop, rather the sender connects to a mailserver (usually referred to as an “MTA”, short for Mail Transfer Agent) and sends the message there. Once that MTA has received the message it sends it on to another MTA, and so on until it reaches the recipient.
Mail clients typically don’t have any intelligence built in to them to decide which MTA to send an email to. Instead they’re configured to blindly send every message to one particular local MTA, the smarthost, which then does all the proper SMTP work to decide where to send it on to.