E.3 Message Headers

RFC 822 details the standard headers that are to be used when sending mail across the Internet. Most of these fields are quite common, and you would expect to find them in almost any electronic mail system. This includes the "To:", "From:", "Subject:" and "Date:" fields, among others. The local delivery agent that actually stores the mail in a user's mailbox must map the RFC 822 headers into whatever fields are in use on the local system's mail store. Likewise, any system that is originating mail for the Internet (such as an SMTP gateway for Microsoft Mail, cc:Mail, VMS Mail, MHS, and others) must convert the local messages from their proprietary format into RFC 822-compliant form before sending the mail over the SMTP network.

Figure E.2 below shows an example RFC 822 message. The header is everything up to the blank line, and the body is everything after the blank line.

 Return-Path: <supervisor@unoverica.COM>
 Received: from Prophet by Greywolf
         id NAA01898; Sun, 18 May 1997 13:16:24 -0400
 Received: from Greywolf by Fred-PC (8.6.9/1.2-eef)
         id 000000C8; Sun, 18 May 1997 10:15:44 -0700
 Message-ID: 0xlckjds0032
 From: "System Administrator" <supervisor@unoverica.COM>
 Reply-To: <supervisor@unoverica.COM>
 Date: Sun, 18 May 1997 13:15:04 -0400
 To: root@unoverica.com
 Subject: mail headers
  
 Please let me know if you have any questions.

Figure E.2 Sample RFC 822 envelope.

Each of the fields in the header are defined by RFC 822:

• The "Return-Path:" field. This is used to determine information about the sender's address and how to reply to that person. This is not the same as the "From:" or "Reply-To:" fields. Instead it is used to present an address that can be used by the local mail system to generate a response in case the message is undeliverable. For example, mail generated by a mailing list may have a list administrator's e-mail address in the "Return-Path:" field. Thus, if a local mail server needed to return the mail because of some problem, then the mail system would be able to generate and send a delivery-failure notification to the address provided here.
  
  If no "Return-Path:" is provided by the original sender, then the SMTP server is supposed to append this information based on the address provided in the "MAIL FROM:" portion of the envelope.
  
  
• The "Received:" field. Every SMTP server that touches the mail message must make a note of this fact in the "Received:" field in the header. The "Received:" field is never replaced, but is instead continually added by every SMTP server that touched the mail message. This provides a tracking mechanism for administrators to use when diagnosing mail relay problems or bounced messages. Mail that has taken too many "hops" to be delivered will likely get returned by a mail server sooner or later, as a large number hops generally indicates mailing loops.
  
  The "Received:" headers should be read from bottom-to-top, in chronological order. As can be seen in above, this message was first sent from Fred-PC to Greywolf, and then sent from Greywolf to Prophet. Note that because of a potentially significant difference in the clocks on various systems, it may appear that the time stamps are not in the correct order. However, the time stamp is only relevant to the specific server associated with that "Received:" entry, and does not reflect the local time.
  
  
• The "Message-ID:" field. This field is intended to provide an additional layer of tracking for the administrator. The "Message-ID:" field is a unique stamp that identifies this single copy or instance of this single message. Each and every SMTP server that processes this message is supposed to stamp it with a unique ID. The theory is that the ID can then be used to gather information about the message by using logging tools to locate information about this particular message.
  
  
• The "From:" field. In RFC 822 lingo, this field is defined as the person who "wished the message to be sent," which is not necessarily the same person as the sender. For example, the VP of Human Resources may have wished the message sent, although it may have actually been sent by her secretary. An additional field called "Sender:" is provided for this case, although these fields are rarely used for these purposes. Sometimes they are used by mailings lists or system management products.
  
  
• The "Reply-To:" field. As we have seen, the sender may not be the originator. Likewise, responses may not necessarily be intended to go to either of these parties. If for example a coworker wished to take a vote on a subject, they may set the "Reply-To:" field to point to a mailbox used by an automated vote- tallying system.
  
  
• The "Date:" field. The "Date: field is used to indicate the time and date that the message was first sent, and is represented by GMT, with additional GMT off- set information. In the example in above, the GMT off-set is represented as "- 0400", or "minus four hours." This equates to "EST", which could have been used instead. Although each SMTP server stamps the date in the "Received:" headers, the message date itself is determined when the local mail server moves the message into the recipient's mailbox.
  
  
• The "To:" field. This field identifies the message recipient(s). This field can either be created by the SMTP client during transfer, or may be created by the mail client that generated the message. The "To:" field is used for local delivery of mail, although the "RCPT TO:" command used during the SMTP transfer directs the delivery of the actual message to the mail server, prior to its local delivery to a user's mailbox. Additionally, "CC:" and "BCC:" fields are also defined by RFC 822.
  

For more information about the envelope, refer to section E.2 The SMTP Envelope. For more information on the headers, refer to section E.3 Message Headers.

Copyright © 1997, Unoverica Corporation. All rights reserved. Unauthorized use prohibited.