Mailman 3 April 2018 - Mailman-coders

[Bug 1756009] [NEW] emails are not delivered to all recipients
by Raimonds Aug. 2, 2023

Aug. 2, 2023

Public bug reported: Mailman often do not send emails to all addressees. Usually a single recipient is lost, but sometimes 2 or 3. there is a fragment from mailmans smtp log file, recipient count randomly changed from 28 to 27. Mar 15 08:57:31 2018 (60449) <20180315065723.E829F124FB4(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.395 seconds Mar 15 08:58:17 2018 (60449) <20180315065811.D36F512506A(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.… [View More]167 seconds Mar 15 09:09:04 2018 (60449) <20180315070859.42309125071(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.148 seconds Mar 15 09:13:47 2018 (60449) <20180315071331.34C3B12506A(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.151 seconds Mar 15 09:14:59 2018 (60449) <20180315071453.7FC1412506A(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.082 seconds Mar 15 09:15:54 2018 (60449) <20180315071548.217D912505D(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.249 seconds Mar 15 09:16:59 2018 (60449) <20180315071623.0193912506A(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.131 seconds Mar 15 09:17:05 2018 (60449) <20180315071629.1FD64124FC5(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.143 seconds Mar 15 09:17:27 2018 (60449) <20180315071645.194B212505A(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.093 seconds Mar 15 09:17:56 2018 (60449) <20180315071702.004EA12505A(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.211 seconds Mar 15 09:18:11 2018 (60449) <20180315071706.4F5F112505A(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.089 seconds Mar 15 09:18:20 2018 (60449) <20180315071711.BDFE412505A(a)naf.iem.gov.lv> smtp to dml-patch for 27 recips, completed in 0.112 seconds Mar 15 09:23:06 2018 (60449) <20180315072058.5882812506A(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.129 seconds Mar 15 09:23:34 2018 (60449) <20180315072217.AE70D125068(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.560 seconds Mar 15 09:23:41 2018 (60449) <20180315072244.39896124733(a)naf.iem.gov.lv> smtp to dml-patch for 28 recips, completed in 0.061 seconds list_members command always shows correct members count 28. /usr/lib/mailman/bin/list_members dml-patch | wc -l 28 OS CentOS Linux release 7.4.1708 Using Mailman version: 2.1.15 (standart centos package) The same problem was occur on Red Hat Enterprise Linux Server release 6.9 (Santiago) Mailman version: 2.1.12 ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1756009 Title: emails are not delivered to all recipients To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1756009/+subscriptions [View Less]

4 6

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net Aug. 19, 2022

Aug. 19, 2022

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things … [View More]that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… [View Less]

2 1

[Bug 1462755] [NEW] qrunner crashes on invalid unicode sequence
by Thijs Kinkhorst Feb. 28, 2022

Feb. 28, 2022

Public bug reported: When a message contains an invalud unicode sequence in its header, qrunner flat out crashes on that: May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't decode byte 0xe9 in position 18: invalid continuation byte May 17 15:32:20 2015 (981) Traceback (most recent call last): File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop self._onefile(msg, msgdata) File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile … [View More]

6 12

[Bug 965532] [NEW] Need a script to upgrade from MM2 to MM3
by Barry Warsaw Dec. 14, 2021

Dec. 14, 2021

Public bug reported: We need a script, documentation, or other procedure to help people migrate from Mailman 2 to Mailman 3. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/965532 Title: Need a script to upgrade from MM2 to MM3 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/965532/+subscriptions

8 21

[Bug 1609516] [NEW] [needs-packaging] GNU Mailman v3
by Kẏra May 13, 2021

May 13, 2021

Public bug reported: Mailman 3 is essentially five projects: Mailman Core Postorius - The Web UI for Mailman Mailman Client - The REST API Client HyperKitty - The Archiver for Mailman Mailman Bundler - Installer for Mailman Suite including all above projects URL: https://www.gnu.org/software/mailman/ ** Affects: mailman Importance: Undecided Status: New ** Affects: ubuntu Importance: Undecided Status: New ** Affects: debian Importance: Unknown … [View More]

3 7

[Bug 544477] [NEW] setting localhost in postfix_lmtp breaks delivery
by Patrick Ben Koetter Sept. 27, 2020

Sept. 27, 2020

Public bug reported: Setting localhost in postfix_lmtp works against Postfix defaults and breaks delivery. Reason: The Postfix lmtp client only uses dns queries by default to search for hostnames. If the DNS server does not provide an answer for "localhost" delivery from the lmtp client to mailman fails. Solution: Provide "127.0.0.1" instead of "localhost". This does not require DNS and is even faster because it saves DNS lookups. Example: hey2(a)mailman.state-of-mind.de lmtp:[localhost.… [View More]

4 7

[Bug 1731604] [NEW] VERP fails if the recipient address local part is quoted.
by Mark Sapiro April 13, 2020

April 13, 2020

Public bug reported: We have seen (very rarely) cases where a recipient address has a quoted local part such as "jr."@example.org. This results in a VERPed sender address like list-bounces+"jr."=example.org(a)example.com which is syntactically invalid. The VERPed sender should be "list- bounces+jr.=example.org"@example.com in this case. I.e., the entire VERPed sender local part should be quoted, not just the recipient local part. This also requires BounceRunner to recognize this and restore … [View More]

1 6

[Bug 883193] [NEW] Remove the X- prefix from some headers
by Barry Warsaw Jan. 15, 2019

Jan. 15, 2019

Public bug reported: MM3 still uses a lot of X- headers, but some of the X- prefixes can be removed. In general, we can just claim the Mailman- prefix for Mailman specific headers. Candidates include: Mailman-Rule-Hits Mailman-Rule-Misses Mailman-Version Mailman-Approved-At Mailman-LMTP-MailFrom (i.e. X-MailFrom) Mailman-Copy (or remove this header) Mailman-Content-Filter (from X-Content-Filtered-By) Also, fix the outdated comments about add-dup-header in avoid_duplicates.py and verp.py. … [View More]

3 6

[Bug 1094696] [NEW] Event notifications on postings
by George Chatzisofroniou Dec. 23, 2018

Dec. 23, 2018

Public bug reported: It looks like there is no way for a MM3 plugin to be signaled for a new posting. It would be great if core could provide a notification to the plugins that have subscribed to this event when a new post occurs. This notification should carry some interesting information, like the number of recipients and the message size. This request is also essential for the MM3-Metrics module (https://launchpad.net/mm3-metrics). ** Affects: mailman Importance: Undecided … [View More]

4 6

[Bug 1414352] [NEW] Improve code coverage by adding tests
by Terri Dec. 23, 2018

Dec. 23, 2018

Public bug reported: Mailman Core and Postorius have sets of tests, but could use more extensive test coverage. This bug is meant to be a repeatable bug suitable for new contributors (e.g. prospective Google Summer of Code Students). In short: find a piece of Postorius or Mailman Core that isn't yet tested and write a test (or set of tests) for it. Contributors wishing to work on Mailman Core should look at START.rst and DATABASE.rst for more information about setting up tests. For … [View More]

8 14

[Bug 1760506] [NEW] mm_cfg.py syntax error is handled ungracefully
by Bruce Perens June 24, 2018

June 24, 2018

Public bug reported: The user left a trailing quote out in mm_cfg.py . Mailman's response was to fail with the message "Mailman experienced a very low level failure". Perhaps "low-level failure" was Mailman's opinion of the user :-) One would hope that we could catch an exception from Python and give the user a bit more help. Thanks! - Bruce ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, … [View More]

3 5

[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 … [View More]

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/… [View More]

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(… [View More]

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 … [View More]

2 3

[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 … [View More]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 [View Less]

5 12

[Bug 1761528] [NEW] Cannot generate plain-text digests
by SeijiSensei April 5, 2018

April 5, 2018

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 … [View More]

2 1