My worst enemy.
A number of our clients have mailing or distribution lists that they send out from time to time. Part of The Right Thing to do when you maintain a mailing list is to periodically go through the bounces and remove any addresses that no are no longer valid. In fact, most mailing list software is polite enough to handle this for you, automatically removing subscribers who bounce permanently.
Enter this goddamn message. A relatively large number of recipients were bouncing with the (permanent!) error, “554 The message was rejected because it contains prohibited virus or spam content.” Of course, our clients wanted to know why, since these otherwise perfectly-valid addresses were being pruned on a regular basis.
The first step is to figure out who the hell is sending us this garbage. The names here have obviously been changed to protect the innocent. I'm going to use the incredibly confusing convention that the sender (our client) is example.com, and the recipient is at example.org. Let's say this is one of the bounces:
From: Mail Error Handler [mailto:MAILER-DAEMON@example.com]
Sent: Wednesday, October 15, 2008 12:51 PM
To: sender@example.com
Subject: Undeliverable Mail Returned to Sender
*** This message was automatically generated by the MailMax Error Responder ***
Sorry, your message from <sender@example.com> to <recipient@example.org> could not be delivered. The specific error is:
554 The message was rejected because it contains prohibited virus or spam content
This is permanent error, and the message will not be retried any further.
So, the mail server for example.org is the one that gave us the 554 error. Let's see who they are.
user $ dig example.org mx
; <<>> DiG 9.4.2-P2 <<>> example.org mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57549
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;example.org. IN MX
;; ANSWER SECTION:
example.org. 3600 IN MX 0 smtp.secureserver.net.
;; Query time: 97 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Oct 26 12:47:43 2008
;; MSG SIZE rcvd: 87
And so we see that, whoever they are, they use smtp.secureserver.net as their incoming mail server. Now, I'm going to skip some important steps here, and just solve the mystery: smtp.secureserver.net is the incoming mail server for all of the email hosted by GoDaddy.
I asked a couple of the recipients if their email was hosted by GoDaddy, and they confirmed my suspicions. So, what the hell are they doing? That's the real question. It appears as if they're rejecting messages almost at random, without any regard to the actual content.
Googling for this error doesn't produce much unless you know what you're looking for. Mostly you'll just find replies like “stop sending spam.” But, some of the test messages we sent were basically blank – with no text except whatever email signature the client had set up. Ultimately, that's what clued me in to what GoDaddy is doing.
Once I had narrowed it down to a particular set of text that was triggering the filter, it became obvious. One at a time I removed lines from the signature until I was left with the text that triggered the spam filter: http://www.example.com/.
Why the hell are they rejecting the URL? Maybe it sent them some spam in the past? Nope, we can try with some other URLs that never send mail and they get blocked too. Are you ready for the answer yet? Brace yourself because the stupidity of what you are about to hear is dangerous:
GoDaddy is rejecting all mail containing a URL whose hostname resolves to an IP listed in the PBL.
The PBL is a list of IP addresses that, according to policy, should not be sending email. Ok. Wait, what? The IP addresses in the PBL should not send email. Ok, got it. Now, what the hell were we talking about? Oh, right. I'll say it again:
GoDaddy is rejecting all mail containing a URL whose hostname resolves to an IP listed in the PBL.
If that doesn't make much sense to you, good. Because it doesn't make any motherfucking sense.
Here is a not-so-contrived example. Let's say you have a website. Call it, http://www.example.com/ (ha ha, see where this is going?). You do business on this website, and so you have purchased an SSL certificate and host the website on its own IP address.
Now, this IP address is only used to host this one website; nothing else. So, as an upstanding internet citizen, your network administrator has listed it in the PBL. After all, it's not supposed to be sending mail. See the problem? The purpose of the PBL is to list IP addresses just like these.
GoDaddy is using the PBL for something for which it was not intended. When sender@example.com sends a message with his or her website URL in the signature, GoDaddy looks up the IP address for www.example.com, and checks it against the PBL. Of course, it's in there, because the host www.example.com should not be sending email. And www.example.com isn't the one sending the email. The host (i.e. mail server) sending the email is someone completely different with little or no relationship to the website at all.
So this is a completely braindead idea. What's worse is that the PBL FAQ explicitly tells you not to do this because it's stupid.
Once you know the answer, of course, it seems easy to prove yourself right. It turns out that all of Amazon's EC2 service is listed in the PBL, since, according to Amazon policy, it should not be sending mail. EC2 is basically a hosting service for enterprisey clients who need some muscle behind their websites. Note that since it has the word “enterprise” in it, it's expensive.
Putting this together, we have a bunch of rich/important people/websites utilizing EC2 who can't send mail about their websites to GoDaddy users, since the website URL resolves to an IP address on the PBL. Needless to say, they're pissed.
Anyway, it was nice to find that out after I had solved the problem. Oh, right, I solved the problem: I had to manually remove every one of our websites' IP addresses from the PBL so that we can send mail to these pieces of shit. Fuck GoDaddy.