Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Many of my users today got email from (where docs# was between docs0 and docs8 or so, and is obviously changed from my real domain name), with the sender name of "Administrator." The message had subject "New Voice message" and message: "You have received a voice mail message. Message length is 00:06:11." It was sent to many different users and distribution groups, a weird mix of different departments that wouldn't normally make sense (email to our customer service group, plus our CFO, plus a random IT member? Weird). There was an attachment: ATT00001..txt, a text file.

Some research online shows this to be a virus attempt possibly from CryptoLocker (yikes!!!), and the remaining text file is what was left after being stripped upon arrival, either by our spam filtering service (I don't think so, based on logs), our SonicWALL gateway (I believe it's this that saved us), or a virus scanner built in to Outlook (nope, Webmail shows the same attachment). We use Postini for our spam filtering service, so our MX records direct all email there and our squid proxy server only accepts mail from Postini, does some filtering, and passes it on to our Exchange server.

Based on the email header, I've figured out this route that the email has allegedly taken (Domain and our public IP have been changed): ( --> ( ( --> ( ([]) --> ([]) ( []) --> ([]) --> localhost ( [])

localhost (localhost.localdomain []) --> ( --> (

Postini was allowing these messages through, even though there were a couple of strange things about them. For example, the SMTP Message-ID is a unique string that is set by the first message server that handles the message, and is normally not messed with by any subsequent servers. Yet this email's Message-ID was instead of, for example if I got something from Dell, it would say It has my domain in its Message-ID.

But that's when I realized, the first servers to handle the message DID have my domain name! That's how the SMTP Message-ID was spoofed, I presume. In fact, that residential address in India (ABTS-KK-dynamic...) is probably a home user with a virus, and that virus made up the first few addresses.

The problem there is those 10.x.x.x addresses are not only in the private ARPA IP range, but they obviously don't really correspond to our domain (altered, but in this example my "real" IP is Another issue is that there is a gap between the fake and the Indian computer.

How do our mail servers not account for a major gap in the headers? And does it not verify anything about the originating server, just takes its word for it? Because not only is it not a valid IP, it doesn't match DNS records for that domain it says, plus the originating domain is the same as the destination domain! That wouldn't normally make sense, as that mail would be internal.

Also, am I right about this SMTP Message-ID spoofing technique? I can't find anything like it online. But the tactic makes sense - If I say it came from some bogus servers and the middle servers never verify that, the final server will believe it really came from my domain. Simple MAIL FROM: spoofing on an open relay won't work on our server, but something like this apparently can. I'm just not sure if that's what's being done here.

Here's the entire faked headers file (renamed public IP, domain, and To: email addresses only): Pastebin link

share|improve this question

Everything about an email message can be forged, or can be tampered with in transit. The only headers you can trust are those put there by your server; the only content you can trust is that protected by a verified digital signature. In the case of your pastebin file, if I'm understanding your description of your network setup correctly, lines 1 through 22 are trustworthy, lines 23 through 25 are probably trustworthy, and everything from line 26 on down is forged.

Email servers don't account for gaps in the headers because they don't need to. Most email servers are designed on the Unix philosophy: do one thing, do it well, and provide a standard way to interface with other programs. An email server's job is to move email from Point A to Point B; things like checking for gaps in the headers is the job of a spam filter.

share|improve this answer
Any ideas how to prevent these, then? Should I be looking at Postini, our proxy, our SonicWALL, or Exchange? – armani Jan 22 '14 at 14:25
Great answer, although you just said yourself that not all headers can be forged, just the ones your server didn't put there (or sometimes Google's server or your ISP or someone you can semi-trust) That's the first few all-so-important "Received:" headers at the least. (Of course, the last one could be IP spoofed etc) – ebyrob Feb 10 '15 at 14:17
@armani a year late, but investigating who owns that Postini virtual server and how much you trust them would have been the first step... – ebyrob Feb 10 '15 at 14:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.