|SAMPLE MESSAGE HEADER
|From - Mon Mar 19 08:17:17 2001
Received: from otma1.otm.state.de.us (votma1.state.de.us [22.214.171.124])
by copland.udel.edu (8.9.3/8.9.3) with ESMTP id NAA06271
for <email@example.com>; Thu, 15 Mar 2001 13:10:40 -0500 (EST)
Received: from deljismail1.state.de.us (imail.deljis.state.de.us [172.20.66.11])
by otma1.otm.state.de.us (8.11.0/8.11.0) with ESMTP id f2FIA7t28739
for <firstname.lastname@example.org>; Thu, 15 Mar 2001 13:10:07 -0500 (EST)
Received: from newarkpd.state.de.us [172.20.132.102] by deljismail1.state.de.us with ESMTP
(SMTPD32-5.05) id A8B32701AE; Thu, 15 Mar 2001 13:23:47 -0500
Received: by NEWARKPD with Internet Mail Service (5.5.1960.3)
id <FY66DSJT>; Thu, 15 Mar 2001 13:08:29 -0500
See this information about stopping spam at various stages of the process.
How to view an email message header
The message header is a log of hops that the email message went through to get from the sender to the recipient- at each server or gateway, a timestamp and other information is listed. The email message header is buried within the mail message format and is not usually readily visible. The mail message header is lost if a message is forwarded (and replaced by the current email transactions), thus if you're trying to let someone else view the message header, you'll need to find it and cut and paste the header (gibberish to most folks!) back into an email message that you send.
People want to view message headers usually for one of two purposes:
- Trying to determine the source of spam
- Trying to debug why an email message was delayed (i.e., whodunnit)
Here's a great explanation of headers and how to view them.
For instance in Outlook, open the message (not in the preview pane), View> Options>
And look in the bottom section called "internet headers"
(Finding this in outlook is not all that obvious! "View> Message Header>" is something different, it toggles displaying the From/To/Subj information in your message window. Options is what contains the "internet header" which is more commonly known as the message header.)
This text is selectable live text that you can copy and then paste afresh into a new mail message in order to forward the header information to your tech support person.
Spamnet for Outlook & Outlook Express ($40, PC only) - Once someone
in the spamnet community says a particular source of email
is spam, then it's blocked for everyone. "Blocked" means
outlook moves it to your SPAM folder where you could retrieve a message
filtered in error. No subscription involved.
Inboxer plugin for Outlook ($30) When you declare an email source
to be spam, all further emails of that nature are placed into the
SPAM folder in Outlook.
above are client-side filters and would not filter spam at the server.
These do nothing about viruses, that's a separate topic.
We have not tried these products nor endorse them, they just look interesting.
Here are the headers that are defined by RFC 822:
(see bottom for how to parse the header for spam origins)
FROM / RESENT-FROM
This identifies the person, system, or process that originated the message.
If this field does not contain this information, use the SENDER field.
If it does, then using the SENDER field is both redundant and optional.
In either case, the field must contain machine usable addresses, and
not lists or groups.
SENDER / RESENT-SENDER
This field is used to indicate the author of the message, and is optional
if the information is the same as the FROM field. However, in cases
when then sender did not author the message, or to identify the author
as an individual member of a group, then this field should be used.
When the SENDER field is needed, it should specify the name of the
author, rather than the mailbox from which it was sent. An example
for using the SENDER field would be if a secretary sent email for his
supervisor. The supervisor would be identified in the FROM field, and
the secretary would be identified in the SENDER field.
REPLY-TO / RESENT-REPLY-TO
This field identifies the mailbox(es) to which replies should be sent.
This field differs from the RETURN-PATH field (discussed below) in
that the REPLY-TO field directs replies to a particular mailbox, and
the RETURN-PATH is used by Mail Transfer Agents (MTAs) to identify
a path back to the message originator. If the REPLY-TO field is not
present, the reply address defaults to the address in the FROM field.
TO / RESENT-TO
This identifies the primary recipients) of the message.
CC / RESENT-CC
This field identifies the secondary recipient(s) of the message.
BCC / RESENT-BCC
This field specifies additional recipient(s) of the message, but the
information in this field is not included in the message copy that
is sent to the primary and secondary recipient(s). RFC 822 does not
specify whether the contents of the BCC field appear in the message
copy sent to any other recipients included in the BCC field.
Note that the RESENT- fields are used when a message is forwarded, and
refer to the original recipient of the message. In other words, the FROM
field identifies the author of the message, and the RESENT-FROM field
identifies the recipient that forwarded it.
This information is used to provide an audit trail, and a route back
to the sender. Check The Network Information Center, SRI International,
Menlo Park, CA for the current list of known values registered for
use with "via" and "with". See the discussion of
the RECEIVED field below.
Used by the final MTA to identify the path back to the message originator.
This is a dynamic field used by the MTAs to record the path taken to
deliver the message. Each MTA adds to this field as the message traverses
its path to the recipient(s). The field can contain both the sending
and receiving hosts, as well as the time the message was received.
Details such as the physical components (using "via"), and
protocols ("with") may be included. If the address is expanded
or reinterpreted, such as expanding a group list, then "for" may
also be included.
MESSAGE-ID / RESENT-MESSAGE-ID:
Identifies a particular version of a particular message, and is guaranteed
to be unique by the host that generates it. If additional revisions
of the message are created, they will receive another, unique, ID.
Identifies the correspondence to which the current message replies.
If the message references other correspondence, the references would
A comma delimited field of keywords or phrases
A summary, or an indication of the contents of the message
This field allows comments to be added to a message without altering
the original message.
The two <word> parameters of this field are used to identify the
software that encrypted the body and, optionally, to help the recipient
to select the proper decryption key. Note that headers must remain accessible
to the MTAs that use the information to relay the message. Therefore,
header information is never encrypted. Care must be taken if the headers
contain addresses or SUBJECT lines that include sensitive information.
This field is used for any extension field registered with The Network
Information Center. The names of any extension will never begin with "X-".
This field may be used to define additional headers for individual users.
All user-defined information must begin with "X-", to distinguish
it from standardized extension field names registered with The Network
Parsing the Message Header Information
As a mail server processes a message, it adds a special line, the Received:
line to the message's header. The Received: line contains, most interestingly,
server name and IP address of the machine the server received the message
the name of the mail server itself.
The Received: line is always inserted at the top of the message headers.
If we want to reconstruct an email's journey from sender to recipient we
also start at the topmost Received: line (why we do this will become apparent
in a moment) and walk our way down until we have arrived at the last one,
which is where the email originated.
Received: Line Forging
Spammers know that we will apply exactly this procedure to uncover their
whereabouts. To fool us, they may insert forged Received: lines that point
to somebody else sending the message.
Since every mail server will always put its Received: line at the top,
the spammers' forged headers can only be at the bottom of the Received:
line chain. This is why we start our analysis at the top and don't just
derive the point where an email originated from the first Received: line
(at the bottom).
How to Tell a Forged Received: Header Line
The forged Received: lines inserted by spammers to fool us will look like
all the other Received: lines (unless they make an obvious mistake, of
course). By itself, you can't tell a forged Received: line from a genuine
This is where one distinct feature of Received: lines comes into play.
As we've noted above, every server will not only note who it is but also
where it got the message from (in IP address form).
We simply compare who a server claims to be with what the server one notch
up in the chain says it really is. If the two don't match, the earlier Received: line has been forged.
this case, the origin of the email is what the server immediately after
the forged Received: line must say about whom it got the message from.