procmail
[Top] [All Lists]

Re: formail -D generates empty msg. when duplicate found?

1999-12-11 17:58:58
On Dec 11,  2:20pm, Dallman Ross wrote:
Subject: Re: formail -D generates empty msg. when duplicate found?
From: gary(_at_)Intrepid(_dot_)Com (Gary Funck)

On Dec 11,  1:36pm, Dallman Ross wrote:
What I myself am thinking of implementing is a backup
of all non-list mail that would then get cleaned out by a cron job
and find after so many days.  I do this now (have for years) with
my procmail logs and auto-ack respondent database (everybody gets
an auto-ack no more than weekly from each unique sending address,
unless they request verbose acks or no acks).  It would be simple
to add saving mail to files each day and then use find
to delete mail over, say, 7 days old.  I would also gzip the
mail.

If I understand your suggestion above, this would require saving
each e-mail message into a separate file?  I was trying to avoid
that.  I prefer keeping related mail in a single file.


No, they don't each need a separate folder.  I will put all mail
for a 24-hour period in a daily file.  I could do it differently
if I wanted, e.g., put all in a weekly file, of course.
All files go in one directory.

Got it. Makes sense.


I use INCLUDERC to declare the date as yymmdd and save my
current logs in that way, one log file per day.  (I use cron
to change what's in the INCLUDERC.)  But the date filename
is for *my* convenience, not for the purging mechanism,
which merely looks at the mtime of the file and deletes
if over, say, six days old.

You don't even need the INCLUDERC/cron thing to set the
date, of course, if you just take the date from the message
itself.  That assumes you don't mind trusting the dates
on the messages.

If you don't mind the shell process on each invocation, this'll work also:
DATE=`date +%Y%m%d`   # YYYYmmdd - y2k compliant :)


Another thing I was thinking you could do is set a counter
in procmail.  Every time the counter gets to 100 new processed
messages, change the filename.  Maybe that would be more
overhead than what you are trying, I don't know.

This is beginning to seem like one of those situations where
more technology leads to more problems :), but ...

It isn't too much overhead. Still, it has the same problem (for me) with
the current scheme I'm using - it resets the number of mail messages in
the current mail folder, back to zero, which means that I have to look
in some other folder to find the previous few messages.

It would be possible to add some helper files that give
both the number of message bytes and the number of messages in
each folder and use a high/low water mark sort of strategy that
prunes the current folder back to T1 bytes/messages when T2
is exceeded.  For example, it might prune the number of messages
in the current folder back to 100, whenever the current number
of messages exceeds 200.  This would distribute the overhead
of pruning, on a demand basis, and elminate the need for a
cron job.

This might require something like the following:

DEFAULT=|append_to_folder $ORGMAIL <min_messages> <max_messages> <archive_dir>

and then for each folder:

:0
*  <something>
| append_to_folder <falder> <min_messages> <max_messages> <archive_dir>