[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-mail-attributes-04.txt                        Sweden
Category: Informational                                        May 1996
Expires November 1996





                  Common Internet Message Headers

                        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 RFCs.. Distribution of this memo is unlimited.



                            Abstract

This memo contains a table of commonly occurring headers in headings of
e-mail messages. The document compiles information from other RFCs such
as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766,
RFC 1806 and RFC 1864. A few commonly occurring headers which are not
defined in RFCs are also included. For each header, the memo gives a
short description and a reference to the RFC in which the header is
defined.







Palme                                                           [Page 1]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996


                         Table of contents

1. Introduction

2. Use of gatewaying headers

3. Table of headers

   3.1 Phrases used in the tables
   3.2 Trace information
   3.3 Format and control information
   3.4 Sender and recipient indication
   3.5 Response control
   3.6 Message identification and referral headers
   3.7 Other textual headers
   3.8 Headers containing dates and times
   3.9 Quality information
   3.10 Language information
   3.11 Size information
   3.12 Conversion control
   3.13 Encoding information
   3.14 Resent-headers
   3.15 Security and reliability
   3.16 Miscellaneous

4. Acknowledgments

5. References

6. Author's address

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

Appendix B: Alphabetical index


















Palme                                                           [Page 2]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996


                         1. Introduction

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

The document contains all headers which the author has
found in the following Internet standards: , RFC 822 [2],
RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11],
RFC 1766 [12], RFC 1806 [14] and RFC 1864[17]. Note in particular that
heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
[16]) are not included. PEM and MOSS headers only appear inside the
body of a message, and thus are not headers in the RFC 822 sense. Mail
attributes in envelopes, i.e. attributes controlling the message
transport mechanism between mail and news servers, are not included.
This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are
not covered either. Headings used only in HTTP [19] are not included
yet, but may be included in future version of this memo. A few
additional headers which often can be found in e-mail headings but are
not part of any Internet standard are also included.

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

The header names given here are spelled the same way as when they are
actually used. This is usually American but sometimes English spelling.
One header in particular, "Organisation/Organization", occurs in e-mail
headers sometimes with the English and other times with the American
spelling.

The following words are used in this memo with the meaning specified
below:

heading           Formatted text at the top of a message, ended by a
                  blank line

header = heading  One field in the heading, beginning with a field
field             name, colon, and followed by the field value(s)

It is my intention to continue updating this document after its
publication as an RFC. The latest version, which may be more up-to-date
(but also less fully checked out) will be kept available for
downloading by anonymous FTP from URL
http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf.

Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
headers which should be included in this memo but are not.




Palme                                                           [Page 3]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

                 2. Use of gatewaying headers

RFC 1327 defines a number of new headers in Internet mail, which
are defined to map headers which X.400 has but which were
previously not standardized in Internet mail. The fact that a
header 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 header is recommended for messages wholly
within Internet mail. Some of these headers may eventually see
widespread implementation and use in Internet mail, but at the time of
this writing (May 1996) they are not widely implemented or used.

Headers 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 headers are not standardized for use in Internet e-mail
and should be handled with caution by e-mail agents.




                      3. Table of headers

3.1 Phrases used in the tables


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

"not standardized       Used to mark headers defined only in RFC 1036
for use in e-mail"      for use in Usenet News. These headers 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 header is not specified in any of
                        referenced RFCs which define Internet
                        protocols, including Internet Standards, draft
                        standards or proposed standards. The header
                        appears here because it often appears in e-
                        mail or Usenet News. Usage of these headers is
                        not in general recommended.



Palme                                                           [Page 4]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

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

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

"experimental"          This header is used for newly defined headers,
                        which are to be tried out before entering the
                        IETF standards track. These should only be
                        used if both communicating parties agree on
                        using them. In practice, some experimental
                        protocols become de-facto-standards before
                        they are made into IETF standards.



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

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

List of MTAs passed.                 Path:           RFC 1036: 2.2.6,
                                                     only in Usenet
                                                     News, not in e-
                                                     mail.

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

3.3 Format and control
information

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



Palme                                                           [Page 5]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

