It's time for "Learning from the mistakes of others"
A common simple recipe I have is like so:
:0
* conditions (may or may not be scored, may be single or multiple lines)
{
:0c:
| formail -A "someheader: descriptor" >> $DEFAULT
:0:
| gzip -9fc >> specific_archive.gz
}
The premise is that if the conditions match, a copy will be deposited into
$DEFAULT (system mailbox) with an added header (which makes sorting in my
non-*nix mail client easier, since all I'm doing is matching on this added
header), and the original is deposited into an incrementally compressed
gzip archive, so that I have a stored copy on the server in case I need to
refer to it.
FTR, the compressed archives are stored in a year-month named dir, and I
recompress the archives before archiving them off for long term storage on
DVD, as the incremental compression isn't as effective as a whole-stream
compression.
This is all quite straightforward, and I use it for a plethora of lists and
special contacts. The conditions commonly identify senders associated with
one contract job or another, different social groups, and often a specific
email alias I use for that contract/group, so that all the email pertaining
to one job ends up in a mailbox specific to that job. Nice and orderly.
A bit over a week ago, I quickly added another recipe just like
above. I've been buried in work associated with that contract, and haven't
been paying a lot of attention to "optional" email - lower priority stuff,
etc. This morning, I come up for air, and while browsing my email, I
wonder why it's been so long since I've seen a post on the procmail
list. I refer to the logs and find the following scattered amongst all the
messages delivered to this mailbox they've got NOTHING to do with:
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 2: syntax error: unexpected end of file
A quick glance at the recipe gives me no inkling why it would even match a
delivery on these messages, so I copy it (copy and paste, not retype -
that's always important) to my sandbox and throw some of the stored
messages at it. Same error, but with verbose logging, showing that neither
of the conditions on the recipe match.
So I look closer. The opening brace wasn't a brace, it was a paren:
( instead of {
Oops.
Fortunatley, with the order I have the archiving set up in, the second rule
automatically catches the messages and shuttles them to a mailbox. All I
do is fix the recipe, move that mailbox, and pump it into a formail split:
gzip -d < relocated_mailbox.gz | formail -s procmail -d username
and things are back to normal.
The new recipe was down low in the order of message handling, so very
little in the way of time critical stuff would have been impacted - most of
my direct-address recipes are handled above that point, and lots of the
stuff at the bottom are archival tech stuff. About 1200 messages were
dumped to this other archive in a little more than a week the error was in
play.
Anyway, I figured someone else might learn from it, plus it's worth
admitting that we oldtimers aren't immune to typos. <g>
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
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