| TOC |
|
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
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.
This Internet-Draft will expire on November 5, 2004.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document defines the initial IANA registration for permanent mail and MIME message header fields, per [[[RFC XXXX (xref target="msghdr-registry" /)]]].
Please send comments to <ietf-822@imc.org>. To subscribe to this list, send a message with the body 'subscribe' to <ietf-822-request@imc.org>.
1.
Introduction
1.1
Structure of this document
1.2
Document terminology and conventions
2.
Registration templates
2.1
Permanent mail header field registrations
2.1.1
Header field: Date
2.1.2
Header field: From
2.1.3
Header field: Sender
2.1.4
Header field: Reply-To
2.1.5
Header field: To
2.1.6
Header field: Cc
2.1.7
Header field: Bcc
2.1.8
Header field: Message-ID
2.1.9
Header field: In-Reply-To
2.1.10
Header field: References
2.1.11
Header field: Subject
2.1.12
Header field: Comments
2.1.13
Header field: Keywords
2.1.14
Header field: Resent-Date
2.1.15
Header field: Resent-From
2.1.16
Header field: Resent-Sender
2.1.17
Header field: Resent-To
2.1.18
Header field: Resent-Cc
2.1.19
Header field: Resent-Bcc
2.1.20
Header field: Resent-Reply-To
2.1.21
Header field: Resent-Message-ID
2.1.22
Header field: Return-Path
2.1.23
Header field: Received
2.1.24
Header field: Encrypted
2.1.25
Header field: Disposition-Notification-To
2.1.26
Header field: Disposition-Notification-Options
2.1.27
Header field: Accept-Language
2.1.28
Header field: Original-Message-ID
2.1.29
Header field: PICS-Label
2.1.30
Header field: Encoding
2.1.31
Header field: List-Archive
2.1.32
Header field: List-Help
2.1.33
Header field: List-ID
2.1.34
Header field: List-Owner
2.1.35
Header field: List-Post
2.1.36
Header field: List-Subscribe
2.1.37
Header field: List-Unsubscribe
2.1.38
Header field: Message-Context
2.1.39
Header field: DL-Expansion-History
2.1.40
Header field: Alternate-Recipient
2.1.41
Header field: Original-Encoded-Information-Types
2.1.42
Header field: Content-Return
2.1.43
Header field: Generate-Delivery-Report
2.1.44
Header field: Prevent-NonDelivery-Report
2.1.45
Header field: Obsoletes
2.1.46
Header field: Supersedes
2.1.47
Header field: Content-Identifier
2.1.48
Header field: Delivery-Date
2.1.49
Header field: Expiry-Date
2.1.50
Header field: Expires
2.1.51
Header field: Reply-By
2.1.52
Header field: Importance
2.1.53
Header field: Incomplete-Copy
2.1.54
Header field: Priority
2.1.55
Header field: Sensitivity
2.1.56
Header field: Language
2.1.57
Header field: Conversion
2.1.58
Header field: Conversion-With-Loss
2.1.59
Header field: Message-Type
2.1.60
Header field: Autosubmitted
2.1.61
Header field: Autoforwarded
2.1.62
Header field: Discarded-X400-IPMS-Extensions
2.1.63
Header field: Discarded-X400-MTS-Extensions
2.1.64
Header field: Disclose-Recipients
2.1.65
Header field: Deferred-Delivery
2.1.66
Header field: Latest-Delivery-Time
2.1.67
Header field: Originator-Return-Address
2.1.68
Header field: X400-Content-Identifier
2.1.69
Header field: X400-Content-Return
2.1.70
Header field: X400-Content-Type
2.1.71
Header field: X400-MTS-Identifier
2.1.72
Header field: X400-Originator
2.1.73
Header field: X400-Received
2.1.74
Header field: X400-Recipients
2.1.75
Header field: X400-Trace
2.2
Permanent MIME header field registrations
2.2.1
Header field: MIME-Version
2.2.2
Header field: Content-ID
2.2.3
Header field: Content-Description
2.2.4
Header field: Content-Transfer-Encoding
2.2.5
Header field: Content-Type
2.2.6
Header field: Content-Base
2.2.7
Header field: Content-Location
2.2.8
Header field: Content-features
2.2.9
Header field: Content-Disposition
2.2.10
Header field: Content-Language
2.2.11
Header field: Content-Alternative
2.2.12
Header field: Content-MD5
2.2.13
Header field: Content-Duration
3.
IANA considerations
4.
Security considerations
5.
Acknowledgements
§.
Normative references
§.
Informative references
§
Authors' Addresses
A.
Revision history
A.1
draft-klyne-hdrreg-mail-05
A.2
draft-klyne-hdrreg-mail-04
A.3
draft-klyne-hdrreg-mail-03
A.4
draft-klyne-hdrreg-mail-02
A.5
draft-klyne-hdrreg-mail-01
A.6
draft-klyne-hdrreg-mail-00
B.
TODO:
§
Intellectual Property and Copyright Statements
| TOC |
This document defines IANA registration for a number of mail message and MIME header fields, per Registration procedures for message header fieldsKlyne, G., Nottingham, M. and J. Mogul, Registration procedures for message headers, Oct 2003.[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 http://www.ninebynine.org/IETF/Messaging/HdrRegistry/Intro.html.
Section Section 2.1 contains the templates for initial registration of mail message header fields.
Section Section 2.2 contains templates for initial registration of MIME header fields.
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 RFC 2119 [11]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
[[[Editorial comments and questions about outstanding issues are provided in triple brackets like this. These working comments should be resolved and removed prior to final publication.]]]
| TOC |
Header field registry entries are summarized in tabular form for convenience of reference, and presented in full in the following sections.
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 lenguage
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
- Description:
- Message date and time
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Mailbox of message author
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Mailbox of message sender
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Mailbox for replies to message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Primary recipient mailbox
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.3)
- Related information:
- Contains the address(es) of the primary recipient(s) of the message. Defined as standard by RFC 822.
- Description:
- Carbon-copy recipient mailbox
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Blind-carbon-copy recipient mailbox
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Message identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Identify replied-to message(s)
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Related message identifier(s)
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.4)
- Related information:
- The message identifier(s) of other message(s) to which the current message may be related. In RFC2822, 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.
- Description:
- Topic of message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.5)
- Related information:
- Contains a short string identifying the topic of the message. Defined as standard by RFC 822.
- Description:
- Additional comments about the message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Message key words and/or phrases
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Date and time message is resent
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Mailbox of person for whom message is resent
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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 behanlf the message has been resent. Defined as standard by RFC 822.
- Description:
- Mailbox of person who actually resends the message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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.
- Description:
- Mailbox to which message is resent
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.6)
- Related information:
- Contains the mailbox(es) to which the message has been resent. Defined as standard by RFC 822.
- Description:
- Mailbox(es) to which message is cc'ed on resend
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.6)
- Related information:
- Containes the mailbox(es) to which message is cc'ed on resend. Defined as standard by RFC 822.
- Description:
- Mailbox(es) to which message is bcc'ed on resend
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.6)
- Related information:
- Containes the mailbox(es) to which message is bcc'ed on resend. Defined as standard by RFC 822.
- Description:
- Resent reply-to
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20]
- Related information:
- Resent Reply-to. Defined by RFC 822, obsoleteed by RFC2822.
- Description:
- Message identifier for resent message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.6)
- Related information:
- Contains a message identifier for a resent message. Defined as standard by RFC 822.
- Description:
- Message return path
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (section 3.6.7)
- Related information:
- Return path for message response diagnostics. See also, RFC 2821. Defined as standard by RFC 822.
- Description:
- Mail transfer trace information
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2822Resnick, P., Internet Message Format, April 2001.[20] (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. Defined as standard by RFC 822.
- Description:
- Message encryption information
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 822Crocker, D., Standard for the format of ARPA Internet text messages, August 1982.[2]
- Related information:
- Defined by RFC 822, but was found to be inadequately specified, not widely implemented, and 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.
- Description:
- Mailbox for sending disposition notification
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2298Fajman, R., An Extensible Message Format for Message Disposition Notifications, March 1998.[14]
- Related information:
- Indicates that the sender wants a disposition notification when this message is received (read, processed, etc.) by its recipients.
- Description:
- Disposition notification options
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2298Fajman, R., An Extensible Message Format for Message Disposition Notifications, March 1998.[14]
- Related information:
- For optional modifiers on disposition notification requests.
- Description:
- Language(s) for auto-responses
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 3282Alvestrand, H., Content Language Headers, May 2002.[23]
- Related information:
- Indicates a language that the message sender requests be used for responses. Accept-language was not designed for email, but has been considered to be 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; determining what character set encoding should be used.
- Description:
- Original message identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 3297Klyne, G., Iwazaki, R. and D. Crocker, Content Negotiation for Messaging Services based on Email, July 2002.[24]
- Related information:
- Original message identifier used with resend of message with alternative content format, identifies the original message data to which it corresponds.
- Description:
- PICS rating label
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standard
- Author/change controller:
- W3C (mailto:web-human@w3.org)
World Wide Web Consortium- Specification document(s):
- PICS-labelsMiller, J., Krauskopf, T., Resnick, P. and W. Treese, PICS Label Distribution Label Syntax and Communication Protocols, October 1996.[26]
- Related information:
- Ratings label to control selection (filtering) of messages according to the PICS protocol. Specified for general use with RFC822 message format, with HTTP-specific extensions
- Description:
- Message encoding and other information
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- experimental
- Author/change controller:
- Albert K. Costanzo (mailto:AL@AKC.COM)
AKC Consulting Inc.- Specification document(s):
- RFC 1505Costanzo, A., Robinson, D. and R. Ullmann, Encoding Header Field for Internet Messages, August 1993.[5]
- 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, some in other ways.
- Description:
- URL of mailing list archive
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to use to browse the archives of the mailing list from which this message was relayed.
- Description:
- URL for mailing list information
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to use to get a information about the mailing list from which this message was relayed.
- Description:
- Mailing list identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2919Chandhok, R. and G. Wenger, List-Id: A Structured Field and Namespace for the Identification of Mailing Lists, March 2001.[22]
- Related information:
- Stores an identification of the mailing list, through which this message was distributed.
- Description:
- URL for mailing list owner's mailbox
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to send e-mail to the owner of the mailing list from which this message was relayed.
- Description:
- URL for mailing list posting
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to use to send contributions to the mailing list from which this message was relayed.
- Description:
- URL for mailing list subscription
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to use to get a subscription to the mailing list from which this message was relayed.
- Description:
- URL for mailing list unsubscription
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2369Neufeld, G. and J. Baer, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields, July 1998.[15]
- Related information:
- Contains URL to use to unsubscribe the mailing list from which this message was relayed.
- Description:
- Type or context of message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- Standards track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC3458Burger, E., Candell, E., Eliot, C. and G. Klyne, Message Context for Internet Mail, January 2003.[25]
- 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', 'none'.
- Description:
- Trace of distribution lists passed
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Trace of distribution lists passed. (MIXER X.400 mapping, not for general use.)
- Description:
- Controls forwarding to alternate recipients
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- 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. RFC 2156 (MIXER), not for general use.
- Description:
- Body part types in message
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Which body part types occur in this message. RFC 2156 (MIXER), not for general use.
- Description:
- Return content on non-delivery?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 1327Hardcastle-Kille, S., Mapping between X.400(1988) / ISO 10021 and RFC 822, May 1992.[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.
- Description:
- Request delivery report generation
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Non-delivery report required?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Indicates whether non-delivery report is wanted on delivery error. Default is to generate such a report. RFC 2156 (MIXER), not for general use.
- Description:
- Reference message to be replaced
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 1327Hardcastle-Kille, S., Mapping between X.400(1988) / ISO 10021 and RFC 822, May 1992.[3]
- Related information:
- Reference to a previous message being corrected and replaced. Compare to 'Supersedes:' used in Usenet News. Introduced by RFC 1327, and subsequently renamed by RFC 2156 to 'Supersedes'.
- Description:
- Reference message to be replaced
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Message content identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 1327Hardcastle-Kille, S., Mapping between X.400(1988) / ISO 10021 and RFC 822, May 1992.[3]
- Related information:
- A text string which identifies the content of a message. Introduced by RFC 1327, and subsequently changed by RFC 2156 to avoid confusion with MIME defined fields. Gateways which reverse map may support the old field.
- Description:
- Message delivery time
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- The time when a message was delivered to its recipient. RFC 2156 (MIXER), not for general use.
- Description:
- Message expiry time
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- obsolete
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 1327Hardcastle-Kille, S., Mapping between X.400(1988) / ISO 10021 and RFC 822, May 1992.[3]
- Related information:
- Time at which a message loses its validity. Introduced by RFC 1327, and subsequently changed by RFC 2156 to 'Expires:'.
- Description:
- Message expiry time
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Time by which a reply is requested
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Latest time at which a reply is requested (not demanded). RFC 2156 (MIXER), not for general use.
- Description:
- Message importance
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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) and RFC 2421 (VPIM).
- Description:
- Body parts are missing.
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Body parts are missing. RFC 2156 (MIXER), not for general use.
- Description:
- Message priority
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Can be 'normal', 'urgent' or 'non-urgent' and can influence transmission speed and delivery. RFC 2156 (MIXER), not for general use.
- Description:
- Message content sensitivity
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- 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. Proposed for use with RFC 2156 (MIXER) and RFC 2421 (VPIM).
- Description:
- X.400 message content lenguage
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Conversion allowed?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Lossy conversion allowed?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- Message type: delivery report?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Only used with the value 'Delivery Report' to indicates that this is a delivery report gatewayed from X.400. RFC 2156 (MIXER), not for general use.
- Description:
- Automatically submitted indicator
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Has been automatically submitted. RFC 2156 (MIXER), not for general use.
- Description:
- Automatically forwarded indicator
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Has been automatically forwarded. RFC 2156 (MIXER), not for general use.
- Description:
- X.400 IPM extensions discarded
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Can be used in Internet mail to indicate X.400 IPM extensions which could not be mapped to Internet mail format. RFC 2156 (MIXER), not for general use.
- Description:
- X.400 MTS extensions discarded
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Can be used in Internet mail to indicate X.400 MTS extensions which could not be mapped to Internet mail format. RFC 2156 (MIXER), not for general use.
- Description:
- Disclose names of other recipients?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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 in Internet mail done via the To:, cc: and bcc: header fields. Not for general use.
- Description:
- Deferred delivery information
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Provides information about deferred delivery service to the recipient. RFC 2156 (MIXER), not for general use.
- Description:
- Latest delivery time requested
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Provides the recipient information about requested delivery, but will not be acted on by the SMTP infrastrucuture. RFC 2156 (MIXER), not for general use.
- Description:
- Originator return address
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- Originator return address. RFC 2156 (MIXER), not for general use.
- Description:
- Message content identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- A text string which identifies the content of a message. Renamed version of obsolete Content-Identifier field. RFC 2156 (MIXER), not for general use.
- Description:
- Return content on non-delivery?
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- 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.
- Description:
- X400 content type
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 content type. RFC 2156 (MIXER), not for general use.
- Description:
- X400 MTS-Identifier
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 MTS-Identifier. RFC 2156 (MIXER), not for general use.
- Description:
- X400 Originator
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 Originator. RFC 2156 (MIXER), not for general use.
- Description:
- X400 Received
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 Received. RFC 2156 (MIXER), not for general use.
- Description:
- X400 Recipients
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 Recipients. RFC 2156 (MIXER), not for general use.
- Description:
- X400 Trace
- Applicable protocol:
- MailResnick, P., Internet Message Format, April 2001.[20]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2156Kille, S., MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME, January 1998.[12]
- Related information:
- X400 Trace. RFC 2156 (MIXER), not for general use.
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
- Description:
- MIME version number
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2045Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8] (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 utilized.
- Description:
- Identify content body part
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2045Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8] (section 7)
- Related information:
- Specifies a Unique ID for one MIME body part of the content of a message.
- Description:
- Description of message body part
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2045Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8] (section 8)
- Related information:
- Description of a particular body part of a message, for example a caption for an image body part.
- Description:
- Content transfer encoding applied
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2045Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8] (section 6)
- Related information:
- Coding method used in a MIME message body part.
- Description:
- MIME content type
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2045Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8] (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), 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. See also: RFC 1049, RFC 1123: 5.2.13, RFC 1766: 4.1.
- Description:
- Base to be used for resolving relative URIs within this content part.
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2110Palme, J. and A. Hopmann, MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML), March 1997.[10]
- 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 (RFC2557).
- Description:
- URI for retrieving a body part
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2557Palme, F., Hopmann, A., Shelness, N. and E. Stefferud, MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), March 1999.[18]
- 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.
- Description:
- Indicates content features of a MIME body part
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2912Klyne, G., Indicating Media Features for MIME Content, September 2000.[21] (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, RFC 2045.
- Description:
- Intended content disposition and file name
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2183Troost, R., Dorner, S. and K. Moore, Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field, August 1997.[13]
- Related information:
- 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.
- Description:
- Language of message content
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 3282Alvestrand, H., Content Language Headers, May 2002.[23]
- 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.
- Description:
- Alternative content available
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- work-in-progress
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 3297Klyne, G., Iwazaki, R. and D. Crocker, Content Negotiation for Messaging Services based on Email, July 2002.[24]
- Related information:
- Information about the media features of alternative content formats available for the current message.
- Description:
- MD5 checksum of content
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 1864Myers, J. and M. Rose, The Content-MD5 Header Field, October 1995.[7]
- Related information:
- Checksum of content to ensure that it has not been modified.
- Description:
- Time duration of content
- Applicable protocol:
- MIMEFreed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.[8]
- Status:
- standards-track
- Author/change controller:
- IETF (mailto:iesg@ietf.org)
Internet Engineering Task Force- Specification document(s):
- RFC 2424Vaudreuil, G. and G. Parsons, Content Duration MIME Header Definition, September 1998.[17]
- Related information:
- Time duration of body part content, in seconds (e.g. for audio message).
| TOC |
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 fieldsKlyne, G., Nottingham, M. and J. Mogul, Registration procedures for message headers, Oct 2003.[1].
| TOC |
No security considerations are introduced by this registration document beyond those already inherent in use of the mail message header fields referenced.
| TOC |
Most of the information in this document has been derived from Jacob Palme's work in RFC 2076Palme, J., Common Internet Message Headers, February 1997.[27] and subsequent updates [28]Palme, J., Common Internet Message Header Fields, November 2001..
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).
| TOC |
| TOC |
| TOC |
| [27] | Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. |
| [28] | Palme, J., "Common Internet Message Header Fields", Internet draft draft-palme-mailext-headers-08, November 2001. |
| TOC |
| Graham Klyne | |
| Nine by Nine | |
| UK | |
| EMail: | GK-IETF@ninebynine.org |
| URI: | http://www.ninebynine.net/ |
| 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 |
| TOC |
[[[Please remove this section on final publication]]]
- 05a 07-May-2004: