Terry Zink: Security Talk

Discussing Internet security in (mostly) plain English

Sender authentication part 3: Checking the received headers

Sender authentication part 3: Checking the received headers

Rate This
  • Comments 2

In my previous post on the basics of email headers, we saw the basic headers that are inserted by receiving mail agent.  In this post, we are going to look at some of the techniques that spammers use to hide themselves.

Recall a received header; it's an envelope header that a machine inserts to log where it came from.  A good mail recipient will log the received IP.  From the example earlier:

Received: from mailhost.tzink-is-awesome.com (mailhost.tzink-is-awesome.com [292.13.130.22]) by mail.tzink.net (8.8.5) for me@tzink-is-awesome.com with EMSTP id 123456789-0AH for <me@tzink.net>

In this example, the IP (292.13.130.22) that sent the message has a reverse DNS of mailhost.tzink-is-awesome.com.  When the transmitting machine sent the message, it said "Hello, my name is mailhost.tzink-is-awesome.com."  In other words, everything checked out.

However, what would happen if a spammer decided to forge the HELO?  What if they said "Hello, my name is mailhost.awiebersand.com"?

Received: from mailhost.awiebersand.com (mailhost.tzink-is-awesome.com [292.13.130.22]) by mail.tzink.net (8.8.5) for me@tzink-is-awesome.com with EMSTP id 545D2FE805C for <me@tzink.net>

In this example, the machine claimed to be mailhost.awiebe.com, but was sending from mailhost.tzink-is-awesome.com.  Right off the bat we can see that there is a mismatch.  By looking up the IP address awiebersand.com, it resolves to 264.33.78.90.  In other words, it is completely different than tzink-is-awesome.com.  Thus, we have come across an example of a transmitting machine that claimed to be sending from one mail host but in actually was sending from another.

A smarter spammer will use a trick to bypass this.  Rather than sending from an IP address that has a reverse DNS lookup (ie, converting an IP to a domain name), they will send mail from an IP that has no reverse DNS.  In that case, the received line would look like the following:

Received: from mailhost.awiebersand.com (unknown [282.31.31.22]) by mail.tzink.net (8.8.5) for me@tzink-is-awesome.com with EMSTP id 545D2FE805C for <me@tzink.net>

I've inserted the "unknown" because the above IP address does not resolve to a DNS (and that's the way our servers mark it in the headers).  Since the transmitting IP has no reverse DNS there's no way to verify whether 282.31.31.22 resolves to it.  Doing a DNS lookup on awiebersand.com doesn't match the IP address; this is suspicious and in itself doesn't prove the domain is spammy but is definitely worth increasing the spam probability.

A smarter spammer still would obfuscate even more:

Received: from hofgado (unknown [272.16.141.210]) by mail.tzink.net (8.8.5) for me@tzink-is-awesome.com with EMSTP id 545D2FE805C for <me@tzink.net>

The transmitting machine called itself hofgado and sent from an IP with no reverse DNS.  In this case, there's definitely no way to resolve this because the machine name won't resolve via a DNS lookup (not in the proper format) and there is no reverse IP.  This is certainly suspicious and would definitely increase the spam probability.  On the other hand, there are a lot of misconfigured mail servers out there that are sending legitimate mail.

In the next post, I will go into how Forward-Confirmed Reverse DNS can help with email authentication.

Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
  • It may be worth noting that sometimes spammers insert extra, completely fabricated Received: headers just to make it appear that a message followed a route which it really did not.  Often you can't look at any one Received: in isolation, but instead must make sure that the whole chain of them makes sense.

  • Bart,

    That will be in my next post.

Page 1 of 1 (2 items)