At 11:44 2005-11-14 -0800, Gary Funck wrote:
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
Well, IMO, procmail doesn't need to necessarily be faster or use fewer
resources in order to be the mail processor of choice: GETTING THE JOB
DONE is probably the biggest concern for most users. Next to that would be
conservation of resources, which often (though not always) goes hand in
hand with speed. Both of the latter concerns are probably bigger factors
for sysadms.
An ISP I contract for has about a dozen hosts running spamd - a
SpamAssassin daemon that scores messages. This is for users who are
otherwise handled quite handily on just two shell servers. Oh, and they
don't discard the spam, they just mark it and let the users do with it as
they will (though there are web interfaces to tweak procmail rules for
users to discard junk).
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.
I use external processes where necessary, but yea, I'd like to avoid them
where possible. A ten-liner to avoid a shell is fine, a 50-line-plus
convoluted recursive INCLUDERC isn't. I've written support programs to do
specific things (my MEGAGREP for instance, which uses an AVL-tree to load a
wordlist and match that against message headers or whatnot - it's
tremendously faster than trying to use grep to provide similar functionality).
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.
Clairity goes a long ways towards maintainability.
If the original design goal were really in utilizing other tools for their
given purposes rather than folding oft-used features into the program
itself, wouldn't procmail LACK basic regexp support and instead rely upon
grep(1) to perform matching?
I'm going to guess the argument against that logic is that the regexp
operations are frequently used. That's the same argument for adding other
features. Even if they're spam related - because, let's face it - procmail
is used by a lot of people to deal with spam.
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.
I don't see why it can't do both. Enter procmail-lib or somesuch - a way
to extend the featureset.
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail