📄 rfc2076.txt
字号:
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.).
Some mail systems use this header
to indicate a better form of the
e-mail address of the sender.
Some mailing list expanders puts
the name of the list in this
header. These practices are
controversial. The personal
opinion of the author of this RFC
is that this header should be
avoided except in special cases,
but this is a personal opinion
not shared by all specialists in
the area.
Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3,
that future discussions (=follow- not standardized
up) on an article should go to a for use in e-mail.
different set of newsgroups than
the replied-to article. The most
common usage is when an article
is posted to several newsgroups,
and further discussions is to
take place in only one of them.
In e-mail, this header 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 does
not say anything about where
follow-up in e-mail is to be
sent.
Note that the value of this
header must always be one or more
newsgroup names, never e-mail
addresses.
Address to which notifications Errors-To:, Non-standard,
are to be sent and a request to Return- discouraged.
get delivery notifications. Receipt-To:
Internet standards recommend,
however, the use of RCPT TO and
Return-Path, not Errors-To, for
where delivery notifications are
to be sent.
Whether non-delivery report is Prevent- RFC 1327, not for
wanted at delivery error. Default NonDelivery- general usage.
is to want such a report. Report:
Whether a delivery report is Generate- RFC 1327, not for
wanted at successful delivery. Delivery- general usage.
Default is not to generate such a Report:
report.
Indicates whether the content of Content- RFC 1327, not for
a message is to be returned with Return: general usage.
non-delivery notifications.
Possible future change of name X400-Content- non-standard
for "Content-Return:" Return:
3.6 Message identification and referral headers
Unique ID of this message. Message-ID: RFC 822: 4.6.1
RFC 1036: 2.1.5.
Unique ID of one body part of the Content-ID: RFC 1521: 6.1.
content of a message.
Base to be used for resolving Content-Base: Non-standard
relative URIs within this content
part.
URI with which the content of Content- Non-standard
this content part might be Location:
retrievable.
Reference to message which this In-Reply-To: RFC 822: 4.6.2.
message is a reply to.
In e-mail: reference to other References: RFC 822: 4.6.3
related messages, in Usenet News: RFC 1036: 2.1.5.
reference to replied-to-articles.
References to other related See-Also: Son-of-RFC1036
articles in Usenet News. [21], non-standard
Reference to previous message Obsoletes: RFC 1327, not for
being corrected and replaced. general usage.
Compare to "Supersedes:" below.
This field may in the future be
replaced with "Supersedes:".
Commonly used in Usenet News in Supersedes: son-of-RFC1036
similar ways to the "Obsoletes" [21], non-standard
header 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.
Only in Usenet News, similar to Article- son-of-RFC1036
"Supersedes:" but does not cause Updates: [21], non-standard
the referenced article to be
physically deleted.
Reference to specially important Article- son-of-RFC1036
articles for a particular Usenet Names: [21], non-standard
Newsgroup.
3.7 Other textual headers
Search keys for data base Keywords: RFC 822: 4.7.1
retrieval. RFC 1036: 2.2.9.
Title, heading, subject. Often Subject: RFC 822: 4.7.1
used as thread indicator for RFC 1036: 2.1.4.
messages replying to or
commenting on other messages.
Comments on a message. Comments: RFC 822: 4.7.2.
Description of a particular body Content- RFC 1521: 6.2.
part of a message. Description:
Organization to which the sender Organization: RFC 1036: 2.2.8,
of this article 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,
article. Warning: Some mail not standardized
systems will not display this for use in e-mail,
text to the recipient. Because of discouraged.
this, do not use this header for
text which you want to ensure
that the recipient gets.
A text string which identifies Content- RFC 1327, not for
the content of a message. Identifier: general usage.
3.8 Headers containing dates and times
The time when a message was Delivery- RFC 1327, not for
delivered to its recipient. Date: general usage.
In Internet, the date when a Date: RFC 822: 5.1,
message was written, in X.400, RFC 1123: 5.2.14
the time a message was submitted. RFC 1036: 2.1.2.
Some Internet mail systems also
use the date when the message was
submitted.
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. This field may in the general usage.
future be replaced by "Expires:".
Latest time at which a reply is Reply-By: RFC 1327, not for
requested (not demanded). general usage.
3.9 Quality information
Can be "normal", "urgent" or "non- Priority: RFC 1327, not for
urgent" and can influence general usage.
transmission speed and delivery.
Sometimes used as a priority Precedence: Non-standard,
value which can influence controversial,
transmission speed and delivery. discouraged.
Common values are "bulk" and
"first-class". Other uses is to
control automatic replies and to
control return-of-content
facilities, and to stop mailing
list loops.
A hint from the originator to the Importance: RFC 1327 and
recipients about how important a RFC 1911,
message is. Values: High, normal experimental
or low. Not used to control
transmission speed.
How sensitive it is to disclose Sensitivity: RFC 1327 and
this message to other people than RFC 1911,
the specified recipients. Values: experimental
Personal, private, company
confidential. The absence of this
header in messages gatewayed from
X.400 indicates that the message
is not sensitive.
Body parts are missing. Incomplete- RFC 1327, not for
Copy: general usage.
3.10 Language information
Can include a code for the Language: RFC 1327, not for
natural language used in a general usage.
message, e.g. "en" for English.
Can include a code for the Content- RFC 1766, proposed
natural language used in a Language: standard.
message, e.g. "en" for English.
3.11 Size information
Inserted by certain mailers to Content- Non-standard,
indicate the size in bytes of the Length: discouraged.
message text. This is part of a
format some mailers use when
showing a message to its users,
and this header should not be
used when sending a message
through the net. The use of this
header in transmission of a
message can cause several
robustness and interoperability
problems.
Size of the message. Lines: RFC 1036: 2.2.12,
not standardized
for use in e-mail.
3.12 Conversion control
The body of this message may not Conversion: RFC 1327, not for
be converted from one character general usage.
set to another. Values:
Prohibited and allowed.
Non-standard variant of Content- Non-standard.
Conversion: with the same values. Conversion:
The body of this message may not Conversion- RFC 1327, not for
be converted from one character With-Loss: general usage.
set to another if information
will be lost. Values: Prohibited
and allowed.
3.13 Encoding information
Format of content (character set Content-Type: RFC 1049,
etc.) Note that the values for RFC 1123: 5.2.13,
this header are defined in RFC 1521: 4.
different ways in RFC 1049 and in RFC 1766: 4.1
MIME (RFC 1521), look for the
"MIME-version" header to
understand if Content-Type is to
be interpreted according to RFC
1049 or according to MIME. The
MIME definition should be used in
generating mail.
RFC 1766 defines a parameter
"difference" to this header.
Information from the SGML entity Content-SGML- non-standard
declaration corresponding to the Entity:
entity contained in the body of
the body part.
Coding method used in a MIME Content- RFC 1521: 5.
message body. Transfer-
Encoding:
Only used with the value Message-Type: RFC 1327, not for
"Delivery Report" to indicates general usage.
that this is a delivery report
gatewayed from X.400.
Used in several different ways by Encoding: RFC 1154,
different mail systems. Some use RFC 1505,
it for a kind of content-type experimental.
information, some for encoding
and length information, some for
a kind of boundary information,
some in other ways.
3.14 Resent-headers
When manually forwarding a Resent-Reply- RFC 822: C.3.3.
message, headers referring to the To:,
forwarding, not to the original Resent-From:,
message. Note: MIME specifies Resent-
another way of resending Sender:,
messages, using the "Message" Resent-From:,
Content-Type. Resent-Date:,
Resent-To:,
Resent-cc:,
Resent-bcc:,
Resent-
Message-ID:
3.15 Security and reliability
Checksum of content to ensure Content-MD5: RFC 1864, proposed
that it has not been modified. standard.
Used in Usenet News to store Xref: RFC 1036: 2.2.13,
information to avoid showing a only in Usenet
reader the same article twice if News, not in e-
it was sent to more than one mail.
newsgroup. Only for local usage
within one Usenet News server,
should not be sent between
servers.
3.16 Miscellaneous
Name of file in which a copy of Fcc: Non-standard.
this message is stored.
Has been automatically forwarded. Auto- RFC 1327, not for
Forwarded: general usage.
Can be used in Internet mail to Discarded- RFC 1327, not for
indicate X.400 IPM extensions X400-IPMS- general usage.
which could not be mapped to Extensions:
Internet mail format.
Can be used in Internet mail to Discarded- RFC 1327, not for
indicate X.400 MTS extensions X400-MTS- general usage.
which could not be mapped to Extensions:
Internet mail format.
This field is used by some mail Status: Non-standard,
delivery systems to indicate the should never
status of delivery for this appear in mail in
message when stored. Common transit.
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.
Combinations of these characters
can occur, such as "Status: OR"
to indicate that a message is
downloaded but not deleted.
4. Acknowledgments
Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore, Nick
Smith and several other people have helped me with compiling this
list. I especially thank Ned Freed and Olle Jdrnefors for their
thorough review and many helpful suggestions for improvements. I
alone take responsibility for any errors which may still be in the
list.
An earlier version of this list has been published as part of [13].
5. References
Ref. Author, title IETF status
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -