This page lists the development plans of the dbmail team. Here you can find the features and fixes that we will be adding in the future. If you have any questions or remarks regarding the development of dbmail, please subscribe to the development mailinglist.

DBMail development will follow a Linux kernel-like model from now on: Stable versions have an even minor version number, e.g. 2.0, 2.2, unstable versions have an uneven minor number, e.g. 2.1, 2.3.

Version 2.2

The following features will be implemented in the somewhat longer term (winter 2004/2005). The features are first implemented in development version 2.1, and will be released as 2.2.

Customisable table names/prefixes

The ability to customise the names of database tables used in DBMail. Some more discussion is needed to decide whether we need fully customisable tablenames, or only custom prefixes. Brian Blood has offered to work on this.

Update: Leif Jackson has provided us with a working patch for this feature. It has therefor already been included in cvs-head. A patch for 2.0 is available in the experimental debian-packages.


An extension that could make some things easier for (web)clients is the IMAP SORT and Thread Extension. From the draft: “The SORT and THREAD extensions to the [IMAP] protocol provide a means of server-based sorting and threading of messages, without requiring that the client download the necessary data to do so itself.” One of the questions is, whether any clients already implement this extension. Without clients implementing this, it would be a waste of resources to implement it.

Update: a sort implementation specifically geared at the squirrelmail webmail client has already been added to cvs.

Sieve scripting

Aaron Stone's LMTP & Sieve scripting patch has the beginning's of a Sieve scripting extension for DBMail. Using this, users can upload scripts to the DBMail server that will be able to sort (send to different folders) their messages on arrival. These scripts are of course stored in the database. Currently, only Cyrus IMAP implements this feature. This extension will use libSieve for interpreting the actual scripts. Because this adds a library dependency, Sieve scripting support should always be optional!

Update: Leif Jackson has updated the libSieve interface to match libSieve's CVS and has written the database layers necessary to support the Sieve frontends that Aaron wrote long ago. At this point, we just need to pester Aaron into releasing a stabilized libSieve. Specifically, the script results API sucks. Yeah, this is Aaron writing this update, too :-P

But who will do the pestering Paul wonders…


Configuration in Database

Put most of the configuration options of DBMail into the database backend. We must find a sane way of doing this. There must still be some stuff in a config file, the database connection info for instance.

Speed optimisations

DBMail should be optimised for speed. These optimisations include the proper use of transactions. Discussion is needed whether or not to support the use of database systems that have no support for transactions (MySQL with MyISAM tables).

Don't know if this is the right place, but please don't keep the lower common denominator.

Version 2.4

This version should make none or small changes to the database model.

Loadable db layer

Some people have indicated that they would like to be able to have the DBMail core load the database layer/driver at runtime. This would simplify things for people distributing DBMail binary packages for instance. Loading the drivers at runtime will mean creating shared libraries (.so files) and loading them with dlopen. A lot of care has to be taken to make this portable to all (UNIX-like) systems. GNU libtool would probably help with this

SSL server

Change the servers to support IMAP-SSL and POP3-SSL. This can also be done by using stunnel, so the question is if we want to go through the trouble of doing this.

Paul: Well actually STARTTLS is required in rfc3501 so I think we should mark this feature as planned.

-Note that stunnel breaks pop-before-smtp/imap-before-smtp by accessing only from localhost-

Connections to other authentication mechanisms

Some users, e.g. ISPs, need to authenticate users against other systems like Radius servers. DBMail should be able to use those authentication mechanisms.

Features that need discussion

The following features need discussion to see if they're really needed in DBMail.

ODBC driver

It could be useful to implement an ODBC driver, which could serve for handling databases that have no native driver. Also, we should add drivers for more databases, for instance for Firebird and SAPDB.

resume writing services online casino

developmentplansandideas.txt · Last modified: 2013/01/09 17:36 by mivpl
DBMail is developed by Paul J Stevens together with developers world-wide