📄 rfc2076.txt
字号:
Network Working Group J. Palme
Request for Comments: 2076 Stockholm University/KTH
Category: Informational February 1997
Common Internet Message Headers
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. 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, RFC 1864 and RFC 1911. 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.
Table of contents
1. Introduction.............................................. 2
2. Use of gatewaying headers................................. 3
3. Table of headers.......................................... 3
3.1 Phrases used in the tables.......................... 3
3.2 Trace information................................... 5
3.3 Format and control information...................... 5
3.4 Sender and recipient indication..................... 6
3.5 Response control.................................... 9
3.6 Message identification and referral headers......... 11
3.7 Other textual headers............................... 12
3.8 Headers containing dates and times.................. 13
3.9 Quality information................................. 13
3.10 Language information............................... 14
3.11 Size information................................... 14
3.12 Conversion control................................. 15
3.13 Encoding information............................... 15
3.14 Resent-headers..................................... 16
3.15 Security and reliability........................... 16
3.16 Miscellaneous...................................... 16
4. Acknowledgments........................................... 18
5. References................................................ 18
6. Author's Address.......................................... 20
Appendix A:
Headers sorted by Internet RFC document in which they appear. 21
Appendix B:
Alphabetical index........................................... 25
1. Introduction
Many different Internet standards and RFCs define headers which may
occur on Internet Mail Messages and Usenet 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], RFC 1864[17] and RFC 1911[20]. 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
mainly 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 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.
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 (1996) they are not
widely implemented or used.
Headers 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 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 de-facto standard for Usenet News, is not an
official IETF standard or even 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. Some header
proposed in ongoing IETF standards development
work, but not yet accepted, are also marked in
this way.
"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.1.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.
Special Usenet News actions only. Control: RFC 1036: 2.1.6,
only in Usenet
News, not in e-
mail.
Special Usenet News actions and a Also-Control: son-of-RFC1036
normal article at the same time. [21], non-
standard, 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,
Note difference from the "From " RFC 1036 2.1.1
header (not followed by ":")
below.
(1) This header should never From not standardized
appear in e-mail being sent, and for use in e-mail
should thus not appear in this
memo. It is however included,
since people often ask about it.
This header 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 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
should NOT be used to find an
address to which replies to a
message are to be sent.
(2) Used in Usenet News mail From RFC 976: 2.4 for
transport, to indicate the path or use in Usenet News
through which an article has gone >From
when transferred to a new host.
Sometimes called "From_" header.
Name of the moderator of the Approved: RFC 1036: 2.2.11,
newsgroup to which this article 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.
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.
Primary recipients, who are For-Handling: Non-standard
requested to handle the
information in this message
or its attachments.
Primary recipients, who are For-Comment: Non-standard
requested to comment on the
information in this message
or its attachments.
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) Indicating the newsgroup
recipient of an article/message
sent to both e-mail and Usenet
News recipients.
(b) In a personally addressed
reply to an article in a news-
group, indicating 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 article not standardized
can be distributed. for use in e-mail.
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -