On Fri, Aug 30, 2024 at 03:49:33PM -0400, Wietse Venema via Postfix-users wrote:
> BDAT is different than other SMTP commands: the client sends a byte
> count for the amount of data that follows the command, and Postfix
> will not reply until it has received the number of bytes in the
> BDAT command. If that number is somehow made larger in transit,
> or if some data bytes are lost in transit, then the BDAT command
> will time out.
I rather expect the problem was at the TCP layer, perhaps a bug
similar to:
https://bugzilla.redhat.com/show_bug.cgi?id=191336
https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/
...
> This session was using TLS, therefore it is unlikely that the bits
> were changed after encryption in the SMTP client and before decryption
> in the SMTP server (TLS has stronger integrity guarantees than TCP
> checksums). It could however be a problem in data compression before
> encryption or decompression after decryption. One could work around
> that with "tls_ssl_options = NO_COMPRESSION".
IIRC hasn't supported TLS compression for quite some time.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
