From Bill.Costa at unh.edu  Wed Nov  4 14:37:20 2015
From: Bill.Costa at unh.edu (Bill.Costa at unh.edu)
Date: Wed, 4 Nov 2015 14:37:20 -0500 (EST)
Subject: [Mailman-Developers] Mailman and Box
Message-ID: <alpine.LRH.2.03.1511041419100.24833@conundrum.unh.edu>

We will be retiring our Blackboard system (an e-learning portal)
which offered users 'organizations'; basically a combination of
group sharing of documents and collaboration via email.

I can't begin to duplicate all of the functionality of this part
of Blackboard, but I figured if I could link our school's Box
cloud storage with our new Mailman v2 installation, that would go
a long ways to provide a similar service.

The idea is that for every Mailman list created, a new Box shared
folder would also be created and associated with that list.  The
list owner and subscriber information would live in Mailman.  A
nightly reconciliation job would maintain the
list-owner/folder-owner roster and subscriber list between the
two systems.  Subscribers to the list would be granted, as a
whole, either reader or contributor access to the Box folder
(whatever the owner chooses).  The list-owner would be able to do
things like put the associated Box folder's URL into the list's
message footer.

Box provides a RESTful API, so I think I just might be able to
pull this off.

My question is, is there anybody else already doing this or
something similar?

...BC

-- 
=====================================[ Bill.Costa at unh.edu ]==
  Bill Costa
  1 Leavitt Lane
  UNH IT -- 1st Floor
  University of New Hampshire
  Durham, NH  03824
  USA
  Voice: +1-603-862-3056
  No good deed... Goes unpunished.
===========================[ http://pubpages.unh.edu/~wfc ]==

From mark at msapiro.net  Wed Nov  4 16:33:53 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 4 Nov 2015 13:33:53 -0800
Subject: [Mailman-Developers] Usenet gateway posting issue
Message-ID: <563A79C1.3040805@msapiro.net>

Due to the recent death and reincarnation of mail.python.org, we had to
find a new news server as a gateway to/from a few python.org lists.

I ran into an issue with the server we are now using. This is described
at <https://bugs.launchpad.net/bugs/1512866>.

The issue has to do with posts that may arrive via email to a list and
are thus gated to usenet. Posts which are gated from usenet to the list
are just posted to the list and are never gated back to usenet.

The issue is if a post arrives by email and already contains a
Newsgroups: header, the gateway will ensure that the group it gates to
is in the header, adding it if necessary. This can result in posts gated
to usenet with a Newsgroups: header mentioning other groups in addition
to the gating list's group. In our case, this seemed to cause a reject
if the other group didn't exist on the news server.

I thought about this and decided we shouldn't be gating posts to usenet
for groups other than the one(s) associated with the list and that the
correct fix is just to ensure that gated posts contain a single
Newsgroups: header mentioning only the target group(s).

Then it occurred to me that past behavior, in our case for example where
python-list gates to/from comp.lang.python and  python-announce-list
gates to/from comp.lang.python.announce that one could post by email to
only say python-list with a 'Newsgroups:
comp.lang.python,comp.lang.python.announce' header, the post would be
gated to the news server for both groups, and the next time the news
server is polled the post would come back for both lists and be posted
to python-announce-list (python-list would be bypassed because of
X-BeenThere:).

Note: that this scenario may or may not have 'Message-ID:' issues, but
assuming it works, my question is is this scenario a feature that people
actually use that I would break by only putting comp.lang.python in the
Newsgroups: header of posts gated from python-list or is it potentially
a bug that should be fixed.

Does anyone have an opinion on this?

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

From stephen at xemacs.org  Wed Nov  4 19:26:35 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 5 Nov 2015 09:26:35 +0900
Subject: [Mailman-Developers]  Mailman and Box
In-Reply-To: <alpine.LRH.2.03.1511041419100.24833@conundrum.unh.edu>
References: <alpine.LRH.2.03.1511041419100.24833@conundrum.unh.edu>
Message-ID: <22074.41531.560633.920628@turnbull.sk.tsukuba.ac.jp>

Moving to mailman-users, be a better place to post a request for
experience.

Please respect cross-posting restrictions.  If you're just reporting
experience, reply-to is set to Mailman-Users which is appropriate (at
least, IIRC the Mailman Users/Developers lists don't mess with
preexisting Reply-To).  If you have patched Mailman to make it work
better in this kind of application, you *may* wish to move the
conversation back to Mailman Developers to propose inclusin in a
future version of Mailman.  (If you just want to say "hey I have a
patch", I would leave that on -Users, FWIW YMMV.)

Bill.Costa at unh.edu writes:
 > We will be retiring our Blackboard system (an e-learning portal)
 > which offered users 'organizations'; basically a combination of
 > group sharing of documents and collaboration via email.
 > 
 > I can't begin to duplicate all of the functionality of this part
 > of Blackboard, but I figured if I could link our school's Box
 > cloud storage with our new Mailman v2 installation, that would go
 > a long ways to provide a similar service.
 > 
 > The idea is that for every Mailman list created, a new Box shared
 > folder would also be created and associated with that list.  The
 > list owner and subscriber information would live in Mailman.  A
 > nightly reconciliation job would maintain the
 > list-owner/folder-owner roster and subscriber list between the
 > two systems.  Subscribers to the list would be granted, as a
 > whole, either reader or contributor access to the Box folder
 > (whatever the owner chooses).  The list-owner would be able to do
 > things like put the associated Box folder's URL into the list's
 > message footer.
 > 
 > Box provides a RESTful API, so I think I just might be able to
 > pull this off.
 > 
 > My question is, is there anybody else already doing this or
 > something similar?

From efkin at cooperativa.cat  Tue Nov 10 18:29:07 2015
From: efkin at cooperativa.cat (efkin)
Date: Wed, 11 Nov 2015 00:29:07 +0100
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
Message-ID: <56427DC3.7080401@cooperativa.cat>

hi devs!

from calafou hacklab & friends we wanted to reimplement schleuder in
python. speaking and speaking we arrived at the conclusion that maybe
writing a plug-in for Mailman 3 could be a good solution: we contribute
to a great project and we have encrypt mailing list for hacktivist people.

first and obvious question: is there already an ongoing effort to
achieve gpg encryption that we could join?

if not:

we thought this plug-in as a milter (mail filter) with added features
for executing commands.

after reading your Core docs, things are little bit more complicated:
1. the preprocess (and maybe postprocess?) of the messages could be done
by what you call `chains` and `pipelines`
2. the command system could be implemented extending the already
existing Mailman command system (`echo` and `end`).
3. it is just not clear how to prompt if encripton is desired in your
ecosystem.

our questions are maybe:

* is there a plug-in way to tackle this problem?
* do we really need to submit a merge request to the core instead of
doing an optional debian package?
* are we totally on the wrong way? :)

thx for the support!
best wishes!

efkin.
Calafou.

From stefan.schlott at ulm.ccc.de  Wed Nov 11 03:28:45 2015
From: stefan.schlott at ulm.ccc.de (Stefan Schlott)
Date: Wed, 11 Nov 2015 09:28:45 +0100
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <56427DC3.7080401@cooperativa.cat>
References: <56427DC3.7080401@cooperativa.cat>
Message-ID: <5642FC3D.4020006@ulm.ccc.de>

Hi,

> from calafou hacklab & friends we wanted to reimplement schleuder in
> python. speaking and speaking we arrived at the conclusion that maybe
> writing a plug-in for Mailman 3 could be a good solution: we contribute
> to a great project and we have encrypt mailing list for hacktivist people.

imho a good idea. afaik is Schleuder undergoing a "v2 rewrite" - I have
the feeling they discovered  it's not that easy to write a mailinglist
manager (even without encryption) ;-)


