Philip Guenther wrote:
SoloCDM <deedsmis(_at_)ris(_dot_)net> writes:
1) Is there a way to send detailed error messages to the
administrator as e-mail (besides LOGFILE=$PMDIR/log) when mail goes
awry and where is the best place to locate that recipe?
What do you mean by "when mail goes awry"? That covers a lot of different
things, most of which are beyond the ability of procmail to identify
exactly, making it difficult to impossible for procmail to usefully be
the source of any notification to the administrator.
Occasionally I have an e-mail destroyed by the rcfile, resulting from
some symbol I left behind while making an additional recipe.
2) For a backup cache, I'm assuming the following recipe with "backup"
is a directory. Is this based on a system without a MAILDIR (assigned
in .procmailrc) and are the following recipes correct and extremely
efficient -- base on how they're designed and designated to execute?
:0 c
backup
:0 ic
| cd backup && rm -f dummy `ls -t msg.* | sed -e 1,100d`
These recipes will work even if you assign to MAILDIR earlier in the
rcfile. The "backup" directory just needs to exist relative to wherever
MAILDIR has taken procmail. If you want the "backup" directory to always
be under $HOME, then just change the actions to say so:
:0 c $HOME/backup
:0 ic
| cd $HOME/backup && rm -f dummy `ls -t msg.* | sed -e 1,100d`
I'm concerned about Netscape's conflict of interest with msg.*'s
created in backup; therefore, I'm designing the best route to avoid
Netscape.
A specialized program written in C to do the removal would be faster,
but it wouldn't be portable. It's also debatable how much faster it
would really be and whether writing it would be worth the effort.
Note that the above recipe weren't really designed for use on *everyone's*
account: the procmailex(5) manpage talks about using these recipes as a
safety net for inexperienced users of procmail, presumably to be removed
once the user is comfortable with writing recipes. A general purpose
e-mail backup system would have to scale better than the above does.
If there is an alternate and more highly efficient recipe (general
purpose e-mail backup . . . not foreign to Netscape), then what are
you suggesting, in detail?
3) It seems "dummy" becomes the default filename. Can I override that
with ":0 c: <filename>" OR does "backup" become the filename and
"dummy" become obsolete once MAILDIR is in affect, which means:
switching directories points to the location of "cd $MAILDIR" and "rm"
deletes "backup"?
What do you mean by "default filename"? "dummy" is on the rm command
line so that rm won't barf when the backup directory is completely empty
and the ls commmand returns no filenames.
I don't understand what you're trying to say in the rest of that
paragraph.
You answered it well.
4) Are the above recipes placed somewhere among the following recipes
-- presumably, directly following these two recipes?
# Nuke duplicate messages
:0 Wh: msgid.lock
| $FORMAIL -D 8192 $PMDIR/msgid.cache
Depends. The answer depends on your reason for backing up the messages
you receive. What are you trying to protect yourself from?
Overlooked symbols that destroy the e-mail processed.
# Regenerate "From" lines to make sure they are valid
:0 fhw
| $FORMAIL -I "From " -a "From "
To quote the procmailex(5) manpage, right before that recipe:
If your system doesn't generate or generates incorrect
leading `From ' lines on every mail, you can fix this by
calling up procmail with the -f- option.
Does your system generate valid "From " lines with that recipe? If yes,
DON'T USE IT. Is the system fixable? If so, do so and DON'T USE THAT
RECIPE. If not, can you invoke procmail with the -f- option? If yes,
DON'T USE THAT RECIPE. Only if you answered no to all three of those
questions should you be using that recipe.
I tend to be over precautionary for good measure, but if you feel
(based upon your above guidelines) that it is totally unnecessary,
I'll have it removed.
*********************************************************************
Signed,
SoloCDM
P.'S. Detailed Documentation(s) and Sample(s) are more than welcome.
When you reply to this message, please include
the mailing list and my address.