Postfix SMTPUTF8 support


This document describes Postfix support for Email Address Internationalization (EAI) as defined in RFC 6531 (SMTPUTF8 extension), RFC 6532 (Internationalized email headers) and RFC 6533 (Internationalized delivery status notifications). Introduced with Postfix version 2.12, this fully supports UTF-8 email addresses and UTF-8 message header values.

Topics covered in this document:

Enabling Postfix SMTPUTF8 support

Before turning on SMTPUTF8 support in Postfix, you need to verify that the rest of your email infrastructure can handle UTF-8 email addresses and message header values, including SMTPUTF8 protocol support in SMTP-based content filters (Amavisd), LMTP servers (Dovecot), and down-stream SMTP servers.

SMTPUTF8 support is enabled by setting the smtputf8_enable parameter in

# postconf "smtputf8_enable = yes"
# postfix reload

With SMTPUTF8 support enabled, Postfix changes behavior as follows:

Postfix already permitted UTF-8 in message header values and in address localparts. This does not change.

Using Postfix SMTPUTF8 support

After Postfix SMTPUTF8 support is turned on, Postfix behavior will depend on 1) whether a remote SMTP client requests SMTPUTF8 support, 2) the presence of UTF-8 content in the message envelope and headers, and 3) whether a down-stream SMTP (or LMTP) server announces SMTPUTF8 support.

SMTPUTF8 autodetection

This section applies only to systems that have SMTPUTF8 support turned on (smtputf8_enable = yes).

For compatibility with pre-SMTPUTF8 environments, Postfix does not automatically set the "SMTPUTF8 requested" flag on messages from non-SMTPUTF8 clients that contain an UTF-8 header value or UTF-8 address localpart. This would make such messages undeliverable to non-SMTPUTF8 servers, and could be a barrier to SMTPUTF8 adoption.

By default, Postfix sets the "SMTPUTF8 requested" flag only on address verification probes and on Postfix sendmail submissions that contain UTF-8 in the sender address, UTF-8 in a recipient address, or UTF-8 in a message header value.

    smtputf8_autodetect_classes = sendmail, verify

However, if you have a non-ASCII myorigin or mydomain setting, or if you have a configuration that introduces UTF-8 addresses with virtual aliases, canonical mappings, or BCC mappings, then you may have to apply SMTPUTF8 autodetection to all email:

    smtputf8_autodetect_classes = all

This will, of course, also flag email that was received without SMTPUTF8 request, but that contains UTF-8 in a sender address localpart, receiver address localpart, or message header value. Such email was not standards-compliant, but Postfix would have delivered it if SMTPUTF8 support was disabled.

Limitations of the current implementation

"Internationalized" domain names can appear in two forms: the UTF-8 form, and the ASCII (xn--mumble) form. The initial Postfix SMTPUTF8 implementation performs no automatic conversions on UTF8 strings beyond what is needed to perform DNS lookups.

No characterset canonicalization for non-ASCII domain names.

Postfix currently does not translate domain names from UTF-8 into ASCII (or ASCII into UTF-8) before looking up the domain name in mydestination, relay_domains, access tables, etc., before logging the domain name, or before using the domain name in a policy daemon or Milter request. You will have to configure both UTF-8 and ASCII forms in Postfix configuration files; and both forms will have to be handled by logfile tools, policy daemons and Milters.

No case canonicalization for non-ASCII characters.

Postfix currently does not case-fold non-ASCII characters when looking up an "Internationalized" domain name in mydestination, relay_domains, access maps, etc. Some non-ASCII scripts do not distinguish between upper and lower case, some have different numbers of upper and lower case characters.

Compatibility with pre-SMTPUTF8 environments

Mailing lists with UTF-8 and non-UTF-8 subscribers

With Postfix, there is no need to split mailing lists into UTF-8 and non-UTF-8 members. Postfix will try to deliver the non-UTF8 subscribers over "traditional" non-SMTPUTF8 sessions, as long as the message has an ASCII envelope sender address and all-ASCII header values. The mailing list manager will have to apply RFC 2047 encoding to satisfy that last condition.

Pre-existing non-ASCII email flows

In pre-SMTPUTF8 environments, email with UTF-8 in address localparts (and in headers) works just fine. The vast majority of email software including Postfix is perfectly capable of handling such email, even if pre-SMTPUTF8 standards do not support this.

Therefore, when Postfix SMTPUTF8 support is turned on, Postfix must not suddenly start to break pre-existing email flows with UTF-8 in addres localparts (and in headers).

Thus, Postfix continues to permit UTF-8 in address localparts (and in headers) in email from and to pre-SMTPUTF8 systems. At least, that is the default (see autodetection above).

Building with/without SMTPUTF8 support

Postfix SMTPUTF8 support requires the ICU library. Postfix automatically builds with SMTPUTF8 support when the library and its header files are installed. To force Postfix to build without SMTPUTF8, specify:

$ make makefiles -DNO_EAI ...