Tracking E-mail – Part 1

Using e-mail header information to track the sender

Nearly everyone who has an Internet e-mail account has received unsolicited commerical e-mail (UCE), commonly referred to as junk mail or spam.

A one-time Forrester Research survey showed that about 10 percent of consumers responded to e-mail messages, with a quarter of those actually buying something. Another Forrester survey of e-mail marketing managers found that the e-mail marketing industry will generate some US $4.8 billion by 2003 and they plan to triple their e-mail spending by 2004, and that by 2004, the marketers will send almost 210 billion e-mail messages which means the average US household will get 9 pieces of unwanted or unexpected e-mail solicitations a day. Maybe you have wondered if there isn’t something you can do besides simply deleting it.

You might also want to trace e-mail because somebody sent you a threatening or malicious piece of hate mail from a fake address. Many methods can be employed to trace e-mail. These methods do not work in 100% of the situations nor are they guaranteed for tracing e-mail. However, if you are willing to do some detective work and learn a few things about e-mail headers, then you can be successful in your trace.

There are some tools required that you’ll need before you launch your tracing campaign:

  • ping (Packet InterNet Groper) is a protocol and program for sending a signal to see whether another network host or other device is online and responding. The term is normally used as a verb in “Ping [host] to see if it is up!”
  • traceroute sends small packets of information which are designed to return information to the sender every time the packet encounters a new server. These small messages expire after a short period of time. The information they send you allow tracking of their progress towards the Internet Protocol IP address they are sent to, returning the name and IP address of each server and the time it took to get there.
  • nslookup is an interactive program to query Internet domain name servers. The user can contact servers to request information about a specific host or print a list of hosts in the domain. It provides a translation between names and IP addresses and vice versa. That is, you can lookup a domain name and get the IP address or you can lookup an IP address and get the domain name.
  • whois is used to lookup the full name, mailing address, telephone number, and network mailbox for owner, administractive and technical contacts for the hosts/domains/IP addresses registered in one of the Domain name Registrar databases. Also used to find the domain name and IP address of the two required domain name servers.
  • finger displays information about each logged-in user, including his or her login name, full name, terminal name, idle time, login time, and location if known.
  • dig (Domain Information Groper) is a flexible command line tool which can be used to gather information from the Domain Name System servers.
  • host Host command prints information about specified hosts in Domain Name System servers.

Some of these tools can be found on your UNIX shell account or as part of Windows 9X. If you are a Windows 9X user you can download SamSpade, CyberKit or NetLab free of charge.

If you don’t want to download these programs, Julian Byrne’s “Get That Spammer” and Sam Spade make these tools available online.

Just as a letter makes stops at different postal stations along its way, e-mail passes from one computer, to another as it travels over the Internet. To help you trace e-mail, an explanation of this e-mail process is included.

Also included is a description of Common E-mail Headers that you will probably see as you begin to trace different pieces of e-mail. You will also begin to recognize many of these after you look at enough e-mail headers. RFC2076 also lists and explains more Common Internet Message Headers.

For a list of mailbox names for common services, roles and functions, see RFC2142. This can be used when contacting personnel at an organization. For example, using the abuse address.

Address faking and forging

Analysis of a spam message 1

Analysis of a spam message 2

Sample traces NOT COMPLETE

[(Top of page)]

E-mail Process

Adapted from a posting to the Procmail mailing list by Alan Stebbens Fri, 09 Aug 1996 13:19:52 -0700

To help clarify E-mail headers, here’s a diagram of the E-mail process and its several steps:

sender -> MUA -> MTA -> (routing) -> MTA -> MDA -> {filtering} -> MUA -> receiver
[1]       [2]    [3]                        [4]                   [5]    [6]
MUA
Mail User Agent — The program run by the user to read, reply to, compose and dispose of electronic mail (E-mail) messages. The MUA provides the interface between the user and the Message Transport Agent (MTA). Outgoing mail is handed over to an MTA for delivery while the incoming messages are picked up from a Mail Delivery Agent (MDA). Example of MUAs include the original UNIX mail program, /bin/mail, the Berkely Mail program and it’s System V equivalent mailx, software programs like mush, elm, mutt, mh, Pine, Pegasus, and commerical programs like Eudora.
MTA
Mail Transport Agent or Message Transfer Agent — The program responsible for storing and forwarding or delivering E-mail messages. Upon receiving a message from an MUA or another MTA it stores it locally and temporarily for analysis of the recipients and either delivers it to a local addressee or forwards it to another MTA. In either case it may edit and/or add to the message headers. It is usually referred to as the “mail server program.” An example of this is UNIX sendmail or others including mmdf, smail, ZMailer, Exim, and Microsoft Exchange Server.
MDA
Mail Delivery Agent — the actual program responsible for delivering mail to a user. MDAs usually handle one specific type of mail delivery. On UNIX systems this is typically the program /bin/mail, which is responsible for placing E-mail into a user’s local mailbox file. Other MDAs include: uux for delivering UUCP mail; Procmail for advanced filtering of mail before delivery or maildrop which reads a mail message from standard input, then delivers the message to your mailbox.

Headers typically are provided by a “template” from the MUA to the sender when composing E-mail, usually during step [1]: See RFC2822

From:               # who is the sender
To:                 # who gets this mail
Cc:                 # people to keep informed, but need not respond
Bcc:                # other people to keep informed, keep secret
Subject:            # what the mail is about
Reply-To:           # added by originator to direct replies
Priority:           # try to influence speed and delivery
Precedence:         # set ordering in queue
Resent-To:          # used for redirecting (forwarding) E-mail
Resent-Cc:          # ditto
X-[something]:      # personalized headers

When the sender is done composing, and says “send it” to their mailer, some additional headers may get inserted by the MUA at step [2]: See RFC2045 for MIME (Multipurpose Internet Mail Extensions).

Date:               # day month year or dd mm yy hh:mm:ss zzz
Resent-Date:        # if being redirected (forwarded)
From:               # actual submittor
Sender:             # if a From: is already present
X-Mailer:           # what MUA composed this message
Mime-Version:       # if using a MIME capable mail program
Content-Type:       # type and subtype of data in message
Content-Transfer-Encoding:       # describe data type in message

When the MTA receives the E-mail from the MUA at step [3], it may insert additional headers showing the origination of the E-mail:

From                # if local E-mail, automatic or by filter options
Date                # if not already present
Message-Id:         # unique ID for the E-mail; the first MTA creates this
Received:           # trace routing of mail
Return-Path:        # shows how to get back to the sender

As each MTA hands off the E-mail, additional headers may get added, all as part of the MTA to >MTA hand-off in step [3]:

Received:           # inserted by each MTA for each message relay

As the final MTA hands the E-mail to a MDA, in step [4], there are still some more header insertions which may occur:

Apparently-To:      # added if no To: header exists
From                # may get added if local E-mail

Some sites insert special rewrite rules and mail filtering to occur to support virtual domains, and these header changes will occur at step [5], just before the incoming mail is dropped. Generally though, no new headers are added, except possibly by procmail to avoid loops, sort e-mail or auto-respond to a sender’s e-mail request:

X-Loop:             # inserted to avoid filtering loops

Finally, at step [6] when the reader views their E-mail, most MUAs will apply a filter to the stored mail causing selected headers to be omitted from the display. In a sense then, this filtering “removes” the headers from the user’s view (although no headers are actually removed by the MUA).

Example from Eudora before full header display:

