Mailman 3 March 2016 - Mailman-Developers

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

07 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

Re: [Mailman-Developers] Rosters not using 'ISubscriptionService' Interface.
by Barry Warsaw 31 Mar '16

31 Mar '16

On Apr 01, 2016, at 01:59 AM, Harshit Bansal wrote: >I was looking at the 'rosters.py' and I am unable to understand that >why are rosters not using 'ISubscriptionService' interface instead of >making raw queries for finding members? Is there any reason for doing >so and if no then should it be changed? The easy answer is that rosters (and the IRoster interface) predates ISubscriptionService by quite a bit. The latter was added primarily to support REST APIs for member searchers. The concept of a roster as a query is pretty fundamental, and the idea was also that rosters should be composable. I'm not keen on changing these interfaces. Cheers, -Barry

1 0

Rosters not using 'ISubscriptionService' Interface.
by Harshit Bansal 31 Mar '16

31 Mar '16

Hi, I was looking at the 'rosters.py' and I am unable to understand that why are rosters not using 'ISubscriptionService' interface instead of making raw queries for finding members? Is there any reason for doing so and if no then should it be changed? Thanks, Harshit Bansal.

1 0

Re: [Mailman-Developers] Correcting the display name in the recipient address
by Barry Warsaw 31 Mar '16

31 Mar '16

On Mar 25, 2016, at 05:58 PM, Aditya Divekar wrote: >> A perhaps more convincing example would be an extension to anonymous >> lists with personal reply-to. This could be accomplished by creating >> a mailbox at the list host, which would be associated with the user so >> she can set options for it (eg, which address to forward to), but >> should not have a display name associated with it, and certainly not >> the user-level display name (which in organizational contexts -- >> including Python! -- is likely to be a real name). >> >Actually, the code has already been merged for the above mentioned >automatic fallback on the user display name. So I'm not really sure about >the next step in this issue, and think that Barry would be better qualified >to give an opinion here than me. Two things to keep in mind. This comes into play for messages that Mailman crafts out of whole cloth for notifying the user of something. It won't be used in messages posted to the list. Also, although currently there's no distinction, there *could* be a difference between None and the empty string for display_name. The former could mean no-fallback. Cheers, -Barry

1 0

Re: [Mailman-Developers] mailman
by Christian Schoepplein 31 Mar '16

31 Mar '16

Hi Aditya, On Do, Mär 31, 2016 at 07:17:50 +0530, Aditya Divekar wrote: > I'm sorry for the misdirect. I'm myself a beginner here! Absolutely no problem, every hint is welcome :-). I'm also a beginner with mailman 3 and absolutely no python expert :-(. To be honest it is not easy to understand the full procedure of installation of all needed components for mm3, at least if you like to install not the mailman_bundler package. There are so many sites with documentation and it is not easy to find out what is the right one. A step to step guide to install all components, which also beginners or not python programmers do understand, would be great. Maybe there is some kind of such a guide, but I haven't found it. And if it is not, I'd like to help to create such a guide, but I'd need support from people with mor knowledge of python and all the things which are needed. > This issue on gitlab is probably the same as the one you are facing. > The fix recommended is the installation of falcon 0.3.0.1 or 0.3 > [1]https://gitlab.com/mailman/postorius/issues/122#note_4509503 If I understand it correctly, I already have a newer version of falcon installed: root@mm3:/opt/mailman-bundler# find . -name *falcon* ./venv-3.4/lib/python3.4/site-packages/falcon ./venv-3.4/lib/python3.4/site-packages/falcon-1.0.0rc1-py3.4.egg-info ./venv-3.4/bin/falcon-bench root@mm3:/opt/mailman-bundler# But as said before, I'mno python expert... Ciao and thanks again for your help, Schoepp

5 6

Re: [Mailman-Developers] mailman
by Christian Schoepplein 31 Mar '16

31 Mar '16

Hi, On Do, Mär 31, 2016 at 06:39:14 +0530, Aditya Divekar wrote: >Try removing the /mailman3 part from the URL. i.e. try accessing the URL - >http://192.168.122.147:8000/ Using this address opens the webinterface for hyperkitty and I could browse mailinglist archives, e.g., but what I'd like to do is setup a new domain for the new installation. If I open the settings page directly (http://192.168.122.147:8000/mailman3/settings/) I ge tno error, but after entering a mail and web host and a description and send the formular another error occures :-(. Seems that something is not correctly installed or configured, but what is it? Ciao and tia, Schoepp

2 1

mailman
by Christian Schoepplein 31 Mar '16

31 Mar '16

Hi, I'm getting the following error after a fresh installation of mailman_bundler with mailman 3.0.3 included. Is this a known issue or a bug? How can I resolve it? Ciao and thx, Schoepp ------ Environment: Request Method: GET Request URL: http://192.168.122.147:8000/mailman3/ Django Version: 1.8.11 Python Version: 2.7.9 Installed Applications: ('django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'django.contrib.admin', 'hyperkitty', 'social.apps.django_app.default', 'rest_framework', 'django_gravatar', 'crispy_forms', 'paintstore', 'compressor', 'django_browserid', 'haystack', 'django_extensions', 'postorius') Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'hyperkitty.middleware.TimezoneMiddleware') Traceback: File "/opt/mailman-bundler/eggs/Django-1.8.11-py2.7.egg/django/core/handlers/base.py" in get_response 132. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/views/list.py" in list_index 511. lists = sorted(List.objects.all(only_public=only_public), File "/opt/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/models.py" in all 144. objects = getattr(get_client(), self.resource_name_plural) File "/opt/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanclient/_client.py" in lists 158. response, content = self._connection.call('lists') File "/opt/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanclient/_client.py" in call 109. raise HTTPError(url, response.status, content, response, None) Exception Type: HTTPError at /mailman3/ Exception Value: HTTP Error 500: A server error occurred. Please contact the administrator.

2 1

ANNOUNCE: Mailman Core 3.0.3
by Barry Warsaw 30 Mar '16

30 Mar '16

Hello Mailmandables! I'm happy to announce Mailman Core 3.0.3 which fixes a number of bugs. This also pins the Falcon version in setup.py to < 1.0. https://gitlab.com/mailman/mailman/milestones/4 More information on version compatibility is available here: http://wiki.list.org/Mailman3 As usual, you can download it from PyPI: https://pypi.python.org/pypi/mailman/3.0.3 view the documentation: http://mailman.readthedocs.org/en/release-3.0/ Enjoy, -Barry (on behalf of the Mailman development team) _______________________________________________ Mailman-Developers mailing list Mailman-Developers(a)python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/gmmd-mailman-dev… Security Policy: http://wiki.list.org/x/QIA9

1 0

Big merge landing soon
by Barry Warsaw 29 Mar '16

29 Mar '16

Hello developers! As soon as the latest CI passes, I am going to merge a massive code clean up branch to the core's master branch. This integrates flake8 (pyflakes + pep8) static analysis, with a few local customizations. https://gitlab.com/mailman/mailman/merge_requests/127 One of the most important checks is a customization to enforce our GNU Mailman import style rules, which are codified in the style guide: https://gitlab.com/mailman/mailman/blob/master/src/mailman/docs/STYLEGUIDE.… This branch also updates that style guide. This merge will cause some churn and if you have merge proposals currently in the queue, it's very possible there will be conflicts. To the extent that you can rebase and push updates, that would be appreciated, but I will not require it as I continue to review outstanding merge proposals. I apologize for any disruption, but with GSoC coming, I want to be sure that to the extent possible, CI will early detect simple style guide violations. That way, reviews can focus more on the actual interesting bits rather than the boring bits. This branch also bandaids over the problem with the newest Falcon by pinning that package's version to < 1.0. Issue #20 will address a more long-term fix. I plan on releasing core 3.0.3 very soon which will have this fix backported. There are a few other minor code modernizations, and a local implementation of the idea expressed in this Python bug: http://bugs.python.org/issue26632 It's been quite the eye-opener to see all the little violations that have crept into the code, but everything will be better now <wink>. Cheers, -Barry

1 1

Re: [Mailman-Developers] Interest in "Implement module to process ARC headers" project GSoc
by Stephen J. Turnbull 27 Mar '16

27 Mar '16

nitish salwan writes: > I know that was late but I wanted to take part in GSOC. And now > when the submission deadline is over,can I contribute in this > project through GSOC or separate contribution. You can certainly contribute at any time. About GSoC, if you submitted a proposal, I'm not allowed to say until the official announcements. Regards,

1 0