Noel J. Bergman wrote:
Yes, with DBCP, or maybe we use another pool. Aside from removing what isn't the best pooler, I want to expose javax.sql.DataSource's via JNDI so matchers/mailets could get DB connections easily (just like with any web-app)Now that I can (at long last) post it ( ;-) ), this has been my personal list of items:V3.0: - Replace Mordred
Related to this, I am thinking through a VERP gateway... basically you need a unique ID and a list of recipients for a message. From their, the recipient list gets coded to make bounces trackable, and it keeps track of who was sent what (based on that unique ID).- Full Function Mailing Lists
Have to figure out exactly how to structure/configure this, but then the idea is you could use whatever remote delivery needs you want (be it a James supplied mailing list or your own code). This code (running within James) would track the bounces per the VERP recipients it created, and so you could just check the DB or maybe register listeners. Anyway, not that bad.
This isn't very easy, but related to this (and classloaders below) is to also have James support compiling java files in the "classes" directory, so you can just edit your mailets and hopefully get them working. Could pull this from webservers, but need to them also figure out how to report failed compilations. Anyway, a would-be-nice.- Dynamic Reconfiguration
- Mailet Classloaders
I had done a bunch of work on this already... I'll try to dig up that code.
- Remove Finalizers
Which finalizers?
- Security
What do you mean by security?
Cool, just reminder that the geo-ip guy gave us rights to bundle the free copy of their IP lookup table with James.V2.1.x: - GeoMatcher
We're already using JAF 1.0.2 (I don't think that's changed in years), so hopefully just JavaMail, and should be pretty straight-forward.- RegexMatcher - Index on repository name (looks like v2.1 only does it for MySQL) - JavaMail 1.3/JAF 1.0.2
OK, so other things...
** DRAC support
If you're familiar with this protocol (or whatever you call it), the idea is when POP3 user is authenticated (could be IMAP too), that IP address gets registered for say the next 30 minutes. Then the SMTP server can check that list and will accept messages from that IP address in that time frame. This is an alternate way of letting remote dial-up users send email without resorting to SMTP-AUTH (and thus possibly deal passwords unencrypted as it's easier to require POP3/IMAP4 connections to be in SSL).
** Mail attributes
Right now the mail attributes has a String error message, which is something of a hack, and there's no way to attach extra objects to a Mail object. This would allow you to have one mailet do some checking and set a flag on a message, without having to add new headers to the message. I prefer to make these attributes rather than properties, and we could support any serializable object.
** Message repository directory structure
Ok, this is my big idea for the week. This does not relate to changing the API of repositories, but instead changing the way we reference a given repository.
Currently, each repository is defined with a URL metaphor, e.g., db://maildb/inboxes or file:/var/mail/inboxes. While workable, it makes it somewhat ornery to support multiple formats (we have file, db, and dbfile, and would hope to have at least mbox, maildir, remote IMAP folders, and probably others). It also makes it more difficult to use tools to copy/move messages between these repository instances because you have to remember these URLs and use the same ones already defined in the configuration file. Finally, it makes it very difficult to pass configuration settings to a given repository implementation. For instance, it would be nice to configure a specific dbfile implementation to have different thresholds before the message body is stored in the file system (instead of just in the DB). This configuration by appending query string parameters to the URL quickly becomes out of hand with this metaphor.
What I propose is a virtual message repository structure that uses a *mount* metaphor. For example, you could mount the db repository implementation to /inboxes and the file repository implementation to /spool. Or instead maybe you mount /inboxes/lokitech.com to the db repository implementation and /inboxes/otherdomain.com to the maildir repository implementation.
Admin tools are much easier to use now as you can simply read messages in /spam, decide whether to delete or move them back into /spool, without having to worry about underlying implementations and URLs. As a more advanced example, you could at run-time mount /tmp/remote1 to a remote IMAP account, move all messages from /tmp/remote1 to /inboxes/sergek, and then unmount /tmp/remote1. This would transfer all my messages (and folder structure) from that remote server into James's store (which of course it doesn't matter whether that's maildir or db or whatever).
This allows us to more easily use the repository abstraction that we've defined (or that we could revise). Our repository architecture already supports child repositories, so it's well understood that you can start with file:/var/mail/inboxes, and if you asked for a child named "sergek", you would get file:/var/mail/inboxes/sergek. This translates very nicely to the mount metaphor and in fact makes it that much easier to do.
While this is a big conceptual and configuration change, it does not impact the existing code very much. The repository implementations can potentially work without any change because we're only changing how they are initially looked up. Existing mailets/matchers would need minimal change since they would be configured to ask for /inboxes rather than file:/var/mail/inboxes (we might change what classes they use to do the lookups, and I would have that's the limit to the changes they would need). The code to do the mounting would be new and relatively separate, thus making it not overly difficult.
Ok, enough wrambling for now. Probably will have other ideas in the future.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
