[Mailman-Developers] sender-based authorisation

[David Lee]

Mailman: Proposed sender-based passwords
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note: this is based on Mailman 2.1.8 which, at the time of writing, is the
current version.

A discussion "approval password linked to sender rather than list?" on
mailman-users around 15 May 2006 agreed on the desirability of a variant
of the "Approved: password" mechanism, whose permission-granting password
would be associated with the email's sender rather than with the list.

The motivation is large sites with many "announcement" lists (in our case
over 2,000), where the entire membership of each such list is moderated,
and where several legitimate senders might regularly need to post single
emails to several lists.  These lists might well exist in clusters.

But the option of allowing unmoderated access for those legitimate senders
opens up a major problem with spoofed email.  So everyone needs to be
moderated.

But then the potentially useful moderation-bypass "Approved: listpw"
mechanism has the problems of requiring many people to share a particular
list's password, and of the passwords across a cluster of lists having to
be common.  This "shared secret" problem grows even more alarmingly if the
list clusters overlap which would force reduction to a single password
across many lists, and widespread knowledge (hence leakage potential) of
that password.

Introducing an "Approval:"-like mechanism, whose password is associated
with the sender ("From:"), is intended address all this.


Virtual host considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mailman is beginning to allow some virtual hosting (i.e. multiple domains
("... at dom1", "... at dom2").  Although this is currently limited (cannot have
the same listname at multiple domains) it is clearly on the roadmap for
the future.  Accordingly this password proposal attempts to take full
account of that direction.


New "sender" role
~~~~~~~~~~~~~~~~~

Currently, according to "Mailman/SecurityManager.py":

   # There are current 5 roles defined in Mailman, [...]
   # user, list-creator, list-moderator, list-admin, site-admin.

That is, five contexts in which passwords are used and supported.

Clarification: "user" means the intersection of a particular email address
and a particular list: the (in)famous "monthly password reminder" entity.
Put another way:  the same person (email address) on 'n' different lists
is actually 'n' unrelated "users".

A new "sender" role is proposed, available across all lists at all virtual
hosts. It is implemeted as a site-wide database of email addresses and
their passwords, with the same variety of options for encryption and
storage as in (or potentially in) the other databases.  Across virtual
hosts it similarly remains the same, common, sender.

Clarification: Unlike a "user", this is a single stored-once entity,
representing a single email address across the entire installation.

In each list a new list-admin function maintains a set of email addresses,
herein called "authorised_senders", that can post through the list.  On
the GUI, this would present a little like various "*_these_nonmembers".

An incoming email can specify "Authorised: sender-password" in the manner
of the existing "Approved: list-password"  mechanism (headers, first real
blank-separated line, etc.).

[Note: I have chosen a separate word "Authorised:".  Perhaps we can
conflate this new concept onto "Approved:" if there would be no loss of
functionality.  If so, then "authorised_senders" should perhaps be called
"approved_senders".]

Its processing confirms the "From:" in the list's "authorised_senders",
then does an authorisation check against the site-wide "sender" (role)
database.  (If we conflate "Authorised:" and "Approved:", the password
check would potentially need to be done on both the list and the "sender"
databases.)

If an incoming "Authorised:" email is destined for several lists, perhaps
at several virtual hosts, its "From:" is processed within each list as
described above against the site-wide "sender" database.


Maintenance of "sender"
~~~~~~~~~~~~~~~~~~~~~~~

The new "sender" database requires maintenance.

Insertion:  How are email addresses and their passwords added?  How is it
requested?  By whom or by what is it implemented?  What should be done to
detect and prevent malicious (spam-like, DOS-like) mass sign-up?

Deletion:  How can an email address be removed from the database?  When it
is removed, how is that reflected back into all the lists which had it in
their "authorised_senders" table?  (Analogous to removing a file in a
filesystem but leaving behind dangling symbolic links.)  Should those
lists be left alone (but now containing redundant entries) or should their
tables be amended?  Suppose the deletion from "senders" was accidental or
transient: how can any removed entries in the several "authorised_senders"
tables be efficently restored?

Changes:  How does someone maintain (change) their email address and
password?

If a person changes their email address how is that reflected back to the
lists?  (See "Deletion".)  Intuitively, the database key would have been
the email address.  But perhaps the real key should rather be some opaque,
unique (UUID-like?) entity, with the email address simply being an
attribute.



-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :