Mailman 3 September 2014 - Mailman-coders

[Bug 1351312] [NEW] Message acceptance options not working
by John Naggets 23 May '15

23 May '15

Public bug reported: I am testing the two following list config parameters: default_nonmember_action default_member_action and actually the following options do not work: Reject (with notification) and Discard (no notification) It looks like currently only the hold for moderator and accept options are working. Is it possible that these two are not ready yet in the beta4 version of mailman? Furthermore the approval mail to the moderator contains in its body as reason XXX: Reason: XXX I guess this also needs adapting. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1351312 Title: Message acceptance options not working To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1351312/+subscriptions

2 1

[Bug 1333902] [NEW] Mailman 3.0 goes awry when handling messages in an unexpected format
by NotTheEvilOne 23 May '15

23 May '15

Public bug reported: Hi, This bug report is little bit inaccurate. I had the following situation. I sent a message to Mailman 3 from mutt. I think that this message had no unixfrom header in "email.message.Message". The log file showed an exception thrown at "mailman/cure/runner.py". The exception "AttributeError: class MIMEMultipart has no attribute 'sender'" was caused because "_process_one_file()" of "runner.py" accesses "mailman.email.message.Message.sender" without any validation. The loaded, pickled file contained a "MIMEMultipart" object, the other one a "email.message.Message" as far as I can remember. I have attached a patch that ensures that "runner.py" is handling the expected Mailman "Message" instance but I think this was not the root of the problem. Hope it helps anyway. Best regards and keep up the good work on Mailman 3 ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 ** Patch added: "Ensure runner.py handles a Mailman "Message" instance" https://bugs.launchpad.net/bugs/1333902/+attachment/4138396/+files/0003-mai… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1333902 Title: Mailman 3.0 goes awry when handling messages in an unexpected format To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1333902/+subscriptions

2 1

[Bug 1332922] [NEW] Mailman 3.0 REST API does not support e-mails with uppercase letters
by NotTheEvilOne 23 May '15

23 May '15

Public bug reported: Hi, the following test case resulted in: HTTP/1.0 500 Internal Server Error Username: MyTest e-mail: MyTest(a)domain.invalid 1. Create user curl -v -H "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" -X POST -d 'email=MyTest@domain.invalid&display_name=MyTest@domain.invalid' http://localhost:8001/3.0/users -> 201 Created DB address contains email "mytest(a)domain.invalid" and _original "MyTest(a)domain.invalid" curl -v -H "Accept: application/json" -H "Content-type: application/x -www-form-urlencoded" -X POST -d 'list_id=some_list.domain.invalid&role=member&subscriber=MyTest(a)domain.invalid' http://localhost:8001/3.0/members -> 500 Internal Server Error No log file contain any exception or error message Workaround available: Using lower-case letters result in a success curl -v -H "Accept: application/json" -H "Content-type: application/x-www-form-urlencoded" -X POST -d 'list_id=some_list.domain.invalid&role=member&subscriber=mymest(a)domain.invalid' http://localhost:8001/3.0/members ** 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/1332922 Title: Mailman 3.0 REST API does not support e-mails with uppercase letters To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1332922/+subscriptions

3 2

[Bug 1307644] [NEW] Remove IMailingList.moderator_password
by Barry Warsaw 23 May '15

23 May '15

Public bug reported: This attribute is obsolete and should be removed. ** Affects: mailman Importance: Undecided Assignee: Barry Warsaw (barry) Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1307644 Title: Remove IMailingList.moderator_password To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1307644/+subscriptions

2 1

[Bug 1292958] [NEW] Precedence: bulk header on subscription confirmation requests can cause request to be mis-classified
by Mark Sapiro 23 May '15

23 May '15

Public bug reported: This may be an issue with gmail and possibly elsewhere. See <https://mail.python.org/pipermail/mailman-users/2014-March/076294.html> ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1292958 Title: Precedence: bulk header on subscription confirmation requests can cause request to be mis-classified To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1292958/+subscriptions

3 2

[Bug 1285496] [NEW] A test in src/mailman/model/docs/registration.rst fails if Python default encoding is UTF-8
by Mark Sapiro 23 May '15

23 May '15

Public bug reported: The Invalid email addresses section in the doctests in src/mailman/model/docs/registration.rst attempts to register various invalid email addresses and checks that they are rejected. In particular, the test >>> registrar.register(mlist, '\xa0(a)example.com') Traceback (most recent call last): ... InvalidEmailAddressError: \xa0(a)example.com will fail if python's sys.getdefaultencoding() returns 'UTF-8' because the invalid address is reported with the UTF-8 encoding of nonbreaking space rather than \xa0. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1285496 Title: A test in src/mailman/model/docs/registration.rst fails if Python default encoding is UTF-8 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1285496/+subscriptions

2 1

[Bug 1252575] [NEW] The Mail<->News gateway doesn't honor moderation or *_these_nonmembers for messages gated from usnet.
by Mark Sapiro 23 May '15

23 May '15

Public bug reported: Messages gated to a list from usenet bypass all the checks in Moderate.py. It is appropriate to bypass generic_nonmember_action because many usenet posts will be from nonmembers of the list, but if the sender is a moderated member or a nonmember matching one of the *_these_nonmembers filters, those things should be honored. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1252575 Title: The Mail<->News gateway doesn't honor moderation or *_these_nonmembers for messages gated from usnet. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1252575/+subscriptions

4 5

[Bug 1197473] [NEW] moderating usenet->mailman posts
by Karl Berry 23 May '15

23 May '15

Public bug reported: In http://www.mail-archive.com/mailman-users%40python.org/msg62889.html, I explained the (very strong) desirability of having posts made from Usenet to Mailman be subject to normal moderation rules instead of automatically and unconditionally approved. (In short, to not let Usenet spam through to the mailing lists without any checking.) In his reply, http://www.mail-archive.com/mailman- users%40python.org/msg62890.html, Mark gave a simple one-line change (that is working fine so far as we can tell). When I asked, Mark told me that the change couldn't be made for mailman 2.1, since it would need to be a user option and thus have i18n impact, so suggested that I post it here, tagged mailman3, which I hope I've done here. Happy hacking, Karl ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1197473 Title: moderating usenet->mailman posts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1197473/+subscriptions

3 2

[Bug 1190582] [NEW] Add some common filters to REST API resources that expose collections
by Florian Fuchs 23 May '15

23 May '15

Public bug reported: When Postorius GETs a collection of lists from the REST API, it will in most situations only use a subset (the ones that are set to "advertise in list index"). This is a minor issue as long as the request isn't paginated, but can lead to incorrect item counts when it is. Example: GET /lists/test(a)example.com?page=1&count=10 will return all lists within the range [:10] from the database. If there are x unadvertised lists in the result, the page will only show 10 - x results. I guess the most common way to solve this is for the REST API to accept a number of common filter params which are used in the WHERE clause of the database query. In this case: GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest ** Description changed: When Postorius GETs a collection of lists from the REST API, it will in most situations only use a subset (the ones that are set to "advertise in list index"). This is a minor issue as long as the request isn't paginated, but can lead to incorrect item counts when it is. Example: GET /lists/test(a)example.com?page=1&count=10 will return all lists within the range [:10] from the database. If there are x unadvertised list in the result, the page will only show 10 - x results. I guess the most common way to solve this is for the REST API to accept - a number of common filter params which are used for the WHERE clause of + a number of common filter params which are used in the WHERE clause of the database query. In this case: GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both ** Description changed: When Postorius GETs a collection of lists from the REST API, it will in most situations only use a subset (the ones that are set to "advertise in list index"). This is a minor issue as long as the request isn't paginated, but can lead to incorrect item counts when it is. Example: GET /lists/test(a)example.com?page=1&count=10 will return all lists within the range [:10] from the database. If there - are x unadvertised list in the result, the page will only show 10 - x + are x unadvertised lists in the result, the page will only show 10 - x results. I guess the most common way to solve this is for the REST API to accept a number of common filter params which are used in the WHERE clause of the database query. In this case: GET /lists/test(a)example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1190582 Title: Add some common filters to REST API resources that expose collections To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1190582/+subscriptions

2 1

[Bug 1170726] [NEW] The LMTP server needs to check acceptable aliases
by Barry Warsaw 23 May '15

23 May '15

Public bug reported: The LMTP server currently does a sanity check on the To field of the incoming message, to ensure that it is addressed to a valid mailing list. This check ignores acceptable aliases, but it should honor them. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1170726 Title: The LMTP server needs to check acceptable aliases To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1170726/+subscriptions

4 3