Overview
Now that the process of message delivery has been illustrated it may be helpful to look at what actually is being sent. Email messages are viewed as having two entities, an envelope and contents. The envelope is viewed as the data that is needed to accomplish delivery, and the contents compose the object to be delivered to the recipient. When this standard was first proposed, the content was assumed to be text. Of course, the advent of multimedia required the ability to send non-ASCII files. This was later implemented with the use of MIME (Multipurpose Internet Mail Extensions). This topic will be addressed shortly, for the example expressed here we will look at the message structure as illustrated in RFC 822 for transporting ASCII text only messages.
Email message structure is defined to use a "memo" framework. That is to say that the message begins with data that must be structured in a specific way followed by data that is not structured in any specific way. This rigidly defined area of the message is the envelope, the less rigid part of the message is the content.
The Headers
The headers of a message contain data pertaining to the content of the message. It is made up of ASCII text lines consisting of a header field, a colon, and a header field value. There are two types of header fields: structured and unstructured. Structured header fields are those that must follow a specific syntax, such as From: and Date:, so that the data can be parsed as needed. Unstructured header fields are those that are not required to follow a set syntax, such as Subject: and Comments:, and are just considered to be strings. Header fields are not required to be in any specific order, but they are required to appear before the message content.
The following are some commonly used email header fields:
| Header Field | Description |
|---|---|
| Cc: | Carbon copy. It is a place to specify additional recipients. |
| Comments: | A nonstandard header used by some e-mail clients to specify more information about the sender. |
| Content-Description:* | Human-readable string about the content of the message. |
| Content-Id:* | A unique MIME identifier that works in a similar fashion to Message-ID: |
| Content-Transfer-Encoding:* | Shows what MIME encoding was used. |
| Content-Type:* | Tells MIME-compliant mail programs what type of data is in the cargo. |
| Date: | Specifies date the mail was sent. |
| Errors-To: | A place for mail generated errors. |
| From: | Specifies the user-defined sender of the mail. |
| Message-ID: | A unique identifier assigned to the message. |
| MIME-Version:* | Specifies the MIME version that was used by the sender. |
| Organization: | A free form header that usually contains the name of the organization. |
| Priority: | Assigns a priority to the message. |
| Received: | Provides a log of the message's history. This field is added to by every mail transport agent that relays the message. |
| Reply-To: | Specifies the reply address. |
| Return-Path: | This field, added by the final transport system to the user's machine, contains information about the address back to the mail's originator. |
| Sender: | Authenticated identity of the agent that sent the message. |
| Subject: | Specifies the user-defined subject of the e-mail. |
| To: | The recipient of the e-mail. |
* = These signify MIME headers which will be addressed in more detail in the MIME topic.
In addition to these fields, RFC 822 defined the ability to create user-defined fields, called extension fields or X-headers. These are created and given values by the sending client and are only useful if the receiver's client has a method of handling the X-header.
The Message Body.
The body is simply the portion of the email that the sender wishes the receiver to receive. It is merely the cargo and does not otherwise have any use to the TCP/IP mail protocols. The body is usually made up of the actual text of the e-mail and/or any attachments.
In a simple text email message, both the body and the header are typically made up of 7-bit data, which is compatible with all mail servers, and are less than 1000 characters in line length.
A Basic Text Email
As an example, examine the composition of a basic text email. In this example, the sender simply opens their email client, specifies the receiver and the subject, writes a quick note,
To: test@email.com Subject: email test Message: This is a test message to see the message form.
and sends the mail. The message sent would probably look something like this:
Return-Path: <test@email.com>
Received: from YOURCOMPUTER ([192.168.0.0]) by yourserver.com
(Post.Office MTA v3.5 release 215 ID# 0-
54045U100L2S100V35)
with ESMTP id com for <me@test.com>;
Thu, 1 Feb 2001 16:46:38 -0500
To: test@email.com
From: me@test.com
Subject: email test
Message-ID: <0000c93a04003b07d1@[192.168.0.0]>
Date: Thu, 01 Feb 2001 16:47:39 -0500
This is a test message to see the message form.
The first 11 lines are the email headers. In this example the only headers that were user-defined are the "From:" header and the "Subject:" header. The others were added by the email clients and mail servers during the message's journey. Since no MIME headers are present in the message, the content is assumed to be ASCII text which, as we can see from our message at the bottom, it is. What happens if we send an email with an attachment? This is where MIME comes into play. MIME (Multipurpose Internet Mail Extensions) is a specification of how to format non-ASCII messages.
Using PowerTCP Mail for .NET, you can view a message in this form by using the Message.Store method.