[Search] [txt|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-attributes-02.txt                             Sweden
Category: Informational                                       July 1995
Expires January 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 and RFC 1766. 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.

Palme                                                          [Page 1]

draft-ietf-mailext-attributes-02.txt                          July 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-attributes-02.txt                          July 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]
and RFC 1766 [12]. 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-attributes-02.txt                          July 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"       A so-called "experimental" Internet standard.
                        These should be used only if both parties

Palme                                                          [Page 4]

draft-ietf-mailext-attributes-02.txt                          July 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-attributes-02.txt                          July 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.

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.

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

Palme                                                          [Page 6]

draft-ietf-mailext-attributes-02.txt                          July 1995

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
newsgroup, indicates 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-attributes-02.txt                          July 1995

3.5 Response control

Replacement for "From:" to which     Reply-To:       RFC 822: 4.4.3,
replies are to be sent.                              controversial.
Unfortunately, the specification
in RFC 822 is ambiguous, since
some people want this to be a
replacement for all recipients in
commands to send replies to all
recipients of the replied-to
message. The most general
consensus, however, seems to be
that "Reply-To" only indicates
replacement for the "From" field,
not for all the recipients.

Where group replies to this          Followup-To:    RFC 1036: 2.2.3,
message are to be sent.                              not standardized
                                                     for use in e-mail.

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 notifications are to be
sent, and a new standard under
development specifies how
requests for notifications are
specified by a new parameter

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.

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

Palme                                                          [Page 8]

draft-ietf-mailext-attributes-02.txt                          July 1995

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 earlier in this

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.                    Organisation:   Non-standard.

Short text describing a longer       Summary:        RFC 1036: 2.2.10,
message.                                             not standardized
                                                     for use in e-mail.

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

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.

Palme                                                          [Page 9]

draft-ietf-mailext-attributes-02.txt                          July 1995

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.

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.

Palme                                                         [Page 10]

draft-ietf-mailext-attributes-02.txt                          July 1995

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 is 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.

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

Palme                                                         [Page 11]

draft-ietf-mailext-attributes-02.txt                          July 1995

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 12]

draft-ietf-mailext-attributes-02.txt                          July 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             Non-standard
        interchange of USENET messages", RFC 1036,       (but still
        December 1987.                                   widely used).

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

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

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

[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 X.400/84   standard,
        When MIME Content-Types are Present in the       elective.
        Messages", RFC 1496, August 1993.

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

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

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

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

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

Palme                                                         [Page 13]

draft-ietf-mailext-attributes-02.txt                          July 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

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

RFC 821


RFC 822


Palme                                                         [Page 14]

draft-ietf-mailext-attributes-02.txt                          July 1995

RFC 1036


RFC 1049


RFC 1327

Message-Type Delivery

RFC 1505


Palme                                                         [Page 15]

draft-ietf-mailext-attributes-02.txt                          July 1995

RFC 1521


Not Internet standard


Palme                                                         [Page 16]

draft-ietf-mailext-attributes-02.txt                          July 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.6     Content-ID
3.7     Content-identifier
3.10    Content-Language
3.11    Content-Lenght
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.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
3.3     MIME-Version
3.4     Newsgroups

Palme                                                         [Page 18]

draft-ietf-mailext-attributes-02.txt                          July 1995

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 19]