Mailman 3 June 2014 - Mailman-coders

[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

[Bug 881320] [NEW] Mailman 3 translations
by Vincent Fretin May 23, 2015

May 23, 2015

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 1042828] [NEW] UI web URLs should be per-mailinglist
by Richard Wackerbarth May 23, 2015

May 23, 2015

Public bug reported: The web URL needs to be attached to the individual mailing lists and not to the email domain. However, for ease of configuration, and following DRY principals, default values should be derived from the list hierarchy. As an example use case, consider: The mail server is run by an umbrella organization. Each of the groups under the umbrella has its own website. Some of those might be co-hosted from the same server, but others could be elsewhere. Each group wants it to appear as if they are "stand alone", providing UI access to the mailing list functions from their individual websites rather than from that of the umbrella organization. ** 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/1042828 Title: UI web URLs should be per-mailinglist To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1042828/+subscriptions

3 5

[Bug 987019] [NEW] special case archive@mail-archive.com
by Jeff Breidenbach May 23, 2015

May 23, 2015

Public bug reported: As discussed, confusion can arise between the archiving module for mailman, and the manual mechanism of adding the archiving subscriber. Do something, perhaps involving ban lists, to keep us out of trouble. (I don't really know what is most sensible. I'd always imagined the archiving module would simply be adding the special subscriber address, but that's not the way it turned out.) ** 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/987019 Title: special case archive(a)mail-archive.com To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/987019/+subscriptions

3 2

[Bug 985149] [NEW] Add List-Post value to permalink hash input
by Barry Warsaw May 23, 2015

May 23, 2015

Public bug reported: Currently, we define the X-Message-ID-Hash as the base32 encoding of the sha1 hash of the Message-ID content (sans angle brackets as defined in RFC 5322). The suggestion is made that List-Post value should be added to this hash so as to be able to distinguish cross-posted messages. This should be fine, and pretty easy. My only concern is that the header name is now a misnomer. I wonder, is it worth coming up with a better header? Now's the time to do it since it's likely that there are almost no consumers of this standard. What about `Permalink-Hash` ? ** Affects: mailman Importance: High 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/985149 Title: Add List-Post value to permalink hash input To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/985149/+subscriptions

4 7

[Bug 982555] [NEW] LMTP should reject unknown lists in RCPT-stage
by Bernhard Schmidt May 23, 2015

May 23, 2015

Public bug reported: At the moment the LMTP runner rejects mails to non-existing lists after the DATA stage. # telnet localhost 8024 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mail.svr02.mucip.net Python LMTP runner 1.0 MAIL FROM: <berni(a)birkenwald.de> 250 Ok RCPT TO: <thislistdoesnotexist(a)birkenwald.de> 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Message-ID: <bal(a)blubb.de> as . 550 Requested action not taken: mailbox unavailable It should reject invalid addresses in the RCPT TO stage, this way it could easily be used with Postfix' feature "reject_unverified_recipient" to avoid accepting and then bouncing messages. ** 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/982555 Title: LMTP should reject unknown lists in RCPT-stage To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/982555/+subscriptions

4 3

[Bug 975711] [NEW] Store the list style in the mailinglist table
by Barry Warsaw May 23, 2015

May 23, 2015

Public bug reported: It seems useful to record the list style that was used to create the mailing list. Maybe this could be used later to propagate changes in the style to lists that were created with it. The problem is that the style machinery is way to over-engineered. There's actually a priority system for applying a style to a mailing list. This should be simplified anyway, and then we could store the style name in the database. It makes no sense to do this with the complicated scheme currently used. ** Affects: mailman Importance: High 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/975711 Title: Store the list style in the mailinglist table To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/975711/+subscriptions

2 1

[Bug 975670] [NEW] Documentation fails to specifying sphinx requirement
by Richard Wackerbarth May 23, 2015

May 23, 2015

Public bug reported: Sphinx is required to build the documentation. However, it is not automatically installed and the installation documentation fails to instruct that it be installed before building the online docs. ** 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/975670 Title: Documentation fails to specifying sphinx requirement To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/975670/+subscriptions

5 6

[Bug 965520] [NEW] Improve installation documentation
by Barry Warsaw May 23, 2015

May 23, 2015

Public bug reported: This page: http://packages.python.org/mailman/src/mailman/docs/START.html describes how to install, configure, and start Mailman 3. It's a bit sparse and out-of-date. For example, it doesn't describe all the locations that mailman.cfg is search for. It also doesn't describe installing and running mm3 in a virtualenv. This would make a nice bite-sized bug for someone wanting to contribution to Mailman. ** Affects: mailman Importance: Undecided Status: New ** Tags: documentation easy mailman3 ** Tags removed: bite-size ** Tags added: easy -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/965520 Title: Improve installation documentation To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/965520/+subscriptions

6 12