Dan Astoorian wrote:
Personally, I'm of the opinion that it's wrong ever to use a reject rule for spam filtering in the first place, since so much spam has forged sender information anyway, but debating that is well beyond the scope of how this bug should be fixed.
I think we all agree that 'spam' should be discarded or maybe held for examination by a human, but never rejected.
The problem I see is that while header_filter_rules are in the Spam filters section of the admin interface and enforced by a module named SpamDetect, they can actually be used in other ways to reject messages which are not 'spam' per se.
However, I agree with Mark that discarding instead of rejecting feels wrong.
Would checking the x-beenthere: headers to avoid the loop not be a far cleaner solution, or is there some reason I've overlooked why that wouldn't work?
X-Been-There: won't work because it's never added in messages to -owner.
Perhaps we could test if msg.get_sender() == mlist.GetOwnerEmail(), and discard in that case only, but I'd want a somewhat different test in case the sender's domain were not identical - something like
if msg.get_sender().split('@')[0] == \
mlist.GetOwnerEmail().split('@')[0]:-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan