maildrop + bogofilter: error writing to filter

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

Sam Varshavchik answered:
|Of course I recompiled all involved programs, like maildrop,
|bogofilter, tokyocabinet.
|
|bogofilter does not read the entire contents of the message from its
|standard input. It terminates before it is read in its entirety. xfilter
|pipes the message to the external filter program that it runs. If
|xfilter detects that the pipe is broken, before it's finished writing
|the entire message to the pipe, it concludes that the external filter
|has crashed.
|
|Given the buffering involved with pipes, you get non-predictable
|behavior that, sometimes, maildrop succesfully finishes writing the end
|of the message, which gets buffered in the pipe before the external
|command terminates without reading in its entirety. There's no way to
|detect that, so, depending on random factors, sometimes an error gets
|detected, sometimes not; and this depends in part on the underlying
|operating system platform and implementation. It's not surprising that
|different behavior is observed after upgrading.

and:

|Looking at the message won't be very useful. There's nothing wrong with
|the message itself, but rather with what bogofilter appears to be doing;
|namely failing to read the message and terminating before doing that.
|It's unlikely that one can tell why, just by looking at the message
|itself.
|
|The only thing I know is that the whole purpose of the "xfilter" command
|is to pass the contents of the message to "something external", which is
|expected to read it, and create a new message that maildrop uses as a
|replacement message for further filtering or delivery. Although I'm not
|familiar with bogofilter, looking at its man page the -p option seems to
|be doing just that.
|
|But if that "something external" clearly terminates before it reads the
|entire message, then something obviously went wrong. If whatever's
|procmail's equivalent to "xfilter" is, ignores this, and blissfully
|carries on, that's procmail's call, but I don't think that's a smart
|decision.
|
|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.

The problem is that bogofilter works fine from the cli - like
maildrop does, but not in actual delivery. Right now I have to:

1. inspect the postfix queue
2. in case there is this problem, disable bogofilter by
   temporarily changing the mailfilter
3. sendmail -q
4. reinstate bogofilter in the mailfilter

Needless to say this cannot even be called a workaround.

Any ideas?

TIA

-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions
_______________________________________________
Bogofilter mailing list
[email protected]
http://www.bogofilter.org/mailman/listinfo/bogofilter