Mailman 3 January 2016 - Mailman-coders

[Bug 576675] [NEW] Content filtering fails to collapse alternatives.
by Mark Sapiro 09 Jun '17

09 Jun '17

Public bug reported: Collapsing multipart/alternative parts to just the first alternative only works if the message itself is multipart/alternative, or the multipart/alternative part is at the first sub-level. For example, given this structure: multipart/mixed | multipart/related | | multipart/alternative | | | text/plain | | | text/html | | image/jpeg | application/msword The multipart/alternative part will not be collapsed. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- Content filtering fails to collapse alternatives. https://bugs.launchpad.net/bugs/576675 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

3 7

[Bug 978351] [NEW] Content Filtering *_filename_extension matches are case sensitive.
by Mark Sapiro 09 Jun '17

09 Jun '17

Public bug reported: If the case of the filename extension in the message doesn't agree with that in *_filename_extension, they won't match. Matching should be case insensitive. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Affects: mailman/2.1 Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Fix Released ** Affects: mailman/3.0 Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Tags: mailman3 ** Also affects: mailman/3.0 Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Fix Released ** Also affects: mailman/2.1 Importance: Undecided Status: New ** Changed in: mailman/3.0 Status: Fix Released => In Progress ** Changed in: mailman/3.0 Milestone: mailman-2.1 => 3.0.0b2 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/978351 Title: Content Filtering *_filename_extension matches are case sensitive. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/978351/+subscriptions

3 5

[Bug 757062] [NEW] Content filtering can remove the headers from a message/rfc822 part.
by Mark Sapiro 09 Jun '17

09 Jun '17

Public bug reported: If Content filtering accepts both message/rfc822 and multipart/alternative MIME parts, and a message/rfc822 part contains a message whose content type is multipart/alternative and collapse_alternatives is Yes, the headers of the message in the message/rfc822 part will be lost. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress ** 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/757062 Title: Content filtering can remove the headers from a message/rfc822 part.

3 12

[Bug 1525954] [NEW] mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters
by sphakka 02 Jun '17

02 Jun '17

Public bug reported: Trailing blanks on option "subject_prefix" are removed on subject lines with non-ASCII characters. F.i., with options preferred_language = "Français" subject_prefix = "[prefix] " (irrespective of encode_ascii_prefixes) sending this (via Seamonkey Mail, LANG=en_US.UTF-8): Subject: "[prefix] c'est du français" results in reception of: Subject: "[prefix]c'est du français" ** 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/1525954 Title: mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1525954/+subscriptions

3 8

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

29 Dec '16

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 05 Sep '16

05 Sep '16

*** 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 26 May '16

26 May '16

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 22 Apr '16

22 Apr '16

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 01 Apr '16

01 Apr '16

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 29 Feb '16

29 Feb '16

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

Mailman-coders January 2016