|
Network
Working Group
Internet
Draft
draft-palme-mailext-headers-05.txt
Category:
Informational
Revision
of: RFC 2076
|
Jacob
Palme
Stockholm
University/KTH
Sweden
Expires:
April 2002
|
|
This
memo contains tables of commonly occurring header fields in headings
of e-mail messages. The document compiles information from other RFCs
such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC
2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly occurring header
fields which are not defined in RFCs are also included. For each header
field, the memo gives a short description and a reference to the RFC
in which the header field is defined.
The
latest, revised version of this document can be found at URL
http://www.dsv.su.se/jpalme/ietf/mail-headers/.
The version at that
URL
may be more recent than the version published as an RFC.
Another
list of headers can be found at URL
http://www.hut.fi/~jkorpela/headers.html
[28]
|
|
This
document is a revision of RFC 2076. The following new header fields,
not included in RFC 2076, have been added:
Abuse-Reports-To:,
Also-Control, Approved-By, Content-Alias, Content-Alternative, Content-Class,
Content-Conversion, Content-Features, Content-ID, Delivered-To, Disposition-Notification-Options,
Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive,
List-Digest, List-Help, List-ID, List-Owner, List-Post, List-Software,
List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-To:, Original-Recipient,
Originator, Originator-Info, Path, PICS-Label, NNTP-Posting-Host, Posted-To:,
Read-Receipt-To, Received, Registered-Mail-Reply-Requested-By, Replaces,
Return-Receipt-Requested, Speech-Act, Translated-By. Translation-Of,
User-Agent, X-Confirm-Reading-To, X-Complaints-To:, X-Envelope-From,
X-Envelope-To, X-Face, X-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted,
X-No-Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-To,
X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
|
|
Many
different Internet standards and RFCs define header fields which may
occur on Internet Mail Messages and Usenet News Articles. The intention
of this document is to list all such header fields in one document as
an aid to people developing message systems or interested in Internet
Mail standards.
The
document contains all header fields which the author has found in the
following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123 [5],
RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC 2183 [14],
RFC 1864[17] and RFC 2421[20]. Note in particular that heading attributes
defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included.
PEM and MOSS header fields only appear inside the body of a message,
and thus are not header fields 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 mainly not covered either.
Headings used only in HTTP [19] are not included yet, but may be included
in future version of this memo. Some additional header fields which
often can be found in e-mail headings but are not part of any Internet
standard are also included.
The
author does not promise that this document contains a complete list
of all heading fields which are specified in any standard or used by
any mailer.
For
each header field, the document gives a short description and a reference
to the Internet standard or RFC, in which they are defined.
The
header field names given here are spelled the same way as when they
are actually used. This is usually American but sometimes English spelling.
One header field in particular, "Organisation/Organization", occurs
in e-mail header fields 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
field
|
One
field in the heading, beginning with a field name, colon, and followed
by the field value(s). The words "heading field" and "header" are also
sometimes used with this meaning.
|
|
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 from
URL http://www.dsv.su.se/jpalme/ietf/mail-headers
Please
e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted header
fields which should be included in this memo but are not.
|
|
RFC
2156 defines a number of new header fields in Internet mail, which are
defined to map header fields which X.400 has but which were previously
not standardized in Internet mail. The fact that a header field occurs
in RFC 2156 indicates that it is recommended for use in gatewaying messages
between X.400 and Internet mail, but does not mean that the header field
is recommended for messages wholly within Internet mail. Some of these
header fields may eventually see widespread implementation and use in
Internet mail, but at the time of this writing (2001) they are not widely
implemented or used.
Header
fields defined only 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
header fields are not standardized for use in Internet e-mail and should
be handled with caution by e-mail agents.
|
|
"not
for general usage"
|
Used
to mark header fields which are defined in RFC 2156 for use in messages
from or to Internet mail/X.400 gateways. These header fields have not
been standardized for general usage in the exchange of messages between
Internet mail-based systems.
|
|
"not
standardized for use in e-mail"
|
Used
to mark header fields defined only in RFC 1036 for use in Usenet News.
These header fields 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 de-facto standard for Usenet
News, is not an official IETF standard or even on the IETF standards
track.
|
|
"non-standard"
|
This
header field is not specified in any of referenced RFCs which define
Internet protocols, including Internet Standards, draft standards or
proposed standards. The header field appears here because it often appears
in e-mail or Usenet News. Usage of these header fields is not in general
recommended. Some header field proposed in ongoing IETF standards development
work, but not yet accepted, are also marked in this way.
|
|
"discouraged"
|
This
header field, which is non-standard, is known to create problems and
should not be generated. Handling of such header fields in incoming
mail should be done with great caution.
|
|
"controversial"
|
The
meaning and usage of this header field is controversial, i.e. different
implementors have chosen to implement the header field in different
ways. Because of this, such header fields should be handled with caution
and understanding of the different possible interpretations.
|
|
"experimental"
|
This
header field is used for newly defined header fields, 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.
|
|
Trace
of distribution lists passed.
|
DL-Expansion-History:
|
RFC
2156, not for general usage.
|
|
List
of MTAs passed.
|
Path:
|
RFC
1036: 2.1.6, only in Usenet News, not in e-mail.
|
|
Trace
of MTAs which a message has passed.
|
Received:
|
RFC
822: 4.3.2, RFC 1123: 5.2.8.
|
|
Used
to convey the information from the MAIL FROM envelope attribute in final
delivery, when the message leaves the SMTP environment in which "MAIL
FROM" is used.
|
Return-Path:
|
RFC
821,
RFC
1123: 5.2.13.
|
|
The
netnews host, to which this article was originally posted. Useful for
finding the sender of spams. Since this header is added by the news
server, it is a little more difficult to forge than other header fields.
|
NNTP-Posting-Host:
|
Non-standard,
common in netnews
|
|
Special
Usenet News commands and a normal article at the same time.
|
Also-Control:
|
son-of-RFC1036
[21], non-standard, only in Usenet News, not in e-mail
|
|
Controls
whether this message may be forwarded to alternate recipients such as
a postmaster if delivery is not possible to the intended recipient.
Default: Allowed.
|
Alternate-Recipient:
|
RFC
2156, not for general usage.
|
|
Whether
a MIME body part is to be shown inline or is an attachment; can also
indicate a suggested filename for use when saving an attachment to a
file.
|
Content-Disposition:
|
RFC
2183, experimental
|
|
Can
have the values "voice-message", "fax-message", "pager-message", "multimedia-message",
"text-message", "none"
|
Message-Context:
|
Non-standard
|
|
Only
in Usenet News, contains commands to be performed by News agents.
|
Control:
|
RFC
1036: 2.1.6, only in Usenet News, not in e-mail.
|
|
Whether
recipients are to be told the names of other recipients of 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:
header fields.
|
Disclose-Recipients:
|
RFC
2156, not for general usage.
|
|
An
indicator that this message is formatted according to the MIME standard,
and an indication of which version of MIME is utilized.
|
MIME-Version:
|
RFC
2045: 4.
|
|
Which
body part types occur in this message.
|
Original-Encoded-Information-Types:
|
RFC
2156, not for general usage.
|
|
Inserted
by Sendmail when there is no "To:" recipient in the original message,
listing recipients derived from the 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.
|
Apparently-To:
|
Non-standard,
discouraged, mentioned in
RFC
1211.
|
|
Name
of the moderator of the newsgroup to which this article is sent; necessary
on an article 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.
|
Approved:
|
RFC
1036: 2.2.11, not standardized for use in e-mail.
|
|
Name
of the moderator of a mailing list, and who has approved this message
for distribution to the members of the list.
|
Approved-By:
|
Non-standard,
used by some mailing list expansion systems.
|
|
Recipients
not to be disclosed to other recipients. (bcc = Blind Carbon Copy).
|
bcc:
|
RFC
822: 4.5.3,
RFC
1123: 5.2.15-16, 5.3.7.
|
|
Secondary,
informational recipients. (cc = Carbon Copy)
|
cc:
|
RFC
822: 4.5.2,
RFC
1123. 5.2.15-16, 5.3.7.
|
|
Geographical
or organizational limitation on where this article can be distributed.
Value can be a compete or incomplete domain names, also various special
values are accepted like "world", "usenet", "USA", etc.
|
Distribution:
|
RFC
1036: 2.2.7, not standardized for use in e-mail.
|
|
Fax
number of the originator.
|
Fax:,
Telefax:
|
Non-standard.
|
|
Primary
recipients, who are requested to approve the information in this message
or its attachments.
|
For-Approval:
|
Non-standard
|
|
Primary
recipients, who are requested to comment on the information in this
message or its attachments.
|
For-Comment:
|
Non-standard
|
|
Primary
recipients, who are requested to handle the information in this message
or its attachments.
|
For-Handling:
|
Non-standard
|
|
(2)
Used in Usenet News mail transport, to indicate the path through which
an article has gone when transferred to a new host.
Sometimes
called "From_" header field.
|
From
or
>From
(not
followed by a colon)
|
RFC
976: 2.4 for use in Usenet News
|
|
(1)
This header field should never appear in e-mail being sent, and should
thus not appear in this memo. It is however included, since people often
ask about it.
This
header field is used in the so-called Unix mailbox format, also known
as Berkely mailbox format or the MBOX format. This is a format for storing
a set of messages in a file. A line beginning with "From " is used to
separate successive messages in such files.
This
header field will thus appear when you use a text editor to look at
a file in the Unix mailbox format. Some mailers also use this format
when printing messages on paper.
The
information in this header field should NOT be used to find an address
to which replies to a message are to be sent.
|
From
(not followed by a colon)
|
not
standardized for use in e-mail
|
|
Authors
or persons taking responsibility for the message.
Note
difference from the "From " header field (not followed by ":") below.
|
From:
|
RFC
822: 4.4.1,
RFC
1123: 5.2.15-16, 5.3.7,
RFC
1036 2.1.1
|
|
Information
about the client software of the originator.
|
Mail-System-Version:,
Mailer:, Originating-Client:, X-Mailer, X-Newsreader, X-MimeOLE:, User-Agent:
|
Non-standard.
|
|
In
Usenet News: group(s) to which this article was posted.
Some
systems provide this header field also in e-mail although it is not
standardized there.
Unfortunately,
the header field can appear in e-mail with three different and contradictory
meanings:
(a)
Indicating the newsgroup recipient of an article/message sent to both
e-mail and Usenet News recipients.
(b)
In a message adressed to some mail to news gateways, indicates the newsgroup(s)
that the message is to be posted to.
(c)
In a personally addressed reply to an article in a news-group, indicating
the newsgroup in which this discussion originated.
See
also: "Posted-To:".
|
Newsgroups:
|
RFC
1036: 2.1.3, not standardized and controversial for use in e-mail.
|
|
Sometimes
used in Usenet News in similar ways to "Sender:"
Also
used in printing protocols.
|
Originator:
|
Non-standard
in Usenet News, Experimental in RFC 1528.
|
|
Contains
information about the authentication of the originator in a format which
is not easily used to send email to, to avoid the problems with "Sender"
and "X-Sender".
|
Originator-Info:
|
Non-standard
[25]
|
|
Phone
number of the originator.
|
Phone:
|
Non-standard.
|
|
The
person or agent submitting the message to the network, if other than
shown by the From: header field. Should be authenticated,
according
to RFC 822, but what
kind
of authentication is not
clear.
Some implementations expect that the e-mail address used in this field
can be used to reach the sender, others do not. See also "X-Sender".
|
Sender:
|
RFC
822: 4.4.2,
RFC
1123: 5.2.15-16, 5.3.7, RFC 1036.
|
|
Primary
recipients.
|
To:
|
RFC
822: 4.5.1,
RFC
1123: 5.2.15-16, 5.3.7.
|
|
If
the sender in the envelope (SMTP "RCTP TO") is not the same as the senders
in the "From" or "Sender" RFC822 header fields, some mail servers add
this to the RFC822 header fields as an aid to clients which would otherwise
not be able to display this information.
|
X-Envelope-From:
|
Non-standard.
|
|
If
the recipient in the envelope (SMTP "MAIL FROM") is not included in
the CC list, some mail servers add this to the RFC822 header field as
an aid to clients which would otherwise not be able to display the envelope
recipients.
|
X-Envelope-To:,
Envelope-To: |
Non-standard.
|
|
48x48
bitmap with picture of the sender of this message.
|
X-Face:
|
Non-Standard
|
|
Indication
in the mail header of recipient on the SMTP envelope.
|
X-RCPT-TO:
|
Non-standard
|
|
Some
mail software expect "Sender:" to be an e-mail address which you can
send mail to. However, some mail software has as the best authenticated
sender a POP or IMAP account, which you might not be able to send to.
Because of this, some mail software put the POP or IMAP account into
an X-sender header field instead of a Sender header field, to indicate
that you may not be able to send e-mail to this address. See also "X-X-Sender".
Another
use of" X-Sender:" is that some e-mail software, which wants to insert
a "Sender:" header, will first change an existing "Sender:" header to
"X-Sender". This use is actually often the same as that described in
the previous paragraph, since the new "Sender:" is added because it
is better authenticated than the old value.
|
X-Sender:
|
Non-standard
|
|
Even
though some systems put the POP or IMAP account name into the "X-Sender:"
instead of the Sender header field, some mail software tries to send
to the "X-Sender:" too. To stop this, some systems have begun to use
"X-X-Sender:" to indicate an authentication of the sender which might
not be useable to send e-mail to. See also "Originator-Info:"
|
X-X-Sender:
|
Non-standard
|
|
When
a message is sent both to netnews and e-mail, this header is used in
the e-mail version of the message to indicate which newsgroup it was
sent to. This header thus contains the same information as the "Newsgroups:"
header in the netnews version of the message.
|
Posted-To:
|
Non-standard
|
|
E-mail
address of administrator of a server, through which this message was
submitted.
|
X-Admin:
|
Non-standard
|
|
Indicates
whether the content of a message is to be returned with non-delivery
notifications.
|
Content-Return:
|
RFC
2156, not for general usage.
|
|
For
future options on disposition notifications.
|
Disposition-Notification-Options:
|
RFC
2298
|
|
Indicate
that the sender wants a dispoisition notification when this message
is received (read, processed, etc.) by its receipents.
|
Disposition-Notification-To:
|
RFC
2298
|
|
Address
to which notifications are to be sent and a request to get delivery
notifications. Internet standards recommend, however, the use of MAIL
FROM and Return-Path, not Errors-To, for where delivery notifications
are to be sent.
|
Errors-To:,
Return-Receipt-To:,
Read-Receipt-To:,
X-Confirm-reading-to:, Return-Receipt-Requested, Register-Mail-Reply-Requested-By:
|
Non-standard,
discouraged, some of them widely used.
|
|
Used
in Usenet News to indicate that future discussions (=follow-up) on an
article should go to a different set of newsgroups than the replied-to
article. The most common usage is when an article is posted to several
newsgroups, and further discussions is to take place in only one of
them.
In
e-mail, this header field may occur 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 field does not say anything about where follow-up in e-mail
is to be sent.
The
value of this header field should be one or more newsgroup names.
The
special value "poster" as in "Followup-To: poster" means that replies
are to be sent as e-mail to the author only.
|
Followup-To:
|
RFC
1036: 2.2.3, not standardized for use in e-mail.
|
|
Whether
a delivery report is wanted at successful delivery. Default is not to
generate such a report.
|
Generate-Delivery-Report:
|
RFC
2156, not for general usage.
|
|
Original
Recipient information for inclusion in disposition notifications.
|
Original-Recipient
|
RFC
2298
|
|
Whether
non-delivery report is wanted at delivery error. Default is to want
such a report.
|
Prevent-NonDelivery-Report:
|
RFC
2156, not for general usage.
|
|
This
header field is meant to indicate where the sender wants replies to
go. Unfortunately, this is ambiguous, since there are different kinds
of replies, which the sender may wish to go to different addresses.
In particular, there are personal replies intended for only one person,
and group replies, intended for the whole group of people who read the
replied-to message (often a mailing list, anewsgroup name cannot appear
here because of different syntax, see "Followup-To" below.).
|
Reply-To:
|
RFC
822: 4.4.3,
RFC
1036: 2.2.1
controversial.
|
|
Some
mail systems use this header field 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 field. These practices are controversial.
The personal opinion of the author of this RFC is that this header field
should be avoided except in special cases, but this is a personal opinion
not shared by all specialists in the area.
|
|
|
|
Indicates
where to send complains if you get a message which you think is against
the laws or rules.
|
Abuse-Reports-To:,
X-Complaints-To:, X-Report-Abuse-To:
|
non-standard
|
|
Used
in netnews articles to indicate that followup (=replies) should be sent
to the indicated e-mail address.
|
Mail-Copies-To:
|
non-standard,
but commonly supported by newsreaders
|
|
Possible
future change of name for "Content-Return:"
|
X400-Content-Return:
|
non-standard
|
|
Reference
to specially important articles for a particular Usenet Newsgroup.
|
Article-Names:
|
son-of-RFC1036
[21], non-standard
|
|
Only
in Usenet News, similar to "Supersedes:" but does not cause the referenced
article to be physically deleted.
|
Article-Updates:
|
son-of-RFC1036
[21], non-standard
|
|
Used
in addition to Content-Location if this content part can be retrieved
through more than one URI. Only one of them is allowed in the Content-Location,
the other can be specified in Content-Alias.
|
Content-Alias:
|
Work
in progress
|
|
Base
to be used for resolving relative URIs within this content part.
|
Content-Base:
|
RFC
2110
|
|
Unique
ID of one body part of the content of a message.
|
Content-ID:
|
RFC
2045: 7.
|
|
URI
with which the content of this content part might be retrievable.
|
Content-Location:
|
RFC
2110
|
|
Used
by some automatic services (mainly MLMs and autoresponders) for the
purpose of loop detection. The service adds the Delivered-To header
to outgoing messages, with its e-mail address as a value, and discards
incoming messages which already have it.
|
Delivered-To:
or
X-Loop:
|
non-standard
|
|
Reference
to message which this message is a reply to.
|
In-Reply-To:
|
RFC
822: 4.6.2.
|
|
Unique
ID of this message.
|
Message-ID:
|
RFC
822: 4.6.1
RFC
1036: 2.1.5.
|
|
Reference
to previous message being corrected and replaced. Compare to "Supersedes:"
below. This field may in the future be replaced with "Supersedes:".
|
Obsoletes:
|
RFC
2156, not for general usage.
|
|
In
e-mail: reference to other related messages, in Usenet News: reference
to replied-to-articles.
|
References:
|
RFC
822: 4.6.3
RFC
1036: 2.1.5.
|
|
Still
another name for similar functionality as for "Obsoletes:" and "Supersedes:".
This may become the most recommended header in the future, but is still
under discussion in IETF standards development work.
|
Replaces:
|
non-standard,
proposed in IETF USEFOR working group
|
|
References
to other related articles in Usenet News.
|
See-Also:
|
Son-of-RFC1036
[21], non-standard
|
|
Commonly
used in Usenet News in similar ways to the "Obsoletes" header field
described above. In Usenet News, however, Supersedes causes a full deletion
of the replaced article in the server, while "Supersedes" and "Obsoletes"
in e-mail is implemented in the client and often does not remove the
old version of the text.
|
Supersedes:
|
son-of-RFC1036
[21], non-standard
|
|
Mailbox
of the person who made the translation.
|
Translated-By:
|
non-standard
|
|
Reference
to the Message-ID of a message, which the current message is a translation
of.
|
Translation-Of:
|
non-standard
|
|
Unique
identifier for a message, local to a particular local mailbox store.
The UIDL identifier is defined in the POP3 standard, but not the "X-UIDL:"
header.
|
X-UIDL:
|
non-standard
|
|
Similar
usage as "X-URL". The URI can be either a URL or a URN. URNs are meant
to become more persistent references to resources than URLs.
|
X-URI:
|
Non-standard
|
|
Sometimes
used with the same meaning as "Content-Location:", sometimes to indicate
the web home page of the sender or of his organisation.
|
X-URL:
|
Non-standard
|
|
The
UID, as defined in the IMAP standard. Only used in internal mailbox
storage in some mail systems, should never be visible to a user.
|
X-IMAP:
|
Non-standard
|
|
Comments
on a message.
|
Comments:
|
RFC
822: 4.7.2.
|
|
Description
of a particular body part of a message, for example a caption for an
image body part.
|
Content-Description:
|
RFC
2045: 8.
|
|
A
text string which identifies the content of a message.
|
Content-Identifier:
|
RFC
2156, not for general usage.
|
|
Search
keys for data base retrieval.
|
Keywords:
|
RFC
822: 4.7.1
RFC
1036: 2.2.9.
|
|
See
Organization above.
|
Organisation:
|
Non-standard.
|
|
Organization
to which the sender of this article belongs.
|
Organization:
|
RFC
1036: 2.2.8, not standardized for use in e-mail.
|
|
Title,
heading, subject. Often used as thread indicator for messages replying
to or commenting on other messages.
|
Subject:
|
RFC
822: 4.7.1
RFC
1036: 2.1.4.
|
|
Short
text describing a longer article. Warning: Some mail systems will not
display this text to the recipient. Because of this, do not use this
header field for text which you want to ensure that the recipient gets.
|
Summary:
|
RFC
1036: 2.2.10, not standardized for use in e-mail, discouraged.
|
|
In
Internet, the date when a message was written, in X.400, the time a
message was submitted. Some Internet mail systems also use the date
when the message was submitted.
|
Date:
|
RFC
822: 5.1,
RFC
1123: 5.2.14
RFC
1036: 2.1.2.
|
|
The
time when a message was delivered to its recipient.
|
Delivery-Date:
|
RFC
2156, not for general usage.
|
|
A
suggested expiration date. Can be used both to limit the time of an
article which is not meaningful after a certain date, and to extend
the storage of important articles.
|
Expires:
|
RFC
1036: 2.2.4, not standardized for use in e-mail.
|
|
Time
at which a message loses its validity. This field may in the future
be replaced by "Expires:".
|
Expiry-Date:
|
RFC
2156, not for general usage.
|
|
Latest
time at which a reply is requested (not demanded).
|
Reply-By:
|
RFC
2156, not for general usage.
|
|
Time
when this message was delivered into the message transport system (usually
the same time as in the last "Received:" header)
|
X-OriginalArrivalTime:
|
Non-standard
|
|
A
hint from the originator to the recipients about how important a message
is. Values: High, normal or low. Not used to control transmission speed.
|
Importance:
|
RFC
2156 and
RFC
2421, proposed
|
|
Body
parts are missing.
|
Incomplete-Copy:
|
RFC
2156, not for general usage.
|
|
Ratings
label to control selection (filtering) of messages according to the
PICS protocol.
|
PICS-Label:
|
REC-PICS-labels,
W3C document [23].
|
|
Sometimes
used as a priority value which can influence transmission speed and
delivery. 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.
|
Precedence:
|
Non-standard,
controversial, widely used.
|
|
Can
be "normal", "urgent" or "non-urgent" and can influence transmission
speed and delivery.
|
Priority:
|
RFC
2156, not for general usage.
|
|
How
sensitive it is to disclose this message to other people than the specified
recipients. Values: Personal, private, company confidential. The absence
of this header field in messages gatewayed from X.400 indicates that
the message is not sensitive.
|
Sensitivity:
|
RFC
2156 and
RFC
2421, proposed
|
|
Yet
another priority indication.
|
X-MSMail-Priority:
|
Non-standard
|
|
Values:
1 (Highest), 2 (High), 3 (Normal), 4 (Low), 5 (Lowest). 3 (Normal) is
default if the field is omitted.
|
X-Priority:
|
Non-standard
[24]
|
|
Can
include a code for the natural language used in a message, e.g. "en"
for English.
|
Content-Language:
|
RFC
1766, proposed standard.
|
|
Can
include a code for the natural language used in a message, e.g. "en"
for English.
|
Language:
|
RFC
2156, not for general usage.
|
|
Inserted
by certain mailers to indicate the size in bytes of the message text.
This is part of a format some mailers use when showing a message to
its users, and this header field should not be used when sending a message
through the net. The use of this header field in transmission of a message
can cause several robustness and interoperability problems.
|
Content-Length:
|
Non-standard,
discouraged.
|
|
Size
of the message.
|
Lines:
|
RFC
1036: 2.2.12, not standardized for use in e-mail.
|
|
Information
on where an alternative variant of this document might be found.
|
Content-Alternative:
|
Non-standard
[27].
|
|
Non-standard
variant of Conversion: with the same values.
|
Content-Conversion:
|
Non-standard.
|
|
The
body of this message may not be converted from one character set to
another. Values: Prohibited and allowed.
|
Conversion:
|
RFC
2156, not for general usage.
|
|
The
body of this message may not be converted from one character set to
another if information will be lost. Values: Prohibited and allowed.
|
Conversion-With-Loss:
|
RFC
2156, not for general usage.
|
|
Type
information of the content in some class hierarchy. Class hierarchies
are commonly used to classify data structures in software development.
|
Content-Class:
|
non-standard
|
|
Can
give more detailed information about the Content-Type. Example:
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
This
header is meant to be used when you can choose between different versions
of a resource, such as when using multipart/atlernative.
|
Content-Features:
|
Proposed
Standard, RFC 2912
|
|
Information
from the SGML entity declaration corresponding to the entity contained
in the body of the body part.
|
Content-SGML-Entity:
|
non-standard
|
|
Coding
method used in a MIME message body.
|
Content-Transfer-Encoding:
|
RFC
2045: 6.
|
|
Format
of content (character set etc.) Note that the values for this header
field are defined in different ways in RFC 1049 and in MIME (RFC 2045),
look for the "MIME-version" header 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. RFC 1049 has "historic"
status.
RFC
1766 defines a parameter "difference" to this header field.
Various
other Content-Type define various additional parameters. For example,
the parameter "charset" is mandatory for all textual Content-Types.
|
Content-Type:
|
RFC
1049,
RFC
1123: 5.2.13,
RFC
1766: 4.1
RFC
2045: 5.
|
|
Used
in several different ways by different mail systems. Some use it for
a kind of content-type information, some for encoding and length information,
some for a kind of boundary information, some in other ways.
|
Encoding:
|
RFC
1154,
RFC
1505,
experimental.
|
|
Only
used with the value "Delivery Report" to indicates that this is a delivery
report gatewayed from X.400.
|
Message-Type:
|
RFC
2156, not for general usage.
|
|
Information
about conversion of this message on the path from sender to recipient,
like conversion between MIME encoding formats. Note: Auto-conversion
may invalidate digital seals and signatures.
|
X-MIME-Autoconverted:
|
non-standard
|
|
When
manually forwarding a message, header fields referring to the forwarding,
not to the original message. Note: MIME specifies another way of resending
messages, using the "Message" Content-Type.
|
Resent-Reply-To:,
Resent-From:,
Resent-Sender:, Resent-From:, Resent-Date:, Resent-To:, Resent-cc:,
Resent-bcc:, Resent-Message-ID:
|
RFC
822: C.3.3.
|
|
Checksum
of content to ensure that it has not been modified.
|
Content-MD5:
|
RFC
1864, proposed standard.
|
|
Used
in Usenet News to store information to avoid showing a reader the same
article twice if it was sent to more than one newsgroup. Only for local
usage within one Usenet News server, should not be sent between servers.
|
Xref:
|
RFC
1036: 2.2.13, only in Usenet News, not in e-mail.
|
|
Contains
URL to use to browse the archives of the mailing list from which this
message was relayed.
|
List-Archive:
|
RFC
2369 [26]
|
|
URL
to use to get a subscription to the digest version of the mailing list
from which this message was relayed.
|
List-Digest:
|
Non-standard
|
|
Contains
URL to use to get a information about the mailing list from which this
message was relayed.
|
List-Help:
|
RFC
2369 [26]
|
|
Stores
an identification of the mailing list, through which this message was
distributed.
|
List-ID:
|
RFC
2919 [27].
|
|
Non-standard
precursors to List-ID and List-Post.
|
Mailing-List:,
X-Mailing-List:
|
Non-standard
|
|
Contains
URL to send e-mail to the owner of the mailing list from which this
message was relayed.
|
List-Owner:
|
RFC
2369 [26]
|
|
Contains
URL to use to send contributions to the mailing list from which this
message was relayed.
|
List-Post:
|
RFC
2369 [26]
|
|
Information
about the software used in a mailing list expander through which this
message has passed.
|
List-Software:
|
Non-standard,
has been considered for inclusion in [26].
|
|
Contains
URL to use to get a subscription to the mailing list from which this
message was relayed.
|
List-Subscribe:
|
RFC
2369 [26]
|
|
Contains
URL to use to unsubscribe the mailing list from which this message was
relayed.
|
List-Unsubscribe:
|
RFC
2369 [26]
|
|
Contains
URL where information of various kinds about the mailing list from which
this message was relayed.
|
List-URL:
|
Non-standard
|
|
Information
about the server and software used in a mailing list expander through
which this message has passed. Warning: "Listserv" is a trademark and
should not be used for other than the "Listserv" product. Use, instead
the "List-Software" header field.
|
X-Listserver:,
X-List-Host:
|
Non-standard.
Recommended to use "List-Software" instead.
|
|
Has
been automatically forwarded.
|
Autoforwarded:
|
RFC
2156, not for general usage.
|
|
Can
be used in Internet mail to indicate X.400 IPM extensions which could
not be mapped to Internet mail format.
|
Discarded-X400-IPMS-Extensions:
|
RFC
2156, not for general usage.
|
|
Can
be used in Internet mail to indicate X.400 MTS extensions which could
not be mapped to Internet mail format.
|
Discarded-X400-MTS-Extensions:
|
RFC
2156, not for general usage.
|
|
Name
of file in which a copy of this message is stored.
|
Fcc:
|
Non-standard.
|
|
Speech
act categoriztion of a message, examples of speeach acts are Question,
Idea, More, Promise, Sad, Happy, Angry, summary, Decision
|
Speech-Act:
|
Non-standard
|
|
This
field is used by some mail delivery systems to indicate the status of
delivery for this message when stored. Common values of this field are:
U
message is not downloaded
and not deleted.
R
message is read or
downloaded.
O
message is old but not
deleted.
D
to be deleted.
N
new (a new message also
sometimes is distinguished
by not having any "Status:"
header field.
Combinations
of these characters can occur, such as "Status: OR" to indicate that
a message is downloaded but not deleted.
|
Status:
|
Non-standard,
should never appear in mail in transit.
|
|
Do
not archive this message in publicly available archives.
|
X-No-Archive:
Yes
|
Non-standard
|
|
Harald
Tveit Alvestrand, Neil Carpenter, William C. Carpenter, Rob Chandhok,
Ned Freed, Olle Järnefors, Jukka Korpela, Usi Paz, Martin Platt,
Keith Moore, Robert A. Rosenberg, Mark Symons, Nick Smith Michael C.
Tiernan 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].
|
|
The
IETF takes no position regarding the validity or scope of any intellectual
property or other rights that might be claimed to pertain to the implementation
or use of the technology described in this document or the extent to
which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any
such rights. Information on the IETF's procedures with respect to rights
in standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the result of
an attempt made to obtain a general license or permission for the use
of such proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat."
The
IETF invites any interested party to bring to its attention any copyrights,
patents or patent applications, or other proprietary rights which may
cover technology that may be required to practice this standard. Please
address the information to the IETF Executive Director.
Copyright
(C) The Internet Society (date). All Rights Reserved.
This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implmentation may be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that
the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or references
to the Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The
limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
|
|
Ref.
-----
|
Author,
title
---------------------------------------------
|
IETF
status (Dec 2000)
-----------
|
|
[1]
|
J.
Klensin: "Simple Mail Transfer Protocol", RFC 2821, April 2001.
|
Proposed
Standard
|
|
[2]
|
P.
Resnick: "Internet Message Format" STD 11, RFC 2822, April 2001.
|
Proposed
Standard
|
|
[3]
|
M.R.
Horton, R. Adams: "Standard for interchange of USENET messages", RFC
1036, December 1987.
|
Not
an offi-cial IETF standard, but in reality a de-facto standard for Usenet
News
|
|
[4]
|
M.
Sirbu: "A Content-Type header field header field for internet messages",
RFC 1049, March 1988.
|
Historic
|
|
[5]
|
R.
Braden (editor): "Requirements for Internet Hosts -- Application and
Support", STD-3, RFC 1123, October 1989.
|
Standard,
Required
|
|
[6]
|
D.
Robinson, R. Ullman: "Encoding Header field for Internet Messages",
RFC 1505, August 1993.
|
Non-standard
|
|
[7]
|
S.
Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 822",
RFC 2156 January 1998.
|
Proposed
standard, elective
|
|
[8]
|
H.
Alvestrand & J. Romaguera: "Rules for Downgrading Messages from
X.400/88 to X.400/84 When MIME Content-Types are Present in the Messages",
RFC 1496, August 1993.
|
Proposed
standard, elective
|
|
[9]
|
A.
Costanzo: "Encoding Header field Header field for Internet Messages",
RFC 1154, April 1990.
|
Non-standard
|
|
[10]
|
A.
Costanzo, D. Robinson: "Encoding Header field Header field for Internet
Messages", RFC 1505, August 1993.
|
Experimental
|
|
[11]
|
N.
Freed & N. Borenstein: "MIME (Multipurpose Internet Mail Extensions)
Part One: Format of Internet Message Bodies. RFC 2045. November 1996.
|
Draft
Standard, elective
|
|
[12]
|
H.
Alvestrand: "Tags for the Identification of Languages", RFC 3066, January
2001.
|
Best
Current Practice, elective
|
|
[13]
|
J.
Palme: "Electronic Mail", Artech House publishers, London-Boston January
1995.
|
Non-standard
|
|
[14]
|
R.
Troost, S. Dorner: "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header field", RFC 2183, June 1995.
|
Experimental
|
|
[15]
|
B.
Kantor, P. Lapsley, "Network News Transfer Protocol: "A Proposed Standard
for the Stream-Based Transmission of News", RFC 977, January 1986.
|
Proposed
standard
|
|
[16]
|
1848
PS S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
Services", RFC 1848, March 1995.
|
Proposed
standard
|
|
[17]
|
J.
Myers, M. Rose: The Content-MD5 Header field Header field, RFC 1864,
October 1995.
|
Draft
standard
|
|
[18]
|
M.
Horton, UUCP mail interchange format standard, RFC 976, Januari 1986.
|
Not
an offi-cial IETF standard, but in reality a de-facto standard for Usenet
News
|
|
[19]
|
R.
Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, June 1999.
|
Draft
standard
|
|
[20]
|
G.
Vaudreuil: Voice Profile for Internet Mail, RFC 2421 Feburary 1998.
|
Proposed
|
|
[21]
|
H.
Spencer: News Article Format and Transmission, June 1994,
FTP://zoo.toronto.edu/pub/news.ps.Z
FTP://zoo.toronto.edu/pub/news.txt.Z
This
document is often referenced under the name "son-of-RFC1036".
|
Not
even an RFC, but still widely used and partly almost a de-facto standard
for Usenet News
|
|
[23]
|
PICS
Label Distribution Label Syntax and Communication Protocols, World Wide
Web Consortium, October 1996.
|
Other
standard
|
|
[24]
|
Eudora
Pro Macintosh User Manual, Qualcomm Inc., 1988-1995.
|
Non-standard
|
|
[25]
|
C.
Newman: Originator-Info Message Header field. work in progress, July
1997.
|
Non-standard
|
|
[26]
|
Grant
Neufeld and Joshua D. Baer: The Use of URLs as Meta-Syntax for Core
Mail List Commands and their Transport through Message Header fields,
RFC 2369, July 1998.
|
Proposed
standard
|
|
[27]
|
G.
Klyne (ed.): Content Negotiation for Facsimile Using Internet Mail,
Work in progress, March 2000.
|
Non-standard
|
|
[27]
|
R.
Chandhok, G. Wenger: List-IDE: A Structured Field and Namespace for
the Identification if Mailing Lists, RFC 2919, March 2001.
|
Proposed
standard
|
|
[28]
|
Jukka
"Yucca" Korpela: Quick reference to Internet message headers, http://www.cs.tut.fi/~jkorpela/headers.html,
October 2001.
|
Non-standard
|
|
Jacob
Palme
Stockholm
University/KTH
Electrum
230
S-164
40 Kista, Sweden
|
Phone:
+46-8-16 16 67
Fax:
+46-8-783 08 29
E-mail:
jpalme@dsv.su.se
|
|
Section
-------
|
Header
field
------------
|
|
3.5
|
Abuse-Reports-To
|
|
3.3
|
Also-Control
|
|
3.3
|
Alternate-Recipient
|
|
3.4
|
Apparently-To
|
|
3.4
|
Approved
|
|
3.4
|
Approved-By
|
|
3.6
|
Article-Names
|
|
3.6
|
Article-Updates
|
| |
Auto-Forwarded
see Autoforwarded
|
|
3.17
|
Autoforwarded
|
|
3.4
|
bcc
|
|
3.4
|
cc
|
| |
Client,
see Originating-Client
|
| |
Comment,
see For-Comment
|
|
3.7
|
Comments
|
|
3.6
|
Content-Alias
|
|
3.12
|
Content-Alternative
|
|
3.6
|
Content-Base
|
|
3.13
|
Content-Class
|
|
3.12
|
Content-Conversion
|
|
3.7
|
Content-Description
|
|
3.3
|
Content-Disposition
|
|
3.13
|
Content-Features
|
|
3.6
|
Content-ID
|
|
3.7
|
Content-Identifier
|
|
3.10
|
Content-Language
see also Language
|
|
3.11
|
Content-Length
|
|
3.6
|
Content-Location
|
|
3.15
|
Content-MD5
|
|
3.4
|
Content-Return
|
|
3.13
|
Content-SGML-Entity
|
|
3.13
|
Content-Transfer-Encoding
|
|
3.13
|
Content-Type
|
|
3.3
|
Control
|
|
3.12
|
Conversion
|
|
3.12
|
Conversion-With-Loss
|
| |
Copy,
see Incomplete-Copy
|
|
3.8
|
Date,
see also Delivery-Date, Received, Expires, Expiry-Date
|
|
3.6
|
Delivered-To
|
|
3.8
|
Delivery-Date
|
| |
Delivery-Report,
see Generate-Delivery-Report, Prevent-Delivery-Report, Non-Delivery-Report,
Content-Type
|
| |
Description,
see Content-Description
|
|
3.17
|
Discarded-X400-IPMS-Extensions
|
|
3.17
|
Discarded-X400-MTS-Extensions
|
|
3.3
|
Disclose-Recipients
|
| |
Disposition,
see also Content-Disposition
|
|
3.5
|
Disposition-Notification-Options
|
|
3.5
|
Disposition-Notification-To
|
|
3.4
|
Distribution
|
|
3.2
|
DL-Expansion-History
|
|
3.13
|
Encoding
see also Content-Transfer-Encoding
|
|
3.4
|
Errors-To
|
|
3.8
|
Expires
|
|
3.8
|
Expiry-Date
|
| |
Extension
see Discarded-X400-IPMS-Extensions, Discarded-X400-MTS-Extensions
|
|
3.4
|
Fax
see also Telefax
|
|
3.17
|
Fcc
|
|
3.4
|
Followup-To
|
|
3.4
|
For-Approval
|
|
3.4
|
For-Comment
|
|
3.4
|
For-Handling
|
| |
Forwarded,
see Autoforwarded
|
|
3.4
|
From
(not followed by (":" or preceded by ">")
|
|
3.4
|
From
(followed by ":")
|
|
3.4
|
Generate-Delivery-Report
|
| |
Handling,
see For-Handling
|
| |
History,
see DL-Expansion-History
|
| |
ID,
see Content-ID and Message-ID
|
| |
Identifier,
see Content-ID and Message-ID
|
|
3.9
|
Importance
|
|
3.6
|
In-Reply-To
|
|
3.9
|
Incomplete-Copy
|
|
3.7
|
Keywords
|
| |
Label,
see PICS-Label
|
|
3.10
|
Language
see also Content-Language
|
| |
Length
see Content-Length
|
|
3.11
|
Lines
|
|
3.16
|
List-Archive
|
|
3.16
|
List-Digest
|
|
3.16
|
List-Help
|
|
3.16
|
List-ID
|
|
3.16
|
List-Owner
|
|
3.16
|
List-Post
|
|
3.16
|
List-Software
|
|
3.16
|
List-Subscribe
|
|
3.16
|
List-URL
|
|
3.16
|
List-Unsubscribe
|
| |
Loss,
see Conversion-With-Loss
|
|
3.16
|
Mailing-List,
see also X-Mailing-List
|
|
3.5
|
Mail-Copies-To
|
|
3.4
|
Mail-System-Version
see also X-mailer
|
|
3.4
|
Mailer
|
| |
MD5
see Content-MD5
|
|
3.3
|
Message-Context
|
|
3.6
|
Message-ID
|
|
3.13
|
Message-Type
|
|
3.3
|
MIME-Version
|
|
3.4
|
Newsgroups
|
| |
Newsreader,
see X-Newsreader
|
|
3.3
|
NNTP-Posting-Host
|
|
3.6
|
Obsoletes
|
|
3.7
|
Organisation
|
|
3.7
|
Organization
|
|
3.3
|
Original-Encoded-Information-Types
|
|
3.6
|
Original-Recipient
|
|
3.4
|
Originating-Client
|
|
3.4
|
Originator
|
|
3.4
|
Originator-Info
see also Sender
|
|
3.2
|
Path
|
|
3.4
|
Phone
|
|
3.9
|
PICS-Label
|
|
3.4
|
Posted-To
|
|
3.9
|
Precedence
|
|
3.4
|
Prevent-NonDelivery-Report
|
|
3.9
|
Priority
|
|
3.5
|
Read-Reciept-To
|
|
3.2
|
Received
|
| |
Recipient,
see To, cc, bcc, Alternate-Recipient, Disclose-Recipients
|
|
3.6
|
References
|
|
3.5
|
Registered-Mail-Reply-Requested-By
|
|
3.6
|
Replaces
|
|
3.8
|
Reply-By
|
|
3.4
|
Reply-To,
see also In-Reply-To, References
|
|
3.14
|
Resent-
|
| |
Return
see Content-Return
|
|
3.2
|
Return-Path
|
|
3.5
|
Return-Receipt-Requested
|
|
3.5
|
Return-Receipt-To
|
|
3.6
|
See-Also
|
|
3.4
|
Sender
|
|
3.9
|
Sensitivity
|
|
3.17
|
Speech-Act
|
|
3.17
|
Status
|
|
3.7
|
Subject
|
|
3.7
|
Summary
|
|
3.6
|
Supersedes
|
|
3.4
|
Telefax
see also Fax
|
|
3.4
|
To
|
| |
Transfer-Encoding
see Content-Transfer-Encoding
|
|
3.6
|
Translated-By
|
|
3.6
|
Translation-Of
|
| |
Type
see Content-Type, Message-Type, Original-Encoded-Information-Types
|
|
3.4
|
User-Agent
|
| |
Version,
see MIME-Version, X-Mailer
|
|
3.4
|
X-Admin
|
|
3.4
|
X-Complaints-To
|
|
3.5
|
X-Confirm-Reading-To
|
|
3.4
|
X-Envelope-From
|
|
3.4
|
X-Envelope-To
|
|
3.4
|
X-Face
|
|
3.6
|
X-IMAP
|
|
3.16
|
X-List-Host
|
|
3.16
|
X-Listserver
|
|
3.6
|
X-Loop
|
|
3.16
|
X-Mailing-List,
see also Mailing-List
|
|
3.4
|
X-Mailer
see also Mail-System-Version
|
|
3.13
|
X-MIME-Autoconverted
|
|
3.4
|
X-MimeOLE
|
|
3.9
|
X-MSMail-Priority
|
|
3.4
|
X-Newsreader
|
|
3.17
|
X-No-Archive
|
|
3.8
|
X-OriginalArrivaltime
|
|
3.9
|
X-Priority
|
|
3.4
|
X-Report-Abuse-To
|
|
3.4
|
X-RCPT-TO
|
|
3.4
|
X-Sender
see also Originator-Info
|
|
3.6
|
X-UIDL
|
|
3.6
|
X-URI
|
|
3.6
|
X-URL
see also Content-Location
|
|
3.4
|
X-X-Sender
see also Originator-Info
|
|
3.4
|
X400-Content-Return
|
|
3.15
|
Xref
|