Reply-To: "Somebody" <SomeReplyAddr@somplace.com>
From: "Somebody" <somebozo@yahoo.com>
To: <gboyd@expita.com>
Subject: Test message
Date: Fri, 2 Mar 2001 12:04:31 -0800
Organization: SomeOrganiztion
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

Test message!!

The headers typically omitted are those inserted by the MTAs, and those having to do with the transport process and less with the contents.

Example from Eudora after full header display:

Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f22K5xv12202
        for <gboyd@expita.com>; Fri, 2 Mar 2001 15:05:59 -0500 (EST)
Received: from pacer2 (hsa184.pool015.at101.earthlink.net [216.249.86.184])
        by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA14914
        for <gboyd@expita.com>; Fri, 2 Mar 2001 12:05:58 -0800 (PST)
Message-ID: <001301c0a353$feb287e0$a64cfea9@pacer2>
Reply-To: "Somebody" <SomeReplyAddr@somplace.com>
From: "Somebody" <somebozo@yahoo.com>
To: <gboyd@expita.com>
Subject: Test message
Date: Fri, 2 Mar 2001 12:04:31 -0800
Organization: SomeOrganiztion
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Status: RO

Test message!!

[(Top of page)]

Common E-mail Headers

Header fields are NOT required to occur in any particular order, except that the message body must occur AFTER the headers. It is recommended that, if present, headers be sent in the order “Return- Path”, “Received”, “Date”, “From”, “Subject”, “Sender”, “To”, “cc”, etc. (RFC2822)

Apparently-To: Inserted by sendmail when there is no “To:” recipient in the original message. This causes the recipients derived from the envelope to be listed in the message heading. This behavior is not quite proper, MTAs should not modify headers (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients. Non-standard header that is discouraged in use, mentioned in RFC1211.

Apparently-To: gboyd@expita.com

Approved-By: Name of the moderator of the mailing list to which this message is sent; necessary on a posting sent to a moderated mailing list to allow its distribution to the list members. Non-standard for use in e-mail. Defined in RFC1036.

Approved-By: gboyd@expita.com

Bcc: (“Blind Carbon Copy”) A copy of the mail message that is sent to one or more recipients without the knowledge of the primary recipients. Primary recipients are listed in the To: and Cc: lines. This is useful if you want to copy a message to many people without each of them seeing who the other recipients are. If you see this header on incoming mail, something is wrong because it does not appear in the headers.

Cc: (“Carbon Copy”) This header can be considered an extension of the “To:” field as it is used to specifiy additional recipients. In this case, the copy of an e-mail message sent to a recipient has the recipient’s address appearing in the message. This is useful if you want to copy a message to many people with each of them seeing who the other recipients are; contrast with Bcc above. This header does appear in incoming e-mail.

Cc: gboyd@netcom.com

Comments: This is a free-form header field defined in RFC2822. The header is used to place explanatory text into the header portion of an e-mail message. The field may contain arbitrary text.

Pegasus mail adds a modified version of the Comments: field with an Authenticated sender. However, this is non-standard so you cannot rely on the authentication.

Comments: Authenticated sender is gboyd@netcom.com

The Comments: Authenticated sender is <userid@domain> is an attempt by your POP3 (Post Office Protocol version 3 – defined in RFC1939) mailer daemon to resolve the sender’s address. Don’t be fooled by “Authenticated sender” messages. They are easily faked and mean nothing. They don’t “authenticate” anything. It’s just an attempt to resolve an address. Some are valid, some are not.

Content-Type: The second of three MIME headers that generally is found. The “Content-Type” defines the format of content (character set etc.) Note that the values for this header are defined in different ways in RFC1049 and in MIME (RFC2045). Look for the MIME-version: header to understand if Content-Type is to be interpreted according to RFC1049 or according to MIME (RFC2045). The MIME definition should be used in generating mail.

Historically, Content-Type field was proposed in RFC1049. In it, Content-Type did not distinguish type and subtype like RFC2045 does.

Content-Type: text/plain; charset="us-ascii"
Content-type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset="iso-8859-1"
Content-Type: text/plain; charset=koi8-r
Content-Type: text/plain; charset=unknown-8bit

ISO-8859-1 (International Organization for Standardization (ISO), “Information Processing — 8-bit Single-Byte Coded Graphic Character Sets — Part 1: Latin Alphabet No.1”, ISO 8859-1:1987) is a MIME character set (charset) for west-European languages written by Latin script. It is an 8bit coded character set based on ISO 2022 and is defined in RFC2046.

ISO 8859 consists of the following parts, under the general title Information technology – 8bit single-byte coded graphic character sets:

  1. Latin 1 (West European)
  2. Latin 2 (East European)
  3. Latin 3 (South European)
  4. Latin 4 (North European)
  5. Cyrillic alphabet
  6. Arabic alphabet
  7. Greek alphabet
  8. Hebrew alphabet
  9. Latin 5 (Turkish)
  10. Latin 6 (Nordic)
  11. Thai alphabet
  12. unassigned
  13. Latin 7 (Baltic)
  14. Latin 8 (Celtic)
  15. Latin 9 (Updated Latin 1)
  16. Latin 10 (Updated Latin 2)

See Michael Everson’s ISO/IEC 8859-16: Latin Alphabet No. 10 document.

Most Microsoft Windows users and programs use ISO-8859-1.

koi8-r is a Russian character more widely used than IS0-8859. It is also common on Russian Internet sites and is described in RFC1489.

The default media type of “text/plain; charset=us-ascii” for Internet mail describes existing Internet practice. That is, it is the standard coded character set of Internet mail defined by RFC2822. It is a 7bit coded character set based on ISO 2022 and contains only ASCII, no code extensions are allowed. If a MIME charset is not specified, US-ASCII is used as default.

Other registered media types can be found at Media Types.

The first registered Character sets and IETF Policy on Character Sets and Languages define improvements over US-ASCII.

Content-Transfer-Encoding: The third of the MIME-related headers. Indicates the coding method used in a MIME message body. It has no direct relevance to the delivery of mail, but it affects how MIME compliant mail programs interpret the content of the message. Defined in RFC2045.

Content-Transfer-Encoding: 8bit
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable

The Base64 Content-Transfer-Encoding is an encoding method defined in the MIME standard RFC2045. It is designed to represent arbitrary sequences of 8-bit data in a form that need not be humanly readable. Note the difference from “quoted-printable” discussed below. Typically, this coding will be used with all binary file types (.EXE, .ZIP, .AVI, .BMP, etc.) and foreign language character sets (charset) such as Chinese Big5 and Japanese.

MIME-Version: 1.0
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: base64

PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8dGl0bGU+Zmx5c2hvc2U8L3RpdGxl
Pg0KPC9oZWFkPg0KDQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4N
CjxkaXYgYWxpZ249ImNlbnRlciI+DQoNCjxwPg0KPG9iamVjdCBjbGFzc2lkPSJjbHNpZDpE
[snip]

Quoted-printable is an encoding method defined in the MIME standard RFC2045. It is used primarily to encode 8-bit text (such as text that includes foreign characters) into 7-bit US ASCII, creating a document that is mostly readable by humans, even in its encoded form. All MIME compliant applications can decode quoted-printable text, though they may not necessarily be able to properly display the document as it was originally intended.

Quoted-printable encoding currently implemented by Microsoft has the annoying habit of not encoding printable ASCII characters (values 33 through 126, excluding 61), tabs and spaces that do not appear at the end of lines, and end-of-line characters. Other characters are represented by an equal sign (“=”) immediately followed by that character’s hexadecimal value. Lines that are longer than 76 characters are shortened by line breaks, with the equal sign marking where the breaks occurred. For more information, see the Knowledge Base articles Q146629 Microsoft Exchange Internet Mail Lines End with a “=” and Q168779 OLEXP: No Quote Characters When Using Quoted Printable Format.

7-bit coding was the original method for sending e-mail. The SMTP (Simple Mail Transfer Protocol – RFC2821) data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero.

Date: This header specifies a date (and time), normally the date the message was composed and sent. In X.400 mail systems, the time a message was submitted. Some Internet mail systems also use the date when the message was submitted. If this header is omitted by the sender’s computer, it might conceivably be added by a mail server or even by some other machine along the route.

What you may not know is that the information in the “Date:” line is supplied by the time on the sender’s computer, which may or may not be set correctly. Also, the “Date:” header does not normally indicate when the message was sent, but only when it was composed.

The date is in the form 3 character day-of-week (Sun – Sat), day number (1-31) dd, 3-character month name, 4-digit year yyyy, followed by time (24-hour) hh:mm:ss and zone zzz format. Time Zone (zzz) is either the 3-character time zone or the local differential in hours and minutes offset from UTC (Universal Time Coordinated – old Greenwich Mean Time). “-” indicates west and “+” indicates east of UTC.

No standard Time Zone definitions seem to exist. Many UNIX versions understand a great range of abbreviations, but the most exhaustive list I found was the GNU tar manual Timezone item and documentation for the Perl date manipulation module TIMEZONES.

Date: Tue, 9 Jan 2001 23:40:00 -0800
Date: Sun, 1 Apr 2001 22:52:04 EDT
Date: Mon, 2 Apr 2001 16:02:19 +0200
Date: Fri, 30 Mar 2001 10:47:15 -0800

Errors-To: This is a non-standard RFC2822 message header added by sendmail and other e-mail clients.

Ordinarily, errors are bounced to the envelope sender. The “Errors-To:” header specifies the address, or addresses, to which sendmail should send additional notification of delivery errors. This header is intended for use by mailing lists, in order to prevent errors in a list from being resent to the list as a whole.

On mailing lists, the From: header allows replies to be submitted for distribution to the mailing list. If an arror is detected, we want it to be handled by someone other than the list.

This header is also used for reporting of errors in USENET postings to the source of the posting.

Internet standards recommend the use of RCPT TO and Return-Path, not Errors-To, for where delivery notifications are to be sent.

From (without colon) This is the “envelope From” and should never appear in e-mail being sent. This header is used in the so-called UNIX mailbox format, also known as Berkely mailbox format or the MBOX format. This is a format for storing a set of messages in a file. A line beginning with “From “(note space) is used to separate successive messages in such files. Thus, this header will appear when you use a text editor to look at a file in the UNIX mailbox format. Some mailers also use this format when printing messages on paper.

The information in this header should NOT be used to find an address to which replies to a message are to be sent.

However, this header is used in USENET News mail transport (See RFC0976) to indicate the path through which an article has gone when transferred to a new host. It is sometimes called the “From_” header.

This is header is inserted automatically by MTAs, unless one is already present and only then if it seems valid.

From: (with colon) This is the “message From:”. This field contains the identity of the person(s) who wished this message to be sent. The message-creation process should default this field to be a single, authenticated machine address, indicating the AGENT (person, system or process) composing the message. If this is not done, the “Sender:” field MUST be present. If the “From:” field IS defaulted this way, the “Sender:” field is optional and is redundant with the “From:” field.

From: "Gerald E. Boyd" gboyd@expita.com

The second “From:” is generated by the MUA (your personal mailer), either by configuration, or by the user. The rewrite rules in sendmail and most filtering programs concern themselves with the “From:”, “To:”, “Cc:”, and “Reply-To:” headers.

Followup-To: Not standardized for use in e-mail. Defined in RFC1036 for used in USENET News to indicate that future discussions (follow-ups) on an article should go to a different set of newsgroups than the replied-to article. The most common usage is when an article is posted to several newsgroups, and further discussions is to take place in only one of them.

In e-mail, this header may occur in a message which is sent to both e-mail addresses and USENET News, to show where follow-up in USENET news is wanted. The header does not say anything about where follow-up in e-mail is to be sent.

Note that the value of this header must always be one or more newsgroup names, never an e-mail addresses.

In-Reply-To: Reference to message which this message is a reply to. The contents of this field identify previous correspondence which this message answers. Note that if message identifiers are used in this field, they must use the “Message-ID:” specification format.

In-Reply-To: <75437062.984144269@orangebrain>
   of Fri, 09 Mar 2001 13:24:29 -0500
In-Reply-To: <200103110322.WAA28920@listserv.aol.com>
In-Reply-To: <000b01c0aa2f$28426a80$21142ed8@win98>

Message-ID: (also Message-Id: or Message-id:) This field is like a serial number and contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one particular message; subsequent revisions to the message should each receive new message identifiers. sendmail constructs the field from the data, the time, a unique file name, and the originating machine name.

Message-ID: <02ba01c07ad8$898fc840$c900000a@checkoway.com>
Message-ID: <d5.4731683.27f94354@aol.com>
Message-ID: <3AC8A28B.27099.198FF5E1@localhost>
Message-Id: <3.0.5.32.20010330104715.007ac100@lineuponline.com>
Message-ID: <9377.010228@busk.cc.lv.ukrtel.net>

MIME-Version: (also Mime-Version:) The first of usually three MIME related message headers. An indicator that this message is formatted according to the MIME standard and indicating which version of MIME is utilized. Originally defined in RFC1521 and obsoleted by RFC2045.

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

Newsgroups: In USENET News (defined in RFC1036), the group(s) to which this article was posted. Some systems provide this header also in e-mail although it is not standardized there. Unfortunately, the header can appear in e-mail with two different and contradictory meanings:

  1. Indicating the newsgroup recipient of an article/message sent to both e-mail and USENET News recipients.
  2. In a personally addressed reply to an article in a newsgroup, indicating the newsgroup in which this discussion originated.

This header only appears in e-mail that is connected with USENET — either e-mail copies of USENET postings, or e-mail replies to postings.

Newsgroups: comp.mail.misc,news.admin.net-abuse.email
Newsgroups: mindspring.users.shell

Organization: A completely free-form header that normally contains the name of the organization to which the sender of this article belongs. Defined in RFC1036 but is a non-standard header for use in e-mail.

Organization: ivolio Corporation
Organization: WorldAccess
Organization: People Who Are Not Old Enough For UNIX (Honorary Member Emeritus)
Organization: The University of New England, Armidale, Australia.

Precedence: Sometimes used as a priority value which can influence transmission speed and delivery. Common values are “bulk”, “junk”, and “first-class”. Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops. This is a non-standard controversial header that is discouraged from use.

Most common programs using or creating this header are sendmail, Eudora e-mail, Majordomo mailing list manager (MLM), and Procmail. The UNIX vacation program uses it to skip replies to messages, Eudora uses it for filtering e-mail, Majordomo adds it to outgoing messages (to prevent accidental mail loops), and Procmail users add it to their autoresponders.

Precedence: bulk

Priority: An essentially free-form header that assigns a priority to the mail. Most software ignores it. Can be “normal”, “urgent” or “non-urgent” and can influence transmission speed and delivery. Defined in RFC1327, not for general usage.

Priority: normal

Received: A copy of this field is added by each MTA that relays the message. The information in the field can be quite useful for tracing problems. The names of the sending and receiving hosts and time-of-receipt may be specified. The “via” parameter may be used, to indicate what physical mechanism the message was sent over and the “with” parameter may be used to indicate the mail-, or connection-, level protocol that was used, such as the SMTP mail protocol, or X.25 transport protocol.

Note: Several “with” parameters may be included, to fully specify the set of protocols that were used. Some MTAs queue mail; the internal message identifier that is assigned to the message may be noted, using the “id” parameter. When the sending host uses a destination address specification that the receiving host reinterprets, by expansion or transformation, the receiving host may wish to record the original specification, using the “for” parameter. For example, when a copy of mail is sent to the member of a mailing list, this parameter may be used to record the original address that was used to specify the list.

The general format of a Received: line is [“from” sending host] “by” receiving host [“via”network, the physical path] [“with” link/mail protocol] “receiver unique id” string [“for recipent” address] “;” date

Optionally you can think of it as Received from Named Server([sending server IP address]) by Receiving server (receiving server software)

Received: from Randy ([65.166.2.47])
    by no2.superb.net (8.11.1/8.11.1) with SMTP id f3LKU6b07804
    for <gboyd@expita.com>; Sat, 21 Apr 2001 16:30:06 -0400 (EDT)

References: The contents of this field identify other correspondence which this message references. Note that if message identifiers are used, they must use the “msg-id” specification format. The References: header used in e-mail to reference to other related messages and in USENET News to reference to replied-to-articles. Its use on USENET is to identify the “upstream” posts to which a message is a response; when it appears in e-mail, it’s usually just a copy of a USENET header. It may also appear in e-mail responses to USENET postings, giving the message ID of the post being responded to as well as the references from that post.

References: <01a901c0a72a$42237960$610ca8c0@hostel1.giki.edu.pk>
References: <OIBBLIKONCNJJLNLJLPJCEEOCOAA.linda@personal-computer-tutor.com>

Reply-To:The Reply-To: header forces replies to messages to go to an address that is different than that of the original sender. This header is usually inserted by mailing list software, where the “From:” is the address of the original sender or mailing list, and the Reply-To: is the address of the mailing list or list’s maintainer.

Reply-To: ACCMAIL Discussion List <ACCMAIL@LISTSERV.AOL.COM>
Reply-To: pcworks@imagicomm.com
Reply-To: <data@downloadslave.com>
Reply-to: Internet Help Resource <HELP-NET@crcvms.unl.edu>
Reply-To: swalert@VNET.IBM.COM
Reply-To: scs@eskimo.com (Steve Summit)
Reply-to: Ann.Tothill@pixie.co.zae

This header is meant to indicate where the sender wants replies to go. Unfortunately, this is ambiguous, since there are different kinds of replies, which the sender may wish to go to different addresses. In particular, there are personal replies intended for only one person, and group replies, intended for the whole group of people who read the replied-to message (often a mailing list, a newsgroup name cannot appear here because of different syntax, see “Followup-To”).

Some mail systems use this header to indicate a better form of the e-mail address of the sender. Some mailing list programs put the name of the list in this header. These practices are controversial.

Return-Path: Intended to show the envelope address of the real sender as opposed to the sender used for replying (the “From:” and “Reply-To:” headers) Defined in RFC2821 and RFC1123.

When posting to USENET news, the “Return-Path:” shows news and the “From:” shows the address of the posting user. In General, “Return-Path:” should never be used for replying to mail. It is soley intended to be used for notification of delivery errors.

sendmail and UNIX Pine both use this header.

Return-Path: <gboyd@expita.com>
From: "Gerald E. Boyd" <gboyd@expita.com>
X-Sender: gboyd@no2.superb.net

Sender: The person or agent submitting the message to the network, if other than shown by the From: header. Normally inserted by mailing list software but appears especially in copies of USENET posts. It should identify the sender in the case of USENET posts, it is a more reliable identifier than the “From:” line.

Sender: ACCMAIL Discussion List <ACCMAIL@LISTSERV.AOL.COM>
Sender: owner-pcworks@imagicomm.com
Sender: owner-faq-maintainers@landfield.com

Status: Status is a non-standard RFC2822 message header added by Eudora and other e-mail clients after message delivery to indicate the status of delivery for this message when stored. Common values of this field are:

  • U message is not downloaded and not deleted.
  • R message is read or downloaded.
  • O message is old but not deleted.
  • D to be deleted.
  • N new (a new message also sometimes is distinguished by not having any “Status:” header.

Combinations of these characters can occur, such as “Status: RO” to indicate that a message is downloaded but not deleted.

Status: RO
Status:

Subject: A completely free-form field specified by the sender, intended, of course, to describe the subject of the message.

Subject: Doing everything via e-mail

To: This header line is used to indicate the primary recipient(s) of the message. One of the standard headers defined in RFC2822 and RFC1123.

Usually a name will precede the actual address, though this is not required. The “To:” line may also contain more than one address, each separated by a comma. In this case, the e-mail will be delivered to each address listed in this line, as well as the “Cc:” line and the otherwise invisible “Bcc:” line (see Cc: and Bcc:) There really is no functional difference between an address contained in the “Cc:” or “To:” lines of an e-mail message. Note that the “To:” header need not contain the recipient’s address if the message is sent to members of a mailing list.

To: <ACCMAIL@LISTSERV.AOL.COM>
To: pcworks@imagicomm.com
To: faq-maintainers@faqs.org
To: "Gerald E. Boyd" <gboyd@netcom.com>
To: gboyd@netcom.com

A blank “To:” header is almost always a sure sign of spam. Many of the spam e-mail programs leave the “To:” field blank (or use a bogus address) and include all the persons to be “spammed” on the “Bcc:” line.

The formats allowed are:

  • “Gerald E. Boyd” <gboyd@netcom.com> [quotes if names contain special characters]
  • Gerald Boyd <gboyd@netcom.com> [names and address]
  • <gboyd@netcom.com> [address in carets]
  • gboyd@netcom.com [address only]

X-headers The “X-” prefix is used to create custom headers that are legal under RFC2822 but are non-standard and provided for information only. Conversely, any non-standard informative header should be given a name starting with “X-“.

X-Envelope-From: steveha@NET-SERVICES.COMPULINK.CO.UK

X-Apparently-From: and X-Apparently-To: Added by eGroups (now Yahoo groups) to postings in an attempt to identify the mailing list group the message belongs to and also to identify the sender. AOL and Yahoo among others also add the X-Apparently-From: header.

X-Confirm-Reading-To: Pegasus Mail was the first e-mail program to use this non-standard directed confirmation header field. “The Bat!” mail client and Exim MTA system filter also support this header. This header requests an automated confirmation notice when the message is received or read. Typically it is ignored by almost all e-mail programs including Pegasus mail.

The reason for this is that the old confirmation header field X-pmrqc: was implemented and most Pegasus mail versions respond to it as best as they can.

X-pmrqc: 1

The RFC standard header for automated confimation is “Disposition-Notification-To” (RFC2298). Outlook, Netscape and Eudora and most MIME aware e-mail programs use this.

X-Distribution: Pegasus Mail now adds one of three new headers to messages it sends when more than 50 recipients are present in the message. These headers can be used as filtering triggers to delete such messages. The headers are based on the number of recipients, and are as follows:

  • 0-50 recipients – no added header
  • 50-499 recipients – “X-Distribution: Moderate”
  • 500-4999 recipients – “X-Distribution: Bulk”
  • 5000+ recipients – “X-Distribution: Mass”

X-Envelope-To: added by sendmail version 8 to specify the actual recipient when using a multidrop mailbox (multiple users in a virtual domain that go to a single mailbox).

X-Errors-To: Like Errors-To: this header specifies an address for errors to be sent to. It is rarely seen except for some ftpmail servers and News mailing services.

X-Errors-To: usenet@LITech.NET
X-Errors-To: sr1@inf.tu-dresden.de

X-Mailer: (also X-mailer:) A freeform header field intended for the e-mail software to identify itself. Most Windows e-mail clients identify the e-mail program, version number, and other information.

X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational
X-Mailer: The Bat! (v1.023) S/N 26756776
X-Mailer: FEddy 1.3
X-Mailer: Juno 2.0.11
X-Mailer: Mutt 0.91.1i
X-Mailer: Mozilla 3.01 Gold (Win16; I)
X-Mailer: Mozilla 4.05 [en] (Win95; I)
X-Mailer: Mozilla 4.05 [de]C-QXW03103 (WinNT; I)
X-Mailer: Mozilla 4.5 (Macintosh; U; PPC)
X-Mailer: Pegasus Mail v3.40 (NDS)
X-Mailer: Pegasus Mail for Windows (v2.53/R1)
X-Mailer: Pegasus Mail for Win32 (v3.12b)
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
X-Mailer: Microsoft Outlook Express 4.72.3007.0
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
X-Mailer: Microsoft Mail V3.0

X-MIME-Autoconverted: This is handled by LISTSERV mailing list program. Starting with version 1.8d of LISTSERV, if you include 8-bit characters (e.g., accented or national language characters) in templates, LISTSERV will automatically encode the templates on-the-fly in MIME quoted-printable encoding. While there is no guarantee that every mail program will be able to properly display 8-bit characters, those mail programs that understand MIME quoted-printable encoding should have no trouble doing so.

Sendmail also converts from 8bit to Base64 or quoted-printable (depending on which is shorter for the particular message) and inserts this line in the header if the receiving MTA doesn’t specify 8BITMIME according to “SMTP Service Extension for 8bit-MIMEtransport” RFC1652 in the reply to EHLO command of SMTP or ESMTP protocols.

X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.ops.aol.com id PAA01630
X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.aol.com id RAA07
X-MIME-Autoconverted: from 8bit to quoted-printable by cygnus.com id LAB09233
X-MIME-Autoconverted: from quoted-printable to 8bit by lista.sulinet.hu id SAA01538

X-PMFLAGS: Pegasus Mail adds this header to any message sent. The number after the keyword is a hexadecimal number and contains information about whether the mail was already read, the color the mail is displayed, whether this mail has been answered and other items.

X-PMFLAGS: 34078848 0
X-PMFLAGS: 33554560 0
X-PMFLAGS: 34078848 0
X-PMFLAGS: 570949760 0

X-Priority: Used mainly by Eudora to assign a priority (which appears as a graphical notation on the message) to incoming and outgoing messages. There are five priority levels available, 1 being the highest, 5 being the lowest. Priority 3 is Normal.

X-Priority: 3 (Normal)

X-Sender: This header is used by Eudora and Pine to identify the sender with greater reliability than the “From:” header.

X-Sender: gboyd@netcom.com
From: "Gerald E. Boyd" <gboyd@netcom.com>

When the senders SMTP or POP3 server address differs from the actual server used to send the e-mail. Eudora adds an “(Unverified)” to the senders e-mail address.

X-Sender: gboyd@netcom.com (Unverified)

UNIX Pine always adds this when you send e-mail from a virtual domain. It shows the actual SMTP server address that e-mail was sent from as compared with the users actual e-mail address.

From: "Gerald E. Boyd" <gboyd@expita.com>
X-Sender: gboyd@no2.superb.net

X-UIDL: The X-UIDL header is standard with POP3 mail servers and clients. It’s defined in RFC1725. But it’s not an RFC2822 standard header, therefore, it’s still an “X” header.

The X-UIDL header is added by the POP3 mail server to give it a unique message ID. This unique identifier is used by the POP3 protocol for retrieving mail from a POP3 mail server. The field is added at your location just before you recieve the message. It’s not from the sender. Valid ones have exactly 32 hexadecimal characters. They are generated by an algorithm involving the date and time to arrive at a unique ID.

X-UIDL: 46b42c1a4222b127e2eec3046603285c
X-UIDL: e3a131b31956ffc5606e25f1dc6e3444

Different “X-” and other headers I’ve seen

Encoding: 31 TEXT
Importance: Normal
X-FTN-CHRS: LATIN-1 2
X-MSMail-Priority: Normal
X-Msmail-Priority: Normal
X-Priority: 3
X-Priority: 3 (Normal)

[(Top of page)]

Address faking and forging

The purpose of this web page is to present steps that can be used to trace e-mail. All of the messages used in this analysis are real messages that were sent to me or sent by me for test purposes. In some places addresses have been changed to protect the senders identity.

Address faking or forging can be done quite easily, simply by changing “Real name”, “Return address” and the “SMTP server” in Eudora. You could also change the “Name”, “Organization”, “E-mail address” and “Reply address” in Outlook Express. In other e-mail clients you could change the “Sender” and “Return-to” fields to something different. You can do this, since these fields, i.e. your identity, are normally not checked by the mailserver when you send mail, but only when you receive mail.

Test message sent using Outlook Express with a faked “Name:”, “Organization:”, “E-mail adddress:” and “Reply address:”.

Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f22K5xv12202
        for <gboyd@expita.com>; Fri, 2 Mar 2001 15:05:59 -0500 (EST)
Received: from pacer2 (hsa184.pool015.at101.earthlink.net [216.249.86.184])
        by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id MAA14914
        for <gboyd@expita.com>; Fri, 2 Mar 2001 12:05:58 -0800 (PST)
Message-ID: <001301c0a353$feb287e0$a64cfea9@pacer2>
Reply-To: "Somebody" <SomeReplyAddr@somplace.com>
From: "Somebody" <somebozo@yahoo.com>
To: <gboyd@expita.com>
Subject: Test message
Date: Fri, 2 Mar 2001 12:04:31 -0800
Organization: SomeOrganization
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Sorted: Default
Status: RO

Test message!!

Here is a spoof I sent to myself using telnet to port 25 on a remote server. This was done from my Netcom shell account.

The SMTP (Simple Mail Transport Protocol) is just a simple list of commands that you execute using any telnet application.

Using the telnet application,log onto your SMTP server (it’s address is in your e-mail program settings) or another server and this time for port enter number 25, which is the common port number used by SMTP server software.

Once logged in, use the HELO command followed by your domain name, then enter the MAIL FROM:, RCPT TO:, DATA, and QUIT commands.

gboyd>telnet mail.vnn.vn 25
Trying…
Connected to mail.vnn.vn.
Escape character is ‘^]’.
220 hanoi-fw.vnn.vn Generic SMTP handler
help
214 Help not supported by this implementation
helo
250 hanoi-fw.vnn.vn talking to netcom16.netcom.com ([192.100.81.129])
mail from:santa.claus@north.pole.org
250 Sender <santa.claus@north.pole.org> Ok
rcpt to:gboyd@netcom.com
250 Recipient <gboyd@netcom.com> Ok
data
354 Ok Send data ending with <CRLF>.<CRLF>
It works!!
.
250 Message received: 19980308004818.AAA322@hanoi-fw.vnn.vn

This was a secure SMTP server as evidenced by:

250 hanoi-fw.vnn.vn talking to netcom16.netcom.com ([192.100.81.129])

Notice that it picked up the domain and IP address from my Netcom account.

And here is what the actual headers look like:

Received: from mail.vnn.vn by hanoi-fw-ex.vnn.vn
        via smtpd (for mail3.netcom.com [192.100.81.127]) with SMTP; 8
        Mar 1998 00:51:26 UT
Received: from hanoi-fw.vnn.vn ([203.162.0.100]) by mail.vnn.vn
        (Netscape Mail Server v2.02) with SMTP id AAA322
        for <gboyd@netcom.com>; Sun, 8 Mar 1998 07:50:27 +0700
Received: from netcom16.netcom.com ([192.100.81.129]) by hanoi-fw.vnn.vn
        via smtpd (for mail.vnn.vn [203.162.0.9]) with SMTP; 8 Mar
        1998 00:48:18 UT
Message-Id: <199803080051.QAA02136@mail3.netcom.com>
From: santa.claus@north.pole.org
To: <gboyd@netcom.com>
Date: Sat, 7 Mar 1998 16:51:44 -0800 (PST)
X-UIDL: 8e0cb18c27cfcc2197db33dd7530b350

It works!!

telnet domain.com 25 (Port 25 is SMTP port) * SMTP Basic Command Summary * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HELO somewhere.com (Tell SMTP where you’re from) MAIL FROM: <someone@somewhere.com> (Your return address) RCPT TO: <anyone@anywhere.com> (A recipient’s address) RCPT TO: <jill@someplace.com> (…and another recipient) RCPT TO: <jack@somewhere.edu> (Send a copy to Jack too) VRFY <jack@somewhere.edu> (Verify his address) DATA (Message is as follows…) (type lines of message here) (…close message with carriage return, period, carriage return) RSET (Abort sending this message) EXPN mailing-list name (Expand a mailing list) NOOP (Do nothing. Useful for testing the server’s response) HELP (Get general help) HELP rcpt (Get help on RCPT TO command) SEND FROM: <someone@somewhere.com> (Send mail) SOML FROM: <someone@somewhere.com> (Send or mail) SAML FROM: <someone@somewhere.com> (Send and mail) TURN (Change from sender to reciever) QUIT (Goodbye. I’m done here)

 

[(Top of page)]

Analysis of a Spam Message 1

To gain a better understanding of what e-mail headers indicate, I provide an analysis of a real spam message received by me. In this case, all of the information in the headers is real, that is, none of the header information was faked, forged, or otherwise changed.

Forging headers is almost universal among spammers. The reason being that UCE is prohibited by the Acceptable Use Policy (AUP) and Terms of Service (TOS) of almost every major Internet Service Provider (ISP), and is grounds for immediate termination. Often, spammers use bulk e-mail systems on their own PCs to relay their e-mail through another mail server to attempt to hide their tracks. Since the headers usually show the IP number from which they dialed in, they also insert forged headers to try to confuse users who may try to track the e-mail to report them to their ISPs.

What the sender sees in their e-mail program.

From: "J.A. van Ierland" <ierland2001@yahoo.com>
To: gboyd@expita.com
Date: Sun, 22 Apr 2001 14:19:13 -0400
Subject: Divorce and the Internet

THIS IS NOT SPAM!
[remainder of message removed]

Headers as generated by the sender and handed off to the mailer daemon at Yahoo.com mailer:

From: "J.A. van Ierland" <ierland2001@yahoo.com>
To: gboyd@expita.com
Date: Sun, 22 Apr 2001 14:19:13 -0400
Subject: Divorce and the Internet
Reply-To: legalexplorers@yahoo.com
Organization: Curacao Legal Services Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

THIS IS NOT SPAM!
[remainder of message removed]

Headers as they are when sub-163ip174.carats.net transmits the message to smtp.mail.vip.sc5.yahoo.com and gets ready to send it to me:

Received: from sub-163ip174.carats.net (HELO localhost) (216.152.163.174)
        by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Apr 2001 18:17:04 -0000
X-Apparently-From: <ierland2001@yahoo.com>
X-Sender: ierland2001@yahoo.com
From: "J.A. van Ierland" <ierland2001@yahoo.com>
To: gboyd@expita.com
Date: Sun, 22 Apr 2001 14:19:13 -0400
Subject: Divorce and the Internet
Reply-To: legalexplorers@yahoo.com
Organization: Curacao Legal Services Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

THIS IS NOT SPAM!
[remainder of message removed]

Here are the e-mail headers as they are when no2.superb.net (my domain hoster) finishes processing the message and stores it for me to retrieve. The actual message has been deleted.

Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59])
        by no2.superb.net (8.11.1/8.11.1) with SMTP id f3MIH5k13405
        for <gboyd@expita.com>; Sun, 22 Apr 2001 14:17:05 -0400 (EDT)
Message-Id: <200104221817.f3MIH5k13405@no2.superb.net>
Received: from sub-163ip174.carats.net (HELO localhost) (216.152.163.174)
        by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Apr 2001 18:17:04 -0000
X-Apparently-From: <ierland2001@yahoo.com>
X-Sender: ierland2001@yahoo.com
From: "J.A. van Ierland" <ierland2001@yahoo.com>
To: gboyd@expita.com
Date: Sun, 22 Apr 2001 14:19:13 -0400
Subject: Divorce and the Internet
Reply-To: legalexplorers@yahoo.com
Organization: Curacao Legal Services Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

THIS IS NOT SPAM!
[remainder of message removed]

Here’s a line-by-line analysis of these headers and exactly what each one means.

Received: from smtp015.mail.yahoo.com

This message was sent from a machine calling itself smtp015.mail.yahoo.com

(smtp015.mail.yahoo.com [216.136.173.59])

which is really named smtp015.mail.yahoo.com (i.e., it identified itself and has the IP address [216.136.173.59]. We would use nslookup to check that the IP address matches the name.

by no2.superb.net (8.11.1/8.11.1)

The mailer daemon that did the receiving was no2.superb.net and it’s running sendmail version 8.11.1/8.11.1 (You don’t need to worry about what the software and version numbers mean unless you already know).

with SMTP id f3MIH5k13405

The receiving machine assigned a Simple Mail Transfer Protocol (SMTP) ID number f3MIH5k13405 to the message. (This is used internally by the mailer daemon to uniquely identify this piece of mail from any other mail – an administrator would need to know this ID to look up the message in the mail daemon’s log files, but it’s not usually useful or meaningful to anyone else.)

for <gboyd@expita.com>;

The message is being delivered to gboyd@expita.com. Note that this header is not related to the “To:” line.

Sun, 22 Apr 2001 14:17:05 -0400 (EDT)

This mail transfer happened on Sunday, April 22, 2001, at 14:17:05 (2:17:05 in the afternoon) Eastern Daylight (savings) Time, which is 4 hours behind (west of) Universal Time (UT, old GMT – Greenwich Mean Time); hence the “-0400” offset value.

Message-Id: <200104221817.f3MIH5k13405@no2.superb.net>

The message has been given this number (by no2.superb.net) to identify it. This ID is different from the SMTP ID numbers in the Received: headers because it is attached to this message after delivery at superb.net. The other IDs are only associated with specific mail transactions at specific machines, so that one machine’s ID number means nothing to another machine. Sometimes (as in this example) the Message-ID has the receiving mail address embedded in it as well as the SMTP ID. Other times the Message-ID has the sender’s e-mail address embedded in it. More often than not, it has no intelligible meaning on its own.

Received: from sub-163ip174.carats.net (HELO localhost) (216.152.163.174)
by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Apr 2001 18:17:04 -0000

This line documents the mail handoff from sub-163ip174.carats.net (the sender’s dial-up ISP) to smtp.mail.vip.sc5.yahoo.com. This handoff happened at 18:17:04 Universal Time (UT). The sending machine called itself sub-163ip174.carats.net, and its IP address is (216.152.163.174).

HELO localhost is telling SMTP where the user is from which is indicated by the IP address. A dial-up user of an ISP called Carats.Net sent mail using a web-based Yahoo mail account. Using nslookup on the IP address does indeed show that 216.152.163.174 is sub-163ip174.carats.net. A check on whois Carats.net shows that it located in Willemstad on the island of Curacao in the Netherland Antilles.

If we wish to check times to see if they make sense between sending and receiving, we must convert to a common base. In this case, we can convert to UT or EDT by either adding the 0400 offset or substracting it. 18:17:04 (UT) is 14:17:04 (EDT) -0400. So this message took 1 second to reach me at 14:17:05 (EDT) -0400. The user composed it at 14:19:13 (EDT) -0400 or 2 minutes and 8 seconds before it was sent!

Before you exclaim that this is “fake” e-mail you have to understand that not all administrators are diligent in time synchronizing their mailer dameons with the actual time. If the timing of the e-mail is only off a few minutes or seconds then don’t worry. In fact, you will sometimes see the times off by 1 hour when they forget to account for daylight savings or standard time changes in the US. As long as the time from the “Date” header and each of the “Received:” headers generally progresses in a manner that suggests increasing time, even between time zones, then you can reasonably be sure that the header is not forged.

However, if you see “-0600 (EST)” as a time, this is always forged because -0600 is either CST, MDT, or the Atlantic ocean. No mail should ever have a time of “-0600 (EST)”.

X-Apparently-From: <ierland2001@yahoo.com>

Yahoo added this in an attempt to identify the actual Yahoo user that sent the message. Because Yahoo is a web-based e-mail program and users already have an account at some other ISP when they access Yahoo mail, Yahoo needs to identify the user separately from the ISP userid.

X-Sender: ierland2001@yahoo.com

This header is added by Yahoo to identify the sender with greater reliability than the “From:” header.

From: “J.A. van Ierland” <ierland2001@yahoo.com>

The mail was sent by <ierland2001@yahoo.com>, who gives their real name as J.A. van Ierland.

To: gboyd@expita.com

The letter is addressed to gboyd@expita.com (me!)

Date: Sun, 22 Apr 2001 14:19:13 -0400

The message was composed at 14:19:13 Eastern Daylight Time on Sunday, April 22, 2001.

Subject: Divorce and the Internet

Self-explanatory.

Reply-To: legalexplorers@yahoo.com

This header forces replies to this message to go to an address that is different than that of the original sender indicated in the “From:” header.

Organization: Curacao Legal Services Inc.

An Organization calling itself Curacao Legal Services. Inc. sent this message.

MIME-Version: 1.0

This message is formatted according to the MIME standard version 1.0.

Content-Type: text/plain; charset=iso-8859-1

This message uses an ISO standard Latin 1 West European language character set.

Content-Transfer-Encoding: 7bit

This message was sent using standard 7bit encoding.

[(Top of page)]

Analysis of a Spam Message 2

Received: from netcom.com (mx1.netcom.com [199.174.33.82])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f3MMLnN29301
        for <gboyd@expita.com>; Sun, 22 Apr 2001 18:21:49 -0400 (EDT)
Received: (from smap@localhost)
        by netcom.com (8.9.3/8.9.3) id RAA23097
        for <gboyd@netcom.com>; Sun, 22 Apr 2001 17:21:48 -0500 (CDT)
From: 67385181@bellsouth.net
Received: from smtp6.mindspring.com(207.69.200.110) by mx1.netcom.com via smap (V1.3)
        id rma022716; Sun Apr 22 17:21:27 2001
Received: from 207.69.200.110 (pool-63.49.172.95.troy.grid.net [63.49.172.95])
        by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id SAA17578;
        Sun, 22 Apr 2001 18:16:53 -0400 (EDT)
Message-Id: <200104222216.SAA17578@smtp6.mindspring.com>
Received: from attractsfasti@bellsouth.net by attractsfast@bellsouth.net
    (8.8.5/8.6.5) with SMTP id GAA01907 for <attractsfast@bellsouth.net>; Sun,
     22 Apr 2001 16:55:32 -0600 (EST)
Date: Sun, 22 Apr 01 16:55:32 EST
To: attractsfast@bellsouth.net
Subject: Attracts The Opposite Sex For You...FAST !!

[remainder of message removed]

This would have been sent to dev/null by my procmail filter because it had a “Bad time”.

Here’s a line-by-line analysis of these headers and exactly what each one means.

Received: from netcom.com (mx1.netcom.com [199.174.33.82])

This message was sent from a machine calling itself netcom.com which is really named mx1.netcom.com (i.e., it identified itself and has the IP address [199.174.33.82]). Using nslookup shows this to be true.

My original userid at Netcom (gboyd@netcom.com) has all e-mail forwarded to my new account – gboyd@expita.com (hosted by superb.net) using a .forward file installed at Netcom.

by no2.superb.net (8.11.1/8.11.1) with ESMTP id f3MMLnN29301

The mailer daemon that did the receiving was no2.superb.net and it’s running sendmail version 8.11.1/8.11.1 which assigned an Enhanced Simple Mail Transfer Protocol (ESMTP – see RFC1651) ID number f3MMLnN29301 to the message.

for <gboyd@expita.com>; Sun, 22 Apr 2001 18:21:49 -0400 (EDT)

The message is being delivered to gboyd@expita.com. Note that this header is not related to the “To:” line which is actually a fake address. This mail transfer happened on Sunday, April 22, 2001, at 18:21:49 (6:21:49 in the afternoon) Eastern Daylight (savings) Time, which is 4 hours west of UT.

Received: (from smap@localhost)

SMAP is part of a larger package known as the TIS Firewall Toolkit. It’s a secure, small, simple wrapper around sendmail. It works by assuming sendmail’s role and accepting network connections, and accepting SMTP mail, and then passing it down to sendmail in a secure environment.

By default, a host name called ‘localhost’ has a IP ‘loopback address’ of 127.0.0.1. A loopback address is simply a method of describing a computer to itself.

by netcom.com (8.9.3/8.9.3) id RAA23097

The mailer daemon that did the receiving was netcom.com, running sendmail version 8.9.3/8.9.3 and it assigned an ID number RAA23097 to the message.

for <gboyd@netcom.com>; Sun, 22 Apr 2001 17:21:48 -0500 (CDT)

The message is being delivered to gboyd@netcom.com and happened on Sunday, April 22, 2001, at 17:21:48 (5:21:48 in the afternoon) Central Daylight (savings) Time, which is 5 hours west from UT.

From: 67385181@bellsouth.net

This “From:” header was added by the MUA when the message was sent.

Received: from smtp6.mindspring.com(207.69.200.110) by mx1.netcom.com via smap (V1.3)

This message was sent by a machine calling itself mx1.netcom.com via SMAP (small, simple and secure wrapper around sendmail) version 1.3. The message was handed off by a machine calling itself smtp6.mindspring.com which identified itself and has the IP address 207.69.200.110. NOTE: Netcom.com was purchased by Mindspring.Com which has since merged with Earthlink.Net. So the Mindspring to Netcom handoff makes sense.

id rma022716; Sun Apr 22 17:21:27 2001

The receiving machine assigned a Simple Mail Transfer Protocol (SMTP) ID number rma022716 to the message. This mail transfer happened on Sunday, April 22, 2001, at 17:21:27 (5:21:27 in the afternoon) Central Daylight (savings) Time, which is 5 hours west of Universal Time.

Received: from 207.69.200.110 (pool-63.49.172.95.troy.grid.net [63.49.172.95])

This line documents the sending of mail from smtp6.mindspring.com (which has an IP address of 207.69.200.110, use nslookup to verify). The sending machine is part of a dial-up pool of machines and is called pool-63.49.172.95.troy.grid.net which identified itself with its IP address of (63.49.172.95, nslookup also verifies this IP address).

by smtp6.mindspring.com (8.9.3/8.8.5) with SMTP id SAA17578;

The mailer daemon that did the receiving was smtp6.mindspring.com, it’s running sendmail version 8.9.3/8.8.5 and assigned an SMTP ID of SAA17578.

Sun, 22 Apr 2001 18:16:53 -0400 (EDT)

This mail transfer happened on Sunday, April 22, 2001, at 18:16:53 (6:16:53 in the afternoon) Eastern Daylight (savings) Time, which is 4 hours west of Universal Time.

Message-Id: <200104222216.SAA17578@smtp6.mindspring.com>

The message has been given this number (by smtp6.mindspring.com) to identify it. This ID is different from the SMTP ID numbers in the Received: headers because it is attached to this message after delivery at Netcom/Mindspring. The other IDs are only associated with specific mail transactions at specific machines, so that one machine’s ID number means nothing to another machine. Sometimes (as in this example) the Message-ID has the receiving mail address embedded in it as well as the SMTP ID.

Received: from attractsfasti@bellsouth.net by attractsfast@bellsouth.net
(8.8.5/8.6.5) with SMTP id GAA01907 for <attractsfast@bellsouth.net>; Sun,
22 Apr 2001 16:55:32 -0600 (EST)

This looks like a standard “Received:” header line except for one glaring error, and that is the time. If you see “-0600 (EST)” as a time, this is always forged because -0600 is either CST, MDT, or the Atlantic ocean. No mail should ever have a time of “-0600 (EST)”.

Date: Sun, 22 Apr 01 16:55:32 EST

The message was composed at 16:55:32 Eastern Standard Time on Sunday, April 22, 2001. Probably true if we compare times:
I receive mail at 18:21:49 -0400 (EDT)
Netcom receives mail at 17:21:48 -0500 (CDT) or 18:21:48 -0400 (EDT)
Mindspring passes it to Netcom at 17:21:27 or 18:21:27 -0400 (EDT)
Mindspring receives mail at 18:16:53 -0400 (EDT)
Composed at 16:55:32 -0500 EST or 17:55:32 -0400 (EDT)

To: attractsfast@bellsouth.net

The letter is addressed to a fake userid. I received the message because my address was (no doubt) in the “Bcc:” header line.

Subject: Attracts The Opposite Sex For You…FAST !!

Self-explanatory for spam.

Sample Traces

–THIS SECTION NOT COMPLETE–

Spam with virus

Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net[207.69.200.246])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f1RKvm922624
        for <gboyd@expita.com>; Tue, 27 Feb 2001 15:57:48 -0500 (EST)
Received: from oemcomputer (user-33qtovt.dialup.mindspring.com[199.174.227.253])
        by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id PAA27137
        for <gboyd@expita.com>; Tue, 27 Feb 2001 15:57:35 -0500 (EST)
Date: Tue, 27 Feb 2001 15:57:35 -0500 (EST)
Message-Id: <200102272057.PAA27137@smtp10.atl.mindspring.net>
From: Hahaha <hahaha@sexyfun.net>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEPU3SL"
Status:

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated
and polite with Snowhite. When they go out work at mornign, they promissed a
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the
Seven Dwarfs enter...
    [ Part 2, Application/OCTET-STREAM (Name: "dwarf4you.exe")  31KB. ]
    [ Cannot display this part. Press "V" then "S" to save in a file. ]

Forwarded e-mail

Received: from netcom.com (mx2.netcom.com [199.174.33.83])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f1RKKB918097
        for <gboyd@expita.com>; Tue, 27 Feb 2001 15:20:11 -0500 (EST)
Received: (from smap@localhost)
        by netcom.com (8.9.3/8.9.3) id OAA12843
        for <gboyd@netcom.com>; Tue, 27 Feb 2001 14:20:10 -0600 (CST)
Received: from mail.enitel.no(194.19.2.12) by mx2.netcom.com via smap (V1.3)
        id rma012660; Tue Feb 27 14:19:58 2001
