Re: Querying a DB to determine destination mailbox for an email using Procmail

> From [email protected]  Thu Oct 27 20:57:18 2011
> Subject: Re: Querying a DB to determine destination mailbox for an email using
>     Procmail
> From: LuKreme <[email protected]>
> Date: Thu, 27 Oct 2011 19:56:53 -0600
> To: [email protected]
>
>
> 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.