Special Usenet News actions.         Control:        RFC 1036: 2.1.6,
                                                     only in Usenet
                                                     News, not in e-
                                                     mail.

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

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:
Allowed.

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. In
X.400, this is an envelope
attribute and refers to
disclosure of the envelope
recipient list. Disclosure of
other recipients is in Internet
mail done via the To:, cc: and
bcc: headers.

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
indication

Authors or persons taking            From:           RFC 822: 4.4.1,
responsibility for the message.                      RFC 1123: 5.2.15-
                                                     16, 5.3.7,
                                                     RFC 1036 2.1.1

Name of the moderator of the         Approved:       RFC 1036: 2.2.11,
newsgroup to which this message                      not standardized
is sent; necessary on an article                     for use in e-mail.
sent to a moderated newsgroup to
allow its distribution to the
newsgroup members. Also used on
certain control messages, which
are only performed if they are
marked as Approved.



Palme                                                           [Page 6]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

The person or agent submitting       Sender:         RFC 822: 4.4.2,
the message to the network, if                       RFC 1123: 5.2.15-
other than shown by the From:                        16, 5.3.7.
header.

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

Secondary, informational             cc:             RFC 822: 4.5.2,
recipients. (cc = Carbon Copy)                       RFC 1123. 5.2.15-
                                                     16, 5.3.7.

Recipients not to be disclosed to    bcc:            RFC 822: 4.5.3,
other recipients. (bcc = Blind                       RFC 1123: 5.2.15-
Carbon Copy).                                        16, 5.3.7.

In Usenet News: group(s) to which    Newsgroups:     RFC 1036: 2.1.3,
this article was posted.                             not standardized
Some systems provide this header                     and controversial
also in e-mail although it is not                    for use in e-mail.
standardized there.
Unfortunately, the header can
appear in e-mail with two
different and contradictory
meanings:
(a) Indicates the newsgroup
recipient of a message sent to
both e-mail and Usenet News
recipients.
(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, MTAs should not
modify headings (except inserting
Received lines), and it can in
some cases cause Bcc recipients
to be wrongly divulged to non-Bcc
recipients.

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




Palme                                                           [Page 7]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

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


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

Information about the client         Mail-System-    Non-standard.
software of the originator.          Version:,
                                     Mailer:,
                                     Originating-
                                     Client:, X-
                                     Mailer, X-
                                     Newsreader

3.5 Response control

This header is meant to indicate     Reply-To:       RFC 822: 4.4.3,
where the sender wants replies to                    RFC 1036: 2.2.1
go. Unfortunately, this is                           controversial.
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).

Some mail systems use this header
to indicate a better form of the
e-mail address of the sender.
Some mailing list expanders puts
the name of the list in this
header. These practices are
controversial. The personal
opinion of the author of this RFC
is that this header should be
avoided except in special cases,
but this is a personal opinion
not shared by all specialists in
the area.

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.

Palme                                                           [Page 8]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

In e-mail, this header 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 header does not say
anything about where follow-up in
e-mail is to be sent.

Note that the value of this
header must always be one or more
newsgroup names, never e-mail
addresses.

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.

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:
report.

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

3.6 Message identification and
referral headers

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

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
messages.                                            RFC 1036: 2.1.5.

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


Palme                                                           [Page 9]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

Commonly used in Usenet News in      Supersedes:     Non-standard.
similar ways to the "Obsoletes"
header described above. In Usenet
News, however, Supersedes causes
a full deletion of the replaced
message in the server, while
Obsoletes is implemented in the
client and often does not remove
the old version of the text.

3.7 Other textual headers

Search keys for data base            Keywords:       RFC 822: 4.7.1
retrieval.                                           RFC 1036: 2.2.9.

Title, heading, subject. Often       Subject:        RFC 822: 4.7.1
used as thread indicator for                         RFC 1036: 2.1.4.
messages replying to or
commenting on other messages.

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

3.8 Headers 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.                    RFC 1036: 2.1.2.
Some Internet mail systems also
use the date when the message was
submitted.

Palme                                                          [Page 10]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

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.

A hint from the originator to the    Importance:     RFC 1327, not for
recipients about how important a                     general usage.
message is. Values: High, normal
or low. Not used to control
transmission speed.

How sensitive it is to disclose      Sensitivity:    RFC 1327, not for
this message to other people than                    general usage.
the specified recipients. Values:
Personal, private, company
confidential. The absence of this
header in messages gatewayed from
X.400 indicates that the message
is not sensitive.

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.



Palme                                                          [Page 11]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

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. This is part of a
format some mailers use when
showing a message to its users,
and this header should not be
used when sending a message
through the net. The use of this
header in transmission of a
message can cause several
robustness and interoperability
problems.

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. Values:
Prohibited and allowed.

Non-standard variant of              Content-        Non-standard.
Conversion: with the same values.    Conversion:

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. Values: Prohibited
and allowed.

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 header are defined in                           RFC 1521: 4.
different ways in RFC 1049 and in
MIME (RFC 1521), look for the
"MIME-version" header 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.



Palme                                                          [Page 12]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

Coding method used in a MIME         Content-        RFC 1521: 5.
message body.                        Transfer-
                                     Encoding:

Only used with the value             Message-Type:   RFC 1327, not for
"Delivery Report" to indicates                       general usage.
that this is a delivery report
gatewayed from X.400.

Used in several different ways by    Encoding:       RFC 1154,
different mail systems. Some use                     RFC 1505,
it for a kind of content-type                        experimental.
information, some for encoding
and length information, some for
a kind of boundary information,
some in other ways.

3.14 Resent-headers

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

3.15 Security and reliability

Checksum of content to ensure        Content-MD5:    RFC 1864, proposed
that it has not been modified.                       standard.

3.16 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 IPM extensions        X400-IPMS-      general usage.
which could not be mapped to         Extensions:
Internet mail format.

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

Palme                                                          [Page 13]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996


                          4. Acknowledgments

Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Keith Moore, Nick
Smith and several other people have helped me with compiling this list.
I especially thank Ned Freed and Olle Järnefors for their thorough
review and many helpful suggestions for improvements. 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].



                            5. References

Ref.    Author, title                                    IETF status
                                                         (May 1996)
-----   ---------------------------------------------    -----------
[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-
                                                         facto
                                                         standard for
                                                         Usenet News

[4]     M. Sirbu: "A Content-Type header header for      Standard,
        internet messages", RFC 1049, March 1988.        Recommended,
                                                         but can in
                                                         the future
                                                         be expected
                                                         to be
                                                         replaced by
                                                         MIME

[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-standard
        Header for Internet Messages", RFC 1154,
        April 1990.





Palme                                                          [Page 14]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

[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 Header for         Non-standard
        Internet Messages", RFC 1154, April 1990.

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

[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,
                                                         elective

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

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

[15]    B. Kantor, P. Lapsley, "Network News Transfer    Proposed
        Protocol: "A Proposed Standard for the Stream-   standard
        Based Transmission of News", RFC 977, January
        1986.
[16]    1848  PS   S. Crocker, N. Freed, J. Galvin,      Proposed
        S. Murphy, "MIME Object Security Services",      standard
        RFC 1848, March 1995.

[17]    J. Myers, M. Rose: The Content-MD5 Header        Draft
        Header, RFC 1864, October 1995.                  standard

[18]    M. Horton, UUCP mail interchange format          Not an offi-
        standard, RFC 976, Januari 1986.                 cial IETF
                                                         standard,
                                                         but in
                                                         reality a de-
                                                         facto
                                                         standard for
                                                         Usenet News


Palme                                                          [Page 15]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

[19]    T. Berners-Lee, R. Headering, H. Frystyk:        IETF draft
        Hypertext Transfer Protocol -- HTTP/1.0,
        draft-ietf-http-v10-spec-04.txt.



                          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:
Headers sorted by Internet RFC document in which they appear.


RFC 822
-------

bcc
cc
Comments
Date
From
In-Reply-To
Keywords
Message-ID
Received
References
Reply-To
Resent-
Resent-bcc
Resent-cc
Resent-Date
Resent-From
Resent-From
Resent-Message-ID
Resent-Reply-To
Resent-To
Return-Path
Sender
Sender
Subject
To







Palme                                                          [Page 16]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

RFC 1036
--------

Approved
Control
Distribution
Expires
Followup-To
Lines
Newsgroups
Organization
Path
Summary

RFC 1049
--------

Content-Type

RFC 1327
--------

Alternate-recipient
Auto-Forwarded
Autoforwarded
Content-Identifier
Content-Return
Conversion
Conversion-With-Loss
Delivery-Date
Discarded-X400-IPMS-Extensions
Discarded-X400-MTS-Extensions
Disclose-Recipients
DL-Expansion-History
Expiry-Date
Generate-Delivery-Report
Importance
Incomplete-Copy
Language
Message-Type Delivery
Obsoletes
Original-Encoded-Information-Types
Prevent-NonDelivery-Report
Priority
Reply-By
Report
Sensitivity

RFC 1505
--------

Encoding


Palme                                                          [Page 17]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

RFC 1521
--------

Content-Description
Content-ID
Content-Transfer-Encoding
Content-Type
MIME-Version

RFC 1806
--------

Content-Disposition

RFC 1864
--------

Content-MD5

Not Internet standard
---------------------

Apparently-to
Content-length
Encoding
Errors-To
Return-Receipt-To
Fax
Telefax
Fcc
Mail-System-Version
Mailer
Organisation
Originating-Client
Phone
Supersedes
X-Mailer
X-Newsreader


















Palme                                                          [Page 18]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

                             Appendix B:
                         Alphabetical index

Section Heading-header
------- --------------

3.3     Alternate-Recipient
3.4     Apparently-To
3.4     Approved
3.16    Auto-Forwarded
3.4     bcc
3.4     cc
        Client, see Originating-Client
3.7     Comments
3.12    Content-Conversion
3.7     Content-Description
3.3     Content-Disposition
3.6     Content-ID
3.7     Content-Identifier
3.10    Content-Language see also Language
3.11    Content-Length
3.15    Content-MD5
3.4     Content-Return
3.13    Content-Transfer-Encoding
3.13    Content-Type
3.3     Control
3.12    Conversion
3.12    Conversion-With-Loss
3.8     Date
3.8     Delivery-Date
        Delivery-Report, see Generate-Delivery-Report, Prevent-
        Delivery-Report, Non-Delivery-Report, Content-Type
        Description, see Content-Description
3.16    Discarded-X400-IPMS-Extensions
3.16    Discarded-X400-MTS-Extensions
3.3     Disclose-Recipients
        Disposition, see Content-Disposition
3.4     Distribution
3.2     DL-Expansion-History-Indication
3.13    Encoding see also Content-Transfer-Encoding
3.4     Errors-To
3.8     Expires
        Extension see Discarded-X400-IPMS-Extensions, Discarded-
        X400-MTS-Extensions
3.4     Fax
3.16    Fcc
3.4     Followup-To
        Forwarded, see Auto-Forwarded
3.4     From
3.4     Generate-Delivery-Report
        History, see DL-Expansion-History-Indication
        ID, see Content-ID and Message-ID
        Identifier, see Content-ID and Message-ID


Palme                                                          [Page 19]


draft-ietf-mailext-mail-attributes-04.txt                      May 1996

3.9     Importance
3.6     In-Reply-To
3.9     Incomplete-Copy
3.7     Keywords
3.10    Language see also Content-Language
        Length see Content-Length
3.11    Lines
3.4     Mail-System-Version see also X-mailer
3.4     Mailer
        MD5 see Content-MD5
3.6     Message-ID
3.13    Message-Type
3.3     MIME-Version
3.4     Newsgroups
        Newsreader, see X-Newsreader
3.6     Obsoletes
3.7     Organisation
3.7     Organization
3.3     Original-Encoded-Information-Types
3.4     Originating-Client
3.2     Path
3.4     Phone
3.9     Precedence
3.4     Prevent-NonDelivery-Report
3.9     Priority
3.2     Received
        Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
        Recipient
3.6     References
3.8     Reply-By
3.4     Reply-To, see also In-Reply-To, References
3.14    Resent-
        Return see also Content-Return
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
        Transfer-Encoding see Content-Transfer-Encoding
        Type see Content-Type, Message-Type, Original-Encoded-
        Information-Types
        Version, see MIME-Version, X-Mailer
3.4     X-Mailer see also Mail-System-Version
3.4     X-Newsreader






Palme                                                          [Page 20]