Mailman 3 December 2017 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 08 Nov '22

08 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

3.1.x REST API enhancements around preferred email address
by Scott Koranda 09 Mar '18

09 Mar '18

Hello, I am interested in contributing enhancements around preferred address to the REST API for version 3.1.x. To prove out my use case(s) and familiarize myself with the code I have made changes already. Here are some example curl command line invocations and output to illustrate: 1) Create an address for an existing user and mark that address as the user's preferred address: curl -u restadmin:restpass \ -X POST \ -d email=skoranda(a)example.nil \ -d preferred=1 \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addres… This returns a '201 Created'. 2) Return the preferred address, if set, for a user: curl -u restadmin:restpass \ -X GET \ http://mystestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 | python -m json.tool { "created_on": "2017-11-11T22:20:45.950949", "display_name": "Scott Koranda", "http_etag": "\"26bc0d9f21eb145248884aedae4c1ffd00b608d2\"", "is_server_owner": false, "password": "$6$rounds=656000$gWGfwpajfZ7rVn5O$Sl559B2TgtpJWXA2i67G5ukjzkV6iTp4NgP.6FJpMFMUTDdDXULAmwdN8YW92w87EdctgqFqAUkUqS6.EOTCz/", "preferred_address": "skoranda(a)example.nil", "self_link": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "user_id": "e57ecfd0c0c74a319ac958b18882a6d8" } 3) Update/patch a user to set a preferred address: curl -u restadmin:restpass \ -X PATCH \ -d preferred_address=skoranda(a)example.nil \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 This returns a '204 No Content'. 4) Get all addresses for a user with the preferred address (if set) having the attribute 'preferred' set to 'true': curl -u restadmin:restpass \ -X GET \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addres… | python -m json.tool { "entries": [ { "email": "skoranda(a)example.nil", "http_etag": "\"492824d150f9f11e32d530d3cad0f76422bddb48\"", "original_email": "skoranda01(a)example.nil", "preferred": true, "registered_on": "2017-11-13T22:35:17.232180", "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda@example.nil", "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "verified_on": "2017-11-20T16:48:51.738145" }, { "email": "skoranda01(a)example.nil", "http_etag": "\"f0f28c1c6a925a595269d3fe21ef7fc1515d7670\"", "original_email": "skoranda01(a)example.nil", "registered_on": "2017-11-20T16:46:20.941262", "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda01@example.nil", "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "verified_on": "2017-11-20T16:46:20.941595" }, ], "http_etag": "\"89c46bd312c6f1a344e6e6180aed6f11b62e6048\"", "start": 0, "total_size": 2 } Before I submit a pull request I would be grateful for any comments or feedback on the functionality as illustrated above, or any other comments or feedback. I will also begin the "copyright assignment" paperwork as explained at https://wiki.list.org/DEV/Home Thank you for your consideration. Sincerely, Scott Koranda

2 3

Handling additions to REST API in client side
by Abhilash Raj 30 Dec '17

30 Dec '17

Hi All, Core's REST API is versioned and any change that break backwards-compatibility cause the version to bump so that clients can take care of that. However, one question that I have been thinking about recently is how to handle additions to REST API that don't necessarily break the backwards compatibility. For example, Core added `max_message_size` attribute to MailingList's REST endpoint, but it hasn't made into any released version yet. Also, Postorius added max_message_size in `Message Acceptance` settings. The problem here is that the entire PUT/PATCH request is going to fail if the currently running version of Core doesn't have `max_message_size` attribute exposed (Unknown Attribute Error). There is no easy way to check for whether the Core has this attribute as API is versioned at 3.1 for both cases. So, how do we actually handle this and maybe future cases like this? -- thanks, Abhilash Raj

5 10

Postorius 1.1.2 security release
by Abhilash Raj 28 Dec '17

28 Dec '17

Hi Everyone, I am pleased to announce that Postorius 1.1.2 is released and is up on PyPI[1]. This release fixes a security bug that sets the password of a user in Core to their display name. It is recommended that you upgrade to this version. Postorius (Django) and Mailman Core both have different notion of "user" and "password". When a user account in created in Postorius, it creates a user in Core using the REST API. This bug, causes the password of user created in Core to be set to their display name instead. However, as of now, there are no use cases of the user password in Core and it is present only for historical reasons. So, while this bug is a serious one, it wouldn't result in any real-world exploit. Along with the bug-fix, this release includes a new command that resets *all* user passwords in Core to a random value. Again, there are no use cases of these passwords so resetting *all* of them isn't going to cause any inconvenience to users. This command should be run after the upgrade: $ cd mailman-suite/mailman-suite_project/ $ python manage.py reset_passwords Python 2.7 is the only supported Python version for this release. All versions of Django <=1.11 is supported. For more information about GNU Mailman and Postorius, please see our website: http://list.org The source code is available on Gitlab: https://gitlab.com/mailman/ [1]: https://pypi.org/project/postorius -- thanks, Abhilash Raj

1 0

Re: [Mailman-Developers] ARC PR for Mailman 3
by Peter Münster 20 Dec '17

20 Dec '17

On Wed, Dec 13 2017, Gene Shuman wrote: >> foo("01234567890123456789" >> "01234567890123456789") > > Compensating for line lengths this way, just to satisfy a stylistic > requirement, I personally believe would reduce the quality of the > code. Hi, I personally believe that the limitation of the line length would *increase* the quality of the code. (Please, no lines with 500 characters in a text file.) Kind regards, -- Peter

2 1

Re: [Mailman-Developers] Date of Mailman 3 Suite going Python 3 only after Django dropped Python 2
by Simon Hanna 19 Dec '17

19 Dec '17

On 12/15/2017 08:03 PM, Tobias Conradi wrote: > https://www.djangoproject.com/weblog/2017/dec/02/django-20-released/ > > 1) Is there a date for when Mailman Suite will switch to Python 3 only, > so user are not required to install two Python versions? AFAIK there are merge requests for all the parts, the only hold-up is testing to make sure they actualy work. You can search for "Python 3" in the gitlab issue trackers for more information. > 2) Is there a date for a switch to Django 2? Since Django 2 only supports Python3 support for it will most probably be added by merging the Python3 branches. I haven't gone over all the details, but I don't think there are any changes that still require porting...

2 1

Re: [Mailman-Developers] no module named django
by Simon Hanna 19 Dec '17

19 Dec '17

Replying back to the list :-) > #virtualenv = /srv/django/mailman/env > since you managed to install postorius and get it running, you either > installed it systemwide which would work with it commented out, or you > actually created a virtualenv in which case you should know where the > location of that is. (virtualenv is preferred, you only use the system > packages, if they are installes using your package manager and the > application is too. Otherwise you will run into incompatibilties sooner > or later. > > totally do not know about virtualenv, just follow the guide to install > postorius. > when runserver, it can visit by 192.168.1.96, when "ctrl+c", > 192.168.1.96 not work. virtualenv is a python concept, you should be able to find information online about that. It's about how and where you install python dependencies. > > > #socket = /run/uwsgi/mailman.sock > This is the socket that is created for the webserver to connect to. I'm > actually not sure what happens if you don't include that... I doubt > uwsgi would actually start. > > installed uwsgi and it seems running, I run $ uwsgi, there is no error. > but can't find /run/uwsgi/ directory, usually mailman.sock can be at > which directory? > By convention sockets are placed in /run/ you can put them wherever you want. > I tried with docker, here is its guide with 6 steps: > --- > $ mkdir -p /opt/mailman/core > $ mkdir -p /opt/mailman/web > $ git clone https://github.com/maxking/docker-mailman > $ cd docker-mailman > # Change some configuration variables as mentioned above. > $ docker-compose up -d > ---- > But about configuration in step 5, I can't > find /opt/mailman/core/mailman-extra.cfg > and /opt/mailman/web/settings_local.py, and can't find it in any > directory from /home/lists/docker-mailman/. > so do not know what to with it. is it to create these two files? > Yes, you have to manually create them. The idea is that there are default settings and you would override them in additional files. The default settings are found here https://github.com/maxking/docker-mailman/blob/master/web/mailman-web/setti… https://github.com/maxking/docker-mailman/blob/master/core/assets/mailman.c… There are some settings that you have to overwrite, as mentioned in the readme of https://github.com/maxking/docker-mailman You do so, by specifing them in the respective files that you create in /opt/mailman/ on your host machine. You can search for the settings in the original files in the github repo and then use the same syntax in your new files. > OK, maybe it is realistic for me to wait for debian backport. That will definelty mean less work for you, and you will have it running directly on the machine managed by your package manager. This will probably be easier with upgrades as well.

1 0

no module named django
by 孙志勇 18 Dec '17

18 Dec '17

Hi, when I init uwsgi, I find a problem "importerror no module named django". I install postorius following installation in http://postorius.readthedocs.io/en/latest/setup.html, and visit http://192.168.1.96:8001 it workes well after run: $ sudo python manage.py runserver 0.0.0.0:8001. Do not know what is about development in the page: http://postorius.readthedocs.io/en/latest/development.html, so I pass it. Then go to deployment in http://postorius.readthedocs.io/en/latest/deployment.html. I creat file /home/lists/uwsgi.ini and put in it: --- [uwsgi] chdir = /home/lists/postorius/sample_project #virtualenv = /srv/django/mailman/env #socket = /run/uwsgi/mailman.sock wsgi-file = wsgi.py master = true process = 4 threads = 2 vacuum = true plugin = python2 uid = http gid = http --- then run: $ uwsgi --ini /home/lists/uwsgi.ini it gives the error "importerror, no module named django". I think it is the problem of the below 2 line: #virtualenv = /srv/django/mailman/env #socket = /run/uwsgi/mailman.sock but docs do not mention how to set about this 2 line, so I just comment out the 2 line. I also tried with mailman-suite, also have the same problem. can you help with me? will you think to write a installing instruction with command to follow for people totally don't know django in future? Thank you.

2 1

mailman var directory pip3
by 孙志勇 16 Dec '17

16 Dec '17

Hi, I installed mailman3.1.1 using pip3 on debian9.3. Where is the var directory of mailman?Thank you.

3 2

Date of Mailman 3 Suite going Python 3 only after Django dropped Python 2
by Tobias Conradi 16 Dec '17

16 Dec '17

https://www.djangoproject.com/weblog/2017/dec/02/django-20-released/ 1) Is there a date for when Mailman Suite will switch to Python 3 only, so user are not required to install two Python versions? 2) Is there a date for a switch to Django 2? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany https://tobiasconradi.com

1 0

Mailman-Developers December 2017