Received: from [195.204.54.202] (HELO hjemmemaskin.m1.2537.telia.com)
        by enitel.no (CommuniGate Pro SMTP 3.4b7)
        with ESMTP id 18419608 for gboyd@NETCOM.COM; Tue, 27 Feb 2001 21:19:55 +0100
Message-Id: <4.3.2.7.2.20010227203335.00abeaf0@m1.2537.telia.com>
X-Sender: u253700169@m1.2537.telia.com@m1.2537.telia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 27 Feb 2001 20:58:32 +0100
To: "Gerald E. Boyd" <gboyd@netcom.com>
From: Allan Myrvang <allan.myrvang@go.telia.no>
Subject: Modern History Conference?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Status: RO

More spam

Received: from moon.mahez.nl ([212.136.204.74])
        by no2.superb.net (8.11.1/8.11.1) with ESMTP id f22KL8v13257
        for <-faq@expita.com>; Fri, 2 Mar 2000 15:21:09 -0500 (EST)
Received: from kqBQ6lm1l (max1-71.losangeles.corecomm.net [216.214.106.199]) by
        moon.mahez.nl with SMTP (Microsoft Exchange Internet Mail Service Version
        5.5.2448.0)
        id FXBHC3LP; Fri, 2 Mar 2001 20:39:30 +0100
DATE: 02 Mar 02 11:46:38 AM
FROM: zx11zx14@yahoo.com
Message-ID: <4MyfPYu7HkADr>
SUBJECT: .

Dear Web Merchant:

[spam removed]
This would have been sent to dev/null by my procmail filter because it had no “To:” header.

Porn mail

Received: from ocs (line-217-161.dial.matav.net [145.236.217.161])
        by no2.superb.net (8.11.1/8.11.1) with SMTP id f22IsU606174
        for <gboyd@expita.com>; Fri, 2 Mar 2001 13:54:31 -0500 (EST)
Message-Id: <200103021854.f22IsU606174@no2.superb.net>
From: "Kate" <kate149@freemail.hu>
To: <gboyd@expita.com>
Subject: Hi
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Fri, 2 Mar 2001 19:55:39
Status: RO

[spam removed]
However there was an adddress at http://www.nexus.hu/

[(Top of page)]

References:

[(Top of page)]