Mailman 3 February 2017 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett Nov. 7, 2022

Nov. 7, 2022

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

Discourse Integration
by Vaibhav Lohani Feb. 22, 2017

Feb. 22, 2017

Hello All, There was a mention of integrating mailman 3 with discourse some times back. I am interested in working on it. Is someone else interested in it or already working on it ? Regards, Vaibhav Lohani

1 0

What characters should be allowed in listnames
by Mark Sapiro Feb. 19, 2017

Feb. 19, 2017

I have just files <https://gitlab.com/mailman/mailman/issues/311> which is about Mailman core allowing list's to be created with a slash '/' in the name. Core validates listnames by ensuring the fqdn_listname is a valid email address. This is too liberal. RFC 5321 allows many characters in the local part of a list name. We don't allow quite all of them, but we allow this set [-0-9a-z!#$%&'*+./=?@_`{}~]. Since list names form parts of a URI, both in Postorius/HyperKitty and in the Core's REST API, it is clear that characters that will cause problems there should not be allowed. These include [#%&/?] and maybe others. Additionally, I don't think we want @ in an email address local part and + and = might cause problems with VERP which whittles it down to [-0-9a-z!$'*._`{}~], but I'm thinking of being even more conservative and going with just [-0-9a-z._]. I don't intend to change the email address validation except maybe to remove @, but the code is such that an address with multiple @ won't validate anyway. I'd like feedback on this. What are your thoughts on what characters should be allowed in list names? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 7

Re: [Mailman-Developers] Google Summer of Code
by Mark Sapiro Feb. 11, 2017

Feb. 11, 2017

On 02/11/2017 12:54 AM, Sukeesh V wrote: > > When I tried to run postorius django server. I got this error ( Screenshot > attached ). I am running on Arch Linux. Postorius can't connect to Mailman core. Mailman core must be running and the port defined in the [webservice] section of var/etc/mailman.cfg must match that in the definition of MAILMAN_REST_API_URL in whatever Postorius settings file you're using. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Google Summer of Code
by Sukeesh V Feb. 11, 2017

Feb. 11, 2017

Hi, Myself Sukeesh, an undergraduate student. I am interested in contributing to mailman. I have setup the development enviroment as mentioned here <https://wiki.list.org/DEV/SetupDevEnvironment>. When I tried to run postorius django server. I got this error ( Screenshot attached ). I am running on Arch Linux. Can someone please help? Thanks, Sukeesh

1 0

Fwd: Mailman | The unsubscribe process using the -leave address does not work because of an `assert` in the code (#310)
by Mark Sapiro Feb. 9, 2017

Feb. 9, 2017

@abompard I don't know what's going here. I received the notice below from GitLab. I tried to go there to comment that this looks like a duplicate or at least very similar to <https://gitlab.com/mailman/mailman/issues/294> which was fixed about 3 weeks ago, but GitLab gives me a 404 and says there is no issue #310. -------- Forwarded Message -------- Subject: Mailman | The unsubscribe process using the -leave address does not work because of an `assert` in the code (#310) Date: Thu, 09 Feb 2017 10:31:52 +0000 From: Aurélien Bompard <gitlab(a)mg.gitlab.com> Reply-To: mailman / Mailman <incoming+36519312af637e6be0deecee3e4f348b(a)gitlab.com> To: mark(a)msapiro.net GitLab Here's the situation that I have confirmed on my servers: * a members sends an email to the |-leave| address to unsubscribe * they recieve a confirmation email * they reply to this email- * |SubscriptionManager.confirm()| get called, the |UnSubscriptionWorkflow| gets restored and run, the goodbye email gets sent to the user. * at the end of the |UnSubscriptionWorkflow| in |._step_do_unsubscription()|, the |.member| attribute gets set to None * the |.confirm()| command returns |workflow.token|, |workflow.token_owner|, and |workflow.member| to the caller * on line 56, |commands.eml_confirm.Confirm| has an |assert member is not None|, which causes an AssertionError. As a result, the database transaction is rollbacked and the unsubscription is forgotten. I suspect this |assert| comes from the time where the -confirm command was only used for subscription confirmations, not unsubscription confirmation. Removing it solves the problem. I think this is important and simple enough to fix it for 3.1. — Reply to this email directly or view it on GitLab <https://gitlab.com/mailman/mailman/issues/310>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 3

Development Enviromnent setup
by Stephen J. Turnbull Feb. 2, 2017

Feb. 2, 2017

Diptanshu Jamgade writes: > I did `mailman info -v`. This returned me with this (error)[ > http://pastebin.com/wLzDQwAu], Kindly help. In the future, when you don't have any idea what your problem is, please report as a bug at GitLab (right now GitLab is down I hear?), or attach the trace to your mail rather than using pastebin, so that it is archived and searchable. No action needed this time. pastebin is an excellent service for on-the-fly discussions, such as draft patches, but by design it is not archival. Your report is wasted for others searching for a solution if the traceback goes away, and probably isn't very searchable at pastebin even while it's stored there. Thanks in advance! Steve

1 0

Re: [Mailman-Developers] Development Enviromnent setup
by Barry Warsaw Feb. 2, 2017

Feb. 2, 2017

On Feb 01, 2017, at 11:57 AM, Diptanshu Jamgade wrote: >I have clonned the mailman gitlab repo(forked version) and created a >python3 virtualenv using `virtualenv p- python3 <virtualenv dir>`. Then I >activated the virtualenv and did `python3 setup.py develop`. On completion >I did `mailman info -v`. This returned me with this (error)[ >http://pastebin.com/wLzDQwAu], Kindly help. That makes me think that your Python installation is broken. Can you tell us more about what OS you're on, what version of Python you're using, and how Python was built/installed on it? FWIW, I tried this on Ubuntu 17.04 (devel) and it works fine. I build my venv a little differently, but that shouldn't matter: $ python3 -m venv /tmp/mm3 $ source /tmp/mm3/bin/activate $ python setup.py develop $ mailman info -v <expected output> I'll also mention that very often I don't create a separate venv, but just use the ones that tox builds, since I almost always have them around by running the test suite. If you want to build those without running the tests, you can do something like this: $ tox -e py35-nocov --notest -r $ .tox/py35-nocov/bin/mailman info -v You don't need to activate the venv to use it. All that said, if you can't import _sqlite3, then your Python installation is messed up. That's a stdlib module so it should always be around. Cheers, -Barry

2 1

Re: [Mailman-Developers] Development Enviromnent setup
by Mark Sapiro Feb. 1, 2017

Feb. 1, 2017

On 02/01/2017 03:57 AM, Diptanshu Jamgade wrote: > Hello, > I have clonned the mailman gitlab repo(forked version) and created a > python3 virtualenv using `virtualenv p- python3 <virtualenv dir>`. Then I > activated the virtualenv and did `python3 setup.py develop`. On completion > I did `mailman info -v`. This returned me with this (error)[ > http://pastebin.com/wLzDQwAu], Kindly help. > With your Python3 venv active, do pip install pysqlite -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Serious issue with Mailman MR 238, PEP 475
by Mark Sapiro Feb. 1, 2017

Feb. 1, 2017

It appears that the subject fix has the following nasty effect, at least with Python 3.4 > Jan 29 00:00:13 2017 (7099) Master watcher caught SIGHUP. Re-opening log files. > Jan 29 00:00:13 2017 (8568) in runner caught SIGHUP. Reopening logs. > Jan 29 00:00:13 2017 (8566) pipeline runner caught SIGHUP. Reopening logs. > Jan 29 00:00:13 2017 (8568) in runner exiting. > Jan 29 00:00:13 2017 (8566) pipeline runner exiting. > Jan 29 00:00:13 2017 (8569) retry runner caught SIGHUP. Reopening logs. > Jan 29 00:00:13 2017 (8569) retry runner exiting. ... I.e. when logrotate SIGHUPs the master to reopen logs, all the runners except for 'rest' exit. Ordinarily, I'd report this on GitLab, but they are having problems of their own right now. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 3