Loading ...
Sorry, an error occurred while loading the content.

301033Postfix SMTPUTF8 support (unicode email addresses)

Expand Messages
  • Wietse Venema
    Jul 15, 2014
    • 0 Attachment
      Proudly presenting Postfix SMTPUTF8 support! Below is text from
      the RELEASE_NOTES file for postfix-2.12-20140715, to be uploaded
      later today.

      Wietse

      Major changes with snapshot 20140715
      ====================================

      Support for Internationalized Email, also known as EAI or SMTPUTF8,
      defined in RFC 6530..6533. This supports UTF8 in SMTP/LMTP sender
      addresses, recipient addresses, and message header values. The
      implementation is based on initial work by Arnt Gulbrandsen that
      was funded by CNNIC.

      This text describes:
      - Compatibility with pre-SMTPUTF8 environments,
      - How to enable SMTPUTF8 support,
      - How to use SMTPUTF8 support,
      - SMTPUTF8 autodetection,
      - Limitations of the current implementation.

      Compatibility with pre-SMTPUTF8 environments
      --------------------------------------------

      Mailing list friendliness

      In the future, mailing lists will have a mix of UTF8 and non-UTF8
      subscribers. With Postfix, there is no need to split the lists
      into UTF8 and non-UTF8 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 may have to apply RFC
      2047 encoding to satisfy the second condition).

      Pre-existing non-ASCII mail flows

      In pre-SMTPUTF8 environments, mail with UTF8 in address localparts
      (and in headers) works just fine because the vast majority of mail
      software including Postfix is perfectly capable of handling such
      mail, 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 mail flows with UTF8 in
      addres localparts (and in headers).

      Thus, Postfix continues to permit UTF8 in address localparts (and
      in headers) in mail from and to pre-SMTPUTF8 systems. At least,
      that is the default.

      Enabling Postfix SMTPUTF8 support
      ---------------------------------

      By default, SMTPUTF8 support is disabled, and Postfix should work
      exactly as it has worked before.

      SMTPUTF8 support is enabled by setting in main.cf:

      smtputf8_enable = yes

      and by issuing the "postfix reload" command.

      With SMTPUTF8 support enabled, Postfix changes behavior as follows:

      - The Postfix SMTP server announces SMTPUTF8 support in the EHLO
      response.

      250-hostname.example.com
      250-PIPELINING
      250-SIZE 10240000
      250-VRFY
      250-ETRN
      250-STARTTLS
      250-AUTH PLAIN LOGIN
      250-ENHANCEDSTATUSCODES
      250-8BITMIME
      250-DSN
      250 SMTPUTF8

      - The Postfix SMTP server accepts the SMTPUTF8 request in MAIL FROM
      and VRFY commands.

      MAIL FROM:<address> SMTPUTF8
      VRFY address SMTPUTF8

      - The Postfix SMTP client may issue the SMTPUTF8 request in MAIL FROM
      commands.

      - UTF8 is supported anywhere in an email address, not just silently
      permitted in the localpart, but only after the client issues MAIL
      FROM or VRFY as shown above.

      - UTF8 was already silently permitted in message header values.

      SMTP-based content filters (Amavisd) and LMTP servers (Dovecot)
      will need to be updated to support SMTPUTF8. A notice has been
      sent to the respective maintainers.

      Using Postfix SMTPUTF8 support
      ------------------------------

      - When the Postfix SMTP server receives a message WITHOUT the
      SMTPUTF8 request, Postfix handles the message as it has always
      done (at least that is the default, see autodetection below).
      Specifically, the Postfix SMTP server does not accept UTF8 in the
      envelope sender domain name or envelope recipient domain name,
      and the Postfix SMTP client does not issue the SMTPUTF8 request
      when delivering that message an SMTP or LMTP server that announces
      SMTPUTF8 support (again, that is the default).

      - When the Postfix SMTP server receives a message WITH the SMTPUTF8
      request, Postfix will issue the SMTPUTF8 request when delivering
      that message to an SMTP or LMTP server that announces SMTPUTF8
      support. This is not configurable.

      - When a message is received with the SMTPUTF8 request, Postfix
      will deliver the message to a non-SMTPUTF8 server ONLY if:

      - No message header value contains UTF8.

      - The envelope sender address contains no UTF8,

      - No envelope recipient address for that specific SMTP/LMTP
      delivery transaction contains UTF8.

      NOTE: Recipients in other mail delivery transactions for
      that same message may still contain UTF8.

      Otherwise, Postfix will return the recipient(s) for that mail
      delivery transaction as undeliverable. The delivery status
      notification message will be subject to the same restrictions
      as mail that is received with the SMTPUTF8 request.

      - When the Postfix SMTP server receives a message with the SMTPUTF8
      request, that request also applies after the message is forwarded
      via a virtual or local alias, or $HOME/.forward file.

      SMTPUTF8 autodetection
      ----------------------

      By default, Postfix sets the "SMTPUTF8 requested" bit on address
      verification probes and on Postfix sendmail submissions that contain
      UTF8 in the sender address, UTF8 in a recipient address, or UTF8
      in a message header value.

      smtputf8_autodetect_classes = sendmail, verify

      This will suffice for the vast majority of sites. It minimizes the
      chances of accidentally setting the "SMTPUTF8 requested" bit on a
      message from a non-SMTPUTF8 client, thereby making that message
      undeliverable to a non-SMTPUTF8 server as discussed above. Remember,
      once a message is flagged as "SMTPUTF8 requested", the Postfix SMTP
      client may not be able to deliver it to a non-SMTPUTF8 server.

      However, if you have a non-ASCII myorigin or mydomain setting, or
      if you have virtual aliases, canonical mappings, or BCC mappings
      that introduce UTF8 addresses, then you may have to apply SMTPUTF8
      autodetection to all mail:

      smtputf8_autodetect_classes = all

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

      Limitations of Postfix SMTPUTF8 support
      ---------------------------------------

      "Internationalized" domain names can appear in two forms: the UTF8
      form, and the ASCII (xn--mumble) form.

      No characterset canonicalization for non-ASCII domain names.

      Postfix currently does not translate domain names from UTF8 into
      ASCII (or ASCII into UTF8) 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 UTF8 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, and reportedly some even have
      title case in addition to upper and lower case (at this time it
      is unclear if those will ever be used in email addresses, though).