tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5322

 
 
 

Internet Message Format

Part 3 of 3, p. 38 to 57
Prev RFC Part

 


prevText      Top      Up      ToC       Page 38 
5.  Security Considerations

   Care needs to be taken when displaying messages on a terminal or
   terminal emulator.  Powerful terminals may act on escape sequences
   and other combinations of US-ASCII control characters with a variety
   of consequences.  They can remap the keyboard or permit other
   modifications to the terminal that could lead to denial of service or
   even damaged data.  They can trigger (sometimes programmable)

Top      Up      ToC       Page 39 
   answerback messages that can allow a message to cause commands to be
   issued on the recipient's behalf.  They can also affect the operation
   of terminal attached devices such as printers.  Message viewers may
   wish to strip potentially dangerous terminal escape sequences from
   the message prior to display.  However, other escape sequences appear
   in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
   [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
   should not be stripped indiscriminately.

   Transmission of non-text objects in messages raises additional
   security issues.  These issues are discussed in [RFC2045], [RFC2046],
   [RFC2047], [RFC2049], [RFC4288], and [RFC4289].

   Many implementations use the "Bcc:" (blind carbon copy) field,
   described in section 3.6.3, to facilitate sending messages to
   recipients without revealing the addresses of one or more of the
   addressees to the other recipients.  Mishandling this use of "Bcc:"
   may disclose confidential information that could eventually lead to
   security problems through knowledge of even the existence of a
   particular mail address.  For example, if using the first method
   described in section 3.6.3, where the "Bcc:" line is removed from the
   message, blind recipients have no explicit indication that they have
   been sent a blind copy, except insofar as their address does not
   appear in the header section of a message.  Because of this, one of
   the blind addressees could potentially send a reply to all of the
   shown recipients and accidentally reveal that the message went to the
   blind recipient.  When the second method from section 3.6.3 is used,
   the blind recipient's address appears in the "Bcc:" field of a
   separate copy of the message.  If the "Bcc:" field sent contains all
   of the blind addressees, all of the "Bcc:" recipients will be seen by
   each "Bcc:" recipient.  Even if a separate message is sent to each
   "Bcc:" recipient with only the individual's address, implementations
   still need to be careful to process replies to the message as per
   section 3.6.3 so as not to accidentally reveal the blind recipient to
   other recipients.

6.  IANA Considerations

   This document updates the registrations that appeared in [RFC4021]
   that referred to the definitions in [RFC2822].  IANA has updated the
   Permanent Message Header Field Repository with the following header
   fields, in accordance with the procedures set out in [RFC3864].

   Header field name:  Date
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.1)

Top      Up      ToC       Page 40 
   Header field name:  From
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.2)

   Header field name:  Sender
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.2)

   Header field name:  Reply-To
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.2)

   Header field name:  To
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.3)

   Header field name:  Cc
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.3)

   Header field name:  Bcc
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.3)

   Header field name:  Message-ID
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.4)

   Header field name:  In-Reply-To
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.4)

Top      Up      ToC       Page 41 
   Header field name:  References
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.4)

   Header field name:  Subject
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.5)

   Header field name:  Comments
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.5)

   Header field name:  Keywords
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.5)

   Header field name:  Resent-Date
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Resent-From
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Resent-Sender
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Resent-To
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

Top      Up      ToC       Page 42 
   Header field name:  Resent-Cc
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Resent-Bcc
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Resent-Reply-To
   Applicable protocol:  Mail
   Status:  obsolete
   Author/Change controller:  IETF
   Specification document(s):  This document (section 4.5.6)

   Header field name:  Resent-Message-ID
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.6)

   Header field name:  Return-Path
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.7)

   Header field name:  Received
   Applicable protocol:  Mail
   Status:  standard
   Author/Change controller:  IETF
   Specification document(s):  This document (section 3.6.7)
   Related information:  [RFC5321]

