• Prepared by: Aaron Stone
• Date: Oct 25, 2006

As of October 24, 2006, the dbmail_2_2_branch has been cut and trunk is open for new development!

Please see the DBMail 2.2 page for status updates on the actively maintained stable branch.

There is no guarantee that any of the items listed on this page will be developed. It is likely that DBMail 2.4 will not appear until late 2007 or 2008. Do not hold your breath on these features.

DO get involved in coding! DO consider sponsoring development!

• THREAD capability.
• STARTTLS capability.
• Use yacc/lex or lemon to rewrite the imap command parser.
• Start sending unilateral server data, and maybe even support IDLE. (done)
• Support AUTHENTICATE CRAM-MD5 RFC 2195

• Redesign the internal message cache system (memcached ?).
• Separate Data such as attachment from the message body (done)
• Split the deliver_to field of the aliases table
• Safer SQL query builder (safer because SQL is never 100% safe ;-)

• Ability to alter the main SQL queries in the config file
• Ability to set daemon response messages
• Multiplex, multithread, multiprocess or Event based(libevent) architecture
• Revamping the trace() call and debugging options
• Better organization of users into groups
• Mailing lists
• IMAP V-Folders - finally, true server-side virtual folders
• System-wide and client-wide Sieve scripts.

• Indexed bodysearches in IMAP
• MAPI, Calendar and shared contacts for MS Outlook / Integration of OpenChange Library

• Broad goals for clustering
• Token passing algorithm

• Integration with Alfresco
• Integration with indexing and document management systems
• Enterprise-grade archiving
• Integration with information lifecycle management and differential storage and backup

• Mailbox's (IMAP) permissions
• Log for received messages
• Log connections for POP and IMAP
• More flexible Auto Replies, Auto Notifications
• Mail Client Settings on DBMail
• Blacklisting Individualized for User
• Individualized Message Filters
• Make default accounts for RFC required addresses, such as POSTMASTER, etc.
• Better options for controlling daemonizing