Paul Thomas followed up,
| I'm trying to call Spambouncer to filter emails from /etc/procmailrc
| on a per-user basis rather than from the home directories (.procmailrc),
| and I don't have any previous experience with Spambouncer.
And I've none at all (but rather a very strong distrust of anyone else's
canned all-purpose spam detection, especially if it trashes mail it thinks
is spam, more so if it bounces it).
| :0
| * ^(To:|Cc:|Received:.*for).*paul@
| {
| INCLUDERC=/etc/procmail/spambouncer/rc.paul
| :0 w:
| $DEFAULT
| }
My understanding is that `w' is needed only for pipe deliveries and filters;
on a save to a folder, recovering and continuing on failure are implicit.
Anyhow,
| And this filters the emails but dumps the emails that survive into
| $DEFAULT which I don't want, I have some other recipes below all
| this (that work btw). So if I do this:
|
| :0
| * ^(To:|Cc:|Received:.*for).*paul@
| {
| INCLUDERC=/etc/procmail/spambouncer/rc.paul
| }
|
| then the delivery hangs in mqueue and mailq gives the error:
|
| QAA07382 150 Wed Dec 26 16:15 <cueman(_at_)cuenet(_dot_)com>
| (mailer local died with signal 13)
| <paul(_at_)cuenet(_dot_)com>
What does a verbose procmail logfile say? Maybe that can pinpoint how far
procmail gets.
| The contents of rc.paul is just the procmail.rc included with
| Spambouncer...their own suggested procmailrc which sets Spambouncer
| to some simple defaults and then calls Spambouncer with:
|
| INCLUDERC=/etc/procmail/spambouncer/sb.rc
Ah, that's why you were asking about nesting. I might suggest that maybe
you had a loop building up INCLUDERC levels, but the recipe to dump to
$DEFAULT works, so apparently procmail is returning properly from sb.rc to
paul.rc and from there to .procmailrc. Maybe some variable set in sb.rc or
paul.rc is making a later recipe screw up.
One thing you haven't said is whether the messages that make the delivery
hang are what Spambouncer would call spam or not (or maybe it happens for
both?).
Here's something to test: get some messages that Spambouncer would consider
legitimate mail and some that it would deem spam, and give them to procmail
at a shell prompt (not as incoming deliveries). Then you might get another
perspective on the problem.
Here's something else you can try:
:0
* ^(To:|Cc:|Received:.*for).*paul@
{
INCLUDERC=/etc/procmail/spambouncer/paul.rc
LOG="We got back from the Spambouncer files.
"
}
If that text is logged but you also get the hung delivery report, then
something is going wrong later in your .procmailrc.
| It is looking more an more to me like a Spambouncer issue and since
| that 'solution' is so complex, includes no users/support list/forum,
| maybe I should look at Spamassasin or something else?
Don't ask me. I deal with spam with my delete key.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail