Prereq: "3.3.11"
diff -ur --new-file /var/tmp/postfix-3.3.11/src/global/mail_version.h ./src/global/mail_version.h
--- /var/tmp/postfix-3.3.11/src/global/mail_version.h	2020-06-14 16:42:58.000000000 -0400
+++ ./src/global/mail_version.h	2020-06-27 17:25:03.000000000 -0400
@@ -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 -ur --new-file /var/tmp/postfix-3.3.11/HISTORY ./HISTORY
--- /var/tmp/postfix-3.3.11/HISTORY	2020-05-31 15:47:35.000000000 -0400
+++ ./HISTORY	2020-06-27 17:17:21.000000000 -0400
@@ -23615,4 +23615,21 @@
 
 	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 -ur --new-file /var/tmp/postfix-3.3.11/src/tls/tls_client.c ./src/tls/tls_client.c
--- /var/tmp/postfix-3.3.11/src/tls/tls_client.c	2018-11-17 17:33:15.000000000 -0500
+++ ./src/tls/tls_client.c	2020-06-27 17:17:26.000000000 -0400
@@ -973,6 +973,7 @@
 #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 @@
 	 * 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);
 	}