procmail
[Top] [All Lists]

Re: new feature request in 3.22, pipes interpreted from variable expansion

2002-03-27 00:12:54
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.

Well, this is true, but I used a local file lock on the procmail rule
to overcome this problem.

The big problem using the built-in feature of procmail is that it
really doesn't work too with "exmh", a graphical front end program
to mh.  exmh depends on the unseen sequence to not only highlight
incoming messages, so that it's easy to see what's new and unread, but
it also uses it to determine when to update it's scan (or folder view).
So without the unseen sequence being updated, you can't even read your
email unless you rescan the folder, which is time consuming.

Maybe an appropriate change to procmail would be to enhance it's MH
compatibility by updating the unseen sequences with a local lock so
as not to corrupt the unseen sequence file.

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).

I guess I don't understand why people would use an unparsed pipe in a
variable, but if you say it happens, then so be it.

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.

Well, this ends up modifying the orginal procmail files which I didn't
want to have to do.


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.

Yes, I had to end up modifying the original files to get this to work.
The reason I didn't want to do that is because the original spam recipe
files get maintained weekly by the originater, and I didn't want to
have to edit in changes myself every week.

-Dave


________________________________________________________________________
David Meleedy                           Analog Devices, Inc.
David(_dot_)Meleedy(_at_)analog(_dot_)com               Three Technology Way
Phone: 781 461 3494                     Norwood, MA  02062-9106  USA


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>