At 00:01 2005-11-12 +0100, Ruud H.G. van Tol wrote:
On busy systems, parsing the values out of the From_ line in stead of
calling date (once or more) per message, could mean an important
difference in the number of messages per second it can handle.
Which, er, is the point of wanting to integrate some additional
capabilities into procmail - avoid the overhead of external shells and
processes.
Besides, I extract the From_ date *AND* call date (to parse the Date:
field) so as to check lag times and bogoid messages, so to do that, I'm
definatley getting hit with the overhead of an external process, to do
something that is just a standard C library call away...
I really don't understand the fierce opposition to facilitating new
features. Properly implemented, extended features can be used alongside a
compliant "compatability mode" parser. I suggest those who want to hold on
to old versions go and check to see if your recipes work on an older
version of procmail. INCLUDERC? Sorry.
I'd really like to see procmail be able to parse multipart messages, handle
encodings (imagine being able to search for text and match it even if it is
encoded, just by indicating you want to search the "decoded" target - much
like there's the B and H variables), and to have some additional functions
built in (such as date, PCRE, sed-like operators, DNSBL type lookups and
other DNS operations, etc). There's undoubtedly a host of other features
others have considered which would make many peoples use of procmail MUCH
less complicated.
---
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