tlsproxy failed / flooded log

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

tlsproxy failed / flooded log

A. Schulze

Hello,

today I enabled smtp_tls_connection_reuse on some production server.
after approx. an hour and ~70 reused SMTP connections, tlsproxy on two  
machines logged this:

...
Sep  6 09:03:52 idvmailout03 postfix/tlsproxy[18637]: DISCONNECT  
[213.23.92.204]:25
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:1409F07F:SSL routines:ssl3_write_pending:bad  
write retry:ssl/record/rec_layer_s3.c:1131:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
...

...
Sep  6 09:03:47 idvmailout04 postfix/tlsproxy[22852]: DISCONNECT  
[77.75.78.42]:25
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:1409F07F:SSL routines:ssl3_write_pending:bad  
write retry:ssl/record/rec_layer_s3.c:1131:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
...

that continue until the logfile occupied all diskspace with up to 15k  
lines per second


After I enabled smtp_tls_connection_reuse, there was only one tlsproxy process

Sep  6 08:26:21 idvmailout04 postfix/tlsproxy[21687]: CONNECT to  
[80.67.18.126]:25
Sep  6 08:28:19 idvmailout04 postfix/tlsproxy[21687]: DISCONNECT  
[193.158.9.202]:25

Sep  6 08:28:25 idvmailout04 postfix/tlsproxy[21832]: CONNECT to  
[176.9.125.207]:25
Sep  6 08:31:19 idvmailout04 postfix/tlsproxy[21832]: DISCONNECT  
[64.233.166.27]:25


but very fast postfix begun to spawn two instances overlapping


Sep  6 08:30:43 idvmailout04 postfix/tlsproxy[21961]: CONNECT to  
[104.47.4.36]:25
Sep  6 08:32:05 idvmailout04 postfix/tlsproxy[21961]: DISCONNECT  
[193.143.77.14]:25

Sep  6 08:31:25 idvmailout04 postfix/tlsproxy[22024]: CONNECT to  
[194.8.120.225]:25
Sep  6 08:32:48 idvmailout04 postfix/tlsproxy[22024]: DISCONNECT  
[185.15.192.56]:25

Sep  6 08:32:55 idvmailout04 postfix/tlsproxy[22075]: CONNECT to  
[95.130.253.60]:25
Sep  6 08:36:18 idvmailout04 postfix/tlsproxy[22075]: DISCONNECT  
[91.220.42.201]:25

these are the nondefault options for tlsproxy
tls_high_cipherlist =  
HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA
tls_medium_cipherlist = aNULL:-aNULL:CHACHA20:HIGH:MEDIUM:+RC4:@STRENGTH
tls_preempt_cipherlist = yes

interesting:
# postconf tls_fast_shutdown_enable
postconf: warning: tls_fast_shutdown_enable: unknown parameter

http://www.postfix.org/postconf.5.html#tls_fast_shutdown_enable say  
nothing about a specific postfix version number is required for this  
parameter
but http://www.postfix.org/tlsproxy.8.html do say,  
tls_fast_shutdown_enable is available in 3.4.6
also, it' a very new feature:  
http://www.postfix.org/announcements/postfix-3.4.6.html

# postconf mail_version
mail_version = 3.4.6

A grep in the source also found "tls_fast_shutdown" without "_enable"

# postconf tls_fast_shutdown
tls_fast_shutdown = yes

Looks, like the documentation is incorrect. But may that be related to  
the problem?
postconf -Mf and postfonf -f attached.
Just disabled smtp_tls_connection_reuse again...

Andreas

postconf_Mf.txt (1K) Download Attachment
postconf_n.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Wietse Venema
A. Schulze:

>
> Hello,
>
> today I enabled smtp_tls_connection_reuse on some production server.
> after approx. an hour and ~70 reused SMTP connections, tlsproxy on two  
> machines logged this:
>
> ...
> Sep  6 09:03:52 idvmailout03 postfix/tlsproxy[18637]: DISCONNECT  
> [213.23.92.204]:25
> Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
> library problem: error:1409F07F:SSL routines:ssl3_write_pending:bad  
> write retry:ssl/record/rec_layer_s3.c:1131:
> Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
> library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
> while in init:ssl/ssl_lib.c:2077:
> Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
> library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
> while in init:ssl/ssl_lib.c:2077:
> Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
> library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
> while in init:ssl/ssl_lib.c:2077:

Any particular Postfix and OpenSSL version?

Does setting tls_fast_shutdown_enable (or tls_fast_shutdown)
make a difference?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

A. Schulze


Am 06.09.19 um 14:24 schrieb Wietse Venema:

Hello Wietse!

> Any particular Postfix and OpenSSL version?
postfix-3.4.6
openssl-1.1.1c

> Does setting tls_fast_shutdown_enable (or tls_fast_shutdown)
> make a difference?
I could set tls_fast_shutdown = no and try again.
Unfortunately that mean I risk an outage on a production system.

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Wietse Venema
A. Schulze:

>
>
> Am 06.09.19 um 14:24 schrieb Wietse Venema:
>
> Hello Wietse!
>
> > Any particular Postfix and OpenSSL version?
> postfix-3.4.6
> openssl-1.1.1c
>
> > Does setting tls_fast_shutdown_enable (or tls_fast_shutdown)
> > make a difference?
> I could set tls_fast_shutdown = no and try again.
> Unfortunately that mean I risk an outage on a production system.

To avoid disruption:

postconf smtp_tls_connection_reuse=no
postfix reload
then kill the errant postscreen process by hand.

The SMTP clients should automatically reconnect to an alternate MX.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Wietse Venema
Wietse Venema:

> A. Schulze:
> >
> >
> > Am 06.09.19 um 14:24 schrieb Wietse Venema:
> >
> > Hello Wietse!
> >
> > > Any particular Postfix and OpenSSL version?
> > postfix-3.4.6
> > openssl-1.1.1c
> >
> > > Does setting tls_fast_shutdown_enable (or tls_fast_shutdown)
> > > make a difference?
> > I could set tls_fast_shutdown = no and try again.
> > Unfortunately that mean I risk an outage on a production system.
>
> To avoid disruption:
>
> postconf smtp_tls_connection_reuse=no
> postfix reload
> then kill the errant postscreen process by hand.
>
> The SMTP clients should automatically reconnect to an alternate MX.

Forget that. The tlsproxy daemon does not use the code that
implements tls_fast_shutdown_enable/tls_fast_shutdown.

In fact the tlsproxy daemon never invokes SSL_shutdown(), except
when there is an I/O error on the plaintext connection between
Postfix SMTP client and tlsproxy process, AFTER the TLS handshake
has completed.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Viktor Dukhovni
On Fri, Sep 06, 2019 at 11:03:16AM -0400, Wietse Venema wrote:

> Forget that. The tlsproxy daemon does not use the code that
> implements tls_fast_shutdown_enable/tls_fast_shutdown.
>
> In fact the tlsproxy daemon never invokes SSL_shutdown(), except
> when there is an I/O error on the plaintext connection between
> Postfix SMTP client and tlsproxy process, AFTER the TLS handshake
> has completed.

However, perhaps the code below (which I don't yet properly understand)
can loop retrying the shutdown, because `SSL_shutdown()` of an SSL
handle that is not established returns `SSL_ERROR_SSL` when the
connection is not in an established state, but `tlsp_eval_tls_error()`
does not clean up when

    state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf)

is true, perhaps leaving the shutdown to be retried somehow?

    src/tlsproxy/tlsproxy.c:tlsp_strategy()

        plaintext_buf = state->plaintext_buf;
        if (NBBIO_ERROR_FLAGS(plaintext_buf)) {
            if (NBBIO_ACTIVE_FLAGS(plaintext_buf))
                nbbio_disable_readwrite(state->plaintext_buf);
            ssl_stat = SSL_shutdown(tls_context->con);
            /* XXX Wait for return value 1 if sessions are to be reused? */
            if (ssl_stat < 0) {
                handshake_err = SSL_get_error(tls_context->con, ssl_stat);
                tlsp_eval_tls_error(state, handshake_err);
                /* At this point, state could be a dangling pointer. */
                return;
            }
            tlsp_state_free(state);
            return;
        }

    src/tlsproxy/tlsproxy.c:tlsp_eval_tls_error()

            /*
             * Some error. Self-destruct. This automagically cleans up all
             * pending read/write and timeout event requests, making state a
             * dangling pointer.
             */
        case SSL_ERROR_SSL:
            tls_print_errors();
            /* FALLTHROUGH */
        default:

            /*
             * Allow buffered-up plaintext output to trickle out.
             */
            if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
                return (TLSP_STAT_OK);
            tlsp_state_free(state);
            return (TLSP_STAT_ERR);

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Wietse Venema
Viktor Dukhovni:

> On Fri, Sep 06, 2019 at 11:03:16AM -0400, Wietse Venema wrote:
>
> > Forget that. The tlsproxy daemon does not use the code that
> > implements tls_fast_shutdown_enable/tls_fast_shutdown.
> >
> > In fact the tlsproxy daemon never invokes SSL_shutdown(), except
> > when there is an I/O error on the plaintext connection between
> > Postfix SMTP client and tlsproxy process, AFTER the TLS handshake
> > has completed.
>
> However, perhaps the code below (which I don't yet properly understand)
> can loop retrying the shutdown, because `SSL_shutdown()` of an SSL
> handle that is not established returns `SSL_ERROR_SSL` when the
> connection is not in an established state, but `tlsp_eval_tls_error()`
> does not clean up when
>
>     state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf)

state->plaintext_buf is NULL until after the SSL handshake completes.

SSL_shutdown(), see below. is called ONLY AFTER state->plaintext_buf
I/O error. But state->plaintext_buf is null until the handshake is
completed.

OpenSSL may enter the init state later, during session
renegotiation. How would we detect that?

        Wietse

> is true, perhaps leaving the shutdown to be retried somehow?
>
>     src/tlsproxy/tlsproxy.c:tlsp_strategy()
>
> plaintext_buf = state->plaintext_buf;
> if (NBBIO_ERROR_FLAGS(plaintext_buf)) {
>    if (NBBIO_ACTIVE_FLAGS(plaintext_buf))
> nbbio_disable_readwrite(state->plaintext_buf);
>    ssl_stat = SSL_shutdown(tls_context->con);
>    /* XXX Wait for return value 1 if sessions are to be reused? */
>    if (ssl_stat < 0) {
> handshake_err = SSL_get_error(tls_context->con, ssl_stat);
> tlsp_eval_tls_error(state, handshake_err);
> /* At this point, state could be a dangling pointer. */
> return;
>    }
>    tlsp_state_free(state);
>    return;
> }
>
>     src/tlsproxy/tlsproxy.c:tlsp_eval_tls_error()
>
>    /*
>     * Some error. Self-destruct. This automagically cleans up all
>     * pending read/write and timeout event requests, making state a
>     * dangling pointer.
>     */
> case SSL_ERROR_SSL:
>    tls_print_errors();
>    /* FALLTHROUGH */
> default:
>
>    /*
>     * Allow buffered-up plaintext output to trickle out.
>     */
>    if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
> return (TLSP_STAT_OK);
>    tlsp_state_free(state);
>    return (TLSP_STAT_ERR);
>
> --
> Viktor.
>
Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Viktor Dukhovni
> On Sep 6, 2019, at 11:39 AM, Wietse Venema <[hidden email]> wrote:
>
> SSL_shutdown(), see below. is called ONLY AFTER state->plaintext_buf
> I/O error. But state->plaintext_buf is null until the handshake is
> completed.
>
> OpenSSL may enter the init state later, during session
> renegotiation. How would we detect that?

  SSL_IN_INIT(1)

       SSL_in_init() returns 1 if the SSL/TLS state machine is currently
       processing or awaiting handshake messages, or 0 otherwise.

       SSL_in_before() returns 1 if no SSL/TLS handshake has yet been
       initiated, or 0 otherwise.

       SSL_is_init_finished() returns 1 if the SSL/TLS connection is in a
       state where fully protected application data can be transferred or 0
       otherwise.

       Note that in some circumstances (such as when early data is being
       transferred) SSL_in_init(), SSL_in_before() and SSL_is_init_finished()
       can all return 0.

       SSL_in_connect_init() returns 1 if s is acting as a client and
       SSL_in_init() would return 1, or 0 otherwise.

       SSL_in_accept_init() returns 1 if s is acting as a server and
       SSL_in_init() would return 1, or 0 otherwise.

       SSL_in_connect_init() and SSL_in_accept_init() are implemented as
       macros.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: tlsproxy failed / flooded log

Wietse Venema
Viktor Dukhovni:

