mlist

the title says it all. i finally got off my but and submitted the patch
to the sympa developers to support seperation of identity and email during
authentication in support of shibboleth and myvocs. many thanks to the
sympa team in helping develop this patch.

[phpwiki]
an issue to deal with when picking an application as the vocore is that
you'll need to map its abastractions and terms into the general system
environment. for example, we're using a mailing list as the vo core which
speaks of lists and subscribers. this is a general groups and members
concept. unless web interfaces are redefined to use a vo-specific naming
convention then users need to map these concepts themselves.

an advantage of using a mlist as the vocore app is that end users can
self regsiter for group membership and there is a concept of administrator
approval for membership. another aspect is that this instantly gives

[phpwiki]
I've set up a [wiki for the mlist project|http://webapp.lab.ac.uab.edu/wiki/mlist]. This will be where contributors can easily add to a [glossary of terms|http://webapp.lab.ac.uab.edu/wiki/mlist/index.php/MlistGlossary] and contribute to the [mailing list developer howto|http://webapp.lab.ac.uab.edu/wiki/mlist/index.php/MlistDevHowTo]. Please check out the new pages and let us know what you think.

feel like we're getting to a good point of having our raw materials to the
point of some integration that will lead to useful outcomes. combining
the three diagrams into a developer guide book is really doable and having
the target of the that guide be the pycon2005 mailman developers seems
like a workable goal.

It's desirable to allow multiple members of an organization to share a
single mail list subscription.

This would let an org, say a lab with developers, monitor list traffic
centrally for a list of interest, eg. you could have a local archive page
for a specific list like ogce-discuss. If the any of the developers wants
to participate in the list or ask questions, they can post under the
authority of the common subscription. (The post might show up on the
remote list as being from "member of devel group" .)
The content of the message could of course reveal the individual identity,

I want to comment a little more (concisely?) on some of what I was
saying on the call yesterday.

I feel like a lot of the web interfaces of the mail list tools (and web
tools in general) have an account-action authorization model. That is,
they define a (sometimes long) list of actions that can be performed in
the application, like "post to list" "moderate" "subscribe" etc. They
then go about associating accounts with the actions they can perform.

When per-account assignements become combersome, the tools typically move
to a role based assignment of authorizations. This allows you to assign

On our call yesterday I mentioned one way to perceive the interface points
for middleware in the mailist space is to imagine a mail list service not
composed of a single application but as a collection of best-of-breed
apps: message distribution engine, archive viewer, and message composition
tool.

This is a link to a 3rd party site that provides list archive services:

http://www.mail-archive.com/about.html

Another method of archiving is via NNTP. This site is another 3rd party
service.

http://gmane.org/about.php

Both of these tools are nice stand alone services that could be collected

[phpwiki]
Found an article on the sympa site that nicely describes the authn/z
features.

http://www.sympa.org/documentation/AA-in-Sympa/

Looks like sympa is already well along the path of the features we are
discussing. This will help highlight the interfaces necessary for
directory service integration.

Looks like mm3 code is available via cvs on sourceforge

http://cvs.sourceforge.net/viewcvs.py/mailman/mailman3/

Follow these instrux and use the mailman3 module to access it

http://sourceforge.net/cvs/?group_id=103