Things Spammers Do

Much like every other day, I got some spam today. Here’s a lightly edited copy of it.
Let’s go through it and see what they did that makes it clear that it’s spam, which companies helped them out, and what you should avoid doing to avoid looking like these spammers…

This tells me it was sent from Verizon wireless network space – which means it’s almost certainly spam, as legitimate mail doesn’t come directly from cellphones or cellular access points, it comes from smarthosts. And it also tells me that the spammer is lying about who they are, claiming to be “[213.144.59.132]” when they’re really not.

X-Spam-Status: No, score=1.7 required=7.0 tests=HTML_EXTRA_CLOSE,HTML_MESSAGE, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=disabled version=3.2.5

This line was added by SpamAssassin running on my mailserver. HTML_MESSAGE isn’t very interesting – it just says there was some HTML in the mail – but the others are fairly strong signs that it’s spam. HTML_EXTRA_CLOSE is one of many spamassassin rules based on the HTML content of the message being malformed in some way, suggesting it was created by badly written software such as spamware.
RCVD_IN_PBL and RDNS_DYNAMIC are both really strong signs that no email from this Verizon IP address is legitimate, but in different ways. RDNS_DYNAMIC shows that Verizon hasn’t done anything special with the IP address to suggest it might be a legitimate server – it’s in the vast wasteland of consumer IP addresses that nobody really cares about, and not somewhere you should expect legitimate mail from. RCVD_IN_PBL is much more specific – it tells us that Verizon explicitly told Spamhaus that no email should ever be emitted from here (a provider that cared about spam might actually block traffic on port 25 from that sort of space, but we’ll take what we can get). If you ever see either of these on mail, it’s spam.

From: “Tom Joelson” <Noreply234239-389512@qmail.com>

Legitimate mail would have a company name, or maybe a personal name I’d recognize in the “friendly from”. Strike one. Legitimate mail wouldn’t have the word “noreply” anywhere in it – telling your recipients you don’t want to hear from them is rather disrespectful. Strike two. Random numerics in the From field are really bad: as well as looking like you’re trying to pull a fast one they’d make it impossible for a recipient to whitelist your mail. That sort of thing is fine in the return path, as part of VERP encoding, but not in the From address that’s visible to the recipient. Strike three. Qmail.com is an asian freemail provider – legitimate bulk mail never claims to be from someone it isn’t, and is never from a freemail provider. Strike four.

There’s very seldom a legitimate reason to have an attachment in bulk email, for several reasons. The email should stand on it’s own, giving the recipient the information they need in a form that’s immediately visible in their mail client. Links to your web page, sure, but the mail should make sense on it’s own, with the links part of a call to action. If you’re sending out mail to existing customers it might occasionally be useful to attach a PDF copy of a catalogue or somesuch, but the content of the email should still stand on it’s own (and given the security flaws in PDF that allow it to be used as a payload for viruses I’d be wary about doing even that).

Click This Link to Stop Future Messages =
<mailto:listservices@gmx.com?subject=3DUnsubscribe%3A%20myemail@mydomain>

Sure, you should have an unsubscription link in the messages you send. But it should be to an unsubscription page on your webserver, not a mailto link that sends mail anywhere, let alone to a dubious freemail provider (I’m prepared to believe gmx.com has legitimate users, but I’ve never seen it used anywhere other than in spam). And the clumsy phrasing looks like an attempt to avoid naive content filters.
All these things told me, and would have told a decent spam filter, that this wasn’t legitimate mail. Let’s dig down further and see how the spammer tried to avoid being identified.
The attachment is an HTML document, and it’s been base64 encoded. There’s never a good reason to use base64 encoding for English language attachments, unless you consider hiding the content of your email from naive spam filters a good reason. Less naive spam filters will decode the attachment and look inside it anyway. And they might consider the dishonest use of base64 encoding a bad enough sign in itself.
We can easily decode the base64 by hand, either by using a web based decoder or from a random unix-ish commandline by typing “openssl enc -d -base64”, hitting return, pasting in the encoded text and hitting ctrl-d.
That gives us this:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<html><head>
<META HTTP-EQUIV=”Refresh” CONTENT=”0; URL=http://cts.vresp.com/c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416″>
</head></body></html>

What that snippet of HTML will do when you open it is immediately redirect to the URL given in the middle. I recognize cts.vresp.com as VerticalResponse‘s clickthrough redirector, so it looks like a spammer created a test account at VerticalResponse in order to be able to abuse their redirector to hide the final destination. Naughty spammer.
If I didn’t recognize the URL as belonging to VerticalResponse, though, I’d visit the obvious webpages to see who it is. http://cts.vresp.com/ just tells me “Forbidden”. Bad.  http://vresp.com/ just says “hola”, which isn’t a good sign either. I’m not sure whether http://www.vresp.com/ is better or worse – it doesn’t mention the real company name and claims it’s “a domain that sends permission-based emails”. That’s really fishy, and looks just like many, many dedicated spammer domains. The lesson to learn is that if you use a domain in your email, then there should be a webserver at any of the related hostnames, it should tell anyone visiting it what the domain is used for, the real name of the company that’s operating it and provide a link to their corporate website.
Let’s see where the VerticalResponse redirector sends us to. This is pretty easy to do using telnet from a unix commandline or a windows command prompt. We’re looking at the URL http://cts.vresp.com/c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416, which I’m going to split into the host “cts.vresp.com” and the path “/c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416”. You just have to type the bits in blue, and remember to hit return twice after the Host: line.
steve@ubuntu:~$ telnet cts.vresp.com 80
Trying 74.116.90.234...
Connected to cts.vresp.com.
Escape character is '^]'.
GET /c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416 HTTP/1.1
Host: cts.vresp.com
HTTP/1.1 302 Found
Date: Mon, 14 May 2012 18:36:58 GMT
Server: Apache
Location: http://www.christiancafe.com/guests/join/indexc.jsp?id=11416
P3P: policyref="https://cts.vresp.com/w3c/p3p.xml", CP="CAO DSP COR IVAo IVDo OUR STP PUR COM NAV"
Cache-Control: max-age=0, no-store, no-cache, must-revalidate
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

(If you try and do this yourself you’ll discover that VerticalResponse have already shut down this redirector in response to an abuse report. Thanks, VR.)
And christiancafe.com is our spammer.
There’s more I could say about how they’re hosting their website (on Amazon EC2 Web Services, with suspiciously short DNS TTLs) but I think this is more than enough for one blog post.