RFC 1544

RFC 1544: The Content-MD5 Header Field 💖

okay bestie, this one is a Standards Track doc from November 1993 🦋 It was written by Marshall T. Rose of Dover Beach Consulting, Inc. The title block doesn't list anything it obsoletes or updates, so it's flying solo 💅

• RFC number: 1544
• Title: The Content-MD5 Header Field
• Author: Marshall T. Rose, Dover Beach Consulting, Inc.
• Category: Standards Track
• Date: November 1993
• Obsoletes / Updates: none listed in the title block

---

Status of This Memo 📜

this is a standards track protocol for the Internet community, and it's looking for discussion and suggestions for improvements 🗣️ for the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔍 distribution of this memo is unlimited 🌈

Abstract 🌸

this memo introduces an optional header field 🎀, Content-MD5, for use with MIME-conformant messages.

Table of Contents 🗂️

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

1. Introduction ✨

okay so even with all the protections MIME [1] gives email to stop data from getting damaged in transport 🫠, it's still super useful to have a way to check that the data, once decoded, is still intact 🔍 that's why this memo defines 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.

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 show up as alterations in the digest. the MD5 algorithm itself is defined in [2]. this memo spells out how the algorithm may be used as an integrity check for MIME mail 💜

2. Generation of the Content-MD5 Field 🍓

the Content-MD5 field is generated by only an originating user agent 🙅‍♀️ message relays and gateways are expressly forbidden from generating a Content-MD5 field 💀

using the Content-MD5 field is completely optional 🌸 but its use is recommended whenever data integrity is desired, but 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, i.e., 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 data 🎀 in particular, this means that the sender applies the MD5 algorithm on the raw data, before applying any content-transfer-encoding, and that the receiver also applies the MD5 algorithm on the raw data, 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, that is, in which each newline is represented by a CR-LF pair 🫶

the output of the MD5 algorithm is a 128 bit digest. when it's viewed in network byte order (big-endian order), that 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 the application of the MD5 algorithm over the raw data of a MIME entity results in a digest with the (unlikely) value of "Check Integrity!" 🙈 then that MIME entity's header could contain the field:

               Content-MD5:  Q2hlY2sgSW50ZWdyaXR5IQ==

finally, as discussed in Appendix B of [1], textual data is regularly altered in the normal delivery of mail 😭 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 alter their processing based on the presence of the Content-MD5 field. 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 🚨

🚨 bestie, this part is serious! this document specifies a data integrity service that protects data from accidental modification while 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.

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. Author's Address 🦋

   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA 94043-2112

   Phone: (415) 968-1052
   EMail: mrose@dbc.mtview.ca.us

that's the whole thing bestie, periodt 🌈💅