Greg Matheson <lang(_at_)ms(_dot_)chinmin(_dot_)edu(_dot_)tw> writes:
Theres an article on http://www.perl.com about the Mail::Audit
module that is critical of procmail at
http://www.perl.com/pub/a/2001/07/17/mailfiltering.html
Coming from a perl programmer, his second paragraph is almost
hilarious. I don't recall Simon ever complaining about all of
perl's single letter commands and flags ($foo = s/foo/bar/eiox).
I started writing perl scripts and procmail recipes at about the same
time in 1992, so I feel comfortable in both, though they both feel weird
in different ways.
What I think interesting is that procmail holds to one of perl's oft
stated mottos: make the easy things easy and the hard things possible.
Procmail's syntax may be obscure to someone who's does most their work
in languages whose syntaxes are descended from ALGOL (C, perl, python,
C++, etc), and it certainly has plenty of warts (the zero in ":0",
the wacky rules governing backslash-newline removal, etc), but simple
filters are generally very straight-forward. A few examples of how
to get from "desire A" to "procmail recipe alpha" most people quickly
get the feel for mapping.
(A bigger problem that *all* filtering languages suffer from is the
difficulty in actually knowing what you want the filter to do. I think
that most errors in rcfiles are caused by the author not considering all
the side-effects implicit in their goal. "I want to forward all messages
to else(_at_)where(_dot_)com". What about bounce messages? Mailing list
messages?
What if else(_at_)where(_dot_)com bounces? etc.)
I will be sticking with procmail, but I can see the virtues of an
interface between the programs I want to write and the mail
filtering I do. It's kind of difficult to create procmail rcfiles
on the fly and use the data it provides on the fly. The relation
I'm not sure what you mean by the above. If you want to pipe 'out' of
procmail, have your rcfile deliver to "|", ala:
:0
* conditions here
|
Delivery to "|" makes procmail dump the message to stdout.
between procmail and other programs is like the relation between
awk and C programs, perhaps. Perl filled in a gap there.
I understand how Perl filled the gap between awk and C, but I'm not sure
how you're matching those to procmail and 'other programs'. Is procmail
with C or awk of mail filters? I think elm's old "filter" program was
the oawk (or maybe grep) of mail filters, but where to put procmail and
Simon's Mail::Audit module is more questionable.
Where is the language that will make programming the mail
intuitive?
That's part of the purpose of Sieve (rfc3028), but it is purposely *not*
Turing-complete--no loops or variables--such that users can only hurt
themselves with it.
I've thought for some time that the Right Thing would be to use sieve's
extension capabilities to give it loops, variables, and the ability
to deliver to and filter through programs like procmail. Once those
extensions are designed and documented, write a sieve to procmail
translator and tell users that you support sieve.
Ironically, if I ever get around to writing that translator, it'll
probably be in perl.
(Did he really have to call procmail "moldy"? <Sigh> Or maybe that's
a good thing: despite procmail being so 'old' that it's moldy, no one
has come up with a replacement that's as robust and efficient, so it
keeps on ticking...)
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail