On 2022-02-03 14:21:58 +0100, Marc Haber wrote: > Is the bug repeatable by unfreezing the message and forcing a delivery > attempt? If so, you might be able to get a core dump from the delivering > exim.
The delivery was successful. There was still a "TLS error on connection (recv): The TLS connection was non-properly terminated." error, but no 450: 2022-02-02 13:42:28 Start queue run: pid=150965 -qff 2022-02-02 13:42:28 1nEt2b-0008jG-97 Unfrozen by forced delivery 2022-02-02 13:42:31 1nEt2b-0008jG-97 H=mx1.mailchannels.net [54.189.39.249] TLS error on connection (recv): The TLS connection was non-properly terminated. 2022-02-02 13:42:31 1nEt2b-0008jG-97 => xxx@yyy R=dnslookup T=remote_smtp H=mx1.mailchannels.net [54.189.39.249] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=yes DN="CN=*.mailchannels.net" C="250 2.0.0 Ok: queued as 6D9D5201EF" 2022-02-02 13:42:31 1nEt2b-0008jG-97 Completed 2022-02-02 13:42:31 End queue run: pid=150965 -qff > If the 450 is casued by greylisting on the remote side, that debugging > attempt must be close to the first time of sending the message so that > the 450 is still there. Unfortunately, I can't control that. Perhaps the bug is due to the combination of both a "TLS error on connection (recv): The TLS connection was non-properly terminated." error and a 450, e.g. in case exim does something valid only if there were no errors. A potential security issue? If I understand correctly, the error comes from record_io_error(state, (int)inbytes, US"recv", NULL); in src/tls-gnu.c, tls_read(). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
