option to discard messages that lack explicit destination

Bug #266812 reported by Msswift
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
New
Medium
Unassigned

Bug Description

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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1387243&group_id=103&atid=350103]

Revision history for this message
Msswift (msswift) wrote :

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".

Revision history for this message
Mark Sapiro (msapiro) wrote :

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.

Revision history for this message
Mark Sapiro (msapiro) wrote :

While we're at it, we probably should also add hold, reject
and discard choices if max_num_recipients is > 0

Revision history for this message
Tpv (tpv) wrote :

Originator: NO

This RFE is becoming a significant issue for some lists that I run. What
can be done to get this fixed?
Would a patch help, or is there some specific piece of work that you want
to bundle it up with?

I'm happy to put together a patch (although my python is a little rusty)
but I don't want to waste everyone's time if you want it done a specific
way.

Revision history for this message
Tom Helner (duffman) wrote :

Having hold, reject and discard choices for max_num_recipients and require_explicit_destination would be a HUGE help in the lists I manage. Unfortunately, I see this bug has been open since 2005s so I am not holding my breath.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.