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…
Received: from [22.214.171.124] (114.sub-75-210-142.myvzw.com [126.96.36.199] by m.wordtothewise.com (Postfix) with SMTP id DEA552EAE2
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 “[188.8.131.52]” 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” <Noreply234239firstname.lastname@example.org>
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.
… check out the attached brochure for more information …
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 =
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”>
<META HTTP-EQUIV=”Refresh” CONTENT=”0; URL=http://cts.vresp.com/c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416″>
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
Connected to cts.vresp.com.
Escape character is '^]'.
GET /c/?ChristianCafe/207bd98dc8/TEST/025270d267/id=11416 HTTP/1.1
HTTP/1.1 302 Found
Date: Mon, 14 May 2012 18:36:58 GMT
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
(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.
“a provider that cared about spam might actually block traffic on port 25 from that sort of space”
Most certainly not. If I want to use outbound GMail on my Verizon iPhone, I have to set it up to connect to smtp.gmail.com on port 25, issue a SMTP AUTH and then send my email. Blocking outbound SMTP connections would cripple that. With GMail I have the option to use port 587, but not every email provider supports that.
I’ve found that pretty much every smarthost provider that supports roaming does offer SUBMIT on port 587, not least because port 25 blocking isn’t unusual (as it’s an extremely effective way to mitigate spam and botnet activity from consumer address pools).
A few years back port 587 wasn’t quite so easy to use as client support for it wasn’t universal, but that problem seems to have passed.
An interesting thing happened on most US dialup providers over the course of 2000 to 2002 or thereabouts: as each major provider began blocking direct access to port 25, you could watch the spammers migrate to the next easy target. So one week, there’d be a huge pile of bad guys on one provider’s network, and as their network rollout of port 25 blocking happened, you’d see all the complaints spike at a different provider. And this spammer migration happened a couple times.
The effect is much less now, due in no small part to things like the PBL, but it’s still easy for mailserver operators to tell which providers block port 25 and which don’t. And the PBL is kind of a copout — if someone doesn’t have any business being able to talk on port 25, the solution is not to list them in a database that will block them after the fact, the solution is to specifically disallow them from doing so. And the hobbyists who say “But I should be allowed to!”: first, you are the edge case, and the vast numbers of trojanned machines that this policy protects the world from are not you; and second, I agree with you. If you have a legitimate reason to talk on port 25, there should be a simple checkbox on your provider’s control panel page that would allow you to do that, in much the same way that you can painlessly remove yourself from the CBL assuming you’ve solved the underlying problem. This policy is not meant to hinder those people who know what the hell they’re doing, it’s meant to protect the internet from those who don’t.
Great post, very informative. Thanx.
An *excellent* description of how to track down the actual spammer behind a spam. Laura, you might want to turn this into a permanent page.
Is unsubscribe by a mailto link bad ? Why?
Ram: This one in particular uses a freemail or ISP account to collect unsubscribe replies. It implies this is a spammer playing dress-up, pretending to be legitimate. It implies no actual infrastructure to handle processing of unsubscribe requests, and by extension, implies that you cannot assume or trust that the spammer will respect the request and stop sending you email.
If it wasn’t at a freemail provider, it still wouldn’t be great. Email-based unsubscribe processes are more prone to failure, because it’s most commonly done in a way where they’re set up to automatically unsub the address that sends the request. This is not always the proper recipient address to unsubscribe. And may not even be an address on the list.
Hi. This is Grayson Peddie managing my own Postfix mail server. Can I reject or discard e-mail based on the rule condition that matches RDNS_DYNAMIC? I have blocked e-mail messages in the past that matched “RDNS_NONE.” I haven’t gotten any legitimate e-mail messages with that rule.
You can block anything you want to block, it’s your server and your responsibility is to your users. If you’re going to block dynamic addresses, I might look at one of the publicly maintained dynamic lists like the PBL. That’s going to be a bit more accurate and curated.
In general unsubscribe fields should be carefully examined. If they are not, using them will inevitably lead to exponentially increasing spam. This isn’t so much in the nature of experience (beyond experiment, which I did) as of many articles dating from last century. Spammers don’t change much.