https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8447
Bug ID: 8447
Summary: spamc using SSL gets no reply from spamd running on
Linux
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: spamc/spamd
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
Created attachment 6138
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=6138&action=edit
read client input before closing SSL connections; close_notify only for
compressed requests
Steps to reproduce:
Build with ENABLE_SSL=yes on Linux
make test TEST_FILES="t/spamd_ssl.t t/spamd_ssl_accept_fail.t"
Result: On Ubuntu 26.04 both tests fail every time; on other systems the
failure can be intermittent, as in bug 8068. spamd processes the message, but
spamc gets no reply and, without -x, passes the message through unscanned.
spamc -K and -L fail the same way. Compressed requests (-z) work.
Cause: Since the fix for bug 7183, spamc sends a TLS close_notify right after
its request. spamd stops reading at Content-length, so it closes the connection
with the close_notify unread, and Linux then resets the connection and drops
any part of the reply not yet sent. spamd on macOS is not affected. Compressed
requests work because spamd reads them to EOF, which reads the close_notify.
The attached patch changes both sides. spamd reads any input already waiting
before it closes an SSL connection, which also fixes existing 4.0.x spamc
clients. spamc sends the close_notify only for compressed requests, which is
what bug 7183 needed it for.
This is also the cause of the t/spamd_ssl_accept_fail.t failures in bug 8068.
--
You are receiving this mail because:
You are the assignee for the bug.
