A Mail message generally consists of a message body, which is the text the sender wrote, and special data specifying recipients, transport medium, etc., very much like what you see when you look at a letter's envelope.
This administrative data falls into two categories; in the first category is any data that is specific to the transport medium, like the address of sender and recipient. It is therefore called the envelope. It may be transformed by the transport software as the message is passed along.
The second variety is any data necessary for handling the mail message, which is not particular to any transport mechanism, such as the message's subject line, a list of all recipients, and the date the message was sent. In many networks, it has become standard to prepend this data to the mail message, forming the so-called mail header. It is offset from the mail body by an empty line.
Most mail transport software in the world uses a header format outlined in a RFC-822. Its original purpose was to specify a standard for use on the ARPANET, but since it was designed to be independent from any environment, it has been easily adapted to other networks, including many UUCP-based networks.
RFC-822 however is only the greatest common denominator. More recent standards have been conceived to cope with growing needs as, for example, data encryption, international character set support, and multi-media mail extensions (MIME).
In all these standards, the header consists of several lines, separated by newline characters. A line is made up of a field name, beginning in column one, and the field itself, offset by a colon and white space. The format and semantics of each field vary depending on the field name. A header field may be continued across a newline, if the next line begins with a TAB. Fields can appear in any order.
A typical mail header may look like this:
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994 Return-Path:Usually, all necessary header fields are generated by the mailer interface you use, like elm, pine, mush, or mailx. Some however are optional, and may be added by the user. elm, for example, allows you to edit part of the message header. Others are added by the mail transport software. A list of common header fields and their meaning are given below:Received: from brewhq.swb.de by monad.swb.de with uucp (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp (Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 2 Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 Date: Tue, 12 Apr 1994 15:56:49 -0400 Message-Id: <199404121956.PAA07787@ruby> From: andyo@ora.com (Andy Oram) To: okir@monad.swb.de Subject: Re: Your RPC section
From: This contains the sender's email address, and possibly the ``real name''. A complete zoo of formats is used here. To: This is the recipient's email address. Subject: Describes the content of the mail in a few words. At least that's what it should do. Date: The date the mail was sent. Reply-To: Specifies the address the sender wants the recipient's reply directed to. This may be useful if you have several accounts, but want to receive the bulk of mail only on the one you use most frequently. This field is optional. Organization: The organization that owns the machine from which the mail originates. If your machine is owned by you privately, either leave this out, or insert ``private'' or some complete non- sense. This field is optional. Message-ID: A string generated by mail transport on the originating sys- tem. It is unique to this message. Received: Every site that processes your mail (including the machines of sender and recipient) inserts such a field into the header, giving its site name, a message id, time and date it received the message, which site it is from, and which transport soft- ware was used. This is so that you can trace which route the message took, and can complain to the person responsible if something went wrong. X-anything: No mail-related programs should complain about any header which starts with X-. It is used to implement additional fea- tures that have not yet made it into an RFC, or never will. This is used by the Linux Activists mailing list, for example, where the channel is selected by the X-Mn-Key: header field.
The one exception to this structure is the very first line. It starts with the keyword From which is followed by a blank instead of a colon. To distinguish it from the ordinary From: field, it is frequently referred to as From_. It contains the route the message has taken in UUCP bang-path style (explained below), time and date when it was received by the last machine having processed it, and an optional part specifying which host it was received from. Since this field is regenerated by every system that processes the message, it is sometimes subsumed under the envelope data.
The From_ field is there for backward compatibility with some older mailers, but is not used very much anymore, except by mail user interfaces that rely on it to mark the beginning of a message in the user's mailbox. To avoid potential trouble with lines in the message body that begin with ``From '', too, it has become standard procedure to escape any such occurrence by preceding it with ``>''.