Eightbit, eightnegotiate, eightstrict, sevenbit, utf8header, utf8negotiate, utf8strict Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

Eight bit SMTP capability and EAI capability (eightbit, eightnegotiate, eightstrict, sevenbit, utf8header, utf8negotiate, utf8strict)

Some transports restrict the use of characters with ordinal values greater than 127 (decimal). Most notably, some SMTP servers will strip the high bit and thus garble messages that use characters in this "eight bit" range. Indeed, there have even been past cases of SMTP servers which will crash when presented with eight bit data.

The MTA provides facilities to automatically encode such messages so that troublesome eight bit characters do not appear directly in the message. This encoding can be applied to all messages on a given channel by specifying the sevenbit channel option. A channel should be marked eightbit if no such restriction exists.

Some transports such as extended SMTP may actually support a form of negotiation to determine if eight bit characters can be transmitted. The eightnegotiate channel option can be used to instruct the channel to encode messages when negotiation fails. This is the default for all channels; channels that do not support negotiation will simply assume that the transport is capable of handling eight bit data.

The eightstrict source channel option tells the MTA to reject any messages that contain unnegotiated eight bit data; the exact text of this error may be controlled via the error_text_unnegotiated_eightbit MTA option. (Note that the timing of the rejection can be postponed via the acceptalladdresses channel option.)

The MS 8.0.2 release adds MTA support for EAI messages and the SMTPUTF8 extension. EAI messaging is documented in RFC 6530 (overview), RFC 6531 (SMTPUTF8 extension), RFC 6532 (header format changes), and RFC 6533 (DSN and MDN format changes). Three additional channel options have been added to enable and control EAI support:

As a SMTP source channel option, offer the SMTPUTF8 SMTP extension. As a destination channel option, allow enqueue and dequeue of EAI messages unconditionally; in particular, the SMTPUTF8 extension will not be required. Note that delivery of EAI messages via SMTP/LMTP to a non-EAI system is a standards violation.
As a SMTP source channel option, offer the SMTPUTF8 SMTP extension. As a destination channel option, allow enqueue unconditionally. On dequeue, require the SMTPUTF8 extension be offered by SMTP/LMTP servers for EAI messages with EAI recipient (RCPT TO) addresses or un-downgradable EAI originator (MAIL FROM) addresses.
Same as utf8negotiate as far as SMTP/LMTP destination channels are concerned. But additionally, for SMTP/LMTP servers (source channels), reject messages that contain 8bit headers without having negotiated the SMTPUTF8 extension and 8bit bodies without having negotiated the 8BITMIME extension. (Note that such rejections are postponed if the acceptalladdress channel option is used.)

As of MS the channel default for internal channels has changed from eightnegotiate to utf8always. Note, however, that the channel default remains eightnegotiate on all other channels; EAI support must therefore be explicitly enabled. A channel set to eightnegotiate will not offer the SMTPUTF8 extensions or allow EAI messages with EAI recipient or originator addresses to be enqueued. Also note that the Message Store does not support EAI at the present time.

See also: