Remote List Administration in Project Lancelot

Overview

In many cases, administrators of Project Lancelot lists do not have access to a shell on the hosting computer. This may be due to security restrictions or because the administrators do not want the hassle associated with having to type obtuse commands at a shell prompt.

This document outlines a proposal for an interface that allows designated administrators to interact with existing Project Lancelot mailing lists by e-mail.

Operation

Administrative actions to be performed on Project Lancelot mailing lists include the following:

  • Manually adding or removing subscribers
  • Manually adding or removing options from subscriptions
  • Changing parameters of the list itself

All of these actions should naturally be restricted to designated administrators of the list.

The current proposal enables these actions by allowing an administrator to send an e-mail message including a selection of commands to a suitable address (e.g., list+admin@…), and to receive a reply message containing the results of the operation(s).

In particular, an incoming message will be parsed line by line. Empty lines and comment lines (beginning with #) will be ignored. Non-empty non-comment lines are considered command lines. Whitespace and quote indicators (>) at the beginning of a command line will be ignored and removed before the line is processed further.

The following commands are supported: 

  subscribe OPTIONS ADDRESS
  unsubscribe OPTIONS ADDRESS
  subchange OPTIONS ADDRESS
  getconfig [PARAMETER]
  setconfig [<<END]

The subscribe, unsubscribe, and subchange commands support the same options as the ll-subscribe, ll-unsubscribe, and ll-subchange command-line tools, respectively. The only difference is that they allow just one address per command, and that this address does not need to be quoted. Here are a few examples: 

  subscribe --nomail Alfred E. Newman <alfred@example.com>
  unsubscribe --nogoodbye alfred@example.com

(As a security precaution, the admin subscription option may not be set remotely using the subchange commands. See Authentication and Authorisation below.)

The getconfig command allows an administrator to review the settings of list parameters. It returns a block of lines formatted like 

  setconfig <<END
  list.address = list@example.com
  list.addressdb = sqlite:
  list.language = en
  ...
  END

These parameters may then be edited and sent back as part of a new configuration message (recall that reply marks at the beginning of a line are ignored by Project Lancelot). If the optional PARAMETER (a regular expression) is given, only parameters whose name matches PARAMETER will be returned by the command.

The setconfig command allows an administrator to change the settings of list parameters. It is followed by a number of list parameter assignments in the format shown above (or, equivalently, described in the ll-conf(1) manual page). These assignments are incorporated in the list configuration and become effective after the message has been processed. The sequence of list parameter assignments extends to the end of the message or (optionally) the first line consisting of exactly the sequence of characters specified after the << on the setconfig line, whichever occurs earlier.

As a precaution, any assignment occurring as part of a setconfig sequence is checked as follows:

  • If the admin.setconfigrefuse configuration parameter is set to a regular expression, any assignment whose parameter name does match this expression will be refused.
  • If the admin.setconfigallow configuration parameter is set to a regular expression, any assignment whose parameter name does not match this expression will be refused.

If both these parameters are set, then admin.setconfigrefuse is checked before admin.setconfigallow, and the end result counts. I.e., an assignment that matches both regular expressions is allowed.

The admin.setconfigrefuse and admin.setconfigallow parameters may not be set using setconfig at all -- they can only be modified using ll-conf(1) on the command line.

Authentication and Authorisation

As mentioned above, it is paramount to restrict administrative actions to designated list administrators. Any subscriber to a list whose options include the admin flag (A in the »long« output of ll-list(1)) is eligible to perform administrative actions.

For security, administrative messages must be authenticated to establish that they have indeed been sent by a bona-fide list administrator. In Project Lancelot, this is handled by means of a generic authentication infrastructure that potentially applies to all list subscribers, not just administrators. Authentication ties an incoming message to a particular subscriber, while authorisation checks that that subscriber is indeed allowed to do administration. (The advantage of a generic framework is that authentication can be useful in other contexts, e.g., with moderation or a web-based frontend that allows users to change their subscriptions, as in Mailman.)

The following authentication mechanisms are conceivable. It is unlikely that they will all be available with the initial implementation of this proposal:

No authentication::

No authentication is performed on incoming messages. Given the current state of e-mail security, this is clearly unacceptable for administrative actions, but this is the type of security that normally applies to ordinary list submissions.

Sender address::

A message is always ascribed to the person named in that message's From: header. Again, this is very insecure as mail headers are straightforward to forge. However, the approach is frequently used in other mail systems for moderated lists. The projected implementation of moderation in Project Lancelot will probably require at least password authentication (see below).

Cookie confirmation::

When a request is received, Project Lancelot sends a message to the purported sender asking for confirmation. This message contains a random cookie that the sender must send back to Lancelot to cause the request to be executed. This is still not particularly secure. Project Lancelot uses this scheme to check subscription and (if desired) unsubscription requests as well as configuration changes.

Password authentication::

A request must be authenticated using a pre-arranged password. This, again, is very insecure in e-mail but may at some stage be used for a user-centric web frontend (possibly based on HTTPS). This approach is used by Mailman.

One-time passwords::

A request must be authenticated using a one-time password scheme (such as S/Key). This is reasonably straightforward to implement and fairly secure against eavesdroppers (as each password is used only once). It might be used with list administrators who are unable to use stronger forms of authentication. Non-technical list administrators will find this approach similar to that used by banks -- they can be given printed lists of one-time passwords to use. The method is not secure against man-in-the-middle attacks (but if, as with Our-ISP, a mail administrator submits administrative messages directly to the server in question using SMTP over TLS, this is not a grave problem).

Signed messages::

A request message must be properly signed using GPG, by a key which is part of the list administrators' keyring. This is the strongest form of authentication, but presumes that administrators have access to GPG software and are familiar with its use.

Proposed Implementation

The implementation of remote list administration consists of five parts, four of which deal with the generic authentication and authorisation problem:

  • For the generic authentication infrastructure, an authentication method table must be added to the subscriber database. For each subscriber, this holds one or more entries giving various authentication methods (from the list in the previous section) together with any supplementary information such as a password or S/Key hash.
  • An authenticate workflow module must be implemented. This module will check an incoming message against the authentication methods (if any) listed in the subscriber database for the message's sender, and reject or pass a message depending on the result. Authentication methods will be implemented as plugins. The workflow module will take a parameter giving the minimum »security level« required, where higher security levels correspond to more secure authentication methods (e.g., no authentication = 0, GPG authentication = 9). This workflow module can be used generically wherever non-trivial authentication is required.
  • One or more plugins for authentication methods, in particular the password, S/Key and GPG methods.
  • The admin flag must be added to the subscribers table, and the ll-subchange(1) and ll-list(1) commands must be changed to support this. (As an extra precaution, it will not be possible to make a subscriber into an administrator when he or she is subscribing -- an additional step by the list owner (or somebody suitably privileged to enter administrative commands at a shell prompt) is required.)
  • A configuration workflow module must be implemented. This module will process configuration commands as outlined above.

Proposed Parameters

We propose the following set of parameters to control Project Lancelot's remote administration capabilities:

admin.setconfigallow::

Contains a regular expression which parameter names of proposed configuration changes must match to be acceptable.

admin.setconfigrefuse::

Contains a regular expression which parameter names of proposed configuration changes must not match to be acceptable.

auth.mechanism::

The standard authentication mechanism to be used with this list. none implies no authentication (the default). The point of this parameter is to make it possible to generate suitable authentication credentials when a person subscribes to the list. For example, a random password could be generated and mailed back to the user with the final subscription confirmation message. (This is not the pinnacle of security, but hey, if Mailman does it so can we.)