Mailman 3 June 2018 - Mailman-coders

[Bug 1769374] [NEW] The reCAPTCHA feature requires JavaScript
by Mark Sapiro June 22, 2018

June 22, 2018

Public bug reported: Without JavaScript in the browser, the reCAPTCHA dialog does not appear on the listinfo subscribe form. JavaScript is required for this to work. For MM 2.1.27, we will add <noscript>This form requires JavaScript.</noscript> to the page to display that message if JavaScript is not enabled. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1769374 Title: The reCAPTCHA feature requires JavaScript To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1769374/+subscriptions

2 3

[Bug 1762871] [NEW] Retries of temporary delivery failures can cause excessive activity in OutgoingRunner.
by Mark Sapiro June 22, 2018

June 22, 2018

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 June 22, 2018

June 22, 2018

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 June 22, 2018

June 22, 2018

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 June 22, 2018

June 22, 2018

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

[Merge] lp:~futatuki/mailman/enhance-i18n-list-overview into lp:mailman/2.1
by Yasuhito FUTATSUKI＠POEM June 21, 2018

June 21, 2018

Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/enhance-i18n-list-overview into lp:mailman/2.1. Commit message: enhance i18n of listinfo/admin overview page Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/enhance-i18n-list-overview/+me… On listinfo/admin overview page, lists' description may be stored in different charset/encoding from what the page uses. However current implementation of listinfo/admin overview page uses those regardlessly of the difference, so those cannot be displayed correctly. To avoid this, (1) I've implemented a new function to get description as string of specified charset (with XML character reference) in MailList class, MailList.GetDescription(), and use it instead of accessing .description attribute directly in overview functions. This function uses a precondition that .description attribute is stored in charset of list's preferred_language. This is fundamentally true, but in case list's preferred_language has been changed and of the description hasn't, it is not true(Suppose changing preferred_language temporary to edit template files via Web UI, for example). To help to ensure the precondition, (2) I've added hook to change charset of list's description when preferred_language is changed via Web UI. (This is not always preserve identity of description string when preferred_languages is changed one of other charset/encoding and then changed back, because of multiple mapping of character between charset, and intentional use of XML character reference) -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/enhance-i18n-list-overview into lp:mailman/2.1.

1 0

[Merge] lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1
by Yasuhito FUTATSUKI＠POEM June 17, 2018

June 17, 2018

Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1. Commit message: Update ja translation up to lp:mailman/2.1 rev.1776 Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/3481… in messages/ja/LC_MESSAGES/mailman.po * Add translation of whence reasons into ja po file * refine translation of --unknown option description in docstring of cron/disabled in messages/ja/doc/Defaults.py.in * Add translation of comment for BLOCK_SPAMHAUS_LISTED_DBL_SUBSCRIBE in Defaults.py.in * fix corrupted comment -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1.

2 1

[Merge] lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1
by Yasuhito FUTATSUKI＠POEM June 17, 2018

June 17, 2018

Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1. Commit message: i18nize whence candidate message strings Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/i18n-add-whence-to-adminack-te… This is a solution of problem left in mp+347992. To mark whence messages for pygettext, I introduced dummy function i18n.D_(s) returns s it self, and then added "-k D_" option to pygettext commandline in messages/Makefile.in. This costs extra function call on execute, for its maintenancebility. I've picked up whence candidate message strings except from bin/add_member, bin/delete_member, and cron/disabled, and tested with ja translation (temporary for test, not included in this proposal). Note: * whence messages for user conformation of subscribe and unsubscribe are inconsistent. For subscribe they are 'via email confirmation' and 'via web confirmation', but for unsubscribe they are 'email confirmation' and 'web confirmation'. * admin approval for unsubscription dosen't report whence because ListAdmin.__handleunsubscription() calls ApproveDeleteMember() without whence option. -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1.

1 1

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

June 15, 2018

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

[Merge] lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1
by Yasuhito FUTATSUKI＠POEM June 14, 2018

June 14, 2018

Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1. Commit message: Add '%(whence)s' to adminsubscribeack.txt and adminunsubscribeack.txt, for each language. Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/i18n-add-whence-to-adminack-te… As far as I saw adminsubscribeack.txt and adminunsubscribeack.txt templates other than 'en', '%(whence)s' line can be added safely. So, I did it by using sed and shell script below(in ./templates directory, FreeBSD envirionment): --- begin --- #!/bin/sh LC_CTYPE=C sed='/usr/bin/sed' for l in * ; do if [ -d "${l}" -a ! "$l" = en ] ; then if [ -f ${l}/adminsubscribeack.txt ]; then ${sed} -I '' -e 's/$.$$/\1\ %(whence)s/' ${l}/adminsubscribeack.txt fi if [ -f ${l}/adminunsubscribeack.txt ]; then ${sed} -I '' -e 's/$.$$/\1\ %(whence)s/' ${l}/adminunsubscribeack.txt fi fi done --- end --- -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/i18n-add-whence-to-adminack-templates into lp:mailman/2.1.

2 1