Bug#348592: [Pkg-mailman-hackers] Bug#348592: mailman: Spam causes a moderation loop

[Christoph Haas]

On Wednesday 18 January 2006 23:06, Lionel Elie Mamane wrote:
> Thank you for your bug report. We cannot fix this in sarge, as sarge
> is already released and only security / critical bugfixes are accepted
> into point releases.

Yes, of course. You may consider leaving this bug report open though so 
other users of the mailman package in Sarge know there is a problem. 
(Perhaps give it a 'sarge' tag.) Unfortunately a couple of users seemed to 
have encountered this phenomenon but there wasn't yet a fix.

> I'll integrate this in my upload of Mailman 2.1.7.

Good idea. 2.1.8 seems to be containing this fix already. So there's time 
until the release of Etch. :)

> > --- SpamDetect.py.orig  2006-01-16 14:05:42.000000000 +0100
> > +++ SpamDetect.py       2006-01-16 14:05:18.000000000 +0100
> > @@ -103,6 +103,15 @@
> >          if mo:
> >              # we've detected spam, so throw the message away
> >              raise SpamDetected
> > +    # Before we go to header_filter_rules, we exclude internally
> > generated +    # owner notification from checking, because 1) we
> > collect headers from +    # all the attachments but this will cause
> > matching the filter rule again, +    # and 2) list owners may want to
> > check header name / value pair like +    # 'Precedence: bulk' which is
> > also generated by mailman.  Both will +    # cause loop of holding
> > owner notification messages if the action is +    # set to 'hold'.
> > +    if msgdata.get('toowner') and msg.get('x-list-administrivia') ==
> > 'yes': +        return
>
> Ugh, so all a spam has to do is to put an "x-list-administrivia: yes"
> header to get past the rules?

That's indeed scary. I don't claim to understand all portions of the 
upstream's patch. Perhaps other parts of the patch deal with that.

Kindly
 Christoph