From: Udi Mottelo
Sent: Monday, November 14, 2005 7:03 AM
[...]
Gary adds:
- [...]
- 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.
It will make procmail to be an heavy monster, isn't? I suggest
to add more templates to the examples in the distribution pack
where you can catn`paste or include.
If there is one thing that a new procmail should contribute, IMO, it
should be more easily used, less error prone. Procmail is in very
wide use these days, but based upon my limited experience, is often
unintentionally mis-used. That's because the syntax is quirky,
sometimes the semantics are quirky, and often the "simple" is
made "difficult". Being "lean and mean" is not an "end" goal, but
a "means". If we consider that when procmail first came out, it
was used mainly by admins, and now it is often a standard tool
provided on shell accounts, and that during procmail's
lifetime that the Internet has probably grown by 10x, computer
processing speeds by 10x, and spam by 1000x, it isn't surprising
that people are clamoring for new features.
Back to the subject, I think simply adding examples is insufficient.
I think there should be easy to use and understand support for
commonly needed operations. We can argue about how that support is
provided to the user. Is it a pre-defined pattern, an environment
variable that is evaluated when referenced, or some new flag or
fucntion? That doesn't matter so much, except that all similar
things should be handled in a similar way.
Here's something to consider: TO_ is a generally useful pattern, and
if more people used it, their scripts would be more reliable. However,
it is scary to look at its definition in "man procmailrc" and "quirky"
to use (remember to add ^ ahead of it, but no .* after it), so it is
still pretty easy to get things wrong. Perhaps better, and more intuitive
would be support that looped over all of the TO_ addresses.
:0 T # the T flag loops over all To addresses, splitting them out
# as if they appearead on To:, Apparently-To:, Cc;, etc. lines
# all by themselves. Each time through the recipe, it sents
# the TO variable
* TO ?? "fred(_at_)example(_dot_)com"
{
# do something for Fred
}
Probably a few people won't like the suggested method of introducing
improved TO address processing above. I think it could use some more
work, but the idea is to illustrate how procmail might directly support
something the people seem to want to do fairly often, and do it in
a more natural way (IMO).
On the subject of pre-defining patterns like TO_ and FROM_DAEMON,
these could be done in a global rc file read in by procmail when
it starts up. It would keep its compiled in version, unless it
is overwridden in the procmailrc file. It could be as simple
as:
TO_="...pattern..."
FROM_DAEMON="...pattern..."
though we're running the risk of polluting the name space,
so there might be a better way.
- 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.
Not option but separate command. I think we have diferent
philosophy (:-)
Either way is fine with me, however, the trend these days is to
integrate this support into the program that processes the
input files (perl -c, etc.).
My addition:
- Strip HTML, like lynx -dump where "hel<big></big>lo"
will be found as "hello". Say: * L ?? hello
This is good and useful.
- If procmail will not mix the records in the logfile
I would be satisfied.
Also falls into the camp of less error-prone. We might summarize
as "better logging support".
Although I'm almost afraid to suggest it ... I'd like it if LOG
could expand "\n" and "\t" to avoid the need for the "$NL" and
newline in strings trickery. If I really had my druthers, LOG
would add a new line always, and lock the logfile. That would
be just a little too incompatible unfortunately.
While we're at it, I'd like ABSTRACT=ON to be less built in.
I'd like to be able to define the info that ABSTRACT prints,
and or the actions taken upon delivery.
BTW. did you read RFC3028? http://www.faqs.org/rfcs/rfc3028.html
Maybe you'll find more idea about parsing a message to variables.
It will be nice if we can write the rules that we want by high
level language and translate it automatically to
procmailrc recipes.
I have read the Sieve, spces. Sieve has the advantage that it is
more single purpose than procmail, in that its primitives really
are limited to mail filtering and sorting, and that the syntax is
more easily understood. It's RFC status of course is a plus, and
may becaome a hurdle that procmail can't cross. It does have built
in support for vacation processing and such (additional RFC's).
In my view Sieve is The Competition, and if procmail can't step
up it may be left behind. In particular, procmail should try
to make the simple things easy and to handle commonly requested
operations more directly.
- Gary
____________________________________________________________
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