SMTP Service Extension for 8-bit MIME Transport
Extracted elements (16)
The 8BITMIME extension enables transfer of MIME content with 8BIT content-transfer-encoding but explicitly does NOT provide a means of transferring content with the BINARY content-transfer-encoding, because line length restrictions still apply.
The extension does not eliminate the server's right to limit line length; servers may still enforce a limit as low as 1000 octets. This deliberate constraint keeps the extension scoped to 8-bit text rather than arbitrary binary.
A client SMTP must issue EHLO and check for the 8BITMIME keyword in the server's 250 response before using BODY=8BITMIME. If the server does not advertise the capability, 8-bit content must not be sent.
This extension provides facilities for transferring a MIME object with 8BIT content-transfer-encoding, but is incompatible with BINARY content-transfer-encoding, which requires a separate SMTP extension (BINARYMIME).
A server SMTP supporting the 8-bit MIME transport service extension shall preserve all bits in each octet passed using the DATA command.
Any 8-bit to 7-bit gateway transformation must cause no loss of information (MIME transport encodings must be employed as needed) and the resulting message must be valid 7-bit MIME.
If a server SMTP does not support 8BITMIME (no 250 to EHLO or keyword absent), then the client SMTP must not, under any circumstances, attempt to transfer content containing octets outside the US-ASCII range (hex 00-7F).
Line length limits still apply even with 8BITMIME: servers are free to set a line length limit no lower than 1000 octets (inclusive of the CR-LF pair) per line.
Once a server SMTP accepting 8-bit content receives it, it must deliver or relay the content in such a way as to preserve all bits in each octet.
The standard SMTP data-stuffing algorithm still applies: sequences <CR><LF><DOT><CR><LF> or <DOT><CR><LF> at the start must be handled to avoid premature termination of 8-bit content transfer.
When a client cannot send 8-bit content to a non-8BITMIME server, it must either convert the message to valid 7-bit MIME with no loss of information, or treat the barrier as a permanent error and handle it as a delivery failure.
The 8bit-MIMEtransport SMTP service extension is identified by the EHLO keyword 8BITMIME. No parameters are used with the EHLO keyword itself; the extension adds an optional BODY parameter to the MAIL command.
The BODY parameter added to the MAIL command takes the value 'body-value = "7BIT" / "8BITMIME"', indicating whether the content body is strict 7-bit or MIME with arbitrary octet content.
IANA has updated the 8BITMIME entry in the SMTP Service Extensions registry with keyword '8BITMIME', description 'SMTP and Submit transport of 8-bit MIME content', and reference RFC 6152.
The 8BITMIME extension is not believed to raise any security issues beyond those already present in RFC 5321-conforming SMTP implementations. Since MIME semantics are transport-neutral, 8BITMIME provides no more capability to disseminate malware than unextended 7-bit SMTP.
The MAIL command is extended with a BODY esmtp-keyword parameter. Only one BODY parameter may be used per MAIL command; the esmtp-value is either 7BIT or 8BITMIME. Syntax defined via ABNF per RFC 5234.