From mark at msapiro.net Fri Jun 2 19:54:48 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:54:48 -0000 Subject: [Bug 1694384] Re: Missing mailman-owner@VIRTUAL_DOMAIN entry in data/virtual-mailman References: <149612801384.18003.8212779029827075590.malonedeb@chaenomeles.canonical.com> Message-ID: <149644768927.2977.11348040147440724328.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1694384 Title: Missing mailman-owner at VIRTUAL_DOMAIN entry in data/virtual-mailman To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1694384/+subscriptions From mark at msapiro.net Fri Jun 2 19:54:16 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:54:16 -0000 Subject: [Bug 1693366] Re: Setting member_verbosity_threshold to 1 results in moderating first post. References: <149566383921.22905.10723862354292881550.malonedeb@wampee.canonical.com> Message-ID: <149644765743.23085.4950439961829366944.launchpad@wampee.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1693366 Title: Setting member_verbosity_threshold to 1 results in moderating first post. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1693366/+subscriptions From mark at msapiro.net Fri Jun 2 19:54:06 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:54:06 -0000 Subject: [Bug 1645901] Re: DKIM signatures stripped from -owner messages with anonymous lists References: <20161129230201.28287.10424.malonedeb@soybean.canonical.com> Message-ID: <149644764797.17705.18117686177935311928.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1645901 Title: DKIM signatures stripped from -owner messages with anonymous lists To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1645901/+subscriptions From mark at msapiro.net Fri Jun 2 19:55:57 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:55:57 -0000 Subject: [Bug 1644356] Re: UnicodeError when attempting to send digests References: <20161123212058.8902.24251.malonedeb@soybean.canonical.com> Message-ID: <149644775882.3078.12004606598894641733.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1644356 Title: UnicodeError when attempting to send digests To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1644356/+subscriptions From mark at msapiro.net Fri Jun 2 19:51:38 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:51:38 -0000 Subject: [Bug 1643210] Re: 'from_is_list' does not RFC2047 encode correctly when translation contains non-ascii char References: <20161119170750.8717.22114.malonedeb@soybean.canonical.com> Message-ID: <149644749976.17490.2098107418910947687.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1643210 Title: 'from_is_list' does not RFC2047 encode correctly when translation contains non-ascii char To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1643210/+subscriptions From mark at msapiro.net Fri Jun 2 19:55:32 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:55:32 -0000 Subject: [Bug 1637745] Re: DMARC moderation could throw NameError in logging. References: <20161029165840.29840.51268.malonedeb@wampee.canonical.com> Message-ID: <149644773380.25142.16544592102681287686.launchpad@soybean.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1637745 Title: DMARC moderation could throw NameError in logging. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1637745/+subscriptions From mark at msapiro.net Fri Jun 2 19:53:54 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:53:54 -0000 Subject: [Bug 1637061] Re: Incorrect URLs in admin Membership List when chunked References: <20161027043148.19733.1699.malonedeb@soybean.canonical.com> Message-ID: <149644763478.3621.10327046035682512574.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1637061 Title: Incorrect URLs in admin Membership List when chunked To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1637061/+subscriptions From mark at msapiro.net Fri Jun 2 19:53:34 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:53:34 -0000 Subject: [Bug 1621172] Re: paths.py should add dist-packages (import error in Mailman CGIs) References: <20160907163952.5098.99736.malonedeb@wampee.canonical.com> Message-ID: <149644761572.17847.10410043947545251133.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1621172 Title: paths.py should add dist-packages (import error in Mailman CGIs) To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1621172/+subscriptions From mark at msapiro.net Fri Jun 2 19:55:21 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:55:21 -0000 Subject: [Bug 1620121] Re: The provided SYSV init script for mailman in missing LSB INIT INFO References: <20160904205323.12686.20783.malonedeb@chaenomeles.canonical.com> Message-ID: <149644772270.2802.15852280931190783104.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1620121 Title: The provided SYSV init script for mailman in missing LSB INIT INFO To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1620121/+subscriptions From mark at msapiro.net Fri Jun 2 19:55:11 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:55:11 -0000 Subject: [Bug 1619770] Re: cron/senddigests needs an exceptlist option References: <20160902184923.32623.80593.malonedeb@gac.canonical.com> Message-ID: <149644771226.2911.8220065232586379975.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1619770 Title: cron/senddigests needs an exceptlist option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1619770/+subscriptions From mark at msapiro.net Fri Jun 2 19:53:07 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:53:07 -0000 Subject: [Bug 1604544] Re: Letter links and footer links on admin Membership List rendered as Unicodes. References: <20160719192112.8736.9447.malonedeb@soybean.canonical.com> Message-ID: <149644758817.3368.13900903483687039469.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1604544 Title: Letter links and footer links on admin Membership List rendered as Unicodes. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1604544/+subscriptions From mark at msapiro.net Fri Jun 2 19:54:57 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:54:57 -0000 Subject: [Bug 1525954] Re: mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters References: <20151214152550.25123.231.malonedeb@soybean.canonical.com> Message-ID: <149644769892.18112.12151603236637001247.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1525954 Title: mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1525954/+subscriptions From mark at msapiro.net Fri Jun 2 19:52:54 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:52:54 -0000 Subject: [Bug 266464] Re: Subscriber "disappears" after subscription References: <20080905193221.27052.50410.launchpad@forster.canonical.com> Message-ID: <149644757569.17812.5458744028399669690.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266464 Title: Subscriber "disappears" after subscription To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266464/+subscriptions From mark at msapiro.net Fri Jun 2 19:52:04 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:52:04 -0000 Subject: [Bug 266269] Re: Default list signature blocks do not follow good netiquette References: <20080905193021.27052.96508.launchpad@forster.canonical.com> Message-ID: <149644752602.24684.8451845713469862818.launchpad@soybean.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266269 Title: Default list signature blocks do not follow good netiquette To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266269/+subscriptions From mark at msapiro.net Fri Jun 2 19:57:19 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:57:19 -0000 Subject: [Bug 1673307] Re: msg_header and/or msg_footer can be added as a separate MIME part even if only whitespace. References: <20170316022222.24941.2737.malonedeb@wampee.canonical.com> Message-ID: <149644784060.3514.3080642079758871109.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1673307 Title: msg_header and/or msg_footer can be added as a separate MIME part even if only whitespace. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1673307/+subscriptions From mark at msapiro.net Fri Jun 2 19:57:07 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:57:07 -0000 Subject: [Bug 1670033] Re: Text blocks, e.g. msg_footer, might not end with linefeed References: <20170304180537.7760.14797.malonedeb@chaenomeles.canonical.com> Message-ID: <149644782869.2873.596681300157076829.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1670033 Title: Text blocks, e.g. msg_footer, might not end with linefeed To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1670033/+subscriptions From mark at msapiro.net Fri Jun 2 19:56:56 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:56:56 -0000 Subject: [Bug 1667215] Re: Uncaught TypeError in subscribe CGI with multiple digest flags in post/query data References: <20170223054624.4063.63833.malonedeb@chaenomeles.canonical.com> Message-ID: <149644781741.18112.12465589381140413364.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1667215 Title: Uncaught TypeError in subscribe CGI with multiple digest flags in post/query data To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1667215/+subscriptions From mark at msapiro.net Fri Jun 2 19:56:44 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:56:44 -0000 Subject: [Bug 1664729] Re: Processing a probe bounce from a deleted member throws NotAMemberError References: <20170214214456.29967.71622.malonedeb@gac.canonical.com> Message-ID: <149644780545.25541.11947680606032483636.launchpad@soybean.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1664729 Title: Processing a probe bounce from a deleted member throws NotAMemberError To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1664729/+subscriptions From mark at msapiro.net Fri Jun 2 19:56:28 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:56:28 -0000 Subject: [Bug 1661810] Re: Certain Malformed list names throw TypeError: in roster CGI References: <20170204060726.14491.70065.malonedeb@soybean.canonical.com> Message-ID: <149644778908.3552.1459539161774711447.launchpad@gac.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1661810 Title: Certain Malformed list names throw TypeError: in roster CGI To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1661810/+subscriptions From mark at msapiro.net Fri Jun 2 19:56:17 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 02 Jun 2017 23:56:17 -0000 Subject: [Bug 1647450] Re: bin/add_members causes NameError when DISABLE_COMMAND_LOCALE_CSET = yes References: <20161205190734.25729.4237.malonedeb@wampee.canonical.com> Message-ID: <149644777880.17812.16841157783038064582.launchpad@chaenomeles.canonical.com> ** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1647450 Title: bin/add_members causes NameError when DISABLE_COMMAND_LOCALE_CSET = yes To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1647450/+subscriptions From 1695610 at bugs.launchpad.net Sat Jun 3 08:42:42 2017 From: 1695610 at bugs.launchpad.net (Laurent Declercq) Date: Sat, 03 Jun 2017 12:42:42 -0000 Subject: [Bug 1695610] [NEW] Test missing in lists_lists leading to wrong listing when using -V option Message-ID: <149649376267.25429.7404416901217304673.malonedeb@soybean.canonical.com> Public bug reported: Dear project leader, When we list the lists for specific virtualhost, a wrong result can be printed-out in the following condition: Let's say we have somme lists hosted on bbox.nuxwin.com domain and other lists on the lists.bbox.nuxwin.com virtualhost. Then, when running list_lists as follow: list_lists -b -V bbox.nuxwin.com We get also the lists names from the lists.bbox.nuxwin.com virtualhost which is an unexpected behavior. This is due to the fact that you're using find() only. Real use case: # Expected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V lists.bbox.nuxwin.com foobar release # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V bbox.nuxwin.com foobar mailman release # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V nuxwin.com foobar mailman release # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V com foobar mailman release # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V m foobar mailman release Thank you. ** Affects: mailman Importance: Undecided Status: New ** Description changed: Dear project leader, When we list the lists for specific virtualhost, a wrong result can be printed-out in the following condition: Let's say we have somme lists hosted on bbox.nuxwin.com domain and other lists on the lists.bbox.nuxwin.com virtualhost. Then, when running list_lists as follow: list_lists -b -V bbox.nuxwin.com We get also the lists names from the lists.bbox.nuxwin.com virtualhost which is an unexpected behavior. This is due to the fact that you're using find() only. Real use case: # Expected result: - root at devuan:/usr/lib/mailman/bin# /usr/lib/mailman/bin/list_lists -b -V lists.bbox.nuxwin.com + root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V lists.bbox.nuxwin.com foobar release # Unexpected result: - root at devuan:/usr/lib/mailman/bin# /usr/lib/mailman/bin/list_lists -b -V bbox.nuxwin.com + root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V bbox.nuxwin.com foobar mailman release # Unexpected result: - root at devuan:/usr/lib/mailman/bin# /usr/lib/mailman/bin/list_lists -b -V nuxwin.com + root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V nuxwin.com foobar mailman release # Unexpected result: - root at devuan:/usr/lib/mailman/bin# /usr/lib/mailman/bin/list_lists -b -V com + root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V com foobar mailman release # Unexpected result: - root at devuan:/usr/lib/mailman/bin# /usr/lib/mailman/bin/list_lists -b -V m + root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V m foobar mailman release 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/1695610 Title: Test missing in lists_lists leading to wrong listing when using -V option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695610/+subscriptions From 1695610 at bugs.launchpad.net Sat Jun 3 08:55:13 2017 From: 1695610 at bugs.launchpad.net (Laurent Declercq) Date: Sat, 03 Jun 2017 12:55:13 -0000 Subject: [Bug 1695610] Re: Test missing in lists_lists leading to wrong listing when using -V option References: <149649376267.25429.7404416901217304673.malonedeb@soybean.canonical.com> Message-ID: <149649451334.17566.1924909301263517982.launchpad@chaenomeles.canonical.com> ** Also affects: mailman (Ubuntu) Importance: Undecided Status: New ** Also affects: mailman (Debian) Importance: Undecided Status: New ** Description changed: Dear project leader, When we list the lists for specific virtualhost, a wrong result can be printed-out in the following condition: - Let's say we have somme lists hosted on bbox.nuxwin.com domain and other - lists on the lists.bbox.nuxwin.com virtualhost. Then, when running - list_lists as follow: + Let's say we have somme lists hosted on bbox.nuxwin.com virtualhost and + other lists on the lists.bbox.nuxwin.com virtualhost. Then, when + running list_lists as follow: list_lists -b -V bbox.nuxwin.com We get also the lists names from the lists.bbox.nuxwin.com virtualhost which is an unexpected behavior. This is due to the fact that you're using find() only. Real use case: # Expected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V lists.bbox.nuxwin.com - foobar - release + foo + bar # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V bbox.nuxwin.com - foobar - mailman - release + foo + bar # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V nuxwin.com - foobar - mailman - release + foo + bar # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V com - foobar - mailman - release + foo + bar # Unexpected result: root at devuan:~# /usr/lib/mailman/bin/list_lists -b -V m - foobar - mailman - release + foo + bar 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/1695610 Title: Test missing in lists_lists leading to wrong listing when using -V option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695610/+subscriptions From 1695610 at bugs.launchpad.net Sat Jun 3 16:35:19 2017 From: 1695610 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Sat, 03 Jun 2017 20:35:19 -0000 Subject: [Bug 1695610] Re: Test missing in lists_lists leading to wrong listing when using -V option References: <149649376267.25429.7404416901217304673.malonedeb@soybean.canonical.com> Message-ID: <20170603203521.7126.71018.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1695610 Title: Test missing in lists_lists leading to wrong listing when using -V option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695610/+subscriptions From mark at msapiro.net Sat Jun 3 16:36:00 2017 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 03 Jun 2017 20:36:00 -0000 Subject: [Bug 1695610] Re: Test missing in lists_lists leading to wrong listing when using -V option References: <149649376267.25429.7404416901217304673.malonedeb@soybean.canonical.com> Message-ID: <149652216200.3621.12208626862302328292.launchpad@gac.canonical.com> ** Changed in: mailman Importance: Undecided => Low ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.25 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1695610 Title: Test missing in lists_lists leading to wrong listing when using -V option To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695610/+subscriptions From mark at msapiro.net Sat Jun 3 16:49:25 2017 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 03 Jun 2017 20:49:25 -0000 Subject: [Bug 1695667] [NEW] Various web attacks cause CGI modules to throw uncaught exceptions Message-ID: <149652296577.17490.12287481389540698590.malonedeb@chaenomeles.canonical.com> Public bug reported: This is merely an annoyance in that it adds error reports to Mailman's error log. The web response is just the "we hit a bug" page, but we may wish to defend against these. We have seen errors like Jun 02 15:47:45 2017 admin(31978): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(31978): [----- Mailman Version: 2.1.23 -----] admin(31978): [----- Traceback ------] admin(31978): Traceback (most recent call last): admin(31978): File "/srv/mailman/scripts/driver", line 117, in run_main admin(31978): main() admin(31978): File "/srv/mailman/Mailman/Cgi/subscribe.py", line 109, in main admin(31978): process_form(mlist, doc, cgidata, language) admin(31978): File "/srv/mailman/Mailman/Cgi/subscribe.py", line 147, in process_form admin(31978): ftime, fhash = cgidata.getvalue('sub_form_token', '').split(':') admin(31978): AttributeError: 'list' object has no attribute 'split' Jun 02 15:48:05 2017 admin(32270): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(32270): [----- Mailman Version: 2.1.23 -----] admin(32270): [----- Traceback ------] admin(32270): Traceback (most recent call last): admin(32270): File "/srv/mailman/scripts/driver", line 117, in run_main admin(32270): main() admin(32270): File "/srv/mailman/Mailman/Cgi/listinfo.py", line 74, in main admin(32270): if not Utils.IsLanguage(language): admin(32270): File "/srv/mailman/Mailman/Utils.py", line 751, in IsLanguage admin(32270): return mm_cfg.LC_DESCRIPTIONS.has_key(lang) admin(32270): TypeError: unhashable type: 'list' Jun 02 17:24:06 2017 admin(6887): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(6887): [----- Mailman Version: 2.1.23 -----] admin(6887): [----- Traceback ------] admin(6887): Traceback (most recent call last): admin(6887): File "/srv/mailman/scripts/driver", line 117, in run_main admin(6887): main() admin(6887): File "/srv/mailman/Mailman/Cgi/admin.py", line 118, in main admin(6887): cgidata.getvalue('adminpw', '')): admin(6887): File "/srv/mailman/Mailman/SecurityManager.py", line 238, in WebAuthenticate admin(6887): ac = self.Authenticate(authcontexts, response, user) admin(6887): File "/srv/mailman/Mailman/SecurityManager.py", line 180, in Authenticate admin(6887): sharesponse = sha_new(response).hexdigest() admin(6887): TypeError: must be string or buffer, not list The above all result from POST data or query fragments containing multiple values for the same parameter resultin in that parameter being passed to the CGI as a list rather than a string. We have also seen Jun 02 17:08:00 2017 admin(27163): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(27163): [----- Mailman Version: 2.1.23 -----] admin(27163): [----- Traceback ------] admin(27163): Traceback (most recent call last): admin(27163): File "/srv/mailman/scripts/driver", line 117, in run_main admin(27163): main() admin(27163): File "/srv/mailman/Mailman/Cgi/options.py", line 113, in main admin(27163): params = cgidata.keys() admin(27163): File "/usr/lib/python2.7/cgi.py", line 582, in keys admin(27163): raise TypeError, "not indexable" admin(27163): TypeError: not indexable which comes from a POST with no post data. ** Affects: mailman Importance: Low 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/1695667 Title: Various web attacks cause CGI modules to throw uncaught exceptions To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695667/+subscriptions From mark at msapiro.net Sun Jun 4 22:00:57 2017 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 05 Jun 2017 02:00:57 -0000 Subject: [Bug 1602608] Re: mailman crash for subscription in webinterface References: <20160713101125.14797.9509.malonedeb@soybean.canonical.com> Message-ID: <149662805816.2873.8652715779023470019.malone@gac.canonical.com> The fix for https://bugs.launchpad.net/bugs/1614841 caused a regression of this fix in options.py. This regression is fixed in http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1711. ** Changed in: mailman Status: Fix Released => Fix Committed ** Changed in: mailman Milestone: 2.1.23 => 2.1.25 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1602608 Title: mailman crash for subscription in webinterface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1602608/+subscriptions From mark at msapiro.net Sun Jun 4 22:07:18 2017 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 05 Jun 2017 02:07:18 -0000 Subject: [Bug 1695667] Re: Various web attacks cause CGI modules to throw uncaught exceptions References: <149652296577.17490.12287481389540698590.malonedeb@chaenomeles.canonical.com> Message-ID: <149662843885.24715.2676587880051012051.malone@soybean.canonical.com> Regarding the last error above, "TypeError: not indexable"; that had been fixed by https://bugs.launchpad.net/bugs/1602608 but https://bugs.launchpad.net/bugs/1614841 caused a regression of that fix in options.py. The regression is now fixed at http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1711 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1695667 Title: Various web attacks cause CGI modules to throw uncaught exceptions To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695667/+subscriptions From 1695667 at bugs.launchpad.net Mon Jun 5 23:27:09 2017 From: 1695667 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Tue, 06 Jun 2017 03:27:09 -0000 Subject: [Bug 1695667] Re: Various web attacks cause CGI modules to throw uncaught exceptions References: <149652296577.17490.12287481389540698590.malonedeb@chaenomeles.canonical.com> Message-ID: <20170606032710.2417.27848.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1695667 Title: Various web attacks cause CGI modules to throw uncaught exceptions To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695667/+subscriptions From 1696066 at bugs.launchpad.net Tue Jun 6 03:41:04 2017 From: 1696066 at bugs.launchpad.net (Laurent Declercq) Date: Tue, 06 Jun 2017 07:41:04 -0000 Subject: [Bug 1696066] [NEW] Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files Message-ID: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> 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 From 1696066 at bugs.launchpad.net Tue Jun 6 04:03:20 2017 From: 1696066 at bugs.launchpad.net (Laurent Declercq) Date: Tue, 06 Jun 2017 08:03:20 -0000 Subject: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files References: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> Message-ID: <149673620142.8658.11987843765065837237.launchpad@gac.canonical.com> ** 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 (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. + when the files are created from scratch. Eg: + + IF NOT EXISTS aliases: + Touch data/aliases data/aliases.db with correct permissions (066x) + Add alias entries into aliases as usually + Run POSTALIAS(1) command as usually + + Then, we are fine. 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 (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. Eg: + correct permissions on *.db file, to be sure that Mailman group has + write permissions, at least when the files are created from scratch. Eg: IF NOT EXISTS aliases: - Touch data/aliases data/aliases.db with correct permissions (066x) - Add alias entries into aliases as usually - Run POSTALIAS(1) command as usually + ???Touch data/aliases data/aliases.db with correct permissions (066x) + ???Add alias entries into aliases as usually + ???Run POSTALIAS(1) command as usually Then, we are fine. 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 From 1696066 at bugs.launchpad.net Tue Jun 6 06:13:44 2017 From: 1696066 at bugs.launchpad.net (Laurent Declercq) Date: Tue, 06 Jun 2017 10:13:44 -0000 Subject: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files References: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> Message-ID: <149674402473.32423.13771370852682811192.launchpad@chaenomeles.canonical.com> ** 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 (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 + As you can see here, the Mailman data/aliases file 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 *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg: IF NOT EXISTS aliases: ???Touch data/aliases data/aliases.db with correct permissions (066x) ???Add alias entries into aliases as usually ???Run POSTALIAS(1) command as usually Then, we are fine. 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 From 1696202 at bugs.launchpad.net Tue Jun 6 14:24:49 2017 From: 1696202 at bugs.launchpad.net (Terri) Date: Tue, 06 Jun 2017 18:24:49 -0000 Subject: [Bug 1696202] [NEW] Setting private_roster to list admin only causes subscriptions to break Message-ID: <149677348943.28996.14282639406295986673.malonedeb@wampee.canonical.com> Public bug reported: This is an odd one, seen on https://mail.python.org/ The Pycon Pune list was set up such that private_roster was set to list admin only, whereupon all subscribers got a message "The hidden token didn't match. Did your IP change?" after they entered their email address and were sent to the standard page at https://mail.python.org/mailman/confirm/pycon-pune I reset the private_roster to "List members" and for some reason, this solved the problem and would-be subscribers get the usual "Your subscription request has been received, and will soon be acted upon." message. Not sure if this is a mail.python.org specific bug or a mailman 2.1 issue in general, but I figure Mark's equipped to handle either one so filing here is the right choice regardless. ** 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/1696202 Title: Setting private_roster to list admin only causes subscriptions to break To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696202/+subscriptions From mark at msapiro.net Tue Jun 6 17:32:30 2017 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 06 Jun 2017 21:32:30 -0000 Subject: [Bug 1696202] Re: Setting private_roster to list admin only causes subscriptions to break References: <149677348943.28996.14282639406295986673.malonedeb@wampee.canonical.com> Message-ID: <149678475013.29240.3529531645957077695.malone@wampee.canonical.com> I just tried subscribing to mailman-users at python.org from the page at . This list has private rosters and the subscription process went completely normally. Upon submitting the form, I was sent to the subscribe results page and all was as expected. There is in issue with load balancers and perhaps proxies. The IPv4 address that submits the form has to match the address that did the GET of the form. It used to have to match exactly, but because of load balancer issues we've seen it now only has to match the first 3 octets . Maybe there is some IP change issue and changing private_roster was just a coincidence. I've looked at logs and I see Jun 05 11:15:42 2017 (21148) pycon-pune: pending Anwesha ... Jun 05 11:25:35 2017 (23837) pycon-pune: pending Kushal ... Jun 05 20:42:26 2017 (18559) pycon-pune: pending Kushal ... Jun 06 07:32:48 2017 (9267) pycon-pune: pending Sayan ... Jun 06 14:13:45 2017 (5012) pycon-pune: pending Terri Test ... Associated with some of those, I see successful GETs of the listinfo and POSTs of the form. I also see these GETs and posts shortly before the successful Terri Test subscribe. /var/log/apache2/mail.python.org-ssl_access.log:134.134.139.75 - - [06/Jun/2017:14:06:21 -0400] "GET /mailman/listinfo/pycon-pune HTTP/2.0" 200 2292 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:192.55.55.41 - - [06/Jun/2017:14:08:31 -0400] "GET /mailman/listinfo/pycon-pune HTTP/2.0" 200 2291 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:134.134.139.75 - - [06/Jun/2017:14:08:42 -0400] "POST /mailman/subscribe/pycon-pune HTTP/2.0" 200 546 "https://mail.python.org/mailman/listinfo/pycon-pune" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:134.134.139.75 - - [06/Jun/2017:14:09:15 -0400] "GET /mailman/listinfo/pycon-pune HTTP/2.0" 200 2293 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:192.55.55.41 - - [06/Jun/2017:14:09:24 -0400] "POST /mailman/subscribe/pycon-pune HTTP/2.0" 200 546 "https://mail.python.org/mailman/listinfo/pycon-pune" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:192.55.55.41 - - [06/Jun/2017:14:12:02 -0400] "GET /mailman/listinfo/pycon-pune HTTP/2.0" 200 2292 "https://mail.python.org/mailman/admin/pycon-pune/digest" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" /var/log/apache2/mail.python.org-ssl_access.log:134.134.139.75 - - [06/Jun/2017:14:12:51 -0400] "POST /mailman/subscribe/pycon-pune HTTP/2.0" 200 546 "https://mail.python.org/mailman/listinfo/pycon-pune" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36" These look like two different IPs doing GET and POST and that should be OK, but may be an issue somehow. I also installed the not well tested fix for at about 13:20 on 06 June, so that could be involved, but as I said, it worked for me on Mailman-users with private_roster set to admin only. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1696202 Title: Setting private_roster to list admin only causes subscriptions to break To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696202/+subscriptions From 1696066 at bugs.launchpad.net Tue Jun 6 17:44:47 2017 From: 1696066 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Tue, 06 Jun 2017 21:44:47 -0000 Subject: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files References: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> Message-ID: <20170606214448.2417.33776.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- 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 From mark at msapiro.net Tue Jun 6 17:53:47 2017 From: mark at msapiro.net (Mark Sapiro) Date: Tue, 06 Jun 2017 21:53:47 -0000 Subject: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files References: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> Message-ID: <149678602719.8344.14220951445814395218.malone@gac.canonical.com> There is another issue not mentioned in the original report and that is that aliases.db must be owned by the Mailman user so Postfix runs the pipe as the Mailman user and group. bin/check_perms would check/fix this and also ensure the mode is at least 0660, but I've gone a step further and now ensure these things at the time the postalias and postmap commands are run and also ensure the mode is at least 0664 so Postfix doesn't need to be in Mailman's group. ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => Fix Committed ** Changed in: mailman Milestone: None => 2.1.25 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- 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 From kushaldas at gmail.com Tue Jun 6 20:25:44 2017 From: kushaldas at gmail.com (Kushal Das) Date: Wed, 07 Jun 2017 00:25:44 -0000 Subject: [Bug 1696202] Re: Setting private_roster to list admin only causes subscriptions to break References: <149677348943.28996.14282639406295986673.malonedeb@wampee.canonical.com> Message-ID: <149679514432.8739.6271022258398704615.malone@gac.canonical.com> I tried to subscribe again with my id, and I am getting stuck to the same confirmation page. So, maybe it is the load balancer as Mark suggested. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1696202 Title: Setting private_roster to list admin only causes subscriptions to break To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696202/+subscriptions From mark at msapiro.net Tue Jun 6 21:33:44 2017 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 07 Jun 2017 01:33:44 -0000 Subject: [Bug 1696202] Re: Setting private_roster to list admin only causes subscriptions to break References: <149677348943.28996.14282639406295986673.malonedeb@wampee.canonical.com> Message-ID: <149679922460.4479.7176731856891508439.malone@soybean.canonical.com> It's not load balancing or the "The hidden token didn't match. Did your IP change?" message that Terri mentions. I think that was affecting her testing, but is not the actual problem that was originally reported. The issue is that when one gets the initial https://mail.python.org/mailman/confirm/pycon-pune/xxx... page, it succeeds as it should, but somehow clicking "subscribe" Posts the form, but Apache sees a GET rather than a POST so The CGI doesn't see the cookie in the post data. I don't know how many lists are affected or why, but I've successfully confirmed subscription to two other mail.python.org lists, so I don't think it's a Mailman issue. Rather it seems to be apache or the network. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1696202 Title: Setting private_roster to list admin only causes subscriptions to break To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696202/+subscriptions From mark at msapiro.net Tue Jun 6 21:54:09 2017 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 07 Jun 2017 01:54:09 -0000 Subject: [Bug 1696202] Re: Setting private_roster to list admin only causes subscriptions to break References: <149677348943.28996.14282639406295986673.malonedeb@wampee.canonical.com> Message-ID: <149680044928.4861.9475478335327341208.malone@soybean.canonical.com> I'm marking this as invalid because the actual issue wasn't the "The hidden token didn't match. Did your IP change?" issue which I think only appeared in Terri's testing. The underlying issue was the list was created with URL host = python.org rather than mail.python.org causing all form submissions to redirect and lose POST data. The list is now fixed. ** Changed in: mailman Status: New => Invalid ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1696202 Title: Setting private_roster to list admin only causes subscriptions to break To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1696202/+subscriptions From 1696066 at bugs.launchpad.net Wed Jun 7 04:13:59 2017 From: 1696066 at bugs.launchpad.net (Laurent Declercq) Date: Wed, 07 Jun 2017 08:13:59 -0000 Subject: [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files References: <149673486419.28883.14597965095773088289.malonedeb@wampee.canonical.com> Message-ID: <149682323921.28841.15403443856955174994.malone@wampee.canonical.com> @msapiro I can confirm that the fixes solve the problems. Thank you for your involvement here. That is much appreciated. -- 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 From mark at msapiro.net Wed Jun 7 23:14:51 2017 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 08 Jun 2017 03:14:51 -0000 Subject: [Bug 1695667] Re: Various web attacks cause CGI modules to throw uncaught exceptions References: <149652296577.17490.12287481389540698590.malonedeb@chaenomeles.canonical.com> Message-ID: <149689169182.10191.3680112568506084921.launchpad@wampee.canonical.com> ** Changed in: mailman Status: In Progress => 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/1695667 Title: Various web attacks cause CGI modules to throw uncaught exceptions To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1695667/+subscriptions From mark at msapiro.net Wed Jun 7 23:18:04 2017 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 08 Jun 2017 03:18:04 -0000 Subject: [Bug 576675] Re: Content filtering fails to collapse alternatives. References: <20100506222630.1851.73554.malonedeb@gandwana.canonical.com> Message-ID: <149689188614.20169.7668542889652346132.launchpad@soybean.canonical.com> ** Changed in: mailman/3.0 Status: In Progress => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/576675 Title: Content filtering fails to collapse alternatives. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/576675/+subscriptions From mark at msapiro.net Fri Jun 9 17:12:15 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 21:12:15 -0000 Subject: [Bug 1697097] [NEW] The admindb held (un)subscriptions listing should include date and list newest. Message-ID: <149704273524.19571.2187879244593908054.malonedeb@soybean.canonical.com> Public bug reported: Currently, when presenting the list of held (un)subscription requests, the admindb CGI will delete all but one request from the same address. This deletion currently deletes all but the first request. I think it makes more sense to delete all but the last request. Also, the date of a subscription request is not reported in the listing. I think it should be. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) 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/1697097 Title: The admindb held (un)subscriptions listing should include date and list newest. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1697097/+subscriptions From mark at msapiro.net Fri Jun 9 17:30:27 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 21:30:27 -0000 Subject: [Bug 1697097] Re: The admindb held subscriptions listing should include date and list newest. References: <149704273524.19571.2187879244593908054.malonedeb@soybean.canonical.com> Message-ID: <149704382862.10476.13296475506461899746.launchpad@wampee.canonical.com> ** Summary changed: - The admindb held (un)subscriptions listing should include date and list newest. + The admindb held subscriptions listing should include date and list newest. ** Description changed: - Currently, when presenting the list of held (un)subscription requests, - the admindb CGI will delete all but one request from the same address. - This deletion currently deletes all but the first request. I think it - makes more sense to delete all but the last request. Also, the date of a + Currently, when presenting the list of held subscription requests, the + admindb CGI will delete all but one request from the same address. This + deletion currently deletes all but the first request. I think it makes + more sense to delete all but the last request. Also, the date of a subscription request is not reported in the listing. I think it should be. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1697097 Title: The admindb held subscriptions listing should include date and list newest. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1697097/+subscriptions From mark at msapiro.net Fri Jun 9 17:50:26 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 21:50:26 -0000 Subject: [Bug 1697097] Re: The admindb held subscriptions listing should include date and list newest. References: <149704273524.19571.2187879244593908054.malonedeb@soybean.canonical.com> Message-ID: <149704502740.8457.724256202338010097.launchpad@gac.canonical.com> ** Changed in: mailman Status: New => 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/1697097 Title: The admindb held subscriptions listing should include date and list newest. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1697097/+subscriptions From 1697097 at bugs.launchpad.net Fri Jun 9 17:50:32 2017 From: 1697097 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 09 Jun 2017 21:50:32 -0000 Subject: [Bug 1697097] Re: The admindb held subscriptions listing should include date and list newest. References: <149704273524.19571.2187879244593908054.malonedeb@soybean.canonical.com> Message-ID: <20170609215032.5667.61442.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1697097 Title: The admindb held subscriptions listing should include date and list newest. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1697097/+subscriptions From mark at msapiro.net Fri Jun 9 18:01:14 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:01:14 -0000 Subject: [Bug 978351] Re: Content Filtering *_filename_extension matches are case sensitive. References: <20120410205111.15378.93673.malonedeb@soybean.canonical.com> Message-ID: <149704567472.9686.1606760125962380100.launchpad@wampee.canonical.com> ** Branch unlinked: lp:~msapiro/mailman/mime_delete ** Changed in: mailman/3.0 Status: In Progress => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/978351 Title: Content Filtering *_filename_extension matches are case sensitive. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/978351/+subscriptions From mark at msapiro.net Fri Jun 9 18:02:51 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:02:51 -0000 Subject: [Bug 701558] Re: Content filtering leaves a single sub-part in a multipart message. References: <20110111172558.26120.79325.malonedeb@wampee.canonical.com> Message-ID: <149704577232.2611.2971904355381790186.launchpad@chaenomeles.canonical.com> ** Changed in: mailman/3.0 Status: In Progress => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/701558 Title: Content filtering leaves a single sub-part in a multipart message. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/701558/+subscriptions From mark at msapiro.net Fri Jun 9 18:13:11 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:13:11 -0000 Subject: [Bug 978351] Re: Content Filtering *_filename_extension matches are case sensitive. References: <20120410205111.15378.93673.malonedeb@soybean.canonical.com> Message-ID: <149704639225.2503.705683381925140548.launchpad@chaenomeles.canonical.com> ** Changed in: mailman/3.0 Milestone: None => 3.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/978351 Title: Content Filtering *_filename_extension matches are case sensitive. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/978351/+subscriptions From mark at msapiro.net Fri Jun 9 18:09:55 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:09:55 -0000 Subject: [Bug 757062] Re: Content filtering can remove the headers from a message/rfc822 part. References: <20110411032649.25540.48269.malonedeb@soybean.canonical.com> Message-ID: <149704619565.8562.15938505013364594112.launchpad@gac.canonical.com> ** Changed in: mailman/3.0 Status: In Progress => Fix Committed ** Changed in: mailman/3.0 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/757062 Title: Content filtering can remove the headers from a message/rfc822 part. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/757062/+subscriptions From mark at msapiro.net Fri Jun 9 18:09:18 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:09:18 -0000 Subject: [Bug 266230] Re: HTML email disappears References: <20080905192949.27052.54554.launchpad@forster.canonical.com> Message-ID: <149704615890.2429.4273749893299629151.launchpad@chaenomeles.canonical.com> ** Branch unlinked: lp:~msapiro/mailman/mime_delete -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266230 Title: HTML email disappears To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266230/+subscriptions From mark at msapiro.net Fri Jun 9 18:16:53 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:16:53 -0000 Subject: [Bug 576675] Re: Content filtering fails to collapse alternatives. References: <20100506222630.1851.73554.malonedeb@gandwana.canonical.com> Message-ID: <149704661414.20134.242204253562173054.launchpad@soybean.canonical.com> ** Changed in: mailman/3.0 Milestone: None => 3.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/576675 Title: Content filtering fails to collapse alternatives. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/576675/+subscriptions From mark at msapiro.net Fri Jun 9 18:17:22 2017 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 09 Jun 2017 22:17:22 -0000 Subject: [Bug 701558] Re: Content filtering leaves a single sub-part in a multipart message. References: <20110111172558.26120.79325.malonedeb@wampee.canonical.com> Message-ID: <149704664291.2873.7483683721979207424.launchpad@chaenomeles.canonical.com> ** Changed in: mailman/3.0 Milestone: None => 3.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/701558 Title: Content filtering leaves a single sub-part in a multipart message. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/701558/+subscriptions