Top      Up      ToC       Page 43 
Appendix A.  Example Messages

   This section presents a selection of messages.  These are intended to
   assist in the implementation of this specification, but should not be
   taken as normative; that is to say, although the examples in this
   section were carefully reviewed, if there happens to be a conflict
   between these examples and the syntax described in sections 3 and 4
   of this document, the syntax in those sections is to be taken as
   correct.

   In the text version of this document, messages in this section are
   delimited between lines of "----".  The "----" lines are not part of
   the message itself.

Top      Up      ToC       Page 44 
Appendix A.1.  Addressing Examples

   The following are examples of messages that might be sent between two
   individuals.

Appendix A.1.1.  A Message from One Person to Another with Simple
                 Addressing

   This could be called a canonical message.  It has a single author,
   John Doe, a single recipient, Mary Smith, a subject, the date, a
   message identifier, and a textual message in the body.

   ----
   From: John Doe <jdoe@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

   If John's secretary Michael actually sent the message, even though
   John was the author and replies to this message should go back to
   him, the sender field would be used:

   ----
   From: John Doe <jdoe@machine.example>
   Sender: Michael Jones <mjones@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

Top      Up      ToC       Page 45 
Appendix A.1.2.  Different Types of Mailboxes

   This message includes multiple addresses in the destination fields
   and also uses several different forms of addresses.

   ----
   From: "Joe Q. Public" <john.q.public@example.com>
   To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test>
   Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net>
   Date: Tue, 1 Jul 2003 10:52:37 +0200
   Message-ID: <5678.21-Nov-1997@example.com>

   Hi everyone.
   ----

   Note that the display names for Joe Q. Public and Giant; "Big" Box
   needed to be enclosed in double-quotes because the former contains
   the period and the latter contains both semicolon and double-quote
   characters (the double-quote characters appearing as quoted-pair
   constructs).  Conversely, the display name for Who? could appear
   without them because the question mark is legal in an atom.  Notice
   also that jdoe@example.org and boss@nil.test have no display names
   associated with them at all, and jdoe@example.org uses the simpler
   address form without the angle brackets.

Appendix A.1.3.  Group Addresses

   ----
   From: Pete <pete@silly.example>
   To: A Group:Ed Jones <c@a.test>,joe@where.test,John <jdoe@one.test>;
   Cc: Undisclosed recipients:;
   Date: Thu, 13 Feb 1969 23:32:54 -0330
   Message-ID: <testabcd.1234@silly.example>

   Testing.
   ----

   In this message, the "To:" field has a single group recipient named
   "A Group", which contains 3 addresses, and a "Cc:" field with an
   empty group recipient named Undisclosed recipients.

Top      Up      ToC       Page 46 
Appendix A.2.  Reply Messages

   The following is a series of three messages that make up a
   conversation thread between John and Mary.  John first sends a
   message to Mary, Mary then replies to John's message, and then John
   replies to Mary's reply message.

   Note especially the "Message-ID:", "References:", and "In-Reply-To:"
   fields in each message.

   ----
   From: John Doe <jdoe@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

   When sending replies, the Subject field is often retained, though
   prepended with "Re: " as described in section 3.6.5.

   ----
   From: Mary Smith <mary@example.net>
   To: John Doe <jdoe@machine.example>
   Reply-To: "Mary Smith: Personal Account" <smith@home.example>
   Subject: Re: Saying Hello
   Date: Fri, 21 Nov 1997 10:01:10 -0600
   Message-ID: <3456@example.net>
   In-Reply-To: <1234@local.machine.example>
   References: <1234@local.machine.example>

   This is a reply to your hello.
   ----

   Note the "Reply-To:" field in the above message.  When John replies
   to Mary's message above, the reply should go to the address in the
   "Reply-To:" field instead of the address in the "From:" field.

Top      Up      ToC       Page 47 
   ----
   To: "Mary Smith: Personal Account" <smith@home.example>
   From: John Doe <jdoe@machine.example>
   Subject: Re: Saying Hello
   Date: Fri, 21 Nov 1997 11:00:00 -0600
   Message-ID: <abcd.1234@local.machine.test>
   In-Reply-To: <3456@example.net>
   References: <1234@local.machine.example> <3456@example.net>

   This is a reply to your reply.
   ----

Appendix A.3.  Resent Messages

   Start with the message that has been used as an example several
   times:

   ----
   From: John Doe <jdoe@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

   Say that Mary, upon receiving this message, wishes to send a copy of
   the message to Jane such that (a) the message would appear to have
   come straight from John; (b) if Jane replies to the message, the
   reply should go back to John; and (c) all of the original
   information, like the date the message was originally sent to Mary,
   the message identifier, and the original addressee, is preserved.  In
   this case, resent fields are prepended to the message:

Top      Up      ToC       Page 48 
   ----
   Resent-From: Mary Smith <mary@example.net>
   Resent-To: Jane Brown <j-brown@other.example>
   Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800
   Resent-Message-ID: <78910@example.net>
   From: John Doe <jdoe@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

   If Jane, in turn, wished to resend this message to another person,
   she would prepend her own set of resent header fields to the above
   and send that.  (Note that for brevity, trace fields are not shown.)

Appendix A.4.  Messages with Trace Fields

   As messages are sent through the transport system as described in
   [RFC5321], trace fields are prepended to the message.  The following
   is an example of what those trace fields might look like.  Note that
   there is some folding white space in the first one since these lines
   can be long.

   ----
   Received: from x.y.test
      by example.net
      via TCP
      with ESMTP
      id ABC12345
      for <mary@example.net>;  21 Nov 1997 10:05:43 -0600
   Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600
   From: John Doe <jdoe@node.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: Fri, 21 Nov 1997 09:55:06 -0600
   Message-ID: <1234@local.node.example>

   This is a message just to say hello.
   So, "Hello".
   ----

Top      Up      ToC       Page 49 
Appendix A.5.  White Space, Comments, and Other Oddities

   White space, including folding white space, and comments can be
   inserted between many of the tokens of fields.  Taking the example
   from A.1.3, white space and comments can be inserted into all of the
   fields.

   ----
   From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)
   Cc:(Empty list)(start)Hidden recipients  :(nobody(that I know))  ;
   Date: Thu,
         13
           Feb
             1969
         23:32
                  -0330 (Newfoundland Time)
   Message-ID:              <testabcd.1234@silly.test>

   Testing.
   ----

   The above example is aesthetically displeasing, but perfectly legal.
   Note particularly (1) the comments in the "From:" field (including
   one that has a ")" character appearing as part of a quoted-pair); (2)
   the white space absent after the ":" in the "To:" field as well as
   the comment and folding white space after the group name, the special
   character (".") in the comment in Chris Jones's address, and the
   folding white space before and after "joe@example.org,"; (3) the
   multiple and nested comments in the "Cc:" field as well as the
   comment immediately following the ":" after "Cc"; (4) the folding
   white space (but no comments except at the end) and the missing
   seconds in the time of the date field; and (5) the white space before
   (but not within) the identifier in the "Message-ID:" field.

