Volker Kuhlmann:
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.
Parsing From_ in procmail, with a truckload of recipes, is faster than
calling date?
Yes. You can further limit the recipes to the values that you need.
Would it also be faster if some basic functionality of
date was included in procmail?
Procmail already has it included, see a procmail logfile, there is a
date and time as the first line for every log session. But I suspect
that the call to get that date/time value is only made if such a
log-line is asked for (the lazy evaluation principle).
A way in between would be to store the procmail-start-date/time values
(per PID) in one or more environment variables, and not hide those
variables from .procmailrc. That needs the procmail code to be changed,
but see also the -p option of procmail.
In a secure environment, `date` doesn't even have to be available.
That's the shortcoming in procmail, IMHO.
No, it is a secure environment. Procmail works fine without it.
If you only need the date, you can let a cron-job create a DATE.INC once
per day, with code in it that sets some variables:
# DATE.INC
DATE_YYYY = '2005'
DATE_MMM = 'Nov
DATE_MM = '11'
DATE_M = '11'
DATE_DDD = 'Sat'
DATE_DD = '12'
DATE_D = '12'
and let procmail include that. I haven't benchmarked such an INCLUDERC
against the From_ parser (or against calling `date`), but I never need
values finer than the day-number, so it would work for me.
Parsing From_ is a workaround, not a solution.
It has been a solution for many years. A Received header field has one
important extra: the TimeZone.
--
Ruud
____________________________________________________________
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