mlist

Looks like Mailman 3.0 is being fleshed out.

The dev page shows some future plans for the tool that are relevent to
our efforts:

http://list.org/devs.html

The 3.0 flesh-out site is:

http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/MailmanThreePointOh

Of particular relevance is the potential for mm3 to leverage zope. It's my
understanding that work is underway to integrate shib/zope. This may offer
some significant out of box integration.

the basic idea for a self registration site needs to be that a user can
determine what federation they are from and then either auto-login based
on an existing affiliation in the fed or join the friends zone. this can
let users span across several apps. there is still the need for an
application local user. but this doesn't necarrily need to be exposed, eg.
interface for admin/root to log in to a specific app. when thinking about
standalong orgs though, or all self registered orgs, people aren't really
joining the friends of. in that case they are the organization itself.
the friends of service is needed only if your site has a dominate user

slapd built and installed.

./configure --enable-dnssrv --enable-hdb --enable-ldap \

[textile]

h1. I2 Campus Survey: Mailing List Software

intro re: MACE-MLIST & purpose of survey

# Which list management software id used on your campus?
## By Central IT
## In use outside central IT (please forward to these users)

|_.Name|_.Version|
|LSOFT ListServ||
|Mailman||
|MajorDomo||
|Sympa||

2.What were the main reasons for selecting this list management software over other choices that were available?

3.How many lists are managed with this software?

4.What are the list management’s most desirable features?
(Describe an occasion when a feature would be used (or not used))

did a poor job of recording tasks today. spent the afternoon split between two projects, storage and mlist. Started recording my namespace understands and wishes for the storage project and documented the home automounting config. Set up a test rss gw list feed for the mlist project.

http://www.mailbucket.org/

MailBucket is an experiment in alternative methods of email management.
The service is probably most useful to those who lurk on high-traffic
mailing lists, but it could also be used as a rudimentary bridge between
applications, with email as the transfer protocol.

bring up an nntp interface to the lists to help force the thinking about
the spread of the archives and what it means for authz issues in this
space. we'll have archive access on a list-specific page provided by the
listmgr tool, archives via a website (cms/forum/bboard system), archives
via nntp, archives via imap, archives via rss.

it should be possible to subscribe to any one of these services. the key
in the authz space is really to determine if you may subscribe.

i wouldn't mind having all or a lot of the content running across the
website also running across a list. so most of my posts should be going
to the devel list and then appearing on the site. this would enable
conversations to occur in any space (website or email). (thought. if you
subscribe to my blog you could almost think of it as subscribing to the
"jpr@uab.edu" or "jpr@lab.ac.uab.edu" list or channel.)

this also brings up the point that the website (posts and discussion
forums) are really more like nntp or even imap since your talking about
views into common message stores. the mail list traffic is really just the

the lists.u.washington login sequence is a simple wayf, if from
u.washington login here else login there. this type of
"enterprise&friends/others" wayf will be a typical user collection
senario.

thinking about the cosign implementation and comparing to pubcookie and
shib, you can think of them as an ever increasing scope of user bases.
pubcookie is single domain, cosign is two domains (enterprise and friends)
both "hosted" but the same site, and shib is a 2 or more solution though
the complexity of shib suggests you better have a lot to justify the work.

Debian testing has nicely packaged sympa so it's a lot easier to install,
simple "apt-get install sympa". Although it's the 3.4.4 release, it
installs all the perl dependencies. This should make it easier to build
4.1.1.

The docs for sympa are ok. They cover the bases but the english is a
little light (forgivable since it's the second language). This makes it a
little frustrating though to feel confident about the config of the
shib/cas/sso stuff.

This, of course, all ties into the vo business. There are, seemingly, a
hundred and one tools needed to set up a vo and each vo is going to have