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.
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
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.
*** 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
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
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
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
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
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
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