> first and obvious question: is there already an ongoing effort to
> achieve gpg encryption that we could join?

I tried to do that ~10 years ago. I tried to implement an addition to
the pipeline chain. The patch was further maintained by Joost van
Baal-Ilic, who reverted the pipeline approach and made it a direct patch
for Mailman. As far as I can tell, the project is resting (I haven't
checked for a long time, though).

imho the pipeline chain approach is the preferable approach. I remember
I still had to do some minor patches at the Mailman core because some
operations weren't doable otherwise (plus the configuration settings).
Unfortunately, I haven't had time to have a closer look at Mailman 3, so
I can't tell if things have become easier there.


> * do we really need to submit a merge request to the core instead of
> doing an optional debian package?

My personal recommendation would be: Stick to separate modules (i.e. the
pipeline approach) as long as possible, this should make things easier
to maintain:

* the whole encryption stuff is a lot more tricky than one might think
at first sight
* you don't want to add instability for the majority (unfortunately) of
users who don't want to use any encryption on their mailing list


Good luck, I'd love to see someone picking up that usecase!


Stefan.

From stephen at xemacs.org  Wed Nov 11 05:51:00 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 11 Nov 2015 19:51:00 +0900
Subject: [Mailman-Developers]  [gpg] encrypted list management plug-in
In-Reply-To: <56427DC3.7080401@cooperativa.cat>
References: <56427DC3.7080401@cooperativa.cat>
Message-ID: <22083.7572.69116.738543@turnbull.sk.tsukuba.ac.jp>

efkin writes:

 > from calafou hacklab & friends we wanted to reimplement schleuder in
 > python.

URLs would be nice.

 > first and obvious question: is there already an ongoing effort to
 > achieve gpg encryption that we could join?

Not really, although there's been discussion of it; see below.  The
first big problem is use case; there are several and they demand
somewhat different treatment.  I suppose your use case is defined by
"schleuder", but I don't know what that is, and the first followup
suggests that they aren't 100% sure themselves. :-)

 > after reading your Core docs, things are little bit more complicated:
 > 1. the preprocess (and maybe postprocess?) of the messages could be done
 > by what you call `chains` and `pipelines`

Just pipelines, most likely.  The basic idea is that chains determine
whether messages are accepted for delivery at all, pipelines handle
transformations and actual delivery to various targets.

 > 2. the command system could be implemented extending the already
 > existing Mailman command system (`echo` and `end`).

What command system?  Do you mean the REST interface, or the GSoC
project to provide a nicer CLI?

 > 3. it is just not clear how to prompt if encripton is desired in your
 > ecosystem.

It is, at least by users.  There's been a GSoC project to add some
signature and encryption capabilities (IIRC only signatures were
implemented), but it's not been merged yet.

http://www.google-melange.com/gsoc/project/details/google/gsoc2013/maxking/5764017909923840

Abhilash, do you have anything to say? ;-)

 > * is there a plug-in way to tackle this problem?

What do you mean by "plug-in"?

 > * do we really need to submit a merge request to the core instead of
 > doing an optional debian package?

Given that you're intervening in the pipeline in a big way (have you
considered what your "plugin" might imply for DKIM and DMARC, as well
as various existing transformations that Mailman can apply?) and you
say you need to "extend the command system", I think the latter would
have to be considered a fork.  I doubt you'd get any support from the
Debian maintainership or Mailman core if you do that.

 > * are we totally on the wrong way? :)

Hard to tell.  I supervised the GSoC project mentioned above, but I
have no idea what you're talking about with respect to "schleuder".
That means there's a good chance nobody in core knows much, either.

So tell us about it, and then we'll tell you. :-)



From efkin at cooperativa.cat  Wed Nov 11 06:48:25 2015
From: efkin at cooperativa.cat (efkin)
Date: Wed, 11 Nov 2015 12:48:25 +0100
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <22083.7572.69116.738543@turnbull.sk.tsukuba.ac.jp>
References: <56427DC3.7080401@cooperativa.cat>
 <22083.7572.69116.738543@turnbull.sk.tsukuba.ac.jp>
Message-ID: <56432B09.1090900@cooperativa.cat>



On 11/11/2015 11:51 AM, Stephen J. Turnbull wrote:
> efkin writes:
> 
>  > from calafou hacklab & friends we wanted to reimplement schleuder in
>  > python.
> 
> URLs would be nice.

After some minimalist tackle to the problem we decided to start a small
research about the problem here[0]. And schleuder software is here[1].

[0] https://gitlab.com/calafou/lythyr/issues/1
[1] http://schleuder2.nadir.org/

>  > first and obvious question: is there already an ongoing effort to
>  > achieve gpg encryption that we could join?
> 
> Not really, although there's been discussion of it; see below.  The
> first big problem is use case; there are several and they demand
> somewhat different treatment.  I suppose your use case is defined by
> "schleuder", but I don't know what that is, and the first followup
> suggests that they aren't 100% sure themselves. :-)
> 
>  > after reading your Core docs, things are little bit more complicated:
>  > 1. the preprocess (and maybe postprocess?) of the messages could be done
>  > by what you call `chains` and `pipelines`
> 
> Just pipelines, most likely.  The basic idea is that chains determine
> whether messages are accepted for delivery at all, pipelines handle
> transformations and actual delivery to various targets.

Interesting.

>  > 2. the command system could be implemented extending the already
>  > existing Mailman command system (`echo` and `end`).
> 
> What command system?  Do you mean the REST interface, or the GSoC
> project to provide a nicer CLI?

something like what is described here:
http://mailman.readthedocs.org/en/release-3.0/src/mailman/commands/docs/end.html
it could be helpful, for example, to the mantainers of the encrypted
list to add one fingerprint/email to the mailing list object without
having to have shell access to the machine where it is installed.
maybe i just misunderstood what these commands are.
but the idea is that a mantainer could execute specific commands given a
special syntax in the firstline of an email.

>  > 3. it is just not clear how to prompt if encripton is desired in your
>  > ecosystem.
> 
> It is, at least by users.  There's been a GSoC project to add some
> signature and encryption capabilities (IIRC only signatures were
> implemented), but it's not been merged yet.
> 
> http://www.google-melange.com/gsoc/project/details/google/gsoc2013/maxking/5764017909923840
> 
> Abhilash, do you have anything to say? ;-)
> 
>  > * is there a plug-in way to tackle this problem?
> 
> What do you mean by "plug-in"?

well, basically something that could be packaged as mailman3-lythyr at
does not need to patch the core. i think Stefan suggested a modular
approach. and it seems quite reasonable.

>  > * do we really need to submit a merge request to the core instead of
>  > doing an optional debian package?
> 
> Given that you're intervening in the pipeline in a big way (have you
> considered what your "plugin" might imply for DKIM and DMARC, as well
> as various existing transformations that Mailman can apply?) and you
> say you need to "extend the command system", I think the latter would
> have to be considered a fork.  I doubt you'd get any support from the
> Debian maintainership or Mailman core if you do that.

we obviously want to avoid a fork. at the same time, the three of us,
that would work on this project, are quite unaware of mailman3 and
mailman in general architecture. but at the same time we are enthusiast
of researching it and happy to code for it.


>  > * are we totally on the wrong way? :)
> 
> Hard to tell.  I supervised the GSoC project mentioned above, but I
> have no idea what you're talking about with respect to "schleuder".
> That means there's a good chance nobody in core knows much, either.

well, hope the links i gave at the beginning are enough. if you need
some more info just let us know.

> So tell us about it, and then we'll tell you. :-)
> 

From efkin at cooperativa.cat  Wed Nov 11 06:58:11 2015
From: efkin at cooperativa.cat (efkin)
Date: Wed, 11 Nov 2015 12:58:11 +0100
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <5642FC3D.4020006@ulm.ccc.de>
References: <56427DC3.7080401@cooperativa.cat> <5642FC3D.4020006@ulm.ccc.de>
Message-ID: <56432D53.8080504@cooperativa.cat>



On 11/11/2015 09:28 AM, Stefan Schlott wrote:
> Hi,
> 
>> from calafou hacklab & friends we wanted to reimplement schleuder in
>> python. speaking and speaking we arrived at the conclusion that maybe
>> writing a plug-in for Mailman 3 could be a good solution: we contribute
>> to a great project and we have encrypt mailing list for hacktivist people.
> 
> imho a good idea. afaik is Schleuder undergoing a "v2 rewrite" - I have
> the feeling they discovered  it's not that easy to write a mailinglist
> manager (even without encryption) ;-)
> 
> 
>> first and obvious question: is there already an ongoing effort to
>> achieve gpg encryption that we could join?
> 
> I tried to do that ~10 years ago. I tried to implement an addition to
> the pipeline chain. The patch was further maintained by Joost van
> Baal-Ilic, who reverted the pipeline approach and made it a direct patch
> for Mailman. As far as I can tell, the project is resting (I haven't
> checked for a long time, though).

wow 10 years ago!  can u give me a link to the project?
so as far i understood by the archive,  recurrently in time somebody
appears saying that he/she 's gonna develop this feature. but there was
this funny answer that said "this feature may be implmented in  mailman
3". so maybe we are at the right moment in the right place :)

