Mailman 3 May 2015 - Mailman-coders

[Bug 802540] Re: Add c.get_domain() by web_host and not only mail_host
by Abhilash Raj 23 May '15

23 May '15

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/28 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/802540 Title: Add c.get_domain() by web_host and not only mail_host To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/802540/+subscriptions

1 0

[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 23 May '15

23 May '15

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 23 May '15

23 May '15

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 23 May '15

23 May '15

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

[Bug 266263] Re: NNTP gatewaying trashes Message-IDs
by Abhilash Raj 23 May '15

23 May '15

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/24 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266263 Title: NNTP gatewaying trashes Message-IDs To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266263/+subscriptions

1 0

[Bug 265831] Re: Autoreplies confirm subscription invitations
by Abhilash Raj 23 May '15

23 May '15

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/23 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/265831 Title: Autoreplies confirm subscription invitations To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/265831/+subscriptions

1 0

[Bug 881320] [NEW] Mailman 3 translations
by Vincent Fretin 23 May '15

23 May '15

Public bug reported: In mailman 3.0.0a8, the locales directory contains actually mailman 2 translations. The unsubscribe mail is not translated into French because the msgids are different between mailman2 and mailman3. Do you have a script to generate a pot file and sync the po files? I had to generate myself the French mo file from the po. It's maybe a good idea to include mo files in the sdist, or generate mo files at mailman startup. ** 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/881320 Title: Mailman 3 translations To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/881320/+subscriptions

4 5

[Bug 266758] Re: cc rejects to admins
by Abhilash Raj 23 May '15

23 May '15

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/21 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266758 Title: cc rejects to admins To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266758/+subscriptions

1 0

[Bug 1447845] [NEW] Port to the Falcon 0.3 routing architecture
by Barry Warsaw 23 May '15

23 May '15

Public bug reported: In Mailman 3.0 we're still using a hacky subclass of falcon.API to integrate with Falcon 0.3. This works fine for now, but with Falcon's new pluggable routing architecture, there's a better way: http://falcon.readthedocs.org/en/latest/api/routing.html#routing It's too disruptive this close to the MM3.0 release to port our Falcon integration to this API, but we'll do it early in the MM3.1 development cycle. ** Affects: mailman Importance: High Assignee: Barry Warsaw (barry) Status: Triaged ** 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/1447845 Title: Port to the Falcon 0.3 routing architecture To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1447845/+subscriptions

2 1

[Bug 1444184] [NEW] Cannot join getting digest delivery via email interface
by Barry Warsaw 23 May '15

23 May '15

Public bug reported: The -join/-subscribe email command accepts a `digest=mime` and `digest=plain` option, but this does not work in Mailman 3.0 because it isn't plumbed through the IRegistrar interface. I'm deferring fixing this regression until 3.1. ** Affects: mailman Importance: High Assignee: Barry Warsaw (barry) Status: Triaged ** Tags: mailman3 ** Description changed: - The -join/-subscribe email command accepts a `digest=mime` option, but - this does not work in Mailman 3.0 because it isn't plumbed through the - IRegistrar interface. + The -join/-subscribe email command accepts a `digest=mime` and + `digest=plain` option, but this does not work in Mailman 3.0 because it + isn't plumbed through the IRegistrar interface. I'm deferring fixing this regression until 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/1444184 Title: Cannot join getting digest delivery via email interface To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1444184/+subscriptions

2 1