I think I might be able to go this route. The middle-level function execute_filters() would need to be a bit more psychic, but not a lot. Mostly it would just need to know about mailbox delivery, and in fact that's probably the most appropriate place for that to go. I suddenly found myself coding an INBOX find/create routine in insert_messages() and really didn't like the feel of where that was going.
I should have time to write execute_filters() this evening; with luck, that will pretty much finish straightening out the delivery path! Aaron On Mon, 28 Apr 2003, Jesse Norell wrote: > > Hey, > > Did you use a temporary mailbox (idnr=0)? If so, you could just > dump the message there and everything else should probably work > (you already give it the user_idnr and message_idnr). Make > execute_filters default to INBOX delivery, or maybe need to clean up > after it if the message is still in the temp mailbox (have to consider > handling multiple recipients of the same message). > > ---- Original Message ---- > From: Aaron Stone <[email protected]> > To: [email protected] > Subject: Re: [Dbmail-dev] [PATCH] procmail-like filters for dbmail > Sent: Mon, 28 Apr 2003 08:39:05 -0700 (PDT) > > You're correct, thanks for pointing that out! There are a few other > problems yet to work out, I also noticed an issue if the specified > mailbox does not exist, among other things -- totally missed this one. > > In this version, I tried to avoid changes to the db layer, but it > looks like that won't hold up for much longer... > > Aaron > > > On Mon, 28 Apr 2003, Jesse Norell wrote: > > > > > Hello Aaron, > > > > > The flow I sketched in my pipe.c rewrite first copies messages into a > > > target user's INBOX, and then calls the function execute_filters(useridnr, > > > msgidnr). The filters can then run on the header and/or body and toss the > > > message around as needed, sending a rejection to the From address and > > > deleting it, forwarding and possibly deleting it, or just moving it to > > > another mailbox. > > > > Just a thought - it seems there'd be a race-condition here where > > a message has been inserted into INBOX, but before the filters get > > executed to move it somewhere else, a user reads their mailbox (eg. > > via imap). I don't know if this would cause any actual errors (I > > noticed in a recent imap trace posted that it queried for message > > metadata matching both message_idnr and mailbox_idnr - if the latter > > changed since having been looked up, it could), or just an > > inconsistent view of the mailbox. Considering some of those filters > > will likely be for matching virus headers, etc., there's a chance > > someone could end up opening such a message that should have been > > deleted. > > > > Also, I've not looked at your code, so you may well have addressed > > this.... > > > > Jesse > > > > > > -- > > Jesse Norell > > jesse (at) kci.net > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > -- End Original Message -- > > > -- > Jesse Norell > jesse (at) kci.net > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
