[Mailman3-dev] Problem with the schema

[Donn Cave]

On Thursday, March 31, 2005, at 03:21 AM, Ian Eiloart wrote:
> --On March 31, 2005 02:05:36 -0800 J C Lawrence <claw at kanga.nu> wrote:
>
>> On Thu, 31 Mar 2005 10:40:46 +0100
>> Ian Eiloart <iane at sussex.ac.uk> wrote:
>>
>>> Alternatively, viewed from the perspective of a subscriber, rosters
>>> are internal nodes and lists are leaf nodes. This isn't really a tree
>>> - it's a net.
>>
>> It becomes more complex when/if you want to support the concept of a
>> user having an account with the system,
>
> Yes, I do want to do that. In fact I want two types of account: local 
> and non-local. A local account is one that is already defined on my 
> LDAP (or whatever) servers - they're students and staff on my campus. 
> A non-local account type would be closer to what Mailman has right now 
> - it could use any non-local mail addresses.

For what it's worth, that's exactly what we do here (University of 
Washington
central site.)  This morning I count 9308 lists, 115676 site local list 
members
subscribed under 117610 email addresses.  Couldn't say without a lot 
more work
how many external members.

> The distinction is important for several reasons:
>
>    1. I know who local people are, and I can take action against them 
> if they misuse lists. Therefore, I can allow them greater permissions. 
> My instinct would be to allow local accounts to post to ANY of my 
> lists, at least by default. I'd want to be able to revoke that for 
> some lists, and for some individuals.

Only site local members can administer a list, for this reason.  
Posting is
governed by list membership as usual, though.  I think this is the list
admin's call, not the site admin's, and Mailman already supports that 
pretty
well out of the box.

>    2. Local users shouldn't have to go through the same sign-up 
> process. I already know their email address, and their authentication 
> credentials. I might want to have them agree to some terms and 
> conditions before making their first post, though.

Check.  For on site users, HTTP access can use web "single sign-on", 
which
is better for several reasons and allows us to skip the confirm ritual 
for
subscription.

>    3. A site should be able to define which are local addresses (a 
> list of regular expressions), and decide whether Local accounts can 
> register non-local addresses.

We use a database that maps site local identifiers (login names) to the
email address as used to sign up.  Often the latter is closely related
to the former, but by no means always.

> An additional complication: here a person may have one account with 
> several mail aliases (I'm iane AND i.eiloart, for example). But they 
> may also have several accounts. Management of people with several 
> accounts may be beyond the scope of Mailman 3 - but it may be that 
> there are design decisions (name spaces, for example) that could be 
> influenced by the need to allow for this in the future.

You're iane and i.eiloart outside of Mailman?  I think that would not be
Mailman's problem.

> And, when it comes to addresses... We manage many mail domains here. 
> Some are synonymous (susx.ac.uk and sussex.ac.uk, for example), and 
> others aren't. Mailman should permit me to define synonymous local 
> mail domains so that when iane at susx.ac.uk is allowed to post to a 
> list, then iane at sussex.ac.uk is too.

Yeah, this is one we haven't tackled.

Anyway, this obviously took quite a bit of changes to Mailman, but it 
was
certainly worth it for our site, I can't imagine trying to support the
out-of-the-box model here.

The code is available via http://staff.washington.edu/donn/UWmm.html
We have had some inquiries, though I can't say for sure anyone else
has actually deployed it.  It isn't trivial to apply these changes
and make them work at your own site.

	Donn Cave, donn at u.washington.edu