
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:
- the preprocess (and maybe postprocess?) of the messages could be done by what you call
chains
andpipelines
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.
- the command system could be implemented extending the already existing Mailman command system (
echo
andend
).
What command system? Do you mean the REST interface, or the GSoC project to provide a nicer CLI?
- 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/5...
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. :-)