What is an email header?

The email header is the information that travels with every email, containing details about the sender, route and receiver. It is like a flight ticket: it can tell you who booked it (who sent the email), the departure information (when the email was sent), the route (from where it was sent and how did it arrive to you) and arrival details (who is the receiver and when it was received). As when you would book a flight ticket with a false identity, the same goes for emails: the sender can partially fake these details, pretending that the email was sent from a different account (common practice for spammers or viruses).

 

This document explains how to analyze information extracted from an email when troubleshooting. It describes the kinds of data that can be found in the email header and message body and what kinds of clues to look for in the various header and message fields.

                                             How to interpret email headers?

Starting from the assumption that you want to read an email header because you want to know who really sent it,

If you don't know how to find out the header of the email then , kindly follow the below document.

http://supportnew.netcore.co.in/supportnew/index.php?/Knowledgebase/Article/View/269/0/how-do-i-view-the-header-information-of-an-email-message

 

                                            Here is the email header of the Example  message 

Full header example

This is a fairly straightforward example of an email sent from a mailing list. Several fields that would normally appear in a header have been omitted so that we can focus on the fields that are most important in troubleshooting. Although certain fields are standard in email headers per the document that defines email standards (RFC 822) there is some variation in the kinds of information that can be added to headers by different mail servers.

Return-Path: <mailinglist@example.org>

Delivered-To: subscriber@example.com

Received: (qmail 12694 invoked from network); 24 Sep 2012 23:18:10 -0000

Received: from server1.example.com (HELO server2) (00.111.222.333) by mailserver.originator_domain.com with mail_application; 24 Sep 2012 23:18:10 -0000

From: <mailinglist@example.org>

To: <mailinglist@example.org>

Subject: Re: Thread

Date: Wed, 24 May 2012 16:17:19 -0700

Reply-To: bounce_handler@example.org

Header fields you should know about

Return-Path

The 'Return-Path' is contained in the envelope header so it is generally not visible when viewing an email. In this case, the originator is a mailing list whose domain name (listname@domain.tld) is 'mailinglist@example.org'.

This field is important because it contains the fully qualified domain name  of the originating sender's email account and cannot be forged. When an email is transferred from the originating  MTA to the first receiving MTA, the receiving MTA checks to see whether the hostname  that has been provided to it by the originating MTA resolves to a unique Internet address. If it does, then it is a fully qualified domain name and the receiving MTA adds the hostname to the 'Return-Path'. If the hostname does not resolve properly, the receiving MTA adds the originating MTA's IP address instead. Even if the 'From:' and 'Reply-to:' fields do not reveal the address of the originator, this information is available in the 'Return-Path' in the message's envelope header.

Delivered-To

The 'Delivered-To' field is contained in the envelope headers so it is generally not visible when viewing an email. This header shows this email was delivered to the mailbox of a subscriber whose email address is 'subscriber@example.com'.

Since email messages generated from mailing lists are addressed to the listname alias, rather than individual subscribers, the 'To:' field in the message header doesn't match the value in the 'Delivered-To' field in the envelope header— so the 'To:' field would contain something like 'listname@example.org' and the 'Delivered-To' field would contain something like bob@marketing.example.com.

Received

A 'Received' field is added to the envelope header for each step of the host-to-host delivery process. The MTA that receives the email adds a 'Received' field with information about the transfer, including the address of the sending MTA, the date and time of the transfer (according to its own 24-hour clock), the length of time it took to process the transfer and the type of email application it used.

From:

This is the message header 'From:' field you see when you view an email message. When you receive an email from another person, the 'From:' field generally contains the person's email address (and name or nickname). When an email is posted to a mailing list, the mailing list software sets the 'From:' field to the listname to protect the private email address of the individual who posted the message.

To:

This is the message header 'To:' field that you see when you view email. In this example, it contains the list address because the message was generated by a mailing list, rather than an individual. If a friend or colleague sent you an email, this field would contain your email address.

This field is similar to the address you'd add to an envelope to send a message through the postal service.

Subject:

This is the message header 'Subject:' field that you see when you view email.

Date:

This is the message header 'Date' field that you see when you view email. It is set by the originating host, so it is not necessarily synchronized with the clocks on other hosts it may have encountered en route.

Reply-To

This field is analogous to the return address on a message you'd send through the postal service. As with hardcopy mail, you must have the addressee's information correctly or the mail may be undeliverable, but you could write anything for the return address and the mail would still be deliverable (if not returnable).

If the message is from another person, their email address will usually appear in this field. If this message is from a mailing list, the 'Reply-To' field will contain the alias for an automated bounce-handler, so that bounced messages are handled properly, rather than being posted to the list and forwarded to all the list subscribers.