RFC 2076
Common Internet Message Headers
Common Internet Message Headers 🎀
RFC 2076 (part 1 of 4 💖) is from the Network Working Group, written by J. Palme of Stockholm University/KTH. It's Informational, dated February 1997. The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🦋
Status of this Memo ✨
okay so this memo is here to provide information for the Internet community ✨ It does not specify an Internet standard of any kind, so it's not a rulebook, just a helpful reference. Distribution of it is unlimited 🌸
Abstract 💅
this doc is basically a cute little table of the headers you see all the time in e-mail message headings 💌 It pulls together info from RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911, plus a few popular headers that aren't defined in any RFC at all 👑 For each header, you get a quick description and a pointer to the RFC where it's defined. iconic 🔥
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........................................... 251. Introduction ✨
so tbh loads of Internet standards and RFCs define headers that can pop up on Internet Mail Messages and Usenet News Articles 💖 This doc is trying to gather all of them into one place, as a handy aid for anyone building message systems or who's just curious about Internet Mail standards 🫶
It covers every header the author found in these 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]. Here's the important bit 👀 heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included. PEM and MOSS headers only show up inside the body of a message, so they aren't headers in the RFC 822 sense 🙅♀️ Mail attributes in envelopes (the stuff controlling how a message moves between mail and news servers) are also left out. That means attributes from SMTP [1], UUCP [18] and NNTP [15] are mostly not covered either. Headings used only in HTTP [19] aren't included yet, though they might be in a future version of this memo ✨ A few extra headers that show up a lot in e-mail, even though they aren't part of any Internet standard, are included anyway 🌈
For each header, the document gives a short description and a reference to the Internet standard or RFC where it's defined 💅
Spelling is a whole thing 😭 The header names are spelled exactly how they're actually used. That's usually American spelling, but sometimes English. One header in particular, "Organisation/Organization", shows up in e-mail with English spelling sometimes and American spelling other times 🌸
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's my intention to keep updating this doc after it's published as an RFC 🧚 The latest version might be more up-to-date (but also less fully checked out), and it's kept available for downloading from:
http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf
And if you spot headers that should be in this memo but aren't, e-mail the author (Jacob Palme <jpalme@dsv.su.se>) 💌
2. Use of gatewaying headers 🦋
okay this part is about gatewaying (bridging between systems) 🌉 RFC 1327 defines a bunch of new headers in Internet mail. They map to headers X.400 already has, which weren't previously standardized in Internet mail. So if a header shows up in RFC 1327, that means it's recommended for gatewaying messages between X.400 and Internet mail. It does not mean the header is recommended for messages that stay entirely within Internet mail 🙈 Some of these might eventually get widespread use in Internet mail, but at the time of writing (1996) they weren't widely implemented or used yet 💀
Headers defined only in RFC 1036 for Usenet News sometimes end up in mail messages. Either the message got gatewayed from Usenet News to e-mail, or it was written in a combined client that supports both e-mail and Usenet News 🫠 These headers aren't standardized for Internet e-mail, so e-mail agents should handle them with caution ⚠️
3. Table of headers 🍓
3.1 Phrases used in the tables 💜
this section explains the labels you'll see in the tables. Here's the tea ☕
"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 🔍
this is the paper trail of where a message has been ✨ Here are the trace headers:
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 ✨
okay bestie, this part is all the little control knobs 🎛️ that tell a message how it should be handled. these are the ones that really matter for format and behaviour 💅
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 💌
this is the "who sent it and who gets it" section, and it's full of drama 🙈 some of these headers are standard, some are non-standard, and a few are straight-up contradictory. the notes are right there in the table so nothing gets lost 🫶
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-
Newsreader3.5. Response control 🎀
this part is about where replies go, and honestly it's giving "it's complicated" 🙃 the sender can want replies sent to different places depending on the kind of reply, so one header isn't always enough. the Usenet headers have their own rules too, so read the notes carefully 👀
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.).
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 🦋
last stop for this part: the headers that give a message its unique ID and tie it to other messages 🧚 some of these are really the glue for threads and replies, so they're kinda iconic 💜
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 ✨
okay so these are the little text headers that carry the vibe 💅 Subject is the big one (it's the thread starter fr), and Keywords is the search-key one for finding stuff in databases 🔍
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.⚠️ bestie, the Summary one is a warning: some mail systems won't even show it to the recipient, so don't put anything in it you really need them to get 🙈
3.8 Headers containing dates and times 🕰️
okay the date stuff is lowkey so important, because Delivery-Date, Date, Expires, Expiry-Date and Reply-By all do different jobs 💖
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 🎀
these are the "how urgent is this, bestie?" headers 🚨 Priority, Precedence and Importance all kinda sound the same but they're not, so read them carefully 🧐
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 🌍
Language and Content-Language both say which natural language the message is in, like en for English 🇬🇧 The Content-Language one is the proposed standard version, so that's the one with the paperwork 📜
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 📏
okay so Content-Length is kinda a drama queen 💀 It's non-standard and discouraged, because putting it in a message that goes across the net can cause robustness and interoperability problems. Lines is the other one, and it's not standardised for e-mail.
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 🔐
these headers are like a "do not touch my characters" sign 🙅♀️ Conversion says whether the body can be changed from one character set to another, and Conversion-With-Loss is the stricter version that only cares about whether information would get lost 🧼
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 🧩
this section is giving main character energy 👑 Content-Type is the star, but you have to check the MIME-version header first to know which rules apply 🤓
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, so keep that in mind 💜
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 you manually forward a message, these Resent- headers talk about the forwarding, not the original one 📨 And MIME has its own way of resending, using the "Message" Content-Type, so don't mix those up 🙃
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 🔒
Content-MD5 is the checksum that lets you check whether the content got changed 🧮 Xref is the Usenet one, and it's only for local use inside one Usenet News server, so it shouldn't be sent between servers 🙈
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 🧚
last stop, the random-but-useful ones 🍓 Fcc says where a copy of the message is saved, and Status is a non-standard field that some mail systems use, and it should never show up in mail in transit 💀
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.the Status letters can mix together too, so Status: OR means the message was downloaded but not deleted 🫶
Status: OR4. Acknowledgments 🫶
okay big thank-you energy here 💖 Harald Tveit Alvestrand, Ned Freed, Olle Jdrnefors, Keith Moore and Nick Smith helped me put this list together, and several other people did too ✨ Ned Freed and Olle Jdrnefors were extra amazing and gave a super thorough review with lots of helpful suggestions for improvements 🙌 I alone take responsibility for any errors that might still be in the list 🙈
An earlier version of this list was published as part of [13] 📚
5. References ✨
Okay bestie, here's the reading list 📚 Every source is in one big table, with who wrote it and what its IETF status was back in July 1996 🎀
Ref. Author, title IETF status
(July 1996)
----- --------------------------------------------- -----------
[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
STD 10, RFC 821, August 1982. Recommended
[2] D. Crocker: "Standard for the format of ARPA Standard,
Internet text messages." STD 11, RFC 822, Recommended
August 1982.
[3] M.R. Horton, R. Adams: "Standard for Not an offi-
interchange of USENET messages", RFC 1036, cial IETF
December 1987. standard,
but in
reality a de-
facto
standard for
Usenet News
[4] M. Sirbu: "A Content-Type header header for Standard,
internet messages", RFC 1049, March 1988. Recommended,
but can in
the future
be expected
to be
replaced by
MIME
[5] R. Braden (editor): "Requirements for Standard,
Internet Hosts -- Application and Support", Required
STD-3, RFC 1123, October 1989.
[6] D. Robinson, R. Ullman: "Encoding Header Non-standard
Header for Internet Messages", RFC 1154,
April 1990.
[7] S. Hardcastle-Kille: "Mapping between Proposed
X.400(1988) / ISO 10021 and RFC 822", RFC standard,
1327 May 1992. elective
[8] H. Alvestrand & J. Romaguera: "Rules for Proposed
Downgrading Messages from X.400/88 to standard,
X.400/84 When MIME Content-Types are Present elective
in the Messages", RFC 1496, August 1993.
[9] A. Costanzo: "Encoding Header Header for Non-standard
Internet Messages", RFC 1154, April 1990.
[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
Header for Internet Messages", RFC 1505,
August 1993.
[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft
Internet Mail Extensions) Part One: Standard,
Mechanisms for Specifying and Describing the elective
Format of Internet Message Bodies", RFC 1521,
Sept 1993.
[12] H. Alvestrand: "Tags for the Identification Proposed
of Languages", RFC 1766, February 1995. standard,
elective
[13] J. Palme: "Electronic Mail", Artech House Non-standard
publishers, London-Boston January 1995.
[14] R. Troost, S. Dorner: "Communicating Experimental
Presentation Information in Internet
Messages: The Content-Disposition Header",
RFC 1806, June 1995.
[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed
Protocol: "A Proposed Standard for the Stream- standard
Based Transmission of News", RFC 977, January
1986.
[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed
S. Murphy, "MIME Object Security Services", standard
RFC 1848, March 1995.
[17] J. Myers, M. Rose: The Content-MD5 Header Draft
Header, RFC 1864, October 1995. standard
[18] M. Horton, UUCP mail interchange format Not an offi-
standard, RFC 976, Januari 1986. cial IETF
standard,
but in
reality a de-
facto
standard for
Usenet News
[19] T. Berners-Lee, R. Headering, H. Frystyk: Not an official
Hypertext Transfer Protocol -- HTTP/1.0, IETF standard,
RFC 1945, May 1996. but the defacto
standard until
the next
version is
published
[20] G. Vaudreuil: Voice Profile for Internet Experimental
Mail, RFC 1911, February 1996.
[21] H. Spencer: News Article Format and Not even an
Transmission, June 1994, RFC, but
FTP://zoo.toronto.edu/pub/news.ps still widely
FTP://zoo.toronto.edu/pub/news.txt.Z used and
partly
This document is often referenced under the almost a de-
name "son-of-RFC1036". facto
standard for
Usenet News6. Author's Address 💌
Here's who wrote it, so you know who to slide into the DMs 🫶
Jacob Palme Phone: +46-8-16 16 67
Stockholm University/KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme@dsv.su.se
S-164 40 Kista, SwedenAppendix A: Headers sorted by Internet RFC document in which they appear 🗂️
Okay, this is the big sorting hat 🧚 Every header is grouped by the RFC it shows up in, so you can find your favourite fast.
RFC 822
bcc
cc
Comments
Date
From
In-Reply-To
Keywords
Message-ID
Received
References
Reply-To
Resent-
Resent-bcc
Resent-cc
Resent-Date
Resent-From
Resent-From
Resent-Message-ID
Resent-Reply-To
Resent-To
Return-Path
Sender
Sender
Subject
ToRFC 976
"From " (followed by space, not colon (:")RFC 1036
Approved
Control
Distribution
Expires
Followup-To
Lines
Newsgroups
Organization
Path
Summary
XrefRFC 1049
Content-TypeRFC 1327
Alternate-recipient
Auto-Forwarded
Autoforwarded
Content-Identifier
Content-Return
Conversion
Conversion-With-Loss
Delivery-Date
Discarded-X400-IPMS-Extensions
Discarded-X400-MTS-Extensions
Disclose-Recipients
DL-Expansion-History
Expiry-Date
Generate-Delivery-Report
Importance
Incomplete-Copy
Language
Message-Type Delivery
Obsoletes
Original-Encoded-Information-Types
Prevent-NonDelivery-Report
Priority
Reply-By
Report
SensitivityRFC 1505
EncodingRFC 1521
Content-Description
Content-ID
Content-Transfer-Encoding
Content-Type
MIME-VersionRFC 1806
Content-DispositionRFC 1864
Content-MD5RFC 1911
Importance
Sensitivityson-of-RFC1036 [21]
Also-Control
Article-Names
Article-Updates
See-Also
SupersedesNot Internet standard
Apparently-to
Content-Base
Content-Length
Content-Location
Content-SGML-Entity
Encoding
Errors-To
Return-Receipt-To
Fax
"From " (not followed by ":")
Telefax
Fcc
For-Comment
For-Handling
Mail-System-Version
Mailer
Organisation
Originating-Client
Phone
Status
Supersedes
X400-Content-Return
X-Mailer
X-NewsreaderAppendix B: Alphabetical index 🦋
And last but not least, the alphabetical index 💖 Every header, the section it lives in, and where to find it. Super handy when you're hunting for one specific header at 2am 😭
Section Heading-header
------- --------------
3.3 Also-Control
3.3 Alternate-Recipient
3.4 Apparently-To
3.4 Approved
3.6 Article-Names
3.6 Article-Updates
3.16 Auto-Forwarded
3.4 bcc
3.4 cc
Client, see Originating-Client
3.7 Comments
3.6 Content-Base
3.12 Content-Conversion
3.7 Content-Description
3.3 Content-Disposition
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
3.8 Date
3.8 Delivery-Date
Delivery-Report, see Generate-Delivery-Report, Prevent-
Delivery-Report, Non-Delivery-Report, Content-Type
Description, see Content-Description
3.16 Discarded-X400-IPMS-Extensions
3.16 Discarded-X400-MTS-Extensions
3.3 Disclose-Recipients
Disposition, see Content-Disposition
3.4 Distribution
3.2 DL-Expansion-History-Indication
3.13 Encoding see also Content-Transfer-Encoding
3.4 Errors-To
3.8 Expires
Extension see Discarded-X400-IPMS-Extensions, Discarded-
X400-MTS-Extensions
3.4 Fax
3.16 Fcc
3.4 Followup-To
Forwarded, see Auto-Forwarded
3.4 For-Comment
3.4 For-Handling
3.4 From
3.4 Generate-Delivery-Report
History, see DL-Expansion-History-Indication
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
3.10 Language see also Content-Language
Length see Content-Length
3.11 Lines
3.4 Mail-System-Version see also X-mailer
3.4 Mailer
MD5 see Content-MD5
3.6 Message-ID
3.13 Message-Type
3.3 MIME-Version
3.4 Newsgroups
Newsreader, see X-Newsreader
3.6 Obsoletes
3.7 Organisation
3.7 Organization
3.3 Original-Encoded-Information-Types
3.4 Originating-Client
3.2 Path
3.4 Phone
3.9 Precedence
3.4 Prevent-NonDelivery-Report
3.9 Priority
3.2 Received
Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
Recipient
3.6 References
3.8 Reply-By
3.4 Reply-To, see also In-Reply-To, References
3.14 Resent-
Return see also Content-Return
3.2 Return-Path
3.5 Return-Receipt-To
3.6 See-Also
3.4 Sender
3.9 Sensitivity
3.16 Status
3.7 Subject
3.7 Summary
3.6 Supersedes
3.4 Telefax
3.4 To
Transfer-Encoding see Content-Transfer-Encoding
Type see Content-Type, Message-Type, Original-Encoded-
Information-Types
Version, see MIME-Version, X-Mailer
3.4 X400-Content-Return
3.4 X-Mailer see also Mail-System-Version
3.4 X-Newsreader
3.15 Xref📦 where this page comes from
- ietf: rfc2076 1997-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms