Hi all, In the last year we succesfully separated the mailet-api and a collection of generic matcher/mailets from the main james codebase. Yet we have still many mailets in the code base mainly because they depends on some james specific behaviour/class. I think this is not good for mailets and that this is the right place to find a solution. In past we discussed about wishlists for mailets v3, but we always stuck. I try again and I hope to find some time to push this a bit further.
In order to allow more generic mailets I think we need to evolve the mailetcontext to provide some more service. Here are a couple of easy and enabling changes: + dns queries: SPF, whitelists, blacklists, DKIM. There are a lot of mail processing nowadays requiring dns calls. Mailets could use java dns resolver but we know that from a server point on view it is better to work with dnsjava: if we provide some generic api to run a dns query then each container will be able to decide how to implement it and mailets would be easier and more portable. + redirect/forward mailets tree: we have a bunch of mailets that are not generic because the duplicate the current "Mail". mailet api doesn't provide a way to do this, so our mailets simply have to use "new MailImpl(mail)". What about exposing message creation and message duplication methods from the mailet context? e.g: Mail createMail(String sender); Mail duplicateMail(String sender, Mail original); (as an alternative to have sender as a parameter we could add the setSender to the Mail interface. Not sure what's best) Then I have a couple of other changes. This will require some more thinking, but I'd like to throw them in, maybe someone else share my needs: + routing: in a mailet container we "move mails" around. Yet, mailet-api just provide the "Mail.state" handling. Should an implementor simply "embrace" state and use it as a destination url so that each mailet can define a new destination url or should mailet api provide something smarter about rerouting? (I feel it's better to skip this at this time, but I still think this is on the table) + simple persistence: I find that often a mailet needs some sort of simple persistence or some sort of "advanced/dynamic" configuration. a list of domains for a whitelist, a list of usernames (list<string>) a list of email addresses for a mailing list expansion (list<string>) map of aliases (map<string,string>) a properties like configuration (map<string,string>) They are simple list of strings or maps of strings to strings. Why don't we provide a way for mailets to declare they work with a "named map" or a "named list" and automatically provide persistence/lookup methods in a container agnostic way? This way a container could provide a simple file based (properties files works too!) a jdbc/jpa/jcr based implementation (configured in the container not in the mailet). I know this may sound "limited" but mailets could then encode/decode their data in simple strings to be added as values in the map and this would be a very little cost compared to writing the persistence backed (or being limited to a simple file or jdbc solution hardcoded in the mailet itself). I think this would be a great step beyond! But there are details to be understood: the content should be "editable" both by the mailet (mailet keeping statistics) and by the container (e.g container monitoring the filesystem for changes), so we probably need to define how new data is "flushed" and how persistence is monitored for changes. Maybe we could even provide just maps as list are a subset (the keys of a map are not so different from a list) Sendmail provides "compiled" (hash db) lists and maps to be used in processing for virtusertable, mailertable, domaintable, aliases because it is generic enough to be useful. WDYT? (maybe it's better to start a new topic if answering to this one). Stefano
