RFC 4021 PROPOSED STANDARD EMAIL · IANA · REGISTRY
Registration of Mail and MIME Header Fields
The first official IANA list of permanent mail and MIME header fields, from Date and Subject to Content-Type.
RFC EDITOR
Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, DOI 10.17487/RFC4021, March 2005, <https://www.rfc-editor.org/info/rfc4021>.
BIBTEX
@misc{rfc4021,
series = {Request for Comments},
number = 4021,
howpublished = {RFC 4021},
publisher = {RFC Editor},
doi = {10.17487/RFC4021},
url = {https://www.rfc-editor.org/info/rfc4021},
author = {G. Klyne and J. Palme},
title = {{Registration of Mail and MIME Header Fields}},
pagetotal = 54,
year = 2005,
month = mar,
} RFC text
Contents
Network Working Group G. Klyne
Request for Comments: 4021 University of Oxford
Category: Standards Track J. Palme
Stockholm University/KT
March 2005
Registration of Mail and MIME Header Fields
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the initial IANA registration for permanent
mail and MIME message header fields, per RFC 3864.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Structure of This Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Registration Templates . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent Mail Header Field Registrations . . . . . . . 4
2.1.1. Header Field: Date . . . . . . . . . . . . . . . 6
2.1.2. Header Field: From . . . . . . . . . . . . . . . 7
2.1.3. Header Field: Sender . . . . . . . . . . . . . . 7
2.1.4. Header Field: Reply-To . . . . . . . . . . . . . 8
2.1.5. Header Field: To . . . . . . . . . . . . . . . . 8
2.1.6. Header Field: Cc . . . . . . . . . . . . . . . . 9
2.1.7. Header Field: Bcc . . . . . . . . . . . . . . . 9
2.1.8. Header Field: Message-ID . . . . . . . . . . . . 10
2.1.9. Header Field: In-Reply-To . . . . . . . . . . . 10
2.1.10. Header Field: References . . . . . . . . . . . . 11
2.1.11. Header Field: Subject . . . . . . . . . . . . . 11
2.1.12. Header Field: Comments . . . . . . . . . . . . . 12
2.1.13. Header Field: Keywords . . . . . . . . . . . . . 12
2.1.14. Header Field: Resent-Date . . . . . . . . . . . 13
2.1.15. Header Field: Resent-From . . . . . . . . . . . 13
2.1.16. Header Field: Resent-Sender . . . . . . . . . . 14
2.1.17. Header Field: Resent-To . . . . . . . . . . . . 14
2.1.18. Header Field: Resent-Cc . . . . . . . . . . . . 15
2.1.19. Header Field: Resent-Bcc . . . . . . . . . . . . 15
2.1.20. Header Field: Resent-Reply-To . . . . . . . . . 16
2.1.21. Header Field: Resent-Message-ID . . . . . . . . 16
2.1.22. Header Field: Return-Path . . . . . . . . . . . 17
2.1.23. Header Field: Received . . . . . . . . . . . . . 17
2.1.24. Header Field: Encrypted . . . . . . . . . . . . 18
2.1.25. Header Field: Disposition-Notification-To . . . 18
2.1.26. Header Field: Disposition-Notification-Options . 19
2.1.27. Header Field: Accept-Language . . . . . . . . . 19
2.1.28. Header Field: Original-Message-ID . . . . . . . 20
2.1.29. Header Field: PICS-Label . . . . . . . . . . . . 20
2.1.30. Header Field: Encoding . . . . . . . . . . . . . 21
2.1.31. Header Field: List-Archive . . . . . . . . . . . 21
2.1.32. Header Field: List-Help . . . . . . . . . . . . 22
2.1.33. Header Field: List-ID . . . . . . . . . . . . . 22
2.1.34. Header Field: List-Owner . . . . . . . . . . . . 23
2.1.35. Header Field: List-Post . . . . . . . . . . . . 23
2.1.36. Header Field: List-Subscribe . . . . . . . . . . 24
2.1.37. Header Field: List-Unsubscribe . . . . . . . . . 24
2.1.38. Header Field: Message-Context . . . . . . . . . 25
2.1.39. Header Field: DL-Expansion-History . . . . . . . 25
2.1.40. Header Field: Alternate-Recipient . . . . . . . 26
2.1.41. Header Field: Original-Encoded-Information-Types 26
2.1.42. Header Field: Content-Return . . . . . . . . . . 27
2.1.43. Header Field: Generate-Delivery-Report . . . . . 27
2.1.44. Header Field: Prevent-NonDelivery-Report . . . . 28
2.1.45. Header Field: Obsoletes . . . . . . . . . . . . 28
2.1.46. Header Field: Supersedes . . . . . . . . . . . . 29
2.1.47. Header Field: Content-Identifier . . . . . . . . 29
2.1.48. Header Field: Delivery-Date . . . . . . . . . . 30
2.1.49. Header Field: Expiry-Date . . . . . . . . . . . 30
2.1.50. Header Field: Expires . . . . . . . . . . . . . 31
2.1.51. Header Field: Reply-By . . . . . . . . . . . . . 31
2.1.52. Header Field: Importance . . . . . . . . . . . . 32
2.1.53. Header Field: Incomplete-Copy . . . . . . . . . 32
2.1.54. Header Field: Priority . . . . . . . . . . . . . 33
2.1.55. Header Field: Sensitivity . . . . . . . . . . . 33
2.1.56. Header Field: Language . . . . . . . . . . . . . 34
2.1.57. Header Field: Conversion . . . . . . . . . . . . 34
2.1.58. Header Field: Conversion-With-Loss . . . . . . . 35
2.1.59. Header Field: Message-Type . . . . . . . . . . . 35
2.1.60. Header Field: Autosubmitted . . . . . . . . . . 36
2.1.61. Header Field: Autoforwarded . . . . . . . . . . 36
2.1.62. Header Field: Discarded-X400-IPMS-Extensions . . 37
2.1.63. Header Field: Discarded-X400-MTS-Extensions . . 37
2.1.64. Header Field: Disclose-Recipients . . . . . . . 38
2.1.65. Header Field: Deferred-Delivery . . . . . . . . 38
2.1.66. Header Field: Latest-Delivery-Time . . . . . . . 39
2.1.67. Header Field: Originator-Return-Address . . . . 39
2.1.68. Header Field: X400-Content-Identifier . . . . . 40
2.1.69. Header Field: X400-Content-Return . . . . . . . 40
2.1.70. Header Field: X400-Content-Type . . . . . . . . 41
2.1.71. Header Field: X400-MTS-Identifier . . . . . . . 41
2.1.72. Header Field: X400-Originator . . . . . . . . . 42
2.1.73. Header Field: X400-Received . . . . . . . . . . 42
2.1.74. Header Field: X400-Recipients . . . . . . . . . 43
2.1.75. Header Field: X400-Trace . . . . . . . . . . . . 43
2.2. Permanent MIME Header Field Registrations . . . . . . . 44
2.2.1. Header Field: MIME-Version . . . . . . . . . . . 44
2.2.2. Header Field: Content-ID . . . . . . . . . . . . 45
2.2.3. Header Field: Content-Description . . . . . . . 45
2.2.4. Header Field: Content-Transfer-Encoding . . . . 46
2.2.5. Header Field: Content-Type . . . . . . . . . . . 46
2.2.6. Header Field: Content-Base . . . . . . . . . . . 47
2.2.7. Header Field: Content-Location . . . . . . . . . 47
2.2.8. Header Field: Content-features . . . . . . . . . 48
2.2.9. Header Field: Content-Disposition . . . . . . . 48
2.2.10. Header Field: Content-Language . . . . . . . . . 49
2.2.11. Header Field: Content-Alternative . . . . . . . 49
2.2.12. Header Field: Content-MD5 . . . . . . . . . . . 50
2.2.13. Header Field: Content-Duration . . . . . . . . . 50
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
4. Security Considerations . . . . . . . . . . . . . . . . . . . 51
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1. Normative References . . . . . . . . . . . . . . . . . . 51
6.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
This document defines IANA registration for a number of mail message
and MIME header fields, per registration procedures for message
header fields [1].
The main body of this document is automatically generated from RDF/N3
data. Some experimental HTML registry pages have been prepared from
the same data and can be found at [27].
1.1. Structure of This Document
Section 2.1 contains the templates for initial registration of mail
message header fields.
Section 2.2 contains templates for initial registration of MIME
header fields.
1.2. Document Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [9].
2. Registration Templates
Header field registry entries are summarized in tabular form for
convenience of reference and presented in full in the following
sections.
2.1. Permanent Mail Header Field Registrations
Header name Protocol
----------- --------
Date Mail Message date and time
From Mail Mailbox of message author
Sender Mail Mailbox of message sender
Reply-To Mail Mailbox for replies to message
To Mail Primary recipient mailbox
Cc Mail Carbon-copy recipient mailbox
Bcc Mail Blind-carbon-copy recipient
mailbox
Message-ID Mail Message identifier
In-Reply-To Mail Identify replied-to message(s)
References Mail Related message identifier(s)
Subject Mail Topic of message
Comments Mail Additional comments about the
message
Keywords Mail Message key words and/or phrases
Resent-Date Mail Date and time message is resent
Resent-From Mail Mailbox of person for whom message
is resent
Resent-Sender Mail Mailbox of person who actually
resends the message
Resent-To Mail Mailbox to which message is resent
Resent-Cc Mail Mailbox(es) to which message is
cc'ed on resend
Resent-Bcc Mail Mailbox(es) to which message is
bcc'ed on resend
Resent-Reply-To Mail Resent reply-to
Resent-Message-ID Mail Message identifier for resent
message
Return-Path Mail Message return path
Received Mail Mail transfer trace information
Encrypted Mail Message encryption information
Disposition-Notification-To
Mail Mailbox for sending disposition
notification
Disposition-Notification-Options
Mail Disposition notification options
Accept-Language Mail Language(s) for auto-responses
Original-Message-ID Mail Original message identifier
PICS-Label Mail PICS rating label
Encoding Mail Message encoding and other
information
List-Archive Mail URL of mailing list archive
List-Help Mail URL for mailing list information
List-ID Mail Mailing list identifier
List-Owner Mail URL for mailing list owner's
mailbox
List-Post Mail URL for mailing list posting
List-Subscribe Mail URL for mailing list subscription
List-Unsubscribe Mail URL for mailing list
unsubscription
Message-Context Mail Type or context of message
DL-Expansion-History
Mail Trace of distribution lists passed
Alternate-Recipient Mail Controls forwarding to alternate
recipients
Original-Encoded-Information-Types
Mail Body part types in message
Content-Return Mail Return content on non-delivery?
Generate-Delivery-Report
Mail Request delivery report generation
Prevent-NonDelivery-Report
Mail Non-delivery report required?
Obsoletes Mail Reference message to be replaced
Supersedes Mail Reference message to be replaced
Content-Identifier Mail Message content identifier
Delivery-Date Mail Message delivery time
Expiry-Date Mail Message expiry time
Expires Mail Message expiry time
Reply-By Mail Time by which a reply is requested
Importance Mail Message importance
Incomplete-Copy Mail Body parts are missing
Priority Mail Message priority
Sensitivity Mail Message content sensitivity
Language Mail X.400 message content language
Conversion Mail Conversion allowed?
Conversion-With-Loss
Mail Lossy conversion allowed?
Message-Type Mail Message type: delivery report?
Autosubmitted Mail Automatically submitted indicator
Autoforwarded Mail Automatically forwarded indicator
Discarded-X400-IPMS-Extensions
Mail X.400 IPM extensions discarded
Discarded-X400-MTS-Extensions
Mail X.400 MTS extensions discarded
Disclose-Recipients Mail Disclose names of other
recipients?
Deferred-Delivery Mail Deferred delivery information
Latest-Delivery-Time
Mail Latest delivery time requested
Originator-Return-Address
Mail Originator return address
X400-Content-Identifier
Mail Message content identifier
X400-Content-Return Mail Return content on non-delivery?
X400-Content-Type Mail X400 content type
X400-MTS-Identifier Mail X400 MTS-Identifier
X400-Originator Mail X400 Originator
X400-Received Mail X400 Received
X400-Recipients Mail X400 Recipients
X400-Trace Mail X400 Trace
2.1.1. Header Field: Date
Description:
Message date and time
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.1)
Related information:
Specifies the date and time at which the creator of the message
indicated that the message was complete and ready to enter the
mail delivery system. Defined as standard by RFC 822.
2.1.2. Header Field: From
Description:
Mailbox of message author
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.2)
Related information:
Specifies the author(s) of the message; that is, the mailbox(es)
of the person(s) or system(s) responsible for the writing of the
message. Defined as standard by RFC 822.
2.1.3. Header Field: Sender
Description:
Mailbox of message sender
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.2)
Related information:
Specifies the mailbox of the agent responsible for the actual
transmission of the message. Defined as standard by RFC 822.
2.1.4. Header Field: Reply-To
Description:
Mailbox for replies to message
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org) Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.2)
Related information:
When the "Reply-To:" field is present, it indicates the
mailbox(es) to which the author of the message suggests that
replies be sent. Defined as standard by RFC 822.
2.1.5. Header Field: To
Description:
Primary recipient mailbox
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.3)
Related information:
Contains the address(es) of the primary recipient(s) of the
message. Defined as standard by RFC 822.
2.1.6. Header Field: Cc
Description:
Carbon-copy recipient mailbox
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.3)
Related information:
Contains the addresses of others who are to receive the message,
though the content of the message may not be directed at them.
Defined as standard by RFC 822.
2.1.7. Header Field: Bcc
Description:
Blind-carbon-copy recipient mailbox
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.3)
Related information:
Contains addresses of recipients of the message whose addresses
are not to be revealed to other recipients of the message.
Defined as standard by RFC 822.
2.1.8. Header Field: Message-ID
Description:
Message identifier
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.4)
Related information:
Contains a single unique message identifier that refers to a
particular version of a particular message. If the message is
resent without changes, the original Message-ID is retained.
Defined as standard by RFC 822.
2.1.9. Header Field: In-Reply-To
Description:
Identify replied-to message(s)
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.4)
Related information:
The message identifier(s) of the original message(s) to which the
current message is a reply. Defined as standard by RFC 822.
2.1.10. Header Field: References
Description:
Related message identifier(s)
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.4)
Related information:
The message identifier(s) of other message(s) to which the current
message may be related. In RFC 2822, the definition was changed
to say that this header field contains a list of all Message-IDs
of messages in the preceding reply chain. Defined as standard by
RFC 822.
2.1.11. Header Field: Subject
Description:
Topic of message
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.5)
Related information:
Contains a short string identifying the topic of the message.
Defined as standard by RFC 822.
2.1.12. Header Field: Comments
Description:
Additional comments about the message
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.5)
Related information:
Contains any additional comments on the text of the body of the
message. Warning: Some mailers will not show this field to
recipients. Defined as standard by RFC 822.
2.1.13. Header Field: Keywords
Description:
Message key words and/or phrases
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.5)
Related information:
Contains a comma-separated list of important words and phrases
that might be useful for the recipient. Defined as standard by
RFC 822.
2.1.14. Header Field: Resent-Date
Description:
Date and time message is resent
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the date and time that a message is reintroduced into the
message transfer system. Defined as standard by RFC 822.
2.1.15. Header Field: Resent-From
Description:
Mailbox of person for whom message is resent
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the mailbox of the agent who has reintroduced the message
into the message transfer system, or on whose behalf the message
has been resent. Defined as standard by RFC 822.
2.1.16. Header Field: Resent-Sender
Description:
Mailbox of person who actually resends the message
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the mailbox of the agent who has reintroduced the message
into the message transfer system, if this is different from the
Resent-From value. Defined as standard by RFC 822.
2.1.17. Header Field: Resent-To
Description:
Mailbox to which message is resent
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the mailbox(es) to which the message has been resent.
Defined as standard by RFC 822.
2.1.18. Header Field: Resent-Cc
Description:
Mailbox(es) to which message is cc'ed on resend
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the mailbox(es) to which message is cc'ed on resend.
Defined as standard by RFC 822.
2.1.19. Header Field: Resent-Bcc
Description:
Mailbox(es) to which message is bcc'ed on resend
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains the mailbox(es) to which message is bcc'ed on resend.
Defined as standard by RFC 822.
2.1.20. Header Field: Resent-Reply-To
Description:
Resent reply-to
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18]
Related information:
Resent Reply-to. Defined by RFC 822, obsoleted by RFC 2822.
2.1.21. Header Field: Resent-Message-ID
Description:
Message identifier for resent message
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.6)
Related information:
Contains a message identifier for a resent message. Defined as
standard by RFC 822.
2.1.22. Header Field: Return-Path
Description:
Message return path
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.7)
Related information:
Return path for message response diagnostics. See also RFC 2821
[17]. Defined as standard by RFC 822.
2.1.23. Header Field: Received
Description:
Mail transfer trace information
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2822 [18] (section 3.6.7)
Related information:
Contains information about receipt of the current message by a
mail transfer agent on the transfer path. See also RFC 2821 [17].
Defined as standard by RFC 822.
2.1.24. Header Field: Encrypted
Description:
Message encryption information
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 822 [2]
Related information:
Defined by RFC 822, but was found to be inadequately specified,
was not widely implemented, and was removed in RFC 2822. Current
practice is to use separate encryption, such as S/MIME or OpenPGP,
possibly in conjunction with RFC 1847 MIME security multiparts.
2.1.25. Header Field: Disposition-Notification-To
Description:
Mailbox for sending disposition notification
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2298 [12]
Related information:
Indicates that the sender wants a disposition notification when
this message is received (read, processed, etc.) by its
recipients.
2.1.26. Header Field: Disposition-Notification-Options
Description:
Disposition notification options
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2298 [12]
Related information:
For optional modifiers on disposition notification requests.
2.1.27. Header Field: Accept-Language
Description:
Language(s) for auto-responses
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 3282 [21]
Related information:
Indicates a language that the message sender requests to be used
for responses. Accept-language was not designed for email but has
been considered useful as input to the generation of automatic
replies. Some problems have been noted concerning its use with
email, including but not limited to determination of the email
address to which it refers; cost and lack of effective
internationalization of email responses; interpretation of
language subtags; and determining what character set encoding
should be used.
2.1.28. Header Field: Original-Message-ID
Description:
Original message identifier
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 3297 [22]
Related information:
Original message identifier used with resend of message with
alternative content format; identifies the original message data
to which it corresponds.
2.1.29. Header Field: PICS-Label
Description:
PICS rating label
Applicable protocol: Mail [18]
Status: standard
Author/change controller:
W3C (mailto:web-human@w3.org)
World Wide Web Consortium
Specification document(s):
PICS-labels [24]
Related information:
Ratings label to control selection (filtering) of messages
according to the PICS protocol. Specified for general use with
RFC 822 message format, with HTTP-specific extensions.
2.1.30. Header Field: Encoding
Description:
Message encoding and other information
Applicable protocol: Mail [18]
Status: experimental
Author/change controller:
Albert K. Costanzo (mailto:AL@AKC.COM)
AKC Consulting Inc.
Specification document(s):
RFC 1505 [4]
Related information:
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,
and some in other ways.
2.1.31. Header Field: List-Archive
Description:
URL of mailing list archive
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to use to browse the archives of the mailing list
from which this message was relayed.
2.1.32. Header Field: List-Help
Description:
URL for mailing list information
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to use to get information about the mailing list
from which this message was relayed.
2.1.33. Header Field: List-ID
Description:
Mailing list identifier
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2919 [20]
Related information:
Stores an identification of the mailing list through which this
message was distributed.
2.1.34. Header Field: List-Owner
Description:
URL for mailing list owner's mailbox
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to send e-mail to the owner of the mailing list
from which this message was relayed.
2.1.35. Header Field: List-Post
Description:
URL for mailing list posting
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to use to send contributions to the mailing list
from which this message was relayed.
2.1.36. Header Field: List-Subscribe
Description:
URL for mailing list subscription
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to use to get a subscription to the mailing list
from which this message was relayed.
2.1.37. Header Field: List-Unsubscribe
Description:
URL for mailing list unsubscription
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2369 [13]
Related information:
Contains the URL to use to unsubscribe the mailing list from which
this message was relayed.
2.1.38. Header Field: Message-Context
Description:
Type or context of message
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 3458 [23]
Related information:
Provides information about the context and presentation
characteristics of a message. Can have the values 'voice-
message', 'fax-message', 'pager-message', 'multimedia-message',
'text-message', or 'none'.
2.1.39. Header Field: DL-Expansion-History
Description:
Trace of distribution lists passed
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Trace of distribution lists passed. (MIXER X.400 mapping; not for
general use.)
2.1.40. Header Field: Alternate-Recipient
Description:
Controls forwarding to alternate recipients
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Controls whether this message may be forwarded to an alternate
recipient, such as a postmaster, if delivery to the intended
recipient is not possible. Default: Allowed. RFC 2156 (MIXER),
not for general use.
2.1.41. Header Field: Original-Encoded-Information-Types
Description:
Body part types in message
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Which body part types occur in this message. RFC 2156 (MIXER);
not for general use.
2.1.42. Header Field: Content-Return
Description:
Return content on non-delivery?
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 1327 [3]
Related information:
Indicates whether the content of a message is to be returned with
non-delivery notifications. Introduced by RFC 1327 and
subsequently changed by RFC 2156 to avoid confusion with MIME
defined fields.
2.1.43. Header Field: Generate-Delivery-Report
Description:
Request delivery report generation
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Indicates whether a delivery report is wanted at successful
delivery. Default is not to generate such a report. RFC 2156
(MIXER); not for general use.
2.1.44. Header Field: Prevent-NonDelivery-Report
Description:
Non-delivery report required?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Indicates whether a non-delivery report is wanted on delivery
error. Default is to generate such a report. RFC 2156 (MIXER);
not for general use.
2.1.45. Header Field: Obsoletes
Description:
Reference message to be replaced
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 1327 [3]
Related information:
Reference to a previous message being corrected and replaced.
Compare to 'Supersedes:',f used in Usenet News. Introduced by RFC
1327 and subsequently renamed by RFC 2156 to 'Supersedes'.
2.1.46. Header Field: Supersedes
Description:
Reference message to be replaced
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Reference to a previous message being corrected and replaced.
Renamed version of obsolete 'Obsoletes' header field. RFC 2156
(MIXER); not for general use.
2.1.47. Header Field: Content-Identifier
Description:
Message content identifier
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 1327 [3]
Related information:
A text string that identifies the content of a message.
Introduced by RFC 1327 and subsequently changed by RFC 2156 to
avoid confusion with MIME defined fields. Gateways that reverse
map may support the old field.
2.1.48. Header Field: Delivery-Date
Description:
Message delivery time
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
The time when a message was delivered to its recipient. RFC 2156
(MIXER); not for general use.
2.1.49. Header Field: Expiry-Date
Description:
Message expiry time
Applicable protocol: Mail [18]
Status: obsolete
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 1327 [3]
Related information:
Time at which a message loses its validity. Introduced by RFC
1327 and subsequently changed by RFC 2156 to 'Expires:'.
2.1.50. Header Field: Expires
Description:
Message expiry time
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Time at which a message loses its validity. Renamed version of
obsolete Expiry-Date header field. RFC 2156 (MIXER), not for
general use.
2.1.51. Header Field: Reply-By
Description:
Time by which a reply is requested
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Latest time by which a reply is requested (not demanded). RFC
2156 (MIXER); not for general use.
2.1.52. Header Field: Importance
Description:
Message importance
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
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. Proposed for use with RFC 2156 (MIXER) [10]
and RFC 3801 (VPIM) [14].
2.1.53. Header Field: Incomplete-Copy
Description:
Body parts are missing
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Body parts are missing. RFC 2156 (MIXER); not for general use.
2.1.54. Header Field: Priority
Description:
Message priority
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Can be 'normal', 'urgent', or 'non-urgent' and can influence
transmission speed and delivery. RFC 2156 (MIXER); not for
general use.
2.1.55. Header Field: Sensitivity
Description:
Message content sensitivity
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
How sensitive it is to disclose this message to people other than
the specified recipients. Values: Personal, private, and company
confidential. The absence of this header field in messages
gatewayed from X.400 indicates that the message is not sensitive.
Proposed for use with RFC 2156 (MIXER) [10] and RFC 3801 (VPIM)
[14].
2.1.56. Header Field: Language
Description:
X.400 message content language
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Can include a code for the natural language used in a message;
e.g., 'en' for English. See also 'Content-Language'. RFC 2156
(MIXER); not for general use.
2.1.57. Header Field: Conversion
Description:
Conversion allowed?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
The body of this message may not be converted from one character
set to another. Values: prohibited and allowed. RFC 2156
(MIXER); not for general use.
2.1.58. Header Field: Conversion-With-Loss
Description:
Lossy conversion allowed?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
The body of this message may not be converted from one character
set to another if information will be lost. Values: prohibited
and allowed. RFC 2156 (MIXER); not for general use.
2.1.59. Header Field: Message-Type
Description:
Message type: delivery report?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Only used with the value 'Delivery Report' to indicate that this
is a delivery report gatewayed from X.400. RFC 2156 (MIXER); not
for general use.
2.1.60. Header Field: Autosubmitted
Description:
Automatically submitted indicator
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Has been automatically submitted. RFC 2156 (MIXER); not for
general use.
2.1.61. Header Field: Autoforwarded
Description:
Automatically forwarded indicator
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Has been automatically forwarded. RFC 2156 (MIXER), not for
general use.
2.1.62. Header Field: Discarded-X400-IPMS-Extensions
Description:
X.400 IPM extensions discarded
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Can be used in Internet mail to indicate X.400 IPM extensions that
could not be mapped to Internet mail format. RFC 2156 (MIXER);
not for general use.
2.1.63. Header Field: Discarded-X400-MTS-Extensions
Description:
X.400 MTS extensions discarded
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Can be used in Internet mail to indicate X.400 MTS extensions that
could not be mapped to Internet mail format. RFC 2156 (MIXER);
not for general use.
2.1.64. Header Field: Disclose-Recipients
Description:
Disclose names of other recipients?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Tells 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 done in Internet mail via the To:, cc:, and bcc:
header fields. Not for general use.
2.1.65. Header Field: Deferred-Delivery
Description:
Deferred delivery information
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Provides information about deferred delivery service to the
recipient. RFC 2156 (MIXER); not for general use.
2.1.66. Header Field: Latest-Delivery-Time
Description:
Latest delivery time requested
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Provides the recipient with information about requested delivery
but will not be acted on by the SMTP infrastructure. RFC 2156
(MIXER); not for general use.
2.1.67. Header Field: Originator-Return-Address
Description:
Originator return address
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Originator return address. RFC 2156 (MIXER); not for general use.
2.1.68. Header Field: X400-Content-Identifier
Description:
Message content identifier
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
A text string that identifies the content of a message. Renamed
version of obsolete Content-Identifier field. RFC 2156 (MIXER);
not for general use.
2.1.69. Header Field: X400-Content-Return
Description:
Return content on non-delivery?
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
Indicates whether the content of a message is to be returned with
non-delivery notifications. Renamed version of obsolete Content-
Return field. RFC 2156 (MIXER); not for general use.
2.1.70. Header Field: X400-Content-Type
Description:
X400 content type
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 content type. RFC 2156 (MIXER); not for general use.
2.1.71. Header Field: X400-MTS-Identifier
Description:
X400 MTS-Identifier
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 MTS-Identifier. RFC 2156 (MIXER); not for general use.
2.1.72. Header Field: X400-Originator
Description:
X400 Originator
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 Originator. RFC 2156 (MIXER); not for general use.
2.1.73. Header Field: X400-Received
Description:
X400 Received
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 Received. RFC 2156 (MIXER); not for general use.
2.1.74. Header Field: X400-Recipients
Description:
X400 Recipients
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 Recipients. RFC 2156 (MIXER); not for general use.
2.1.75. Header Field: X400-Trace
Description:
X400 Trace
Applicable protocol: Mail [18]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2156 [10]
Related information:
X400 Trace. RFC 2156 (MIXER), not for general use.
2.2. Permanent MIME Header Field Registrations
Header name Protocol
----------- --------
MIME-Version MIME MIME version number
Content-ID MIME Identify content body part
Content-Description MIME Description of message body part
Content-Transfer-Encoding
MIME Content transfer encoding applied
Content-Type MIME MIME content type
Content-Base MIME Base to be used for resolving
relative URIs within this content
part
Content-Location MIME URI for retrieving a body part
Content-features MIME Indicates content features of a
MIME body part
Content-Disposition MIME Intended content disposition and
file name
Content-Language MIME Language of message content
Content-Alternative MIME Alternative content available
Content-MD5 MIME MD5 checksum of content
Content-Duration MIME Time duration of content
2.2.1. Header Field: MIME-Version
Description:
MIME version number
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2045 [7] (section 4)
Related information:
An indicator that this message is formatted according to the MIME
standard, and an indication of which version of MIME is used.
2.2.2. Header Field: Content-ID
Description:
Identify content body part
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2045 [7] (section 7)
Related information:
Specifies a Unique ID for one MIME body part of the content of a
message.
2.2.3. Header Field: Content-Description
Description:
Description of message body part
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2045 [7] (section 8)
Related information:
Description of a particular body part of a message; for example, a
caption for an image body part.
2.2.4. Header Field: Content-Transfer-Encoding
Description:
Content transfer encoding applied
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2045 [7] (section 6)
Related information:
Coding method used in a MIME message body part.
2.2.5. Header Field: Content-Type
Description:
MIME content type
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2045 [7] (section 5)
Related information:
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). The 'MIME-version' header field will show
whether 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 [5]
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. See also RFC 1049, RFC 1123: 5.2.13, and RFC 1766:
4.1.
2.2.6. Header Field: Content-Base
Description:
Base to be used for resolving relative URIs within this content
part.
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2110 [8]
Related information:
Base to be used for resolving relative URIs within this content
part. See also Content-Location. This header was included in the
first version of MHTML and HTTP 1.1 but removed in the second
version (RFC 2557).
2.2.7. Header Field: Content-Location
Description:
URI for retrieving a body part
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2557 [16]
Related information:
URI using which the content of this body-part part was retrieved,
might be retrievable, or which otherwise gives a globally unique
identification of the content.
2.2.8. Header Field: Content-features
Description:
Indicates content features of a MIME body part
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2912 [19] (section 3)
Related information:
The 'Content-features:' header can be used to annotate a MIME body
part with a media feature expression, to indicate features of the
body part content. See also RFC 2533, RFC 2506, and RFC 2045.
2.2.9. Header Field: Content-Disposition
Description:
Intended content disposition and file name
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2183 [11]
Related information:
Indicates 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.
2.2.10. Header Field: Content-Language
Description:
Language of message content
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 3282 [21]
Related information:
Can include a code for the natural language used in a message;
e.g., 'en' for English. Can also contain a list of languages for
a message containing more than one language.
2.2.11. Header Field: Content-Alternative
Description:
Alternative content available
Applicable protocol: MIME [7]
Status: work-in-progress
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 3297 [22]
Related information:
Information about the media features of alternative content
formats available for the current message.
2.2.12. Header Field: Content-MD5
Description:
MD5 checksum of content
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 1864 [6]
Related information:
Checksum of content to ensure that it has not been modified.
2.2.13. Header Field: Content-Duration
Description:
Time duration of content
Applicable protocol: MIME [7]
Status: standards-track
Author/change controller:
IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force
Specification document(s):
RFC 2424 [15]
Related information:
Time duration of body part content, in seconds (e.g., for audio
message).
3. IANA Considerations
Section 2 of this specification provides initial registrations of
mail and MIME header fields in the "Permanent Message Header Field
Registry", defined by registration procedures for message header
fields [1].
4. Security Considerations
No security considerations are introduced by this registration
document beyond those already inherent in use of the mail message
header fields referenced.
5. Acknowledgements
Most of the information in this document has been derived from Jacob
Palme's work in RFC 2076 [25] and subsequent updates [26]. The
authors also gratefully acknowledge contributions and constructive
input from Mark Nottingham, Bruce Lilly, Keith Moore, and Charles
Lindsey (the mention of whom is not intended to imply their
unqualified support for material herein).
6. References
6.1. Normative References
[1] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[2] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, May 1992.
[4] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", RFC 1505, August 1993.
[5] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[6] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[8] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
1997.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[11] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[12] Hansen, T. and G. Vaudreuil, "Message Disposition Notification",
RFC 3798, May 2004.
[13] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", RFC 2369, July 1998.
[14] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", RFC 3801, June 2004.
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
Definition", RFC 3803, June 2004.
[16] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
1999.
[17] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[18] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[19] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[20] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", RFC 2919,
March 2001.
[21] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[22] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for
Messaging Services based on Email", RFC 3297, July 2002.
[23] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[24] Miller, J., Krauskopf, T., Resnick, P. and W. Treese, "PICS
Label Distribution Label Syntax and Communication Protocols",
W3C Recommendation REC-PICS-labels, October 1996,
<http://www.w3.org/TR/REC-PICS-labels>.
6.2. Informative References
[25] Palme, J., "Common Internet Message Headers", RFC 2076, February
1997.
[26] Palme, J., "Common Internet Message Header Fields", Work in
Progress.
URIs
[27] <http://www.ninebynine.org/IETF/Messaging/HdrRegistry/
Intro.html>
Authors' Addresses
Graham Klyne
Image Bioinformatics Research Group
Department of Zoology, University of Oxford
South Parks Road, Oxford OX1 3PS, UK
Phone: +44-(0)1865-281991
Fax: +44-(0)1865-310447
EMail: GK-IETF@ninebynine.org
Jacob Palme
Stockholm University/KTH
Forum 100
Kista S-164 40
Sweden
Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
PROBLEMMail and MIME messages carry many named header fields, and without one authoritative list two people could use the same name for different things.
MECHANISMRFC 4021 supplies the initial registrations of 75 mail header fields and 13 MIME header fields, each as a template giving description, protocol, status, controller and specification, following the procedure in RFC 3864.
WHY IT MATTERSThe registrations seed the Permanent Message Header Field Registry. The RFC is a Proposed Standard and is updated by RFC 5322.
§1What This Document Registers
RFC 4021 gives the initial IANA registrations for a number of mail message and MIME header fields, using the registration procedures for message header fields in RFC 3864. It contains no new protocol. Its main body is automatically generated from RDF/N3 data.
Section 2.1 holds the templates for mail header fields and section 2.2 holds the templates for MIME header fields. Most of the information comes from Jacob Palme's earlier work in RFC 2076 and later updates.
It is a phone book for email labels. It does not invent new labels, it just writes down the ones already in use.
§2The Registration Template
Each header field gets a template with the same few entries: a Description, the Applicable protocol (Mail or MIME), a Status, the Author/change controller, the Specification document(s) and Related information. In every entry the controller is the IETF, with the IESG mailbox as contact.
The status values used are standard (23 entries), standards-track (57), obsolete (6), experimental (1) and work-in-progress (1). Each section also opens with a summary table of header names, so you can scan the list before the full templates.
Each label gets an index card with the same blanks: what it means, who owns it, and whether it is still in good standing.
| Status | Entries |
|---|---|
| standard | 23 |
| standards-track | 57 |
| obsolete | 6 |
| experimental | 1 |
| work-in-progress | 1 |
§2.1Core Mail Header Fields
The mail section covers 75 fields. The best known are marked standard and point to RFC 2822, with the note that they were defined as standard by RFC 822. These include Date, From (the author's mailbox), Sender (the agent that actually transmitted the message), Reply-To, To, Cc, Bcc, Subject, Comments and Keywords.
Threading and tracing fields sit alongside them. Message-ID is a single unique identifier for a particular version of a message, and it is kept if the message is resent without changes. In-Reply-To and References name related messages, and RFC 2822 changed References to list the Message-IDs of the preceding reply chain. Received carries trace information from each mail transfer agent, and Return-Path carries the return path. The Resent-* family covers messages that are reintroduced into the transfer system.
These are the labels every email has: who wrote it, who it is for, what it is about, and when. Others record each stop the message made on its trip.
§2.1.31Mailing List, Notification and Specialised Fields
Many mail fields serve narrower jobs. The List-* group (List-Archive, List-Help, List-ID, List-Owner, List-Post, List-Subscribe and List-Unsubscribe) lets a mailing list identify itself and point at its archive, help, posting and subscription addresses. Disposition-Notification-To and Disposition-Notification-Options relate to disposition notifications, and Importance is a hint about how important a message is, with values high, normal or low, and it is not used to control transmission speed.
A large block of fields comes from mapping between X.400 and Internet mail, mostly from RFC 2156 (MIXER). Examples are Autosubmitted, Autoforwarded, Incomplete-Copy and the X400-* fields. Their entries are marked as for MIXER and not for general use. Some fields are marked obsolete: Obsoletes was renamed Supersedes by RFC 2156, and Encrypted is also listed as obsolete.
Some labels are for special jobs, like telling you how to leave a club's mailing list, or marking a letter that came from a different kind of post office.
§2.2MIME Header Fields
The MIME section registers 13 fields. MIME-Version says a message follows MIME and which version. Content-Type gives the format of the content, Content-Transfer-Encoding gives the coding method used in a body part, and Content-ID and Content-Description identify and describe a part, for example a caption for an image. All of these point to RFC 2045.
Others deal with where and how a part is shown. Content-Disposition says whether a part is shown inline or is an attachment and can suggest a filename. Content-Language carries a language code such as en. Content-Location gives a URI for the body part, Content-MD5 carries a checksum of the content, and Content-Duration gives a duration in seconds. Content-Base was in the first version of MHTML but was removed in the second, and Content-Alternative is marked work-in-progress.
These labels describe what is inside the envelope: a picture, a sound or plain words, how it was packed, and whether to show it right away or save it as a file.
§3IANA and Security Considerations
The IANA Considerations say that section 2 provides the initial registrations in the "Permanent Message Header Field Registry" defined by the procedures in RFC 3864.
The Security Considerations are short: no security considerations are introduced beyond those already inherent in the use of the referenced mail message header fields.
The list is handed to the official record keeper. Writing the list down does not add any new danger to email.
§7References
[1]RFC 3864Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.September 2004[2]RFC 822Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.August 1982[7]RFC 2045Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.November 1996[10]RFC 2156Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.January 1998[18]RFC 2822Resnick, P., "Internet Message Format", RFC 2822, April 2001.April 2001[25]RFC 2076Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.February 1997