Bug 7938 - spamd with SSL will wait for newline in body before responding
Summary: spamd with SSL will wait for newline in body before responding
Status: RESOLVED INVALID
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC Linux
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-25 00:31 UTC by Michael Caley
Modified: 2022-01-14 22:29 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Caley 2021-10-25 00:31:02 UTC
When spamd is running with SSL it will hang expecting a newline character at the end of the body. If the client closes the connection, the logs says it finishes processing the message.

I started the server with:
spamd --ssl --port 11783 --server-cert ./private_key_and_cert.pem --server-key ./private_key_and_cert.pem --timeout-tcp=30 --timeout-child=30

I was able to reproduce with the following command:
echo -n abc | spamc --ssl --port 11783


It looks like it's hanging on this line: https://svn.apache.org/viewvc/spamassassin/trunk/spamd/spamd.raw?view=markup#l1807

 	    @msglines = ();
 	    $actual_length = 0;
>>>> 	    while (defined($_ = $client->getline())) {
 	      $actual_length += length($_);
 	      push(@msglines, $_);    

It's probably the call to getline.  I'm not sure if there's a different call to get the number of bytes, since at this point it knows the expected length from the Content-length header.
Comment 1 Bill Cole 2021-10-25 03:34:22 UTC
I'm not convinced that this qualifies as a bug. 

Actual email messages end with CRLF, as RFC5322 (like its ancestors) defines a message body as a set of lines. What real-world circumstance would actually result in sending spamd something without a trailing CRLF? 

Also, "Content-Length" is not present in many messages, in part because it is inherently risky to actually trust a number in a header written by a random spammer.
Comment 2 Michael Caley 2022-01-14 22:29:12 UTC
Ya, I must have misinterpreted the RFC. I thought there was an overall newline at the end but it looks like each line in the body as a newline at the end.

I can close this, thanks!