|
Network
Working Group
Internet
Draft
draft-palme-mailext-headers-05.txt
Category:
Informational
Revision
of: RFC 2076
|
Jacob
Palme
Stockholm
University/KTH
Sweden
Expires:
April 2002
|
|
This
memo contains tables of commonly occurring header fields in headings
of e-mail messages. The document compiles information from other RFCs
such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC
2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly occurring header
fields which are not defined in RFCs are also included. For each header
field, the memo gives a short description and a reference to the RFC
in which the header field is defined.
The
latest, revised version of this document can be found at URL
http://www.dsv.su.se/jpalme/ietf/mail-headers/.
The version at that
URL
may be more recent than the version published as an RFC.
Another
list of headers can be found at URL
http://www.hut.fi/~jkorpela/headers.html
[28]
|
|
This
document is a revision of RFC 2076. The following new header fields,
not included in RFC 2076, have been added:
Abuse-Reports-To:,
Also-Control, Approved-By, Content-Alias, Content-Alternative, Content-Class,
Content-Conversion, Content-Features, Content-ID, Delivered-To, Disposition-Notification-Options,
Disposition-Notification-To, Expiry-Date, For-Approval, List-Archive,
List-Digest, List-Help, List-ID, List-Owner, List-Post, List-Software,
List-Subscribe, List-Unsubscribe, List-URL, Mail-Copies-To:, Original-Recipient,
Originator, Originator-Info, Path, PICS-Label, NNTP-Posting-Host, Posted-To:,
Read-Receipt-To, Received, Registered-Mail-Reply-Requested-By, Replaces,
Return-Receipt-Requested, Speech-Act, Translated-By. Translation-Of,
User-Agent, X-Confirm-Reading-To, X-Complaints-To:, X-Envelope-From,
X-Envelope-To, X-Face, X-List-Host, X-Listserver, X-Loop, X-MIME-Autoconverted,
X-No-Archive, X-OriginalArrivalTime, X-Priority, X-Report-Abuse-To,
X-Sender, X-X-Sender, X-UIDL, X-URL, X-URI.
|
|
Many
different Internet standards and RFCs define header fields which may
occur on Internet Mail Messages and Usenet News Articles. The intention
of this document is to list all such header fields in one document as
an aid to people developing message systems or interested in Internet
Mail standards.
The
document contains all header fields which the author has found in the
following Internet standards: RFC 822 [2], RFC 1036 [3], RFC 1123 [5],
RFC 2156 [7], RFC 1496 [8], RFC 2045 [11], RFC 1766 [12], RFC 2183 [14],
RFC 1864[17] and RFC 2421[20]. Note in particular that heading attributes
defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included.
PEM and MOSS header fields only appear inside the body of a message,
and thus are not header fields 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. Some additional header fields which
often can be found in e-mail headings but are not part of any Internet
standard are also included.
The
author does not promise that this document contains a complete list
of all heading fields which are specified in any standard or used by
any mailer.
For
each header field, the document gives a short description and a reference
to the Internet standard or RFC, in which they are defined.
The
header field names given here are spelled the same way as when they
are actually used. This is usually American but sometimes English spelling.
One header field in particular, "Organisation/Organization", occurs
in e-mail header fields 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
field
|
One
field in the heading, beginning with a field name, colon, and followed
by the field value(s). The words "heading field" and "header" are also
sometimes used with this meaning.
|
|
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-headers
Please
e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted header
fields which should be included in this memo but are not.
|
|
RFC
2156 defines a number of new header fields in Internet mail, which are
defined to map header fields which X.400 has but which were previously
not standardized in Internet mail. The fact that a header field occurs
in RFC 2156 indicates that it is recommended for use in gatewaying messages
between X.400 and Internet mail, but does not mean that the header field
is recommended for messages wholly within Internet mail. Some of these
header fields may eventually see widespread implementation and use in
Internet mail, but at the time of this writing (2001) they are not widely
implemented or used.
Header
fields 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
header fields are not standardized for use in Internet e-mail and should
be handled with caution by e-mail agents.
|
|
"not
for general usage"
|
Used
to mark header fields which are defined in RFC 2156 for use in messages
from or to Internet mail/X.400 gateways. These header fields have not
been standardized for general usage in the exchange of messages between
Internet mail-based systems.
|
|
"not
standardized for use in e-mail"
|
Used
to mark header fields defined only in RFC 1036 for use in Usenet News.
These header fields 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 field is not specified in any of referenced RFCs which define
Internet protocols, including Internet Standards, draft standards or
proposed standards. The header field appears here because it often appears
in e-mail or Usenet News. Usage of these header fields is not in general
recommended. Some header field proposed in ongoing IETF standards development
work, but not yet accepted, are also marked in this way.
|
|
"discouraged"
|
This
header field, which is non-standard, is known to create problems and
should not be generated. Handling of such header fields in incoming
mail should be done with great caution.
|
|
"controversial"
|
The
meaning and usage of this header field is controversial, i.e. different
implementors have chosen to implement the header field in different
ways. Because of this, such header fields should be handled with caution
and understanding of the different possible interpretations.
|
|
"experimental"
|
This
header field is used for newly defined header fields, 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.
|
|
Trace
of distribution lists passed.
|
DL-Expansion-History:
|
RFC
2156, not for general usage.
|
|
List
of MTAs passed.
|
Path:
|
RFC
1036: 2.1.6, only in Usenet News, not in e-mail.
|
|
Trace
of MTAs which a message has passed.
|
Received:
|
RFC
822: 4.3.2, RFC 1123: 5.2.8.
|
|
Used
to convey the information from the MAIL FROM envelope attribute in final
delivery, when the message leaves the SMTP environment in which "MAIL
FROM" is used.
|
Return-Path:
|
RFC
821,
RFC
1123: 5.2.13.
|
|
The
netnews host, to which this article was originally posted. Useful for
finding the sender of spams. Since this header is added by the news
server, it is a little more difficult to forge than other header fields.
|
NNTP-Posting-Host:
|
Non-standard,
common in netnews
|
|
Special
Usenet News commands and a normal article at the same time.
|
Also-Control:
|
son-of-RFC1036
[21], non-standard, only in Usenet News, not in e-mail
|
|
Controls
whether this message may be forwarded to alternate recipients such as
a postmaster if delivery is not possible to the intended recipient.
Default: Allowed.
|
Alternate-Recipient:
|
RFC
2156, not for general usage.
|
|
Whether
a MIME body part is to be shown inline or is an attachment; can also
indicate a suggested filename for use when saving an attachment to a
file.
|
Content-Disposition:
|
RFC
2183, experimental
|
|
Can
have the values "voice-message", "fax-message", "pager-message", "multimedia-message",
"text-message", "none"
|
Message-Context:
|
Non-standard
|
|
Only
in Usenet News, contains commands to be performed by News agents.
|
Control:
|
RFC
1036: 2.1.6, only in Usenet News, not in e-mail.
|
|
Whether
recipients are to be told the names of other recipients of 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:
header fields.
|
Disclose-Recipients:
|
RFC
2156, not for general usage.
|
|
An
indicator that this message is formatted according to the MIME standard,
and an indication of which version of MIME is utilized.
|
MIME-Version:
|
RFC
2045: 4.
|
|
Which
body part types occur in this message.
|
Original-Encoded-Information-Types:
|
RFC
2156, not for general usage.
|
|
Inserted
by Sendmail when there is no "To:" recipient in the original message,
listing recipients derived from the 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.
|
Apparently-To:
|
Non-standard,
discouraged, mentioned in
RFC
1211.
|
|
Name
of the moderator of the newsgroup to which this article is sent; necessary
on an article 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.
|
Approved:
|
RFC
1036: 2.2.11, not standardized for use in e-mail.
|
|
Name
of the moderator of a mailing list, and who has approved this message
for distribution to the members of the list.
|
Approved-By:
|
Non-standard,
used by some mailing list expansion systems.
|
|
Recipients
not to be disclosed to other recipients. (bcc = Blind Carbon Copy).
|
bcc:
|
RFC
822: 4.5.3,
RFC
1123: 5.2.15-16, 5.3.7.
|
|
Secondary,
informational recipients. (cc = Carbon Copy)
|
cc:
|
RFC
822: 4.5.2,
RFC
1123. 5.2.15-16, 5.3.7.
|
|
Geographical
or organizational limitation on where this article can be distributed.
Value can be a compete or incomplete domain names, also various special
values are accepted like "world", "usenet", "USA", etc.
|
Distribution:
|
RFC
1036: 2.2.7, not standardized for use in e-mail.
|
|
Fax
number of the originator.
|
Fax:,
Telefax:
|
Non-standard.
|
|
Primary
recipients, who are requested to approve the information in this message
or its attachments.
|
For-Approval:
|
Non-standard
|
|
Primary
recipients, who are requested to comment on the information in this
message or its attachments.
|
For-Comment:
|
Non-standard
|
|
Primary
recipients, who are requested to handle the information in this message
or its attachments.
|
For-Handling:
|
Non-standard
|
|
(2)
Used in Usenet News mail transport, to indicate the path through which
an article has gone when transferred to a new host.
Sometimes
called "From_" header field.
|
From
or
>From
(not
followed by a colon)
|
RFC
976: 2.4 for use in Usenet News
|
|
(1)
This header field should never appear in e-mail being sent, and should
thus not appear in this memo. It is however included, since people often
ask about it.
This
header field 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 field 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 field should NOT be used to find an address
to which replies to a message are to be sent.
|
From
(not followed by a colon)
|
not
standardized for use in e-mail
|
|
Authors
or persons taking responsibility for the message.
Note
difference from the "From " header field (not followed by ":") below.
|
From:
|
RFC
822: 4.4.1,
RFC
1123: 5.2.15-16, 5.3.7,
RFC
1036 2.1.1
|
|
Information
about the client software of the originator.
|
Mail-System-Version:,
Mailer:, Originating-Client:, X-Mailer, X-Newsreader, X-MimeOLE:, User-Agent:
|
Non-standard.
|
|
In
Usenet News: group(s) to which this article was posted.
Some
systems provide this header field also in e-mail although it is not
standardized there.
Unfortunately,
the header field can appear in e-mail with three 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 message adressed to some mail to news gateways, indicates the newsgroup(s)
that the message is to be posted to.
(c)
In a personally addressed reply to an article in a news-group, indicating
the newsgroup in which this discussion originated.
See
also: "Posted-To:".
|
Newsgroups:
|
RFC
1036: 2.1.3, not standardized and controversial for use in e-mail.
|
|
Sometimes
used in Usenet News in similar ways to "Sender:"
Also
used in printing protocols.
|
Originator:
|
Non-standard
in Usenet News, Experimental in RFC 1528.
|
|
Contains
information about the authentication of the originator in a format which
is not easily used to send email to, to avoid the problems with "Sender"
and "X-Sender".
|
Originator-Info:
|
Non-standard
[25]
|
|
Phone
number of the originator.
|
Phone:
|
Non-standard.
|
|
The
person or agent submitting the message to the network, if other than
shown by the From: header field. Should be authenticated,
according
to RFC 822, but what
kind
of authentication is not
clear.
Some implementations expect that the e-mail address used in this field
can be used to reach the sender, others do not. See also "X-Sender".
|
Sender:
|
RFC
822: 4.4.2,
RFC
1123: 5.2.15-16, 5.3.7, RFC 1036.
|
|
Primary
recipients.
|
To:
|
RFC
822: 4.5.1,
RFC
1123: 5.2.15-16, 5.3.7.
|
|
If
the sender in the envelope (SMTP "RCTP TO") is not the same as the senders
in the "From" or "Sender" RFC822 header fields, some mail servers add
this to the RFC822 header fields as an aid to clients which would otherwise
not be able to display this information.
|
X-Envelope-From:
|
Non-standard.
|
|
If
the recipient in the envelope (SMTP "MAIL FROM") is not included in
the CC list, some mail servers add this to the RFC822 header field as
an aid to clients which would otherwise not be able to display the envelope
recipients.
|
X-Envelope-To:,
Envelope-To: |
Non-standard.
|
|
48x48
bitmap with picture of the sender of this message.
|
X-Face:
|
Non-Standard
|
|
Indication
in the mail header of recipient on the SMTP envelope.
|
X-RCPT-TO:
|
Non-standard
|
|
Some
mail software expect "Sender:" to be an e-mail address which you can
send mail to. However, some mail software has as the best authenticated
sender a POP or IMAP account, which you might not be able to send to.
Because of this, some mail software put the POP or IMAP account into
an X-sender header field instead of a Sender header field, to indicate
that you may not be able to send e-mail to this address. See also "X-X-Sender".
Another
use of" X-Sender:" is that some e-mail software, which wants to insert
a "Sender:" header, will first change an existing "Sender:" header to
"X-Sender". This use is actually often the same as that described in
the previous paragraph, since the new "Sender:" is added because it
is better authenticated than the old value.
|
X-Sender:
|
Non-standard
|
|
Even
though some systems put the POP or IMAP account name into the "X-Sender:"
instead of the Sender header field, some mail software tries to send
to the "X-Sender:" too. To stop this, some systems have begun to use
"X-X-Sender:" to indicate an authentication of the sender which might
not be useable to send e-mail to. See also "Originator-Info:"
|
X-X-Sender:
|
Non-standard
|
|
When
a message is sent both to netnews and e-mail, this header is used in
the e-mail version of the message to indicate which newsgroup it was
sent to. This header thus contains the same information as the "Newsgroups:"
header in the netnews version of the message.
|
Posted-To:
|
Non-standard
|
|
E-mail
address of administrator of a server, through which this message was
submitted.
|
X-Admin:
|
Non-standard
|
|
Indicates
whether the content of a message is to be returned with non-delivery
notifications.
|
Content-Return:
|
RFC
2156, not for general usage.
|
|
For
future options on disposition notifications.
|
Disposition-Notification-Options:
|
RFC
2298
|
|
Indicate
that the sender wants a dispoisition notification when this message
is received (read, processed, etc.) by its receipents.
|
Disposition-Notification-To:
|
RFC
2298
|
|
Address
to which notifications are to be sent and a request to get delivery
notifications. Internet standards recommend, however, the use of MAIL
FROM and Return-Path, not Errors-To, for where delivery notifications
are to be sent.
|
Errors-To:,
Return-Receipt-To:,
Read-Receipt-To:,
X-Confirm-reading-to:, Return-Receipt-Requested, Register-Mail-Reply-Requested-By:
|
Non-standard,
discouraged, some of them widely used.
|
|
Used
in Usenet News to indicate that future discussions (=follow-up) on an
article should go to a 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 field 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 field does not say anything about where follow-up in e-mail
is to be sent.
The
value of this header field should be one or more newsgroup names.
The
special value "poster" as in "Followup-To: poster" means that replies
are to be sent as e-mail to the author only.
|
Followup-To:
|
RFC
1036: 2.2.3, not standardized for use in e-mail.
|
|
Whether
a delivery report is wanted at successful delivery. Default is not to
generate such a report.
|
Generate-Delivery-Report:
|
RFC
2156, not for general usage.
|
|
Original
Recipient information for inclusion in disposition notifications.
|
Original-Recipient
|
RFC
2298
|
|
Whether
non-delivery report is wanted at delivery error. Default is to want
such a report.
|
Prevent-NonDelivery-Report:
|
RFC
2156, not for general usage.
|
|
This
header field is meant to indicate where the sender wants replies to
go. Unfortunately, this is 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.).
|
Reply-To:
|
RFC
822: 4.4.3,
RFC
1036: 2.2.1
controversial.
|
|
Some
mail systems use this header field 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 field. These practices are controversial.
The personal opinion of the author of this RFC is that this header field
should be avoided except in special cases, but this is a personal opinion
not shared by all specialists in the area.
|
|
|
|
Indicates
where to send complains if you get a message which you think is against
the laws or rules.
|
Abuse-Reports-To:,
X-Complaints-To:, X-Report-Abuse-To:
|
non-standard
|
|
Used
in netnews articles to indicate that followup (=replies) should be sent
to the indicated e-mail address.
|
Mail-Copies-To:
|
non-standard,
but commonly supported by newsreaders
|
|
Possible
future change of name for "Content-Return:"
|
X400-Content-Return:
|
non-standard
|
|
Reference
to specially important articles for a particular Usenet Newsgroup.
|
Article-Names:
|
son-of-RFC1036
[21], non-standard
|
|
Only
in Usenet News, similar to "Supersedes:" but does not cause the referenced
article to be physically deleted.
|
Article-Updates:
|
son-of-RFC1036
[21], non-standard
|
|
Used
in addition to Content-Location if this content part can be retrieved
through more than one URI. Only one of them is allowed in the Content-Location,
the other can be specified in Content-Alias.
|
Content-Alias:
|
Work
in progress
|
|
Base
to be used for resolving relative URIs within this content part.
|
Content-Base:
|
RFC
2110
|
|
Unique
ID of one body part of the content of a message.
|
Content-ID:
|
RFC
2045: 7.
|
|
URI
with which the content of this content part might be retrievable.
|
Content-Location:
|
RFC
2110
|
|
Used
by some automatic services (mainly MLMs and autoresponders) for the
purpose of loop detection. The service adds the Delivered-To header
to outgoing messages, with its e-mail address as a value, and discards
incoming messages which already have it.
|
Delivered-To:
or
X-Loop:
|
non-standard
|
|
Reference
to message which this message is a reply to.
|
In-Reply-To:
|
RFC
822: 4.6.2.
|
|
Unique
ID of this message.
|
Message-ID:
|
RFC
822: 4.6.1
RFC
1036: 2.1.5.
|
|
Reference
to previous message being corrected and replaced. Compare to "Supersedes:"
below. This field may in the future be replaced with "Supersedes:".
|
Obsoletes:
|
RFC
2156, not for general usage.
|
|
In
e-mail: reference to other related messages, in Usenet News: reference
to replied-to-articles.
|
References:
|
RFC
822: 4.6.3
RFC
1036: 2.1.5.
|
|
Still
another name for similar functionality as for "Obsoletes:" and "Supersedes:".
This may become the most recommended header in the future, but is still
under discussion in IETF standards development work.
|
Replaces:
|
non-standard,
proposed in IETF USEFOR working group
|
|
References
to other related articles in Usenet News.
|
See-Also:
|
Son-of-RFC1036
[21], non-standard
|
|
Commonly
used in Usenet News in similar ways to the "Obsoletes" header field
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.
|
Supersedes:
|
son-of-RFC1036
[21], non-standard
|
|
Mailbox
of the person who made the translation.
|
Translated-By:
|
non-standard
|
|
Reference
to the Message-ID of a message, which the current message is a translation
of.
|
Translation-Of:
|
non-standard
|
|
Unique
identifier for a message, local to a particular local mailbox store.
The UIDL identifier is defined in the POP3 standard, but not the "X-UIDL:"
header.
|
X-UIDL:
|
non-standard
|
|
Similar
usage as "X-URL". The URI can be either a URL or a URN. URNs are meant
to become more persistent references to resources than URLs.
|
X-URI:
|
Non-standard
|
|
Sometimes
used with the same meaning as "Content-Location:", sometimes to indicate
the web home page of the sender or of his organisation.
|
X-URL:
|
Non-standard
|
|
The
UID, as defined in the IMAP standard. Only used in internal mailbox
storage in some mail systems, should never be visible to a user.
|
X-IMAP:
|
Non-standard
|
|
Comments
on a message.
|
Comments:
|
RFC
822: 4.7.2.
|
|
Description
of a particular body part of a message, for example a caption for an
image body part.
|
Content-Description:
|
RFC
2045: 8.
|
|
A
text string which identifies the content of a message.
|
Content-Identifier:
|
RFC
2156, not for general usage.
|
|
Search
keys for data base retrieval.
|
Keywords:
|
RFC
822: 4.7.1
RFC
1036: 2.2.9.
|
|
See
Organization above.
|
Organisation:
|
Non-standard.
|
|
Organization
to which the sender of this article belongs.
|
Organization:
|
RFC
1036: 2.2.8, not standardized for use in e-mail.
|
|
Title,
heading, subject. Often used as thread indicator for messages replying
to or commenting on other messages.
|
Subject:
|
RFC
822: 4.7.1
RFC
1036: 2.1.4.
|
|
Short
text describing a longer article. Warning: Some mail systems will not
display this text to the recipient. Because of this, do not use this
header field for text which you want to ensure that the recipient gets.
|
Summary:
|
RFC
1036: 2.2.10, not standardized for use in e-mail, discouraged.
|
|
In
Internet, the date when a message was written, in X.400, the time a
message was submitted. Some Internet mail systems also use the date
when the message was submitted.
|
Date:
|
RFC
822: 5.1,
RFC
1123: 5.2.14
RFC
1036: 2.1.2.
|
|
The
time when a message was delivered to its recipient.
|
Delivery-Date:
|
RFC
2156, not for general usage.
|
|
A
suggested expiration date. Can be used both to limit the time of an
article which is not meaningful after a certain date, and to extend
the storage of important articles.
|
Expires:
|
RFC
1036: 2.2.4, not standardized for use in e-mail.
|
|
Time
at which a message loses its validity. This field may in the future
be replaced by "Expires:".
|
Expiry-Date:
|
RFC
2156, not for general usage.
|
|
Latest
time at which a reply is requested (not demanded).
|
Reply-By:
|
RFC
2156, not for general usage.
|
|
Time
when this message was delivered into the message transport system (usually
the same time as in the last "Received:" header)
|
X-OriginalArrivalTime:
|
Non-standard
|
|
A
hint from the originator to the recipients about how important a message
is. Values: High, normal or low. Not used to control transmission speed.
|
Importance:
|
RFC
2156 and
RFC
2421, proposed
|
|
Body
parts are missing.
|
Incomplete-Copy:
|
RFC
2156, not for general usage.
|
|
Ratings
label to control selection (filtering) of messages according to the
PICS protocol.
|
PICS-Label:
|
REC-PICS-labels,
W3C document [23].
|
|
Sometimes
used as a priority value which can influence transmission speed and
delivery. 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.
|
Precedence:
|
Non-standard,
controversial, widely used.
|
|
Can
be "normal", "urgent" or "non-urgent" and can influence transmission
speed and delivery.
|
Priority:
|
RFC
2156, not for general usage.
|
|
How
sensitive it is to disclose this message to other people than the specified
recipients. Values: Personal, private, company confidential. The absence
of this header field in messages gatewayed from X.400 indicates that
the message is not sensitive.
|
Sensitivity:
|
RFC
2156 and
RFC
2421, proposed
|
|
Yet
another priority indication.
|
X-MSMail-Priority:
|
Non-standard
|
|
Values:
1 (Highest), 2 (High), 3 (Normal), 4 (Low), 5 (Lowest). 3 (Normal) is
default if the field is omitted.
|
X-Priority:
|
Non-standard
[24]
|
|
Can
include a code for the natural language used in a message, e.g. "en"
for English.
|
Content-Language:
|
RFC
1766, proposed standard.
|
|
Can
include a code for the natural language used in a message, e.g. "en"
for English.
|
Language:
|
RFC
2156, not for general usage.
|
|
Inserted
by certain mailers to indicate the size in bytes of the message text.
This is part of a format some mailers use when showing a message to
its users, and this header field should not be used when sending a message
through the net. The use of this header field in transmission of a message
can cause several robustness and interoperability problems.
|
Content-Length:
|
Non-standard,
discouraged.
|
|
Size
of the message.
|
Lines:
|
RFC
1036: 2.2.12, not standardized for use in e-mail.
|
|
Information
on where an alternative variant of this document might be found.
|
Content-Alternative:
|
Non-standard
[27].
|
|
Non-standard
variant of Conversion: with the same values.
|
Content-Conversion:
|
Non-standard.
|
|
The
body of this message may not be converted from one character set to
another. Values: Prohibited and allowed.
|
Conversion:
|
RFC
2156, not for general usage.
|
|
The
body of this message may not be converted from one character set to
another if information will be lost. Values: Prohibited and allowed.
|
Conversion-With-Loss:
|
RFC
2156, not for general usage.
|
|
Type
information of the content in some class hierarchy. Class hierarchies
are commonly used to classify data structures in software development.
|
Content-Class:
|
non-standard
|
|
Can
give more detailed information about the Content-Type. Example:
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
This
header is meant to be used when you can choose between different versions
of a resource, such as when using multipart/atlernative.
|
Content-Features:
|
Proposed
Standard, RFC 2912
|
|
Information
from the SGML entity declaration corresponding to the entity contained
in the body of the body part.
|
Content-SGML-Entity:
|
non-standard
|
|
Coding
method used in a MIME message body.
|
Content-Transfer-Encoding:
|
RFC
2045: 6.
|
|
Format
of content (character set etc.) Note that the values for this header
field are defined in different ways in RFC 1049 and in MIME (RFC 2045),
look for the "MIME-version" header field 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 1049 has "historic"
status.
RFC
1766 defines a parameter "difference" to this header field.
Various
other Content-Type define various additional parameters. For example,
the parameter "charset" is mandatory for all textual Content-Types.
|
Content-Type:
|
RFC
1049,
RFC
1123: 5.2.13,
RFC
1766: 4.1
RFC
2045: 5.
|
|
Used
in several different ways by different mail systems. Some use it for
a kind of content-type information, some for encoding and length information,
some for a kind of boundary information, some in other ways.
|
Encoding:
|
RFC
1154,
RFC
1505,
experimental.
|
|
Only
used with the value "Delivery Report" to indicates that this is a delivery
report gatewayed from X.400.
|
Message-Type:
|
RFC
2156, not for general usage.
|
|
Information
about conversion of this message on the path from sender to recipient,
like conversion between MIME encoding formats. Note: Auto-conversion
may invalidate digital seals and signatures.
|
X-MIME-Autoconverted:
|