Things To Do
$Id: TODO,v 1.8 2001/04/13 13:17:04 chris Exp $


* More portability

I only use tpop3d on Linux, but would be interested in getting it running
elsewhere. This is likely to happen only on a case-by-case basis, since I
don't have access to that many machines to play with and my time is limited.

In addition, the mess of mailspool locking should be investigated and better
documented for the various platforms on which tpop3d runs.


* More authentication schemes

Virtual-domain schemes which use /etc/passwd-style flat text files seem to be
popular, but I do not make use of anything like this. However, it would be
relatively easy to implement such a thing.


* A proper code audit

tpop3d is, as far as I know, free of obvious security deficiencies. I do not
believe that it contains any buffer overruns, and it does not make use of
temporary files, so is unlikely to suffer from /tmp race conditions. I have
thought about denial-of-service attacks, and I think that it is safe from the
most obvious ones. Nevertheless, a full security audit would be desirable.


* `Autoconfiscation'

Editing Makefiles may be the way "we" did things in the good old days, but
nowadays even people like me who don't believe in package management do
believe in ./configure.


* Maildir support

A number of people have expressed interest in a version of tpop3d which
supports the `maildir' mail-spool format of qmail. Maildir has the advantage
of being lock-free (it is implemented using a set of operations which ought to
be atomic on a POSIX system) but requires a filesystem which copes gracefully
with directories containing thousands of files. If enough people are
interested, I will implement this.


* Index-saving support

One of the deficiencies of the BSD mailspool format is the parsing time at
startup; a way to avoid this is to save metadata (message offsets) for each
mailspool, and re-use this information whenever that mailbox is opened. This
is a good optimisation for the case where a user leaves an enormous amount of
mail on the server, and checks their mailspool more frequently than they
receive new mail. (Some would argue that another, even more effective,
optimisation would address the behaviour of the user rather than the
software).

