On 11 Feb, Homer Wilson Smith wrote:
|
| I wish to test a global spam filter that resides in /etc/procmailrc
|
| To test I want the filter in place, but I want ALL mail
| delivered to the end user even if it matches the filter.
|
| :0c:
| *^ Subject: XXX Horney pictures of your mother!
| spamtrap.caught
|
| Will this deliver the mail to the file called spamtrap.caught AND
| deliver to end user also?
|
| Remember this is GLOBAL procmailrc not a per user .procmailrc
|
If there is no prior recipe that delivers the message before this one,
and if it matches the condition, and if there is no succeeding recipe
that delivers the message elsewhere, and if there are no other problems
(permissions, etc.) that prevent it, yes this will deliver the message
to both places.
The rest of this may fall into the "more than you wanted to know"
category, but... If there are other recipies following this one and you
know you want it delivered to the user's mbox if this one matches, you
can save the overhead of processing the "extra" recipies by adding
right after yours:
:0 A
$DEFAULT
You could also write an entry to the LOGFILE with an assignment like
LOG="spam would be caught" (which might only be useful if you also have
LOGABSTRACT=on), or insert a header something like:
:0
*^ Subject: XXX Horney pictures of your mother!
{
:0fh
formail -A "X-SPAM-TEST: nabbed"
:0
$DEFAULT
}
Not that either of those should be preferable to you, but just offering
a couple other possibilities in case you hadn't thought of them.
Lastly, you might consider setting up a testbed before putting new
recipies and rcfiles into production, especially if they'll affect
users other than yourself. You can pass a sample of messages to a test
rcfile which processes them without doing any delivery to the mail
spool. It has the benefits of avoiding unwitting mistakes that could
mess up normal delivery (syntax or logic errors), doesn't fill up user
mailboxes with additional junk, and creates a control environment where
you can test that messages are disposed of as expected without any
interference from "real" messages coming in. It could be accomplished by
delivering to files such as $TESTDIR/spam.no and $TESTDIR/spam.yes (with
TESTDIR suitable assigned). You can use the same file with 5 or 10 or as
many as you want messages and use 'formal -s' to pass them to procmail.
You should be able to find examples of testbed setups in the archive at:
http://www.xray.mpe.mpg.de/mailing-lists/procmail.
Don Hammond
(Who admits to often times foregoing this for a handful of test messages
from another account if the changes are simple and straightforward.)
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail