On Thu, 12 Dec 2002, Professional Software Engineering wrote:
At 21:32 2002-12-12 +0100, Oliver Fuchs did say:
So you think check first the spam and then the duplicates?
The man procmailex is not clear at this special point ... there
are three or four receipes that should be placed on top of my
.procmailrc file.
FTR, man procmailex does not espousing any specific mail handling procedure
- it presents multiple examples of how you can do certain things within
procmail. Nor does procmailex get into spam checking either.
Yes, that is true. There is no spam-checking advice in man
procmailex.
What I noticed was that a few times it is recommended a recipe to
be placed at top of the .procmailrc file:
Man procmailex:
[...]
1)
If you are fairly new to procmail and plan to experiment a little bit it
often helps to have a safety net of
some sort. Inserting the following two recipes above all other recipes
will make sure that of all arriving
mail always the last 32 messages will be preserved. In order for it to
work as intended, you have to create
a directory named `backup' in $MAILDIR prior to inserting these two
recipes.
2)
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. To fix the same problem by
different means, you could have
inserted the following two recipes above all other recipes in your
rcfile. They will filter the header of
any mail through formail which will strip any leading `From ', and
automatically regenerates it subse
quently.
3)
If you are subscribed to several mailinglists and people cross-post
to some of them, you usually receive
several duplicate mails (one from every list). The following simple
recipe eliminates duplicate mails. It
tells formail to keep an 8KB cache file in which it will store the
Message-IDs of the most recent mails you
received. Since Message-IDs are guaranteed to be unique for every new
mail, they are ideally suited to weed
out duplicate mails. Simply put the following recipe at the top of
your rcfile, and no duplicate mail will
get past it.
4)
Suppose you have two accounts, you use both accounts regularly, but they
are in very distinct places (i.e.,
you can only read mail that arrived at either one of the accounts). You
would like to forward mail arriving
at account one to account two, and the other way around. The first
thing that comes to mind is using .for
ward files at both sites; this won't work of course, since you will be
creating a mail loop. This mail loop
can be avoided by inserting the following recipe in front of all other
recipes in the $HOME/.procmailrc
files on both sites. If you make sure that you add the same
X-Loop: field at both sites, mail can now
safely be forwarded to the other account from either of them.
[...]
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.
I did:
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.
Makes the most sense - consisder that dupe checking by itself probably
consumes less CPU than the spamassassin code.
I agree and found that it works this the best way.
Thanx for the tuning help.
BTW how long is the duplicate cache kept?
Oliver
--
... don't touch the bang bang fruit
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail