Revealing Email Headers

Posted by admin

March 31, 2010

When a fraudulent phishing e-mail or scam, arrives in your mailbox, there is no danger to you unless you reply to the message. The ACCC’s SCAMwatch website provides information on common scams. The website has tips on how to protect yourself from scams and report them to the relevant agencies.

We encourage all customers to forward any and all spam to ACMA. In order for ACMA to do anything about the spam you have received, you must include the full email headers in the email that you forward.

Full e-mail headers are needed to investigate any phishing attempt so that the source of a message can be revealed. To retrieve the full headers from a message, you will need to locate it within your e-mail client. Instructions for locating and copying e-mail headers in different e-mail clients can be found at: www.spamcop.net.

Below is a quick set of instructions in how to reveal email headers in Outlook 2003 and Outlook 2007

Open the offending email.
Click on the word View in the menu bar.
Select the option Options.
The Message Options dialog will apear.
Right-click on the text in the Internet Headerssection.
A submenu will appear.
Choose the option Select All.
The text will appear in inverse video, indicating that it is selected.
Right-click on the selected text.
A submenu will appear.
Choose the option Copy.
Click on the Close button.
The Message Options will disappear and you
will return to the offending email. Now you have the message in your buffer.

A Sample phishing mail

Below is a more detailed look at email headers, it is not for the faint hearted.

Return-Path: <(Aktiviere JavaScript, um die Email-Adresse zu sehen)>
Envelope-To: (Aktiviere JavaScript, um die Email-Adresse zu sehen)
Received: from [84.120.132.215]
 (helo=84-120-132-215.onocable.ono.com)
 by example.com with smtp (NetMail-SMTP 1.16);
 Sun, 10 Oct 2004 03:40:32 +0200 (CEST)
Date: Sun, 10 Oct 2004 05:39:35 +0300
From: CitiBank <(Aktiviere JavaScript, um die Email-Adresse zu sehen)>
MIME-Version: 1.0
To: (Aktiviere JavaScript, um die Email-Adresse zu sehen)
Subject: CITIBANK REMINDER: UPDATE YOUR DATA

The sample above shows a very typical mail header. In this case it is even a so-called phishing e-mail, offering a link to a faked website which looks like the one of a bank, but then captures (fishes) your log-in data to use it for fraud. We have changed the recipient’s address to (Aktiviere JavaScript, um die Email-Adresse zu sehen) for privacy reasons. Let’s look at the header lines one by one.

Return-Path: This line is not created by the sender but inserted by the receiving e-mail server using the address behind MAIL FROM in the SMTP dialogue. It is not verified. In most cases (but not all) it is the same as in the From: header line which your e-mail client displays as the sender’s address. Since there is only one MAIL FROM during the SMTP dialogue, there should be only one Return-Path line. An empty address like <> is allowed if the mail is from a Mailer-Daemon or a similar automated sender which cannot receive answers.

Envelope-To: For routing the received e-mail to the intended recipient(s), many e-mail systems insert this line using the address(es) from RCPT TO in the SMTP dialogue. While this is not really necessary for mails where all recipients are behind To: or Cc:, it allows the correct routing even for a Bcc: addressed e-mail. Unfortunately, the syntax is not standardized. “X-Envelope-To:”, “Delivered-To:” or “X-Pop3-Rcpt:” are some alternative forms. Angle brackets around each address are optional.

Received: While our example shows only one Received line, two or more of them are typical for most e-mails. Each mail server the e-mail passes on its way from the sender to the recipient inserts its own. The topmost is the newest, created by the server nearest to you, and you should rely on this one only, since all following lines may be faked. If there is only one Received line in the header, the sender did not deliver it via the SMTP smarthost of his local provider, but sent it directly to your server or your provider, which is very typical for spam and viruses. The format of Received lines is not always exactly the same, but in most cases it consists of this information:

IP address: If the topmost Received line is created by your local mail server or your provider, the true IP address of the sender is shown here (which is 84.120.132.215 in our sample above).

HELO identification: The HELO command is used by the sending SMTP client to identify itself (…ono.com here, obviously an ISP in Spain). Note that HELO should display the reverse-DNS name of the IP, which surprisingly is the case in this phishing e-mail, but for many spam and virus mails it is just a fantasy name. If the IP address is not in your local LAN, a HELO name without dots is definitively faked. In the sample above, the sender apparently used a reverse DNS request to find out his local domain name in order to send a realistic HELO string.

Mail server name and system: The line "by example.com with smtp (NetMail-SMTP 1.16)" shows the (or at least one) domain of the server receiving this e-mail, the protocol used (typically SMTP) and the server software (the NetMail SMTP module in this sample).

Recipient (optional): The recipient’s address is sometimes given behind the keyword "for" in the Received line. This may be useful for BCC-addressed mails. If there is no Envelope-To line (or similar), then this may be the only place where the intended recipient address can be seen. However, this field is optional. Furthermore the SMTP standard only allows one address there, so this information is often suppressed for multi-addressed mails.

Date and time: Assuming that the clocks of all systems involved are not too inaccurate, you can see when a specific server received this message. Note that the local time zones may be different. The difference to GMT/UTC is given as a signed 4-digit number. For instance, +0200 means 02 hours and 00 minutes earlier than UTC. Some systems add the name of the time zone in brackets for better readability. A few proprietary, typically American systems replace the number by the time zone name like EDT (Eastern
Daylight Time), but this is a bad idea since it is often ambiguous: EDT is valid in the US (UTC+4) as well as in Australia (UTC+11).

Date: The date and time when this e-mail was created. It is not necessarily the time when the message was actually sent to the Internet. The format is the same as the one used in Received: lines described above. Since it depends on the client’s system clock, it may be more inaccurate than the times in the Received lines created by well-adjusted servers.

From: The alleged sender of this e-mail. If an answer is requested to a different address than the one behind From:, a Reply-To: line is added with the address where an answer should go to. Both may be completely faked. It is crystal-clear that citibank.com would never send their mails over a cable access of ono.com in Spain. For most normal mails, the From: line shows the same address as the Return-Path information in the header, but this is not required. Typical From lines are (comments added in brackets):

From: CitiBank <(Aktiviere JavaScript, um die Email-Adresse zu sehen)> (as in sample above)
From: "CitiBank" <(Aktiviere JavaScript, um die Email-Adresse zu sehen)> (quoted real name)
From: (Aktiviere JavaScript, um die Email-Adresse zu sehen) (no real name given)

The From: address in the sample above is faked, of course: The word “antifraud” and the name of the bank are simply intended to confuse the recipient.

To:, Cc: Displays the recipients except the ones sent as Bcc. Some badly implemented clients even send a Bcc line, but this does not conform to the standard since Bcc addresses should not be visible to other recipients. When sending an e-mail, the SMTP dialogue uses RCPT TO for all destination addresses, so the things behind To and Cc (just as all the other content of the message header and body) are completely irrelevant and may be even faked. The possible address formats are the same as for From (see above), multiple addresses can be separated by commas.

Subject: The subject of the e-mail. It is interesting that it is uppercase-only in this sample; this fact could add some percent to a probability value that an e-mail is unwanted spam.

Email Support, Security

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.

Comments

No comments yet.