From procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)de Thu Oct 27
20:57:18 2011
Subject: Re: Querying a DB to determine destination mailbox for an email using
Procmail
From: LuKreme <kremels(_at_)kreme(_dot_)com>
Date: Thu, 27 Oct 2011 19:56:53 -0600
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
On 27 Oct 2011, at 18:58 , Komal Tagdiwala (ktagdiwa) wrote:
Requirement: I need to devise a solution where a procmail script can dynam
ically determine the final destination mailbox by querying a database for
a particular keyword to get the corresponding mailbox.
Approach I have in mind:
Based on my knowledge of procmail so far, I envision the following steps b
ut wanted some expert opinion on finding the right approach.
1. Use a database to maintain a key/value pair type information for a keyw
ord and a corresponding mailbox name. This information may be maintained m
anually or using a custom application (outside of procmail).
2. Write a Perl script which takes an input parameter from procmail (I hav
e not done this before but I believe procmail can call a Perl script and j
ust pass an argument in the call).
If it is simply a matter of key/value pair, then it is much easier to use gr
ep.
Assuming the number of pairs to check is 'rerasonable', 'grep' is a clear
winner. If the count is in the millions, or hundreds of millions (unlikely!
admitted :) then the start-up cost of a real database query is likely to
be more than offset by the superiour 'efficiency' of the database, vs. the
brute-force of grep.
3. The Perl script performs the actual query to database for a given keywo
rd to find the corresponding mailbox name.
If you need to query an actual database, then yes you will need an external
script to do it.
4. The script then returns the mailbox name to the procmail script/recipe
that invoked the Perl script.
That won't work, the procmail recipe has to either wait for success, or assu
me success. This will be the hangup.
Quote "No problem" unquote, if invoked from within .procmailrc. The particular
instance of procmail processing that message will wait until the external
process returns its results.
There are many ways to test for 'non success' of the script -- one of the
easiet being to check the returned string length. If zero, there was no
match, "obviously". <grin>
If yes, are there any conditions that I missed in my approach that I need
to be mindful of before beginning research and development for this soluti
on using this approach?
The biggest issue is that your procmail deliveries will come to a complete st
op while your query script runs. This might be a critical flaw, a minor annoy
ance, or of no importance at all.
This is simply not true. If the perl invocation is run as part of a
variable assignment, from inside .procmailrc e.g.:
VARIABLE=`perl scriptname $KEYWORD`
then procmail will happily process other incoming mails while that perl
instance is running. And, if the other emails happen to need that query as
well, there will be multiple instances of perl running, each processing the
same perl script, with (possibly) different KEYWORD parameters.
____________________________________________________________
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