This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. Last Updated 10 December 2002.

Determine a way to support multiple domains.

Revisit UserRepository. The interface must support multiple authentication types per user, aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able to associate attributes with users in the repository.

Revisit the MailRepository interface and associated implementations. Special consideration is necessary to support IMAP Search functionality. It should be possible to associate attributes with mail messages stored in the repository.

Revisit the SpoolRepository implementations and do away with the current exception-generating two-phase message retrieval.

Define a simple mechaism for addressing repositories in a uniform way.

Add support for mbox mail file repository.

Add support for the maildir file repository.

Add support for DRAC login/relay authorization. This feature records the IP addresses and times of POP3 logins. SMTP connections from these same IP addresses are considered authenticated if they occur within a fixed period of the POP3 authentication.

Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.

Add support for the enhanced status codes extension (RFC 2034).

Add support for the 8BITMIME extension.

Expand the SMTP server so it supports a variety of SASL authentication mechanisms.

Complete support for delivery service notification (RFC 1891).

Discuss optional support for VRFY and EXPN.

Discuss some form of spam filtering that would allow filtering before messages are fully read in from the network.

Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).

Add #news namespace to IMAP system

Give admins the option to enforce one access at a time to a POP3 mailbox.

Refactor NNTP code base.

Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.

Write a list server implementation with functionality comparable to ezmlm. This would include the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms, and a full suite of mail-driven commands.

Update code base to use Serviceable/ServiceManager rather than Composable/ComponentManager. This requires an effective change in how we expose components through the Mailet API.

Discuss and design the next revision of the Mailet API.

Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)

Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern

Get classloaders working so custom mailets don't have to be in james.jar (SK: I suggest adding support for apps/james/classes and apps/james/lib directories and have the MailetLoader and MatcherLoader use these in addition to system level classpath).

Add support for deployable message processing apps using Camelot pattern

Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.

Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.

Add support in the RemoteManager to manage repositories. This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.

Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.

Document instructions on configuring logging in James.