Mailman 3 November 2011 - Mailman-coders

[Bug 889829] [NEW] setup takes zope interface 3.5.1, but needs 3.8.0
by Harry Enke July 31, 2015

July 31, 2015

Public bug reported: separate installation of zope interface 3.8.0 fixes the issue, afterwards mailman 3.0.0.8a OS: Scientific Linux 6.1, Python 2.6.6 ** 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/889829 Title: setup takes zope interface 3.5.1, but needs 3.8.0 To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/889829/+subscriptions

3 7

[Bug 856004] [NEW] "OperationalError: database is locked" encountered under very light load while using REST API
by Stephen A. Goss May 23, 2015

May 23, 2015

Public bug reported: I've seen this error twice while running integration tests (of our own application) that access Mailman 3 using the API. The load on Mailman is very light, as all requests made to the API are serial, never in parallel. Of course the various processing queues in MM3 are separate processes and could be doing work concurrently. The platform is Centos 6. Traceback (most recent call last): File "/usr/lib64/python2.6/wsgiref/handlers.py", line 93, in run self.result = application(self.environ, self.start_response) File "/home/sgoss/mailman_clone/src/mailman/rest/wsgiapp.py", line 63, in __call__ config.db.commit() File "/home/sgoss/mailman_clone/src/mailman/database/stock.py", line 70, in commit self.store.commit() File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/store.py", line 122, in commit self._connection.commit() File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 126, in commit self.raw_execute("COMMIT", _end=True) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/databases/sqlite.py", line 154, in raw_execute return Connection.raw_execute(self, statement, params) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 321, in raw_execute self._check_disconnect(raw_cursor.execute, *args) File "/home/sgoss/phoenix-deploy/lib/python2.6/site-packages/storm-0.18-py2.6-linux-x86_64.egg/storm/database.py", line 366, in _check_disconnect return function(*args, **kwargs) OperationalError: database is locked The backend here is SQLite, which falls over very quickly under concurrent load. If the goal here is to create a stable mailing list server, maybe SQLite is a poor default. ** 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/856004 Title: "OperationalError: database is locked" encountered under very light load while using REST API To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/856004/+subscriptions

3 8

[Bug 827547] [NEW] KeyError in "virgin" runner.
by Stephen A. Goss May 23, 2015

May 23, 2015

Public bug reported: Not sure what caused this error that showed up in mailman.log: Aug 16 10:54:50 2011 (31400) Uncaught runner exception: u'foo.example.com' Aug 16 10:54:50 2011 (31400) Traceback (most recent call last): File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 138, in _one_iteration self._process_one_file(msg, msgdata) File "/home/sgoss/mailman_clone/src/mailman/core/runner.py", line 220, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/home/sgoss/mailman_clone/src/mailman/runners/virgin.py", line 37, in _dispose process(mlist, msg, msgdata, 'virgin') File "/home/sgoss/mailman_clone/src/mailman/core/pipelines.py", line 50, in process handler.process(mlist, msg, msgdata) File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 360, in process process(mlist, msg, msgdata) File "/home/sgoss/mailman_clone/src/mailman/pipeline/cook_headers.py", line 202, in process listinfo = mlist.script_url('listinfo') File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 243, in script_url return urljoin(self.domain.base_url, target + '/' + self.fqdn_listname) File "/home/sgoss/mailman_clone/src/mailman/model/mailinglist.py", line 227, in domain return getUtility(IDomainManager)[self.mail_host] File "/home/sgoss/mailman_clone/src/mailman/model/domain.py", line 142, in __getitem__ raise KeyError(email_host) KeyError: u'foo.example.com' ** 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/827547 Title: KeyError in "virgin" runner. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/827547/+subscriptions

3 8

[Bug 889635] [NEW] Per-list configurable message headers for digests
by Joseph Fall May 23, 2015

May 23, 2015

Public bug reported: Digest messages are sent out with a partial set of headers for each message. The list of headers kept for each plain-text digested message is configured by the setting: PLAIN_DIGEST_KEEP_HEADERS = [ 'Message', 'Date', 'From', 'Subject', 'To', 'Cc', 'Message-ID', 'Keywords', 'Content-Type', ] My users are very perplexed and frustrated by the e-mail headers included in the digest - in particular, the Message-ID and Content-Type are meaningless, and the To header is repetitive. All this "noise" clutters up the content and makes the digest harder to read. Given that this is a plain-text digest, with the headers listed in the message body, I don't really see an RFC issue here? Yet they can only be configured using a list-wide override in mm_cfg.py I would be willing to work on this to allow a list admin to override the plain digest headers using the web interface, but want to hear from the development team if this is a patch they would be willing to consider before I invest the time. thanks. ** 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/889635 Title: Per-list configurable message headers for digests To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/889635/+subscriptions

4 7

[Bug 885715] [NEW] Mailman should add a Received header
by Barry Warsaw May 23, 2015

May 23, 2015

Public bug reported: When the LMTP runner or any other injection vector receives a message, it should add a Received header to indicate the time at which Mailman got the message. Use case: there is a spam filter between the incoming MTA and Mailman, and the message sits in the spam filter for a while before its administrator accepts the message. ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 ** Tags added: 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/885715 Title: Mailman should add a Received header To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/885715/+subscriptions

2 3

[Bug 869347] [NEW] bin/test script fails unless zope.testrunner is pip installed
by Stephen A. Goss May 23, 2015

May 23, 2015

Public bug reported: I am running Mailman 3 in a virtualenv with most of its package dependencies installed through pip. In this particular configuration, if I run `buildout`, the test script that is created cannot seem to load zope.testrunner properly: $ bin/test -vv Traceback (most recent call last): File "bin/test", line 35, in <module> import zope.testrunner ImportError: No module named testrunner The workaround is to remove the eggs folder, pip install zope.testrunner, and then re-run buildout. ** 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/869347 Title: bin/test script fails unless zope.testrunner is pip installed To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/869347/+subscriptions

3 3

[Bug 837700] [NEW] Issues with users subscribed via their preferred address
by Barry Warsaw May 23, 2015

May 23, 2015

Public bug reported: You can subscribe an address to a mailing list, and you can subscribe a user to a mailing list, if the user has a preferred address. There are two problems with this. * You can actually end up getting doubly subscribed (i.e. same address with the same role). Normally, the subscription mechanism prevents you from subscribing the same address with the same role more than once, or the same user with the same role more than once. However, if you subscribe once by the address, and once by the user whose preferred address is that same address, the double subscription occurs. * The Member repr() doesn't distinguish between a member that's subscribed via explicit address, and one that's subscribed via preferred address. This means that the above will appear as a double address subscription, when it's really not. Are these substantial problems that need to be fixed? Almost certainly the second one does, but I haven't come up with an elegant repr() for the case of a user subscribed with their preferred address. ** Affects: mailman Importance: Low Status: Confirmed ** 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/837700 Title: Issues with users subscribed via their preferred address To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/837700/+subscriptions

2 2

[Bug 793669] [NEW] feature request. change the 'list my other subscriptions' to also report if the other subscriptions are enabled or disabled
by Laura Creighton May 23, 2015

May 23, 2015

Public bug reported: I have a large number of subscriptions to mailing lists on python.org. Delivery is disabled on most of them. This is exactly how I want it -- I don't want to keep up with the day to day matters of the list, but I do want to be able to re-anable delivery and discuss things there should the need arise without having to create a new account. However, when I go on vacation, what I want to do is also disable a few high volume lists that I normally want to read every day. Thus what I would really like to see is which lists are currently enabled, so I can decide which one(s) if any I want to disable for the vacation. I don't want to disable the low-volume ones. Given that I am going to have to re-enable the lists I want to read when I get back one by one, I want the number of lists that get temporarily disabled to be as small as possible. And I want to be able to email me the short list of what they were so I can remember which ones to turn on again. Interestingly, the text of the message indicates a usability misunderstanding, and a grammatical error. The text reads: You can view a list of all the other mailing lists at python.org for which you are a member. Use this if you want to make the same membership option changes to this other subscriptions. It should be 'these other subscriptions'. And the people who want to make the same membership option changes to all the lists they are subscribed to on a site are precisely the users who don't need the feature. They can blindly go off and change things globally. If the number of lists they are subscribed to on that site is 1 -- i.e. they do not have any other subscriptions -- then saying to do things globally will do no harm. The reason you might want to look is to check because you might _not_ want to do things globally. And once you are dealing with that case, things you do not want to do globally, then of course you want to see the current settings that you have. But for my use case, all I care about is changing delivery status. All the other options I either never change, or want to change globally. I suspect that most people use mailing lists in this way, where the only thing they need to worry about is changes due to vacation, but I haven't conducted any polls to test this theory. This request sent to the tracker because the automated mail I recevied when some moderator refused to accept my mail to mailman-dev with this feature request, with the message 'why don't you just disable delivery globally and then reset them globally when you return' said that this was the place for feature requests and not the mailing list. Hope this request is clearer and explains why globally disabling is not what I want to do. Thank you ** 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/793669 Title: feature request. change the 'list my other subscriptions' to also report if the other subscriptions are enabled or disabled

4 9

[Bug 707295] [NEW] Membership Management Better Search Function
by arky May 23, 2015

May 23, 2015

Public bug reported: In Mailman Membership Management, I would like to option to filter search results by status viz (hide,nomail [reason], ack, not metoo, nodupes, digest, plain) ** 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/707295 Title: Membership Management Better Search Function

4 3

[Bug 514625] [NEW] Mailman 3 member functions should "guess" address membership
by Stephen Turnbull May 23, 2015

May 23, 2015

Public bug reported: Feature request Mailman 3 should try to fuzzily match unknown author addresses against the member database. For example, if "turnbull(a)sk.domain.tld" is subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and address>. [ ] Add <unknown address> as an alias for <member>." ** Affects: mailman Importance: Undecided Status: New ** Description changed: Feature request Mailman 3 should try to fuzzily match unknown author addresses against the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and - address>. [ ] Add <unknown> address as an alias for <member>." + address>. [ ] Add <unknown address> as an alias for <member>." ** Description changed: Feature request Mailman 3 should try to fuzzily match unknown author addresses against - the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is - subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same + the member database. For example, if "turnbull(a)sk.domain.tld" is + subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and address>. [ ] Add <unknown address> as an alias for <member>." -- Mailman 3 member functions should "guess" address membership https://bugs.launchpad.net/bugs/514625 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

4 5