RFC 1864

RFC 1864: The Content-MD5 Header Field 💖

okay bestie, this is RFC 1864 🎀 and it's giving MIME energy 💅 It was written by J. Myers of Carnegie Mellon and M. Rose of Dover Beach Consulting, Inc., in October 1995. It's a standards track document from the Network Working Group, and it obsoletes RFC 1544 📜 Its title block doesn't list anything it updates ✨

---

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🌸

Abstract 🦋

So the big idea is this: there's an optional header field called Content-MD5, and it's made for MIME-conformant messages 💌

Table of Contents 🗂️

1. Introduction ..............................................    1
2. Generation of the Content-MD5 Field .......................    2
3. Processing the Content-MD5 field ..........................    3
4. Security Considerations ...................................    3
5. Acknowledgements ..........................................    3
6. References ................................................    3
7. Authors' Addresses ........................................    4

---

1. Introduction 🌷

Okay so even with all the stuff MIME [1] does to keep data from getting damaged during email transport, it's still lowkey desirable to have a way to check that the data, once decoded, is actually intact 🔍 That's why this memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC) to verify that the decoded data are the same data that were initially sent. The Content-MD5 header may also be placed in the encapsulated headers of an object of type message/external-body, to be used to verify that the retrieved and decoded data are the same data that were initially referenced. Iconic behavior 👑

MD5 is an algorithm that computes a 128 bit "digest" of arbitrary-length data, with a high degree of confidence that any alterations in the data will be reflected in alterations in the digest 🧚 The MD5 algorithm itself is defined in [2]. This memo specifies how the algorithm may be used as an integrity check for MIME mail 💜

2. Generation of the Content-MD5 Field 🍓

Only an originating user agent generates the Content-MD5 field. Message relays and gateways are expressly forbidden from generating a Content-MD5 field, no exceptions 🚫

Use of the Content-MD5 field is completely optional, but its use is recommended whenever data integrity is desired and Privacy-Enhanced Mail services [3] are not available. (Consult Section 4 for further details.) The Content-MD5 field may only be added to MIME entities of a `leaf' nature. In other words, the Content-MD5 field may be used with any content type other than multipart or message/rfc822 ✨

To generate the value of the Content-MD5 field, the MD5 algorithm is computed on the canonical form of the MIME entity's object. Basically, the sender runs MD5 on the data right after it's converted to canonical form and before any content-transfer-encoding is applied. The receiver also runs MD5 on the canonical form, after undoing any content-transfer-encoding 🔄 For textual data, the MD5 algorithm must be computed on data in which the canonical form for newlines applies, meaning each newline is represented by a CR-LF pair. The canonical encoding model of MIME is described in Appendix G of [1] 📖

The output of the MD5 algorithm is a 128 bit digest. When viewed in network byte order (big-endian order), this gives a sequence of 16 octets of binary data. Those 16 octets are then encoded according to the base64 algorithm to get the value that goes in the Content-MD5 field. So if running MD5 over the raw data of a MIME entity gives a digest with the (unlikely) value of "Check Integrity!", then that entity's header could contain the field:

        Content-MD5:  Q2hlY2sgSW50ZWdyaXR5IQ==

Finally, as discussed in Appendix B of [1], textual data gets altered all the time during normal mail delivery 😭 Because adding or deleting trailing white space results in a different digest, either the quoted-printable or base64 algorithm should be employed as a content-transfer-encoding when the Content-MD5 field is used 🫶

3. Processing the Content-MD5 field 🔍

If the Content-MD5 field is present, a recipient user agent may choose to use it to verify that the contents of a MIME entity have not been modified during transport. Message relays and gateways are expressly forbidden to change their processing based on whether the Content-MD5 field is present 🙅‍♀️ However, a message gateway is allowed to remove the Content-MD5 field if the corresponding MIME entity is translated into a different content-type 🦋

4. Security Considerations 🔐

Okay, serious moment. This document specifies a data integrity service that protects data from accidental modification while it's in transit from the sender to the recipient. A secure data integrity service, such as the one provided by Privacy Enhanced Mail [3], is conjectured to protect data from all modifications. Conjectured means it's a hunch, not a proven fact 🙃

5. Acknowledgements 🫶

This memo is based almost entirely on text originally written by Nathaniel Borenstein of Bellcore. Several improvements were also suggested by Keith Moore of the University of Tennessee, Knoxville 🌈

6. References 📚

• [1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
• [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992.
• [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail, Part I: Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

7. Authors' Addresses 💌

John G. Myers Carnegie Mellon University EMail: jgm+@cmu.edu 🎓

Marshall T. Rose Dover Beach Consulting, Inc. EMail: mrose@dbc.mtview.ca.us 💜

That's the whole RFC, bestie! 🌈✨ Bye bye 💅