Things To Do
$Id: TODO,v 1.32 2002/06/25 20:28:00 chris Exp $

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


* Internationalisation

  The long-term plan is that tpop3d should support internationalised messages
  for server responses, log messages etc. (I have already received Polish
  translations for the server responses, but these have not yet been
  incorporated into the code.) This will be done with GNU gettext; hence,
  strings should be wrapped in _("...") as described in the gettext `info'
  documentation.

  But this doesn't do anything yet :)


* Asynchronous authentication

  The major architectural problem in tpop3d is that the main server, which
  performs authentication, is single-threaded and authenticators block its
  execution. This is not a significant problem in most environments, but it
  would be preferable to fix it. It is a more serious problem with auth-other,
  since a failed external authenticator program could potentially delay all
  authentications by auth-other-timeout.

  The vague plan here is to run some authenticators in separate threads, and
  to put connections into an intermediate `credentials received, awaiting
  authentication' state while the authenticator does its stuff. There are a
  couple of subtleties to do with shared data structures, which will need to
  be reference-counted, but fundamentally this approach ought to work. Each
  authenticator would then have a queue of connections to authenticate. This
  means that thread-unsafe functions such as strtok should be avoided in new
  code.
  
  An alternative is to use the fork-on-alarm idiom, where a timer is set
  immediately prior to embarking upon a potentially-lengthy operation, and,
  if the timer fires prior to the operation completing, fork is called in the
  signal handler and the child continues the long operation while the parent
  carries on doing whatever it was doing before. The problem with this
  approach is that resources which cannot be shared between parent and child
  (such as database connections) must be disowned by the parent and
  reacquired. This is feasible, but would require careful thought.


* Secured Sockets Layer support

  It is possible to use tpop3d with an SSL proxy such as stunnel or tlsproxyd,
    http://ex-parrot.com/~chris/software.html#tlsproxyd;
  however, there are advantages to implementing such support natively in
  tpop3d; in particular, it is more compatible with POP-before-SMTP relaying.
  There is example code in the OpenSSL distribution which would serve as the
  starting point for an implementation. However, there are issues with
  blocking and non-blocking calls. The current plan is to have tpop3d fork
  a process to handle TLS, while the main daemon carries on doing its stuff.


* Obey --sysconfdir.


* Mass-hosting option

  At the moment, if tpop3d listens on 0.0.0.0, the append-domain option can
  only be used with one specified domain. Although Matthew Reimer's addition
  of the $(serverhost) variable to the authentication code permits a workaround
  for this, it would be helpful for tpop3d to be able to infer the domain name
  from the actual IP address to which a connection is made.


