rfc2076.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/4 页
TXT
1,516 行
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.
Palme Informational [Page 7]
RFC 2076 Internet Message Headers February 1997
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.
Palme Informational [Page 8]
RFC 2076 Internet Message Headers February 1997
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
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.).
Palme Informational [Page 9]
RFC 2076 Internet Message Headers February 1997
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.
Palme Informational [Page 10]
RFC 2076 Internet Message Headers February 1997
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:".
Palme Informational [Page 11]
RFC 2076 Internet Message Headers February 1997
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.
Palme Informational [Page 12]
RFC 2076 Internet Message Headers February 1997
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.
Palme Informational [Page 13]
RFC 2076 Internet Message Headers February 1997
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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?