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
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
It seems that if I want to have a good source package, I need 5 repos :
- HyperKitty - MailMan Plugin
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
Am I also right?
Thanks for your answer, I hope I'll be able to make this package look as
you'd like. :)
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
"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. :-)
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:
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?
Hi Cabal. I'm sorry that I've neglected Mailman so much for the past
several months; I've just registered for PyCon 2016 and will be
ramping up my participation especially leading up to that.
has just announced that it wants to "identify up to 10 projects we
rely on and can fund in a thoughtful, meaningful way by December
12th". They use Mailman and if we can identify useful ways they can
spend that money to advance Mailman's development and usefulness to
them (e.g., paying for someone's time to get packaging or localization
to a better state), I'd be happy to take point on organizing that
Again, regrets on my absence.
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.
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:
You can find more information about the changes in each component by following
the version links in that overview page.
-Barry (on behalf of the entire Mailman development team)
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
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
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(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
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?
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
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!
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
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
=====================================[ Bill.Costa(a)unh.edu ]==
1 Leavitt Lane
UNH IT -- 1st Floor
University of New Hampshire
Durham, NH 03824
No good deed... Goes unpunished.
===========================[ http://pubpages.unh.edu/~wfc ]==