Things To Do
$Id: TODO,v 1.23 2001/11/07 19:25:41 chris Exp $


* 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. (This can now be done with
  auth-other or auth-perl, but it might be desirable to have it in the main
  program.) I do not intend to implement support for additional databases,
  since it seems better to use the existing code in the various perl DBD
  modules from auth-perl.


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


* More example scripts and configs

  These would be handy, especially for answering user questions. In
  particular, some configurations are quite common in practice but not
  directly addressed by examples here; for instance, POP-before-SMTP relaying.

  Also, not everyone likes perl; some non-perl examples would be good.


* Secured Sockets Layer support

  It is possible to use tpop3d with an SSL proxy such as stunnel; 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.

