You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/03/06 14:58:07 UTC

[Bug 6081] spamc stops reading after reading max_len bytes

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6081


Karsten Bräckelmann <gu...@rudersport.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|less than useful behavior of|spamc stops reading after
                   |spamc                       |reading max_len bytes




--- Comment #1 from Karsten Bräckelmann <gu...@rudersport.de>  2009-03-06 05:58:06 PST ---
Adjusted "less than useful" Summary, based on the first paragraph.


(In reply to comment #0)
> If the combined size of the two arrays is > the "-s max_len" parameter, I just
> hang because spamc reads max_len+1 and then stops reading.

Hmm, so spamc doesn't keep reading beyond -s...

> So, the enhancement is to have spamc quietly read the rest of the input stream,
> and then not process the message.
> I believe it's the case that spamc reads the whole message anyway, as it
> parrots it back untouched to STDOUT.

And now you say it does read STDIN completely, to dump it back to STDOUT. Which
kind of contradicts this bug report.


Anyway, tried feeding a Meg to spamc (SA 3.2.5), with and without an explicit
-s option. Passes through the entire input, so it did not stop reading.

A quick guess would be, this is due to some parts of your code you didn't show.
Randy, can you provide a stripped-down test case? Full code that shows the
issue.


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.