I want to install, and use, MM 3. I'm on a single-user, Debian 7
server, and control the whole thing.
Is it important to use a virtual environment? I'm sure I will be
updating from the development branch until the stable release, and I
am prepared to have interruptions in service along the way.
Note that I may eventually allow other users, but I will probably
remain the supreme administrator.
Successful requests to the REST API return a 2xx HTTP code to indicate success either with or without JSON data depending on the context of the request.
At least one (I’ve not checked the othes yet) 4xx error returned from the REST API returns a plain text error message rather than a JSON error message.
For example attempting to create a domain that exists returns a 400 error with the response text “Domain exists”.
Do you think this matters? Probably not much but does mean handling valid responses goes down a JSON path and handling error message goes down a plain text path. JSON error messages might arguable have been somewhat more consistent and programmable.
I’m aware that it’s not the actual cleartext password.
From a security perspective should even salted and hashed passwords should stay behind the API or might there be a need for something on the other side of the API to access that field?
On Mailman-Users, Mark Sapiro writes:
> 3) You can set Mailman's character set for English to utf-8 by putting
> add_language('en', 'English (USA)', 'utf-8')
> in mm_cfg.py (and restarting Mailman). The downside of this is the
> bodies of Mailman generated messages including plain digests will be
> base64 encoded and will not be readable by non-MIME aware MUAs.
Does Mailman 3/Python 3 have this limitation?
(One of my MUAs is grep .... :-)
The REST API is returning etags as slashed quoted.
Just wondering if this is intentional, does not seem consistent with the behaviour of the other fields returned from the API.
The user endpoint supports PUT and PATCH methods.
PATCH does a partial update of the user’s configuration
PUT does a full update of the user’s configuration
It seems that for user, the field that can be modified between these two methods are display_name and cleartext_password
What is the difference exactly between partial and full update?
Are the two fields required in one case and optional in the other?
Hello friends of Mailman, and Happy New Year!
You can roll that stone
To the top of the hill
Drag your ball and chain behind you
Once again, it's time for the traditional "avoid the copyright year bump"
release. I'm happy to announce the fifth beta release of Mailman 3.0 core,
code named "Carve Away The Stone".
We're really quite close now, but this release is a little different. Those
of you who follow the proceedings on the mailman-developers mailing list will
note that I have ported the core engine to Python 3.4. While it is my intent
to release Mailman 3.0 core[*] final as a Python 3 application, some of the
details are still be hashed out on the mailing list, and in the code base.
For this reason, I am releasing two "flavors" of 3.0b5:
* "A" release, which remains on Python 2.7
* "B" release, which is only compatible with Python 3.4
The A and B releases are functionally equivalent. There may be different bugs
in them, but they both implement the exact same feature set, with the only
difference being the version of Python they are compatible with. Some time
early in 2015, I will be merging the Python 3 branch back into trunk, and
dropping Python 2 support.
I would encourage you to download the "B" release and try it out. If you do
try both, please submit bugs for any functional differences you encounter.
You can download GNU Mailman 3.0b5 core (both "A" and "B" releases) from the
The documentation is available online at:
Mailman 3.0 is released under the terms of the GNU General Public License
version 3 or later.
Detailed changes in 3.0b5 are available here:
Bugs can be reported here:
Special thanks go to Abhilash Raj and Aurélien Bompard, who implemented the
conversion of the ORM layer from Storm to SQLAlchemy and Alembic. Thanks also
to Kurt Griffiths for his excellent Falcon Framework package, which now
replaces restish as our WSGI-compatible REST layer. Both of these changes
were critical in allowing me to port the core to Python 3.
Enjoy, and Happy New Year.
[*] Postorious and HyperKitty will port to Python 3 on their own time
schedule, and may remain Python 2 applications for the final release of the
GNU Mailman Suite. mailman.client, the standalone REST client will be a
bilingual library, supporting both Python 2 and Python 3.
On Jan 07, 2015, at 11:42 PM, Paul Wise wrote:
>What about just a backport of Python 3.4 (and any future mailman3 package)?
For sure, Python 3.4 should be in backports, IMHO.