[Mailman3-dev] Problem with the schema

J C Lawrence claw at kanga.nu
Fri Apr 1 05:26:08 CEST 2005

On Thu, 31 Mar 2005 11:20:35 -0600 (CST)
John-Paul Robinson <jpr at uab.edu> wrote:

> The options you mention seem to be attributes of accounts, addresses,
> rosters, and lists.  Owners, admins, users can set the attributes and
> then as the message "moves" through the delivery net
> (list->roster->address->account)...

Why is an address subscribed to a list?  Why isn't it the account which
then specialised delivery to one of its addresses?

> Then there are some lists which just apply the list-level attribute
> filters and simply rely on the (list->roster->address) path for
> delivery address expansion.  That is, you will get the message as long
> as it meets the list criteria.  Yuck.  That could get ugly.

I tend to like looking at these sorts of problem sets as process queues
(in the MQS sense).  At that point its really is just an FSM with nodes
linked by message-passing (not email messages), and certain state
transforms able to fork the FSM into multiple new/distinct FSMs.  The
problem with this view is collapsing the delivery space: a given email,
having entered the system, could have spawned a dozen leafnode states by
the time it gets ready to exit the system, each of those states ready to
dump the email out to an arbitrary set of email addresses extracted from
accounts.  The (a) problem is then coalescing the leaf states for
duplicate address removal.

> Seems like it may be best to just have (account,address,list) tuples
> for attribute setting and matching.

Ehh?  Why?  Intuitively the following approach seems workable:

  - Rosters are the primary data type.

  - Rosters are composed of accounts.

  - Accounts contain one or more email addresses and policies to
  control/direct message flow to/for/from those addresses.

  - Email addresses are special cases of rosters, and have all the
  properties and capabilities of rosters (same base type).

  - Lists are accounts with sextra meta-data.

  - Lists are special(ised) in that they (more easily) accept mail
  injections from sources outside the system.

  - Accounts normally only accept mail from other components within the

  - Policy statements glue everything together.

  - Polices decompose into state trees.

  - Emails entering the system are dropped into a list (as a specialised
  account that accepts external mail by policy definition).

etc.  The final system would probably consist of a few score small
cooperative executables, each of which is responsible for one narrow
class of state transforms for the set of possible FSMs.  (Do one thing,
one thing only, and do it well) The FSM set can then be
represented/stored on the filesystem (my preference), or in SQL tables
as appropriate, subsequent processes initialising from that store and
then transforming it to the new state.

> Just thinking this through out loud.


J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

More information about the Mailman3-Dev mailing list