Gordon Messmer <[EMAIL PROTECTED]> writes: > Lloyd Zusman wrote: >> I have the courier-pythonfilter set up to run first, and there are >> cases where one of its filters decides to accept a message without >> further processing. The courier-pythonfilter code knows to not run >> any more of its own filters, but then, the Courier::Filter still >> processes the message. In this case, I don't want this to occur. >> [ ... ] > > It's really not either. Courier normally hands each message to all of > the active filters. I designed the pythonfilter framework so that a > given module within pythonfilter could indicate that other modules > should not run. However, that capability does not extend to filters > outside of the pythonfilter framework. > > I wasn't thinking about it at the time, but I suppose that's kinda > disappointing after you went to the trouble of making Courier run > filters in a specific order.
Yeah ... (sigh). But now, I have a new challenge: coming up with a patch/enhancement to the filtering mechanism which will cause a message to be accepted without any further filtering. In other words, every filtering step would result in a three-possibility outcome: 1. Reject the message. 2. Pass the message on to the next filtering step. 3. Accept the message without any further filtering. Numbers 1 and 2 are already in place, and all that's necessary would be to come up with number 3. It doesn't seem too hard. I'll post a proposal in a little while. -- Lloyd Zusman [EMAIL PROTECTED] God bless you. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
