postfix-3.3.12

diff --git a/postfix/HISTORY b/postfix/HISTORY
index ecb2e65879d717e79196f1a85eec03a37271261e..7d0913bbd52ec9b9be2294b70c7c77bd8de3419a 100644 (file)
--- a/postfix/HISTORY
+++ b/postfix/HISTORY
@@ -23615,4 +23615,21 @@ 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
+       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 94bf4b1dc0947e873cc8e3a0eac86d37ab3ba195..daa3d24215a5387d34c1f7fef7634df00176d90f 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.3.11"
+#define MAIL_RELEASE_DATE      "20200627"
+#define MAIL_VERSION_NUMBER    "3.3.12"
 
 #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);
        }