postfix-3.2.17

diff --git a/postfix/HISTORY b/postfix/HISTORY
index 707bad4b7c5b73d23bffab763547f6e119b83c6f..1b905bb061e5e7cbc9d13fe30b530a1e0bdf3805 100644 (file)
--- a/postfix/HISTORY
+++ b/postfix/HISTORY
@@ -23326,3 +23326,20 @@ Apologies for any names omitted.
        Bugfix (introduced: Postfix 3.1): "postfix tls deploy-server-cert"
        did not handle a missing optional argument. File:
        conf/postfix-tls-script.
+
+20200626
+
+       Bugfix (introduced: Postfix 2.11): The Postfix smtp(8)
+       client did not send the right SNI name when the TLSA base
+       domain was a secure CNAME expansion of the MX hostname (or
+       non-MX nexthop domain). Domains with CNAME expanded MX hosts
+       are not conformant with RFC5321, and so are rare. Even more
+       rare are MX hosts with TLSA records for their CNAME expansion.
+       For this to matter, the remote SMTP server would also have
+       to select its certificate based on the SNI name in such a
+       way that the original MX host would yield a different
+       certificate. Among the ~2 million hosts in the DANE survey,
+       none meet the conditions for returning a different certificate
+       for the expanded CNAME. Therefore, sending the correct SNI
+       name should not break existing mail flows. Fixed by Viktor
+       Dukhovni. File: src/tls/tls_client.c.

diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h
index ca30ebb27220868fab21e7bed6b479966b58ed3f..d8cece3faa628d08827cd39343b51e6333a60544 100644 (file)
--- a/postfix/src/global/mail_version.h
+++ b/postfix/src/global/mail_version.h
@@ -20,8 +20,8 @@
   * Patches change both the patchlevel and the release date. Snapshots have no
   * patchlevel; they change the release date only.
   */
-#define MAIL_RELEASE_DATE      "20200614"
-#define MAIL_VERSION_NUMBER    "3.2.16"
+#define MAIL_RELEASE_DATE      "20200627"
+#define MAIL_VERSION_NUMBER    "3.2.17"
 
 #ifdef SNAPSHOT
 #define MAIL_VERSION_DATE      "-" MAIL_RELEASE_DATE

diff --git a/postfix/src/tls/tls_client.c b/postfix/src/tls/tls_client.c
index 6bc1c3acd0f8fb4e5536bc548b56f9cb98a1cb66..72f90090c372f5d22dd2af0d0b4361984cdb7497 100644 (file)
--- a/postfix/src/tls/tls_client.c
+++ b/postfix/src/tls/tls_client.c
@@ -973,6 +973,7 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
 #ifdef TLSEXT_MAXLEN_host_name
     if (TLS_DANE_BASED(props->tls_level)
        && strlen(props->host) <= TLSEXT_MAXLEN_host_name) {
+       const char *sni;
 
        /*
         * With DANE sessions, send an SNI hint.  We don't care whether the
@@ -984,15 +985,19 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
         * avoid SNI, and there are no plans to support SNI in the Postfix
         * SMTP server).
         * 
+        * Per RFC7672, the required SNI name is the TLSA "base domain" (the one
+        * used to construct the "_25._tcp.<fqdn>" TLSA record DNS query).
+        * 
         * Since the hostname is DNSSEC-validated, it must be a DNS FQDN and
         * thererefore valid for use with SNI.  Failure to set a valid SNI
         * hostname is a memory allocation error, and thus transient.  Since
         * we must not cache the session if we failed to send the SNI name,
         * we have little choice but to abort.
         */
-       if (!SSL_set_tlsext_host_name(TLScontext->con, props->host)) {
+       sni = props->dane->base_domain;
+       if (!SSL_set_tlsext_host_name(TLScontext->con, sni)) {
            msg_warn("%s: error setting SNI hostname to: %s", props->namaddr,
-                    props->host);
+                    sni);
            tls_free_context(TLScontext);
            return (0);
        }