Public bug reported:
When a message contains an invalud unicode sequence in its header,
qrunner flat out crashes on that:
May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't decode byte
0xe9 in position 18: invalid continuation byte
May 17 15:32:20 2015 (981) Traceback (most recent call last):
File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 239, in process
i18ndesc = uheader(mlist, mlist.description, 'List-Id', maxlinelen=998)
File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 65, in uheader
return Header(s, charset, maxlinelen, header_name, continuation_ws)
File "/usr/lib/python2.7/email/header.py", line 183, in __init__
self.append(s, charset, errors)
File "/usr/lib/python2.7/email/header.py", line 267, in append
ustr = unicode(s, incodec, errors)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18: invalid
continuation byte
May 17 15:32:20 2015 (981) SHUNTING:
1431869540.389822+156779307d54473d0eb732994bb67eee95733285
A solution for this specific case is to have Mailman/Handlers/CookHeaders.py pass the erorrs='replace' parameter.
I would say that this is actually a bug in python-email, since I think it doesn't make sense to set errors to "strict" rather than something like "replace" when the intention is to parse stuff so free-formed, under-specd
and user-controlled as email. Nonetheless, Mailman already sets errors='replace' in some places so it might aswell add it here.
** 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/1462755
Title:
qrunner crashes on invalid unicode sequence
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1462755/+subscriptions
Public bug reported:
We need a script, documentation, or other procedure to help people
migrate from Mailman 2 to Mailman 3.
** 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/965532
Title:
Need a script to upgrade from MM2 to MM3
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/965532/+subscriptions
Public bug reported:
Mailman 3 is essentially five projects:
Mailman Core
Postorius - The Web UI for Mailman
Mailman Client - The REST API Client
HyperKitty - The Archiver for Mailman
Mailman Bundler - Installer for Mailman Suite including all above projects
URL: https://www.gnu.org/software/mailman/
** Affects: mailman
Importance: Undecided
Status: New
** Affects: ubuntu
Importance: Undecided
Status: New
** Affects: debian
Importance: Unknown
Status: Unknown
** Tags: needs-packaging
** Bug watch added: Debian Bug tracker #799292
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799292
** Also affects: debian via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799292
Importance: Unknown
Status: Unknown
** Also 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/1609516
Title:
[needs-packaging] GNU Mailman v3
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1609516/+subscriptions
Public bug reported:
Setting localhost in postfix_lmtp works against Postfix defaults and
breaks delivery.
Reason: The Postfix lmtp client only uses dns queries by default to
search for hostnames. If the DNS server does not provide an answer for
"localhost" delivery from the lmtp client to mailman fails.
Solution: Provide "127.0.0.1" instead of "localhost". This does not
require DNS and is even faster because it saves DNS lookups.
Example:
hey2(a)mailman.state-of-mind.de
lmtp:[localhost.localdomain]:8024
** Affects: mailman
Importance: Undecided
Status: New
** Tags: 3.0 mailman
--
setting localhost in postfix_lmtp breaks delivery
https://bugs.launchpad.net/bugs/544477
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
Public bug reported:
We have seen (very rarely) cases where a recipient address has a quoted
local part such as "jr."@example.org. This results in a VERPed sender
address like list-bounces+"jr."=example.org(a)example.com which is
syntactically invalid. The VERPed sender should be "list-
bounces+jr.=example.org"@example.com in this case. I.e., the entire
VERPed sender local part should be quoted, not just the recipient local
part.
This also requires BounceRunner to recognize this and restore the
original local part.
** 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/1731604
Title:
VERP fails if the recipient address local part is quoted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1731604/+subscriptions
Public bug reported:
MM3 still uses a lot of X- headers, but some of the X- prefixes can be
removed. In general, we can just claim the Mailman- prefix for Mailman
specific headers. Candidates include:
Mailman-Rule-Hits
Mailman-Rule-Misses
Mailman-Version
Mailman-Approved-At
Mailman-LMTP-MailFrom (i.e. X-MailFrom)
Mailman-Copy (or remove this header)
Mailman-Content-Filter (from X-Content-Filtered-By)
Also, fix the outdated comments about add-dup-header in
avoid_duplicates.py and verp.py.
Probably also get rid of X-List-Administrivia (and possibly
reduced_list_headers). These seem unnecessary now.
** 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/883193
Title:
Remove the X- prefix from some headers
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/883193/+subscriptions
Public bug reported:
It looks like there is no way for a MM3 plugin to be signaled for a new
posting.
It would be great if core could provide a notification to the plugins
that have subscribed to this event when a new post occurs.
This notification should carry some interesting information, like the
number of recipients and the message size.
This request is also essential for the MM3-Metrics module
(https://launchpad.net/mm3-metrics).
** Affects: mailman
Importance: Undecided
Status: New
** Tags: events mailman3 metrics modules notification plugins post
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1094696
Title:
Event notifications on postings
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1094696/+subscriptions
Public bug reported:
Mailman Core and Postorius have sets of tests, but could use more
extensive test coverage. This bug is meant to be a repeatable bug
suitable for new contributors (e.g. prospective Google Summer of Code
Students). In short: find a piece of Postorius or Mailman Core that
isn't yet tested and write a test (or set of tests) for it.
Contributors wishing to work on Mailman Core should look at START.rst
and DATABASE.rst for more information about setting up tests.
For Postorius, Florian is working on vcrpy test integration, so new
tests can use that format.
Links to documentation and examples much appreciated to update this bug!
** Affects: mailman
Importance: Undecided
Status: New
** Affects: postorius
Importance: Undecided
Status: New
** Tags: beginner-friendly easy mailman3 repeatable test
** Tags added: easy mailman3
** Also affects: mailman
Importance: Undecided
Status: New
** Description changed:
- Postorius has a set of tests, but it could use more extensive coverage.
- This bug is meant to be a repeatable bug suitable for new contributors
- (e.g. prospective Google Summer of Code Students). In short: find a
- piece of postorius that isn't yet tested and write a test (or set of
- tests) for it.
+ Mailman Core and Postorius have sets of tests, but could use more
+ extensive test coverage. This bug is meant to be a repeatable bug
+ suitable for new contributors (e.g. prospective Google Summer of Code
+ Students). In short: find a piece of Postorius or Mailman Core that
+ isn't yet tested and write a test (or set of tests) for it.
- Florian is working on vcrpy test integration, so new tests can use that
- format.
+ Contributors wishing to work on Mailman Core should look at START.rst
+ and DATABASE.rst for more information about setting up tests.
+
+ For Postorius, Florian is working on vcrpy test integration, so new
+ tests can use that format.
+
+ Links to documentation and examples much appreciated to update this bug!
** Tags added: repeatable
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1414352
Title:
Improve code coverage by adding tests
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1414352/+subscriptions
Public bug reported:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are created from scratch.
Thank you.
** Affects: mailman
Importance: Undecided
Status: New
** Affects: mailman (Ubuntu)
Importance: Undecided
Status: New
** Affects: mailman (Debian)
Importance: Undecided
Status: New
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these file get created from scratch and which I describe below for the
Mailman data/aliases table only but the problem is identical for the
Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix need read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group need write access to those files at any time
Currently, the following behavior has been observed.
- When creating a new list on command line, using newlist as follow: '#
- newlist -u virtualhost foobar', the files will be created as follow
+ When creating a new list on command line, using newlist script as
+ follow:
+
+ # newlist -u virtualhost foobar
+
+ the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
- using bin/genaliases
+ using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
- Note that in both case, files were not present. Thus, they were created
+ Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these file get created from scratch and which I describe below for the
Mailman data/aliases table only but the problem is identical for the
Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
- I. Postfix need read access to the aliases.db file
+ I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
- II. Mailman group need write access to those files at any time
+ II. Mailman group needs a write access to those files at any time
Currently, the following behavior has been observed.
When creating a new list on command line, using newlist script as
follow:
- # newlist -u virtualhost foobar
+ # newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these file get created from scratch and which I describe below for the
Mailman data/aliases table only but the problem is identical for the
Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
- Currently, the following behavior has been observed.
+ The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these file get created from scratch and which I describe below for the
Mailman data/aliases table only but the problem is identical for the
Mailman data/virtual-mailman map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
- command to be sure that Mailman group has write permissions.
+ command to be sure that Mailman group has write permissions, at least
+ when the files are create from scratch.
+
+ Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
- these file get created from scratch and which I describe below for the
- Mailman data/aliases table only but the problem is identical for the
- Mailman data/virtual-mailman map.
+ these files are created from scratch.
+
+ Here I describe the current behavior for the Mailman data/aliases table
+ only but the problem is identical for the Mailman data/virtual-mailman
+ map.
In order, the following conditions have to be meet:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are create from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
- In order, the following conditions have to be meet:
+ In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are create from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
- The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because
- the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).
+ The problem here is that with those permissions, creating a list through
+ Mailman interface later on will result in a permissions denied error
+ because the Mailman group, through the wrapper, cannot write (update)
+ the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
- correct permissions on resulting *db file, after running POSTALIAS(1)
+ correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are create from scratch.
Thank you.
** Also affects: mailman (Ubuntu)
Importance: Undecided
Status: New
** Also affects: mailman (Debian)
Importance: Undecided
Status: New
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
- when the files are create from scratch.
+ when the files are created from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
- When creating a new list on command line, using newlist script as
+ When creating a new list on command line, using bin/newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are created from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
- # chmod 0660 data/aliases
+ # chmod 0660 data/aliases.db
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are created from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
group or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
- # chmod 0660 data/aliases.db
+ # chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are created from scratch.
Thank you.
** Description changed:
Dear project leader
At least in version 2.1.23, there is a bug regarding permissions set for
Mailman data/aliases table and Mailman data/virtual-mailman map when
these files are created from scratch.
Here I describe the current behavior for the Mailman data/aliases table
only but the problem is identical for the Mailman data/virtual-mailman
map.
In order, the following conditions have to be met:
- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them
I. Postfix needs a read access to the aliases.db file
We can either set permissions as 0660 and add postfix user to mailman
- group or set the permissions as 0664
+ group (what I've done), or set the permissions as 0664
II. Mailman group needs a write access to those files at any time
The following behavior has been observed:
When creating a new list on command line, using bin/newlist script as
follow:
# newlist -u virtualhost foobar
the files will be created as follow:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
The same thing has been observed when recreating the file from scratch
using bin/genaliases:
-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db
Note that in both cases, files were not present. Thus, they were created
from scratch.
As you can see here, the Mailman data/aliases table is created with the
expected group and permissions but the data/aliases.db file is only
writable by owner. From the POSTALIAS(1) command point of view, that is
the expected behavior: The file is created with the same group and other
read permissions as their source file.
The problem here is that with those permissions, creating a list through
Mailman interface later on will result in a permissions denied error
because the Mailman group, through the wrapper, cannot write (update)
the aliases.db file (no write permissions).
That is really a problem. Of course, one can just pre-create the files
as follow:
# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*
but that seem tedious. What if at some point (for any reason), the files
get recreated from scratch?
So, from my point of view, the MTA/Postfix.py module should always set
correct permissions on resulting *.db file, after running POSTALIAS(1)
command to be sure that Mailman group has write permissions, at least
when the files are created from scratch.
Thank you.
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1696066
Title:
Postfix module - Mailman wrapper - Couldn't write data/aliases.db and
data/virtual-mailman.db files
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1696066/+subscriptions
Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/2.1-add-smtp-timeout into lp:mailman/2.1.
Requested reviews:
Mailman Coders (mailman-coders)
For more details, see:
https://code.launchpad.net/~futatuki/mailman/2.1-add-smtp-timeout/+merge/33…
This add a feature to specify timeout for SMTP response to avoid waiting response forever, to SMTPDirect Handler. To specify timeout, set SMTP_TIMEOUT in mm_cfg.py.
By default, this is disabled(waiting response until respond the MTA).
To test this feature, set mm_cfg.SMTP_TIMEOUT to small value and setup MTA to wait responding (by using greet pause feature, etc) and run smtp test or post message to mailing list to deliver it.
--
Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/2.1-add-smtp-timeout into lp:mailman/2.1.