Re: Spam in the bug tracker

[David De La Harpe Golden]

[Getting kind of OT for emacs-devel I guess, and likely old hat to Don 
Armstrong &co., but just in case]:

Mikko Huhtala wrote:
> Samuel Bronson writes:
>
>  > We need to come up with a way to get rid of the spam before it hits
>  > the tracker without causing anyone too much work.
>
> Maybe require the messages sent by report-emacs-bug to be confirmed by
> replying to a 'did you send this' question from the tracker?

Well, only questioning messages tagged probable-spam by spamassasin (or 
whatever). In the modern era such challenge-response systems can 
themselves potentially be abused for their backscatter possibilities 
with fake from addresses though.

*** what RT land does:

Anyway, over in RT land, probable-spams are typically diverted into a 
"spam" RT queue with enough data about where they would have gone if 
they hadn't been tagged so that a probable-spam can be moved to a real 
RT queue if it's a false positive (either manually detected or via 
aforementioned challenge-response).

http://www.soundwave.net/~wmono/rt/
http://wiki.bestpractical.com/view/SpamFiltering

I don't see why something similar couldn't be done in the debbugs case, 
apart from needing someone who deeply understands debbugs internals to 
actually implement it... if it's not there already, which it might be...

Due to some very basic design differences in debbugs vs. RT (the latter 
being what I'm really familiar with), I'm having a slightly difficult 
time imagining how best to implement it for debbugs, something Don has 
probably thought about a lot more, but here's my blowhard take on it:

Way I see it, there are three main cases - (using "spamassassin" to mean 
"spamassassin or whatever", and assuming mails incoming to the tracker
are passed through said "spamassassin or whatever" and are thereby
tagged with the usual this-looks-like-spam headers):

*** 1. spam that would open new bugs:

That's relatively easy. Go ahead and open the bug, but auto-reassign to 
a package "spam" based on the spamassassin headers.  Someone needs to 
check that package every so often for false positives to be reassigned 
to real emacs package, and closing definite-spam bugs.

*** 2. spam that's going to existing bugs:

Maybe giving every single debbugs bug two "micro mailing lists" instead 
of just one would in fact be the best approach, though extravagant 
looking on the surface, the micro mailing lists are obviously not that 
heavyweight given there's a new one for every bug anyway...

 i.e. address@hidden and address@hidden 
mail sent to the former being diverted to the latter if it looks like 
spam to spamassassin. Then a "rescue this mail from the per-bug 
spambucket" becomes a relatively easy op to implement, just a forward, 
and people owning each individual bug can take responsibility for 
checking their bug's per-bug spambucket for spam once in a while.  The 
spambucket micro mailing list could presumably have a different cc list 
to the main bug micro mailing list to avoid echoing suspected spam to 
every subscriber to the bug. Could perhaps do the 
challenge-response-auto-rescue thing since could also have a different 
autoreply for the diverted mails.

*** 3. spam that closes/mangles bugs, eek:

There's an additional issue of control messages in the debbugs case 
(i.e. spammers were closing emacs bugs) - was that resolved?  requiring 
gpg signed control messages seems a fairly obvious solution there, at 
least if emacs devs are willing to gpg sign control messages. Which is a 
one-click-or-less op in modern muas. Chances of spammers bothering to 
gpg-sign mails are slim. I guess they'll eventually start doing so (most 
likely using victim's gpg keys and keylogged passphrases found from 
infiltrated hosts), but then you just limit to good gpg identities.