bogofilter closing stdin prematurely in passthrough mode

[Matthias Andree]

Am 23.09.25 um 13:27 schrieb Tomaž Šolc via bogofilter:
> On 21. 09. 25 23:58, Matthias Andree via bogofilter wrote:
>> Am 21.09.25 um 13:03 schrieb Tomaž Šolc via bogofilter:
>>> Hi
>>>
>>> I have a bogofilter setup where procmail pipes messages through 
>>> bogofilter for sorting. I've been looking into a problem where a 
>>> certain email causes procmail to error out ("error while writing to 
>>> bogofilter") and repeatedly defer the delivery.
>>>
>>> It appears that the reason is that bogofilter prematurely closes 
>>> stdin and exits while procmail still has bytes to write. Indeed, if 
>>> I just cat the offending email through "bogofilter -p" the email 
>>> printed on stdout is truncated somewhere in the middle.
>>>
>>> Otherwise bogofilter appears to work normally. It doesn't return an 
>>> error code. There's no segfault. The only weird thing I see is that 
>>> if I do a strace it attempts to do an invalid seek on fd=0 before it 
>>> exits, but this might be benign.
>>>
>>> I think the email is hitting somekind of a token or input buffer 
>>> limit. It has a few very long sequences of U+3164 "HANGUL FILLER" 
>>> characters. I've been able to reproduce the problem by creating an 
>>> email with such a sequence. Bogofilter cuts it off after 3640 
>>> characters (but, for example, it will not cut off an identical email 
>>> with an ascii "a" instead of U+3164).
>>>
>>> This is with bogofilter 1.2.5 as packaged in Debian Bookworm.
>>>
>>> I'll check if the same issue appears with 1.3.0 once I get it running. 
>>
>>
>> Tomaž, thanks for the report.
>>
>> I believe 1.3.0 is bound to fix that, as the result of reports from - 
>> among others - Jonathan Kamens (Gitlab issues #7 and #11) in the beta 
>> phase,
>> and if you want to avoid messing with the 1.3.0 build if that's too 
>> troublesome, you can also send me your reduced test case off-list and 
>> I can test it.
>
> Thank you both. I've been out of the loop for a while and only 
> realized there's an issue tracker after I sent my last mail.
>
> Yes, issue #7 describes the same symptoms I see. Probably lexer tries 
> to stuff the long sequence of U+3164 characters into the buffer in a 
> similar way described there.
>
> I've tested the current git main branch and it works as expected.
>
> I've attached a patch with a test case (based on 
> t.passthrough-truncation) that fails on 1.2.5 and passes on 1.3.0. 
> Feel free to include it if you think it will help prevent future 
> regressions.

Tomaž,

Thanks a lot, that's cool. Applied & pushed (anyone trying this patch 
on  1.2.5: it does apply there, too, but you'd better also manually add 
the new test also in XFAIL_TESTS in src/tests/Makefile.am - because we 
expect it to fail).

Cheers,
Matthias