Mailman-coders December 2005

mailman-coders@python.org

1 participants
27 discussions

[ mailman-Feature Requests-1394592 ] Allow any registered member to be a moderator

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Patches-933757 ] fix for [815297] signatures break

by SourceForge.net

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…

15 years, 5 months

[ mailman-Bugs-1390018 ] HTML attachment escaped in archive

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Bugs-1388778 ] /templates/fr/archtocentry.html typo

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387349 ] clarify when regexps are case-sensitive

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387324 ] document order in which message filters are applied

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination

by SourceForge.net

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_…

15 years, 5 months

[ mailman-Feature Requests-1387243 ] option to discard messages that lack explicit destination

by SourceForge.net

Feature Requests item #1387243, was opened at 2005-12-21 11:01 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=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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1387243&group_…

15 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders December 2005