Mailman 3 December 2005 - Mailman-coders

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

Aug. 19, 2022

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

[ mailman-Feature Requests-1394592 ] Allow any registered member to be a moderator
by SourceForge.net Dec. 31, 2005

Dec. 31, 2005

Feature Requests item #1394592, was opened at 2005-12-31 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1394592&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any registered member to be a moderator Initial Comment: A number of bug, info, or help mailing list are the target of spam, viruses and hoaxes. So often they have to be public but be moderated for non-subscribers even if they have spam or virus checking. The sad part about moderation is that it is usually an additional burden on the relatively fewer developers who are more skilled rather than the relatively larger folks who requesting services who are less skilled. So it might be nice to have a box or flag for such a mailing list that allows anyone who is registered in the mailing list have the pleasure of doing email moderation. After all, what's needed here is someone to be able to detect spam from a legitimate post and most people are capable of doing that. I suppose this could be subject for abuse too (discard valid posts and accept spam), but I have a feeling that to first order approximaton this would be a big help. And doesn't mailman already have ways of watching users or moderators, and revoking moderation by the administrator or whatnot? Thanks for considering this. -- worn down developer/administrator of GPL projects ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1394592&group_…

1 0

[ mailman-Patches-933757 ] fix for [815297] signatures break
by SourceForge.net Dec. 25, 2005

Dec. 25, 2005

Patches item #933757, was opened at 2004-04-12 19:15 Message generated for change (Comment added) made by schoinobates You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=933757&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Bernhard Reiter (ber) Assigned to: Nobody/Anonymous (nobody) Summary: fix for [815297] signatures break Initial Comment: Fix attempt for [ 815297 ] Breaking signatures in message/rfc822 attachement! https://sourceforge.net/tracker/?func=detail&aid=815297&group_id=103&atid=1… The patch introduces a new Mailman specific Generator class and only enables header folding for the top object and Mailbox.py and SMTPDirect.py. ---------------------------------------------------------------------- Comment By: Schoinobates Volans (schoinobates) Date: 2005-12-25 15:25 Message: Logged In: YES user_id=41822 A further revised version is at http://bugs.debian.org/cgi-bin/bugreport.cgi/77_header_folding_in_attachmen… ---------------------------------------------------------------------- Comment By: Schoinobates Volans (schoinobates) Date: 2005-12-12 17:33 Message: Logged In: YES user_id=41822 A slightly edited version of this patch is at http://bugs.debian.org/cgi-bin/bugreport.cgi/77_header_folding_in_attachmen… ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 19:56 Message: Logged In: YES user_id=113859 My patch was tested with python 2.3.3. Thomas Köster made a patch which also works with python 2.1.x I'll attach it. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-12 19:24 Message: Logged In: YES user_id=113859 A bug fix to a priority 8 bug... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=933757&group_i…

1 0

[ mailman-Bugs-1390018 ] HTML attachment escaped in archive
by SourceForge.net Dec. 25, 2005

Dec. 25, 2005

Bugs item #1390018, was opened at 2005-12-25 13:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1390018&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: HTML attachment escaped in archive Initial Comment: Send email to a list with an HTML attachment. Go to archive. Click on attachment link. See the HTML source instead of the rendered HTML. Use "view source" feature of browser. See that all HTML tags are themselves HTML-escaped. An example is at http://kitenet.net/pipermail/sayma/attachments/20051214/2ce1af82/10454316-0… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1390018&group_…

1 0

[ mailman-Bugs-1388778 ] /templates/fr/archtocentry.html typo
by SourceForge.net Dec. 23, 2005

Dec. 23, 2005

Bugs item #1388778, was opened at 2005-12-23 10:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1388778&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Fabrice Di Pasquale (fabdipasquale) Assigned to: Nobody/Anonymous (nobody) Summary: /templates/fr/archtocentry.html typo Initial Comment: <td> tags are missing o<--o<--o<--o<--o<--o<--o<--o<-- <tr> <td>%(archivelabel)s: o<--o<--o<--o<--o<--o<--o<--o<-- should be changed to o<--o<--o<--o<--o<--o<--o<--o<-- <tr> <td>%(archivelabel)s:</td> <td> o<--o<--o<--o<--o<--o<--o<--o<-- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1388778&group_…

1 0

[ mailman-Feature Requests-1387349 ] clarify when regexps are case-sensitive
by SourceForge.net Dec. 21, 2005

Dec. 21, 2005

