At 05:36 2002-12-13 +0100, Oliver Fuchs did say:
What I noticed was that a few times it is recommended a recipe to
be placed at top of the .procmailrc file:
[big snip - yup, lotsa stuff we can get by typing 'man procmailex']
I know that I do not have to quote the man procmailex here but I
only wanted to show that it is mentioned very often in the examples
that a special recipe should be placed on top.
That isn't telling you that you need to do any of those things -- merely
that for the type of things you want to occur before anything else
(backups, dupe checking, spam filtering) they should reasonably occur
before you start filtering for individual things (like sorting for mailing
lists or vacation messages, etc). It makes sense that if you're going to
make backups that you do that before anything else (except for variable
definitions of course), and dupe checking after that (no need to subject
all your other recipes to dealing with duplicates), THEN anything else you
want to subject every incoming message to.
First one is 2 (correct the header) and 3 (eliminating of duplicates).
If I would have to place a backup-recipe the rank for me would be:
1 (because 2 could fail), 2, 3 followed by the spamassassin recipe.
Fine, so you seem to have the idea.
IMO, if you thoroughly test your recipes in a sandbox, there's no need to
run a backup recipe (except perhaps to collect a central mailbox worth of
messages which you can throw at the sandbox recipes).
BTW how long is the duplicate cache kept?
See 'man formail' -- the messageid cache is defined by *SIZE*, so when that
size limit is reached, old items will be dropped from the cache. The
duration depends on how large of a cache you specify, how large the
messageids are on messages which you receive, and how many messages you
receive over a given period.
If you use the 8192 size (8KB) that the typical example provides, and your
messages have an average messageid length of 48 bytes (the contents of the
Message-ID field, not inclusive of the field name - I got this number by
examining a messageid cache on my system), then the cache should last about
8192/(48+1) = ~167 unique messages (the +1 is for the field
separator). You should be able to expect that most duplicates should
arrive within close proximity of one another (for instance, a day lag would
be rather excessive), so even if you receive hundreds of emails in a day,
the cache size doesn't need to be able to accomodate every one simultaniously.
I highly recommend that you consider setting up a sandbox (as described in
links from my disclaimer), so that you can experiment with things to see
firsthand how they work.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail