Public bug reported:
The fix for https://bugs.launchpad.net/mailman/+bug/1729472 will cause
OutgoingRunner to continually dequeue and requeue the message after the
first 15 minutes if DELIVERY_RETRY_WAIT is greater than 15 minutes. This
is because RetryRunner will wake up and requeue the message to be
retried in the out queue and from there, when OutgoingRunner determines
it's not yet time to retry, it just requeues the message in its own
queue.
RetryRunner should wait until DELIVERY_RETRY_WAIT has elapsed before
moving the message to the out queue.
** 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/1762871
Title:
Retries of temporary delivery failures can cause excessive activity in
OutgoingRunner.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1762871/+subscriptions
Public bug reported:
Mailman 2.1.24 added some string encode and decode method calls with an
errors= keyword argument. Sopport for errors as a keyword argument
requires Python 2.7.
This will be fixed by changing the argument to positional.
** 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/1755317
Title:
Python 2.7 dependency in Handlers/ToDigests.py
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1755317/+subscriptions
Public bug reported:
config_list can set list attributes to invalid values. For example, the
list's topics attribute is a list of 4-tuples. it is possible with
config_list to set topics to, e.g., a string or a list of strings. Doing
this will cause Mailman.MailList.CheckValues() to throw a ValueError.
This is a serious issue as it breaks everything that tries to
instantiate all lists such as the listinfo overview.
I'm not going to attempt to fix this in config_list, but I will fix
CheckValues() to not throw the uncaught ValueError() if topics is not a
list of 4-tuples.
** Affects: mailman
Importance: High
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/1754516
Title:
config_list can set invalid values and break lists.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1754516/+subscriptions
Public bug reported:
In Mailman 2.1.26, line 154 of Mailman/Cgi/subscribe.py is
except urllib2.URLError as e:
To work with Python older than 2.7 this needs to be
except urllib2.URLError, e:
** Affects: mailman
Importance: High
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/1752658
Title:
The reCAPTCHA implementation in Mailman 2.1.26 requires Python 2.7
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1752658/+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
Public bug reported:
Regardless of whether I choose MIME or plain-text digests, mailman
generates a MIME digest.
If I dump the configuration with "bin/config_list -o" it has the correct
plain-text setting.
# When receiving digests, which format is default?
#
# legal values are:
# 0 = "Plain"
# 1 = "MIME"
mime_is_default_digest = 0
Any ideas?
** Affects: mailman
Importance: Undecided
Status: New
** Tags: digest mime plain-text
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1761528
Title:
Cannot generate plain-text digests
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1761528/+subscriptions