-----Original Message-----
From: R.G. Ball
Sent: Monday, November 14, 2005 10:26 AM
[...]
Ach! Stay away from spam stuff. It is too much of a moving target and is
much better handled by specialized tools (even if those tools are written
in procmail). As several people have pointed out, very effective spam
filters can be created using some smart scoring of the headers without
ever looking at the body.
Rich, not only do I agree with your "use the proper tool" advice, I practice
it.
However, that said, I have admin. privileges and the luxury of just a few
users. So compute time, memory, disk space, and privileges are not a
concern.
This isn't the case for everyone. Quite a few have shell accounts and
seem to want to do at least a little spam filtering on their own. Why
not accommodate them? Note also, I think that approximate matching has
other uses and they don't just relate to processing message bodies.
If procmail is going to continue to be the mail-processor-of-choice then
it needs to do that job better and faster and with less resource-use than
other choices.
If we implemented to that goal, procmail scripts wouldn't allow variable
substitutions that amount to adding new code on the fly. Further, it
would be possible for procmail to go directly to the recipes that
apply to the incoming mail, setting only the environment variables
required by that recipe, and would not slog its way through a bunch
of text lines trying to figure out which recipe applies. Of course,
a lot of useful applications would go out the door, but the program
would be _fast_.
Right now, if we worry about a procmail script being fast, we tend
to discourage proc-ing off separate programs, but that leads to some
really convoluted scripts which are maintainable only by gurus.
The thinking in favor of new features goes: if procmail had more
expressive power and builtin support, there'd be less need for proc-ing,
and less need for trickery.
I like using procmail but I don't like writing complicated
recipes in it. So, improve the syntax and add some features needed to
improve the job it needs to do but stay away from adding functionality
targeted to making the job of spam-filtering (or other high-level
decision-making) easier. There's nothing wrong with a
sendmail->procmail(deliver the stuff I know is
good)->spam_test/mime_test->procmail(deliver the spam/ham) message-flow as
long as the resource footprint stays small.
I'm not advocating direct support for spam processing. I happen
to believe that a feature like approximate matching might have
other uses. By the way, approximate matching might simply set
a 0..1.0 score, and could be folded into scoring rules.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail