David Meleedy <david(_dot_)meleedy(_at_)analog(_dot_)com> writes:
What I would like to do is be able to configure a .procmailrc
file that can handle both mh and non-mh users as a front end
to the unmodified spambouncer procmail scripts.
In order to do this, a typical rule in spambouncer might
look like this:
:0 Aw
* !FILTER ?? yes
${BLOCKFOLDER}
In other words a variable is used to hold the name of the file
where blocked messages would go.
typically you might have something like this:
BLOCKFOLDER=${HOME}/Mail/blocked.incoming
but for MH, what I would like to do is this:
BLOCKFOLDER="| /usr/local/lib/mh/rcvstore +blocked"
Why not just use procmail's own ability to deliver to MH folders,
by appending "/." to the folder path, ala:
BLOCKFOLDER = "$HOME/Mail/blocked/."
The only thing that rcvstore can do that procmail doesn't is update the
'unseen' sequence. However, that's a _feature_, as rcvstore doesn't
perform any locking of the .mh_sequences file (or worse, the .context
file), so it can corrupt them if two messages are received at the
same time.
In other words, the first character of the expanded variable
is a PIPE, so it'd be nice if the rule could expand the variable,
and if I pipe is found, try to use it.
This change isn't really a good idea, as it leads to nasty reparsing
issues and security problems (existing recipes assume the mapping into
a pipe or forward action doesn't happen).
You can, of course, do the work yourself using a set of recipes that check
the contents of the variable and passes it to a pipe action as needed.
For example:
# If $MAILBOX starts with a '!' we perform a forwarding action
# If $MAILBOX starts with a '|' we reparse it as a pipe action
# otherwise, it's just a mailbox
:0 w
* MAILBOX ?? ^^!\/.*
! $MATCH
:0 E
* MAILBOX ?? ^^|\/.*
| eval "$MATCH" ;
:0 E
$MAILBOX
The 'eval' is to allow $MAILBOX to include its own embedded shell
meta-characters, while the ';' forces procmail to use a shell. The
trick is that you need to use single-quotes when setting MAILBOX to
such an action:
MAILBOX = '| (formail -rtk -A"X-Loop: my(_at_)addr"; cat message) |
$SENDMAIL $SENDMAILFLAGS -t'
It may be handy to place that recipe block in an rcfile and invoke it
via INCLUDERC as needed.
If not, is there another way around this problem given that I don't
want to modify the original source files?
Original source of what? The spam recipes? If using procmail's builtin
MH delivery won't work for you, such that you _must_ invoke a program,
then you're going to have to change the rcfiles. Using an INCLUDERC
as suggested above may make it a palatable change for the maintainer of
the spam recipe in question.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail