[Search] [txt|ps|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2076                                  
Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
draft-ietf-mailext-mail-attributes-03.txt                        Sweden
Category: Informational                                   November 1995
Expires May 1996

                  Common Internet Message Attributes

                        Status of this Memo

  This document is an Internet-Draft.  Internet-Drafts are working
  documents of the Internet Engineering Task Force (IETF), its
  areas, and its working groups.  Note that other groups may also
  distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  ``work in progress.''

  To learn the current status of any Internet-Draft, please check
  the ``1id-abstracts.txt'' listing contained in the Internet-
  Drafts Shadow Directories on ftp.is.co.za (Africa),
  nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

  This memo provides information for the Internet community. This'
  memo does not specify an Internet standard of any kind, since
  this document is mainly a compilation of information taken from
  other RFC-s.. Distribution of this memo is unlimited.


This memo contains a table of commonly occurring attributes in
headings and on envelopes of e-mail messages. The document compiles
information from other RFC-s such as RFC 821, RFC 822, RFC 1036,
RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766 and RFC 1806. A few
commonly occurring attributes which are not defined in RFC-s are
also included. For each attribute, the memo gives a short
description and a reference to the RFC, in which the attribute
is defined. The postscript version of this memo shows the changes
as compared to version 02.

Palme                                                          [Page 1]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                         Table of contents

1. Introduction

2. Use of gatewaying attributes

3. Table of attributes

   3.1  Phrases used in the tables
   3.2  Addressing information
   3.3  Envelope and format information
   3.4  Sender and recipient indication
   3.5  Response control
   3.6  Message identification and referral attributes
   3.7  Other textual attributes
   3.8  Attributes containing dates and times
   3.9  Quality information
   3.10 Language information
   3.11 Size information
   3.13 Encoding information
   3.14 Resent-attributes
   3.15 Miscellaneous

4. Acknowledgments

5. References

6. Author's address

Appendix A: Attributes sorted by Internet RFC document in which
            they appear

Appendix B: Alphabetical index

Palme                                                          [Page 2]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                         1. Introduction

Many different Internet standards and RFC-s define attributes which
may occur on Internet Mail Messages and Network News Articles. The
intention of this document is to list all such attributes in one
document as an aid to people developing message systems or interested
in Internet Mail standards.

The document contains all heading attributes which the author has
found in the following Internet standards: RFC 821 [1], RFC 822 [2],
RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11],
RFC 1766 [12] and RFC 1806 [14]. Note in particular that heading
attributes defined in RFC 1421-1424, "Privacy Enhancement for Internet
Electronic Mail", are not included. A few additional attributes which
often can be found in e-mail headings but are not part of any Internet
standard are also included.

For each heading attribute, the document gives a short description and
a reference to the Internet standard or RFC, in which they are defined.

                 2. Use of gatewaying attributes

RFC 1327 defines a number of new attributes in Internet mail, which
are defined to map attributes which X.400 has but which were
previously not standardized in Internet mail. The fact that an
attribute occurs in RFC 1327 indicates that it is recommended for
use in gatewaying messages between X.400 and Internet mail, but
does not mean that the attribute is recommended for messages wholly
within Internet mail. Some of these attributes may eventually get
accepted also for usage within Internet mail, but they are, when
this is written (July 1995) not recommended for such usage.

Fields defined in RFC 1036 for use in Usenet News sometimes appear
in mail messages, either because the messages have been gatewayed
from Usenet News to e-mail, or because the messages were written in
combined clients supporting both e-mail and Usenet News in the same
client. These fields are however not standardized for use in
Internet e-mail and should be handled with caution.

Fields are given here in the spelling used in e-mail headers. This
may sometimes be English, sometimes American spelling. One attribute,
"Organisation/Organization" occurs in e-mail headers sometimes with
English, sometimes with American spelling.

Palme                                                          [Page 3]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                      3. Table of attributes

3.1 Phrases used in the tables

"not for general        Used to mark attributes which are defined in
usage"                  RFC 1327 for use in messages from or to
                        Internet mail/X.400 gateways. These attributes
                        have not been standardized for general usage
                        in the exchange of messages between Internet
                        mail-based systems.

"not standardized       Used to mark attributes defined only in RFC
for use in e-mail"      1036 for use in Usenet News. These attributes
                        have no standard meaning when appearing in e-
                        mail, some of them may even be used in
                        different ways by different software. When
                        appearing in e-mail, they should be handled
                        with caution. Note that RFC 1036, although
                        generally used as a standard for Usenet News,
                        is not an accepted IETF standard or on the
                        IETF standards track.

"non-standard"          This attribute is not specified in any of
                        those referenced RFC-s which are Internet
                        standards, draft standards or proposed
                        standards. The attribute appears here because
                        it is common in e-mail or Usenet News headers.
                        Usage of these attributes is not in general

"discouraged"           This attribute, which is non-standard, is
                        known to create problems and should not be
                        generated. Handling of such attributes in
                        incoming mail should be done with great

"controversial"         The meaning and usage of this attribute is
                        controversial, i.e. different implementors
                        have chosen to implement the attribute in
                        different ways. Because of this, such
                        attributes should be handled with caution and
                        understanding of the different possible

"for limited use"       Attributes defined in a so-called
                        "experimental" Internet standard. These should
                        be used only if both parties agree.

"experimental"          This attribute is used for newly defined
                        attributes, which are to be tried out before
                        entering the IETF standards track.

Palme                                                          [Page 4]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

3.2 Addressing information

Original sender. Should in           MAIL FROM       RFC 821,
Internet be empty ("MAIL FROM:                       RFC 1123: 5.2.9.
<>") when sending notifications,
and be the list administrator
when forwarding from a
distribution list. This value may
for gatewayed messages contain a
chain of hosts to be passed in
sequence to reach the original
sender (i.e. a relative address).

Used to convey the information       Return-Path:    RFC 821,
from the MAIL FROM envelope                          RFC 1123: 5.2.13.
attribute when the message leaves
the SMTP environment in which
"MAIL FROM" is used.

Recipient to which message is to     RCPT TO         RFC 821,
be delivered. Relative address                       RFC 1123: 5.2.6.
was allowed in RFC 821, but later
prohibited in RFC 1123.

3.3 Envelope and format

All that is inside the envelope.     DATA            RFC 821,
                                                     RFC 1123: 5.2.8.

Trace of MTA-s which a message       Received:       RFC 822: 4.3.2,
has passed.                                          RFC 1123: 5.2.8.

An indicator that this message is    MIME-Version:   RFC 1521: 3.
formatted according to the MIME
standard, and an indication of
which version of MIME is

List of MTA-s passed.                Path:           RFC 1036: 2.2.6,
                                                     not standardized
                                                     for use in e-mail.

Special Usenet News actions.         Control:        RFC 1036: 2.1.6,
                                                     not standardized
                                                     for use in

Trace of distribution lists          DL-Expansion-   RFC 1327, not for
passed.                              History-        general usage.

Palme                                                          [Page 5]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Which body part types occur in       Original-       RFC 1327, not for
this message.                        Encoded-        general usage.

Special informational message.       Message-Type:   RFC 1327, not for
                                     Delivery        general usage.

Controls whether this message may    Alternate-      RFC 1327, not for
be forwarded to alternate            Recipient:      general usage.
recipients such as a postmaster
if delivery is not possible to
the intended recipient. Default:

Whether recipients are to be told    Disclose-       RFC 1327, not for
the names of other recipients of     Recipients:     general usage.
the same message. This is
primarily an X.400 facility, such
disclosure is in Internet mail
done via the To:, Cc: and Bcc:
heading fields.

Whether a MIME body part is to be    Content-        RFC 1806,
shown inline or is an attachment,    Disposition:    experimental
can also indicate a suggested
filename for use when saving an
attachment to a file.

3.4 Sender and recipient

Author, approver                     From:           RFC 822: 4.4.1,
                                                     RFC 1123: 5.2.15-
                                                     16, 5.3.7.

Moderator                            Approved:       RFC 1036: 2.2.11,
                                                     not standardized
                                                     for use in e-mail.

Sender information inside the        Sender:         RFC 822: 4.4.2,
envelope.                                            RFC 1123: 5.2.15-
                                                     16, 5.3.7.

Main recipients.                     To:             RFC 822: 4.5.1,
                                                     RFC 1123: 5.2.15-
                                                     16, 5.3.7.

Additional recipients.               Cc:             RFC 822: 4.5.2,
                                                     RFC 1123. 5.2.15-
                                                     16, 5.3.7.

Palme                                                          [Page 6]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Recipients not shown to other        Bcc:            RFC 822: 4.5.3,
recipients.                                          RFC 1123: 5.2.15-
                                                     16, 5.3.7.

In Usenet News: group to which       Newsgroups:     RFC 1036: 2.1.3,
this article was posted.                             not standardized
Some systems provide this field                      and controversial
also in e-mail although it is not                    for use in e-mail.
standardized there.
Unfortunately, the field can
appear in e-mail with two
different and contradictory
(a) Indicates the newsgroup
recipient of a message sent to
both e-mail and Usenet News
(b) In a personally addressed
reply to a message in a news-
group, indicate the newsgroup in
which this discussion originated.

Inserted by Sendmail when there      Apparently-     Non-standard,
is no "To:" recipient in the         To:             discouraged,
original message, listing                            mentioned in
recipients derived from the                          RFC 1211.
envelope into the message
heading. This behavior is not
quite proper, MTA-s should not
modify headings (except inserting
Received lines), and it can in
some cases cause Bcc recipients
to be wrongly divulged to non-Bcc

Limitation on where this message     Distribution:   RFC 1036: 2.2.7,
can be distributed.                                  not standardized
                                                     for use in e-mail.

Fax number of the originator.        Fax:,           Non-standard.

Phone number of the originator.      Phone:          Non-standard.

Information about the client         Mail-System-    Non-standard.
software of the originator.          Version:,

Palme                                                          [Page 7]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

3.5 Response control

This heading field is meant to       Reply-To:       RFC 822: 4.4.3,
indicate where the sender wants                      controversial.
replies to go. Unfortunately,
this is ambiguous, since there
are different kinds of replies,
which the sender may wish to go
to different addresses. In
particular, there are personal
replies intended for only one
person, and group replies,
intended for the whole group of
people who read the replied-to
message (often a mailing list).

There has been various
suggestions to differentiate
between these two uses of "Reply-
To", with new header fields names
"Personal-Reply-To", "Group-Reply-
To" or "Wide-Reply-To". None of
these proposals have been

In practice, "Reply-To" is often
used to indicate a neater format
for the e-mail address of the
sender than that given in the
"From" field. In this case, it
would be better to put the neater
format directly in the "From"

A well-known mailing list
software will optionally insert
"Reply-To" with the name of the
list into messages distributed by
the list.

The opinion of the author of this
RFC is that you should avoid
using "Reply-To" until IETF has
defined less ambiguous
constructs. This opinion is
however also controversial and
not shared by everyone.

Palme                                                          [Page 8]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Used in Usenet News to indicate      Followup-To:    RFC 1036: 2.2.3,
that future discussions (=follow-                    not standardized
up) on an article should go to a                     for use in e-mail.
different set of newsgroups than
the replied-to article. The most
common usage is when an article
is posted to several newsgroups,
and further discussions is to
take place in only one of them.

In e-mail, this heading field is
used in a message which is sent
to both e-mail and Usenet News,
to show where follow-up in Usenet
news is wanted. The field does
not say anything about where
follow-up in e-mail is to be

Address to which notifications       Errors-To:,     Non-standard,
are to be sent and a request to      Return-         discouraged.
get delivery notifications.          Receipt-To:
Internet standards recommend,
however, the use of RCPT TO and
Return-Path, not Errors-To, for
where delivery notifications are
to be sent, and a new standard
for delivery notifications
specifies how requests for
notifications are specified by a
new parameter "NOTIFY" to the
"RCPT TO" SMTP command.

An IETF group is working on a        Disposition-    Do not use until
standard for receipt notifica-       Notification-   the proposal from
tions (note that this is not the     To:             this IETF group is
same as delivery notifications).                     ready and accepted
This group is discussing this new                    by IETF.
heading field, but no agreement
has been reached yet.

Whether non-delivery report is       Prevent-        RFC 1327, not for
wanted at delivery error. Default    NonDelivery-    general usage.
is to want such a report.            Report:

Whether a delivery report is         Generate-       RFC 1327, not for
wanted at successful delivery.       Delivery-       general usage.
Default is not to generate such a    Report:

Indicates whether the content of     Content-        RFC 1327, not for
a message is to be returned with     Return          general usage.
non-delivery notifications.

Palme                                                          [Page 9]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Indicates whether the content of     RET in DRPT     In forthcoming new
a message is to be returned with     SMTP exten-     Internet standard.
non-delivery notifications.          sion

3.6 Message identification and
referral attributes

Unique ID of this message.           Message-ID:     RFC 822: 4.6.1.

Unique ID of one body part of the    Content-ID:     RFC 1521: 6.1.
content of a message.

Reference to message which this      In-Reply-To:    RFC 822: 4.6.2.
message is a reply to.

Reference to other related           References:     RFC 822: 4.6.3.

Reference to previous message        Obsoletes:      RFC 1327, not for
being corrected and replaced.                        general usage.

Used in Usenet News in similar       Supersedes:     Non-standard.
ways to the "Obsoletes" attribute
described above.

3.7 Other textual attributes

Search keys for data base            Keywords:       RFC 822: 4.7.1.

Title, heading, subject.             Subject:        RFC 822: 4.7.1.

Comments on a message.               Comments:       RFC 822: 4.7.2.

Description of a particular body     Content-        RFC 1521: 6.2.
part of a message.                   description:

Organization to which the sender     Organization:   RFC 1036: 2.2.8,
of this message belongs.                             not standardized
                                                     for use in e-mail.

See Organization above.              Organisation:   Non-standard.

Short text describing a longer       Summary:        RFC 1036: 2.2.10,
message. Warning: Some mail                          not standardized
systems will not display this                        for use in e-mail,
text to the recipient. Because of                    discouraged.
this, do not use this field for
text which you want to ensure
that the recipient gets.

A text string which identifies       Content-        RFC 1327, not for
the content of a message.            identifier:     general usage.

Palme                                                          [Page 10]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

3.8 Attributes containing dates
and times

The time when a message was          Delivery-       RFC 1327, not for
delivered to its recipient.          Date:           general usage.

In Internet, the date when a         Date:           RFC 822: 5.1,
message was written, in X.400,                       RFC 1123: 5.2.14.
the time a message was submitted.

A suggested expiration date. Can     Expires:        RFC 1036: 2.2.4,
be used both to limit the time of                    not standardized
an article which is not                              for use in e-mail.
meaningful after a certain date,
and to extend the storage of
important articles.

Time at which a message loses its    Expiry-Date:    RFC 1327, not for
validity.                                            general usage.

Latest time at which a reply is      Reply-By:       RFC 1327, not for
requested (not demanded).                            general usage.

3.9 Quality information

Can be "normal", "urgent" or "non-   Priority:       RFC 1327, not for
urgent" and can influence                            general usage.
transmission speed and delivery.

Sometimes used as a priority         Precedence:     Non-standard,
value which can influence                            controversial,
transmission speed and delivery.                     discouraged.
Common values are "bulk" and
"first-class". Other uses is to
control automatic replies and to
control return-of-content
facilities, and to stop mailing
list loops.

Can be high, normal or low and is    Importance:     RFC 1327, not for
only used in the recipient client                    general usage.

Can be personal, private, company    Sensitivity:    RFC 1327, not for
confidential or absent.                              general usage.

Body parts are missing.              Incomplete-     RFC 1327, not for
                                     Copy:           general usage.

Palme                                                          [Page 11]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

3.10 Language information

Can include a code for the           Language:       RFC 1327, not for
natural language used in a                           general usage.
message, e.g. "en" for English.

Can include a code for the           Content-        RFC 1766, proposed
natural language used in a           Language:       standard.
message, e.g. "en" for English.

3.11 Size information

Inserted by certain mailers to       Content-        Non-standard,
indicate the size in bytes of the    length:         discouraged.
message text. Can cause several
robustness and interoperability
problems and is not recommended.

Size of the message.                 Lines:          RFC 1036: 2.2.12,
                                                     not standardized
                                                     for use in e-mail.

3.12 Conversion control

The body of this message may not     Conversion:     RFC 1327, not for
be converted from one character                      general usage.
set to another.

The body of this message may not     Conversion-     RFC 1327, not for
be converted from one character      With-Loss:      general usage.
set to another if information
will be lost.

3.13 Encoding information

Format of content (character set     Content-Type:   RFC 1049,
etc.) Note that the values for                       RFC 1123: 5.2.13,
this field are defined in                            RFC 1521: 4.
different ways in RFC 1049 and in
MIME (RFC 1521), look for the
"MIME-version" heading field to
understand if Content-Type is to
be interpreted according to RFC
1049 or according to MIME. The
MIME definition should be used in
generating mail.

Coding method used in content.       Content-        RFC 1521: 5.

Palme                                                          [Page 12]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Coding method used in content.       Encoding:       RFC 1154,
                                                     RFC 1505,
                                                     for limited use.

3.14 Resent-attributes

When manually forwarding a           Resent-Reply-   RFC 822: C.3.3.
message, attributes referring to     To:,
the forwarding, not to the           Resent-From:,
original message.  Note: MIME        Resent-
specifies another way of             Sender:,
resending messages, using the        Resent-From:,
"Message" Content-Type.              Resent-Date:,

3.15 Miscellaneous

Name of file in which a copy of      Fcc:            Non-standard.
this message is stored.

Has been automatically forwarded.    Auto-           RFC 1327, not for
                                     Forwarded:      general usage.

Can be used in Internet mail to      Discarded-      RFC 1327, not for
indicate X.400 extensions which      X400-IPMS-      general usage.
could not be mapped to Internet      Extensions:
mail format.

Can be used in Internet mail to      Discarded-      RFC 1327, not for
indicate X.400 extensions which      X400-MTS-       general usage.
could not be mapped to Internet      Extensions:
mail format.

                          4. Acknowledgments

Harald Tveit Alvestrand, Keith Moore, Nick Smith and several other
people have helped me with compiling this list. I alone take
responsibility for any errors which may still be in the list.

An earlier version of this list has been published as part of [13].

Palme                                                          [Page 13]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                            5. References

Ref.    Author, title                                    IETF status
                                                         (July 1995)
-----   ---------------------------------------------    -----------
-       -
[1]     J. Postel: "Simple Mail Transfer Protocol",      Standard,
        STD 10, RFC 821, August 1982.                    Recommended.

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

[3]     M.R. Horton, R. Adams: "Standard for             Not an offi-
        interchange of USENET messages", RFC 1036,       cial IETF
        December 1987.                                   standard,
                                                         but in
                                                         reality a de-
                                                         standard for
                                                         Usenet News.

[4]     M. Sirbu: "A Content-Type header field for       Standard,
        internet messages", RFC 1049, March 1988.        Recommended.

[5]     R. Braden (editor): "Requirements for            Standard,
        Internet Hosts -- Application and Support",      Required.
        STD-3, RFC 1123, October 1989.

[6]     D. Robinson, R. Ullman: "Encoding Header         Non-
        Field for Internet Messages", RFC 1154, April    standard.

[7]     S. Hardcastle-Kille: "Mapping between            Proposed
        X.400(1988) / ISO 10021 and RFC 822",  RFC       standard,
        1327 May 1992.                                   elective.

[8]     H. Alvestrand & J. Romaguera: "Rules for         Proposed
        Downgrading Messages from X.400/88 to            standard,
        X.400/84 When MIME Content-Types are Present     elective.
        in the Messages", RFC 1496, August 1993.

[9]     A. Costanzo: "Encoding Header Field for          Non-
        Internet Messages", RFC 1154, April 1990.        standard.

[10]    A. Costanzo, D. Robinson: "Encoding Header       Experimental
        Field for Internet Messages", RFC 1505,          .
        August 1993.

Palme                                                          [Page 14]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

[11]    N. Borenstein & N. Freed: "MIME (Multipurpose    Draft
        Internet Mail Extensions) Part One:              Standard,
        Mechanisms for Specifying and Describing the     elective.
        Format of Internet Message Bodies", RFC 1521,
        Sept 1993.

[12]    H. Alvestrand: "Tags for the Identification      Proposed
        of Languages", RFC 1766, February 1995.          standard,

[13]    J. Palme: "Electronic Mail", Artech House        Non-
        publishers, London-Boston January 1995.          standard.

[14]    R. Troost, S. Dorner: "Communicating             Experimental
        Presentation Information in Internet             .
        Messages: The Content-Disposition Header",
        RFC 1806, June 1995.

                          6. Author's address

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University/KTH             Fax: +46-8-783 08 29
Electrum 230                         E-mail: jpalme@dsv.su.se
S-164 40 Kista, Sweden

Palme                                                          [Page 15]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                             Appendix A:
Attributes sorted by Internet RFC document in which they appear.

RFC 821


RFC 822


RFC 1036


Palme                                                          [Page 16]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

RFC 1049


RFC 1327

Message-Type Delivery

RFC 1505


RFC 1521


RFC 1806


Palme                                                          [Page 17]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

Not Internet standard


Palme                                                          [Page 18]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

                             Appendix B:
                         Alphabetical index

Section Heading-field
------- -------------

3.3     Alternate-Recipient
3.4     Apparently-To
3.4     Approved
3.16    Auto-Forwarded
3.4     Bcc
3.4     Cc
3.7     Content-Description
3.3     Content-Disposition
3.6     Content-ID
3.7     Content-identifier
3.10    Content-Language
3.11    Content-Length
3.5     Content-Return
3.13    Content-Transfer-Encoding
3.13    Content-Type
3.3     Control
3.12    Conversion
3.12    Conversion-With-Loss
3.3     DATA
3.8     Date
3.8     Delivery-Date
3.16    Discarded-X400-IPMS-Extensions
3.16    Discarded-X400-MTS-Extensions
3.3     Disclose-Recipients
3.5     Disposition-Notification-To
3.4     Distribution
3.3     DL-Expansion-History-Indication
3.13    Encoding
3.5     Errors-To
3.8     Expires
3.4     Fax
3.15    Fcc
3.5     Followup-To
3.4     From
3.5     Generate-Delivery-Report
3.9     Importance
3.6     In-Reply-To
3.9     Incomplete-Copy
3.7     Keywords
3.10    Language
3.11    Lines
3.2     MAIL FROM
3.4     Mail-System-Version
3.4     Mailer
3.6     Message-ID
3.3     Message-Type

Palme                                                          [Page 19]

draft-ietf-mailext-mail-attributes-03.txt                 November 1995

3.3     MIME-Version
3.4     Newsgroups
3.6     Obsoletes
3.7     Organisation
3.7     Organization
3.3     Original-encoded-Information-Types
3.4     Originating-Client
3.3     Path
3.4     Phone
3.9     Precedence
3.5     Prevent-NonDelivery-Report
3.9     Priority
3.2     RCPT TO
3.3     Received
3.6     References
3.8     Reply-By
3.5     Reply-To
3.14    Resent-
3.5     RET in DRPT SMTP extension
3.2     Return-Path
3.5     Return-Receipt-To
3.4     Sender
3.9     Sensitivity
3.7     Subject
3.7     Summary
3.6     Supersedes
3.4     Telefax
3.4     To

Palme                                                          [Page 20]