[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spam in the bug tracker

From: David De La Harpe Golden
Subject: Re: Spam in the bug tracker
Date: Sat, 09 May 2009 00:31:40 +0100
User-agent: Mozilla-Thunderbird (X11/20090103)

[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).


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]