Top      Up      ToC       Page 50 
Appendix A.6.  Obsoleted Forms

   The following are examples of obsolete (that is, the "MUST NOT
   generate") syntactic elements described in section 4 of this
   document.

Appendix A.6.1.  Obsolete Addressing

   Note in the example below the lack of quotes around Joe Q. Public,
   the route that appears in the address for Mary Smith, the two commas
   that appear in the "To:" field, and the spaces that appear around the
   "." in the jdoe address.

   ----
   From: Joe Q. Public <john.q.public@example.com>
   To: Mary Smith <@node.test:mary@example.net>, , jdoe@test  . example
   Date: Tue, 1 Jul 2003 10:52:37 +0200
   Message-ID: <5678.21-Nov-1997@example.com>

   Hi everyone.
   ----

Appendix A.6.2.  Obsolete Dates

   The following message uses an obsolete date format, including a non-
   numeric time zone and a two digit year.  Note that although the day-
   of-week is missing, that is not specific to the obsolete syntax; it
   is optional in the current syntax as well.

   ----
   From: John Doe <jdoe@machine.example>
   To: Mary Smith <mary@example.net>
   Subject: Saying Hello
   Date: 21 Nov 97 09:55:06 GMT
   Message-ID: <1234@local.machine.example>

   This is a message just to say hello.
   So, "Hello".
   ----

Top      Up      ToC       Page 51 
Appendix A.6.3.  Obsolete White Space and Comments

   White space and comments can appear between many more elements than
   in the current syntax.  Also, folding lines that are made up entirely
   of white space are legal.

   ----
   From  : John Doe <jdoe@machine(comment).  example>
   To    : Mary Smith
   __
             <mary@example.net>
   Subject     : Saying Hello
   Date  : Fri, 21 Nov 1997 09(comment):   55  :  06 -0600
   Message-ID  : <1234   @   local(blah)  .machine .example>

   This is a message just to say hello.
   So, "Hello".
   ----

   Note especially the second line of the "To:" field.  It starts with
   two space characters.  (Note that "__" represent blank spaces.)
   Therefore, it is considered part of the folding, as described in
   section 4.2.  Also, the comments and white space throughout
   addresses, dates, and message identifiers are all part of the
   obsolete syntax.

Top      Up      ToC       Page 52 
Appendix B.  Differences from Earlier Specifications

   This appendix contains a list of changes that have been made in the
   Internet Message Format from earlier specifications, specifically
   [RFC0822], [RFC1123], and [RFC2822].  Items marked with an asterisk
   (*) below are items which appear in section 4 of this document and
   therefore can no longer be generated.

   The following are the changes made from [RFC0822] and [RFC1123] to
   [RFC2822] that remain in this document:

   1.   Period allowed in obsolete form of phrase.
   2.   ABNF moved out of document, now in [RFC5234].
   3.   Four or more digits allowed for year.
   4.   Header field ordering (and lack thereof) made explicit.
   5.   Encrypted header field removed.
   6.   Specifically allow and give meaning to "-0000" time zone.
   7.   Folding white space is not allowed between every token.
   8.   Requirement for destinations removed.
   9.   Forwarding and resending redefined.
   10.  Extension header fields no longer specifically called out.
   11.  ASCII 0 (null) removed.*
   12.  Folding continuation lines cannot contain only white space.*
   13.  Free insertion of comments not allowed in date.*
   14.  Non-numeric time zones not allowed.*
   15.  Two digit years not allowed.*
   16.  Three digit years interpreted, but not allowed for generation.*
   17.  Routes in addresses not allowed.*
   18.  CFWS within local-parts and domains not allowed.*
   19.  Empty members of address lists not allowed.*
   20.  Folding white space between field name and colon not allowed.*
   21.  Comments between field name and colon not allowed.
   22.  Tightened syntax of in-reply-to and references.*
   23.  CFWS within msg-id not allowed.*
   24.  Tightened semantics of resent fields as informational only.
   25.  Resent-Reply-To not allowed.*
   26.  No multiple occurrences of fields (except resent and received).*
   27.  Free CR and LF not allowed.*
   28.  Line length limits specified.
   29.  Bcc more clearly specified.

Top      Up      ToC       Page 53 
   The following are changes from [RFC2822].
   1.   Assorted typographical/grammatical errors fixed and
        clarifications made.
   2.   Changed "standard" to "document" or "specification" throughout.
   3.   Made distinction between "header field" and "header section".
   4.   Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.*
   5.   Moved discussion of specials to the "Atom" section.  Moved text
        to "Overall message syntax" section.
   6.   Simplified CFWS syntax.
   7.   Fixed unstructured syntax.
   8.   Changed date and time syntax to deal with white space in
        obsolete date syntax.
   9.   Removed quoted-pair from domain literals and message
        identifiers.*
   10.  Clarified that other specifications limit domain syntax.
   11.  Simplified "Bcc:" and "Resent-Bcc:" syntax.
   12.  Allowed optional-field to appear within trace information.
   13.  Removed no-fold-quote from msg-id.  Clarified syntax
        limitations.
   14.  Generalized "Received:" syntax to fix bugs and move definition
        out of this document.
   15.  Simplified obs-qp.  Fixed and simplified obs-utext (which now
        only appears in the obsolete syntax).  Removed obs-text and obs-
        char, adding obs-body.
   16.  Fixed obsolete date syntax to allow for more (or less) comments
        and white space.
   17.  Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list,
        obs-addr-list, obs-phrase-list, and the newly added obs-group-
        list).
   18.  Fixed obs-reply-to syntax.
   19.  Fixed obs-bcc and obs-resent-bcc to allow empty lists.
   20.  Removed obs-path.

