Andrew wrote,
However I wouldn't take a spool file and just feed it back through sendmail.
At the very least move the old spool out of the way, lest you end up
appending to the file you're reading from and create a nasty loop.
Michelle's original question indicated that she had recompiled procmail to put
ORGMAIL under $HOME, so I figured that the reprocessing she wants to do
wouldn't add any messages to the old files. But Andrew is right: suppose,
under the old system, a user wanted a particular type of message delivered to
$DEFAULT, but instead of using procmail's $DEFAULT or $ORGMAIL variable or
just letting it fall off the end of ~/.procmailrc, that user had specifically
named /var/mail/$LOGNAME (either with the $LOGNAME variable or by spelling out
his/her logname) as the destination of a recipe. You can't get around
~/.procmailrc by specifying an rcfile when you're using the -d option, so
Michelle would run into that nasty loop Andrew pointed out. Sure, she could
put
:0:
$DEFAULT
at the top of /etc/procmailrc for a few minutes, but what about brand new
incoming mail that arrived during that interval?
Then again, Udi brought up just catting the old spools onto the new spools,
and that might be the way to go after all. Michelle would need some algorithm
to figure out the home directory of each user who has mail in the old spool
directory -- for example, using a shell that groks tildes instead of
/bin/sh -- but otherwise it ought to be straightforward:
#!/usr/bin/ksh
for user in /var/mail/+([a-z0-9])
do
test -s $user || continue
eval 'newspool=~'$user/.mail
lockfile $user.lock $newspool.lock
cat $user >> $newspool && rm $user
rm -f $newspool.lock $user.lock
done
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail