Adding upstream version 3.5.24.upstream/3.5.24

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 294 insertions, 0 deletions

diff --git a/README_FILES/SMTPUTF8_README b/README_FILES/SMTPUTF8_README
new file mode 100644
index 0000000..5496a3b
--- /dev/null
+++ b/README_FILES/SMTPUTF8_README
@@ -0,0 +1,294 @@
+ PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+-------------------------------------------------------------------------------
+
+OOvveerrvviieeww
+
+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 3.0, this fully supports UTF-8 email addresses
+and UTF-8 message header values.
+
+Topics covered in this document:
+
+  * Building with/without SMTPUTF8 support
+  * Enabling Postfix SMTPUTF8 support
+  * Using Postfix SMTPUTF8 support
+  * SMTPUTF8 autodetection
+  * Limitations of the current implementation
+  * Compatibility with pre-SMTPUTF8 environments
+  * Compatibility with IDNA2003
+  * Credits
+
+BBuuiillddiinngg PPoossttffiixx wwiitthh//wwiitthhoouutt SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+Postfix will build with SMTPUTF8 support if the ICU version >= 46 library and
+header files are installed on the system. The package name varies with the OS
+distribution. The table shows package names for a number of platforms at the
+time this text was written.
+
+     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
+    |OOSS DDiissttrriibbuuttiioonn      |PPaacckkaaggee     |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |FreeBSD, NetBSD, etc.|icu         |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Centos, Fedora, RHEL |libicu-devel|
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+    |Debian, Ubuntu       |libicu-dev  |
+    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ |
+
+To force Postfix to build without SMTPUTF8, specify:
+
+    $ mmaakkee mmaakkeeffiilleess CCCCAARRGGSS==""--DDNNOO__EEAAII ......""
+
+See the INSTALL document for more "make makefiles" options.
+
+EEnnaabblliinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+There is more to SMTPUTF8 than just Postfix itself. The rest of your email
+infrastructure also needs to be able to handle UTF-8 email addresses and
+message header values. This includes SMTPUTF8 protocol support in SMTP-based
+content filters (Amavisd), LMTP servers (Dovecot), and down-stream SMTP
+servers.
+
+Postfix SMTPUTF8 support is enabled by default, but it may be disabled as part
+of a backwards-compatibility safety net (see the COMPATIBILITY_README file).
+
+SMTPUTF8 support is enabled by setting the smtputf8_enable parameter in
+main.cf:
+
+    # ppoossttccoonnff ""ssmmttppuuttff88__eennaabbllee == yyeess""
+    # ppoossttffiixx rreellooaadd
+
+(With Postfix <= 3.1, you may also need to specify "ooppttiioonn__ggrroouupp == cclliieenntt" in
+Postfix MySQL client files, to enable UTF8 support in MySQL queries. This
+setting is the default as of Postfix 3.2.)
+
+With SMTPUTF8 support enabled, Postfix changes behavior with respect to earlier
+Postfix releases:
+
+  * UTF-8 is permitted in the myorigin parameter value. However, the myhostname
+    and mydomain parameters must currently specify ASCII-only domain names.
+    This limitation may be removed later.
+
+  * UTF-8 is the only form of non-ASCII text that Postfix supports in access
+    tables, address rewriting tables, and other tables that are indexed with an
+    email address, hostname, or domain name.
+
+  * The header_checks-like and body_checks-like features are not UTF-8 enabled,
+    and therefore they do not enforce UTF-8 syntax rules on inputs and outputs.
+    The reason is that non-ASCII text may be sent in encodings other than UTF-
+    8, and that real email sometimes contains malformed headers. Instead of
+    skipping non-UTF-8 content, Postfix should be able to filter it. You may
+    try to enable UTF-8 processing by starting a PCRE pattern with the sequence
+    (*UTF8), but this is will result in "message not accepted, try again later"
+    errors when the PCRE pattern matcher encounters non-UTF-8 input. Other
+    features that are not UTF-8 enabled are smtpd_command_filter,
+    smtp_reply_filter, the *_delivery_status_filter features, and the
+    *_dns_reply_filter features (the latter because DNS is by definition an
+    ASCII protocol).
+
+  * The Postfix SMTP server announces SMTPUTF8 support in the EHLO response.
+
+    220 server.example.com ESMTP Postfix
+    EEHHLLOO cclliieenntt..eexxaammppllee..ccoomm
+    250-server.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.
+
+    MMAAIILL FFRROOMM::<<aaddddrreessss>> SSMMTTPPUUTTFF88 ......
+
+    VVRRFFYY aaddddrreessss SSMMTTPPUUTTFF88
+
+  * The Postfix SMTP client may issue the SMTPUTF8 request in MAIL FROM
+    commands.
+
+  * The Postfix SMTP server accepts UTF-8 in email address domains, but only
+    after the remote SMTP client issues the SMTPUTF8 request in MAIL FROM or
+    VRFY commands.
+
+Postfix already permitted UTF-8 in message header values and in address
+localparts. This does not change.
+
+UUssiinngg PPoossttffiixx SSMMTTPPUUTTFF88 ssuuppppoorrtt
+
+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.
+
+  * 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 UTF-8 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 to an SMTP or LMTP server
+    that announces SMTPUTF8 support (again, that is the default). Postfix will
+    accept UTF-8 in message header values and in the localpart of envelope
+    sender and recipient addresses, because it has always done that.
+
+  * 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 SMTP or LMTP server ONLY if:
+
+      o No message header value contains UTF-8.
+
+      o The envelope sender address contains no UTF-8,
+
+      o No envelope recipient address for that specific SMTP/LMTP delivery
+        transaction contains UTF-8.
+
+            NOTE: Recipients in other email delivery transactions for that same
+            message may still contain UTF-8.
+
+    Otherwise, Postfix will return the recipient(s) for that email delivery
+    transaction as undeliverable. The delivery status notification message will
+    be an SMTPUTF8 message. It will therefore be subject to the same
+    restrictions as email 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.
+
+SSMMTTPPUUTTFF88 aauuttooddeetteeccttiioonn
+
+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.
+
+    /etc/postfix/main.cf:
+        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:
+
+    /etc/postfix/main.cf:
+        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.
+
+LLiimmiittaattiioonnss ooff tthhee ccuurrrreenntt iimmpplleemmeennttaattiioonn
+
+The Postfix implementation is a work in progress; limitations are steadily
+being removed. The text below describes the situation at one point in time.
+
+NNoo aauuttoommaattiicc ccoonnvveerrssiioonnss bbeettwweeeenn AASSCCIIII aanndd UUTTFF--88 ddoommaaiinn nnaammeess..
+
+Some background: According to RFC 6530 and related documents, an
+internationalized domain name can appear in two forms: the UTF-8 form, and the
+ASCII (xn--mumble) form. An internationalized address localpart must be encoded
+in UTF-8; the RFCs do not define an ASCII alternative form.
+
+Postfix currently does not convert internationalized domain names from UTF-
+8 into ASCII (or from ASCII into UTF-8) before using domain names in SMTP
+commands and responses, before looking up domain names in lists such as
+mydestination, relay_domains or in lookup tables such as access tables, etc.,
+before using domain names in a policy daemon or Milter request, or before
+logging events.
+
+Postfix does, however, casefold domain names and email addresses before
+matching them against a Postfix configuration parameter or lookup table.
+
+In order to use Postfix SMTPUTF8 support:
+
+  * The Postfix parameters myhostname and mydomain must be in ASCII form. One
+    is a substring of the other, and the myhostname value is used in SMTP
+    commands and responses that require ASCII. The parameter myorigin (added to
+    local addresses without domain) supports UTF-8.
+
+  * You need to configure both the ASCII and UTF-8 forms of an
+    Internationalized domain name in Postfix parameters such as mydestination
+    and relay_domains, as well as lookup table search keys.
+
+  * Milters, content filters, policy servers and logfile analysis tools need to
+    be able to handle both the ASCII and UTF-8 forms of Internationalized
+    domain names.
+
+CCoommppaattiibbiilliittyy wwiitthh pprree--SSMMTTPPUUTTFF88 eennvviirroonnmmeennttss
+
+MMaaiilliinngg lliissttss wwiitthh UUTTFF--88 aanndd nnoonn--UUTTFF--88 ssuubbssccrriibbeerrss
+
+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
+may have to apply RFC 2047 encoding to satisfy that last condition.
+
+PPrree--eexxiissttiinngg nnoonn--AASSCCIIII eemmaaiill fflloowwss
+
+With "smtputf8_enable = no", Postfix handles email with non-ASCII in address
+localparts (and in headers) as before. The vast majority of email software is
+perfectly capable of handling such email, even if pre-SMTPUTF8 standards do not
+support such practice.
+
+RReejjeeccttiinngg nnoonn--UUTTFF88 aaddddrreesssseess
+
+With "smtputf8_enable = yes", Postfix requires that non-ASCII address
+information is encoded in UTF-8 and will reject other encodings such as ISO-
+8859. It is not practical for Postfix to support multiple encodings at the same
+time. There is no problem with RFC 2047 encodings such as "=?ISO-8859-
+1?Q?text?=", because those use only characters from the ASCII characterset.
+
+RReejjeeccttiinngg nnoonn--AASSCCIIII aaddddrreesssseess iinn nnoonn--SSMMTTPPUUTTFF88 ttrraannssaaccttiioonnss
+
+Setting "strict_smtputf8 = yes" in addition to "smtputf8_enable = yes" will
+enable stricter enforcement of the SMTPUTF8 protocol. Specifically, the Postfix
+SMTP server will not only reject non-UTF8 sender or recipient addresses, it
+will in addition accept UTF-8 sender or recipient addresses only when the
+client requests an SMTPUTF8 mail transaction.
+
+CCoommppaattiibbiilliittyy wwiitthh IIDDNNAA22000033
+
+Postfix >= 3.2 by default disables the 'transitional' compatibility between
+IDNA2003 and IDNA2008, when converting UTF-8 domain names to/from the ASCII
+form that is used in DNS lookups. This makes Postfix behavior consistent with
+current versions of the Firefox and Chrome web browsers. Specify
+"enable_idna2003_compatibility = yes" to get the historical behavior.
+
+This affects the conversion of domain names that contain for example the German
+sz (ß) and the Greek zeta (ς). See http://unicode.org/cldr/utility/idna.jsp
+for more examples.
+
+CCrreeddiittss
+
+  * May 15, 2014: Arnt Gulbrandsen posted his patch for Unicode email support.
+    This work was sponsored by CNNIC.
+
+  * July 15, 2014: Wietse integrated Arnt Gulbrandsen's code and released
+    Postfix with SMTPUTF8 support.
+
+  * January 2015: Wietse added UTF-8 support for casefolding in Postfix lookup
+    tables and caseless string comparison in Postfix list-based features.
+