Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]
Replaces RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1342: Representation of Non-ASCII Text in Internet Message Headers, RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1590: Media Type Registration Procedure.
This document is current and has been amended. 4 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
What it is
The first MIME document: Content-Type, Content-Transfer-Encoding and the header fields that let a message carry something other than plain ASCII text.
What it solves
A message was a single block of 7-bit text. No attachments, no character sets, no alternative representations.
What it means to operate
Content-Transfer-Encoding is where DKIM signatures die. Any hop that re-encodes a body, quoted-printable to base64 or the reverse, changes the bytes the signature covers. If DKIM fails only for some recipients, look for a gateway doing conversion before you look at your keys.
Header analyser parses a real message and says what each header is claiming. Open header analyser
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
4 MIME-Version Header Field
- MUSTMessages composed in accordance with this document MUST include such a header field, with the following verbatim text:
6.7 Quoted-Printable Content-Transfer-Encoding
- MAY(2) (Literal representation) Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the US-ASCII characters which correspond to those octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN through TILDE, respectively).
- MAY(3) (White Space) Octets with values of 9 and 32 MAY be represented as US-ASCII TAB (HT) and SPACE characters,
- MUST NOTrespectively, but MUST NOT be so represented at the end of an encoded line.
- MUSTAny TAB (HT) or SPACE characters on an encoded line MUST thus be followed on that line by a printable character.
- MUST NOTtransport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports.