At 17:32 2002-06-18 -0700, procmail(_at_)deliberate(_dot_)net did say:
I finally realize that you've been absolutely right all
along and I should sit down and learn to do this and set it up
and quit complaining ... thanks for continuing to press on this.
Once you take a look at the sandbox setup, you'll realize that it is little
more than a generic .procmailrc that sets a few things up so that you don't
deliver messages on forwards, and deposit messages into a separate subdir
from where you normally would. If you can write a procmail recipe, you can
use a sandbox.
Very slick. Would I mess it up by using $DOMAINLIST
instead of mydomain\.tld?
* $ ^(To|Cc):.*\/[-+\(_dot_)_a-z0-9]*(_at_)$DOMAINLIST
If $DOMAINLIST is properly defined to be a regexp to select one of your
domains, yes, that would work:
(that third one is an over-simplified optional hostname construct - it
could be made better, but the idea is there).
BTW, I have no problem with the stricter definition of an
address to not include goofy special characters. But, would
using the "word" construct something like that below be OK as
* $ ^(To|Cc):.*\<\/(_dot_)*(_at_)$DOMAINLIST
.* is too greedy, and the word construct will happily match the wordbreak
before any previous address. Try that in a sandbox'ed recipe and run it
using a constructed test message with a To: header something like:
This really isn't all that contrived -- basically, ANY instance where
*YOUR* domain doesn't appear in the first recipient address. Want to
venture a guess at what the match text will be if the greed is permitted
while matching yourdomain.tld? By specifying the character subset (which
might benefit from some expansion - that was written off the top of my
head), you exclude the previous @, whitespace, and comma (as well as angle
brackets and other symbols).
=> RECIP="$RECIP, $MATCH"
You can do that???
Sandbox it and begin to discover wild things about procmail. A sandbox
will allow you to play all manner of what-if scenarios and tweak your
regexps. You can TRY things without risking your live email, which will
make it a LOT easier to learn about procmail, since you're not living under
the gloomy cloud of "I must get this right the first time or else I'll hose
all my email."
For instance, I have some complex spam recipes - which I can run against a
saved mail file simply by including the spam rcfile (and perhaps setting a
variable or two) into another rcfile used by my sandbox. This permits me
to take messages that "got past" my filters the first time and see whether
some changes will catch them in the future -- or just to see the VERBOSE
logging output of the spam filters (which I don't normally log as verbose
because of the sheer mail volume and quantity of log material on a single
message due to the number of rules). I can also take a regular mailbox
(known to not be spam) and throw that at the filter in the sandbox to see
that it doesn't incorrectly match normal messages (although in my regular
filtering scheme, they may be messages that are filtered out BEFORE spam
filtering). The point is, with a well considered, yet generally quite
simple test configuration, it is easy to test your filters - often without
ANY changes to the filters themselves (if you run them as included rcfiles
and are orderly with your use of variables, etc), which IMO is the best way
to test a filter, since you're not introducing bugs through your re-editing
of the file -- once it works properly in the test bed, there's little
reason for it to not work properly in production.
Thank you very much,
You're very welcome.
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