Re: Majordomo 2 workers

[Jason L Tibbitts III <tibbs @ math . uh . edu>]

To those on majordomo-workers, I've received permission to move this
discussion into a wider forum.  Mr. Adkins has some features he would like
to have in a MLM and thinks that Mj2 might be a good base to start from. 

My basic response is that we're a way too far into development to change
course now, but that it might be possible to bend things a bit to get some
of this to work.

I will forward the original message later so you can see it un-hacked.

>>>>> "SA" == Stephen Adkins <spadkins@internetdynamics.com> writes:

SA>  * hierarchy of lists (similar to news) rather than a set of lists

There is a plan to support some kind of "meta-lists" built out of the
registration database.  That database holds enough information to generate
duplicate-free lists of addresses matching various criteria.

What differs is that meta-lists would be the exception; since the
meta-lists don't exist as real entities they don't have a real
configuration system and users can't set per-list parameters for them.
(You could take the parameters from the first list of membership, or you
could override the whole system and give users only global parameters,
which I find wholly unsatisfactory for the general case.)

So that probably doesn't do it, unless you expect that the meta-lists would
be used only rarely.

SA>  * configuration obeys scoping rules i.e. config parameters for
SA> "company" apply to all subsidiary lists unless explicitly set.

It wouldn't be too terribly difficult, but the configuration system is not
tree-structured.

SA>  * node aliasing different names can exist for a single list, but the
SA> permissions are managed through the node hierarchy.

Dunno.  Sounds kind of weird.  You want a tree, not a directed graph or
else you have lots of problems (loops being one of them).

SA>  * security is commercial-strength

Marketing-speak.

SA> i.e. a list may be configured to be "public" (open to subscribers who
SA> have been granted membership in the list immediately above). Other
SA> lists may require a request to be sent to the list administrator and he
SA> may grant membership. Integrated with PGP or other e-mail
SA> encryption/authentication schemes.

PGP would be nice.  Security in Mj2 is essentially pluggable anyway.

SA>  * membership in a list obeys a strict hierarchy i.e. You must belong
SA> to the "company" list in order to apply for inclusion in the
SA> "company.finance" list (and so forth). If a user's membership is
SA> removed from "company", his memberships in all subsidiary groups are
SA> implicitly revoked.

We have only one level of that: registration(many) -> list(one).

SA>  * ACL (access control list) level access i.e. each user has
SA> READ/WRITE/ADMINISTER/NONE privilege on each mailing list.

User-based security doesn't work unless you base it on passwords (or PGP,
but we won't get to that point until some time after a Perl module is
written) because addresses are trivially forged.  We have a password
hierarchy in place already.

SA>  * all lists referred to by a single e-mail address, differentiated by
SA> the subject line

Ug, that is horrible, but I suppose there is no other alternative given
that clients don't support adding headers.  The problem is that you will
end up with subject strings so long that they get truncated by some loser
client software (40 characters).  And since you base everything on the
subject...

SA>  * each new message creates its own sub-node i.e. a message to
SA> "company.finance" gets sent out with a message number appended to the
SA> topic.

You probably want to look at HyperNews here; it does this already.

SA>  * complete integration of mailing lists with a web site i.e. all
SA> functions which are achievable through e-mail are also achievable via
SA> the web

The front and back ends of Mj2 are separated; the interface is irrelevant
to the internals.  (You can even post with a command if you like.)  A web
front end needs to be written anyway.

SA>  * supports e-mail authentication creation of a single userid per user
SA> on the web site users can claim ownership of many e-mail addresses for
SA> simple (not really secure) authentication of
SA> e-mails.

We already have this using aliasing.

SA>  * written in Perl 5 in object-oriented fashion can be installed and
SA> run with no special privileges on an ISP web hosting arrangement

The first bit is more marketing-speak.  Requiring a specific language is
humorous; use whatever tools are adequate for the job.

Running without special privileges is impossible for some MTAs/web servers.
If the system software cooperates we already have this (i.e. MTA must
change user before delivery; web server must change user before running
CGI).

SA>  * What are your comments? Are these dumb ideas? Are they in keeping
SA> with the spirit and direction of Majordomo 2?

They are not dumb and many are doable but Mj2 has gone in a different
direction.  If you had come to me with these ideas when things were in the
design phase instead of when the code was essentially done (i.e. now) then
there would be a much better chance, but now much of this would require a
rewrite of large portions of the code.

Which isn't to say that it isn't doable, but that I have to concentrate on
getting the thing out.  I can't turn around now and chase after something
else but I am willing to change course a bit in that direction.

For some internals:

It is obvious that the two-level hierarchy (registration -> list) is
insufficient for what you want to do.  More appropriate is a has-many
relationship between lists, with each list keeping its own subscription
database.  A subscribe to list 'a-b-c' (don't use dots; they have special
rules in RFC822) also subscribes you to 'a' and 'a-b' unless you're already
there.  You can do a top-down security search, so 'a' has to approve it
first, then 'a-b' and finally 'a-b-c'.  You can exploit the defaults
mechanism for configuration to do the config inheritance.  This actually
solves most of the problems.

To get the subject-filtering you just need one front-end that extracts the
list from the subject and calls the backend, instead of taking it on the
command line or from the environment like we do now.  This is pretty easy.

The bit about each thread being a separate list is tricky; if your primary
goal is to have users explicitly opt-out of a thread than you can store
some additional data in the subscriber database about what threads a user
doesn't want and just not send the message to them under certain
conditions.  We already do this depending on their settings and what's in
the To: and CC: headers, so this isn't much of a stretch.  If your goal is
to require explicit opt-in to a thread (which I don't think is a good idea)
then you need some other method.

For PGP or GPG or other strong authentication, an existing Perl interface
really is required.  Once that's done it shouldn't be too terribly
difficult to support it.

So it is actually doable, although I can't really do any work on
implementing it unless the economics of the situation change radically
(i.e. someone hires me to work on this).  And I'm really going to resist
any kind of change that interferes with management of the usual type of
mailing lists.

Anyway, it's really late, so forgive me if I haven't gone into enough
detail or if I've been unclear.

 - J<