Things To Do
$Id: TODO,v 1.39 2003/01/23 19:51:55 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.


* Optionally, run as nonprivileged user


* Optionally, don't log to syslog


* Better control over logging verbosity


* POP3 extended response codes (RFC2449)


* setproctitle


* Allow case-insensitive user names.