Feature Requests item #1387349, was opened at 2005-12-21 12:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387349&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: clarify when regexps are case-sensitive Initial Comment: There are numerous bug reports about case sensitivity in various parts of Mailman. Here I request general clarification/documentation in the web admin's interface of case sensitivity for the regexp variables accessible via the administrative interface (header_filter_rules, etc.). If all regexps are treated the same, let's please have the default explained in a good place (even if it's just to say that Python defaults apply). When individual variables differ from the default, the details should be there in the variable's documentation. Example: as I consider how to set up my privacy filters (header_filter_rules, etc.) I realize I will have to experiment to see whether I need to deal with upper/lowercase issues in my regexp values, because I can find no explanation of how Mailman deals with case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387349&group_…

1 0

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination
by SourceForge.net Dec. 21, 2005

Dec. 21, 2005

Feature Requests item #1387243, was opened at 2005-12-21 08:01 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: option to discard messages that lack explicit destination Initial Comment: The configurable variable require_explicit_destination is a boolean that selects whether to hold a message for moderation if neither the list address nor any aliases appear in the To: or Cc: headers. On certain lists I manage, a lot of spam is sent to the lists via BCC:. Setting this variable keeps this spam off the list, which is great, but I spend a lot of time discarding the spam. I can't simply discard all messages held for moderation, because there are occasional legitimate messages held for another reason that I want to accept. So I have to trawl through it all. Therefore, please make the require_explicit_destination setting offer the familiar choices of allow, hold, reject, and discard. I'd be happy if you added just "discard" without adding "reject", but the full four choices would be consistent with the rest of Mailman. This will save me a lot of time, and I would think many other users are in the same situation. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-12-21 09:28 Message: Logged In: YES user_id=1123998 While we're at it, we probably should also add hold, reject and discard choices if max_num_recipients is > 0 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-12-21 08:32 Message: Logged In: YES user_id=1123998 I think this is a good idea. In the mean time, see the post and reply at <http://mail.python.org/pipermail/mailman-users/2005-December/048078.html> and <http://mail.python.org/pipermail/mailman-users/2005-December/048086.html> for some interim patch ideas. Also see the post at <http://mail.python.org/pipermail/mailman-users/2005-February/042954.html> for a way to do this with spam filters that doesn't require patching. ---------------------------------------------------------------------- Comment By: Matt Swift (msswift) Date: 2005-12-21 08:29 Message: Logged In: YES user_id=1409646 P.S. I realize that I can accomplish what I want by an appropriate setting of header_filter_rules, but it's not very convenient, since I can't make use of acceptable_aliases. The introduction of header_filter_rules is great, but it creates confusion by making the existing sender and recipient filters redundant. I suggest renaming the section in which header_filter_rules from "spam filters" to "advanced filter" or something like that. All three sections can be used to filter spam, so it's misleading to distinguish a "spam filter" from sender and recipient filters. The documentation for header_filter_rules / "advanced filter" section should explain that this filter is a general mechanism which exists; the sender/recipient filters are special cases that are common enough to merit a convenient interface just for them. Even with this clarification of the header_filter_rules, I still think require_explicit_destination should be expanded to offer all four actions. If you're going to go to the trouble of setting up the special interface to filter a lack of explicit destination, it really ought to offer complete options. It won't complicate the interface (really, it will simplify it to have the familiar four actions offered), and it seems very awkward to have to recreate this nice interface in header_filter_rules (acceptable_aliases and so on) just because the manager wants an action other than "accept" or "hold". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…

1 0

[ mailman-Feature Requests-1387324 ] document order in which message filters are applied
by SourceForge.net Dec. 21, 2005

Dec. 21, 2005

Feature Requests item #1387324, was opened at 2005-12-21 12:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387324&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: document order in which message filters are applied Initial Comment: The order in which Mailman applies various filters to messages does not appear to be documented in the administrator's web interface (where it should be) or anywhere else. As far as I can tell, the only way to find this out is to look at the source or to experiment. There are numerous feature requests that ask for control over the order in which these filters are applied. This request is even simpler, just to document the present fixed order of application. If eventually any control over the order is offered, the present state will need to be displayed to the administrator in the interface, so satisfying this request seems to be a prerequisite to satisfying the others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387324&group_…

1 0

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination
by SourceForge.net Dec. 21, 2005

Dec. 21, 2005

Feature Requests item #1387243, was opened at 2005-12-21 08:01 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: option to discard messages that lack explicit destination Initial Comment: The configurable variable require_explicit_destination is a boolean that selects whether to hold a message for moderation if neither the list address nor any aliases appear in the To: or Cc: headers. On certain lists I manage, a lot of spam is sent to the lists via BCC:. Setting this variable keeps this spam off the list, which is great, but I spend a lot of time discarding the spam. I can't simply discard all messages held for moderation, because there are occasional legitimate messages held for another reason that I want to accept. So I have to trawl through it all. Therefore, please make the require_explicit_destination setting offer the familiar choices of allow, hold, reject, and discard. I'd be happy if you added just "discard" without adding "reject", but the full four choices would be consistent with the rest of Mailman. This will save me a lot of time, and I would think many other users are in the same situation. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-12-21 08:32 Message: Logged In: YES user_id=1123998 I think this is a good idea. In the mean time, see the post and reply at <http://mail.python.org/pipermail/mailman-users/2005-December/048078.html> and <http://mail.python.org/pipermail/mailman-users/2005-December/048086.html> for some interim patch ideas. Also see the post at <http://mail.python.org/pipermail/mailman-users/2005-February/042954.html> for a way to do this with spam filters that doesn't require patching. ---------------------------------------------------------------------- Comment By: Matt Swift (msswift) Date: 2005-12-21 08:29 Message: Logged In: YES user_id=1409646 P.S. I realize that I can accomplish what I want by an appropriate setting of header_filter_rules, but it's not very convenient, since I can't make use of acceptable_aliases. The introduction of header_filter_rules is great, but it creates confusion by making the existing sender and recipient filters redundant. I suggest renaming the section in which header_filter_rules from "spam filters" to "advanced filter" or something like that. All three sections can be used to filter spam, so it's misleading to distinguish a "spam filter" from sender and recipient filters. The documentation for header_filter_rules / "advanced filter" section should explain that this filter is a general mechanism which exists; the sender/recipient filters are special cases that are common enough to merit a convenient interface just for them. Even with this clarification of the header_filter_rules, I still think require_explicit_destination should be expanded to offer all four actions. If you're going to go to the trouble of setting up the special interface to filter a lack of explicit destination, it really ought to offer complete options. It won't complicate the interface (really, it will simplify it to have the familiar four actions offered), and it seems very awkward to have to recreate this nice interface in header_filter_rules (acceptable_aliases and so on) just because the manager wants an action other than "accept" or "hold". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…

1 0

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination
by SourceForge.net Dec. 21, 2005

Dec. 21, 2005

Feature Requests item #1387243, was opened at 2005-12-21 11:01 Message generated for change (Comment added) made by msswift You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Swift (msswift) Assigned to: Nobody/Anonymous (nobody) Summary: option to discard messages that lack explicit destination Initial Comment: The configurable variable require_explicit_destination is a boolean that selects whether to hold a message for moderation if neither the list address nor any aliases appear in the To: or Cc: headers. On certain lists I manage, a lot of spam is sent to the lists via BCC:. Setting this variable keeps this spam off the list, which is great, but I spend a lot of time discarding the spam. I can't simply discard all messages held for moderation, because there are occasional legitimate messages held for another reason that I want to accept. So I have to trawl through it all. Therefore, please make the require_explicit_destination setting offer the familiar choices of allow, hold, reject, and discard. I'd be happy if you added just "discard" without adding "reject", but the full four choices would be consistent with the rest of Mailman. This will save me a lot of time, and I would think many other users are in the same situation. ---------------------------------------------------------------------- >Comment By: Matt Swift (msswift) Date: 2005-12-21 11:29 Message: Logged In: YES user_id=1409646 P.S. I realize that I can accomplish what I want by an appropriate setting of header_filter_rules, but it's not very convenient, since I can't make use of acceptable_aliases. The introduction of header_filter_rules is great, but it creates confusion by making the existing sender and recipient filters redundant. I suggest renaming the section in which header_filter_rules from "spam filters" to "advanced filter" or something like that. All three sections can be used to filter spam, so it's misleading to distinguish a "spam filter" from sender and recipient filters. The documentation for header_filter_rules / "advanced filter" section should explain that this filter is a general mechanism which exists; the sender/recipient filters are special cases that are common enough to merit a convenient interface just for them. Even with this clarification of the header_filter_rules, I still think require_explicit_destination should be expanded to offer all four actions. If you're going to go to the trouble of setting up the special interface to filter a lack of explicit destination, it really ought to offer complete options. It won't complicate the interface (really, it will simplify it to have the familiar four actions offered), and it seems very awkward to have to recreate this nice interface in header_filter_rules (acceptable_aliases and so on) just because the manager wants an action other than "accept" or "hold". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…

1 0