Email “Received” Headers

When an email is sent, it should contain no “Received” header fields. Each time the email is processed by a mail server along the delivery route, a new Received header field is prepended to the email. The very first Received header is added by the SMTP server that the SMTP client (such as your app or a program such as Outlook) connects to to send email.

A typical scenario is that an email will contain two Received headers when delivery is complete. The 1st is the Receive header added by your SMTP server. This may often be something like “localhost” and may show an internal IP address, such as “192.168.1.###”. Your SMTP server then relays the email to its destination, and the mail server at the destination (at the receiver) then adds its Received header.

The Received header has a syntax such as this:

        Received: from ? by ? via ? with ? id ? for ? ; date-time

Some mail servers may not include all the parts, and spammers often fake Received headers.

POP3 Headers and Attachment Info

The POP3 protocol is not very feature rich. To download an email “header” the POP3 client must issue a “TOP” command. The following text is from RFC 1939 and describes the response to the TOP command:

...
After the initial +OK, the
POP3 server sends the headers of the message, the blank
line separating the headers from the body, and then the
number of lines of the indicated message's body, being
careful to byte-stuff the termination character (as with
all multi-line responses).
...

What this means is that the response will contain the N raw lines following the email header. An email with attachments is typically a multipart/mixed email and therefore the lines following the initial MIME header are the MIME sub-headers and sub-header bodies. For example, consider the following email which contains 3 GIF image attachments:

MIME-Version: 1.0
Date: Tue, 04 Nov 2008 14:54:33 -0600
Message-ID: <CHILKAT-MID-1adb0da5-2646-edac-1f79-9e288b0677ac@CK2007>
X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
X-Priority: 3 (Normal)
Subject: This is a test
From: "Support" <support@something-123.com>
Return-Path: support@something-123.com
To: "Admin" <admin@something-123.com>
Content-Type: multipart/mixed;
	boundary="-----_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX"

This is a multi-part message in MIME format.

-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

This is line 1
This is line 2
This is line 3
This is line 4
This is line 5
This is line 6
This is line 7
This is line 8
This is line 9

-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
Content-Type: image/gif;
	name="small1.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	 filename="small1.gif"

R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
4kiWYwEAOw==

-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
Content-Type: image/gif;
	name="small2.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	 filename="small2.gif"

R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
4kiWYwEAOw==

-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
Content-Type: image/gif;
	name="small3.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	 filename="small3.gif"

R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
4kiWYwEAOw==

-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX--

A POP3 server would respond to a “TOP 25” lines command by sending the following:
(The line numbers enclosed in parentheses are not actually included in the POP3 server’s response)

MIME-Version: 1.0
Date: Tue, 04 Nov 2008 14:54:33 -0600
Message-ID: <CHILKAT-MID-1adb0da5-2646-edac-1f79-9e288b0677ac@CK2007>
X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)
X-Priority: 3 (Normal)
Subject: This is a test
From: "Support" <support@something-123.com>
Return-Path: support@something-123.com
To: "Admin" <admin@something-123.com>
Content-Type: multipart/mixed;
	boundary="-----_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX"

(1)This is a multi-part message in MIME format.
(2)
(3)-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
(4)Content-Type: text/plain
(5)Content-Transfer-Encoding: quoted-printable
(6)
(7)This is line 1
(8)This is line 2
(9)This is line 3
(10)This is line 4
(11)This is line 5
(12)This is line 6
(13)This is line 7
(14)This is line 8
(15)This is line 9
(16)
(17)-------_chilkat_5ad_e1df_7b63f7c5.559182f3_.MIX
(18)Content-Type: image/gif;
(19)	name="small1.gif"
(20)Content-Transfer-Encoding: base64
(21)Content-Disposition: attachment;
(22)	 filename="small1.gif"
(23)
(24)R0lGODlhFAAUAJH/AP///wD/PACLIQAAACwAAAAAFAAUAEACFoyPqcvtLoaclL6Ls968+w+G
(25)4kiWYwEAOw==

The POP3 client has no knowledge of the attachments following the 1st 25 lines. The POP3 client, if it’s able to parse the prematurely chopped-off MIME, may have knowledge of attachments that might have been included in the response (it would depend on how good the MIME parser is capable of dealing with prematurely terminated MIME). You can see that no matter how many header lines are retrieved, you can never be sure of receiving all the attachments (or even knowing about them) unless the entire email is downloaded. For example, you could have an email with two attachments — one very large one and one very small one. If the small one follows the large one, you’ll never see it unless you download the full contents of the large attachment to get at the small attachment that follows…