> I would like to implement a program, based on procmail, which can have
> many options (it is actually a Web<->mail gateway, mostly for African
> users, who do not have easy and cheap IP access).
>
> I can see two ways to do the option processing: have procmail recognize
> the message is for the gateway, then feed it entirely to it and let the
> program do the processing. Or try to do as much as possible in procmail.
>
> The latter seems really not convenient. I would like the program to allow
> requests such as:
>
> To: wwwmail(_at_)me(_dot_)org
> Subject: get http://www.pasteur.fr/ mime images recursion=2
>
> and this will need the identification of all the options above, some
> having an additional value. This doesn't really seem a job for procmail.
> At least, I didn't find a way to do it.
>
> Is it hopeless in procmail? Should I give in?
Since procmail is a mail filter, and is extensible using shell commands,
you are limited only by what you can do from a shell command.
Deciding how much to do "in procmail" and how much to do in shell
scripts, or another language is always a trade-off.
The criteria I use for making these decisions is to consider:
* how much time it would take me to write the filter in procmail versus
another language, say Perl.
* how frequently the filter will be invoked: the more often, the less
load I would like to place on the processing of the mail.
Some folks go all out to do everything in procmail, in the interest of
completeness and efficiency, even though it may take them three days to
do so. Sometimes, I go this way, for fun -- just to see how it can be
done in procmail.
Others prefer to write the filter in the most convenient language (Perl,
Python, shell scripts, etc.), and then use procmail for just the header
extractions and message piping. I often do this, resorting to Perl to
do any lengthy processing, especially the kind that doesn't invole the
mail headers.
As a sample application, I once wrote an email to database-update
gateway, where email "forms" would be parsed and processed by a mail
filter. Procmail did the header extractions, but then fed the message
body (the "form") to a Perl script which did the form validation and
database update, since Perl's string processing is vastly superior to
that of Procmail. I left the response generation, however, to procmail,
by having the Perl script return an error message to STDOUT, which the
procmail recipe captured and used to compose a return response.
It is best to use the strengths of each tool. It's much like building a
house: you use a hammer on nails, a wrench for the nuts, and a
screwdriver for the screws. It would be silly, terrible even, to use a
hammer on the screws. Likewise, it would be terrible to try to use
procmail recipes to do extensive string processing and interactions with
a database. Just as it is terrible when I see Perl scripts badly
hacking up or generating mail messages. Use each tool where it fits,
and you'll end up with a nicely built house.
I can't really make a recommendation to you concerning your query above,
because the processing requirements weren't made very clear. However,
if you are saying that you don't know how to parse the subject line
using procmail, then you should consider the following recipe as an
example:
:0 # see if this is a "wwwmail" command
* ^TO_wwwmail(_at_)me(_dot_)org
* ^Subject: *\/.*
{
CMD=$MATCH # get the command on the subject
:0 # parse the command
* CMD ?? ()\<get\>
{ URL MIME IMAGES RECURSION=0 # reset vars
:0
* CMD ?? ()\<http:\/[^ ]+
{ URL=$MATCH }
:0
* CMD ?? ()\<mime\>
{ MIME=1 }
:0
* CMD ?? ()\<images\>
{ IMAGES=1 }
:0
* CMD ?? ()\<recursion=\/[0-9]+
{ RECURSION=$MATCH }
# Any other arguments should follow this template
#:0
#* CMD ?? somekeyword=\/[^ ]+
#{ KEYWORD=$MATCH }
#
}
# At this point, without knowing what you wish to do, I can only
# suggest a command to process the results. Since the procmail
# variables are available as environment variables, you do not
# need to pass them as arguments, unless it is more convenient
# than having them available as envars.
#
# Invoke the "get" command processor, which can assume these
# environment variables:
# URL -- URL to "get"
# MIME -- set if MIME enabled
# IMAGES -- set if IMAGES enabled
# RECURSION -- number of levels to recursively fetch stuff,
# default is 0 (zero).
#
:0AWi # if the "get" matched, invoke the command
| www-get-command
:0E # not a "head" command, check on other commands...
... # left to the reader as an exercise
}
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks