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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
