Users send billions of 8-bit messages every year. As far as I know, all servers can handle 8-bit messages. A few years ago I was able to find a few hosts running ancient 7-bit versions of sendmail, but I don't see any now.

Most clients will send 8-bit messages upon request. This is the behavior of qmail, for example, and exim, and sendmail, starting from version 6.57 in 1993.

Exception: sendmail, starting from version 8.7 in 1995, applies Q-P conversion to an 8-bit message if the message contains MIME header fields, the 8 flag (popular in Europe but not the default) is not set, and the SMTP server has not taken the protective measures described below.

Q-P conversion has mixed results. It eliminates message corruption in the rare case that the server is a 7-bit server and the recipient's mailer supports MIME. However, it creates new message corruption in the much more common case that the server is an 8-bit server and the recipient's mailer does not support MIME.

The 8BITMIME extension has two effects in practice:

• The client will avoid Q-P conversion.
• The client may add extra information at the end of a MAIL request: a space followed by either "BODY=7BIT" or "BODY=8BITMIME".

Recommendations for 8-bit support

7-bit mailers are obsolete. Do not attempt to deploy a 7-bit mailer on the Internet. The fact that you are complying with IETF standards is irrelevant; users will not tolerate a 7-bit mailer.

Do not implement Q-P conversion in an SMTP client. You will find that simply sending an 8-bit message is much more successful than attempting Q-P conversion, whether or not the server announces 8BITMIME.

Announce 8BITMIME in your server, to prevent Q-P conversion from sendmail without the 8 flag. Ignore the BODY information.

SIZE

--The SIZE extension has two purposes:

• To give the server an estimate of the size of a message before the message is transmitted.
• To warn the client that messages above a certain size will not be accepted.

The claimed benefit is an occasional large reduction in SMTP traffic. Beware, however, that using SIZE also means a persistent small expansion in SMTP traffic. Measurements at several hosts have found that the expansion outweighs the reduction.

The SIZE extension has at most one argument. If the argument is supplied, it consists entirely of ASCII digits, giving a number n. If n is nonzero, the server is indicating that it will reject messages containing more than n bytes (counting two bytes per line for \015\012).

Whether or not an argument is supplied, the SIZE extension has the following meaning. During this connection, the client may send the following string, between 7 and 26 characters, as extra information at the end of a MAIL request:

1. a space;
2. the word SIZE;
3. an equals sign;
4. between 1 and 20 ASCII digits, giving a number.

The number is an estimate, usually but not necessarily an overestimate, of the total number of bytes in the message.

ETRN

--The parameter to an ETRN request is normally a domain name.

If the server accepts the request, it will schedule deliveries to that domain for the next convenient moment. Note that this does not guarantee any particular time. The server can use code 250, 251, 252, or 253. 251 guarantees that there are no deliveries waiting for the domain. 252 and 253 guarantee that there are deliveries waiting.

The parameter may instead be a domain name preceded by an @; this refers to the domain and all its subdomains. Or the parameter may start with an #; in this case the interpretation is server-defined.

There is an ETRN extension, with no arguments allowed, that promises support for the ETRN verb. I don't know whether ETRN-using clients pay attention to this extension.

ENHANCEDSTATUSCODES

--The Enhanced-Status-Codes service extension Servers supporting the Enhanced-Status-Codes extension must preface the text part of almost all response lines with a status code. As in RFC 1893, the syntax of these status codes is given by the ABNF: status-code ::= class "." subject "." detail class ::= "2" / "4" / "5" subject ::= 1*3digit detail ::= 1*3digit These codes must appear in all 2xx, 4xx, and 5xx response lines other than initial greeting and any response to HELO or EHLO. Note that 3xx responses are NOT included in this list. All status codes returned by the server must agree with the primary response code, that is, a 2xx response must incorporate a 2.X.X code, a 4xx response must incorporate a 4.X.X code, and a 5xx response must incorporate a 5.X.X code.