Summary

  • 8BITMIME let an SMTP client declare that a MIME body contains high-bit octets, but only after the receiving server advertised that capability for the current hop.
  • Acceptance imposed bit-preserving custody; a relay facing a non-capable next hop had to create lossless valid 7-bit MIME or fail, while DATA framing and line limits still ruled out arbitrary binary.

The message and the road were different contracts

MIME gave email a vocabulary for media types, character sets and transfer encodings. That solved a description problem: a message could say what its body meant and how its representation should be decoded. It did not by itself widen the road over which SMTP carried the message.

The old road was seven-bit. RFC 2045 distinguishes 7bit, 8bit and binary transport domains. A body containing an accented letter may be perfectly meaningful MIME and still contain octets whose high bit the next SMTP relay has never promised to preserve. Content identity and transport permission are separate facts.

This is why the history of 8BITMIME is not merely the history of non-English email. It is the history of locating responsibility. Instead of hoping that every machine on an unknown route tolerated eight-bit data, sender and receiver created a narrow contract on each connection.

Three documents stabilized one small promise

RFC 1426 published the 8bit-MIMEtransport extension in February 1993. RFC 1652 replaced it in July 1994. RFC 6152 replaced RFC 1652 in March 2011 and remains the registered specification. The sequence records revision without turning documentary age into evidence of current deployment.

The mechanism stayed deliberately compact. A server adds 8BITMIME to a successful EHLO response. The IANA SMTP Service Extensions registry records the keyword, gives it no EHLO parameter and points to RFC 6152. No new SMTP verb appears.

The client adds one optional parameter to MAIL FROM: BODY=7BIT or BODY=8BITMIME. That parameter tells the receiver about the octet domain of the content body that will follow. It does not name a language, character set, media type or application. A UTF-8 text part and an eight-bit image encoding are not made semantically equivalent because both encounter a high bit.

Advertisement came before permission

A client wishing to send an eight-bit MIME body must first issue EHLO. Only a successful 250 response containing 8BITMIME authorizes the extended MAIL FROM declaration and the later high-bit body on that connection.

Absence is meaningful. If the server does not answer EHLO successfully, or answers without the keyword, the client must not send octets outside the US-ASCII range. Tolerance cannot be inferred from a previous session, a product name or the fact that TCP itself transports arbitrary bytes. The relevant evidence is the current peer's current advertisement.

This is local authority, not global certification. A receiving relay may advertise 8BITMIME and accept the body even though its own next hop will not. The first promise binds the first transfer. It does not speak for machines that were not parties to it.

Acceptance created custody of every bit

Once a supporting server accepts the eight-bit body, RFC 6152 requires it to preserve all bits in every octet passed through DATA. Delivery or onward relay must also preserve them. The keyword is therefore more than a parsing hint. It is an operational undertaking not to shave away the high bit at an internal boundary.

That duty reaches through implementation seams. A queue writer, content scanner, spool format or relay process cannot silently normalize the body merely because the SMTP front end advertised capability. Running code must uphold the promise across the entire custody path covered by that server.

The obligation is exact but narrow. It does not authenticate the sender or prove the content is safe. It does not guarantee that a recipient application understands the declared charset. It proves only that this SMTP participant accepted responsibility for the octets under the negotiated transport rules.

Eight-bit was not binary

The name invites an overclaim. 8BITMIME does not turn DATA into an arbitrary-octet tunnel. Ordinary SMTP dot transparency still applies: a line containing only a dot terminates DATA, and line-leading dots are doubled for transport. The CRLF before the final dot remains part of the content.

Line limits survive too. RFC 6152 notes that a server may impose a limit as low as 1,000 octets including CRLF on one line. MIME 8bit data still has lines; MIME binary permits byte sequences that need not. Because the extension preserves SMTP's line grammar, it supports 8bit content-transfer-encoding but not binary.

This boundary keeps several histories separate. MIME names and encodes content. Dot transparency protects an in-band terminator. 8BITMIME widens the allowed value of an octet while leaving the line-oriented carrier intact. CHUNKING and BINARYMIME later address a different framing problem.

The next hop could reopen the problem

Suppose relay A accepts BODY=8BITMIME, stores the message intact and then connects to relay B. If B does not advertise 8BITMIME, A cannot simply send the body and hope. RFC 6152 leaves two choices.

The relay may transform the message into valid 7-bit MIME. That conversion must lose no information and may use MIME transfer encodings such as quoted-printable or base64 where appropriate. Or the relay may treat the barrier as a permanent delivery error.

The standard deliberately does not prescribe the transformation. That restraint matters because conversion is not a neutral byte shuffle. Headers, multipart boundaries, canonical line endings and transfer-encoding labels must remain coherent. A transformation that changes reader-visible content, corrupts a signature or produces invalid MIME has not satisfied the lossless rule merely because every output byte is seven-bit.

Failure can therefore be the more honest outcome when a trustworthy transformation is unavailable. The common contract states the boundary; it does not force every operator to run the same gateway.

A declaration was evidence, not truth by magic

BODY=8BITMIME is supplied by the client. The server can use it to select a capable path or reject an unsupported domain early, but the parameter does not relieve the receiver of observing what arrives. Nor does BODY=7BIT make an arbitrary malformed body safe. Protocol declarations organize responsibility; they do not suspend verification.

Operators need two distinct records: what the peer advertised and what the sender declared. Add the measured body domain and the action at the next-hop boundary, and the route becomes explainable. Without that ledger, a corrupted character at the destination cannot be separated from a sender error, an unsafe downgrade, an internal eight-bit stripping fault or a rendering problem.

The lesson is recognizably larger than mail. Extension negotiation is useful when it limits who has promised what. It becomes dangerous when a local capability token is treated as an end-to-end property.

Sources and limits

The documentary line runs from RFC 1426 through RFC 1652 to RFC 6152. RFC 2045 supplies the MIME transport-domain distinction, and the IANA SMTP registry supplies the current keyword record. These sources define protocol behavior and history. They do not measure modern adoption, vendor defaults, message volume or downgrade frequency.