Mailman 3 January 2016 - Mailman-coders

[Bug 1539384] [NEW] Non-blocking DMARC mitigations should also be done for p=none
by Jakob Bohm Dec. 29, 2016

Dec. 29, 2016

Public bug reported: If you read the DMARC informational RFC (no longer just a draft), you will see that there are 3 possible policies a mail domain (of a poster) can set p=reject All recipients should reject/drop mails with From: ...<at ourdomain> that have neither DKIM not SPF pass for our ourdomain. Send automatic reports of this to our postmaster at the specified rua address. p=quarantine All recipient spam filters should penalize ditto. Send the same automatic reports. p=none Recipients should act as if this policy was not there, but send the automatic reports so we can decide if our policy needs fine tuning before switching to a tougher p value. Currently Mailman 2.1.20+ has code that applies reasonable adjustments to avoid failures with posters from p=reject domains (such as Yahoo). Mailman 2.1.20+ also has an option to do the same for p=quarantine. But when a domain is set to p=none because the postmaster is trying to figure out what will break if he/she/they turn on quarantine, Mailman will continue sending mail in a way which causes all the backscatter reports from everybody except the list owner. As a postmaster I find this very annoying as it makes it hard to find actual problems in the flurry of backscatter noise from making even a few posts to a single Mailman list. Especially annoying is reports that some servers received mails with failed DKIM from a 4th party IP, as it is impossible to tell if those 4th parties were forwarding mails that were broken by Mailman munging the Subject header or were handling mails of some other kind needing a different correction. I would therefore suggest the following change to the 2.1 branch (since 3.x is still not in a usable state): * If dmarc_moderation_action is set to a value other than Reject or Discard, the specified mitigation should be applied to domains with any valid DMARC policy, not just reject. The effect of this would be: + List admins need to do nothing extra, since this works with the existing Mailman settings. + Domains that use p=none with a user posting to a list with action other than Reject/Discard will see the true effects that setting p=reject would have, and their users will see any change in the Mailing list behavior and be able to complain to the local postmaster before the domain goes to p=reject. Which is exactly the intended purpose of p=none. + Domains that use p=none with a user posting to a list with action set to Reject/Discard will receive a flurry of error reports reflecting how badly things will break if they go to p=reject, but the users will not loose their ability to post (because the reject/discard action is not applied to domains with p=none). Again this is consistent with the intended purpose of p=none. + Domains that use p=quarantine with a user posting to a list that has not set dmarc_quarantine_moderation_action will see the same effects as domains that use p=none (see above). + Domains that use p=quarantine with a user posting to a list that has set dmarc_quarantine_moderation_action will see the same behavior as for the current 2.1.20 code. + Domains that use p=reject will see the same behavior as for the current 2.1.20 code. ** Affects: mailman Importance: Undecided Status: New ** Tags: dmarc -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539384 Title: Non-blocking DMARC mitigations should also be done for p=none To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions

5 14

[Bug 775294] [NEW] Set lifetime for input forms
by Tokio Kikuchi Sept. 5, 2016

Sept. 5, 2016

*** This bug is a security vulnerability *** Private security bug reported: We may have to set lifetime for input forms because of recent activities on cross-site request forgery (CSRF). The form lifetime is successfully deployed in frameworks like web.py or plone etc. Proposed branch lp:~tkikuchi/mailman/form-lifetime implement lifetime in admin, admindb, options and edithtml interfaces. Other forms like create and rmlist have confirmation by password thus are safe regarding CSRF. The form generation time is set by a hidden parameter whose value is calculated following the mailman cookie algorithm. The default lifetime is set 1 hour in Default.py thus configurable by a site administrator. If a password is set in request, authorization cookie is discarded so the password authentication is forced. Wget tricks to manage list in FAQ can be used as they are now. ** Affects: mailman Importance: Undecided Status: New ** Branch linked: lp:~tkikuchi/mailman/form-lifetime -- You received this bug notification because you are a member of Mailman Coders, which is a direct subscriber. https://bugs.launchpad.net/bugs/775294 Title: Set lifetime for input forms

2 5

[Bug 1445764] [NEW] "The executable /usr/bin/python3.4 does not exist" error when Installling Mailman 3 on Centos 7
by Danil Smirnov May 26, 2016

May 26, 2016

Public bug reported: Short summary: when installing Mailman 3 onto new Centos 7 box using manual at page http://mailman-bundler.readthedocs.org/en/latest/ after step (venv)[root@host mailman-bundler]# pip install zc.buildout (venv)[root@host mailman-bundler]# buildout getting the error: --- Installing mailman. The executable /usr/bin/python3.4 (from --python=/usr/bin/python3.4) does not exist /tmp/tmpePyrQ3/run: line 2: /usr/local/src/mailman-bundler/venv-3.4/bin/pip: No such file or directory While: Installing mailman. --- Now in details: Fresh new CentOS Linux release 7.1.1503 (Core) installed as kvm guest. System python package installed: python-2.7.5-16.el7.x86_64 Python 3.4.3 was installed by commands: [root@host ~]# cd /usr/local/src [root@host src]# curl -O https://www.python.org/ftp/python/3.4.3/Python-3.4.3.tgz [root@host src]# tar -xvzf Python-3.4.3.tgz [root@host src]# cd /usr/local/src/Python-3.4.3 [root@host Python-3.4.3]# ./configure --enable-shared --prefix=/usr/local LDFLAGS="-Wl,-rpath /usr/local/lib" [root@host Python-3.4.3]# make [root@host Python-3.4.3]# make altinstall Virtualenv was installed from package python-virtualenv.noarch 0:1.10.1-2.el7 with dependant python-devel.x86_64 0:2.7.5-16.el7 Then everything was don according http://mailman-bundler.readthedocs.org/en/latest/ until the error mentioned above occurred. When I did (venv)[root@host mailman-bundler]# ln -s /usr/local/bin/python3.4 /usr/bin/python3.4 I've got another error: --- (venv)[root@host mailman-bundler]# buildout Develop: '/usr/local/src/mailman-bundler/.' warning: no files found matching '*.in' under directory 'mailman_bundler' warning: no files found matching '*.in' under directory 'deployment' warning: no files found matching 'deployment/mailman-web.logrotate.conf' Updating mailman-web. Updating main. Installing mailman. Running virtualenv with interpreter /usr/bin/python3.4 Using base prefix '/usr/local' New python executable in /usr/local/src/mailman-bundler/venv-3.4/bin/python3.4 Also creating executable in /usr/local/src/mailman-bundler/venv-3.4/bin/python Failed to import the site module Traceback (most recent call last): File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/site.py", line 67, in <module> import os File "/usr/local/src/mailman-bundler/venv-3.4/lib/python3.4/os.py", line 616, in <module> from _collections_abc import MutableMapping ImportError: No module named '_collections_abc' ERROR: The executable /usr/local/src/mailman-bundler/venv-3.4/bin/python3.4 is not functioning ERROR: It thinks sys.prefix is '/usr/local/src/mailman-bundler' (should be '/usr/local/src/mailman-bundler/venv-3.4') ERROR: virtualenv is not compatible with this system or executable /tmp/tmpTl6JgC/run: line 2: /usr/local/src/mailman-bundler/venv-3.4/bin/pip: No such file or directory While: Installing mailman. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1946, in main getattr(buildout, command)(args) File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 626, in install installed_files = self[part]._call(recipe.install) File "/usr/local/src/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1370, in _call return f() File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 56, in install self.execute() File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 69, in execute run_commands(cmds, self.shell) File "/usr/local/src/mailman-bundler/eggs/collective.recipe.cmd-0.10-py2.7.egg/collective/recipe/cmd/__init__.py", line 39, in run_commands check_call('%s %s' % (shell, tmpfile), shell=True) File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command 'sh /tmp/tmpTl6JgC/run' returned non-zero exit status 127 --- ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1445764 Title: "The executable /usr/bin/python3.4 does not exist" error when Installling Mailman 3 on Centos 7 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1445764/+subscriptions

6 24

[Bug 1457271] [NEW] HTTP 500 error when saving changes to Message Acceptance settings
by Josh Farwell April 22, 2016

April 22, 2016

Public bug reported: Hello, I installed Mailman 3 and Postorius on CentOS 7, via the packages available at this repo: https://repos.fedorapeople.org/repos/abompard/hyperkitty/el-7/x86_64/ I am using the default Postorius configuration. I am running Postorius using the provided development Django project from bzr. I have configured a domain that isn't real and a test list. Mailman has access to an outgoing MTA but the MTA can't send mail back via LMTP, at least at the moment. I encountered an error when I attempted to change the test list's settings for Message Acceptance. When I try to save my change in settings, for any setting on that page, I get an error. I was able to successfully change settings on that page (setting default_member_action to "accept", specifically) by using the Python REST client. I directly changed the value and ran .save() and everything looked correct and there were no errors. This is the error in the Postorius log: [20/May/2015 19:59:35] "POST /postorius/lists/testlist.mail.local/settings/message_acceptance HTTP/1.1" 500 78853 This is the output from mailman.log: May 20 20:59:35 2015 (12584) 127.0.0.1 - - "PATCH /3.0/lists/testlist(a)mail.local/config HTTP/1.1" 400 2 Here is the trace output from the error: ******* Environment: Request Method: POST Request URL: http://127.0.0.1:8000/postorius/lists/testlist.mail.local/settings/message_… Django Version: 1.6.11 Python Version: 2.7.5 Installed Applications: ('django.contrib.auth', 'django.contrib.messages', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.staticfiles', 'postorius', 'django_browserid') Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware') Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 112. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/postorius/auth/decorators.py" in wrapper 58. return fn(*args, **kwargs) File "/usr/lib/python2.7/site-packages/postorius/views/list.py" in list_settings 787. except HTTPError as e: Exception Type: UnboundLocalError at /postorius/lists/testlist.mail.local/settings/message_acceptance Exception Value: local variable 'HTTPError' referenced before assignment ********* Let me know what other information you need, or how I can help diagnose this issue. ** Affects: postorius Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1457271 Title: HTTP 500 error when saving changes to Message Acceptance settings To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1457271/+subscriptions

2 3

[Bug 1104498] [NEW] Member contact requests
by Kẏra April 1, 2016

April 1, 2016

Public bug reported: When configured to hide email addresses. a mailman user should be able to contact someone else by using a request contact form a profile page representing a user. This form would email the recipient of the request a short message explaining who is trying to get in contact, and the email address of the user requesting contact. ** Affects: mailman Importance: Undecided Status: New ** Tags: wishlist -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1104498 Title: Member contact requests To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1104498/+subscriptions

6 6

[Bug 1450469] [NEW] install step using buildout fails with os.path.walk error
by Billy Glynn March 1, 2016

March 1, 2016

Public bug reported: (venv)[root@lists mailman-bundler-3.0.0]# buildout Creating directory '/usr/local/src/mailman-bundler-3.0.0/bin'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/parts'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/eggs'. Creating directory '/usr/local/src/mailman-bundler-3.0.0/develop-eggs'. Develop: '/usr/local/src/mailman-bundler-3.0.0/.' warning: no files found matching '*.in' under directory 'mailman_bundler' warning: no files found matching '*.in' under directory 'deployment' warning: no files found matching 'deployment/mailman-web.logrotate.conf' Getting distribution for 'djangorecipe'. Got djangorecipe 1.11. Getting distribution for 'Django'. warning: no previously-included files matching '__pycache__' found under directory '*' warning: no previously-included files matching '*.py[co]' found under directory '*' Got Django 1.8. Getting distribution for 'zc.recipe.egg>=2.0.0a3'. Got zc.recipe.egg 2.0.1. Getting distribution for 'collective.recipe.cmd'. warning: no previously-included files matching '*.pyc' found anywhere in distribution Got collective.recipe.cmd 0.10. Getting distribution for 'z3c.recipe.filetemplate'. Got z3c.recipe.filetemplate 2.2.0. While: Installing. Getting section templates. Initializing section templates. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1946, in main getattr(buildout, command)(args) File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 510, in install [self[part]['recipe'] for part in install_parts] File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 510, in <listcomp> [self[part]['recipe'] for part in install_parts] File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1098, in __getitem__ options._initialize() File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1202, in _initialize self.initialize() File "/usr/local/src/mailman-bundler-3.0.0/venv/lib/python3.4/site-packages/zc/buildout/buildout.py", line 1211, in initialize self.recipe = recipe_class(buildout, name, self) File "/usr/local/src/mailman-bundler-3.0.0/eggs/z3c.recipe.filetemplate-2.2.0-py3.4.egg/z3c/recipe/filetemplate/__init__.py", line 145, in __init__ os.path.walk( AttributeError: 'module' object has no attribute 'walk' ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1450469 Title: install step using buildout fails with os.path.walk error To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1450469/+subscriptions

