Noel, I've had a quick trawl through the jSieve code to revive my 'hazy memory'.
The issue with the mailet API is that the Sieve spec. requires that we use MDN (Message Delivery Notification) to communicate with the sender. This is not exposed as part of the Mailet API so a Mailet used to invoke jSieve would either have to implement this internally or abandon Mailet compatibility by invoking the MDN service supplied by the server (in James this is org.apache.james.util.mail.MDN). The jSieve Mailet example does the latter, so it is a James specific Mailet rather than a truly portable Mailet. Not a big deal? One way of associating scripts with users is to extend the UserRepository, to allow the association of arbitary text objects with each user (or BLOBs, but not all target user repositories support these). We could then add an interface to manage the adding and deletion of a Sieve script and an implementation that used this mechanism. A mailet that detected a particular subject header and the fact that we are dealing with a localuser could process mails with Sieve script add and delete actions by interacting with the above. We would have to think long and hard about how to secure it, but much of this could be covered by the processing chain we sent such mail down, allowing us to re-use pre-existing Mailets infrastructure. In conclusion, there aren't too many hurdles and no high ones. This is good news, as is the fact that any work done in this area is fully compatible with how we might operate when full IMAP support arrives. In fact, all we are missing are the IMAP specific Sieve commands. I hope this helps. If anything isn't clear feel free to shout. Cheers Steve PS: You may need to shout soon. I bought one of these today, http://www.rssailing.com/fleets.asp?fleet=RS%20Vareo, it may kill me! Steve Brewin wrote: > > Noel J. Bergman wrote: > > Steve, > > > > I haven't looked much at the code, but IIRC, you were > waiting for IMAP > > support. > > Yes. Many of the specified standard operations in the spec. > are predicated > on IMAP functionality. We cannot be RFC compliant without it. > Still, as I > recall, included in SVN is an example of plugging JSieve into the > LocalDelivery process. My memory is hazy, but I believe the > example works by > invoking pre-existing mailet code to perform what 'standard' mailet > functions it can. > > I also hazily remember that there were some issues with the > Mailet API that > got in the way of the nirvana solution of being able to > declare custom Sieve > functions that simply mapped to the invocation of > pre-existing Mailets. The > two APIs are not quite symmetric. > > > I would like to pursue activating sieve in the > > current setup, > > perhaps adding a mapping from the recipient address to a > sieve script. > > The example applies the same Sieve script to all, pretty much what our > Mailet chain does using a different vocabulary. Its a proof > of concept, we > can leverage James' architecture, but no more. In my mind the > benefits of > Sieve over the Mailet chain only come into play once we can > associate a > Sieve script to each user. So such a mapping and the means to > persist the > scripts are prerequisites to it being a useful tool. One that > controls mail > flow in an RFC compliant manner. > > > Would you be willing to collaborate on getting that done? I > > am thinking > > that it could be modular, so that it could run in the > protocol handler > > (post-DATA) or in a mailet. > > Yes and can't! Yes I would love to help in anyway I can, but > I can't promise > any coding time. My time is so over committed at the moment > its ridiculous. > I hate saying I will do something and then not delivering, so > I'd rather > not. > > What I can do over the weekend is revive my 'hazy' > recollections by taking a > look at the code with a view to identifying the steps > required to achieve > the "nirvana solution" described above and further work > required for per > user scripting. > > At a minimum, this will give us an idea of the size of the task we are > considering. > > Cheers > > -- Steve > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
