The Movement of Mail Across the Internet

We will follow an email across the internet and use this example to briefly explain some concepts and terms. Afterwords, we will look at the email Header from the example and see that it contains the travel history of the message in a terse cryptic format.


Joe Blow of Whaler Inc. sends a note to his boss, Bity Kelp, informing her of his planned daily activities for tomorrow. Joe is at a hotel about to visit a client. He is using the hotel's internet connection.

1) Joe clicks the send button on his email application. The email application grabs the name of Joe's outgoing mail server from its configuration files. The server name is

An email application (like Kmail, Evolution, Outlook, etc) is sometimes referred to as an MUA, Mail User Agent.

2) The email application attempts to open an SMTP connection with

SMTP means Simple Mail Transfer protocol. SMTP is a tcp protocol that uses port 25 to connect to a mail server and drop off mail.

After a few minutes of not being able to connect, the email application times out. This is a problem that Joe is familiar with. The problem is not with Joe's application or with the server. The address even resolves properly in DNS.

The problem lies with the Internet Service Provider used by the Hotel. The hotel's ISP is stopping Joe's connection at its border. The ISP will only allow it's own servers to initiate external connections on tcp port 25 (SMTP).

While at the hotel Joe cannot drop off mail directly to his corporate mail server (at least not using port 25). Joe will have to drop off his mail on the ISP's mail server and let that server relay his mail on to his corporate mail server.

The ISP's mail server is

Joe reconfigures his email application (his MUA) to use for all outgoing mail. He hits send again.

The email application opens an SMTP connection (tcp - port 25) with and submits Joe's message.

3) The mail service running on examines the TO address of the message and sees that this is not a local delivery - it is a relay. The mail service then checks to see if relaying is allowed from the address that dropped off the message - it is.

The mail service running on a server (like sendmail, postfix, exchange, etc) is often referred to as an MTA, Mail Transfer Agent

4) The accepted message is assigned a local message ID and is dropped into a local outbound queue

5) The MTA isolates the domain from the TO address and does a DNS look-up for the MX or mail records for that domain.

The MX records for indicate that it has two email servers:       mail exchanger = 10       mail exchanger = 100

6) opens an SMTP connection (tcp - port 25) with The connection is successful!

7) The MTA on examines the TO address for the message and sees that this is a local delivery. It accepts the mail and hands it off to a local delivery agent.

Procmail is a good example of a local delivery agent. Some MTA's like Exchange have the local delivery agent built into them.

8) The local delivery agent drops the mail off in Bity Kelp's mail spool.

9) Every ten minutes Bity Kelp's MUA (email application) makes a POP connection to the mail server and checks for new mail in her spool.

POP means Post Office Protocol. POP is a tcp protocol that uses port 110 to connect to a mail server (or a pop server) and download/delete mail from a mail spool.

Her MUA finds a new message waiting in the spool, downloads the message locally, and deletes the message from her spool on the server.

For a more detailed analysis look at:


An email can contain many parts. In its simplest form an email will contain a header and a body. The body contains the message - the text that was originally typed and then sent. The header contains a journal or history of the email's travels.

We will look line-by-line at the header of the above message 
to see what it reveals.

   Received: from ([]) by with ESMTP SMTPSVC
   (5.5.1877.757.75); Mon, 7 Nov 2002 13:26:23 -0400

This is the first "Received" line in the header so it is the last 
MTA that touched the message before it was downloaded via POP to 
Bity Kelps local email.
The message arrived:
- from the server (with IP address of
- to (by) the current server,
- on Monday, November 7th, 2002 at 1:26:23pm (in a timezone 4 hours off of GMT).

Note: this "Received" header is from Bity's own mail server and we 
can assume that it is accurate. Headers can be forged...

   Received: from 
   ( []) by
   (8.12.5/8.12.5) with ESMTP id g97FGMgJ010527 for
   (; Mon, 7 Nov 2002 13:26:22 -0400 (EDT)

This is the second "Received" line in the header. It is also the last 
"Received" line, so it is the MTA that accepted the message for relay 
from Joe Blow in his Hotel.

The message arrived:
- from the workstation (with IP address of
- to (by) this server,
- for the email address,
- on Monday, November 7th, 2002 at 1:26:22pm (in a timezone 4 hours off of GMT).

Note that the Received "from" in the first header is the same 
as the Received "by" in this header. This leads us to believe 
that the header is authentic.


   Content-Type: text/plain; charset="us-ascii"

This is a plain text email using us-ascii as the character set

   From: Joe Blow (

The "From" field is required in a message header

The message claims to be from Joe Blow (, but 
that information is given by the MUA from a configuration file 
filled in by the user.  There is no check for this, so it is 
easily forged.

However, since we know that Joe is staying at, and 
this email was dropped off from a room at, this is 
probably an authentic email from Joe.  I don't know why Bity is so 

   To: 'Bity Kelp' (

The email is plainly addressed to  If this 
was a BCC to Bity then her address would not be in the TO field, 
but it would still show up in "Received" headers in Bity Kelps
copy of the email.

   Subject: Planned Daily Activities for Nov 8

The "Subject" field is required in a message header - though it 
can be blank.

   Date: 07 Nov 2002 13:29:54 -0400

This is the date/time that the mail was downloaded to Bity's email. 
It indicates that Bity is in a timezone that is 4 hours behind GMT.

   MIME-Version: 1.0

This indicates that the message was encoded using version 1.0 of 
Multipurpose Internet Mail Extensions. Mime really is not used in 
this message, as it is a simple text email. If it were used, it 
would be following the rules and conventions of version 1.0

   Content-Transfer-Encoding: quoted-printable

This indicates how the body of the message was encoded when first 
sent. This is often settable in the MUA. Quoted-printable is fairly 

   Message-Id: (

This was the initial message id given to the message when it was 
dropped off for relay/delivery. This ID would only appear in the 
logs of the initial MTA that accepted the email.

Every MTA assigns a unique (for that time) Message-ID to an email 
each time that the email is queued up. You will find a Message-ID 
in each of the "Received" headers. These ID's can be used on the 
appropriate server to trace the email's progress on that server 
(via the log files).


This is the address that a bounce should be sent to. This can be 
different from both the "From" field and the "Reply-to" field. 
If did not exist as a user, or if this email 
was too large to be accepted by one of the servers, then this is 
the address that would receive the error/warning/bounce email.

Introduction: Setting up Mail Services in Linux
Part I, The Movement of Mail Across the Internet
Part II, Setting up a Mail server on Red Hat 8.0
Part III, The File Unmasked!