> > On Sep 6, 2019, at 11:39 AM, Wietse Venema <[hidden email]> wrote:
> >
> > SSL_shutdown(), see below. is called ONLY AFTER state->plaintext_buf
> > I/O error. But state->plaintext_buf is null until the handshake is
> > completed.
> >
> > OpenSSL may enter the init state later, during session
> > renegotiation. How would we detect that?
>
>   SSL_IN_INIT(1)
>
>        SSL_in_init() returns 1 if the SSL/TLS state machine is currently
>        processing or awaiting handshake messages, or 0 otherwise.

Right. It queries a flag that is set on-the-fly during session
renegotiation.

My next post will have a small patch to stop whitewashing SSL errors
in tlsp_eval_tls_error() after SSL_Shutdown() is called.  If that
takes care of the problem then we can avoid tracking OpenSSL internal
state in tlsproxy.

        Wietse
Reply | Threaded
Open this post in threaded view
|

PATCH: tlsproxy failed / flooded log

Wietse Venema
To enable SMTP/TLS connection reuse on a running system:

    postconf smtp_tls_connection_reuse=yes
    postfix reload

To disable SMTP/TLS connection reuse on a running system:

    postconf smtp_tls_connection_reuse=no
    postfix reload (this also flushes the connection cache)
    manually kill any looping tlsproxy process

Unfortunately, already running SMTP client processes will keep using
"smtp_tls_connection_reuse=yes" and talk to tlsproxy until they
have exhausted alternate MXes (subject to smtp_mx_address_limit and
smtp_mx_session_limit). But the odds of the problem returning will
be small.

        Wietse

20190906

        Bugfix: don't whitewash OpenSSL errors after the plaintext
        channel is disabled, to avoid looping on "shutdown while
        in init" errors. File: tlsproxy/tlsproxy.c.

diff --exclude=man --exclude=html --exclude=README_FILES --exclude=INSTALL --exclude=.indent.pro --exclude=Makefile.in -r -ur /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c ./src/tlsproxy/tlsproxy.c
--- /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c 2019-07-23 18:54:20.000000000 -0400
+++ ./src/tlsproxy/tlsproxy.c 2019-09-06 12:12:27.000000000 -0400
@@ -678,7 +678,8 @@
  /*
  * Allow buffered-up plaintext output to trickle out.
  */
- if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
+ if (state->plaintext_buf && NBBIO_ACTIVE_FLAGS(state->plaintext_buf)
+    && NBBIO_WRITE_PEND(state->plaintext_buf))
     return (TLSP_STAT_OK);
  tlsp_state_free(state);
  return (TLSP_STAT_ERR);
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: tlsproxy failed / flooded log

A. Schulze
Am 06.09.19 um 18:30 schrieb Wietse Venema:

> To enable SMTP/TLS connection reuse on a running system:
>
>     postconf smtp_tls_connection_reuse=yes
>     postfix reload
>
> To disable SMTP/TLS connection reuse on a running system:
>
>     postconf smtp_tls_connection_reuse=no
>     postfix reload (this also flushes the connection cache)
>     manually kill any looping tlsproxy process
>
> Unfortunately, already running SMTP client processes will keep using
> "smtp_tls_connection_reuse=yes" and talk to tlsproxy until they
> have exhausted alternate MXes (subject to smtp_mx_address_limit and
> smtp_mx_session_limit). But the odds of the problem returning will
> be small.
>
> Wietse
>
> 20190906
>
> Bugfix: don't whitewash OpenSSL errors after the plaintext
> channel is disabled, to avoid looping on "shutdown while
> in init" errors. File: tlsproxy/tlsproxy.c.
>
> diff --exclude=man --exclude=html --exclude=README_FILES --exclude=INSTALL --exclude=.indent.pro --exclude=Makefile.in -r -ur /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c ./src/tlsproxy/tlsproxy.c
> --- /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c 2019-07-23 18:54:20.000000000 -0400
> +++ ./src/tlsproxy/tlsproxy.c 2019-09-06 12:12:27.000000000 -0400
> @@ -678,7 +678,8 @@
>   /*
>   * Allow buffered-up plaintext output to trickle out.
>   */
> - if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
> + if (state->plaintext_buf && NBBIO_ACTIVE_FLAGS(state->plaintext_buf)
> +    && NBBIO_WRITE_PEND(state->plaintext_buf))
>      return (TLSP_STAT_OK);
>   tlsp_state_free(state);
>   return (TLSP_STAT_ERR);
>

Hello Wietse,

