> - Mailet staging - It would be really nice to be able to have > different stages for mailet execution. The first stage would > start when the SMTP DATA command is received. This mailets > would only be able to process based on data such as: remote > IP, helo/ehlo host name, recipients, sender, user, whether > TLS is enabled or not etc. This would also make it possible > to reject the incoming message before it has been received in > its entirety. The second stage would start after all the > headers have been received and the third stage would start > when the entire message has been received.
I don't fully agree. I think that is not correct to close a connection during a DATA session, so I think that there should be NO stage when we received the headers. I also don't like the "remote IP, helo/ehlo host name, recipients, sender, user, whether TLS is enabled or not" stage: this should be modularized but not the matcher/mailet way IMHO. > - Mailets as deployable units - I don't know if this should > go into the new mailet specification itself but it would be > nice if mailets could be made into discrete deployable units. > I would like to be able to take a jar file with my mailets, > matchers and some type of deployment descriptor and just give > it to the mail server. I think this would make it much > simpler for administrators to use third-party mailets. I can > see this happening with JBoss as this seams to follow closely > with their easy deploy philosophy. Can you provide an example? A mailet need to be configured in a processor and probably associated to a matcher. You can't just plug them and go. Do you mean you would like to have an AdministrablePluggableHotdeployableSpoolManager that allow configuration a pluggability of matchers/mailet on the fly via a remote interface? > - Multiple mailets per matcher. I have a couple of different > matchers that are expensive to run (Naive Bayes classifiers) > that I would like to have multiple mailets process. To do > this I've had to create a separate spool and my James config > file has gotten very messy. > - Process to allow mailets to run for a non-match. Besides > specifying which mailets should run on a positive match, it > would be nice to be able to specify mailets that should run > on an negative match. I think that there is some confusion between matcher and mailets, specifications and james implementations. Mailet API does not specify that there should be a matcher per mailet and multiple matcher/mailet couples in a processor. The current Mailet API simply provide interfaces to match none/partial/full recipients for a given mail (matcher) or to service a given mail (mailet). A more advanced container could provide a full featured workflow designer with multiple matchers and multiple mailets or everything else. Currently you can simply execute more mailets for a single matcher by using the ToProcessor mailet in you matcher and then using as many mailet as you want in the destination processor (all with match="All"). IMHO current Matcher/Mailet api are not enough to have REAL, RE-USABLE mailets between different mailet containers: most James mailets currently use and need concepts specific to james, repositories, states, attributes that are not defined by the mailet api. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
