procmail
[Top] [All Lists]

Testing filters before putting them into live use

2001-12-11 21:01:24
At 16:11 2001-12-11 -0500, some yahoo who just wrote their first mail filter spewed an autoreply to the procmail list, using MY address as the From:

G&G CARGO INFORMA
[snip]

When are people going to learn to thoroughly *TEST* their filters before putting them into live use?

Besides totally missing the mark with my message (the message was text/plain - there were *NO* attachments whatsoever, and nothing even resembling a known virus - did it trip on the mere mention of the word "virus" ?), the filter sent the notification *AS* the originator of the message to which they were autoreplying. Thanks a bunch, Mr. G&G Cargo.


Before putting *ANY* autoreply rule into live use, THOROUGHLY test your recipe in a sandbox! Redefine your $SENDMAIL to execute a local script which dumps STDIN and the arguments to a file which you can examine to see what would have been passed to sendmail (this works both for explicitly invoked sendmail (if you use the variable to do so), and for !forwards):

#------------- begin script (remove this line)
#!/bin/sh
# script: sendmail.sh
# author: Sean B. Straw
#
# This script is intended to be used for sandbox testing of procmail scripts
# so that we don't annoy the hell out of the universe because of some
# oversight in a script implementation.  It permits you to write the body of
# your procmail script just as you would use it in a live context, but by
# redefining $SENDMAIL in your sandbox wrapper, your included script invokes
# this instead of the real MTA.
#
# To use from procmail, simply redefine $SENDMAIL:
#
# SENDMAIL=/path/to/sendmail.sh
#
# Note: if you want to define the output filename dynamically from within
# your procmail config, you could define SENDMAIL above with the filename
# as the first argument and then change this script accordingly).
#
# This script uses 'lockfile', which is a supplemental procmail utility.
#

# set mailbox name, or perhaps it is a passed argument...
MBOXNAME=test.sent.mail

# create a lockfile
if lockfile -2 -r 6 $MBOXNAME.lock; then
( echo X-MTA-Parameters: $@ ; echo X-MTA-Send-Date: `date` ; cat - ) >> $MBOXNAME
 rm -f $MBOXNAME.lock
else
 # emit an error message to STDERR
 echo FAILURE OF $0 > /proc/self/fd/2
 # return a non-zero exit status to our caller so they know we failed
 exit 1
fi
#------------- end script (remove this line)

I've used this technique for a long time and it really helps when you want to test a ruleset but don't want to hack it to _NOT_ actually invoke the MTA (since that would of course _change_ the ruleset operation, which is often the source of such errors). I always run my test rulesets via an INCLUDERC into a sandbox wrapper - so the ruleset itself shouldn't need to change in order to be placed into a live mailstream.

I intentionally wrote it to run the echo and cat operations from within a subshell, so as to make it a trivial modification to actually invoke the MTA using a script-defined address (such as the author's own test address), and pass the modified message (with the two additional headers) to that MTA invocation (hint: replace ">> $MBOXNAME" with "| sendmail -oi someuseraddr", and you can eliminate all the locking as well). The execution cost of this script isn't a major concern since it is used for testing only.

---
 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

<Prev in Thread] Current Thread [Next in Thread>