maildrop + bogofilter: error writing to filter

[Jonathan Kamens]

On 06/15/2013 06:44 AM, Christian Ebert wrote:
> Hi,
>
> I tried my luck at the courier-maildrop list
> http://sourceforge.net/mailarchive/forum.php?thread_name=20130613110855.GB753%40krille.blacktrash.org&forum_name=courier-maildrop
> but was basically referred to bogofilter. So here goes:
>
> After an upgrade to Mac OS 10.8.4 (64bit) from 10.5.8 (32bit) I
> get the following error for _some_ messages:
>
> temporary failure.
> Command output: maildrop: error writing to filter.
> /usr/local/bin/maildrop: Unable to filter message.
>
> The offending rule is rather bog standard:
> xfilter "/usr/local/bin/bogofilter -u -e -p"
>
> Trying the bogofilter suspect on an offending message however
> seems to cause no problems:
>
> $ bogofilter -u -e -p < testbogomsg 1>/dev/null
> $ echo $?
> 0
You're doing two things wrong here: (1) you're not calling bogofilter 
the same way maildrop does; and (2) you're throwing away the information 
that would be most likely to tell you what's going wrong. Let's take 
these one at a time...

(1) Maildrop isn't giving connecting bogofilter's stdin to a file on 
disk. Rather, it is connecting bogofilter's stdin to one end of a pipe, 
and it's writing the email message into the other end of the pipe so 
that bogofilter can read it. If you are trying to test what's going 
wrong with maildrop and bogofilter, you need to do the same thing. 
Something like this:

    cat testbogomsg | bogofilter -u -e -p 1>/dev/null

(2) Maildrop is telling you that bogofilter is exiting before reading 
all data from the pipe. One way you can confirm that is if you see "cat: 
Broken pipe" or something like that when you run the command immediately 
above, which will tell you that cat ran into the same problem as 
maildrop. But even if that doesn't happen, you can find out if 
bogofilter is reading the whole message by checking to see if if 
/prints/ the whole message on its output, and you can't do that if you 
throw the output away as shown above. Try this instead:

    cat testbogomsg | bogofilter -u -e -p >| bogoout
    diff testbogomsg bogoout

If the "cat" command prints an error, or if testbogomsg differs from 
bogoout aside from the added X-Bogosity line, then you have managed to 
reproduce the issue that maildrop is seeing, and we can debug further 
from there. If not, then we're going to have to get more creative in our 
debugging efforts.

By the way, the people on the other mailing list from which you sought 
help told you the same thing about checking the output:
> |You should look at what bogofilter is printing, for the offending
> |messages. It can't be the original message, if bogofilter isn't even
> |reading it. Perhaps looking at bogofilter's output, for the message,
> |will provide more clues.
Does this happen consistently for the same email message. I.e., if 
there's a particular email message that triggers this problem, does it 
happen every time maildrop tries to deliver that message?

   jik