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 smtp.whaler.org
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.whaler.org.
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 smtp.whaler.org 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 smtp.pita.org
Joe reconfigures his email application (his MUA) to use smtp.pita.org for all outgoing mail. He hits send again.
The email application opens an SMTP connection (tcp - port 25) with smtp.pita.org and submits Joe's message.
3) The mail service running on smtp.pita.org 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 whaler.org indicate that it has two email servers:
whaler.org mail exchanger = 10 smtp.whaler.org. whaler.org mail exchanger = 100 backup-smtp.whaler.org.
6) Smtp.pita.org opens an SMTP connection (tcp - port 25) with smtp.whaler.org. The connection is successful!
7) The MTA on smtp.whaler.org 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:
http://www.sendmail.org/email-explained.html
======
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 smtp.pita.org ([24.93.67.251]) by smtp.whaler.org 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 smtp.whaler.org (with IP address of 24.93.67.251) - to (by) the current server, smtp.whaler.org - 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 dhcp432.hotel-chain.org (dhcp432.hotel-chain.org [216.54.164.3]) by smtp.pita.org (8.12.5/8.12.5) with ESMTP id g97FGMgJ010527 for (bity.kelp@whaler.org); 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 dhcp432.hotel-chain.org (with IP address of 216.54.164.3) - to (by) this server, smtp.pita.org - for the email address, bity.kelp@whaler.org - 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 (joe.blow@whaler.org) The "From" field is required in a message header The message claims to be from Joe Blow (joe.blow@whaler.org), 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 Hotel-chain.org, and this email was dropped off from a room at Hotel-chain.org, this is probably an authentic email from Joe. I don't know why Bity is so paranoid! === To: 'Bity Kelp' (Bity.Kelp@whaler.org) The email is plainly addressed to Bity.Kelp@whaler.org. 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 common. === Message-Id: (200210071329.45464.Joe.Blow@whaler.org) 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). === Return-Path: Joe.Blow@whaler.org 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 bity.kelp@whaler.org 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.