Appendix C.  Acknowledgements

   Many people contributed to this document.  They included folks who
   participated in the Detailed Revision and Update of Messaging
   Standards (DRUMS) Working Group of the Internet Engineering Task
   Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and
   people who simply sent their comments in via email.  The editor is
   deeply indebted to them all and thanks them sincerely.  The below
   list includes everyone who sent email concerning both this document
   and [RFC2822].  Hopefully, everyone who contributed is named here:

   +--------------------+----------------------+---------------------+
   | Matti Aarnio       | Tanaka Akira         | Russ Allbery        |
   | Eric Allman        | Harald Alvestrand    | Ran Atkinson        |
   | Jos Backus         | Bruce Balden         | Dave Barr           |

Top      Up      ToC       Page 54 
   | Alan Barrett       | John Beck            | J Robert von Behren |
   | Jos den Bekker     | D J Bernstein        | James Berriman      |
   | Oliver Block       | Norbert Bollow       | Raj Bose            |
   | Antony Bowesman    | Scott Bradner        | Randy Bush          |
   | Tom Byrer          | Bruce Campbell       | Larry Campbell      |
   | W J Carpenter      | Michael Chapman      | Richard Clayton     |
   | Maurizio Codogno   | Jim Conklin          | R Kelley Cook       |
   | Nathan Coulter     | Steve Coya           | Mark Crispin        |
   | Dave Crocker       | Matt Curtin          | Michael D'Errico    |
   | Cyrus Daboo        | Michael D Dean       | Jutta Degener       |
   | Mark Delany        | Steve Dorner         | Harold A Driscoll   |
   | Michael Elkins     | Frank Ellerman       | Robert Elz          |
   | Johnny Eriksson    | Erik E Fair          | Roger Fajman        |
   | Patrik Faltstrom   | Claus Andre Faerber  | Barry Finkel        |
   | Erik Forsberg      | Chuck Foster         | Paul Fox            |
   | Klaus M Frank      | Ned Freed            | Jochen Friedrich    |
   | Randall C Gellens  | Sukvinder Singh Gill | Tim Goodwin         |
   | Philip Guenther    | Arnt Gulbrandsen     | Eric A Hall         |
   | Tony Hansen        | John Hawkinson       | Philip Hazel        |
   | Kai Henningsen     | Robert Herriot       | Paul Hethmon        |
   | Jim Hill           | Alfred Hoenes        | Paul E Hoffman      |
   | Steve Hole         | Kari Hurtta          | Marco S Hyman       |
   | Ofer Inbar         | Olle Jarnefors       | Kevin Johnson       |
   | Sudish Joseph      | Maynard Kang         | Prabhat Keni        |
   | John C Klensin     | Graham Klyne         | Brad Knowles        |
   | Shuhei Kobayashi   | Peter Koch           | Dan Kohn            |
   | Christian Kuhtz    | Anand Kumria         | Steen Larsen        |
   | Eliot Lear         | Barry Leiba          | Jay Levitt          |
   | Bruce Lilly        | Lars-Johan Liman     | Charles Lindsey     |
   | Pete Loshin        | Simon Lyall          | Bill Manning        |
   | John Martin        | Mark Martinec        | Larry Masinter      |
   | Denis McKeon       | William P McQuillan  | Alexey Melnikov     |
   | Perry E Metzger    | Steven Miller        | S Moonesamy         |
   | Keith Moore        | John Gardiner Myers  | Chris Newman        |
   | John W Noerenberg  | Eric Norman          | Mike O'Dell         |
   | Larry Osterman     | Paul Overell         | Jacob Palme         |
   | Michael A Patton   | Uzi Paz              | Michael A Quinlan   |
   | Robert Rapplean    | Eric S Raymond       | Sam Roberts         |
   | Hugh Sasse         | Bart Schaefer        | Tom Scola           |
   | Wolfgang Segmuller | Nick Shelness        | John Stanley        |
   | Einar Stefferud    | Jeff Stephenson      | Bernard Stern       |
   | Peter Sylvester    | Mark Symons          | Eric Thomas         |
   | Lee Thompson       | Karel De Vriendt     | Matthew Wall        |
   | Rolf Weber         | Brent B Welch        | Dan Wing            |
   | Jack De Winter     | Gregory J Woodhouse  | Greg A Woods        |
   | Kazu Yamamoto      | Alain Zahm           | Jamie Zawinski      |
   | Timothy S Zurcher  |                      |                     |
   +--------------------+----------------------+---------------------+

Top      Up      ToC       Page 55 
7.  References

7.1.  Normative References

   [ANSI.X3-4.1986]  American National Standards Institute, "Coded
                     Character Set - 7-bit American Standard Code for
                     Information Interchange", ANSI X3.4, 1986.

   [RFC1034]         Mockapetris, P., "Domain names - concepts and
                     facilities", STD 13, RFC 1034, November 1987.

   [RFC1035]         Mockapetris, P., "Domain names - implementation and
                     specification", STD 13, RFC 1035, November 1987.

   [RFC1123]         Braden, R., "Requirements for Internet Hosts -
                     Application and Support", STD 3, RFC 1123,
                     October 1989.

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5234]         Crocker, D. and P. Overell, "Augmented BNF for
                     Syntax Specifications: ABNF", STD 68, RFC 5234,
                     January 2008.

7.2.  Informative References

   [RFC0822]         Crocker, D., "Standard for the format of ARPA
                     Internet text messages", STD 11, RFC 822,
                     August 1982.

   [RFC1305]         Mills, D., "Network Time Protocol (Version 3)
                     Specification, Implementation", RFC 1305,
                     March 1992.

   [ISO.2022.1994]   International Organization for Standardization,
                     "Information technology - Character code structure
                     and extension techniques", ISO Standard 2022, 1994.

   [RFC2045]         Freed, N. and N. Borenstein, "Multipurpose Internet
                     Mail Extensions (MIME) Part One: Format of Internet
                     Message Bodies", RFC 2045, November 1996.

   [RFC2046]         Freed, N. and N. Borenstein, "Multipurpose Internet
                     Mail Extensions (MIME) Part Two: Media Types",
                     RFC 2046, November 1996.

Top      Up      ToC       Page 56 
   [RFC2047]         Moore, K., "MIME (Multipurpose Internet Mail
                     Extensions) Part Three: Message Header Extensions
                     for Non-ASCII Text", RFC 2047, November 1996.

   [RFC2049]         Freed, N. and N. Borenstein, "Multipurpose Internet
                     Mail Extensions (MIME) Part Five: Conformance
                     Criteria and Examples", RFC 2049, November 1996.

   [RFC2822]         Resnick, P., "Internet Message Format", RFC 2822,
                     April 2001.

   [RFC3864]         Klyne, G., Nottingham, M., and J. Mogul,
                     "Registration Procedures for Message Header
                     Fields", BCP 90, RFC 3864, September 2004.

   [RFC4021]         Klyne, G. and J. Palme, "Registration of Mail and
                     MIME Header Fields", RFC 4021, March 2005.

   [RFC4288]         Freed, N. and J. Klensin, "Media Type
                     Specifications and Registration Procedures",
                     BCP 13, RFC 4288, December 2005.

   [RFC4289]         Freed, N. and J. Klensin, "Multipurpose Internet
                     Mail Extensions (MIME) Part Four: Registration
                     Procedures", BCP 13, RFC 4289, December 2005.

   [RFC5321]         Klensin, J., "Simple Mail Transfer Protocol",
                     RFC 5321, October 2008.

Author's Address

   Peter W. Resnick (editor)
   Qualcomm Incorporated
   5775 Morehouse Drive
   San Diego, CA  92121-1714
   US

   Phone: +1 858 651 4478
   EMail: presnick@qualcomm.com
   URI:   http://www.qualcomm.com/~presnick/

Top      Up      ToC       Page 57 
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.