> imho the pipeline chain approach is the preferable approach. I remember
> I still had to do some minor patches at the Mailman core because some
> operations weren't doable otherwise (plus the configuration settings).
> Unfortunately, I haven't had time to have a closer look at Mailman 3, so
> I can't tell if things have become easier there.
> 
> 
>> * do we really need to submit a merge request to the core instead of
>> doing an optional debian package?
> 
> My personal recommendation would be: Stick to separate modules (i.e. the
> pipeline approach) as long as possible, this should make things easier
> to maintain:
> 
> * the whole encryption stuff is a lot more tricky than one might think
> at first sight
> * you don't want to add instability for the majority (unfortunately) of
> users who don't want to use any encryption on their mailing list
> 

so, as far as i understood, your proposal is actually to write separate
modules that import actually existing modules and add functionality over
them?

it seems reasonable to me...



> Good luck, I'd love to see someone picking up that usecase!

thx.

> Stefan.

efkin.

 _______________________________________________
> 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/efkin%40cooperativa.cat
> 
> Security Policy: http://wiki.list.org/x/QIA9
> 

From barry at list.org  Wed Nov 11 10:32:56 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 11 Nov 2015 10:32:56 -0500
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <56427DC3.7080401@cooperativa.cat>
References: <56427DC3.7080401@cooperativa.cat>
Message-ID: <20151111103256.7f5ee48a@limelight.wooz.org>

Just to add to what others have mentioned.  "Encrypted mailing lists" mean
different things to different people, so being precise about the features
you're interested in will be key.  There are very likely some fundamental work
that would need to be done in any case (e.g. connecting pubkeys to users).

On Nov 11, 2015, at 12:29 AM, efkin wrote:

>after reading your Core docs, things are little bit more complicated:
>1. the preprocess (and maybe postprocess?) of the messages could be done
>by what you call `chains` and `pipelines`

Chains are used in the moderation process, i.e. making the decision "should
this message get posted to the mailing list".  So if you wanted to make
posting decisions based on message signatures, there would be a rule to parse
the signature, verify it, match it to a user, and register a rule "hit" if it
matches.  The link containing this rule might have a jump action to
immediately accept (i.e. jump to the accept chain) it if the signature
matched.  Rules are not allowed to modify the message.

If "encrypted lists" are a special thing, there might even be a named chain
that can be used instead of the default chain for those mailing lists that
need this feature.

Pipelines come into play *after* the message has been accepted for posting.
They contain handlers which modify the message in some way.  So if "encrypted
mailing list" means to sign the message with a list key, this could happen in
a handler.  Note that handlers can currently only handle modifications that
would affect all recipients of the message.  For personalized modifications
(e.g. VERPing or re-encrypting the message to individual recipient's pubkey),
some changes to the code would have to happen; ideally we'd be able to define
pipelines that would be called at MTA delivery time.

>* do we really need to submit a merge request to the core instead of
>doing an optional debian package?

This feature, once properly scoped, isn't going to be a "one merge request"
submission.  There are multiple fundamental changes that could happen along
the way, and some of those might be appropriate for core.

Cheers,
-Barry

From barry at list.org  Wed Nov 11 10:39:59 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 11 Nov 2015 10:39:59 -0500
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <56432B09.1090900@cooperativa.cat>
References: <56427DC3.7080401@cooperativa.cat>
 <22083.7572.69116.738543@turnbull.sk.tsukuba.ac.jp>
 <56432B09.1090900@cooperativa.cat>
Message-ID: <20151111103959.4a5c6643@limelight.wooz.org>

On Nov 11, 2015, at 12:48 PM, efkin wrote:

>> What do you mean by "plug-in"?
>
>well, basically something that could be packaged as mailman3-lythyr at
>does not need to patch the core. i think Stefan suggested a modular
>approach. and it seems quite reasonable.

The intent of Mailman 3 is that additions like this could be packaged as
separate modules, and through config file change could be pulled in and used
by the core.  The reality is that the core may need some code changes so that
all the necessary plug points could be exposed.  This is part of what I said
before about multiple merge proposals.

Cheers,
-Barry

From barry at list.org  Wed Nov 11 10:43:34 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 11 Nov 2015 10:43:34 -0500
Subject: [Mailman-Developers] [gpg] encrypted list management plug-in
In-Reply-To: <5642FC3D.4020006@ulm.ccc.de>
References: <56427DC3.7080401@cooperativa.cat>
	<5642FC3D.4020006@ulm.ccc.de>
Message-ID: <20151111104334.780b3a9a@limelight.wooz.org>

On Nov 11, 2015, at 09:28 AM, Stefan Schlott wrote:

>I tried to do that ~10 years ago. I tried to implement an addition to
>the pipeline chain. The patch was further maintained by Joost van
>Baal-Ilic, who reverted the pipeline approach and made it a direct patch
>for Mailman. As far as I can tell, the project is resting (I haven't
>checked for a long time, though).
>
>imho the pipeline chain approach is the preferable approach. I remember
>I still had to do some minor patches at the Mailman core because some
>operations weren't doable otherwise (plus the configuration settings).
>Unfortunately, I haven't had time to have a closer look at Mailman 3, so
>I can't tell if things have become easier there.

An important difference between MM2 and MM3 is that in MM2, both moderation
and modification functions were intertwined in a single pipeline-of-handlers
mechanism.  This turned out to be to unwieldy so in MM3, we split moderation
into a pre-processing chain of links-and-rules, and modification into a
post-acceptance pipeline of handlers.  The latter looks a lot like MM2's
pipeline of handlers, except of course that it does not make moderation
decisions.

Cheers,
-Barry

From barry at list.org  Thu Nov 12 18:36:45 2015
From: barry at list.org (Barry Warsaw)
Date: Thu, 12 Nov 2015 18:36:45 -0500
Subject: [Mailman-Developers] Usenet gateway posting issue
In-Reply-To: <563A79C1.3040805@msapiro.net>
References: <563A79C1.3040805@msapiro.net>
Message-ID: <20151112183645.0287625c@limelight.wooz.org>

On Nov 04, 2015, at 01:33 PM, Mark Sapiro wrote:

>Then it occurred to me that past behavior, in our case for example where
>python-list gates to/from comp.lang.python and  python-announce-list
>gates to/from comp.lang.python.announce that one could post by email to
>only say python-list with a 'Newsgroups:
>comp.lang.python,comp.lang.python.announce' header, the post would be
>gated to the news server for both groups, and the next time the news
>server is polled the post would come back for both lists and be posted
>to python-announce-list (python-list would be bypassed because of
>X-BeenThere:).
>
>Note: that this scenario may or may not have 'Message-ID:' issues, but
>assuming it works, my question is is this scenario a feature that people
>actually use that I would break by only putting comp.lang.python in the
>Newsgroups: header of posts gated from python-list or is it potentially
>a bug that should be fixed.
>
>Does anyone have an opinion on this?

I'm not aware of anybody using this, but I agree with your original decision.
I don't think users should count on this accidental workflow.

Cheers,
-Barry

From barry at list.org  Sun Nov 15 14:42:19 2015
From: barry at list.org (Barry Warsaw)
Date: Sun, 15 Nov 2015 14:42:19 -0500
Subject: [Mailman-Developers] ANNOUNCING: GNU Mailman 3.0.1
Message-ID: <20151115144219.5ec1c4d6@anarchist.wooz.org>

I'm happy to announce the first maintenance release of GNU Mailman 3.  This
version 3.0.1 release includes updates to the core, Postorius, HyperKitty, and
mailman.client.  The release matrix of versions is available here:

    http://wiki.list.org/Mailman3

You can find more information about the changes in each component by following
the version links in that overview page.

Enjoy,
-Barry (on behalf of the entire Mailman development team)
-------------- 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/20151115/9e592500/attachment.sig>

From clopez at igalia.com  Mon Nov 16 21:14:39 2015
From: clopez at igalia.com (Carlos Alberto Lopez Perez)
Date: Tue, 17 Nov 2015 03:14:39 +0100
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
Message-ID: <564A8D8F.8060907@igalia.com>

Hi,

By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file
with this configuration:

DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain']


So, when someone enables filtering on a mailing list by mime-type, the default is
to filter all emails not matching any of those 3 mime-types.

Therefore, this is unfortunately filtering multipart/signed emails.

multipart/signed is defined on RFC 4880 and 3156 and is the recommended way of
signing mails with GPG: See http://wiki.gnupg.org/SignatureHandling
As an example, this email is multipart/signed.


This default causes trouble to people that signs their mails with GPG.
I already had problems due to this default on the Alioth Debian mailing lists
and on the WebKit mailing lists.


Please, change this default by adding multipart/signed to the list of types allowed.


Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 883 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20151117/d865f6a9/attachment.sig>

From mark at msapiro.net  Tue Nov 17 01:29:42 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 16 Nov 2015 22:29:42 -0800
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
In-Reply-To: <564A8D8F.8060907@igalia.com>
References: <564A8D8F.8060907@igalia.com>
Message-ID: <564AC956.30106@msapiro.net>

On 11/16/15 6:14 PM, Carlos Alberto Lopez Perez wrote:
> Hi,
> 
> By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file
> with this configuration:
> 
> DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain']
...
> Please, change this default by adding multipart/signed to the list of types allowed.


There are other issues, but if you file a bug, I will change it to
['multipart', 'text/plain', 'application/pgp-signature'] or ???.

There are other signature types that are 'binary' rather than plain
ascii text, and I'm reluctant to include those. On my own site, I
include 'message/rfc822' as well and could consider that.

File the bug at <https://bugs.launchpad.net/mailman/+filebug> for MM 2.1
and <https://gitlab.com/mailman/mailman> for MM 3.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20151116/9fee35ae/attachment.sig>

From clopez at igalia.com  Wed Nov 18 07:35:03 2015
From: clopez at igalia.com (Carlos Alberto Lopez Perez)
Date: Wed, 18 Nov 2015 13:35:03 +0100
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
In-Reply-To: <564AC956.30106@msapiro.net>
References: <564A8D8F.8060907@igalia.com> <564AC956.30106@msapiro.net>
Message-ID: <564C7077.7020102@igalia.com>

On 17/11/15 07:29, Mark Sapiro wrote:
> On 11/16/15 6:14 PM, Carlos Alberto Lopez Perez wrote:
>> Hi,
>>
>> By default, mailman tarballs (at least the 2.x ones) contain a Defaults.py file
>> with this configuration:
>>
>> DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain']
> ...
>> Please, change this default by adding multipart/signed to the list of types allowed.
> 
> 
> There are other issues, but if you file a bug, I will change it to
> ['multipart', 'text/plain', 'application/pgp-signature'] or ???.
> 

I was thinking in changing it to :

['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain']

Instead, you suggest to just add [ 'multipart' ] to the list. I have 2 questions:
 - Will 'multipart' match all the 3 previous multipart/variations?
 - Is there any multipart/variation that we shouldn't allow by default?

If the answer is yes to the first question and no/notsure the second one,
then I think is a good idea to just add 'multipart'

Not sure regarding 'application/pgp-signature'. I guess we can include it also.


> There are other signature types that are 'binary' rather than plain
> ascii text, and I'm reluctant to include those. On my own site, I
> include 'message/rfc822' as well and could consider that.
> 

Sounds like a good idea, probably is also worth including message/rfc822 in
the default list of accepted mime types.

> File the bug at <https://bugs.launchpad.net/mailman/+filebug> for MM 2.1

Filed: https://bugs.launchpad.net/mailman/+bug/1517446

> and <https://gitlab.com/mailman/mailman> for MM 3.

I wasn't able to find a Defaults.py on the Mailman3 tarballs.
Neither an alternative config file with this default.

Where are the defaults of Mailman 3 specified?
Has the default for DEFAULT_PASS_MIME_TYPES changed?

Regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 883 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20151118/d98efc2d/attachment.sig>

From barry at list.org  Wed Nov 18 10:00:15 2015
From: barry at list.org (Barry Warsaw)
Date: Wed, 18 Nov 2015 10:00:15 -0500
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
In-Reply-To: <564C7077.7020102@igalia.com>
References: <564A8D8F.8060907@igalia.com> <564AC956.30106@msapiro.net>
 <564C7077.7020102@igalia.com>
Message-ID: <20151118100015.5cdcfdcc@limelight.wooz.org>

On Nov 18, 2015, at 01:35 PM, Carlos Alberto Lopez Perez wrote:

>I wasn't able to find a Defaults.py on the Mailman3 tarballs.
>Neither an alternative config file with this default.
>
>Where are the defaults of Mailman 3 specified?

System-wide defaults in MM3 are specified in ini-style .cfg files, but that's
somewhat irrelevant to this case.

>Has the default for DEFAULT_PASS_MIME_TYPES changed?

Actually, there aren't any default pass or filter types on the mailing list
objects currently, although if a list is migrated from MM2, the filters are
ported over.

When a mailing list is created, a 'style' is applied.  An implementation
strategy would be to add the pass and filter types to a style.  Probably
BasicOperation class in src/mailman/styles/base.py.  Or refactor the
filter/pass stuff into a separate style class which can be composed in the
LegacyDefaultStyle class.  Extra points for adding the defaults to the
schema.cfg file.

If you want to submit a bug against MM3, please have it say something like
"add MIME pass and filter types to the default list styles".

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/20151118/a8391931/attachment.sig>

From mark at msapiro.net  Wed Nov 18 11:17:17 2015
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 18 Nov 2015 08:17:17 -0800
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
In-Reply-To: <564C7077.7020102@igalia.com>
References: <564A8D8F.8060907@igalia.com> <564AC956.30106@msapiro.net>
 <564C7077.7020102@igalia.com>
Message-ID: <564CA48D.6020507@msapiro.net>

On 11/18/15 4:35 AM, Carlos Alberto Lopez Perez wrote:
> 
> I was thinking in changing it to :
> 
> ['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain']
> 
> Instead, you suggest to just add [ 'multipart' ] to the list. I have 2 questions:
>  - Will 'multipart' match all the 3 previous multipart/variations?


'multipart' will match any MIME multipart/anything content type,
including those 3 and multipart/related, multipart/report, etc. See
<http://www.iana.org/assignments/media-types/media-types.xhtml#multipart> for
the registered sub-types, but some MUAs may create even others.


>  - Is there any multipart/variation that we shouldn't allow by default?


Multipart parts are those which contain other parts as sub-parts. Since
ultimately, the elemental (non-multipart) parts that are contained in
the multipart part must be explicitly allowed, passing any multipart
part should be safe.

I.e., considering your issue, you want to accept text/plain parts but
they are contained in a multipart/signed part which is not accepted, so
those parts are removed.

It doesn't matter what multipart types you accept. If the only elemental
parts you accept are text/plain, the only elemental parts that will
remain after filtering is text/plain parts.


> If the answer is yes to the first question and no/notsure the second one,
> then I think is a good idea to just add 'multipart'
> 
> Not sure regarding 'application/pgp-signature'. I guess we can include it also.


This depends on your objective in accepting multipart/signed. If you
only care about accepting the text and don't mind if the signature is
stripped, you don't need to accept signature parts, but if you want to
actually deliver a signed or partially signed message to the list, you
need to accept the signature parts as well. These include in decreasing
order of frequency observed, application/pgp-signature,
application/pkcs7-signature and application/x-pkcs7-signature.


> Filed: https://bugs.launchpad.net/mailman/+bug/1517446


Noted. Thanks.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20151118/af0a290f/attachment.sig>

From stephen at xemacs.org  Thu Nov 19 03:00:21 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 19 Nov 2015 17:00:21 +0900
Subject: [Mailman-Developers] Please add multipart/signed to
 DEFAULT_PASS_MIME_TYPES
In-Reply-To: <564C7077.7020102@igalia.com>
References: <564A8D8F.8060907@igalia.com> <564AC956.30106@msapiro.net>
 <564C7077.7020102@igalia.com>
Message-ID: <22093.33173.71324.362781@turnbull.sk.tsukuba.ac.jp>

Carlos Alberto Lopez Perez writes:

 > Instead, you suggest to just add [ 'multipart' ] to the list. I
 > have 2 questions:
 >  - Will 'multipart' match all the 3 previous multipart/variations?

Yes.

 >  - Is there any multipart/variation that we shouldn't allow by default?

The only other multipart I can think of offhand is multipart/related.
Let's see what Google turns up: multipart/form-data (probably
shouldn't be allowed, but very unlikely to show up except perhaps in
an attack), multiport/report (used for email reports such as delivery
status notifications, but it's basically multipart/mixed -- not a
problem that I can see, but perhaps should trigger administrivia
filters), and multipart/encrypted.  There is also at least one that is
mostly useful in HTTP (multipart/byteranges).

 > Sounds like a good idea, probably is also worth including
 > message/rfc822 in the default list of accepted mime types.

That's a definite "maybe".  There are known to be MUAs that can't
handle embedded messages.  (That's why we can't recommend "Wrap
Message" as the standard workaround for DMARC.)




From sumanah at panix.com  Fri Nov 20 14:04:32 2015
From: sumanah at panix.com (Sumana Harihareswara)
Date: Fri, 20 Nov 2015 19:04:32 +0000
Subject: [Mailman-Developers] Mozilla funding opportunity for Mailman
 work
In-Reply-To: <563072E1.70504@gmail.com>
References: <562E4113.9080004@panix.com>
 <20151027185221.508cebe8@limelight.wooz.org>
 <22064.20353.452872.487566@turnbull.sk.tsukuba.ac.jp>
 <563072E1.70504@gmail.com>
Message-ID: <65p4fv.ny4nnn.8jtxv1-qmf@mailbackend.panix.com>

I saw on the MOSS list that the proposal deadline is about 3 days away.

If no one thinks it's objectionable, I could suggest putting in a proposal to pay for testing, bug triage work, i18n work (choosing a new platform and porting our translation effort to a new platform), and similar project management work. I have just started a FLOSS project management consulting firm http://changeset.nyc and could do this work. I am trying to limit my suggestions here to stuff that's backlogged and that volunteers don't have enough time + interest to do in the next 3 months.

Sumana 


On Wed Oct 28 03:01:53 2015 GMT-0400, Abhilash Raj wrote:
> 
> On 10/27/2015 09:30 PM, Stephen J. Turnbull wrote:
> > Barry Warsaw writes:
> > 
> >  > What would *we* like to do that we can't do because of resources?
> > 
> > That's where I'm blocked.  I can't honestly put myself up as a
> > money-sink: I wouldn't mind getting paid for my effort, but I wouldn't
> > put in any less effort just because I'm unpaid. ;-)
> > 
> > Hm ... maybe generalizing Andrew's authn/authz stuff?  Mozilla would
> > probably like improved Persona support?  Andrew would be good for that
> > and ISTR he's a freelancer.
> > 
> > I wouldn't mind compensating a student even if she/he would do the
> > work for free anyway.  But except for Abhilash, I can't recommend any
> > recent student for a project I think is valuable enough to request
> > such resources without at the same time volunteering to mentor
> > intensively.  Not enough experience, and the project I have in mind is
> > not an extension of any GSoC project.  And I can't really volunteer at
> > this point.
> > 
> > As for Abhilash himself, I think he should concentrate on his graduate
> > studies.  There's no problem with him volunteering the occasional
> > half-day to Mailman, but I've seen far too many students seriously
> > hindered in getting the most out of their graduate study by committing
> > to consulting work.  I won't oppose him if he wants to do something,
> > but I won't nominate him.
> 
> I doubt I would be able to actually do a contract work at all, even if I
> wanted to, due to F-1 Visa regulations. Not for next 8 months at least.
> And I have too much in my plate right now, grad school keep me busy! But
> I can spend some time to mentor/help someone else as a volunteer for
> whichever project we choose.
> 
>   (@Abhilash: If you decide to apply against
> > my advice, it's just advice.  I'll be happy to support you to the
> > extent I can in your Mailman work or your graduate study, whatever you
> > want to do -- though I suspect I'd be useless in the latter role. ;-)
> 
> (off the topic: Prof, I would like to talk to you sometime for some
> advice about studies :)
> 
> > 
> > If somebody else is willing to mentor *my* suggestions: there are a
> > couple of new proposals for DMARC mitigation out there.  I would be
> > willing to evaluate them (in the remaining hours) for use in Mailman.
> > Why "evaluate"?  As most of you probably know, message signing and
> > signature validation are normally considered MTA functions, and
> > Mailman needn't/shouldn't try to duplicate that functionality.
> > However, with experimental protocols, of course they won't be in
> > production MTAs for a while, so it *might* be worthwhile to offer
> > support in Mailman as a spur/temporary workaround while the MTAs
> > implement the new protocols.
> 
> Again off the topic: I recently came to know (from my Advisor) that my
> implementation of Digital signatures in mailman can be improved by
> implementing algorithms where the server does not actually decrypts the
> email, just transforms it so that the recipients can decrypt that. I
> don't have the details, but I am gonna explore more in that front soon.
> 
> 
> > 
> > I don't (yet) have a developer to recommend, though.
> > 
> > Steve
> > 
> > _______________________________________________
> > 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/raj.abhilash1%40gmail.com
> > 
> > Security Policy: http://wiki.list.org/x/QIA9
> > 
> 
> -- 
> thanks,
> Abhilash Raj
> 
>

-- 
Please excuse terseness; sent from mobile.

From becue at crans.org  Sun Nov 22 20:56:27 2015
From: becue at crans.org (Pierre-Elliott =?iso-8859-1?Q?B=E9cue?=)
Date: Mon, 23 Nov 2015 02:56:27 +0100
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: <20151123015627.GB10971@crans.org>

Le vendredi 11 septembre 2015 ? 00:49:44+0200, Pierre-Elliott B?cue a ?crit?:
> [packaging mailman3]

Hey,

Here is an update.

For now on, I focused on mailman3-core package in order to get good
practices working.

One can find my work here : https://github.com/P-EB/mailman3-core

I'm working on having working systemd/sysv services and after that it'll be
a good idea to try installing the package and see how it goes.

I also have to design a good config file for debian, (see
debian/contrib/mailman.cfg in master branch). Any suggestion is welcome!

Cheers

-- 
PEB

From andrew at hodgsonfamily.org  Tue Nov 24 10:32:41 2015
From: andrew at hodgsonfamily.org (Andrew Hodgson)
Date: Tue, 24 Nov 2015 15:32:41 +0000
Subject: [Mailman-Developers] Mailman 3 production setup testbed
Message-ID: <HE1PR04MB1244545EA8B2C71691730346C5060@HE1PR04MB1244.eurprd04.prod.outlook.com>

Hi Guys,

I am a MM3 newbie coming from MM 2.1.  I use Debian as my distro of choice.  I am trying to follow the docs at:
http://mailman-bundler.readthedocs.org/en/latest/
I want to set up as a production environment, the idea is we will be getting people used to the MM3 interface and ways of working before we eventually migrate when 3.1 becomes available.  I would have posted this to the users list, but recent traffic on there regarding MM 3.0 has been redirected to the dev list.

My confusion relates to the virtual environment that I create.  I am running from the dedicated MM3 user I created, and I am looking to expand the bundler from the user?s home directory in /home (for example).  When I create the virtual environment, the files are all held in this directory, and I really want the MM3 to be installed system wide as this will be the only program running on this machine.  Do I even need to create a virtual environment at all?  Are there any other guides relating to setting up MM3 for a purely production environment with minimal dependencies?

Thanks,
Andrew.

From stephen at xemacs.org  Tue Nov 24 22:00:50 2015
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 25 Nov 2015 12:00:50 +0900
Subject: [Mailman-Developers]  Mailman 3 production setup testbed
In-Reply-To: <HE1PR04MB1244545EA8B2C71691730346C5060@HE1PR04MB1244.eurprd04.prod.outlook.com>
References: <HE1PR04MB1244545EA8B2C71691730346C5060@HE1PR04MB1244.eurprd04.prod.outlook.com>
Message-ID: <22101.9314.665693.246396@turnbull.sk.tsukuba.ac.jp>

Andrew Hodgson writes:

 > I want to set up as a production environment, the idea is we will
 > be getting people used to the MM3 interface and ways of working
 > before we eventually migrate when 3.1 becomes available.  I would
 > have posted this to the users list, but recent traffic on there
 > regarding MM 3.0 has been redirected to the dev list.

FYI, this is the kind of thing that would be perfectly reasonable and
useful to post to Mailman Users.  It deals with general Python, email,
and OS-level knowledge and doesn't really require even knowing that
Mailman 3 is a collection of three programs integrated by a REST API.

I'll deal with finding an appropriate place in the docs, no need to
repost to MM Users.

 > My confusion relates to the virtual environment that I create.  I
 > am running from the dedicated MM3 user I created, and I am looking
 > to expand the bundler from the user?s home directory in /home (for
 > example).  When I create the virtual environment, the files are all
 > held in this directory, and I really want the MM3 to be installed
 > system wide as this will be the only program running on this
 > machine.

"System wide" doesn't really have any meaning in Unix, and especially
not for pure network services.  What benefits do you expect from a
"system wide" installation?

 > Do I even need to create a virtual environment at all?

No, but it is still recommended.  The basic problem is what Windows
developers refer to as "DLL hell" -- different programs require
different versions of the same external software.  AFAIK, several of
the dependencies of the Mailman 3 suite are still specified as exact
versions, not "this version or later", because this helps ensure a
constant environment for bug diagnosis.

>From your point of view, what this means is that if you upgrade
Mailman using a new virtual environment for each upgrade, you can
revert to an older version simply by stopping the new version and
starting the old version.  (Assuming file formats don't change, of
course, but at least Mailman detects those and for upgrades will
upgrade them automatically.)  It takes a few more minutes for each
installation, but can save many hours of hair pulling downtime due to
dependency conflicts at installation and mysterious bugs at runtime.

Because Mailman 3 is still evolving rapidly, I suspect you may find
new versions very attractive.  I would put my money on the virtual
environment approach until a Mailman 3 package is available in Debian
"testing" if I were you.  At that point, the whole issue evaporates.

 > Are there any other guides relating to setting up MM3 for a purely
 > production environment with minimal dependencies?

Probably not yet.  If you decide to go that way, please do tell us
about your experience. :-)



From cp at ccil.org  Tue Nov 24 23:04:12 2015
From: cp at ccil.org (Chuck Peters)
Date: Tue, 24 Nov 2015 23:04:12 -0500
Subject: [Mailman-Developers] unsubscribe
Message-ID: <20151125040412.GL25312@ccil.org>

unsubscribe


From adam-mailman at amyl.org.uk  Wed Nov 25 06:30:54 2015
From: adam-mailman at amyl.org.uk (Adam McGreggor)
Date: Wed, 25 Nov 2015 11:30:54 +0000
Subject: [Mailman-Developers] Mailman 3 production setup testbed
In-Reply-To: <22101.9314.665693.246396@turnbull.sk.tsukuba.ac.jp>
References: <HE1PR04MB1244545EA8B2C71691730346C5060@HE1PR04MB1244.eurprd04.prod.outlook.com>
 <22101.9314.665693.246396@turnbull.sk.tsukuba.ac.jp>
Message-ID: <20151125113054.GC21217@hendricks.amyl.org.uk>

On Wed, Nov 25, 2015 at 12:00:50PM +0900, Stephen J. Turnbull wrote:
> Andrew Hodgson writes:
>  > Are there any other guides relating to setting up MM3 for a purely
>  > production environment with minimal dependencies?
> 
> Probably not yet.  If you decide to go that way, please do tell us
> about your experience. :-)

I followed the RTD guide[1]: one thing I keep meaning to do, is add
a note (via a PR) that if the installation/buildout fails with a pbr
error (read your trackbacks!), a workaround is to remove the
require(ments) file in mailman-bundler/eggs/pbr-1.8.1-py2.7.egg .

There's a note somewhere in the (presumed) archive of
irc://irc.freenode.net#mailman from a few weeks ago, too.

[1] http://mailman-bundler.readthedocs.org/en/latest/

-- 
"There seems to be something wrong with our bloody ships today"
    -- David, Vice-Admiral Beatty (re: the Battle of the Jutland)