On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:

It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.

Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing. If the design and API proves stable, then perhaps it'll make sense to integrate it with the core for 3.1.

Cheers, -Barry

...

...

Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing.

if: there was an “application data” table:

———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server

and: the ability to set domainowner and serverowner permissions in 3.0,

then: there would be a huge payoff in terms of avoiding the downstream challenge of migration upgrade scripts, data migrations, testing, backups, the risk of something going wrong for the end-user sysadmin.

else: the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server, and later needing to work out how to migrate these back into Mailman core in some later version - I’m thinking that if those tables were there in Mailman 3.0 rather than say version 3.1 then a vast amount of downstream work, risk and thinking could be saved (for me). Not insurmountable but would really take alot of engineering to do safely. Getting random sysadmins to do stuff like data migrations that is a little anxiety provoking.

David Murray, who does the Python email package, implements APIs as “provisional” so they are not part of the official release but are present in the code, until some version further down the track where he formalises the provisional API following road testing and feedback. Sort of a logical separation for experimentation and testing. Could that be a way to implement an application data table and serverowner and domainowner permissions in 3.0? That way, consumers of the REST API can use the provisional API functionality at our own risk that it might change before being formalised. I’d take that any day over the need to write stuff that a random sysadmin could run to migrate their data into a new table structure later.

Implementing an application data table and domainowner/serverowner as “provisional” would be a stitch in time for me anyway.

As I mentioned I’ve done it myself anyway in the auth server but theres a bunch of unaddressed challenges relating to replication and synchronisation - whenever the application data is accessed, there needs to be checks to verify that both the user and the resource actually exist in Mailman, and there’s no easy way to know when users and resources have been deleted from Mailman, potentially leaving stale application data.

As always though, I’m not super attached to the outcomes - you’re the boss Barry so I’m OK with whatever path.

as

On 22 Feb 2015, at 5:05 am, Barry Warsaw barry@list.org wrote:

On Feb 20, 2015, at 07:25 PM, Andrew Stuart wrote:

It’s workable as a part of the auth proxy but feels like it would fit better in the Mailman core database since the data is so tightly bound to Mailman resources. It’ll need an effective replication mechanism to ensure consistency with Mailman which is a challenge I’m not relishing solving.

Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing. If the design and API proves stable, then perhaps it'll make sense to integrate it with the core for 3.1.

Cheers, -Barry

Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...

Security Policy: http://wiki.list.org/x/QIA9

Yes that’s a reasonable line of thought Stephen. You are correct I haven’t made any attempt to integrate with enterprise auth systems. Also, I’ll avoid describing my auth server as ‘the auth server’.

Is there anything that would define what sort of functionality is required for enterprise integration?

The two things that I’ve suggested might be worth including in the core are hopefully of broad value and not specific only to what I’m doing. (rounding out the permissions, with serverowner and domainowner, including an application data table that stores keys and values).

thanks

as

On 22 Feb 2015, at 9:36 pm, Stephen J. Turnbull stephen@xemacs.org wrote:

Andrew Stuart writes:

...

...

...

Do you think this has to be integrated into the core for 3.0? I'd still prefer to keep it separate for better experimentation and testing.

the alternative for me is to go ahead with deploying application data and domainowner and serverowner into the auth server,

I disagree with the implicit assumption right there. From Mailman's point of view, this is *Andrew's* auth server, not *the* auth server. If we're serious about serving the enterprise, we need to figure these things out、because Mailman is going to need to plug into an existing auth and user database system.

I don't know if we care any more, but enterprise integration used to be a goal. It's still a requirement of some of our most loyal users (universities, who FAQ us about using their databases to populate lists for classes etc every year).

Hi Ian,

Thanks for the info. I’ll have a look.

as

On 24 Feb 2015, at 12:14 am, Ian Eiloart iane@sussex.ac.uk wrote:

On 22 Feb 2015, at 22:10, Andrew Stuart andrew.stuart@supercoders.com.au wrote:

Yes that’s a reasonable line of thought Stephen. You are correct I haven’t made any attempt to integrate with enterprise auth systems. Also, I’ll avoid describing my auth server as ‘the auth server’.

Is there anything that would define what sort of functionality is required for enterprise integration?

For the University of Sussex, UK, we’d love to have LDAP integration to authenticate users against either an OpenLDAP or an Active Directory server. I don’t think there’s much difference, except in the construction of DNs from usernames. We’d need the ability to (a) find a user with an LDAP search, then (b) perform authentication against the LDAP database.

For bonus points, when registering the user, you could also pick up the user’s email address and name from the LDAP database.

However, while some lists are exclusively for local users, others might include third parties. For example, a list might support a multi-institution research project. So, we need a protected username name-space, too. And, we can’t assume that local usernames map to email addresses, either. So, the email address foo AT sussex.ac.uk might not belong to username foo.

Oh, and we probably need to support multiple local domains. Particularly subdomains of sussex.ac.uk.

On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:

there was an “application data” table:

———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server

and: the ability to set domainowner and serverowner permissions in 3.0,

No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).

The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.

The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.

So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.

For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.

Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.

Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.

Cheers, -Barry

Andrew Stuart writes:

I am currently associating users, not addresses with these permissions, so your suggestion is compatible with my stuff.

+1 on associating users with permissions (plus the validation Barry recommends).

site owner does sound more appropriate than server owner.

Users think of "site" as being nearly synonymous with "domain", though. I don't think we should use "site" in a different way, that would confuse them.

There should be a way to contact the actual operator of the host, which I think of as "hostmaster" or "server owner".

Steve

On Feb 24, 2015, at 07:53 AM, Chris Nulk wrote:

Also, I believe I remember a goal for Mailman v3 was to have one instance of Mailman be able to host lists for multiple domains.

Yes, but not on physically distinct hosts. Or in other words, yes MM3 supports virtual domains

Given that information and information from Andrew and Stephen, there are several different layers of "ownership". Thinking about it a little, I see:

"Owner" Description

---

List Owner can administer a list Server Owner can administer all lists on one server (server may host multiple domains) Site Owner can administer for all lists at a site (site has multiple servers) (site is a physical location) Domain Owner can administer for all lists for a domain (domains may be hosted on multiple servers possibly across multiple sites)

Note: if site is considered a physical location, then an additional owner permission may be "Host Owner" for all their sites at different locations

I think the distinction between server owner and site owner as described above doesn't exist, or I don't quite understand the definitions. Multiple servers isn't a concept embodied in Mailman anywhere. For example, if you were to run a hosting provider and had clients at A.example.com and B.example.com, and they ran distinct Mailman servers, the two wouldn't have any organizational or administrative overlap, except at a higher level, e.g. postmaster@HOSTING.example.com. That's not something I see Mailman having to represent in any useful way.

Cheers, -Barry

I’m looking forward to being able to set and get domainowner and serverowner (or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.

Are you anticipating this will be in V3.0?

thanks

as

On 24 Feb 2015, at 11:42 am, Barry Warsaw barry@list.org wrote:

On Feb 22, 2015, at 11:20 AM, Andrew Stuart wrote:

there was an “application data” table:

———————————————————————————————————————————————————————————————————————— resource_type | resource_id | private/public | key | value ———————————————————————————————————————————————————————————————————————— user list domain server

and: the ability to set domainowner and serverowner permissions in 3.0,

No question, I think domain owner and server owner (or site owner) are concepts that we should capture in the core. I'd accept contributions for this, so let me describe my thinking (open to suggestions!).

The first question is whether to associate addresses, users, or both with the permissions. If you look at the member table (Member model class) you'll see we have a foreign key for both, but the logic ensure that we can't get conflicting values. This allows us to implement the "address as a member" or the "user as a member using their preferred address". I'm not sure whether we need this level of complexity for the site and domain owners.

The other observation is that we'd like to make it easy for both owners two have multiple contact addresses, so that we have fallbacks in case one of them starts to fail.

So I'm thinking we use a User for this association. The user would have to have at least one validated address linked to it.

For domains, we already have a domain table (Domain model class). Since we'd like to be able to associate multiple domain owners, it seems like we need a many-to-many table associating domains to users. (More than one user can own a domain, and any user can own more than one domain.) That table probably doesn't need anything else.

Since we have no site table/model, I think it would be enough to add a flag to the user table/model to indicate whether they are a site owner or not.

Now sprinkle with tests, database migrations, documentation, and REST, and I think you have at least this part solved.

Cheers, -Barry _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...

Security Policy: http://wiki.list.org/x/QIA9

How about having personalized announcement mailing lists ?

A personalized mailing list will allow mailman users to send personalized emails to all the list members from a common email template. Suppose I am the manager of a company and I need to ask all the workers for a meeting. I want each of my workers to prepare a topic to speak on during the meeting. For this I need to send each of them a message separately mentioning the topic he/she has to speak on.

Suppose the email *template* is like this:

*To : <worker-email>* *Subject: <sub>*

*Hello <worker-name>,*

*Hope you are having fun at <worker-place>. I am arranging a meeting at 5 p.m. on Saturday. I want you to speak on <topic> during the meeting. So, come prepared for that.* *<other-suff>*

*Best wishes,*

*Ankush Sharma* *Manager* *foo-bar*

And I have a spreadsheet data on the mailing list server like this: https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_zB67qEvgmX8Jr3xYy...

Mailman can have a functionality of flooding the *template* by using the spreadsheet data. The variables in the *template* (< -- > stuff) would be replaced by the corresponding row data in the spreadsheet corresponding to the emails of the list members. This can provide great flexibility to mailman users who use mailman as announcement list.

Later on, mailman can have the functionality of saving email templates and choosing one of them in a certain scenario. Mailing lists can be made more personalized and powerful in this way.

Expecting further feedback or suggestions on this idea.

Ankush Sharma IIT-BHU,Varanasi github.com/black-perl

On Thu, Feb 26, 2015 at 4:40 AM, Barry Warsaw barry@list.org wrote:

On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote:

...

I’m looking forward to being able to set and get domainowner and

serverowner

...

(or siteowner or whatever its called). It will allow me to delete lots of code and there’s no greater joy than deleting code.

Are you anticipating this will be in V3.0?

Please file a bug and we'll see. ;)

Cheers, -Barry

---

Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/ankush.sharma.ece...

Security Policy: http://wiki.list.org/x/QIA9

Thanks all! I've put up stuff for the ideas I could describe well enough off the top of my head.

Also, mentors, I've listed a few likely key people beside each project idea, but some of them are just a generic "anyone can help with this" -- if any of these particularly interests you, please put your name down. Google prefers we have actual names listed when we can (I'm not entirely sure why, as this hasn't proven to be helpful, but we can always change the names after the page is reviewed.)

Applications are due 1900 UTC Friday, so around 13h from now!

Terri