Mailman 3 April 2011 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 19 Aug '22

19 Aug '22

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[Bug 544477] [NEW] setting localhost in postfix_lmtp breaks delivery
by Patrick Ben Koetter 27 Sep '20

27 Sep '20

Public bug reported: Setting localhost in postfix_lmtp works against Postfix defaults and breaks delivery. Reason: The Postfix lmtp client only uses dns queries by default to search for hostnames. If the DNS server does not provide an answer for "localhost" delivery from the lmtp client to mailman fails. Solution: Provide "127.0.0.1" instead of "localhost". This does not require DNS and is even faster because it saves DNS lookups. Example: hey2(a)mailman.state-of-mind.de lmtp:[localhost.localdomain]:8024 ** Affects: mailman Importance: Undecided Status: New ** Tags: 3.0 mailman -- setting localhost in postfix_lmtp breaks delivery https://bugs.launchpad.net/bugs/544477 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

4 7

[Bug 701558] [NEW] Content filtering leaves a single sub-part in a multipart message.
by Mark Sapiro 10 Jun '17

10 Jun '17

Public bug reported: If the original message is multipart but not multipart/alternative and content filtering removes all but one part, the message is left as a multipart message with only the one sub-part instead of being recast as just the sub-part. This can cause msg_header and/or msg_footer to be added as separate parts to a text/plain message instead of being added to the text/plain body part. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Triaged ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => Triaged ** Changed in: mailman Milestone: None => 2.1.15 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) ** Description changed: - If the original message in multipart but not multipart/alternative and + If the original message is multipart but not multipart/alternative and content filtering removes all but one part, the message is left as a multipart message with only the one sub-part instead of being recast as just the sub-part. This can cause msg_header and/or msg_footer to be added as separate - parts to a text/plain message instead if being added to the text/plain + parts to a text/plain message instead of being added to the text/plain body part. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/701558 Title: Content filtering leaves a single sub-part in a multipart message.

3 7

[Bug 576675] [NEW] Content filtering fails to collapse alternatives.
by Mark Sapiro 10 Jun '17

10 Jun '17

Public bug reported: Collapsing multipart/alternative parts to just the first alternative only works if the message itself is multipart/alternative, or the multipart/alternative part is at the first sub-level. For example, given this structure: multipart/mixed | multipart/related | | multipart/alternative | | | text/plain | | | text/html | | image/jpeg | application/msword The multipart/alternative part will not be collapsed. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress ** Changed in: mailman Importance: Undecided => Medium ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: None => 2.1.14 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- Content filtering fails to collapse alternatives. https://bugs.launchpad.net/bugs/576675 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

3 7

[Bug 757062] [NEW] Content filtering can remove the headers from a message/rfc822 part.
by Mark Sapiro 10 Jun '17

10 Jun '17

Public bug reported: If Content filtering accepts both message/rfc822 and multipart/alternative MIME parts, and a message/rfc822 part contains a message whose content type is multipart/alternative and collapse_alternatives is Yes, the headers of the message in the message/rfc822 part will be lost. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: In Progress ** 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/757062 Title: Content filtering can remove the headers from a message/rfc822 part.

3 12

[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 543618] [NEW] test breaks if existing mailman.cfg is found
by Patrick Ben Koetter 24 Mar '15

24 Mar '15

Public bug reported: The test program reports an error if it detects an existing mailman.cfg: Failure in test test_current_working_directory (mailman.tests.test_configfile.TestConfigFileSearch) Traceback (most recent call last): File "/usr/lib/python2.6/unittest.py", line 279, in run testMethod() File "/root/mailman/src/mailman/tests/test_configfile.py", line 107, in test_current_working_directory self.assertEqual(found, config_file) File "/usr/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: '/etc/mailman.cfg' != u'/tmp/tmpVfAIyB/home/alex/mailman/hacking/mailman.cfg' I believe it should not do this. It should either silently ignore the difference or use the test mailman.cfg or ... but not break. ** Affects: mailman Importance: Undecided Status: New ** Tags: 3.0 mailman -- test breaks if existing mailman.cfg is found https://bugs.launchpad.net/bugs/543618 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

4 6

[Bug 518517] [NEW] Add the equivalent of postconf(1)
by Barry Warsaw 23 Apr '14

23 Apr '14

Public bug reported: Postfix has a very handy command called postconf(1) which lets you dump all or one Postfix configuration variable. It would be very handy for Mailman 3 to have something similar. ** Affects: mailman Importance: Medium Assignee: Barry Warsaw (barry) Status: Triaged ** Affects: mailman/3.0 Importance: Medium Assignee: Barry Warsaw (barry) Status: Triaged ** Also affects: mailman/3.0 Importance: Medium Assignee: Barry Warsaw (barry) Status: Triaged -- Add the equivalent of postconf(1) https://bugs.launchpad.net/bugs/518517 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

5 19

[Bug 674352] [NEW] List Moderator Login should check for username
by arky 12 Mar '14

12 Mar '14

Public bug reported: List Moderator logins currently prompt for list moderator password only. It would be good idea if prompt for username/password login as well. Mailman: 2.1.9 ** Affects: mailman Importance: Undecided Status: New -- List Moderator Login should check for username https://bugs.launchpad.net/bugs/674352 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

3 3