[Mailman-Developers] [gpg] encrypted list management plug-in

Stephen J. Turnbull stephen at xemacs.org
Wed Nov 11 05:51:00 EST 2015


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. :-)




More information about the Mailman-Developers mailing list