thanks for you effort. I'll deploy a patched version in my lab environment
and update the production systems next week. Hopefully I could report "works well" some days later.

nice weekend!
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: tlsproxy failed / flooded log

Wietse Venema
This is an updated version of the patch for Postfix 3.4 and 3.5
that addresses two different tlsproxy problems. I've been running
this code since Friday; it is part of today's Postfix 3.5 snapshot.

The longer-term solution is to allow plaintext output to drain
without having code to whitewash OpenSSL error results. But that
change is too invasive for a stable release.

        Wietse

To enable SMTP/TLS connection reuse on a running system:

    postconf smtp_tls_connection_reuse=yes
    postfix reload

To disable SMTP/TLS connection reuse on a running system:

    postconf smtp_tls_connection_reuse=no
    postfix reload (this also flushes the connection cache)
    manually kill any looping tlsproxy process

Unfortunately, already running SMTP client processes will keep using
"smtp_tls_connection_reuse=yes" and will keep using tlsproxy until
they have exhausted smtp_mx_address_limit or smtp_mx_session_limit.
But the odds of the problem returning will be small.

20190906

        Bugfix (introduced: Postfix 3.4): don't whitewash OpenSSL
        error results after a plaintext output error. The code could
        loop, and with some OpenSSL error results could flood the
        log with error messages (see below for a specific case).
        Problem reported by Andreas Schulze. File: tlsproxy/tlsproxy.c.

        Bitrot: don't invoke SSL_shutdown() when the SSL engine
        thinks it is processing a handshake. As of OpenSSL 1.something
        this returns SSL_ERROR_SSL instead of SSL_ERROR_NONE. File:
        tlsproxy/tlsproxy.c.

diff --exclude=man --exclude=html --exclude=README_FILES --exclude=INSTALL --exclude=.indent.pro --exclude=Makefile.in -r -ur /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c ./src/tlsproxy/tlsproxy.c
--- /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c 2019-07-23 18:54:20.000000000 -0400
+++ ./src/tlsproxy/tlsproxy.c 2019-09-06 17:32:36.000000000 -0400
@@ -678,7 +678,8 @@
  /*
  * Allow buffered-up plaintext output to trickle out.
  */
- if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
+ if (state->plaintext_buf && !NBBIO_ERROR_FLAGS(state->plaintext_buf)
+    && NBBIO_WRITE_PEND(state->plaintext_buf))
     return (TLSP_STAT_OK);
  tlsp_state_free(state);
  return (TLSP_STAT_ERR);
@@ -784,9 +785,8 @@
     if (NBBIO_ERROR_FLAGS(plaintext_buf)) {
  if (NBBIO_ACTIVE_FLAGS(plaintext_buf))
     nbbio_disable_readwrite(state->plaintext_buf);
- ssl_stat = SSL_shutdown(tls_context->con);
- /* XXX Wait for return value 1 if sessions are to be reused? */
- if (ssl_stat < 0) {
+ if (!SSL_in_init(tls_context->con)
+    && (ssl_stat = SSL_shutdown(tls_context->con)) < 0) {
     handshake_err = SSL_get_error(tls_context->con, ssl_stat);
     tlsp_eval_tls_error(state, handshake_err);
     /* At this point, state could be a dangling pointer. */
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: tlsproxy failed / flooded log (WORKS)

A. Schulze
In reply to this post by A. Schulze


Am 06.09.19 um 20:50 schrieb A. Schulze:
> Hopefully I could report "works well" some days later.

Hello,

The patched version run here on some production server for a week without issues.
So here is the promised "works well" :-)

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: tlsproxy failed / flooded log (WORKS)

Wietse Venema
A. Schulze:
>
>
> Am 06.09.19 um 20:50 schrieb A. Schulze:
> > Hopefully I could report "works well" some days later.
>
> Hello,
>
> The patched version run here on some production server for a week
> without issues.  So here is the promised "works well" :-)

Thanks for testing this.

In the mean time I have been working on an updated patch that also
stops making OpenSSL calls after tlsproxy detects EOF or error on
a ciptertext stream, before allowing its plaintext output buffer
to drain. This refinement would reduce some residual logfile noise.

The change works as expected, and it is be small enough that it
can be adopted in the stable 3.4 release. I'll expose it first
in a 3.5 snapshot, and update Postfix 3.4 in a week.

        Wietse