I feel that you're attaching too late into the delivery chain. The function insert_messages() in pipe.c should probably be the place for this to go (at the same time breaking insert_messages() into smaller parts).
Interestingly, it is also the exact place where my LDAP patch needs to hook in to create the INBOX for a user who does not have one yet (ie it's their first email since the account was created in the LDAP directory). You probably have a similar issue if a mailbox is specified for a filter rule but does not exist yet. With the filters applied higher up on the delivery chain, they can also be used to generate bounces, forwards or call external programs. If you're interested, I'm working on a Sieve based solution. The project has quite a bit of steps involved; I'm at about step 3 of 2349058725. I'd be happy to share the work on this project! Check out libsieve.sf.net to see the library I set up, although the API needs an overhaul (I have the design document but haven't coded it yet). The best part is that it plugs into existing MUA infrastructure, using the ManageSieve draft RFC to do filter uploading and the Sieve langauge for the filters. There's a bunch of Sieve script editors/uploaders written in Perl, PHP and for X. As always, freshmeat.net is your friend ;-) Really nice patch, though! For those who need filtering yesterday (umm, me...) and in case the Sieve project tanks, this looks great. Aaron On 19 Apr 2003, Jonas Jensen wrote: > The attached patch enables dbmail to use a simple procmail-like > mechanism for filtering incoming mail. Rather than always delivering to > INBOX, users can now filter their mail with regular expressions and > direct them to different folders. For example, a pattern like > ^List-Id:.*dbmail\.org > can be used to direct all mail from the dbmail lists to a specific > folder. > > It should be possible for untrusted users to create these filters, and > it's very fast, so of course it can only do pretty simple matching > (POSIX enhanced regexes) and has no command execution etc. like > procmail. > > To make this work, my patch adds the "filter" table. If this table is > not present, everything will work like always, so backward compatibility > shouldn't be an issue. > A method for users to input these regular expressions is not included, > as it will probably be a part of a web interface for user administration > at each site. > > -- > Jonas Jensen <[EMAIL PROTECTED]> >
