Mailman-coders April 2018

mailman-coders@python.org

5 participants
16 discussions

[Bug 1762871] [NEW] Retries of temporary delivery failures can cause excessive activity in OutgoingRunner.
by Mark Sapiro 22 Jun '18

22 Jun '18

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

2 3

[Bug 1755317] [NEW] Python 2.7 dependency in Handlers/ToDigests.py
by Mark Sapiro 22 Jun '18

22 Jun '18

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

2 3

[Bug 1754516] [NEW] config_list can set invalid values and break lists.
by Mark Sapiro 22 Jun '18

22 Jun '18

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

2 3

[Bug 1752658] [NEW] The reCAPTCHA implementation in Mailman 2.1.26 requires Python 2.7
by Mark Sapiro 22 Jun '18

22 Jun '18

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

2 3

[Bug 1696066] [NEW] Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files
by Laurent Declercq 15 Jun '18

15 Jun '18

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

5 12

[Bug 1761528] [NEW] Cannot generate plain-text digests
by SeijiSensei 05 Apr '18

05 Apr '18

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

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders April 2018