PATCH: multiple deliveries per TLS-encrypted connection

[Wietse Venema]

Wietse Venema:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. This is not to be confused with closing a connection
> and reusing some TLS state in a new connection.

Below is a tiny patch for tlsproxy. After the remote TLS peer shuts
down TLS, the patch allows unsent inbound plaintext to trickle out
before tlsproxy tears down the proxied connection.

This addresses a sporadic "lost connection after end-of-data" error
in the Postfix SMTP client, and addresses a sporadic "lost connection
after sending QUIT" error with "posttls-finger -X".

Also released as postfix-3.4-20180618.

Wietse

diff -cr /var/tmp/postfix-3.4-20180617/src/tlsproxy/tlsproxy.c 
./src/tlsproxy/tlsproxy.c
*** /var/tmp/postfix-3.4-20180617/src/tlsproxy/tlsproxy.c   2018-06-17 
12:35:21.0 -0400
--- ./src/tlsproxy/tlsproxy.c   2018-06-18 19:36:32.0 -0400
***
*** 474,479 
--- 474,485 
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);
  }

Re: available: multiple deliveries per TLS-encrypted connection

[@lbutlr]

On 18 Jun 2018, at 12:08, Wietse Venema  wrote:
> Wuetse

Ah, Mondays!


-- 
Is it my imagination, or do buffalo wings taste like chicken?

Re: available: multiple deliveries per TLS-encrypted connection

[Wietse Venema]

Wietse Venema:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. This is not to be confused with closing a connection
> and reusing some TLS state in a new connection.

BTW this is also called 'connection pooling'. There's a mailgun
blog that discusses how they cut their SMTP-over-TLS delivery times
in half by 'pooling' TLS connections.

Wuetse

Re: available: multiple deliveries per TLS-encrypted connection

[Wietse Venema]

Ralf Hildebrandt:
> * Wietse Venema :
> > Postfix snapshot 20180617, released a few minutes ago, introduces
> > Postfix SMTP client support for multiple deliveries per TLS-encrypted
> > connection. 
> 
> Testing here.

Thanks! I have done tests with mumble_destination_concurrency_limit=1
to force connection reuse without having to queue up a lot of messages.

You can also test interoperability with "posttls-finger -X" (had to
pick a letter that was not already in use :-).

Wietse

Re: available: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Wietse Venema :
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. 

Testing here.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: spamming mailbox ?

[Poliman - Serwis]

Thank you Tom for answer. For me is quite strange, because
do_not_re...@s1.poliman.net is my mailbox. I didn't send any email to
emailemailemailemailemailem...@emailemailemail.com. Btw, how do you know
that receiving server does not exists - due to failing connection on 25
port?

2018-06-15 9:37 GMT+02:00 Tom Hendrikx :

>
>
> On 14-06-18 15:27, Poliman - Serwis wrote:
> > I check the mail queue and the logs and this time I found some strange
> > thing. I used command "grep -r "emailemailemail.com
> > " /var/log/mail.log" and result is in
> > attached .txt file. If I understand properly there is many tries to send
> > from do_not_re...@s1.poliman.net  to
> > emailemailemailemailemailem...@emailemailemail.com
> >  but nothing
> > happens later because of failing connection to emailemailemail.com
> >  on port 25.
> >
>
> Yes, that are many attempts to deliver the same email. Because the
> receiving server does not exist, the message is kept in the queue and
> retried later.
>
> This is easily visible because all log messages show the same queue id
> (9438613CE9E). This will continue until maximal_queue_lifetime (default
> 5d) is reached.
>
> Kind regards,
> Tom
>



-- 

*Pozdrawiam / Best Regards*
*Piotr Bracha*