From waldbiec at lafayette.edu  Tue Sep  1 17:15:47 2015
From: waldbiec at lafayette.edu (Waldbieser, Carl)
Date: Tue, 1 Sep 2015 11:15:47 -0400 (EDT)
Subject: [Mailman-Developers] User-centric authentication and access control
Message-ID: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>

I know that currently, mailman roles are set up such that the roles themselves have a shared password per role.  I want to be able to move away from that model and have roles assigned to individual user accounts that would allow access to the admin interfaces for individual lists.

For example, say we have mail lists "Campus" and "Board of Trustees".  I might have roles "campus_moderators", "campus_admins", "boardoftrustees_moderators", and "boardoftrustees_admins".
If I assign the role campus_admins to user "johnsmith", I would like this user to be able to access the mailman admin interface for the "Campus" list using his own credentials.  Ideally, "johnsmith" would not have to present his primary credentials to the mailman interface because our institution has a web single sign-on infrastructure (Web SSO).

I would like to actually move the authentication and role management *outside* of mailman and have the administrative interface consume the role based information from external sources (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a more "pluggable" authentication and access management architecture.

Does anything like this exist for Mailman, or is it on the roadmap?  Are there technical guidelines for how one might contribute toward something like this?

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

From andrew.stuart at supercoders.com.au  Tue Sep  1 22:17:14 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Wed, 2 Sep 2015 06:17:14 +1000
Subject: [Mailman-Developers] User-centric authentication and access
	control
In-Reply-To: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
Message-ID: <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>

If users still sign in directly, what do you see the functionality of roles being from a Mailman perspective? I don?t see how they relate Mailman resources specifically.

The authenticating proxy server (which is still awaiting a better name - Barry? :-)) currently gives individuals control over Mailing lists, assuming that individual has moderator status.

Currently it decides to grant an authentication token based on reciept of username and password, which it validates by asking Mailman core if the username and password match. If you know Python then that is the staring point for hooking in an additional level of authorisation.  If you can write some pseudocode for how your authentication process works I could comment further.

as
 


On 2 Sep 2015, at 1:15 am, Waldbieser, Carl <waldbiec at lafayette.edu> wrote:

I know that currently, mailman roles are set up such that the roles themselves have a shared password per role.  I want to be able to move away from that model and have roles assigned to individual user accounts that would allow access to the admin interfaces for individual lists.

For example, say we have mail lists "Campus" and "Board of Trustees".  I might have roles "campus_moderators", "campus_admins", "boardoftrustees_moderators", and "boardoftrustees_admins".
If I assign the role campus_admins to user "johnsmith", I would like this user to be able to access the mailman admin interface for the "Campus" list using his own credentials.  Ideally, "johnsmith" would not have to present his primary credentials to the mailman interface because our institution has a web single sign-on infrastructure (Web SSO).

I would like to actually move the authentication and role management *outside* of mailman and have the administrative interface consume the role based information from external sources (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a more "pluggable" authentication and access management architecture.

Does anything like this exist for Mailman, or is it on the roadmap?  Are there technical guidelines for how one might contribute toward something like this?

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers at 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%40supercoders.com.au

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


From andrew.stuart at supercoders.com.au  Tue Sep  1 22:20:08 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Wed, 2 Sep 2015 06:20:08 +1000
Subject: [Mailman-Developers] User-centric authentication and access
	control
In-Reply-To: <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
Message-ID: <DC8A8D98-0181-4B10-A2C6-4EE19C8C60F1@supercoders.com.au>

Sorry I should say - I don?t think roles exist in Mailman 3? Someone else will know but I don?t recall offhand.

From stephen at xemacs.org  Tue Sep  1 22:26:12 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 02 Sep 2015 05:26:12 +0900
Subject: [Mailman-Developers] User-centric authentication and access control
In-Reply-To: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
Message-ID: <877fo951jv.fsf@uwakimon.sk.tsukuba.ac.jp>

Waldbieser, Carl writes:

 > I would like to actually move the authentication and role
 > management *outside* of mailman and have the administrative
 > interface consume the role based information from external sources
 > (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a
 > more "pluggable" authentication and access management architecture.
 > 
 > Does anything like this exist for Mailman, or is it on the roadmap?
 > Are there technical guidelines for how one might contribute toward
 > something like this?

Andrew Stuart (who replied on mailman-users to direct you here) has
been working on something like that.  However, there's a problem here
that there seem to be a number of different use cases, which are not
sufficiently well-understood to specify separate authentication and/or
authorization modules that could be "adapters" for external
authentication and authorization sources.

There's also the problem that Mailman core itself (the user and list
manager, and mail distribution functionality) doesn't really have any
authentication at all.  The Postorius front-end uses an external
authentication mechanism (Mozilla Persona) but the authorization
information is kept in Mailman core.

So we need requirements and specifications.  For your purposes, you
might look at Andrew's work; much of it might be adaptable to your
needs.



From andrew.stuart at supercoders.com.au  Tue Sep  1 23:13:06 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Wed, 2 Sep 2015 07:13:06 +1000
Subject: [Mailman-Developers] User-centric authentication and access
	control
In-Reply-To: <DC8A8D98-0181-4B10-A2C6-4EE19C8C60F1@supercoders.com.au>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
 <DC8A8D98-0181-4B10-A2C6-4EE19C8C60F1@supercoders.com.au>
Message-ID: <D1D94500-0C52-43E6-8C43-F6173DEBF521@supercoders.com.au>

It might be helpful if I explain what Mailmania does.

login - an anonymous HTTP request can be sent to the server asking to log in and POSTing Mailman username and password. Success results in a response with a JWT in the HTTP headers.
authentication - when an HTTP request arrives, it is examined to see if it contains a valid Jason web token (JWT) in its headers
authorization - when an HTTP request comes in, the request is examined to determine if the requesting user (as defined by the JWT attached to the request) has permission to access the resource they have requested. It has a set of business rules that make decisions about what resources a user is able to access. If authorization is approved, the request is proxied to the Mailman core REST API.

The Mailman permissions model is based on the idea that Mailman has the following resources:

a server
domains
lists
users

Users can have auth roles: (not the same as Mailman 2 roles I think)
userowner (this is implied, a user is its own owner)
listowner
listmember
listmoderator
listnonmember
domainowner
serverowner

Any HTTP request to Mailmania must be from a specific user, attempting to access a specific resource. Mailmania basically just figures out if that user is indeed allowed access to the resource that have asked for, and sends it through or denies it.


From mark at msapiro.net  Wed Sep  2 02:46:37 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 1 Sep 2015 17:46:37 -0700
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
Message-ID: <55E646ED.8070600@msapiro.net>

On 09/01/2015 08:15 AM, Waldbieser, Carl wrote:
> I know that currently, mailman roles are set up such that the roles themselves have a shared password per role.


This is true for MM 2.1. It is not true for MM 3.


> I want to be able to move away from that model and have roles assigned
to individual user accounts that would allow access to the admin
interfaces for individual lists.


MM 3 already works this way.

Please clarify whether you want to do this in MM 2.1 or in MM 3.

If you want to do it in MM 2.1, see my reply to your OP at
<https://mail.python.org/pipermail/mailman-users/2015-August/079667.html>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

From simon.hanna at serve-me.info  Tue Sep  1 23:14:08 2015
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Tue, 1 Sep 2015 23:14:08 +0200
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
Message-ID: <20150901211408.GA12359@turing>

On Tue, Sep 01, 2015 at 11:15:47AM -0400, Waldbieser, Carl wrote:
> I know that currently, mailman roles are set up such that the roles themselves have a shared password per role.  I want to be able to move away from that model and have roles assigned to individual user accounts that would allow access to the admin interfaces for individual lists.
> 
> For example, say we have mail lists "Campus" and "Board of Trustees".  I might have roles "campus_moderators", "campus_admins", "boardoftrustees_moderators", and "boardoftrustees_admins".
> If I assign the role campus_admins to user "johnsmith", I would like this user to be able to access the mailman admin interface for the "Campus" list using his own credentials.  Ideally, "johnsmith" would not have to present his primary credentials to the mailman interface because our institution has a web single sign-on infrastructure (Web SSO).
> 
> I would like to actually move the authentication and role management *outside* of mailman and have the administrative interface consume the role based information from external sources (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a more "pluggable" authentication and access management architecture.
> 
> Does anything like this exist for Mailman, or is it on the roadmap?  Are there technical guidelines for how one might contribute toward something like this?

Are you using Mailman version 2 or 3?
From your mail mentioning single moderator password, I suspect version 2.

In postorius (Mailman 3) you can add moderators and owners,
these will have access to the administrative options.

About LDAP:
You just have to add another authentication mechanism in django.
You will just need to provide an email address for every user.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150901/f8bbd2a6/attachment.sig>

From waldbiec at lafayette.edu  Wed Sep  2 03:02:00 2015
From: waldbiec at lafayette.edu (Waldbieser, Carl)
Date: Tue, 1 Sep 2015 21:02:00 -0400 (EDT)
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <20150901211408.GA12359@turing>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <20150901211408.GA12359@turing>
Message-ID: <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>


I am currently using Mailman 2.
If Mailman 3 provides the features I am interested in, that would be great, provided there is some kind of well-defined upgrade path.

I am a bit confused as to what the various components in Mailman 3 are.  Is the web interface to Mailman 3 based on Django?  Is that Postorius?
And if Django is allows you to do user management, where does Mailmania fit into that landscape?

Would I be correct in assuming that if I wanted to use say, CAS authentication for Mailman 3, I could just use a Django middleware like this?

    https://bitbucket.org/cpcc/django-cas/overview

Thanks,
Carl

----- Original Message -----
From: "Simon Hanna" <simon.hanna at serve-me.info>
To: "waldbiec" <waldbiec at lafayette.edu>
Cc: "mailman-developers" <mailman-developers at python.org>
Sent: Tuesday, September 1, 2015 5:14:08 PM
Subject: Re: [Mailman-Developers] User-centric authentication and access control

On Tue, Sep 01, 2015 at 11:15:47AM -0400, Waldbieser, Carl wrote:
> I know that currently, mailman roles are set up such that the roles themselves have a shared password per role.  I want to be able to move away from that model and have roles assigned to individual user accounts that would allow access to the admin interfaces for individual lists.
> 
> For example, say we have mail lists "Campus" and "Board of Trustees".  I might have roles "campus_moderators", "campus_admins", "boardoftrustees_moderators", and "boardoftrustees_admins".
> If I assign the role campus_admins to user "johnsmith", I would like this user to be able to access the mailman admin interface for the "Campus" list using his own credentials.  Ideally, "johnsmith" would not have to present his primary credentials to the mailman interface because our institution has a web single sign-on infrastructure (Web SSO).
> 
> I would like to actually move the authentication and role management *outside* of mailman and have the administrative interface consume the role based information from external sources (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a more "pluggable" authentication and access management architecture.
> 
> Does anything like this exist for Mailman, or is it on the roadmap?  Are there technical guidelines for how one might contribute toward something like this?

Are you using Mailman version 2 or 3?
>From your mail mentioning single moderator password, I suspect version 2.

In postorius (Mailman 3) you can add moderators and owners,
these will have access to the administrative options.

About LDAP:
You just have to add another authentication mechanism in django.
You will just need to provide an email address for every user.

From andrew.stuart at supercoders.com.au  Wed Sep  2 03:58:32 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Wed, 2 Sep 2015 11:58:32 +1000
Subject: [Mailman-Developers] User-centric authentication and access
	control
In-Reply-To: <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <20150901211408.GA12359@turing>
 <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
Message-ID: <8EE90163-042B-4C58-9791-BBE585E63D53@supercoders.com.au>

Postorius is a Django app that talks directly to the Mailman 3 REST API and integrates everything needed to get the job done including user interface, authentication and authorization.

Mailmania is an authenticating reverse proxy server.  Effectively it would allow someone to write a purely JavaScript browser based interface to Mailman 3, and it would provide the back end authorization and authentication.  No such JavaScript interface exists though. Mailmania provides a way for the public to talk to the Mailman 3 core REST API. 

In very loose terms you can imagine if you pulled Postorius apart into a backend and a JavaScript userinterface/front end, then Mailmania would be the equivalent of the back end. Sort of.

If you wanted to write a user interface for Mailman using ReactJS or AngularJS then you?d probably want it to talk to Mailmania.

If you want to actually have a working interface to Mailman 3 then you need Postorius as no-one has written any user interface code for Mailmania.

as


From waldbiec at lafayette.edu  Wed Sep  2 04:50:31 2015
From: waldbiec at lafayette.edu (Waldbieser, Carl)
Date: Tue, 1 Sep 2015 22:50:31 -0400 (EDT)
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <8EE90163-042B-4C58-9791-BBE585E63D53@supercoders.com.au>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <20150901211408.GA12359@turing>
 <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
 <8EE90163-042B-4C58-9791-BBE585E63D53@supercoders.com.au>
Message-ID: <2121128551.1083838.1441162231477.JavaMail.zimbra@lafayette.edu>


I believe I have a better understanding of the puzzle pieces, now.  In a nutshell:

* Mailman 3 allows you to assign administrative privileges to individual users who may log in with their own credentials.
* Mailman 3 is composed of several separate projects that work together to form a coherent system.
* The Postorius component is the Django-based web UI component for Mailman 3.
* Because it is Django based, the authentication scheme for Postorious can be customized by configuring the appropriate Django authentication middleware (e.g. REMOTE_USER [1]).
* The Mailman REST API provides you with superuser-like access to Mailman, and should only be used to integrate trusted apps.
* Mailmania can be used to provide external access to the RESTful API.  Requests are are authenticated, and the typical access controls are enforced.

It seems to me that if I have an authentication mechanism that supports exporting the authenticated user via REMOTE_USER into the web server environment, then I could use that mechanism with Django + Postorius.

I'm assuming Mailmania relies on presenting a username and password directly to the Mailman REST API to authenticate?  Or would it also have some mechanism to let you customize the authentication mechanism?

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

[1] https://docs.djangoproject.com/en/1.8/howto/auth-remote-user/

----- Original Message -----
From: "Andrew Stuart" <andrew.stuart at supercoders.com.au>
To: "waldbiec" <waldbiec at lafayette.edu>
Cc: "mailman-developers" <mailman-developers at python.org>
Sent: Tuesday, September 1, 2015 9:58:32 PM
Subject: Re: [Mailman-Developers] User-centric authentication and access control

Postorius is a Django app that talks directly to the Mailman 3 REST API and integrates everything needed to get the job done including user interface, authentication and authorization.

Mailmania is an authenticating reverse proxy server.  Effectively it would allow someone to write a purely JavaScript browser based interface to Mailman 3, and it would provide the back end authorization and authentication.  No such JavaScript interface exists though. Mailmania provides a way for the public to talk to the Mailman 3 core REST API. 

In very loose terms you can imagine if you pulled Postorius apart into a backend and a JavaScript userinterface/front end, then Mailmania would be the equivalent of the back end. Sort of.

If you wanted to write a user interface for Mailman using ReactJS or AngularJS then you?d probably want it to talk to Mailmania.

If you want to actually have a working interface to Mailman 3 then you need Postorius as no-one has written any user interface code for Mailmania.

as

From andrew.stuart at supercoders.com.au  Wed Sep  2 05:02:43 2015
From: andrew.stuart at supercoders.com.au (Andrew Stuart)
Date: Wed, 2 Sep 2015 13:02:43 +1000
Subject: [Mailman-Developers] User-centric authentication and access
	control
In-Reply-To: <2121128551.1083838.1441162231477.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <20150901211408.GA12359@turing>
 <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
 <8EE90163-042B-4C58-9791-BBE585E63D53@supercoders.com.au>
 <2121128551.1083838.1441162231477.JavaMail.zimbra@lafayette.edu>
Message-ID: <F98F9DE8-E8BA-4820-9277-CEB5EFFBBE6D@supercoders.com.au>

As far as I know that?s a pretty good summary.  I should say however I really don?t know much except about Mailmania.  You?d get better information on Postorius from Aurelien and Barry is the authority on the Mailman core.

It?s important to understand that Mailman core defines the resources and allows assignment of membership and ownership of those resources.  The business rules for how that is interpreted is left up to the application server, so Mailmania and Postorius almost certainly do it differently.  Anyway you probably don?t need to think about that.

The most battle tested parts of this are Mailman Core and Postorius. Mailmania isn?t used as far as I know - someone may do so one day but for the most part it?s leading a quiet life.

>>I'm assuming Mailmania relies on presenting a username and password directly to the Mailman REST API to authenticate?
That is correct.

>>Or would it also have some mechanism to let you customize the authentication mechanism?
All Mailmania?s login function does is check username and password with the core. If all good then it hands back a token.  There?s no reason you couldn?t modify that very simple logic to do some other check like looking up in LDAP and then handing back the token.   Probably you?d create an additional login function that does whatever auth lo9gic you want and then hands backs a JWT.

I don?t know anything about Django authentication.  Others pmay commment on that.

as





On 2 Sep 2015, at 12:50 pm, Waldbieser, Carl <waldbiec at lafayette.edu> wrote:


I believe I have a better understanding of the puzzle pieces, now.  In a nutshell:

* Mailman 3 allows you to assign administrative privileges to individual users who may log in with their own credentials.
* Mailman 3 is composed of several separate projects that work together to form a coherent system.
* The Postorius component is the Django-based web UI component for Mailman 3.
* Because it is Django based, the authentication scheme for Postorious can be customized by configuring the appropriate Django authentication middleware (e.g. REMOTE_USER [1]).
* The Mailman REST API provides you with superuser-like access to Mailman, and should only be used to integrate trusted apps.
* Mailmania can be used to provide external access to the RESTful API.  Requests are are authenticated, and the typical access controls are enforced.

It seems to me that if I have an authentication mechanism that supports exporting the authenticated user via REMOTE_USER into the web server environment, then I could use that mechanism with Django + Postorius.

I'm assuming Mailmania relies on presenting a username and password directly to the Mailman REST API to authenticate?  Or would it also have some mechanism to let you customize the authentication mechanism?

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

[1] https://docs.djangoproject.com/en/1.8/howto/auth-remote-user/

----- Original Message -----
From: "Andrew Stuart" <andrew.stuart at supercoders.com.au>
To: "waldbiec" <waldbiec at lafayette.edu>
Cc: "mailman-developers" <mailman-developers at python.org>
Sent: Tuesday, September 1, 2015 9:58:32 PM
Subject: Re: [Mailman-Developers] User-centric authentication and access control

Postorius is a Django app that talks directly to the Mailman 3 REST API and integrates everything needed to get the job done including user interface, authentication and authorization.

Mailmania is an authenticating reverse proxy server.  Effectively it would allow someone to write a purely JavaScript browser based interface to Mailman 3, and it would provide the back end authorization and authentication.  No such JavaScript interface exists though. Mailmania provides a way for the public to talk to the Mailman 3 core REST API. 

In very loose terms you can imagine if you pulled Postorius apart into a backend and a JavaScript userinterface/front end, then Mailmania would be the equivalent of the back end. Sort of.

If you wanted to write a user interface for Mailman using ReactJS or AngularJS then you?d probably want it to talk to Mailmania.

If you want to actually have a working interface to Mailman 3 then you need Postorius as no-one has written any user interface code for Mailmania.

as


From simon.hanna at serve-me.info  Thu Sep  3 02:26:01 2015
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Thu, 3 Sep 2015 02:26:01 +0200
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <20150901211408.GA12359@turing>
 <478142829.1064257.1441155720505.JavaMail.zimbra@lafayette.edu>
Message-ID: <20150903002601.GA18780@turing>

On Tue, Sep 01, 2015 at 09:02:00PM -0400, Waldbieser, Carl wrote:
> 
> I am currently using Mailman 2.
> If Mailman 3 provides the features I am interested in, that would be great, provided there is some kind of well-defined upgrade path.
AFAIK the official statement is that Mailman 3.1 will provide upgrade paths from 2.x
I would wait for the 3.1 release...
 
> I am a bit confused as to what the various components in Mailman 3 are.  Is the web interface to Mailman 3 based on Django?  Is that Postorius?
Correct. Mailman itself is just the core. The core exposes a REST interface.
There is a client implementation for python (mailman-client).
A Nodejs client is in the works AFAIK.
You can use these to build your own UI.
Or you could use postorius for that.
It is based on django and uses mailman-client to interact with the core.

> And if Django is allows you to do user management, where does Mailmania fit into that landscape?
> 
> Would I be correct in assuming that if I wanted to use say, CAS authentication for Mailman 3, I could just use a Django middleware like this?
> 
>     https://bitbucket.org/cpcc/django-cas/overview

That is probably correct. I personally have not yet included 
other authentication backends to django,
but the process should be rather easy.
Django has ver good documentation online. 
Including an LDAP backend should be standard enough for numerous tutorials to be out there.
You just have to search for integrating different Backends into postorius.
Postorius itself is actually doing this. Persona is used as the main Authentication Backend.

Hyperkitty (yet another module) which is responsible for serving Archives of Lists
even includes more Authentication Backends.
That code should show you what you need to do, to add further Backends.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150903/3f59b5b6/attachment.sig>

From barry at list.org  Mon Sep  7 21:12:18 2015
From: barry at list.org (Barry Warsaw)
Date: Mon, 7 Sep 2015 15:12:18 -0400
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
Message-ID: <20150907151218.4d5b062c@anarchist.wooz.org>

On Sep 02, 2015, at 06:17 AM, Andrew Stuart wrote:

>If users still sign in directly, what do you see the functionality of roles
>being from a Mailman perspective? I don?t see how they relate Mailman
>resources specifically.

Core really only has a small handful of roles, e.g. member, nonmember, list
moderator, list owner, domain owner, site owner.  We keep the number of roles
narrow to keep the responsibilities of the core narrow too.  These roles are
only ones that the core needs to make decisions about posting privileges,
moderation access, and configuration powers.

We can authenticate users against the password stored under their account in
the core via the REST API.  The trick is keeping this data in sync against
multiple components, such that if the user were to log into Postorius via
password, you'd want to (can do so currently) authenticate the password
against the one stored in the core.  We may want to associate other data with
users too, e.g. GPG pubkeys, which would allow authenticate via other
channels, such as email.

We could, and it might actually make sense, to get rid of authenticate in the
core.  We've longed talked about a user database component, which would store
accounts, passwords, and other authentication information.  The core would
then just be a client of this component.  We're not much past the discussion
phase with this idea.

Cheers,
-Barry

From aurelien at bompard.org  Tue Sep  8 08:57:54 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Tue, 8 Sep 2015 08:57:54 +0200
Subject: [Mailman-Developers] Merging users
In-Reply-To: <CAHmoxtWu8eBH+XzQbGr9U1XFxm80fADC7ajYWHr2b66virW4_g@mail.gmail.com>
References: <CAHmoxtUiw2ZGpqAU8v8Pt+t6MhzJKH1BRFg80Lg8xYfG09rTog@mail.gmail.com>
 <20150731195507.508c346d@limelight.wooz.org>
 <CAHmoxtWu8eBH+XzQbGr9U1XFxm80fADC7ajYWHr2b66virW4_g@mail.gmail.com>
Message-ID: <CAHmoxtV=Uo2L9-JkFwnftaHG9F-0uxgWM2z7KOA8+q2FZKHi7g@mail.gmail.com>

> Abhilash's fix is good but I need to actually merge users, so here's
> how I would do it.
> https://gitlab.com/mailman/mailman/merge_requests/32
> The change sits on top of Abhilash's, so there's no conflict.
>
> I don't think I'm missing anything as far as users are concerned, but
> please have a look :-)

Hey guys, do you have any feedback on this? On the principle and/or
the implementation?

Thanks!
Aur?lien

From aurelien at bompard.org  Tue Sep  8 09:38:45 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Tue, 8 Sep 2015 09:38:45 +0200
Subject: [Mailman-Developers] Migration of header_filter_rules
Message-ID: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>

Hey all!

I'm hitting another issue in my migration from 2.1 to 3.x. In 2.1,
there was an option called "header_filter_rules" used mainly for spam
control, and advertised as such in the CGIs. These rules contained a
regex and an action to take on a match : defer, approve, reject,
discard, (un)subscribe, accept or hold.

In 3.x, this has been replaced by the list attribute "header_matches",
which is just a list of regexes. These list-specific regexes will be
added to the list of regexes in the antispam section of the
configuration file. If any of those matches, the action taken will be
the one set in the same section of the configuration file.

I'm having two issues with this. First, different list admins may want
different actions taken on spam, like discard, reject or hold. In 3.x
there's only one action possible.
Second, and that's the biggest problem for me, some of my lists admins
have been considering this feature as a generic filtering system
(because that's what it is in the end). Here are some of the usages
I've seen:
1. Have a rule that matches obvious spam ('^Subject: .*loan.*') and
discard those instead of rejecting
2. Have a rule that would accept an email based on the presence of a
header (X-Git-Module or Approved) and reject all other emails
3. On an automated list where commits are posted, have a series of
rules that would drop emails from the devel branches, accept emails if
they came from the right servers (Received header), and hold all the
rest
They refer to this feature as "regular Mailman filtering".

Use case 1 would need at least list-specific actions, use cases 2 and
3 would need rule-specific actions, like it is now in 2.1.

I don't think our current system of just collecting the header_matches
rules and applying a site-specific action is going to be enough in the
long run anyway, since list admins may want different actions taken on
their spam. For example a list about finance or pharmaceuticals may
want to hold and inspect what the spam detector flagged as spam,
because it's more likely to have false positives.
And if we're going to change this system, I'd suggest going all the
way to rule-specific actions, to ease migrations and give more
flexibility to list admins.

I'm willing to write this change, if you think it's a good idea. If
you think it should be handled differently, I'm all ears.

Thanks for your attention and input

Aur?lien

From barry at list.org  Thu Sep 10 03:34:21 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 9 Sep 2015 21:34:21 -0400
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
Message-ID: <20150909213421.7bd012a7@limelight.wooz.org>

On Sep 08, 2015, at 09:38 AM, Aurelien Bompard wrote:

>And if we're going to change this system, I'd suggest going all the way to
>rule-specific actions, to ease migrations and give more flexibility to list
>admins.

I agree, and I think it's a good idea to go all the way to rule-specific
actions.

The [antispam] section serves the purpose of site-wide filtering, so that site
owners can handle global problems.  Some of this may overlap with what you can
do in the MTA, and editing Mailman's global configuration files probably
requires about the same permissions as editing the MTA's configs.  This is in
Mailman because it may be easier to configure than an MTA and it provides some
consistency with the basic semantics of message handling in Mailman.  So let's
keep that.

The default-posting-chain takes a detour through the header-match chain which
implements the list-specific header matching as you've described.  The trick
then is going to be how to match actions to headers regexps, both internally
and in the "ui".  It's probably going to require a separate table foreign
keyed to the mailing list which contain a list of regexps and their actions,
and HeaderMatchChain.get_links() will likely have to be rewritten.  Then this
has to be exposed through the REST API so Postorius can present it to the list
admin.

I'm not sure that the current semantics of header-match need to be preserved.
If a list admin wanted one of their regexps to trigger the site-defined
action, they could just choose it themselves.  I don't think we need to keep
it for backward compatibility reasons, but we do need to migrate any existing
header_checks to the new feature (i.e. for people upgrading from MM 3.0 to
3.1, as this will obviously be a 3.1-only feature).  I suggest using the
config.antispam.jump_chain value as the default value for the new
header_checks regexp value.

You'll have to disentangle the site-wide header checks with the list-specific
header checks, but maybe that can be done in the .get_links() method.
Site-wide settings should take precedence.

Happy to talk more about implementation details, in whatever forum you want,
but +1 on the feature.

Cheers,
-Barry

From barry at list.org  Thu Sep 10 03:35:32 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 9 Sep 2015 21:35:32 -0400
Subject: [Mailman-Developers] User-centric authentication and access
 control
In-Reply-To: <DC8A8D98-0181-4B10-A2C6-4EE19C8C60F1@supercoders.com.au>
References: <105824734.809658.1441120547258.JavaMail.zimbra@lafayette.edu>
 <6759AA41-43D8-42E7-B547-1409D6482151@supercoders.com.au>
 <DC8A8D98-0181-4B10-A2C6-4EE19C8C60F1@supercoders.com.au>
Message-ID: <20150909213532.2dd5db6c@limelight.wooz.org>

On Sep 02, 2015, at 06:20 AM, Andrew Stuart wrote:

>Sorry I should say - I don?t think roles exist in Mailman 3? Someone else
>will know but I don?t recall offhand.

They do a little bit, but in a limited way.  The roles are really just
site-owner, domain-owner, list-owner, moderator, list-member, and nonmember.

Cheers,
-Barry

From aurelien at bompard.org  Thu Sep 10 11:33:51 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Thu, 10 Sep 2015 11:33:51 +0200
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <20150909213421.7bd012a7@limelight.wooz.org>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
Message-ID: <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>

> It's probably going to require a separate table foreign
> keyed to the mailing list which contain a list of regexps and their actions,

Yeah, it's currently a python list pickled into the header_matches
field of a mailinglist, we can do better :-)

> Then this has to be exposed through the REST API so Postorius can present it to the list
> admin.

Yes, and make edits.

> I'm not sure that the current semantics of header-match need to be preserved.
> If a list admin wanted one of their regexps to trigger the site-defined
> action, they could just choose it themselves.  I don't think we need to keep
> it for backward compatibility reasons, but we do need to migrate any existing
> header_checks to the new feature (i.e. for people upgrading from MM 3.0 to
> 3.1, as this will obviously be a 3.1-only feature).  I suggest using the
> config.antispam.jump_chain value as the default value for the new
> header_checks regexp value.

We could decide that the chain to be jumped to is nullable, in which
case the action would be defer, which would end up in the site-defined
chain like in the current model. Then the existing chain could just
use that and get the same behavior.

> You'll have to disentangle the site-wide header checks with the list-specific
> header checks, but maybe that can be done in the .get_links() method.
> Site-wide settings should take precedence.

Hmm, do you think so? I would have thought that list settings should
take precedence, since they are the most precise. A list could decide
to not filter the spam and deal with it in their own manner (holding
it instead of discarding it).

> Happy to talk more about implementation details, in whatever forum you want,
> but +1 on the feature.

Cool, I'll do it :-)

Aur?lien

From barry at list.org  Thu Sep 10 18:01:20 2015
From: barry at list.org (Barry Warsaw)
Date: Thu, 10 Sep 2015 12:01:20 -0400
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
 <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
Message-ID: <20150910120120.7ae2a8d0@limelight.wooz.org>

On Sep 10, 2015, at 11:33 AM, Aurelien Bompard wrote:

>> It's probably going to require a separate table foreign
>> keyed to the mailing list which contain a list of regexps and their actions,
>
>Yeah, it's currently a python list pickled into the header_matches
>field of a mailinglist, we can do better :-)

Yes, let's eat the pickles! :)

>> I'm not sure that the current semantics of header-match need to be
>> preserved.  If a list admin wanted one of their regexps to trigger the
>> site-defined action, they could just choose it themselves.  I don't think
>> we need to keep it for backward compatibility reasons, but we do need to
>> migrate any existing header_checks to the new feature (i.e. for people
>> upgrading from MM 3.0 to 3.1, as this will obviously be a 3.1-only
>> feature).  I suggest using the config.antispam.jump_chain value as the
>> default value for the new header_checks regexp value.
>
>We could decide that the chain to be jumped to is nullable, in which
>case the action would be defer, which would end up in the site-defined
>chain like in the current model. Then the existing chain could just
>use that and get the same behavior.

That might indeed be a better way to go, so if the site-defined action is
changed, the change will get picked up.  The downside of course is that a
restart is needed.

It might be better to move the site checks out of the config file and into the
database.  It could work the way bans work, where if there is a list-id
context, it's a list-specific ban, and if there is no associated list-id, it's
a site-wide ban.

Don't feel you have to do this extra step, but it might be easy.

>> You'll have to disentangle the site-wide header checks with the
>> list-specific header checks, but maybe that can be done in the .get_links()
>> method.  Site-wide settings should take precedence.
>
>Hmm, do you think so? I would have thought that list settings should
>take precedence, since they are the most precise. A list could decide
>to not filter the spam and deal with it in their own manner (holding
>it instead of discarding it).

My thinking was that site owners have greater permission and responsibility,
so their preference should win.  It might be interesting to have a way for a
site admin to say "here's the default, but let list admins override"
vs. "here's site policy, you cannot override".

This seems like a not-uncommon pattern, especially if you add a domain-owner's
preferences here.  There's a hierarchy that's often repeated.  But
generalizing that, or even supporting it in this case can very definitely
happen in a future feature.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150910/80e6a51c/attachment.sig>

From stephen at xemacs.org  Thu Sep 10 18:18:12 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 11 Sep 2015 01:18:12 +0900
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
 <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
Message-ID: <87zj0uz1rv.fsf@uwakimon.sk.tsukuba.ac.jp>

Aurelien Bompard writes:

 > Hmm, do you think so? I would have thought that list settings
 > should take precedence, since they are the most precise. A list
 > could decide to not filter the spam and deal with it in their own
 > manner (holding it instead of discarding it).

That makes sense when list-owner == site-owner.  However, a list which
is misconfigured or just doesn't care can hurt the reputation of the
whole site.  Also, there are the emergency cases that Barry mentioned,
where you want to flip one switch and turn the lights out for spam.

So maybe there should be "site defaults" which list owners can
override, and "site configurations" which are final.

Steve

From becue at crans.org  Fri Sep 11 00:49:44 2015
From: becue at crans.org (Pierre-Elliott =?iso-8859-1?Q?B=E9cue?=)
Date: Fri, 11 Sep 2015 00:49:44 +0200
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
Message-ID: <20150910224944.GM8564@crans.org>

Hey,

As a Debian fanboy and also a mailman addict, I'd like to try packaging it
in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some
time to think about what would be relevant.

For that, I'd like to have some help. And I was suggested to come here and
ask.

I decided to use https://gitlab.com/groups/mailman as a basis for my work.

First of all, to create the source package, I've to think about what to put
in it.

It seems that if I want to have a good source package, I need 5 repos :

 - Mailman
 - HyperKitty
 - Postorius
 - HyperKitty - MailMan Plugin
 - MailmanClient

My first question is "Am I right?". And the second one is whould I consider
looking into mailman-suite-doc and also have it in the source package?

On another way, I also see that there is a standalone postorius repo and
also some django project files for HyperKitty in another one. I have the
impression it is more designed for people to work on as standalone -
forkable projects for other features, and so I wouldn't need them in a
Debian package.

Am I also right?

Thanks for your answer, I hope I'll be able to make this package look as
you'd like. :)

Cheers,

-- 
PEB

From stephen at xemacs.org  Fri Sep 11 04:26:44 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 11 Sep 2015 11:26:44 +0900
Subject: [Mailman-Developers]  Let's try to package mailman3 in Debian!
In-Reply-To: <20150910224944.GM8564@crans.org>
References: <20150910224944.GM8564@crans.org>
Message-ID: <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>

Pierre-Elliott B?cue writes:

 > It seems that if I want to have a good source package, I need 5 repos :
 > 
 >  - Mailman
 >  - HyperKitty
 >  - Postorius
 >  - HyperKitty - MailMan Plugin
 >  - MailmanClient

In the spirit of the refactoring, I would say mailman-core (mailman +
mailmanclient), hyperkitty, and postorious should be three separate
packages in Debian.  Exactly which repos are needed, I'm not sure.

Mailman3 (or mailman-suite) would be a trivial package that depends on
all of the above.

 > My first question is "Am I right?". And the second one is whould I
 > consider looking into mailman-suite-doc and also have it in the
 > source package?

No, Debian breaks out doc packages anyway.  I think as long as
upstream is a separate repo, you may as well just have a separate
source package for mailman-suite-doc, too.

 > On another way, I also see that there is a standalone postorius repo and
 > also some django project files for HyperKitty in another one. I have the
 > impression it is more designed for people to work on as standalone -
 > forkable projects for other features, and so I wouldn't need them in a
 > Debian package.

No, IIRC these are variants which don't need a separate webserver such
as Apache (convenient for testing), but they're still closely tied to
mailman core and mailmanclient.


From simon.hanna at serve-me.info  Fri Sep 11 04:43:20 2015
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Fri, 11 Sep 2015 04:43:20 +0200
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20150911024319.GA1347@turing>

On Fri, Sep 11, 2015 at 11:26:44AM +0900, Stephen J. Turnbull wrote:
> Pierre-Elliott B?cue writes:
> 
>  > It seems that if I want to have a good source package, I need 5 repos :
>  > 
>  >  - Mailman
>  >  - HyperKitty
>  >  - Postorius
>  >  - HyperKitty - MailMan Plugin
>  >  - MailmanClient
> 
> In the spirit of the refactoring, I would say mailman-core (mailman +
> mailmanclient), hyperkitty, and postorious should be three separate
> packages in Debian.  Exactly which repos are needed, I'm not sure.
Actually mailman-core is fully functional all alone.
- I would make a mailman-core package, everything depends on that
- mailmanclient would be a package providing the python bindings
- postorius would be a package depending on mailman-core and mailmanclient
- hyperkitty would be a package depending on mailman-core and mailmanclient, it should also inlcude
the hyperkitty mailman plugin
- mailman-deploy (or some other name) would contain a django skeleton project. It would have
	optional dependencies on postorius and hyperkitty.
- mailman-suite would depend on all of the packages
 
>  > On another way, I also see that there is a standalone postorius repo and
>  > also some django project files for HyperKitty in another one. I have the
>  > impression it is more designed for people to work on as standalone -
>  > forkable projects for other features, and so I wouldn't need them in a
>  > Debian package.
> 
> No, IIRC these are variants which don't need a separate webserver such
> as Apache (convenient for testing), but they're still closely tied to
> mailman core and mailmanclient.

All django projects can be run without a separate webserver. However, this should _not_ be used in
production enviornments.

I am deploying several django projects using nginx and uwsgi, works like a charm.
I would either link to or provide documentation about different options for deploying django
projects. Anything applicable to django is applicable to postorius and hyperkitty

Since postorius and hyperkitty are django apps,
you are going to need a django project to deploy them.
The *_standalone repositories are such projects to deploy postorius or hyperkitty.
In a production environment you would probably want to have both in one django project.

I would provide a skeleton with comments about what options need to be changed to get to a sane
production system. 

I am currently working on writing such a project skeleton that would be able to deploy postorius or
hyperkitty or both. I will publish a repo on gitlab when it's functional

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150911/36344257/attachment.sig>

From stephen at xemacs.org  Fri Sep 11 08:49:48 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 11 Sep 2015 15:49:48 +0900
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <20150911024319.GA1347@turing>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20150911024319.GA1347@turing>
Message-ID: <87oah9zbzn.fsf@uwakimon.sk.tsukuba.ac.jp>

Simon Hanna writes:

 > Actually mailman-core is fully functional all alone.

That's not really true.  Sure, you can telnet to the REST port and
speak REST by hand, but that's hardly pleasant.  At a minimum, you
need mailmanclient.  (There will be alternatives, there was a GSoC
project to provide a client that integrates with Node.js.  But at the
moment that's not production-ready.)

Also, all this talk may be somewhat premature, as at present there's
no authentication in the REST protocol, so everything needs to be on
the same host.   Andrew Stuart's authenticating proxy will help with
that, but AFAIK it's not integrated yet.  It may be worth waiting for
that (and/or Mailman 3.1 with the migration story) before doing betas
of the Debian package(s).


From barry at list.org  Fri Sep 11 16:04:53 2015
From: barry at list.org (Barry Warsaw)
Date: Fri, 11 Sep 2015 10:04:53 -0400
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <20150910224944.GM8564@crans.org>
References: <20150910224944.GM8564@crans.org>
Message-ID: <20150911100453.026e8424@limelight.wooz.org>

On Sep 11, 2015, at 12:49 AM, Pierre-Elliott B?cue wrote:

>As a Debian fanboy and also a mailman addict, I'd like to try packaging it
>in Debian.

Excellent!  Do check wnpp to make sure there's not already an ITP for Mailman
3.  Note too that there is already a Mailman 2 package, so you might want to
contact the pkg-mailman-hackers at lists.alioth.debian.org mailing list.

>It seems that if I want to have a good source package, I need 5 repos :
>
> - Mailman
> - HyperKitty
> - Postorius
> - HyperKitty - MailMan Plugin
> - MailmanClient
>
>My first question is "Am I right?". And the second one is whould I consider
>looking into mailman-suite-doc and also have it in the source package?

Yes, those are a good start.  I'm in the "separate source packages" camp for
each component.  Since each upstream does separate tarball releases, separate
source packages make the most sense, IMHO.  Definitely for core and client.
You'll probably want to use 'mailman3-' as a prefix for the source packages,
e.g. mailman3-core, mailman3-client, etc.

You'll probably want to talk to some Debian Django developers on the best way
to package Postorius and HK.

mailman-suite-doc doesn't have anything in it right now.

Cheers,
-Barry

From barry at list.org  Fri Sep 11 16:06:12 2015
From: barry at list.org (Barry Warsaw)
Date: Fri, 11 Sep 2015 10:06:12 -0400
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20150911100612.200131f1@limelight.wooz.org>

On Sep 11, 2015, at 11:26 AM, Stephen J. Turnbull wrote:

>Mailman3 (or mailman-suite) would be a trivial package that depends on
>all of the above.

Yep, though I'd go with something like mailman3-suite.  Or you can reserve the
'mailman3' source package name for the umbrella package that depends on all
the sub-components (e.g. mailman3-core, mailman3-client, etc.)

Cheers,
-Barry

From aurelien at bompard.org  Fri Sep 11 16:25:01 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Fri, 11 Sep 2015 16:25:01 +0200
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <87zj0uz1rv.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
 <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
 <87zj0uz1rv.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAHmoxtVSW2ph497k2BQ9c1gvCcmbqFV_1k9d7Hxia2m9gp5dpA@mail.gmail.com>

OK, I have something that follows these requirements (except the
site-defaults + site-config thing, currently site-wide checks take
precedence).
If you want to look at it :
https://gitlab.com/abompard/mailman/commits/import-header-matches

If you have some time Barry, I'd like your review on some things that
I'm not sure I'm doing right:
In the code and in the tests, I'm importing the new model object,
HeaderMatch. Is it OK? Should I go through the corresponding interface
instead? It looks like models are almost never imported from
throughout the code (except in the model module), and I don't know if
that's a best practice that should be followed here. If it is and you
have details on the reasoning, I'm interested :-)
Example : https://gitlab.com/abompard/mailman/commit/7a14a5f42af35185bee19b8e09c6e272fd85282e#4e170b02877ebb99f9ecbcd5fd2f6a50ee49827f_51_51

Thanks !
Aur?lien

From barry at list.org  Sat Sep 12 06:49:31 2015
From: barry at list.org (Barry Warsaw)
Date: Sat, 12 Sep 2015 00:49:31 -0400
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <CAHmoxtVSW2ph497k2BQ9c1gvCcmbqFV_1k9d7Hxia2m9gp5dpA@mail.gmail.com>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
 <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
 <87zj0uz1rv.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAHmoxtVSW2ph497k2BQ9c1gvCcmbqFV_1k9d7Hxia2m9gp5dpA@mail.gmail.com>
Message-ID: <20150912004931.014fdc57@anarchist.wooz.org>

On Sep 11, 2015, at 04:25 PM, Aurelien Bompard wrote:

>If you want to look at it :
>https://gitlab.com/abompard/mailman/commits/import-header-matches

I took a brief look, and I think you're heading in the right direction.  I'll
do a more details review once the mp is up[*].

>In the code and in the tests, I'm importing the new model object,
>HeaderMatch. Is it OK? Should I go through the corresponding interface
>instead? It looks like models are almost never imported from throughout the
>code (except in the model module), and I don't know if that's a best practice
>that should be followed here. If it is and you have details on the reasoning,
>I'm interested :-)

You're right that model classes should never be imported outside mailman/model
although there are a few violations of this rule.  It's less hard-and-fast for
tests since sometimes that's just the most convenient way to handle it.

In cases like this though, the typical pattern is to create a "set" class in
the model, and use it to create, delete, and lookup model objects in the set.
For list-centric collections, you then also create an ZCA adapter which
returns an object in the context of the mailing list.

It's always easier to understand examples, so here's a classic.

Mailing lists have an associated set of acceptable aliases which are kept in
the acceptableasliases table.  Individual alias entries are defined by the
IAcceptableAlias interface and implemented by the AcceptableAlias class.
There's also an IAcceptableAliasSet and AcceptableAliasSet pair (the latter
which does *not* derive from Model), and you'll find .add(), .clear(), and
.remove() methods, and a convenience .aliases attribute.

So, you never add AcceptableAlias objects directly, you always do it through
the IAcceptableAliasSet interface.  How do you get an instance of that without
importing from the model subpackage?  You *adapt* an existing mailing list
object to that interface:

    from mailman.interfaces.mailinglist import IAcceptableAliasSet
    ...
    alias_set = IAcceptableAliasSet(my_mlist)

The thread that ties it all together is this claus in
src/mailman/config/configure.zcml (the configuration file for the Zope
Component Architecture -- ZCA):

  <adapter
    for="mailman.interfaces.mailinglist.IMailingList"
    provides="mailman.interfaces.mailinglist.IAcceptableAliasSet"
    factory="mailman.model.mailinglist.AcceptableAliasSet"
    />

Thus when you call the interface, passing in the IMailingList instance, the
ZCA looks up a factory providing that interface, and calls the object, passing
in the argument.  You can see that AcceptableAliasSet takes a single argument,
the mailing list object which provides the context for that object's
operations.

I think header checks will probably work almost exactly the same way.

Cheers,
-Barry

[*] Side note: NFL season starts here in the USA this weekend, and there's no
better way to salvage a Sunday afternoon normally wasted watching your crappy
ass home team disappoint for another year than doing some fun Mailman hacking
as you scream at the TV.  Just resist the urge to throw your laptop through
the TV!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150912/8af278ed/attachment.sig>

From aurelien at bompard.org  Sat Sep 12 01:55:20 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Sat, 12 Sep 2015 01:55:20 +0200
Subject: [Mailman-Developers] Migration of header_filter_rules
In-Reply-To: <20150912004931.014fdc57@anarchist.wooz.org>
References: <CAHmoxtUQRRASuHzT2xCmQzMoX9qvrrj+RrrnK0NAKveKuov9ug@mail.gmail.com>
 <20150909213421.7bd012a7@limelight.wooz.org>
 <CAHmoxtXZRR=d-7RM4EusS=09Onbb3z_+mvsw5F3byAfD-=z7aQ@mail.gmail.com>
 <87zj0uz1rv.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAHmoxtVSW2ph497k2BQ9c1gvCcmbqFV_1k9d7Hxia2m9gp5dpA@mail.gmail.com>
 <20150912004931.014fdc57@anarchist.wooz.org>
Message-ID: <CAHmoxtXm5Pthc8i6TM-os2xS_dTf2CD_5TZCHWU07RjupcMFgw@mail.gmail.com>

> You're right that model classes should never be imported outside mailman/model
> although there are a few violations of this rule.  It's less hard-and-fast for
> tests since sometimes that's just the most convenient way to handle it.
> [...]

Great explanation, thanks.
I'll send a merge request right now because I won't be able to do the
interface dance this weekend, and you may want to check out the rest
of the code. I'll create the required sets and interfaces on Monday.

Have a fun NFL season start! May all teams win! ;-)

Aur?lien

From simon.hanna at serve-me.info  Sun Sep 13 12:53:55 2015
From: simon.hanna at serve-me.info (Simon Hanna)
Date: Sun, 13 Sep 2015 12:53:55 +0200
Subject: [Mailman-Developers] Mailman 3 packages for Archlinux
Message-ID: <20150913105355.GA15577@turing>

Hi,

I just finished packaging Mailman 3 for Archlinux.
I divided it into packages as follows:

mailman-core: the core mailman installation
mailman-django-git: a skeleton django project for serving hyperkitty and postorius
python2-django-postorius: the postorius module
python2-django-hyperkitty: the hyperkitty module
python-mailman-hyperkitty-plugin: hyperkitty plugin for archival
python-mailmanclient: python bindings for rest api
python2-mailmanclient: python bindings for rest api

python2-django-postorius-git: the postorius module (git-version)
python2-django-hyperkitty-git: the hyperkitty module (git-version)

mailman-suite-git: A dummy package installing everyhing that can be installed


For the dependencies I choose to go with that:
mailman-core: optionally depends on python-mailman-hyperkitty-plugin
              optionally depends on python-mailmanclient
              optionally depends on python2-mailmanclient

mailman-django-git: optionally depends on python2-django-postorius-git
                    optionally depends on python2-django-hyperkitty-git
                    optionally depends on python2-whoosh

python2-django-hyperkitty: depends on python2-mailmanclient

python2-django-postorius: depends on python2-mailmanclient

I will push non-git versions of mailman-django-git and mailman-suite-git.
However, currently they wont work, as hyperkitty's change from {{ STATIC_URL }} to {% static %} is
currently not yet released (just in master branch).
My mailman-django skeleton however requires {% static %}


Currently one dependency of hyperkitty isn't met yet, because
python2-django-compressor should be depending on python2-django-appconf.
However it's maintainer didn't add it. I am trying to contact him
and should resolve this within the next week.

The packages can be found in the AUR under this link:
https://aur.archlinux.org/packages/?SeB=m&K=thelinuxguy&O=0&PP=50

the whole dependency tree is as follows:
(it's probably not a complete list, but these packages should be present for Mailman3 to work)
mailman-suite:
  mailman-core
    postfix
    python-alembic
    python-falcon
    python-flufl-bounce
    python-flufl-i18n
    python-flufl-lock
    python-httplib2
    python-lazr-config
      python-lazr-delegates
    python-lazr-smtptest
    python-mock
    python-nose2
    python-passlib
    python-sqlalchemy
    python-zope-component
    python-zope-configuration
      python-zope-i18nmessageid
      python-zope-schema
    python-zope-event
    python-zope-interface
    python-mailman-hyperkitty-plugin
  mailman-django
    python2-django-hyperkitty
      python2-django
      lessc (nodejs-less)
      python2-dateutil
      python2-django-browserid
      python2-django-extensions
      python2-django-compressor
        python2-lxml
        python2-django-appconf
      python2-django-crispy-forms
      python2-django-gravatar
      python2-django-haystack
      python2-django-paintstore
      python2-django-rest-framework
      python2-enum34
      python2-networkx
      python2-pytz
      python2-robot-detection
      python2-social-auth
        python2-jwt
        python2-oauthlib
        python2-openid
        python2-requests
        python2-requests-oauthlib
        python2-six
      python2-mailmanclient
    python2-django-postorius
      python2-django
      python2-django-browser-id
      python2-httplib2
      python2-mailmanclient
    python2-whoosh

python-setuptools, python2-setuptools and git needed for building the packages
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20150913/1f904fc2/attachment.sig>

From becue at crans.org  Mon Sep 14 16:05:02 2015
From: becue at crans.org (Pierre-Elliott =?iso-8859-1?Q?B=E9cue?=)
Date: Mon, 14 Sep 2015 16:05:02 +0200
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <87oah9zbzn.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20150911024319.GA1347@turing>
 <87oah9zbzn.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20150914140501.GA9723@crans.org>

On ven. 11 sept. 2015 ? 15:49:48, Stephen J. Turnbull wrote:
> Simon Hanna writes:
> 
>  > Actually mailman-core is fully functional all alone.
> 
> That's not really true.  Sure, you can telnet to the REST port and
> speak REST by hand, but that's hardly pleasant.  At a minimum, you
> need mailmanclient.  (There will be alternatives, there was a GSoC
> project to provide a client that integrates with Node.js.  But at the
> moment that's not production-ready.)
> 
> Also, all this talk may be somewhat premature, as at present there's
> no authentication in the REST protocol, so everything needs to be on
> the same host.   Andrew Stuart's authenticating proxy will help with
> that, but AFAIK it's not integrated yet.  It may be worth waiting for
> that (and/or Mailman 3.1 with the migration story) before doing betas
> of the Debian package(s).

Good afternoon (UTC+0200),

Thanks for all your answers, I'm sorry not having answered earlier, but I
was having an Internet free weekend.

Thanks for all your suggestions, I'll think about different sources
packages, except maybe for mailman-core plus client?

Stephen, I was considering that 3.1 would be a better one to release in
debian, but maybe starting before would be good to see how things would go.
As I said, I did not for now packaged any big project, and I'm not a Debian
Dev, so I might be slower than a well trained uploading DD.

If you think I'm wrong, I'm eager to wait, if not, maybe I should start
slowly and try understand all dependencies and create a good bunch of
sources packages so that we'll be able to go faster when 3.1 is out.

Thanks, and cheers,

-- 
PEB

From fsantiago at deviltracks.net  Tue Sep 15 07:05:16 2015
From: fsantiago at deviltracks.net (Fabian Santiago)
Date: Tue, 15 Sep 2015 01:05:16 -0400
Subject: [Mailman-Developers] Mailman 3.0 + Qmail support
Message-ID: <EB8E910F-EFEE-4605-A81D-D5DA10051B3D@deviltracks.net>

Hello,

Just re-posting this on the appropriate list this time;

Any plans to support Qmail along with Mailman 3.0 and above? 

--

Fabe


From barry at list.org  Tue Sep 15 16:58:45 2015
From: barry at list.org (Barry Warsaw)
Date: Tue, 15 Sep 2015 10:58:45 -0400
Subject: [Mailman-Developers] Mailman 3.0 + Qmail support
In-Reply-To: <EB8E910F-EFEE-4605-A81D-D5DA10051B3D@deviltracks.net>
References: <EB8E910F-EFEE-4605-A81D-D5DA10051B3D@deviltracks.net>
Message-ID: <20150915105845.449e6a86@anarchist.wooz.org>

On Sep 15, 2015, at 01:05 AM, Fabian Santiago wrote:

>Any plans to support Qmail along with Mailman 3.0 and above? 

We'd be very happy to accept Qmail support if someone were to contribute it
and agree to help support it for some reasonable amount of time.  It shouldn't
be difficult.  Are you a Qmail expert and can you help out?

Cheers,
-Barry

From fsantiago at deviltracks.net  Tue Sep 15 17:51:06 2015
From: fsantiago at deviltracks.net (Fabian Santiago)
Date: Tue, 15 Sep 2015 11:51:06 -0400
Subject: [Mailman-Developers] Mailman 3.0 + Qmail support
In-Reply-To: <20150915105845.449e6a86@anarchist.wooz.org>
References: <EB8E910F-EFEE-4605-A81D-D5DA10051B3D@deviltracks.net>
 <20150915105845.449e6a86@anarchist.wooz.org>
Message-ID: <DC966C6D-862A-4DE7-9BB9-2B74EF26C902@deviltracks.net>

No I am not an expert but simply an avid user. I wish I could be of more help and of course would in any way I can. 

--

Fabe


> On Sep 15, 2015, at 10:58 AM, Barry Warsaw <barry at list.org> wrote:
> 
>> On Sep 15, 2015, at 01:05 AM, Fabian Santiago wrote:
>> 
>> Any plans to support Qmail along with Mailman 3.0 and above?
> 
> We'd be very happy to accept Qmail support if someone were to contribute it
> and agree to help support it for some reasonable amount of time.  It shouldn't
> be difficult.  Are you a Qmail expert and can you help out?
> 
> Cheers,
> -Barry

From stephen at xemacs.org  Tue Sep 15 18:33:04 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 16 Sep 2015 01:33:04 +0900
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <20150914140501.GA9723@crans.org>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20150911024319.GA1347@turing>
 <87oah9zbzn.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20150914140501.GA9723@crans.org>
Message-ID: <87twqvy75r.fsf@uwakimon.sk.tsukuba.ac.jp>

Pierre-Elliott B?cue writes:

 > Stephen, I was considering that 3.1 would be a better one to release in
 > debian, but maybe starting before would be good to see how things
 > would go.

Yes, and yes.  What I recommended was that you announce "beta" testing
once 3.1 is released and you've updated to that.

 > If you think I'm wrong, I'm eager to wait, if not, maybe I should start
 > slowly and try understand all dependencies and create a good bunch of
 > sources packages so that we'll be able to go faster when 3.1 is out.

Definitely!

Thank you very much for your interest, and of course for the work (in
advance)!

Steve


From becue at crans.org  Wed Sep 16 20:14:33 2015
From: becue at crans.org (Pierre-Elliott =?iso-8859-1?Q?B=E9cue?=)
Date: Wed, 16 Sep 2015 20:14:33 +0200
Subject: [Mailman-Developers] Let's try to package mailman3 in Debian!
In-Reply-To: <20150911100612.200131f1@limelight.wooz.org>
References: <20150910224944.GM8564@crans.org>
 <87wpvxzo63.fsf@uwakimon.sk.tsukuba.ac.jp>
 <20150911100612.200131f1@limelight.wooz.org>
Message-ID: <20150916181433.GI9723@crans.org>

On ven. 11 sept. 2015 ? 10:06:12, Barry Warsaw wrote:
> On Sep 11, 2015, at 11:26 AM, Stephen J. Turnbull wrote:
> 
> >Mailman3 (or mailman-suite) would be a trivial package that depends on
> >all of the above.
> 
> Yep, though I'd go with something like mailman3-suite.  Or you can reserve the
> 'mailman3' source package name for the umbrella package that depends on all
> the sub-components (e.g. mailman3-core, mailman3-client, etc.)

Good evening,

How about ITP?? Should I make only one on mailman3 package name or one per
component?

About debian django developers, do you have a specific idea about who I
should poke?

Thanks,

-- 
PEB

From fsantiago at garbage-juice.com  Mon Sep 28 23:50:21 2015
From: fsantiago at garbage-juice.com (Fabian Santiago)
Date: Mon, 28 Sep 2015 17:50:21 -0400
Subject: [Mailman-Developers] Mailman 3.0 on centos 7
Message-ID: <0CF3A126-689F-4B8F-8382-B8953790C962@garbage-juice.com>

Does anyone know where I can find more info on deploying mailman 3 on centos 7 aside from the standard docs site? 

I am having some difficulty and am unfamiliar with the python virtual env stuff so I'm interested in any help anyone can provide. 

Thanks all. 

Sincerely,

Fabian Santiago

Sent from my iPhone


From deansuhr at deansuhr.us  Tue Sep 29 01:01:58 2015
From: deansuhr at deansuhr.us (Dean Suhr)
Date: Mon, 28 Sep 2015 16:01:58 -0700
Subject: [Mailman-Developers] DMARC and Mailman 3
Message-ID: <9CFC4CCE-1EB9-400E-96FD-097DDA41CDFA@deansuhr.us>

Can someone clarify the optimization of Mailman 3 for MARC?  I?ve installed and the options are slightly different than MM 2.1.x and the documentation in the Wiki here: http://wiki.list.org/DEV/DMARC <http://wiki.list.org/DEV/DMARC>  which is fine, but I can?t find any post-release documentation.  The developer archives are mostly discussions from 2013.

Here?s the current option page and my take on them:

Filter content: [?Should Mailman filter the content of list traffic according to the settings below?]  ? this seems to be a master switch for everything below.

Collapse alternatives: [?Should Mailman collapse multipart/alternative to its first part content?] ? not DMARC

Convert html to plaintext:[?Should Mailman convert text/html parts to plain text? This conversion happens after MIME attachments have been stripped.] ? not DMARC

Anonymous list: [?Hide the sender of a message, replacing it with the list address (Removes From, Sender and Reply-To fields)] ? affects DMARC but not good for discussion/Reply to list style lists

Include RFC2369 headers: ? not DMARC

Include the list post header: ? not DMARC

Explicit reply-to address: ? not sure how/if this affects DMARC (which is a FROM thing).  Also not sure who this interest with REPLY GOES TO LIST, below. 

First strip reply to: ? not explicitly DMARC ? and how it interacts with EXPLICIT and REPLY GOES TO LIST options - seems like it must be done of either other option is enabled 

Reply goes to list: [?Where are replies to list messages directed? No Munging is strongly recommended for most mailing lists. This option controls what Mailman does to the Reply-To: header in messages flowing through this mailing list. When set to No Munging, no Reply-To: header is added by Mailman, although if one is present in the original message, it is not stripped. Setting this value to either Reply to List or Explicit Reply causes Mailman to insert a specific Reply-To: header in all messages, overriding the header in the original message if necessary (Explicit Reply inserts the value of reply_to_address). There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion. Some mailing lists have restricted posting privileges, with a parallel list devoted to discussions. Examples are `patches' or `checkin' lists, where software changes are posted by a revision control system, but discussion about the changes occurs on a developers mailing list. To support these types of mailing lists, select Explicit Reply and set the Reply-To: address option to point to the parallel list.]  

* Does selection REPLY-TO put in a reply header as well as re-write the FROM header?
 
* I want a REPLY to LIST style list where replies always go to the list.  Ideally, I'd like to see the sender?s name (And even email) in text portion of the FROM address even if the list address replaces the FROM address - which I think would solve the FROM/DMARC problem. 
 
Pipeline: [?Type of pipeline you want to use for this mailing list] ? can?t find any documentation on this

Thanks in advance,

Dean


From barry at list.org  Tue Sep 29 03:37:02 2015
From: barry at list.org (Barry Warsaw)
Date: Mon, 28 Sep 2015 21:37:02 -0400
Subject: [Mailman-Developers] DMARC and Mailman 3
In-Reply-To: <9CFC4CCE-1EB9-400E-96FD-097DDA41CDFA@deansuhr.us>
References: <9CFC4CCE-1EB9-400E-96FD-097DDA41CDFA@deansuhr.us>
Message-ID: <20150928213702.53e18e8c@anarchist.wooz.org>

On Sep 28, 2015, at 04:01 PM, Dean Suhr wrote:

>Can someone clarify the optimization of Mailman 3 for MARC?

The DMARC mitigations in MM2.1 really have not been ported to Mailman 3 yet.
Contributions welcome!

Cheers,
-Barry

From aurelien at bompard.org  Tue Sep 29 16:37:36 2015
From: aurelien at bompard.org (Aurelien Bompard)
Date: Tue, 29 Sep 2015 16:37:36 +0200
Subject: [Mailman-Developers] Mailman 3.0 on centos 7
In-Reply-To: <0CF3A126-689F-4B8F-8382-B8953790C962@garbage-juice.com>
References: <0CF3A126-689F-4B8F-8382-B8953790C962@garbage-juice.com>
Message-ID: <CAHmoxtXQv3mJ6YeKD9LcZs=7auDhNFJBOtghvpY1JDb39cO1iw@mail.gmail.com>

Hey Fabian,

> Does anyone know where I can find more info on deploying mailman 3 on centos 7 aside from the standard docs site?

I'm currently packaging Mailman3 and HyperKitty + Postorius for Red
Hat / CentOS 7. My packages are here:
https://repos.fedorapeople.org/repos/abompard/hyperkitty/el-7/x86_64/
and the repo file is here:
https://repos.fedorapeople.org/repos/abompard/hyperkitty/hyperkitty-el.repo
The repo contains all the dependencies too.

However, I'm updating the packages as I go, so they may be unstable,
contain unreleased patches and branches, etc. The SRPMs are there so
if you want to start with that and write your own, go ahead.
I hope it saves you some time.


Aur?lien

From fsantiago at garbage-juice.com  Tue Sep 29 17:05:02 2015
From: fsantiago at garbage-juice.com (Fabian Santiago)
Date: Tue, 29 Sep 2015 11:05:02 -0400
Subject: [Mailman-Developers] Mailman 3.0 on centos 7
In-Reply-To: <CAHmoxtXQv3mJ6YeKD9LcZs=7auDhNFJBOtghvpY1JDb39cO1iw@mail.gmail.com>
References: <0CF3A126-689F-4B8F-8382-B8953790C962@garbage-juice.com>
 <CAHmoxtXQv3mJ6YeKD9LcZs=7auDhNFJBOtghvpY1JDb39cO1iw@mail.gmail.com>
Message-ID: <86C6FB52-CF30-4272-99A6-47A4EDFDA8DC@garbage-juice.com>

That's awesome. I'll check this out ASAP. Thank you for your help. 

Sincerely,

Fabian Santiago

Sent from my iPhone

> On Sep 29, 2015, at 10:37 AM, Aurelien Bompard <aurelien at bompard.org> wrote:
> 
> Hey Fabian,
> 
>> Does anyone know where I can find more info on deploying mailman 3 on centos 7 aside from the standard docs site?
> 
> I'm currently packaging Mailman3 and HyperKitty + Postorius for Red
> Hat / CentOS 7. My packages are here:
> https://repos.fedorapeople.org/repos/abompard/hyperkitty/el-7/x86_64/
> and the repo file is here:
> https://repos.fedorapeople.org/repos/abompard/hyperkitty/hyperkitty-el.repo
> The repo contains all the dependencies too.
> 
> However, I'm updating the packages as I go, so they may be unstable,
> contain unreleased patches and branches, etc. The SRPMs are there so
> if you want to start with that and write your own, go ahead.
> I hope it saves you some time.
> 
> 
> Aur?lien