view Side-By-Side changes
Common Internet Message Attributes 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 RFC-s.. RFCs.. Distribution of this memo is unlimited.
Abstract
This memo contains a table of commonly occurring attributes headers in headings and on envelopes of
e-mail messages. The document compiles information from other RFC-s RFCs such
as RFC 821, RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766 1766,
RFC 1806 and RFC 1806. 1864. A few commonly occurring attributes headers which are not
defined in RFC-s RFCs are also included. For each attribute, header, the memo gives a
short description and a reference to the RFC, RFC in which the attribute header 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
draft-ietf-mailext-mail-attributes-04.txt May 1996
Table of contents
1. Introduction
2. Use of gatewaying attributes headers
3. Table of attributes headers
3.1 Phrases used in the tables
3.2 Addressing Trace information
3.3 Envelope Format and format control information
3.4 Sender and recipient indication
3.5 Response control
3.6 Message identification and referral attributes headers
3.7 Other textual attributes headers
3.8 Attributes 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-attributes Resent-headers
3.15 Security and reliability
3.16 Miscellaneous
4. Acknowledgments
5. References
6. Author's address
Appendix A: Attributes Headers 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
draft-ietf-mailext-mail-attributes-04.txt May 1996
1. Introduction
Many different Internet standards and RFC-s RFCs define attributes headers which
may occur on Internet Mail Messages and Network News Articles. The
intention of this document is to list all such attributes headers in one
document as an aid to people developing message systems or interested
in Internet Mail standards.
The document contains all heading attributes headers 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 [12], RFC 1806 [14]. [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 1421-1424, "Privacy Enhancement for Internet
Electronic Mail", 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 attributes headers which often can be found in e-mail headings but are
not part of any Internet standard are also included.
For each heading attribute, 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 attributes headers
RFC 1327 defines a number of new attributes headers in Internet mail, which
are defined to map attributes headers which X.400 has but which were
previously not standardized in Internet mail. The fact that an
attribute 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 attribute header is recommended for messages wholly
within Internet mail. Some of these attributes headers may eventually get
accepted also for usage within see
widespread implementation and use in Internet mail, but they are, when at the time of
this is written (July 1995) writing (May 1996) they are not recommended for such usage.
Fields 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 fields headers 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 caution by e-mail headers sometimes with
English, sometimes with American spelling.
Palme [Page 3]
draft-ietf-mailext-mail-attributes-03.txt November 1995 agents.
3. Table of attributes headers
3.1 Phrases used in the tables
"not for general Used to mark attributes headers which are defined in
usage" RFC
usage" 1327 for use in messages from or to Internet
mail/X.400 gateways. These attributes headers have not
been standardized for general usage in the
exchange of messages between Internet
mail-based mail-
based systems.
"not standardized Used to mark attributes headers defined only in RFC 1036
for use in e-mail" 1036 for use in Usenet News. These attributes headers have no
standard meaning when appearing in e-
mail, 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 header is not specified in any of
those
referenced RFC-s RFCs which are define Internet
standards,
protocols, including Internet Standards, draft
standards or proposed standards. The attribute header
appears here because it is common often appears in e-mail e-
mail or Usenet News headers. News. Usage of these attributes headers is
not in general recommended.
Palme [Page 4]
draft-ietf-mailext-mail-attributes-04.txt May 1996
"discouraged" This attribute, header, which is non-standard, is known
to create problems and should not be
generated. Handling of such attributes headers in
incoming mail should be done with great
caution.
"controversial" The meaning and usage of this attribute header is
controversial, i.e. different implementors
have chosen to implement the attribute header in
different ways. Because of this, such
attributes headers
should be handled with caution and
understanding of the different possible
interpretations.
"for limited use" Attributes defined in a so-called
"experimental" Internet standard. These should
be used only if both parties agree.
"experimental" This attribute header is used for newly defined
attributes, headers,
which are to be tried out before entering the
IETF standards track.
Palme [Page 4]
draft-ietf-mailext-mail-attributes-03.txt November 1995 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 Addressing Trace 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 in final delivery, 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
information
All that is inside the envelope. DATA RFC 821,
RFC 1123: 5.2.8.
Trace of MTA-s MTAs which a message has Received: RFC 822: 4.3.2,
has
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.
List of MTA-s passed. Path: RFC 1036: 2.2.6,
not standardized
for use in e-mail.
Palme [Page 5]
draft-ietf-mailext-mail-attributes-04.txt May 1996
Special Usenet News actions. Control: RFC 1036: 2.1.6,
not standardized
for use
only in
e-mail.
Trace of distribution lists DL-Expansion- RFC 1327, Usenet
News, not for
passed. History- general usage.
Indication
Palme [Page 5]
draft-ietf-mailext-mail-attributes-03.txt November 1995 in e-
mail.
Which body part types occur in Original- RFC 1327, not for
this message. Encoded- general usage.
Information-
Types:
Special informational message. Message-Type: RFC 1327, not for
Delivery general usage.
Report
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, such 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: cc: and Bcc:
heading fields.
bcc: headers.
Whether a MIME body part is to be Content- RFC 1806,
shown inline or is an attachment, attachment; Disposition: experimental
can also indicate a suggested
filename for use when saving an
attachment to a file.
3.4 Sender and recipient
indication
Author, approver
Authors or persons taking From: RFC 822: 4.4.1,
responsibility for the message. RFC 1123: 5.2.15-
16, 5.3.7.
Moderator 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.
Sender information inside
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,
envelope.
the message to the network, if RFC 1123: 5.2.15-
other than shown by the From: 16, 5.3.7.
Main
header.
Primary recipients. To: RFC 822: 4.5.1,
RFC 1123: 5.2.15-
16, 5.3.7.
Additional recipients. Cc:
Secondary, informational cc: RFC 822: 4.5.2,
recipients. (cc = Carbon Copy) 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: 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 group(s) to which Newsgroups: RFC 1036: 2.1.3,
this article was posted. not standardized
Some systems provide this field header and controversial
also in e-mail although it is not for use in e-mail.
standardized there.
Unfortunately, the field 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, MTA-s 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.
Limitation on where this message
Geographical or organizational Distribution: RFC 1036: 2.2.7,
limitation on where this message not standardized
can be distributed. not standardized 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:
Palme [Page 7]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Client:, X-
Mailer, X-
Newsreader
3.5 Response control
This heading field header is meant to indicate Reply-To: RFC 822: 4.4.3,
indicate
where the sender wants controversial. 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).
There has been various
suggestions to differentiate
between these two uses of "Reply-
To", with new
Some mail systems use this header fields names
"Personal-Reply-To", "Group-Reply-
To" or "Wide-Reply-To". None of
these proposals have been
accepted.
In practice, "Reply-To" is often
used
to indicate a neater format
for better form of 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"
field.
A well-known sender.
Some mailing list
software will optionally insert
"Reply-To" with expanders puts
the name of the list into messages distributed by
the list. in this
header. These practices are
controversial. The personal
opinion of the author of this RFC
is that you this header should avoid
using "Reply-To" until IETF has
defined less ambiguous
constructs. This opinion be
avoided except in special cases,
but this is
however also controversial and a personal opinion
not shared by everyone.
Palme [Page 8]
draft-ietf-mailext-mail-attributes-03.txt November 1995 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 heading field header is used in
a message which is sent to both e-mail e-
mail and Usenet News, to show
where follow-up in Usenet news is
wanted. The field 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, 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. 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 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 headers
Unique ID of this message. Message-ID: RFC 822: 4.6.1. 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. 4.6.3
messages. RFC 1036: 2.1.5.
Reference to previous message Obsoletes: RFC 1327, not for
being corrected and replaced. general usage.
Used
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 Usenet News the server, while
Obsoletes is implemented in similar Supersedes: Non-standard.
ways to the "Obsoletes" attribute
described above.
client and often does not remove
the old version of the text.
3.7 Other textual attributes headers
Search keys for data base Keywords: RFC 822: 4.7.1. 4.7.1
retrieval. RFC 1036: 2.2.9.
Title, heading, subject. Often Subject: RFC 822: 4.7.1. 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: 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 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: Identifier: general usage.
Palme [Page 10]
draft-ietf-mailext-mail-attributes-03.txt November 1995
3.8 Attributes 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. 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.
Can be high, normal or low and is
A hint from the originator to the Importance: RFC 1327, not for
only used in the recipient client
recipients about how important a general usage.
(UA).
Can be personal, private, company
message is. Values: High, normal
or low. Not used to control
transmission speed.
How sensitive it is to disclose Sensitivity: RFC 1327, not for
confidential or absent.
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.
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.
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: Length: discouraged.
message text. Can 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 and is not recommended.
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 field header are defined in RFC 1521: 4.
different ways in RFC 1049 and in
MIME (RFC 1521), look for the
"MIME-version" heading field 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 content. a MIME Content- RFC 1521: 5.
message body. Transfer-
Encoding
Palme [Page 12]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Coding method
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 content. 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 limited use.
a kind of boundary information,
some in other ways.
3.14 Resent-attributes Resent-headers
When manually forwarding a Resent-Reply- RFC 822: C.3.3.
message, attributes headers referring to To:, the To:,
forwarding, not to the Resent-From:, original Resent-From:,
message. Note: MIME Resent- specifies Resent-
another way of Sender:, resending Sender:,
messages, using the Resent-From:, "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 which X400-IPMS- general usage.
which could not be mapped to Internet Extensions:
Internet mail format.
Can be used in Internet mail to Discarded- RFC 1327, not for
indicate X.400 MTS extensions which X400-MTS- general usage.
which could not be mapped to Internet 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].
Palme [Page 13]
draft-ietf-mailext-mail-attributes-03.txt November 1995
5. References
Ref. Author, title IETF status
(July 1995)
(May 1996)
----- --------------------------------------------- -----------
- -
[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
STD 10, RFC 821, August 1982. Recommended. Recommended
[2] D. Crocker: "Standard for the format of ARPA Standard,
Internet text messages." STD 11, RFC 822, Recommended. 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. News
[4] M. Sirbu: "A Content-Type header field header for Standard,
internet messages", RFC 1049, March 1988. Recommended. 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. Required
STD-3, RFC 1123, October 1989.
[6] D. Robinson, R. Ullman: "Encoding Header Non-
Field Non-standard
Header for Internet Messages", RFC 1154,
April standard. 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. 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. elective
in the Messages", RFC 1496, August 1993.
[9] A. Costanzo: "Encoding Header Field Header for Non- Non-standard
Internet Messages", RFC 1154, April 1990. standard.
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
Field
Header 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. 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.
elective
[13] J. Palme: "Electronic Mail", Artech House Non- Non-standard
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.
[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
Palme [Page 15]
draft-ietf-mailext-mail-attributes-03.txt November 1995
Appendix A:
Attributes
Headers sorted by Internet RFC document in which they appear.
RFC 821
-------
DATA
MAIL FROM
RCPT TO
RFC 822
-------
Bcc
Cc
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-ToResent-cc
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
Palme [Page 16]
draft-ietf-mailext-mail-attributes-03.txt November 1995
RFC 1049
--------
Content-Type
RFC 1327
--------
Alternate-recipient
Auto-Forwarded
Autoforwarded
Content-identifier
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
Palme [Page 17]
draft-ietf-mailext-mail-attributes-03.txt November 1995
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-03.txt November 1995
draft-ietf-mailext-mail-attributes-04.txt May 1996
Appendix B:
Alphabetical index
Section Heading-field Heading-header
------- ------------- --------------
3.3 Alternate-Recipient
3.4 Apparently-To
3.4 Approved
3.16 Auto-Forwarded
3.4 Bcc bcc
3.4 Cc 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 Content-Identifier
3.10 Content-Language see also Language
3.11 Content-Length
3.5
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.3 DATA
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
3.5 Disposition-Notification-To
Disposition, see Content-Disposition
3.4 Distribution
3.3
3.2 DL-Expansion-History-Indication
3.13 Encoding
3.5 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.15
3.16 Fcc
3.5
3.4 Followup-To
Forwarded, see Auto-Forwarded
3.4 From
3.5
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.2 MAIL FROM
3.4 Mail-System-Version see also X-mailer
3.4 Mailer
MD5 see Content-MD5
3.6 Message-ID
3.3
3.13 Message-Type
Palme [Page 19]
draft-ietf-mailext-mail-attributes-03.txt November 1995
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 Original-Encoded-Information-Types
3.4 Originating-Client
3.3
3.2 Path
3.4 Phone
3.9 Precedence
3.5
3.4 Prevent-NonDelivery-Report
3.9 Priority
3.2 RCPT TO
3.3 Received
Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
Recipient
3.6 References
3.8 Reply-By
3.5 Reply-To
3.4 Reply-To, see also In-Reply-To, References
3.14 Resent-
3.5 RET in DRPT SMTP extension
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]
----