From: Bart Schaefer
Sent: Saturday, November 26, 2005 11:02 AM
[...]
Shuffling around copies of the cache as suggested by Ruud and
Dallman is in fact what I'm already doing. I've also considered
There is a computational trade-off between the amount of
time required to scan a larger message id database and
to test the return code from formail, and to possibly
copy back a new version of the file. Also, I believe that
formail -D is atomic (?) so no further locking may be
required, which gains further efficiencies, especially when several
recipients all see the same mail.
If on avearge there are 20 recipients of a viral mail,
then it might be possible to make the cache file 20 times
bigger and still come out ahead. Certainly, it is
simpler.
).
Couple of other ideas:
- use grep -Z to first search the id database, because we
know that id's are zero-terminated in the cache file.
- use lockfile to atomically test and create a file whose
name is given by the message id:
MSG_DIR=/var/procmail/scan_cache
MSG_FILE=$MSG_DIR/`formail -X Message-ID: -c | tr -c -d
'[:alnum:](_at_)(_dot_)'
lockfile -s 0 -r 0 -l 0 $MSG_FILE
which will return 0 if the file didn't previously exist.
A cron job can clean the old files up every few days
I'd be a ittle worried about message id as a signature though. Lots of
spammers (and presumably virus spreaders) don't
mind faking message id's, thus possibly colliding with legitamite mail(?
____________________________________________________________
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