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

[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_id=103

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_id=103