Mailman 3 January 2015 - Mailman-Developers

Fwd: Your confirmation is required to leave the Mailman-Developers mailing list
by Andrew Stuart 14 Jan '15

14 Jan '15

errr…. is this someone saying they would prefer I wasn’t on this list? I’d rather hear directly from someone if you feel that way. Begin forwarded message: From: mailman-developers-confirm+e1a7bed1fbf00db07dc7590dcbdba1e364ecc240(a)python.org To: andrew.stuart(a)supercoders.com.au Subject: Your confirmation is required to leave the Mailman-Developers mailing list Reply-To: mailman-developers-confirm+e1a7bed1fbf00db07dc7590dcbdba1e364ecc240(a)python.org Date: 12 January 2015 1:23:31 pm AEDT Mailing list removal confirmation notice for mailing list Mailman-Developers We have received a request from 68.196.224.128 for the removal of your email address, "andrew.stuart(a)supercoders.com.au" from the mailman-developers(a)python.org mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: https://mail.python.org/mailman/confirm/mailman-developers/e1a7bed1fbf00db0… Or include the following line -- and only the following line -- in a message to mailman-developers-request(a)python.org: confirm e1a7bed1fbf00db07dc7590dcbdba1e364ecc240 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be removed from this list, please simply disregard this message. If you think you are being maliciously removed from the list, or have any other questions, send them to mailman-developers-owner(a)python.org.

5 5

MM 3: Virtual Environment Required?
by Tom Browder 13 Jan '15

13 Jan '15

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. Thanks. -Tom

1 0

REST API returns are plain text for errors, JSON or nothing for successful
by Andrew Stuart 12 Jan '15

12 Jan '15

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. thanks

3 7

REST API returning value of password field in user record
by Andrew Stuart 10 Jan '15

10 Jan '15

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? thanks

3 3

English in UTF-8 [was: Does mailman 2.1.18 support hebrew language ?]
by Stephen J. Turnbull 10 Jan '15

10 Jan '15

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

2 2

REST API returning etags as slashed quoted
by Andrew Stuart 10 Jan '15

10 Jan '15

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. i.e. "http_etag": "\"d6d174c76c5fbb5f8a69b648ecd3b27b53a5d27e\”", thanks

2 1

REST API Difference between PUT and PATCH?
by Andrew Stuart 10 Jan '15

10 Jan '15

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? thanks

2 1

Postorius merge proposals: translatability & accuracy in templates
by Sumana Harihareswara 09 Jan '15

09 Jan '15

I've proposed two new branches for merge into Postorius: * https://code.launchpad.net/~sumanah/postorius/bug-1157947/+merge/245979 fixes bug # 1157947 by finding all user-visible occurrences of hard-coded English strings in templates and templatizing them for translatability. * https://code.launchpad.net/~sumanah/postorius/metrics-template/+merge/245965 fixes bug #1409033 by correcting the messages in a template associated with three metrics. I'd welcome any reviews. Thanks! (And I also see that Aurélien and others have a few outstanding merge proposals at https://code.launchpad.net/postorius/+activereviews , in case you want to work FIFO.) -- Sumana Harihareswara http://brainwane.net

1 0

Dark Mail
by Barry Warsaw 08 Jan '15

08 Jan '15

Something interesting to keep an eye on, especially to see if it might relate to encrypted mailing lists. http://arstechnica.com/security/2015/01/lavabit-founder-wants-to-make-dark-… Cheers, -Barry

1 0

RELEASED: GNU Mailman (core) 3.0b5
by Barry Warsaw 08 Jan '15

08 Jan '15

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 Python Cheeseshop: https://pypi.python.org/pypi/mailman/3.0.0b5 The documentation is available online at: http://pythonhosted.org/mailman 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: http://tinyurl.com/p9fpgrh Bugs can be reported here: https://bugs.launchpad.net/mailman 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. -Barry [*] 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.

6 10