Mailman 3 November 2011 - Mailman-coders

[Bug 600780] [NEW] Login function needed in rest-client
by Anna 07 Apr '12

07 Apr '12

Public bug reported: For a good, working Mailman 3.0 UI we have to handle the passwords for each user (needed when they subscribe/unsubscribe/want to access their settings page but also for the admins and listowners). Hence, we need to implement the possibility to check for passwords in the rest-client (I believe these are saved in the user table in the core DB) and/or a login function. We should probably use https for the psw authentication. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest-api -- Login function needed in rest-client https://bugs.launchpad.net/bugs/600780 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

3 4

[Bug 788309] [NEW] Site configuration customization unnecessarily stored in tree
by Richard Wackerbarth 06 Apr '12

06 Apr '12

Public bug reported: The i18n templates for site customization are specified to be in <template_dir>/site/ etc., a part of the tree, rather than being placed in <var_dir> (outside the tree) Solution, move them to <var_dir>/templates/site/ ** 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/788309 Title: Site configuration customization unnecessarily stored in tree

2 5

[Bug 685261] [NEW] emailed command in subject header is ignored
by Mark Sapiro 06 Apr '12

06 Apr '12

Public bug reported: For example, a held message notification to the list owner/moderator contains an attached message/rfc822 part with subject "confirm <token>" and this message can be replied to with or without an "Approved: <password>" header/first body line to accept or discard the held message. The code allows for an MUA possibly inserting 'Re:' or some l10n equivalent in the subject making it "Re: confirm <token>", but if the l10n equivalent contains a non-ascii character, the entire command is ignored and the message continues to be held. ** 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/685261 Title: emailed command in subject header is ignored

2 6

[Bug 890675] [NEW] test_moderation fails on approved_at date comparison
by blacktav 06 Apr '12

06 Apr '12

Public bug reported: Tests fail with Failure in test test_accepted_message_gets_posted (mailman.app.tests.test_moderation.TestModeration) Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 318, in run testMethod() File "/home/devel/mailman/src/mailman/app/tests/test_moderation.py", line 83, in test_accepted_message_gets_posted 'Mon, 01 Aug 2005 07:49:23 -') File "/usr/lib64/python2.7/unittest/case.py", line 494, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib64/python2.7/unittest/case.py", line 487, in _baseAssertEqual raise self.failureException(msg) AssertionError: 'Mon, 01 Aug 2005 07:49:23 +' != u'Mon, 01 Aug 2005 07:49:23 -' which seems to include remnants of UTC offset in its comparison perhaps it should be mailman/src/mailman/app/tests/test_moderation.py: line 82 self.assertEqual(message['x-mailman-approved-at'][:-5], 'Mon, 01 Aug 2005 07:49:23 ') ** 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/890675 Title: test_moderation fails on approved_at date comparison To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/890675/+subscriptions

3 7

[Bug 876774] [NEW] AttributeError: 'MailingList' object has no attribute 'bounce_processing'
by Vincent Fretin 06 Apr '12

06 Apr '12

Public bug reported: With mailman 3.0.0a8 Oct 17 12:06:34 2011 (15436) Traceback (most recent call last): File "/home/zope/mailman/src/mailman/core/runner.py", line 138, in _one_iteration self._process_one_file(msg, msgdata) File "/home/zope/mailman/src/mailman/core/runner.py", line 220, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/home/zope/mailman/src/mailman/runners/bounce.py", line 46, in _dispose if not mlist.bounce_processing: AttributeError: 'MailingList' object has no attribute 'bounce_processing' It seems that bounce_processing is defined in src/mailman/styles/default.py The style are applied at mailing-list creation, but bounce_processing attribute is not persisted, the src/mailman/database/mailman.sql file doesn't define it. ** 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/876774 Title: AttributeError: 'MailingList' object has no attribute 'bounce_processing' To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/876774/+subscriptions

2 3

[Bug 874929] [NEW] Missing aliases in postfix_lmtp file when using more than one mailing-list
by Vincent Fretin 06 Apr '12

06 Apr '12

Public bug reported: With mailman 3.0.0a8. When I create a first mailing-list, I get in var/data/postfix_lmtp cpoi(a)example.com lmtp:[127.0.0.1]:8024 cpoi-bounces(a)example.com lmtp:[127.0.0.1]:8024 cpoi-confirm(a)example.com lmtp:[127.0.0.1]:8024 cpoi-join(a)example.com lmtp:[127.0.0.1]:8024 cpoi-leave(a)example.com lmtp:[127.0.0.1]:8024 cpoi-owner(a)example.com lmtp:[127.0.0.1]:8024 cpoi-request(a)example.com lmtp:[127.0.0.1]:8024 cpoi-subscribe(a)example.com lmtp:[127.0.0.1]:8024 cpoi-unsubscribe(a)example.com lmtp:[127.0.0.1]:8024 Then if I create a second mailing-list, I get: cpoi(a)example.com lmtp:[127.0.0.1]:8024 test(a)example.com lmtp:[127.0.0.1]:8024 test-bounces(a)example.com lmtp:[127.0.0.1]:8024 test-confirm(a)example.com lmtp:[127.0.0.1]:8024 test-join(a)example.com lmtp:[127.0.0.1]:8024 test-leave(a)example.com lmtp:[127.0.0.1]:8024 test-owner(a)example.com lmtp:[127.0.0.1]:8024 test-request(a)example.com lmtp:[127.0.0.1]:8024 test-subscribe(a)example.com lmtp:[127.0.0.1]:8024 test-unsubscribe(a)example.com lmtp:[127.0.0.1]:8024 I lost all aliases of the first mailing-list. I attached a patch for the src/mailman/mta/postfix.py file. ** 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/874929 Title: Missing aliases in postfix_lmtp file when using more than one mailing- list To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/874929/+subscriptions

2 4

[Bug 869317] [NEW] Mailman startup script missing --force option.
by Stephen A. Goss 06 Apr '12

06 Apr '12

Public bug reported: I rebooted the VM that mailman was running on, when I tried to start mailman up after the reboot, i got this output: $ mailman -C /etc/mailman.cfg start usage: mailman [-h] [-v] [-C CONFIG] {info,status,help,withlist,start,unshunt,create,stop,remove,lists,reopen,version,import21,inject,members,qfile,restart,aliases} ... mailman: error: A previous run of GNU Mailman did not exit cleanly. Try using --force. Running with the --force option didn't work: $ mailman --force -C /etc/mailman.cfg start usage: mailman [-h] [-v] [-C CONFIG] {info,status,help,withlist,start,unshunt,create,stop,remove,lists,reopen,version,import21,inject,members,qfile,restart,aliases} ... mailman: error: unrecognized arguments: --force ** 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/869317 Title: Mailman startup script missing --force option. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/869317/+subscriptions

3 7

[Bug 808821] [NEW] Probe messages should not sent Precedence header
by Barry Warsaw 06 Apr '12

06 Apr '12

Public bug reported: Probe messages (sent after an address has been disabled due to bounces) should not set Precedence. This is because they actually are not bulk or list traffic. It's possible that where list traffic might be bouncing, a non-Precedence containing probe message could have a better chance of getting through. One thing to think about though is vacation programs, which (if well-behaved) will not respond to Precedence messages. Thus, if a person's address were bouncing, and they had a vacation program on, these would respond to probe messages. This might be significant if we were to score probe bounces higher (i.e. as signs to permanently disable or delete the address). ** 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/808821 Title: Probe messages should not sent Precedence header To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/808821/+subscriptions

2 4

[Bug 872391] [NEW] KeyError: u'outgoing' in runner
by Stephen A. Goss 06 Apr '12

06 Apr '12

Public bug reported: Found this in my mailman.log. It may have happened around the time I was attempting to send a message through a mailing list and the SMTP receiver (fakemail.py in this case) died, so there were some failures to deliver. Oct 07 16:14:47 2011 (12057) Uncaught runner exception: u'outgoing' Oct 07 16:14:47 2011 (12057) Traceback (most recent call last): File "/home/phoenix/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration self._process_one_file(msg, msgdata) File "/home/phoenix/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/home/phoenix/mailman_clone/src/mailman/runners/retry.py", line 40, in _dispose config.switchboards['outgoing'].enqueue(msg, msgdata) KeyError: u'outgoing' ** 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/872391 Title: KeyError: u'outgoing' in runner To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/872391/+subscriptions

2 6

[Bug 867459] [NEW] REST API: Implement a simple way to check user credentials
by Florian Fuchs 06 Apr '12

06 Apr '12

Public bug reported: Currently there is no way to check a user's credentials via the REST API. While there were discussions on implementing a middleware "hook" to implement complex authentication logic, there should also be a simple way to check if a given combination of a user's credentials (user name and password) matches the one stored in mailman's internal db. A good way to do this (as discussed on IRC a while ago) could be to implement a SQL stored procedure-like behavior in the REST API. Meaning: A client sends a uname/pwd-combination to a specific URL resource and receives a plain True or False (1 or 0?) if the combination matches. This way, no password string is sent out via the API. Things to discuss or consider: 1.) How is the password stored in MMs internal db? (plaintext or hashed? if hashed, which algorithm is used?) 2.) (How) should the pwd be encrypted when sent to the API (depends on 1.)? 3.) Should this API resource be limited to requests from localhost and/or via SSL? ** 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/867459 Title: REST API: Implement a simple way to check user credentials To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/867459/+subscriptions

2 5