Attempting to consolidate the "who is the maintainer?"
and "ways to add new features" threads:
Sean suggested:
- parse multipart messages
- handle encodings
- scan decoded message body (in same vein as B modifier)
- date functions
- Perl-like regular expressions
- text substititions
- DNSBL look ups
Volker concurred, and suggested:
- date parsing operations
- 'test' functionality, in particular
-d, -f, and -a -o !, and-nt
- access to n-th occurrence of a header
- formail as buitin
- access to multi-part headers directly
Ruud adds:
- time-based arithmetic, by conversion to epic seconds
other mktime functions (presumably conversions between
time zones)
- unicode should be used as fully as possible
Gary adds:
- upward compatible with 3.22 version of procmail, except in
erroneous situations.
- extensions should be "context free" in that when we exchange new
procmail constructs on this list, it should be obvious from reading
the recipe that it is new syntax (this argues against, dependency
upon the name of an .rc file, or a global variable, or command line
argument.
- add 'expr' functionality for evaluating simple expressions
- along the lines of merging formail with procmail,
formail, procmail are simply renamings of each other (via hard link
in Unix, or by copy else where, and that they are able to call each
other without creating a new process.
- add a new switch to procmail (-s) that tells it to split an mbox and
repeatedly invoke procmail's processing cycle. This is equivalent
to: formail -s procmail < mbox
- mail address parsing support. Reliably and correctly parse the
addresses in TO: FROM: and any other headers. Once the address
has been broken out, support splitting it into name and address
and host name part.
- provide support for parsing the TLD from a hostname
- support RDNS lookups (might be part of the DNSBL support)
- support MX record lookups
- ability to extract URL's and/or e-mail addresses from message bodies
(arguably could be implemented with the new PCRE support, but this
extraction would be builtin, faster, and syntax added for looping
through the addresses/URL's)
- In addition to PCRE matching, implement "approximate matching",
ala String::Approx (on CPAN)
- Improve procmail's error handling to catch commonly occurring errors.
For example, when the user forgets to specify locking, or when the syntax
for maildirs (the trailing / gotchas) is used incorrectly. Basically,
go through the past couple of years' of Procmail mailing list notes and
note the commonly occurring errors to see what can be done.
- improve the formail -D cache functionality so that it is uses a more
well-defined file organization. Perhaps support BDM and gdbm database
formats
- Add builtin features which make it easier to perform frequently needed
operations, such as vacation processing, auto-replies, mailing list
determination and sorting. In particular, the builtin operations would
make sure an X-loop is added, and so on.
- Add a "lint" option to procmail, to have it scan the rc file for
blatant errors and to diagnose possibly unsafe/incorrect recipes,
without actually executing the script.
- Improve procmail's performance by having it statically compile scripts,
where possible (recursive includes and includes that can't be statically
evaluated throw this out), and use the statically compiled
.pc-procmailrc as long as it is newer than .procmailrc, for example.
- implement a procmail milter (in the vein of mimedefang) that lets
the user express mail processing actions via procmail scripts.
- add a switch to formail telling it the maximum number of processes
to spawn. When invoking parallel instances of procmail, use threads
instead.
____________________________________________________________
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