Things To Do
$Id: TODO,v 1.46 2003/11/24 19:58:28 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.

* More sophisticated configuration model

  Something like Exim's text substitution language would probably make life a
  bit easier in complex configurations, at the risk of making tpop3d's code
  much more complicated.

* Optionally, run as nonprivileged user

* Optionally, don't log to syslog

* Better control over logging verbosity

* POP3 extended response codes (RFC2449)

  I suspect nobody cares about these.

* setproctitle

* Allow case-insensitive user names

* Automated test scripts

* Non-constant UID in auth-flatfile

* Undefine IGNORE_CCLIENT_METADATA when we don't have BSD mailspool support

* Warn if configuration files or private keys are world-readable

* Fix the libcrypt/libcrypto/crypt(3) linking-order issue identified by
  Travis Miller (emails of 20030820)

* Offer an option to disconnect users who fail to issue STLS before USER

* Underlying connection closed... TLS bug (email of 20030906).

  Probably now fixed (email of 20031105).

* Log statistics on transactions (email of 20031013)

* Cache results of authentication for a few minutes, to improve performance
  under high load?

  The problem with this is that, to be useful, we need to cache the information
  for a time which is long by comparison with the interval between mail checks.
  The latter is a few minutes, so we'd need the things to stay in cache for an
  hour or so. Is a one-hour latency in propagating password changes acceptable?

* Latency vs. throughput tradeoff under high load?