|
Network
Working Group
Internet
Draft
draft-palme-mailext-headers-08.txt Category:
Informational
Revision
of: RFC 2076
|
Jacob
Palme
Stockholm
University/KTH
Sweden Expires:
March 2003
|
This document is an Internet-Draft and is in
full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for
a maximum of six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed
at http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories
can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2001. All
Rights Reserved.
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 2822, 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.
URL may be more recent than the version published
as an RFC.
Another list of headers can be found at URL http://www.cs.tut.fi/~jkorpela/headers.html
[28]
Corrected misspelling of "Abouse" should be "Abuse"
and "Register-Mail-Reply-Requested-By" should be "Registered-Mail-Reply-Requested-By".
Added some RFC references. Added some more warnings concerning "Precedence".
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 2822 [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 2822 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 (2002) 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
2822: 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
2822:,
RFC
1123: 5.2.15-16, 5.3.7,
RFC 2156, RFC 2532, RFC 3297. |
|
Secondary,
informational recipients. (cc = Carbon Copy)
|
cc:
|
RFC
2822:,
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
2822:,
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 2822 3.6.2,
RFC
1123: 5.2.15-16, 5.3.7, RFC 1036.
|
|
Primary
recipients.
|
To:
|
RFC
2822:,
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" RFC 2822 header fields, some mail servers add this to
the RFC 2822 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 RFC 2822 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,
Registered-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
2822:,
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.
|
|
|
|
Adress
to which those replies to this message should be sent, which are intended for
all who read the replied-to message, not only for its author.
|
Mail-Followup-To:
|
Non-standard,
see
http://cr.yp.to/proto/replyto.html
|
|
Similar
to "Reply-To:" but more unambiguosly specifies that this is the address for
rpelies to the author only, not to any other recipients of the replied-to
message.
|
Mail-Reply-To:
|
Non-standard,
see
http://cr.yp.to/proto/replyto.html
|
|
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.
Note:
It is better to use References instead of In-Reply-To, because many mailers
produce a multitude of difficult to interpret content of the In-Reply-To header.
|
In-Reply-To:
|
RFC
2822
|
|
Unique
ID of this message.
|
Message-ID:
|
RFC
2822,
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.
|
|
The
"References:" field will contain the contents of the parent's "References:"
field (if any) followed by the contents of the parent's "Message-ID:" field (if
any).
Note:
In RFC 822, this header indicated other messages, which the current message
relates to. But in RFC 2822 this was changed. In Usenet News, the header has
always has the new usage.
|
References:
|
RFC
2822,
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
2822
|
|
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
2822
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
2822,
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
2822,
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 (a) priority value which can influence transmission speed and
delivery. Common values are "bulk" and "first-class". Other uses is to (b)
control automatic replies like delivery status reports and vacation notices and
to (c) control return-of-content facilities, and to (d) stop mailing list
loops, (e)
|
Precedence:
|
Non-standard,
controversial, widely used. Because it is used for so many different purposes,
there is a risk that creator and user of this header mean different things.
|
|
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. Will be deprecated in the
future.
|
|
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:
|
Proposed
Standard, RFC 2912
|
|
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.
|
||
|
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:
|
non-standard
|
|
When
manually forwarding a message, header fields referring to the forwarding, not
to the original message. Note: MIME specifies another way of resending
messages, using the "Message" Content-Type.
|
Resent-Reply-To:,
Resent-From:,
Resent-Sender:, Resent-Date:, Resent-To:, Resent-cc:, Resent-bcc:,
Resent-Message-ID:
|
RFC
2822
|
|
Checksum
of content to ensure that it has not been modified.
|
Content-MD5:
|
RFC
1864, proposed standard.
|
|
Used
in Usenet News to store information to avoid showing a reader the same article
twice if it was sent to more than one newsgroup. Only for local usage within
one Usenet News server, should not be sent between servers.
|
Xref:
|
RFC
1036: 2.2.13, only in Usenet News, not in e-mail.
|
|
Used
in Usenet News to stop rough cancels. Crypthographic methods are used to ensure
that only the original author of an article can cancel it.
|
Cancel-Lock:,
Cancel-Key |
Non-standard
|
|
Contains
URL to use to browse the archives of the mailing list from which this message
was relayed.
|
List-Archive:
|
RFC
2369 [26]
|
|
URL
to use to get a subscription to the digest version of the mailing list from
which this message was relayed.
|
List-Digest:
|
Non-standard
|
|
Contains
URL to use to get a information about the mailing list from which this message
was relayed.
|
List-Help:
|
RFC
2369 [26]
|
|
Stores
an identification of the mailing list, through which this message was
distributed.
|
List-ID:
|
RFC
2919 [27].
|
|
Non-standard
precursors to List-ID and List-Post.
|
Mailing-List:,
X-Mailing-List:
|
Non-standard
|
|
Contains
URL to send e-mail to the owner of the mailing list from which this message was
relayed.
|
List-Owner:
|
RFC
2369 [26]
|
|
Contains
URL to use to send contributions to the mailing list from which this message
was relayed.
|
List-Post:
|
RFC
2369 [26]
|
|
Information
about the software used in a mailing list expander through which this message
has passed.
|
List-Software:
|
Non-standard,
has been considered for inclusion in [26].
|
|
Contains
URL to use to get a subscription to the mailing list from which this message
was relayed.
|
List-Subscribe:
|
RFC
2369 [26]
|
|
Contains
URL to use to unsubscribe the mailing list from which this message was relayed.
|
List-Unsubscribe:
|
RFC
2369 [26]
|
|
Contains
URL where information of various kinds about the mailing list from which this
message was relayed.
|
List-URL:
|
Non-standard
|
|
Information
about the server and software used in a mailing list expander through which
this message has passed. Warning: "Listserv" is a trademark and should not be
used for other than the "Listserv" product. Use, instead the "List-Software"
header field.
|
X-Listserver:,
X-List-Host:
|
Non-standard.
Recommended to use "List-Software" instead.
|
|
Has
been automatically forwarded.
|
Autoforwarded:
|
RFC
2156, not for general usage.
|
|
Can
be used in Internet mail to indicate X.400 IPM extensions which could not be
mapped to Internet mail format.
|
Discarded-X400-IPMS-Extensions:
|
RFC
2156, not for general usage.
|
|
Can
be used in Internet mail to indicate X.400 MTS extensions which could not be
mapped to Internet mail format.
|
Discarded-X400-MTS-Extensions:
|
RFC
2156, not for general usage.
|
|
Name
of file in which a copy of this message is stored.
|
Fcc:
|
Non-standard.
|
|
Speech
act categoriztion of a message, examples of speeach acts are Question, Idea,
More, Promise, Sad, Happy, Angry, summary, Decision
|
Speech-Act:
|
Non-standard
|
|
This
field is used by some mail delivery systems to indicate the status of delivery
for this message when stored. Common 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
field.
Combinations
of these characters can occur, such as "Status: OR" to indicate that a message
is downloaded but not deleted.
|
Status:
|
Non-standard,
should never appear in mail in transit.
|
|
Do
not archive this message in publicly available archives.
|
X-No-Archive:
Yes
|
Non-standard
|
Harald Tveit Alvestrand, Neil Carpenter, William
C. Carpenter, Rob Chandhok, Ned Freed, Olle Järnefors, Jukka Korpela,
Usi Paz, Martin Platt, Keith Moore, Maxim Masiutin, Robert A. Rosenberg, Mark
Symons, Nick Smith Michael C. Tiernan and several other people have helped
me with compiling this list. I especially thank Ned Freed and Olle Järnefors
for their thorough review and many helpful suggestions for improvements. I
alone take responsibility for any errors which may still be in the list.
An earlier version of this list has been published
as part of [13].
The IETF takes no position
regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's procedures
with respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained from
the IETF Secretariat."
The IETF invites any interested
party to bring to its attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology that may be required
to practice this standard. Please address the information to the IETF Executive
Director.
Copyright (C) The Internet
Society (date). All Rights Reserved.
This document and translations
of it may be copied and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implmentation may be prepared,
copied, published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, except
as needed for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than English.
The limited permissions
granted above are perpetual and will not be revoked by the Internet Society
or its successors or assigns.
|
Ref.
|
Author, title
|
IETF
status (July 2002)
|
|
[1]
|
J.
Klensin: "Simple Mail Transfer Protocol", RFC 2821, April 2001.
|
Proposed
Standard
|
|
[2]
|
P.
Resnick: "Internet Message Format" STD 11, RFC 2822, April 2001.
|
Proposed
Standard
|
|
[3]
|
M.R.
Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036,
December 1987.
|
Not
an offi-cial IETF standard, but in reality a de-facto standard for Usenet News
|
|
[4]
|
M.
Sirbu: "A Content-Type header field header field for internet messages", RFC
1049, March 1988.
|
Historic
|
|
[5]
|
R.
Braden (editor): "Requirements for Internet Hosts
Application and Support", STD-3, RFC 1123, October 1989. |
Standard,
Required
|
|
[6]
|
D.
Robinson, R. Ullman: "Encoding Header field for Internet Messages", RFC 1505,
August 1993.
|
Non-standard
|
|
[7]
|
S.
Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 2822", RFC
2156 January 1998.
|
Proposed
standard, elective
|
|
[8]
|
H.
Alvestrand & J. Romaguera: "Rules for Downgrading Messages from X.400/88 to
X.400/84 When MIME Content-Types are Present in the Messages", RFC 1496, August
1993.
|
Proposed
standard, elective
|
|
[9]
|
A.
Costanzo: "Encoding Header field Header field for Internet Messages", RFC 1154,
April 1990.
|
Non-standard
|
|
[10]
|
A.
Costanzo, D. Robinson: "Encoding Header field Header field for Internet
Messages", RFC 1505, August 1993.
|
Experimental
|
|
[11]
|
N.
Freed & N. Borenstein: "MIME (Multipurpose Internet Mail Extensions) Part
One: Format of Internet Message Bodies. RFC 2045. November 1996.
|
Draft
Standard, elective
|
|
[12]
|
H.
Alvestrand: "Tags for the Identification of Languages", RFC 3066, January 2001.
|
Best
Current Practice, elective
|
|
[13]
|
J.
Palme: "Electronic Mail", Artech House publishers, London-Boston January 1995.
|
Non-standard
|
|
[14]
|
R.
Troost, S. Dorner: "Communicating Presentation Information in Internet
Messages: The Content-Disposition Header field", RFC 2183, June 1995.
|
Experimental
|
|
[15]
|
B.
Kantor, P. Lapsley, "Network News Transfer Protocol: "A Proposed Standard for
the Stream-Based Transmission of News", RFC 977, January 1986.
|
Proposed
standard
|
|
[16]
|
1848
PS S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
Services", RFC 1848, March 1995.
|
Proposed
standard
|
|
[17]
|
J.
Myers, M. Rose: The Content-MD5 Header field Header field, RFC 1864, October
1995.
|
Draft
standard
|
|
[18]
|
M.
Horton, UUCP mail interchange format standard, RFC 976, Januari 1986.
|
Not
an offi-cial IETF standard, but in reality a de-facto standard for Usenet News
|
|
[19]
|
R.
Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee: Hypertext Transfer Protocol
HTTP/1.1, June 1999. |
Draft
standard
|
|
[20]
|
G.
Vaudreuil: Voice Profile for Internet Mail, RFC 2421 Feburary 1998.
|
Proposed
|
|
[21]
|
H.
Spencer: News Article Format and Transmission, June 1994,
FTP://zoo.toronto.edu/pub/news.ps.Z FTP://zoo.toronto.edu/pub/news.txt.Z This
document is often referenced under the name "son-of-RFC1036".
|
Not
even an RFC, but still widely used and partly almost a de-facto standard for
Usenet News
|
|
[23]
|
PICS
Label Distribution Label Syntax and Communication Protocols, World Wide Web
Consortium, October 1996.
|
Other
standard
|
|
[24]
|
Eudora
Pro Macintosh User Manual, Qualcomm Inc., 1988-1995.
|
Non-standard
|
|
[25]
|
C.
Newman: Originator-Info Message Header field. work in progress, July 1997.
|
Non-standard
|
|
[26]
|
Grant
Neufeld and Joshua D. Baer: The Use of URLs as Meta-Syntax for Core Mail List
Commands and their Transport through Message Header fields, RFC 2369, July 1998.
|
Proposed
standard
|
|
[27]
|
G.
Klyne (ed.): Content Negotiation for Facsimile Using Internet Mail, Work in
progress, March 2000.
|
Non-standard
|
|
[27]
|
R.
Chandhok, G. Wenger: List-IDE: A Structured Field and Namespace for the
Identification if Mailing Lists, RFC 2919, March 2001.
|
Proposed
standard
|
|
[28]
|
Jukka
"Yucca" Korpela: Quick reference to Internet message headers,
http://www.cs.tut.fi/~jkorpela/headers.html, October 2001.
|
Non-standard
|
|
Jacob
Palme
Stockholm
University/KTH
Forum
100
S-164
40 Kista, Sweden
|
Phone:
+46-8-16 16 67
Fax:
+46-8-783 08 29
E-mail:
jpalme@dsv.su.se
|
|
Section |
Header
field
|
|
3.5
|
Abuse-Reports-To
|
|
3.3
|
Also-Control
|
|
3.3
|
Alternate-Recipient
|
|
3.4
|
Apparently-To
|
|
3.4
|
Approved
|
|
3.4
|
Approved-By
|
|
3.6
|
Article-Names
|
|
3.6
|
Article-Updates
|
|
|
Auto-Forwarded
see Autoforwarded
|
|
3.17
|
Autoforwarded
|
|
3.4
|
bcc
|
|
3.15
|
Cancel-Lock
|
|
3.4
|
cc
|
|
|
Client,
see Originating-Client
|
|
|
Comment,
see For-Comment
|
|
3.7
|
Comments
|
|
3.6
|
Content-Alias
|
|
3.12
|
Content-Alternative
|
|
3.6
|
Content-Base
|
|
3.13
|
Content-Class
|
|
3.12
|
Content-Conversion
|
|
3.7
|
Content-Description
|
|
3.3
|
Content-Disposition
|
|
3.13
|
Content-Features
|
|
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
|
|
|
Copy,
see Incomplete-Copy
|
|
3.8
|
Date,
see also Delivery-Date, Received, Expires, Expiry-Date
|
|
3.6
|
Delivered-To
|
|
3.8
|
Delivery-Date
|
|
|
Delivery-Report,
see Generate-Delivery-Report, Prevent-Delivery-Report, Non-Delivery-Report,
Content-Type
|
|
|
Description,
see Content-Description
|
|
3.17
|
Discarded-X400-IPMS-Extensions
|
|
3.17
|
Discarded-X400-MTS-Extensions
|
|
3.3
|
Disclose-Recipients
|
|
|
Disposition,
see also Content-Disposition
|
|
3.5
|
Disposition-Notification-Options
|
|
3.5
|
Disposition-Notification-To
|
|
3.4
|
Distribution
|
|
3.2
|
DL-Expansion-History
|
|
3.13
|
Encoding
see also Content-Transfer-Encoding
|
|
3.4
|
Errors-To
|
|
3.8
|
Expires
|
|
3.8
|
Expiry-Date
|
|
|
Extension
see Discarded-X400-IPMS-Extensions, Discarded-X400-MTS-Extensions
|
|
3.4
|
Fax
see also Telefax
|
|
3.17
|
Fcc
|
|
3.4
|
Followup-To
|
|
3.4
|
For-Approval
|
|
3.4
|
For-Comment
|
|
3.4
|
For-Handling
|
|
|
Forwarded,
see Autoforwarded
|
|
3.4
|
From
(not followed by (":" or preceded by ">")
|
|
3.4
|
From
(followed by ":")
|
|
3.4
|
Generate-Delivery-Report
|
|
|
Handling,
see For-Handling
|
|
|
History,
see DL-Expansion-History
|
|
|
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
|
|
|
Label,
see PICS-Label
|
|
3.10
|
Language
see also Content-Language
|
|
|
Length
see Content-Length
|
|
3.11
|
Lines
|
|
3.16
|
List-Archive
|
|
3.16
|
List-Digest
|
|
3.16
|
List-Help
|
|
3.16
|
List-ID
|
|
3.16
|
List-Owner
|
|
3.16
|
List-Post
|
|
3.16
|
List-Software
|
|
3.16
|
List-Subscribe
|
|
3.16
|
List-URL
|
|
3.16
|
List-Unsubscribe
|
|
|
Loss,
see Conversion-With-Loss
|
|
3.16
|
Mailing-List,
see also X-Mailing-List
|
|
3.5
|
Mail-Copies-To
|
|
3.6
|
Mail-Followup-To
|
|
3.6
|
Mail-Reply-To
|
|
3.4
|
Mail-System-Version
see also X-mailer
|
|
3.4
|
Mailer
|
|
|
MD5
see Content-MD5
|
|
3.3
|
Message-Context
|
|
3.6
|
Message-ID
|
|
3.13
|
Message-Type
|
|
3.3
|
MIME-Version
|
|
3.4
|
Newsgroups
|
|
|
Newsreader,
see X-Newsreader
|
|
3.3
|
NNTP-Posting-Host
|
|
3.6
|
Obsoletes
|
|
3.7
|
Organisation
|
|
3.7
|
Organization
|
|
3.3
|
Original-Encoded-Information-Types
|
|
3.6
|
Original-Recipient
|
|
3.4
|
Originating-Client
|
|
3.4
|
Originator
|
|
3.4
|
Originator-Info
see also Sender
|
|
3.2
|
Path
|
|
3.4
|
Phone
|
|
3.9
|
PICS-Label
|
|
3.4
|
Posted-To
|
|
3.9
|
Precedence
|
|
3.4
|
Prevent-NonDelivery-Report
|
|
3.9
|
Priority
|
|
3.5
|
Read-Reciept-To
|
|
3.2
|
Received
|
|
|
Recipient,
see To, cc, bcc, Alternate-Recipient, Disclose-Recipients
|
|
3.6
|
References
|
|
3.5
|
Registered-Mail-Reply-Requested-By
|
|
3.6
|
Replaces
|
|
3.8
|
Reply-By
|
|
3.4
|
Reply-To,
see also In-Reply-To, References
|
|
3.14
|
Resent-Reply-To:
|
|
3.14
|
Resent-From:
|
|
3.14
|
Resent-Sender:
|
|
3.14
|
Resent-Date:
|
|
3.14
|
Resent-To:
|
|
3.14
|
Resent-Cc:
|
|
3.14
|
Resent-bcc:
|
|
3.14
|
Resent-Message-ID:
|
|
3.14
|
Return
see Content-Return
|
|
3.2
|
Return-Path
|
|
3.5
|
Return-Receipt-Requested
|
|
3.5
|
Return-Receipt-To
|
|
3.6
|
See-Also
|
|
3.4
|
Sender
|
|
3.9
|
Sensitivity
|
|
3.17
|
Speech-Act
|
|
3.17
|
Status
|
|
3.7
|
Subject
|
|
3.7
|
Summary
|
|
3.6
|
Supersedes
|
|
3.4
|
Telefax
see also Fax
|
|
3.4
|
To
|
|
|
Transfer-Encoding
see Content-Transfer-Encoding
|
|
3.6
|
Translated-By
|
|
3.6
|
Translation-Of
|
|
|
Type
see Content-Type, Message-Type, Original-Encoded-Information-Types
|
|
3.4
|
User-Agent
|
|
|
Version,
see MIME-Version, X-Mailer
|
|
3.4
|
X-Admin
|
|
3.4
|
X-Complaints-To
|
|
3.5
|
X-Confirm-Reading-To
|
|
3.4
|
X-Envelope-From
|
|
3.4
|
X-Envelope-To
|
|
3.4
|
X-Face
|
|
3.6
|
X-IMAP
|
|
3.16
|
X-List-Host
|
|
3.16
|
X-Listserver
|
|
3.6
|
X-Loop
|
|
3.16
|
X-Mailing-List,
see also Mailing-List
|
|
3.4
|
X-Mailer
see also Mail-System-Version
|
|
3.13
|
X-MIME-Autoconverted
|
|
3.4
|
X-MimeOLE
|
|
3.9
|
X-MSMail-Priority
|
|
3.4
|
X-Newsreader
|
|
3.17
|
X-No-Archive
|
|
3.8
|
X-OriginalArrivaltime
|
|
3.9
|
X-Priority
|
|
3.4
|
X-Report-Abuse-To
|
|
3.4
|
X-RCPT-TO
|
|
3.4
|
X-Sender
see also Originator-Info
|
|
3.6
|
X-UIDL
|
|
3.6
|
X-URI
|
|
3.6
|
X-URL
see also Content-Location
|
|
3.4
|
X-X-Sender
see also Originator-Info
|
|
3.4
|
X400-Content-Return
|
|
3.15
|
Xref
|