[Tracker-discuss] [issue105] Dealing with spam
Martin v. Löwis
metatracker at psf.upfronthosting.co.za
Sun Mar 25 10:29:16 CEST 2007
Martin v. Löwis added the comment:
> However, I do not want this to be a blocker issue delaying the transition too
> long. Therefore, I suggest that we apply loewis "4 second form generation" patch
> (very interesting and simple idea, btw) now, and set the priority of this issue
> to 'feature', which means that we no longer consider it a blocker, but rather
> something that should be done as soon as possible to fight spam in a way that
> works even if the spambots start to fill forms slowly.. :-)
That's fine with me. I felt the need for immediate action, but I do hope
that this solution will already catch many spam attempts. Dealing with
the rest manually should be fine for now (altough history tells me that
we have to wait some time to see *how* effective it is - before, I would
have thought that the registration requirement already locks out
> I've applied the "4 second delay" patch to http://bugs.python.org and restarted
> roundup. I've also retired the existing spam issues which means they will not
> appear on the frontpage nor in searches (but can be accessed via direct URL).
> This I did using the commandline tool.
Thanks. When we get email notification to work, the question is how to
deal with spam then: every message sent to, say, python-bugs-list, will
be archived in a mailman archive, which has no support for cleaning out
So it must not hit the list in the first place - either because there
is also a SpamBayes filter on the list, or because roundup won't
mail-notify the mailing list unless they are classified ham.
OTOH, there is plenty of archived spam on mailman archives all over
the world, so its perhaps acceptable to add a little to it.
Meta Tracker <metatracker at psf.upfronthosting.co.za>
More information about the Tracker-discuss