As per Relevance of the word february, we have this rfc below:
Network Working Group J.
Request for Comments: 2076 Stockholm University/
Category: Informational February 1997
Common Internet Message
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo contains a table of commonly occurring headers in
of e-mail messages. The document compiles information from other
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
headers which are not defined in RFCs are also included. For
header, the memo gives a short description and a reference to the
in which the header is defined
Table of
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
Palme Informational [Page 1]
RFC 2076 Internet Message Headers February 1997
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.
Many different Internet standards and RFCs define headers which
occur on Internet Mail Messages and Usenet News Articles.
intention of this document is to list all such headers in
document as an aid to people developing message systems or
in Internet Mail standards
The document contains all headers which the author has found in
following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123
[5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12],
1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular
heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
[16]) are not included. PEM and MOSS headers only appear inside
body of a message, and thus are not headers in the RFC 822 sense
Mail attributes in envelopes, i.e. attributes controlling the
transport mechanism between mail and news servers, are not included
This means that attributes from SMTP [1], UUCP [18] and NNTP [15]
mainly not covered either. Headings used only in HTTP [19] are
included yet, but may be included in future version of this memo.
few additional headers which often can be found in e-mail
but are not part of any Internet standard are also included
For each header, the document gives a short description and
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
actually used. This is usually American but sometimes
spelling. One header in particular, "Organisation/Organization",
occurs in e-mail headers sometimes with the English and other
with the American spelling
The following words are used in this memo with the meaning
below
heading Formatted text at the top of a message, ended by
blank
header = heading One field in the heading, beginning with a
field name, colon, and followed by the field value(s
Palme Informational [Page 2]
RFC 2076 Internet Message Headers February 1997
It is my intention to continue updating this document after
publication as an RFC. The latest version, which may be more up-to
date (but also less fully checked out) will be kept available
downloading from
http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf
Please e-mail me (Jacob Palme ) if you have
headers which should be included in this memo but are not
2. Use of gatewaying
RFC 1327 defines a number of new headers in Internet mail, which
defined to map headers which X.400 has but which were previously
standardized in Internet mail. The fact that a header occurs in
1327 indicates that it is recommended for use in gatewaying
between X.400 and Internet mail, but does not mean that the header
recommended for messages wholly within Internet mail. Some of
headers may eventually see widespread implementation and use
Internet mail, but at the time of this writing (1996) they are
widely implemented or used
Headers defined only in RFC 1036 for use in Usenet News
appear in mail messages, either because the messages have
gatewayed from Usenet News to e-mail, or because the messages
written in combined clients supporting both e-mail and Usenet News
the same client. These headers are not standardized for use
Internet e-mail and should be handled with caution by e-mail agents
3. Table of
3.1 Phrases used in the
"not for general Used to mark headers which are defined in
usage" 1327 for use in messages from or to
mail/X.400 gateways. These headers have
been standardized for general usage in
exchange of messages between Internet mail
based systems
Palme Informational [Page 3]
RFC 2076 Internet Message Headers February 1997
"not standardized Used to mark headers defined only in RFC 1036
for use in e-mail" for use in Usenet News. These headers have
standard meaning when appearing in e-mail
some of them may even be used in
ways by different software. When appearing
e-mail, they should be handled with caution
Note that RFC 1036, although generally used
a de-facto standard for Usenet News, is not
official IETF standard or even on the
standards track
"non-standard" This header is not specified in any
referenced RFCs which define
protocols, including Internet Standards,
standards or proposed standards. The
appears here because it often appears in e
mail or Usenet News. Usage of these headers
not in general recommended. Some
proposed in ongoing IETF standards
work, but not yet accepted, are also marked
this way
"discouraged" This header, which is non-standard, is
to create problems and should not
generated. Handling of such headers
incoming mail should be done with
caution
"controversial" The meaning and usage of this header
controversial, i.e. different
have chosen to implement the header
different ways. Because of this, such
should be handled with caution
understanding of the different
interpretations
"experimental" This header is used for newly defined headers
which are to be tried out before entering
IETF standards track. These should only
used if both communicating parties agree
using them. In practice, some
protocols become de-facto-standards
they are made into IETF standards
Palme Informational [Page 4]
RFC 2076 Internet Message Headers February 1997
3.2 Trace
Used to convey the information Return-Path: RFC 821,
from the MAIL FROM envelope RFC 1123: 5.2.13.
attribute in final delivery,
the message leaves the
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
News, not in e
mail
Trace of distribution lists DL-Expansion- RFC 1327, not
passed. History- general usage
Indication
3.3 Format and control
An indicator that this message is MIME-Version: RFC 1521: 3.
formatted according to the
standard, and an indication
which version of MIME
utilized
Special Usenet News actions only. Control: RFC 1036: 2.1.6,
only in
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
Usenet News,
in e-
Which body part types occur in Original- RFC 1327, not
this message. Encoded- general usage
Information
Types
Palme Informational [Page 5]
RFC 2076 Internet Message Headers February 1997
Controls whether this message may Alternate- RFC 1327, not
be forwarded to alternate Recipient: general usage
recipients such as a
if delivery is not possible
the intended recipient. Default
Allowed
Whether recipients are to be told Disclose- RFC 1327, not
the names of other recipients of Recipients: general usage
the same message. This
primarily an X.400 facility.
X.400, this is an
attribute and refers
disclosure of the
recipient list. Disclosure
other recipients is in
mail done via the To:, cc:
bcc: headers
Whether a MIME body part is to be Content- RFC 1806,
shown inline or is an attachment; Disposition:
can also indicate a
filename for use when saving
attachment to a file
3.4 Sender and recipient
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
appear in e-mail being sent, and for use in e-
should thus not appear in
memo. It is however included
since people often ask about it
Palme Informational [Page 6]
RFC 2076 Internet Message Headers February 1997
This header is used in the so
called Unix mailbox format,
known as Berkely mailbox
or the MBOX format. This is
format for storing a set
messages in a file. A
beginning with "From " is used
separate successive messages
such files
This header will thus appear
you use a text editor to look
a file in the Unix
format. Some mailers also
this format when
messages on paper
The information in this
should NOT be used to find
address to which replies to
message are to be sent
(2) Used in Usenet News mail From RFC 976: 2.4
transport, to indicate the path or use in Usenet
through which an article has gone >
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
is sent; necessary on an article for use in e-mail
sent to a moderated newsgroup
allow its distribution to
newsgroup members. Also used
certain control messages,
are only performed if they
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-
requested to handle
information in this
or its attachments
Primary recipients, who are For-Comment: Non-
requested to comment on
information in this
or its attachments
In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3,
this article was posted. not
Some systems provide this header and
also in e-mail although it is not for use in e-mail
standardized there
Unfortunately, the header
appear in e-mail with
different and
meanings
(a) Indicating the
recipient of an article/
sent to both e-mail and
News recipients
(b) In a personally
reply to an article in a news
group, indicating the
in which this
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
recipients derived from the RFC 1211.
envelope into the
heading. This behavior is
quite proper, MTAs should
modify headings (except
Received lines), and it can
some cases cause Bcc
to be wrongly divulged to non-
recipients
Geographical or organizational Distribution: RFC 1036: 2.2.7,
limitation on where this article not
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
3.5 Response
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
different kinds of replies,
the sender may wish to go
different addresses.
particular, there are
replies intended for only
person, and group replies
intended for the whole group
people who read the replied-
message (often a mailing list
anewsgroup name cannot
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
to indicate a better form of
e-mail address of the sender
Some mailing list expanders
the name of the list in
header. These practices
controversial. The
opinion of the author of this
is that this header should
avoided except in special cases
but this is a personal
not shared by all specialists
the area
Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3,
that future discussions (=follow- not
up) on an article should go to a for use in e-mail
different set of newsgroups
the replied-to article. The
common usage is when an
is posted to several newsgroups
and further discussions is
take place in only one of them
In e-mail, this header may
in a message which is sent
both e-mail and Usenet News,
show where follow-up in
news is wanted. The header
not say anything about
follow-up in e-mail is to
sent
Note that the value of
header must always be one or
newsgroup names, never e-
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
Return-Path, not Errors-To,
where delivery notifications
to be sent
Palme Informational [Page 10]
RFC 2076 Internet Message Headers February 1997
Whether non-delivery report is Prevent- RFC 1327, not
wanted at delivery error. Default NonDelivery- general usage
is to want such a report. Report
Whether a delivery report is Generate- RFC 1327, not
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
a message is to be returned with Return: general usage
non-delivery notifications
Possible future change of name X400-Content- non-
for "Content-Return:" Return
3.6 Message identification and referral
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-
relative URIs within this
part
URI with which the content of Content- Non-
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-
Reference to previous message Obsoletes: RFC 1327, not
being corrected and replaced. general usage
Compare to "Supersedes:" below
This field may in the future
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-
header described above. In
News, however, Supersedes
a full deletion of the
article in the server,
"Supersedes" and "Obsoletes" in e
mail is implemented in the
and often does not remove the
version of the text
Only in Usenet News, similar to Article- son-of-RFC1036
"Supersedes:" but does not cause Updates: [21], non-
the referenced article to
physically deleted
Reference to specially important Article- son-of-RFC1036
articles for a particular Usenet Names: [21], non-
Newsgroup
3.7 Other textual
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
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
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
systems will not display this for use in e-mail
text to the recipient. Because of discouraged
this, do not use this header
text which you want to
that the recipient gets
Palme Informational [Page 12]
RFC 2076 Internet Message Headers February 1997
A text string which identifies Content- RFC 1327, not
the content of a message. Identifier: general usage
3.8 Headers containing dates and
The time when a message was Delivery- RFC 1327, not
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
use the date when the message
submitted
A suggested expiration date. Can Expires: RFC 1036: 2.2.4,
be used both to limit the time of not
an article which is not for use in e-mail
meaningful after a certain date
and to extend the storage
important articles
Time at which a message loses its Expiry-Date: RFC 1327, not
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
requested (not demanded). general usage
3.9 Quality
Can be "normal", "urgent" or "non- Priority: RFC 1327, not
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"
"first-class". Other uses is
control automatic replies and
control return-of-
facilities, and to stop
list loops
Palme Informational [Page 13]
RFC 2076 Internet Message Headers February 1997
A hint from the originator to the Importance: RFC 1327
recipients about how important a RFC 1911,
message is. Values: High, normal
or low. Not used to
transmission speed
How sensitive it is to disclose Sensitivity: RFC 1327
this message to other people than RFC 1911,
the specified recipients. Values:
Personal, private,
confidential. The absence of
header in messages gatewayed
X.400 indicates that the
is not sensitive
Body parts are missing. Incomplete- RFC 1327, not
Copy: general usage
3.10 Language
Can include a code for the Language: RFC 1327, not
natural language used in a general usage
message, e.g. "en" for English
Can include a code for the Content- RFC 1766,
natural language used in a Language: standard
message, e.g. "en" for English
3.11 Size
Inserted by certain mailers to Content- Non-standard
indicate the size in bytes of the Length: discouraged
message text. This is part of
format some mailers use
showing a message to its users
and this header should not
used when sending a
through the net. The use of
header in transmission of
message can cause
robustness and
problems
Size of the message. Lines: RFC 1036: 2.2.12,
not
for use in e-mail
Palme Informational [Page 14]
RFC 2076 Internet Message Headers February 1997
3.12 Conversion
The body of this message may not Conversion: RFC 1327, not
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
be converted from one character With-Loss: general usage
set to another if
will be lost. Values:
and allowed
3.13 Encoding
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
"MIME-version" header
understand if Content-Type is
be interpreted according to
1049 or according to MIME.
MIME definition should be used
generating mail
RFC 1766 defines a
"difference" to this header
Information from the SGML entity Content-SGML- non-
declaration corresponding to the Entity
entity contained in the body
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
"Delivery Report" to indicates general usage
that this is a delivery
gatewayed from X.400.
Palme Informational [Page 15]
RFC 2076 Internet Message Headers February 1997
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
and length information, some
a kind of boundary information
some in other ways
3.14 Resent-
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
Checksum of content to ensure Content-MD5: RFC 1864,
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
reader the same article twice if News, not in e
it was sent to more than one mail
newsgroup. Only for local
within one Usenet News server
should not be sent
servers
3.16
Name of file in which a copy of Fcc: Non-standard
this message is stored
Has been automatically forwarded. Auto- RFC 1327, not
Forwarded: general usage
Palme Informational [Page 16]
RFC 2076 Internet Message Headers February 1997
Can be used in Internet mail to Discarded- RFC 1327, not
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
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
status of delivery for this appear in mail
message when stored. Common transit
values of this field are
U message is not
and not deleted
R message is read
downloaded
O message is old but
deleted
D to be deleted
N new (a new message
sometimes is
by not having any "Status:"
header
Combinations of these
can occur, such as "Status: OR
to indicate that a message
downloaded but not deleted
Palme Informational [Page 17]
RFC 2076 Internet Message Headers February 1997
4.
Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore,
Smith and several other people have helped me with compiling
list. I especially thank Ned Freed and Olle Jdrnefors for
thorough review and many helpful suggestions for improvements.
alone take responsibility for any errors which may still be in
list
An earlier version of this list has been published as part of [13].
5.
Ref. Author, title IETF
(July 1996)
----- --------------------------------------------- -----------
[1] J. Postel: "Simple Mail Transfer Protocol", Standard
STD 10, RFC 821, August 1982.
[2] D. Crocker: "Standard for the format of ARPA Standard
Internet text messages." STD 11, RFC 822,
August 1982.
[3] M.R. Horton, R. Adams: "Standard for Not an offi
interchange of USENET messages", RFC 1036, cial
December 1987. standard
but
reality a de
standard
Usenet
[4] M. Sirbu: "A Content-Type header header for Standard
internet messages", RFC 1049, March 1988. Recommended
but can
the
be
to
replaced
[5] R. Braden (editor): "Requirements for Standard
Internet Hosts -- Application and Support",
STD-3, RFC 1123, October 1989.
[6] D. Robinson, R. Ullman: "Encoding Header Non-
Header for Internet Messages", RFC 1154,
April 1990.
Palme Informational [Page 18]
RFC 2076 Internet Message Headers February 1997
[7] S. Hardcastle-Kille: "Mapping between
X.400(1988) / ISO 10021 and RFC 822", RFC standard
1327 May 1992.
[8] H. Alvestrand & J. Romaguera: "Rules for
Downgrading Messages from X.400/88 to standard
X.400/84 When MIME Content-Types are Present
in the Messages", RFC 1496, August 1993.
[9] A. Costanzo: "Encoding Header Header for Non-
Internet Messages", RFC 1154, April 1990.
[10] A. Costanzo, D. Robinson: "Encoding Header
Header for Internet Messages", RFC 1505,
August 1993.
[11] N. Borenstein & N. Freed: "MIME (Multipurpose
Internet Mail Extensions) Part One: Standard
Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521,
Sept 1993.
[12] H. Alvestrand: "Tags for the Identification
of Languages", RFC 1766, February 1995. standard
[13] J. Palme: "Electronic Mail", Artech House Non-
publishers, London-Boston January 1995.
[14] R. Troost, S. Dorner: "Communicating
Presentation Information in
Messages: The Content-Disposition Header",
RFC 1806, June 1995.
[15] B. Kantor, P. Lapsley, "Network News Transfer
Protocol: "A Proposed Standard for the Stream-
Based Transmission of News", RFC 977,
1986.
[16] 1848 PS S. Crocker, N. Freed, J. Galvin,
S. Murphy, "MIME Object Security Services",
RFC 1848, March 1995.
[17] J. Myers, M. Rose: The Content-MD5 Header
Header, RFC 1864, October 1995.
Palme Informational [Page 19]
RFC 2076 Internet Message Headers February 1997
[18] M. Horton, UUCP mail interchange format Not an offi
standard, RFC 976, Januari 1986. cial
standard
but
reality a de
standard
Usenet
[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an
Hypertext Transfer Protocol -- HTTP/1.0, IETF standard
RFC 1945, May 1996. but the
standard
the
version
[20] G. Vaudreuil: Voice Profile for Internet
Mail, RFC 1911, February 1996.
[21] H. Spencer: News Article Format and Not even
Transmission, June 1994, RFC,
FTP://zoo.toronto.edu/pub/news.ps still
FTP://zoo.toronto.edu/pub/news.txt.Z used
This document is often referenced under the almost a de
name "son-of-RFC1036".
standard
Usenet
6. Author's
Jacob Palme Phone: +46-8-16 16 67
Stockholm University/KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme@dsv.su.
S-164 40 Kista,
Palme Informational [Page 20]
RFC 2076 Internet Message Headers February 1997
Appendix A
Headers sorted by Internet RFC document in which they appear
RFC 822
-------
In-Reply-
Message-
Reply-
Resent
Resent-
Resent-
Resent-
Resent-
Resent-
Resent-Message-
Resent-Reply-
Resent-
Return-
RFC 976
-------
"From " (followed by space, not colon (:")
Palme Informational [Page 21]
RFC 2076 Internet Message Headers February 1997
RFC 1036
--------
Followup-
RFC 1049
--------
Content-
RFC 1327
--------
Alternate-
Auto-
Content-
Content-
Conversion-With-
Delivery-
Discarded-X400-IPMS-
Discarded-X400-MTS-
Disclose-
DL-Expansion-
Expiry-
Generate-Delivery-
Incomplete-
Message-Type
Original-Encoded-Information-
Prevent-NonDelivery-
Reply-
Palme Informational [Page 22]
RFC 2076 Internet Message Headers February 1997
RFC 1505
--------
RFC 1521
--------
Content-
Content-
Content-Transfer-
Content-
MIME-
RFC 1806
--------
Content-
RFC 1864
--------
Content-MD
RFC 1911
--------
son-of-RFC1036 [21]
-------------------
Also-
Article-
Article-
See-
Palme Informational [Page 23]
RFC 2076 Internet Message Headers February 1997
Not Internet
---------------------
Apparently-
Content-
Content-
Content-
Content-SGML-
Errors-
Return-Receipt-
"From " (not followed by ":")
For-
For-
Mail-System-
Originating-
X400-Content-
X-
X-
Palme Informational [Page 24]
RFC 2076 Internet Message Headers February 1997
Appendix B
Alphabetical
Section Heading-
------- --------------
3.3 Also-
3.3 Alternate-
3.4 Apparently-
3.4
3.6 Article-
3.6 Article-
3.16 Auto-
3.4
3.4
Client, see Originating-
3.7
3.6 Content-
3.12 Content-
3.7 Content-
3.3 Content-
3.6 Content-
3.7 Content-
3.10 Content-Language see also
3.11 Content-
3.6 Content-
3.15 Content-MD
3.4 Content-
3.13 Content-SGML-
3.13 Content-Transfer-
3.13 Content-
3.3
3.12
3.12 Conversion-With-
3.8
3.8 Delivery-
Delivery-Report, see Generate-Delivery-Report, Prevent
Delivery-Report, Non-Delivery-Report, Content-
Description, see Content-
3.16 Discarded-X400-IPMS-
3.16 Discarded-X400-MTS-
3.3 Disclose-
Disposition, see Content-
3.4
3.2 DL-Expansion-History-
3.13 Encoding see also Content-Transfer-
3.4 Errors-
Palme Informational [Page 25]
RFC 2076 Internet Message Headers February 1997
3.8
Extension see Discarded-X400-IPMS-Extensions, Discarded
X400-MTS-
3.4
3.16
3.4 Followup-
Forwarded, see Auto-
3.4 For-
3.4 For-
3.4
3.4 Generate-Delivery-
History, see DL-Expansion-History-
ID, see Content-ID and Message-
Identifier, see Content-ID and Message-
3.9
3.6 In-Reply-
3.9 Incomplete-
3.7
3.10 Language see also Content-
Length see Content-
3.11
3.4 Mail-System-Version see also X-
3.4
MD5 see Content-MD
3.6 Message-
3.13 Message-
3.3 MIME-
3.4
Newsreader, see X-
3.6
3.7
3.7
3.3 Original-Encoded-Information-
3.4 Originating-
3.2
3.4
3.9
3.4 Prevent-NonDelivery-
3.9
3.2
Recipient, see To, cc, bcc, Alternate-Recipient, Disclose
3.6
3.8 Reply-
3.4 Reply-To, see also In-Reply-To,
3.14 Resent
Return see also Content-
3.2 Return-
Palme Informational [Page 26]
RFC 2076 Internet Message Headers February 1997
3.5 Return-Receipt-
3.6 See-
3.4
3.9
3.16
3.7
3.7
3.6
3.4
3.4
Transfer-Encoding see Content-Transfer-
Type see Content-Type, Message-Type, Original-Encoded
Information-
Version, see MIME-Version, X-
3.4 X400-Content-
3.4 X-Mailer see also Mail-System-
3.4 X-
3.15
Palme Informational [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
