[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Spam in the bug tracker
David De La Harpe Golden
Re: Spam in the bug tracker
Sat, 09 May 2009 00:31:40 +0100
Mozilla-Thunderbird 18.104.22.168 (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
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.