SMTP Service Extension for 8bit-MIMEtransport
obsoleted by
- rfc-1652 — SMTP Service Extension for 8bit-MIMEtransport
Extracted elements (13)
A client with a non-supporting server has two options: implement a gateway transformation to valid 7-bit MIME (losslessly, using MIME encodings), or treat the situation as a permanent error and handle it via normal delivery failure mechanisms. The RFC deliberately leaves the specific transformation unspecified while constraining its properties.
The extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement 8BITMIME but still set a line length limit no lower than 1000 octets. This preserves backward compatibility with existing line-length constraints.
This extension is defined within the SMTP Service Extensions framework (RFC 1425). A server not responding with 250 to EHLO, or not including '8BITMIME' in the EHLO response, is treated as not supporting this extension, and the client must fall back to 7-bit operation.
A client SMTP wishing to submit 8-bit MIME content MUST first issue EHLO to the server and verify the server responds with 250 and includes the '8BITMIME' keyword before sending a BODY=8BITMIME parameter on MAIL FROM.
A server SMTP supporting the 8-bit MIME transport extension shall preserve all bits in each octet passed using the DATA command.
Although 8-bit content bodies are permitted, the length of each line (number of octets between two CR-LF pairs) is still subject to SMTP server line length restrictions, which may allow as few as 1000 octets on a single line.
If a server SMTP does not support the 8-bit MIME transport extension, then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US ASCII octet range (hex 00-7F).
Once a server SMTP accepts a content body containing octets with the high-order (8th) bit set, the server SMTP must deliver or relay the content in such a way as to preserve all bits in each octet.
When a client converts 8-bit MIME to 7-bit MIME for a non-supporting server, the conversion must cause no loss of information (using MIME transport encodings as needed), and the resulting message must be valid 7-bit MIME.
The extension is named '8bit-MIMEtransport' and its EHLO keyword is '8BITMIME'. No parameter is used with the EHLO keyword itself. The extension adds one optional BODY parameter to the MAIL FROM command.
The usual SMTP data-stuffing algorithm still applies to 8-bit content: a sequence <CR><LF><DOT><CR><LF> or content beginning with <DOT><CR><LF> would prematurely terminate transfer, so stuffing must be performed. The CR-LF pair immediately preceding the final dot is part of the content.
RFC 1426 does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of RFC 821 (SMTP).
The BODY parameter value for the extended MAIL FROM command is defined as: body-value ::= "7BIT" / "8BITMIME". '8BITMIME' indicates a MIME message with arbitrary octet-aligned content; '7BIT' indicates strict 7-bit ASCII content.