procmail
[Top] [All Lists]

Re: processing inbox maildirs with formail

2007-08-27 07:30:22
On 8/27/07, M. Fioretti <mfioretti(_at_)nexaima(_dot_)net> wrote:
formail -s procmail -m another_procmail_file.rc < inbox.waiting

but I'd need to run the formail command above every minute from a cron
job, and inbox.waiting would be a maildir to which postfix/procmail
are continuously delivering new messages.

Why is it necessary to first deliver to inbox.waiting with procmail,
and then reprocess the messages with procmail again?  I'd think it was
almost always better to do the whole thing during the original
delivery.

In any event, formail works (and is necessary) only on flat-file
mailboxes, not on one-message-per-file directory mailboxes.  For
maildirs, you will need to use some other tool to select the messages
(files in inbox.waiting/new) which ought to be fed back to procmail
again.

Please also note that the another_procmail_file.rc file would have the
form:

        if     (some condition is satisfied)
                        move message to other inbox
        else            LEAVE it in inbox.waiting

The question is, will it work without corrupting any message?

Procmail can't "move" messages.  It can only deliver new copies.  You
can have it shell out to something that knows about maildirs and
implements the move operation, but at that point you might begin to
consider writing the entire filter in something other than procmail.

Beyond that, it'll work if the input to the other .rc is only the
files in the "new" subdirectory, and the  "LEAVE it" part is
implemented by (possibly after procmail is finished) moving each file
to the "cur" subdirectory.  If you must both leave them in the maildir
and leave them "new", then you're going to have to do something else
to avoid processing the same message repeatedly.  This is probably all
a job for whatever tool you employ to feed the messages to procmail,
rather than a job for the procmail configuration.

In either case the .rc is going to have to be slightly different than
for a default inbound mail delivery, because (assuming inbox.waiting
really is the inbox of the user executing the later procmail from
cron) you WILL get a second copy of the message if you re-deliver.
Procmail writes to files, but it reads from standard input, so it has
no intrinsic way of knowing that its input represents a message that
is already present in any mailbox it may eventually write.
____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail