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