postfix-3.4-20180422

postfix/HISTORY

@@ -23378,3 +23378,21 @@ Apologies for any names omitted.
 	properly terminate after "postfix stop". With assistance
 	from Andreas Schulze and Eray Aslan. Files: master/master.c,
 	master/master.h, master/master_sig.c.
+
+20180421
+
+	Documentation: in the protocol description mention early
+	on that a policy server must not close the connection unless
+	there is an error. File: proto/SMTPD_POLICY_README.html.
+
+20180422
+
+	Undocumented: when running in PID=1 mode on Linux, a signal
+	won't be delivered unless the process specifies a handler.
+	Conveniently, _exit() can be used directly as a signal
+	handler. This changes the wait status that a parent would
+	see, but in the case of PID=1 mode on Linux, no-one would
+	care. Viktor Dukhovni. File: util/killme_after.c.
+
+	Bugfix: missing error tls_server_start() error handling in
+	tlsproxy(8).  File: tlsproxy/tlsproxy.c.

postfix/README_FILES/SMTPD_POLICY_README

@@ -36,10 +36,14 @@ This document covers the following topics:
 
 PPrroottooccooll ddeessccrriippttiioonn
 
-The Postfix policy delegation protocol is really simple. The client request is
-a sequence of name=value attributes separated by newline, and is terminated by
-an empty line. The server reply is one name=value attribute and it, too, is
-terminated by an empty line.
+The Postfix policy delegation protocol is really simple. The client sends a
+request and the server sends a response. Unless there was an error, the server
+must not close the connection, so that the same connection can be used multiple
+times.
+
+The client request is a sequence of name=value attributes separated by newline,
+and is terminated by an empty line. The server reply is one name=value
+attribute and it, too, is terminated by an empty line.
 
 Here is an example of all the attributes that the Postfix SMTP server sends in
 a delegated SMTPD access policy request:

postfix/html/SMTPD_POLICY_README.html

@@ -65,11 +65,14 @@ multiple times, for up to $<a href="postconf.5.html#max_use">max_use</a> incomin
 
 <h2><a name="protocol">Protocol description</a></h2>
 
-<p> The Postfix policy delegation protocol is really simple. The
-client request is a sequence of name=value attributes separated by
-newline, and is terminated by an empty line. The server reply is
-one name=value attribute and it, too, is terminated by an empty
-line. </p>
+<p> The Postfix policy delegation protocol is really simple. The client
+sends a request and the server sends a response. Unless there was an
+error, the server must not close the connection, so that the same
+connection can be used multiple times. </p>
+
+<p> The client request is a sequence of name=value attributes separated
+by newline, and is terminated by an empty line. The server reply is one
+name=value attribute and it, too, is terminated by an empty line. </p>
 
 <p> Here is an example of all the attributes that the Postfix SMTP
 server sends in a delegated SMTPD access policy request: </p>

postfix/proto/SMTPD_POLICY_README.html

@@ -65,11 +65,14 @@ multiple times, for up to $max_use incoming SMTP connections. </p>
 
 <h2><a name="protocol">Protocol description</a></h2>
 
-<p> The Postfix policy delegation protocol is really simple. The
-client request is a sequence of name=value attributes separated by
-newline, and is terminated by an empty line. The server reply is
-one name=value attribute and it, too, is terminated by an empty
-line. </p>
+<p> The Postfix policy delegation protocol is really simple. The client
+sends a request and the server sends a response. Unless there was an
+error, the server must not close the connection, so that the same
+connection can be used multiple times. </p>
+
+<p> The client request is a sequence of name=value attributes separated
+by newline, and is terminated by an empty line. The server reply is one
+name=value attribute and it, too, is terminated by an empty line. </p>
 
 <p> Here is an example of all the attributes that the Postfix SMTP
 server sends in a delegated SMTPD access policy request: </p>

postfix/src/global/mail_version.h

@@ -20,7 +20,7 @@
   * Patches change both the patchlevel and the release date. Snapshots have no
   * patchlevel; they change the release date only.
   */
-#define MAIL_RELEASE_DATE	"20180404"
+#define MAIL_RELEASE_DATE	"20180422"
 #define MAIL_VERSION_NUMBER	"3.4"
 
 #ifdef SNAPSHOT

postfix/src/tls/tls_proxy_clnt.c

@@ -235,6 +235,8 @@ void    tls_proxy_context_free(TLS_SESS_STATE *tls_context)
 	myfree(tls_context->issuer_CN);
     if (tls_context->peer_cert_fprint)
 	myfree(tls_context->peer_cert_fprint);
+    if (tls_context->peer_pkey_fprint)
+	myfree(tls_context->peer_pkey_fprint);
     if (tls_context->protocol)
 	myfree((void *) tls_context->protocol);
     if (tls_context->cipher_name)

postfix/src/tlsproxy/tlsproxy.c

@@ -663,7 +663,7 @@ static void tlsp_ciphertext_event(int event, void *context)
 
 /* tlsp_start_tls - turn on TLS or force disconnect */
 
-static void tlsp_start_tls(TLSP_STATE *state)
+static int tlsp_start_tls(TLSP_STATE *state)
 {
     TLS_SERVER_START_PROPS props;
     static char *cipher_grade;
@@ -716,7 +716,7 @@ static void tlsp_start_tls(TLSP_STATE *state)
 
     if (state->tls_context == 0) {
 	tlsp_state_free(state);
-	return;
+	return (-1);
     }
 
     /*
@@ -729,6 +729,7 @@ static void tlsp_start_tls(TLSP_STATE *state)
      * XXX Do we care about certificate verification results? Not as long as
      * postscreen(8) doesn't actually receive email.
      */
+    return (0);
 }
 
 /* tlsp_get_fd_event - receive final postscreen(8) hand-off information */
@@ -776,7 +777,8 @@ static void tlsp_get_fd_event(int event, void *context)
      * Perform the TLS layer before-handshake initialization. We perform the
      * remainder after the TLS handshake completes.
      */
-    tlsp_start_tls(state);
+    if (tlsp_start_tls(state) < 0)
+	return;
 
     /*
      * Trigger the initial proxy server I/Os.

postfix/src/util/killme_after.c

@@ -46,11 +46,17 @@ void    killme_after(unsigned int seconds)
      * Schedule an ALARM signal, and make sure the signal will be delivered
      * even if we are being called from a signal handler and SIGALRM delivery
      * is blocked.
+     * 
+     * Undocumented: when running in "init" mode on Linux, the signal won't be
+     * delivered unless the process specifies a handler. Conveniently,
+     * _exit() can be used directly as a signal handler. This changes the
+     * wait status that a parent would see, but in the case of "init" mode on
+     * Linux, no-one would care.
      */
     alarm(0);
     sigemptyset(&sig_action.sa_mask);
     sig_action.sa_flags = 0;
-    sig_action.sa_handler = SIG_DFL;
+    sig_action.sa_handler = (getpid() == 1 ? _exit : SIG_DFL);
     sigaction(SIGALRM, &sig_action, (struct sigaction *) 0);
     alarm(seconds);
     sigaddset(&sig_action.sa_mask, SIGALRM);