3 3

[Bug 1517446] [NEW] Please add multipart/signed to DEFAULT_PASS_MIME_TYPES
by carloslp Feb. 28, 2016

Feb. 28, 2016

Public bug reported: Mailman tarballs contain a Defaults.py file with this configuration: DEFAULT_PASS_MIME_TYPES = ['multipart/mixed','multipart/alternative','text/plain'] NOTE: I don't know how this file is generated, I found it on the tarballs but not on the repository So, when someone enables filtering on a mailing list by mime-type, the default is to filter all emails not matching any of those 3 mime-types. This list of default mime types allowed misses to include "multipart/signed". Therefore, this is unfortunately filtering any "multipart/signed" emails. "multipart/signed" is defined on RFC 3156 <https://tools.ietf.org/html/rfc3156> and is the recommended way of signing mails with GPG. See http://wiki.gnupg.org/SignatureHandling The proposed change is to modify that default configuration to: DEFAULT_PASS_MIME_TYPES = ['multipart/mixed', 'multipart/alternative', 'multipart/signed', 'text/plain', ] This default causes trouble to people that signs their mails with GPG. I already had problems due to this default on the Alioth Debian mailing lists and on the WebKit mailing lists because the admin enabled filtering by mime-type and didn't changed the default. Please, change this default by adding at least 'multipart/signed' to the list of types allowed. ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1517446 Title: Please add multipart/signed to DEFAULT_PASS_MIME_TYPES To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1517446/+subscriptions

3 5

[Bug 1279980] [NEW] Some forms in list admin interfaces use absolute links in form action
by Vitor Choi Feitosa Feb. 15, 2016

Feb. 15, 2016

Public bug reported: Some forms in admin interface, like the one on list member management -- https://HOSTNAME/mailman/admin/somelist/members -- , use absolute links as the form action url. POST data then gets transmitted in the clear because that absolute link points to http instead of https address. I'm running mailman 2.1.14 ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1279980 Title: Some forms in list admin interfaces use absolute links in form action To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1279980/+subscriptions

3 9

[Merge] lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client
by Rajeev S Feb. 3, 2016

Feb. 3, 2016

Rajeev S has proposed merging lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli/+merge/23… GSoC project "Mailman CLI" The branch contains the Mailman CLI shell as well as the command line tools built as a part of the GSoC 2014, Under the mentors Stephen J Turnbull, Abhilash Raj and Barry Warsaw. -- https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli/+merge/23… Your team Mailman Coders is requested to review the proposed merge of lp:~rajeevs1992/mailman.client/mailmancli into lp:mailman.client.

1 3

[Bug 1491187] [NEW] mailmanctl check_privs should check effective uid, not real uid
by Mark Sapiro Feb. 3, 2016

Feb. 3, 2016

Public bug reported: Situations can arise where mailmanctl is running with an effective uid of 'mailman' and a real uid of 'root'. Such a situation is if logrotate does 'su mailman mailman' to rotate mailman's logs and then invokes 'mailmanctl reopen' in a postrotate script. In this case, mailmanctl gets its real uid which is 'root' and then tries to do os.setgroups, but the effective uid is 'mailman' which doesn't have permission to set groups. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1491187 Title: mailmanctl check_privs should check effective uid, not real uid To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1491187/+subscriptions

2 2