bogofilter closing stdin prematurely in passthrough mode

[Tomaž Šolc]

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.

Best regards
Tomaž
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-another-test-for-passthrough-truncation.patch
Type: text/x-patch
Size: 3018 bytes
Desc: not available
URL: <https://www.bogofilter.org/pipermail/bogofilter/attachments/20250923/56d96444/attachment.bin>