Nothing more than brainstorming, for now.

Introduce mailet application deployment features to make mailet deployment *easy*

[Progress: mailet classloader now looks in apps/james/SAR-INF/classes and apps/james/SAR-INF/lib/*.jar]

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).

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.[see JamesMailetV3]

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.

[I agree with the premise of why, but I'm not sure about the how. Seems overly complex, but maybe I'm reading something into it that isn't there.

If we're going to have User attributes, then why not associate a repository directly with the user? This would provide flexibility, and given the presence of a tool for copying between repositories, seems to provide a nice admin capability. And an admin can switch repository types without accidentally screwing up existing users, OR migrate users to another repository type.

What do you think of handling mail repositories that way?]

[see JamesMailetV3]

Spooler Changes

One thing to consider is that the spool doesn't have to be a store, it just has to use a store. This introduces a number of possibilities:

Protocol-based "fast-fail"

All would be configuration options:

Planned fast-fail types:

Note: RFC2821/4.5.1 mandates the ability to deliver e-mail to the local postmaster. One option is to restrict a "rejected" IP from being able to do anything other than send a single, limited length, e-mail to postmaster.

Currently implemented fast fail allows rejecting relay based upon sender IP. One thought is to add a few more calls that provide a fast fail framework, e.g.,

  - acceptRCPT_TO(), returns null or an error [code, message] 

The acceptance logic would be opaque to the handler. The handler would simply implement the protocol response.

JamesV3/Plans (last edited 2009-09-20 23:31:43 by localhost)