RFC 4021

Registration of Mail and MIME Header Fields

📅 published March 2005, from ietf

RFC 4021: Registration of Mail and MIME Header Fields 💌

okay so this one is from the Network Working Group 🌸, and it's a Standards Track doc, so it's a real protocol spec, not just vibes. It came out in March 2005 and it was written by G. Klyne from the University of Oxford and J. Palme from Stockholm University/KT 🎀. It doesn't list anything it obsoletes or updates, so it's standing on its own. Iconic. 💅

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited, so share it with everyone 🦋.

Copyright Notice ©

Copyright (C) The Internet Society (2005). 💜

Abstract ✨

This document sets up the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864 🌈. Basically it's the starter pack for the registry, and it follows the rules from 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 ✨

okay bestie, this section sets up IANA registration for a bunch of mail message and MIME header fields 📬. It follows the registration procedures for message header fields [1] 💖.

The main body of this document is automatically generated from RDF/N3 data 🤖. There are also some experimental HTML registry pages made from that same data, and you can find them at [27] 🌸.

1.1. Structure of This Document

Section 2.1 has the templates for initial registration of mail message header fields 📨. Section 2.2 has the 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] 🧠. This is the bit where the key words get their official meaning, so read it carefully 👑.

2. Registration Templates 🦋

Header field registry entries are summarized in tabular form so they're easy to scan, and they're presented in full in the following sections 💅.

2.1. Permanent Mail Header Field Registrations ✨

okay so this is the big list of permanent mail header fields 📬🎀 every row is a header name with its protocol (always Mail here) and a quick note about what it does. Here's the whole lineup:

   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: this one marks the date and time the message creator said it 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: this names the author(s), meaning the mailbox(es) of whoever is responsible for writing 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: this points to the mailbox of the agent actually in charge of sending 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 shows up, it's the author politely suggesting where replies should go 💌 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: this holds the address(es) of the main recipient(s) 🎯 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: these are the people who get the message too, even if it isn't really aimed 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: this is the secret guest list 🤫 These are recipients whose addresses stay hidden from everyone else on 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: this is one unique ID for one particular version of a message 🆔 If the message gets resent without any changes, the original Message-ID sticks around. 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: these are the message ID(s) of the original message(s) the current one is replying to 💬 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: these are the IDs of other messages the current one might be connected to 🧵 RFC 2822 changed the definition so this field holds a list of all Message-IDs 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: a short string that tells everyone what the message is about 📝 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: any extra comments about the body of the message 🗯️ Defined as standard by RFC 822.

Warning: Some mailers will not show this field to recipients. 💀

2.1.13. Header Field: Keywords 🔑

okay so this one is the little tag-along header bestie 🏷️ It's a comma-separated list of important words and phrases that the recipient might find useful.

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 info: it holds a comma-separated list of the key words and phrases, and it was defined as standard by RFC 822 🎀

2.1.14. Header Field: Resent-Date 📅

this one tells you the date and time that a message got sent again 🔁 it's giving time-stamp energy ⏰

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 info: it contains the date and time that a message gets reintroduced into the message transfer system. It was defined as standard by RFC 822 🌸

2.1.15. Header Field: Resent-From 💌

the mailbox of the person the message was resent for. main character energy 👑

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 info: this contains the mailbox of the agent who reintroduced the message into the message transfer system, or on whose behalf the message was resent. Defined as standard by RFC 822 🦋

2.1.16. Header Field: Resent-Sender 🫶

this is the mailbox of the person who actually did the resending 💅

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 info: it contains the mailbox of the agent who reintroduced the message into the message transfer system, but only if that's different from the Resent-From value. Defined as standard by RFC 822 ✨

2.1.17. Header Field: Resent-To 📮

the mailbox (or mailboxes) the message got 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 info: it contains the mailbox(es) that the message has been resent to. Defined as standard by RFC 822 💖

2.1.18. Header Field: Resent-Cc 📣

the mailboxes that got cc'ed when the message was resent 🙈

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 info: it contains the mailbox(es) that the message was cc'ed to on resend. Defined as standard by RFC 822 🌈

2.1.19. Header Field: Resent-Bcc 🤫

same vibe as Resent-Cc, but secret 🤫 these are the mailboxes that got bcc'ed when the message was resent 🕶️

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 info: it contains the mailbox(es) that the message was bcc'ed to on resend. Defined as standard by RFC 822 💜

2.1.20. Header Field: Resent-Reply-To 🥀

ngl this one is retired now 😭 it was the resent version of 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 info: it was defined by RFC 822 and then obsoleted by RFC 2822. It's a Resent Reply-to, and that's the whole story 🕰️

2.1.21. Header Field: Resent-Message-ID 🪪

the message identifier for a message that got resent 🔖

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 info: it contains a message identifier for a resent message. Defined as standard by RFC 822 🌟

2.1.22. Header Field: Return-Path 🛤️

this is the return path, and it's how diagnostics for message responses get sent back 🔙

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 info: it's the return path for message response diagnostics. See also RFC 2821 [17]. Defined as standard by RFC 822 🧭

2.1.23. Header Field: Received 📬

this one is basically the paper trail of the message 🕵️‍♀️ every mail transfer agent along the way leaves a note about when it got this message

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 info: it contains information about the 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 🔒

okay this one has also retired 🥲 it was the encryption info header for messages

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 info: it was defined by RFC 822, but it was found to be inadequately specified, wasn't widely implemented, and got removed in RFC 2822. Current practice is to use separate encryption, like S/MIME or OpenPGP, possibly together with RFC 1847 MIME security multiparts. honestly the lesson here is to let the pros handle encryption 🔐💀

2.1.25. Header Field: Disposition-Notification-To 👀

this is where the sender says "hey, tell me when you've read this" 👀✨

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 info: it indicates that the sender wants a disposition notification when this message is received (read, processed, etc.) by its recipients. Iconic behaviour 💅

2.1.26. Header Field: Disposition-Notification-Options ⚙️

the extra settings for those read receipts 🎛️ optional modifiers, bestie

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 info: this one is for optional modifiers on disposition notification requests. Customisation is everything 🌸

2.1.27. Header Field: Accept-Language 🌍

this lets the sender ask for a language to be used in auto-replies, which is a whole mood 🗣️ but it wasn't designed for email, so it's a little messy

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 info: it indicates a language that the message sender would like used for responses. Accept-language was not designed for email, but people have found it useful as input when generating automatic replies. There are some problems with using it for email, including but not limited to: working out which email address it refers to; the cost and lack of effective internationalisation of email responses; interpreting language subtags; and deciding which character set encoding should be used. no cap, that's a lot 😭🫠

2.1.28. Header Field: Original-Message-ID 🪞

the identifier of the original message 🪄 it's used when a message gets resent with alternative content format, so it knows which original message data it matches

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 info: it's the original message identifier used with the resend of a message in an alternative content format. It identifies the original message data that it corresponds to 🦋

2.1.29. Header Field: PICS-Label 🏷️

this is the rating label that lets you filter messages using the PICS protocol 🚦 kind of like a content rating on a movie 🎬

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 info: it's a ratings label used to control selection (filtering) of messages according to the PICS protocol. It's specified for general use with the RFC 822 message format, with HTTP-specific extensions. 🌈

2.1.30. Header Field: Encoding 🧩

this one is a little chaotic 🌀 different mail systems have used it in lots of different ways

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 info: some systems 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. it's giving "everyone do their own thing" 🙃

2.1.31. Header Field: List-Archive 🗂️

the URL where you can browse the archives of the mailing list the message came through 📚

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 info: it 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 🆘

the URL with info about the mailing list, for when you're lost 🗺️

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 info: it 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 🆔

the identifier for the mailing list that delivered this message 🪪 it's the list's signature look ✨

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 info: it stores an identification of the mailing list through which this message was distributed. 🌸

2.1.34. Header Field: List-Owner 👑

the URL you use to email the owner of the mailing list 👩‍💼

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 info: it contains the URL to send email to the owner of the mailing list from which this message was relayed. Ask the boss 💅

2.1.35. Header Field: List-Post 📝

the URL you use to send your own contributions to the mailing list ✍️ your moment to speak

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 info: it contains the URL to use to send contributions to the mailing list from which this message was relayed. speak your truth bestie 🎤💖

the URL where you sign up to get the mailing list 💌

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 info: it contains the URL to use to get a subscription to the mailing list from which this message was relayed. join the group chat 🧚✨

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: Bestie, this one holds the URL you use to unsubscribe from the mailing list this message got relayed through ✨

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: This one spills the tea on the vibe and presentation style of a message 💅 It can be voice-message, fax-message, pager-message, multimedia-message, text-message, or none. Iconic, honestly 😭

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: It keeps a trace of the distribution lists the message passed through 🦋 (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: This one decides whether the message is allowed to get forwarded to an alternate recipient, like a postmaster, when the intended recipient can't be reached 📬 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: It lists which body part types show up 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: This one says whether a message's content gets sent back along with non-delivery notifications. It came from RFC 1327 and then RFC 2156 changed it so it wouldn't get mixed up with MIME 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: This one shows whether you want a delivery report when the message gets delivered successfully. 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: This one shows whether you want a non-delivery report when there's a 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: It points at a previous message that's getting corrected and replaced 🔄 Compare to 'Supersedes:', used in Usenet News. It came from RFC 1327, then RFC 2156 renamed it 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: It points at a previous message that's getting corrected and replaced ✨ It's the renamed version of the 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: It's a text string that identifies the content of a message 🧾 It came from RFC 1327, then RFC 2156 changed it so it wouldn't get confused 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 the message got 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: The time when a message stops being valid 💀 It came from RFC 1327, and then RFC 2156 changed it 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: The time when a message stops being valid 🫶 It's the renamed version of the 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: The 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: It's a hint from the sender to the recipients about how important the 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: Some 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: It can be 'normal', 'urgent', or 'non-urgent', and it 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: This one shows how sensitive it is to disclose the message to anyone other than the specified recipients 🔒 Values: Personal, private, and company confidential. If this header field is missing from messages gatewayed from X.400, that means 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: It can hold a code for the natural language used in the message, like '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: It's only used with the value 'Delivery Report' to show that this is a delivery report gatewayed from X.400 💖 RFC 2156 (MIXER); not for general use.

2.1.60. Header Field: Autosubmitted 🤖

Okay so this is the "a robot sent this, not a human" flag 💅

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]

Basically it says the message has been automatically submitted. It comes from RFC 2156 (MIXER) and is not for general use 🫶

2.1.61. Header Field: Autoforwarded 🔁

Same energy, different job: this one flags a message that got automatically forwarded ✨

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]

It's from RFC 2156 (MIXER), not for general use 💜

2.1.62. Header Field: Discarded-X400-IPMS-Extensions 🗑️

This one is for X.400 IPM extensions that didn't survive the trip into Internet mail format. Honestly iconic for a field name 😭

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]

It can be used in Internet mail to point out X.400 IPM extensions that couldn't be mapped to Internet mail format. RFC 2156 (MIXER); not for general use 🌸

2.1.63. Header Field: Discarded-X400-MTS-Extensions 🗑️

Twin of the one above, except this time it's the X.400 MTS extensions that got left behind 🧚

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]

Same deal: it can be used in Internet mail to flag X.400 MTS extensions that couldn't be mapped to Internet mail format. RFC 2156 (MIXER); not for general use 🎀

2.1.64. Header Field: Disclose-Recipients 👀

Okay this one is kind of juicy. It's about whether recipients get to see who else got the message 🙈

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]

It tells whether recipients should be told the names of the other recipients of the same message. This is mainly an X.400 thing. In X.400 it's an envelope attribute and it's about disclosing the envelope recipient list. In Internet mail, other recipients get disclosed through the To:, cc:, and bcc: header fields instead. Not for general use 💅

2.1.65. Header Field: Deferred-Delivery ⏰

This one tells the recipient about the deferred delivery service, so they know the message was set to arrive later 🦋

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]

It gives the recipient information about the deferred delivery service. RFC 2156 (MIXER); not for general use 🌈

2.1.66. Header Field: Latest-Delivery-Time ⌛

The vibe here is "here's the deadline, but no, the mail system won't actually enforce it" 💀

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]

It gives the recipient info about the delivery time that was asked for, but the SMTP infrastructure won't act on it. RFC 2156 (MIXER); not for general use ✨

2.1.67. Header Field: Originator-Return-Address 📮

The sender's return address, plain and simple 💌

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]

Originator return address. RFC 2156 (MIXER); not for general use 🫶

2.1.68. Header Field: X400-Content-Identifier 🏷️

This is a text string that labels what a message contains. It's the renamed version of the old Content-Identifier field, so it got a glow-up 💖

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]

It's a text string that identifies the content of a message. It's the renamed version of the obsolete Content-Identifier field. RFC 2156 (MIXER); not for general use 🎀

2.1.69. Header Field: X400-Content-Return 🔙

This one asks whether the content should come back when a message fails to deliver. Main character drama if it bounces 😭

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]

It shows whether a message's content is supposed to be returned along with non-delivery notifications. It's the renamed version of the obsolete Content-Return field. RFC 2156 (MIXER); not for general use 🌸

2.1.70. Header Field: X400-Content-Type 📦

Just the X400 content type, nothing more, nothing less 🧚

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]

X400 content type. RFC 2156 (MIXER); not for general use 🦋

2.1.71. Header Field: X400-MTS-Identifier 🪪

The X400 MTS-Identifier. It's a very specific ID, so it's giving bouncer at the club vibes 👑

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]

X400 MTS-Identifier. RFC 2156 (MIXER); not for general use 💜

2.1.72. Header Field: X400-Originator ✍️

The X400 Originator, aka who sent it, in X.400 terms 💅

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]

X400 Originator. RFC 2156 (MIXER); not for general use ✨

2.1.73. Header Field: X400-Received 📬

The X400 Received field. It's the X.400 version of "this message passed through here" 🚚

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]

X400 Received. RFC 2156 (MIXER); not for general use 🌈

2.1.74. Header Field: X400-Recipients 👥

The X400 Recipients field, for everyone the message was addressed to in X.400 land 🫶

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]

X400 Recipients. RFC 2156 (MIXER); not for general use 🎀

2.1.75. Header Field: X400-Trace 🕵️

The X400 Trace field, so you can follow the message's path. Detective energy 🔍

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]

X400 Trace. RFC 2156 (MIXER), not for general use 💖

2.2. Permanent MIME Header Field Registrations 🎀

Okay, now we're in MIME territory, and here's the full lineup at a glance:

      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 🔖

This one is the "yep, this message is MIME formatted" stamp, and it also says which version of MIME is in use 💅

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)

It's an indicator that the message is formatted according to the MIME standard, plus an indication of which MIME version is used. ✨

2.2.2. Header Field: Content-ID 🆔

Every MIME body part gets its own unique ID, so it's basically a name tag 🧚

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)

It specifies a unique ID for one MIME body part of a message's content. 🦋

2.2.3. Header Field: Content-Description 📝

Think of this as the caption for a body part. Cute, descriptive, and very on brand 🌸

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)

It's a description of a particular body part of a message. For example, it could be a caption for an image body part. 📸

2.2.4. Header Field: Content-Transfer-Encoding 🔐

This one names the coding method used in a MIME message body part. Encoding is giving secret-message energy 🤫

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)

It's the coding method used in a MIME message body part. 💜

2.2.5. Header Field: Content-Type 🎨

This is the big one, the field that says what the content actually is, like the character set and so on 🌈

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)

Okay, so this field gives the format of the content, like the character set and stuff. ngl the history here is a little messy. The values for this header field are defined in different ways in RFC 1049 and in MIME (RFC 2045). The 'MIME-version' header field tells you whether Content-Type should be read according to RFC 1049 or according to MIME. When you're generating mail, the MIME definition should be used. RFC 1049 has 'historic' status. RFC 1766 [5] defines a parameter 'difference' for this header field. Various other Content-Type values 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 🧭

This one sets the base for resolving relative URIs inside a content part. It had a moment in MHTML and HTTP 1.1, then got dropped in the second version 💀

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]

It's the base 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 it was removed in the second version (RFC 2557). Iconic glow-up arc ⭐

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: This is the URI that the body part's content was retrieved from. It might still be retrievable, or it's the thing that gives the content a globally unique identity. Lowkey the best way to know where your content came from 🫶

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: You can use the Content-features: header to tag a MIME body part with a media feature expression, so it shows off what's inside. 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: This one decides whether a MIME body part shows up inline or comes through as an attachment. It can also suggest a filename for when someone saves that 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: It can hold a code for the natural language in the message, like en for English. It can also hold a list of languages if the message is multilingual, which is so cute for group chats 🌍

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: This one tells you about the media features of other content formats that are available for the same message. Like having backup outfits ready 👗

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: It's a checksum of the content, so you can check that nobody messed with it along the way. Very protective energy 🛡️

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: This is how long the body part's content lasts, measured in seconds. Perfect for something like an audio message 🎧

3. IANA Considerations 📋

Section 2 of this specification gives the initial registrations of mail and MIME header fields in the "Permanent Message Header Field Registry". That registry follows the registration procedures for message header fields [1], so it's all very official 💅

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.

Okay but this is the part where I need you to hear me: this doc doesn't add any new security issues of its own. Any risks are the ones that already come with the mail message header fields it points to. So stay alert, bestie, because those inherited risks are still very real 😭🔥

5. Acknowledgements 🫶

Most of the information in this document comes from Jacob Palme's work in RFC 2076 [25] and its later updates [26]. The authors also gratefully thank Mark Nottingham, Bruce Lilly, Keith Moore, and Charles Lindsey for their contributions and constructive input. Mentioning them doesn't mean they fully agree with everything in here, so no pressure, babes 💜

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

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 doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether a license for those rights is available, and it hasn't independently checked for any such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users of this specification, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from

ietf: rfc4021 2005-03
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms