Error 2 executing bogo in procmail

Matthias Andree matthias.andree at gmx.de
Mon May 16 01:42:58 CEST 2005


Kevin Williams <netkev at gmail.com> writes:

> i call procmail from .qmail and inside .procmailrc i do:
>
> :0fw
> | bogofilter -u -l -d /var/qmail/mailnames/##.com/kevin/.bogofilter

Please revisit the bogofilter manual page, it has a working example from
which you'd quickly find out which option you're missing.

> procmail: Executing
> "bogofilter,-u,-l,-D,-d,/var/qmail/mailnames/##.com/kevin/.bogofilter"
> procmail: Program failure (2) of "bogofilter"
> procmail: Rescue of unfiltered data succeeded

procmail stinks. If something goes wrong, it'll just continue as though
everything was fine, feeding messages through recipes that were never
supposed to see these messages...

You can fix this - AFTER - fixing your filter, by adding a recipe like
this:

:0e
{
  EXITCODE=75 
  HOST
}

after *_EACH_* of your recipes. Yes, it's bulky. And as ugly as
sin. That's the price for using procmail. Evidently, this also makes
using :0e recipes in their own right impossible.

NOTE: I've repressed if 75 is the right code for qmail, replace 75 by
whatever makes qmail retry the mail later on.  qmail was a good
riddance. 75 works on Linux and FreeBSD on x86 machines with Postfix,
Exim and Sendmail. These MTAs all heed /usr/include/sysexits.h, unlike
qmail. You may need 111 instead, I don't know any more. Check the qmail
man pages.

Consider switching to maildrop 1.8.1. While procmail can work several
arcane configurations (though I haven't seen a single that I'd recommend
among these) that maildrop can't, maildrop usually is a much smoother
ride than procmail. Much clearer, and no such hacks needed to defer
mail.

-- 
Matthias Andree



More information about the Bogofilter mailing list