GNU bug report logs - #14811
Debbugs <at> spam countermeasure inadequate

Previous Next

Package: debbugs.gnu.org;

Reported by: ua2y-rti1 <at> spamex.com

Date: Sun, 7 Jul 2013 13:50:02 UTC

Severity: normal

Merged with 13194

To reply to this bug, email your comments to 14811 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to help-debbugs <at> gnu.org:
bug#14811; Package debbugs.gnu.org. (Sun, 07 Jul 2013 13:50:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to ua2y-rti1 <at> spamex.com:
New bug report received and forwarded. Copy sent to help-debbugs <at> gnu.org. (Sun, 07 Jul 2013 13:50:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ua2y-rti1 <at> spamex.com
To: submit <at> debbugs.gnu.org
Subject: Debbugs <at> spam countermeasure inadequate
Date: Sun, 07 Jul 2013 09:50:35 -0400
Package: debbugs.gnu.org

On 2013 April 22 I filed an emacs bug using an email address specifically generated for that purpose and used for nothing else.

On 2013 May 18 I started receiving spam messages on that email address.  The most likely explanation is that
an email address harvester is overcoming the <at> countermeasure.





Merged 13194 14811. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Sun, 07 Jul 2013 17:29:02 GMT) Full text and rfc822 format available.

Information forwarded to help-debbugs <at> gnu.org:
bug#14811; Package debbugs.gnu.org. (Mon, 08 Jul 2013 00:28:02 GMT) Full text and rfc822 format available.

Message #10 received at 14811 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: ua2y-rti1 <at> spamex.com
Cc: 14811 <at> debbugs.gnu.org
Subject: Re: bug#14811: Debbugs <at> spam countermeasure inadequate
Date: Sun, 07 Jul 2013 20:27:39 -0400
ua2y-rti1 <at> spamex.com wrote:

> On 2013 April 22 I filed an emacs bug using an email address
> specifically generated for that purpose and used for nothing else.
>
> On 2013 May 18 I started receiving spam messages on that email
> address. The most likely explanation is that an email address
> harvester is overcoming the <at> countermeasure.

I can mainly repeat my comments from

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13194

I'm sympathetic. I don't like spam, and we should certainly not make it
totally trivial to harvest addresses (like bugs.debian.org does), but I
feel that in this day and age everyone has to expect some spam and have
a method for dealing with it. Based on the data I mention in bug#13194,
it feels to me like the simple "at" solution we have in place eliminates
say ~ 99% of the spam (this is a qualitative feeling).

Emacs bug reports appear on several other sites that are not under our
control, and further obscuring debbugs.gnu.org will have zero impact on
them. For example, the gnu.emacs.bugs newsgroup (how I wish it would go
away), and gmane.org, which uses the same <at> mechanism.

So no matter what we do on debbugs.gnu.org, we cannot promise that
reporting an Emacs bug will never lead to you getting a spam email.
Sorry.

If you want to do an experiment, make another totally new address and
use it to send mail to 14811-quiet <at> debbugs.gnu.org. This should not get
sent on to any other site. Then wait and see if that new address gets
spam.

I don't mind tweaking the obscuration method if someone has a
suggestion, but I doubt it will make much difference, for the reasons I
mention above.




Information forwarded to help-debbugs <at> gnu.org:
bug#14811; Package debbugs.gnu.org. (Sat, 20 Jul 2013 00:45:02 GMT) Full text and rfc822 format available.

Message #13 received at 14811 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 14811 <at> debbugs.gnu.org
Cc: ua2y-rti1 <at> spamex.com
Subject: Re: bug#14811: Debbugs <at> spam countermeasure inadequate
Date: Fri, 19 Jul 2013 18:44:08 -0600
Glenn Morris wrote:
> ua2y-rti1 <at> spamex.com wrote:
> > On 2013 April 22 I filed an emacs bug using an email address
> > specifically generated for that purpose and used for nothing else.

I don't see the usefulness of using fingerprinted email addresses when
sending messages out to the world.  Because out of the thousands of
potential readers of the message all it takes is one of them to be
reading the message on a virus infected system.  At that point the
email address is very likely to be used by the spammer driving the
botnet behind the virus.

> > On 2013 May 18 I started receiving spam messages on that email
> > address. The most likely explanation is that an email address
> > harvester is overcoming the <at> countermeasure.

Or that your email was read by someone on a virus infected MS-Windows
computer system and the virus harvested your address.

> I'm sympathetic. I don't like spam, and we should certainly not make it
> totally trivial to harvest addresses (like bugs.debian.org does), but I
> feel that in this day and age everyone has to expect some spam and have
> a method for dealing with it.

I agree.  I wanted to add a few thoughts.

I think it is unreasonable to expect that email may be sent and that
the sender's email address will never be known.  Once you send an
email then there are so many things that can happen to cause the
sending email address to become known.  Like the virus example.  But
that is simply one of many possibilities.  Genies are easy to let out
of the bottle but quite hard to put back in them.

Also it is impossible for a free(dom) software project to operate
without transparency.  And that very transparency requires that email
addresses will be seen somewhere along the way.  It isn't possible to
keep something secret when the very basis of the project is that it is
available to the community to contribute.  Community projects operate
in a public setting.  Anything else would be a completely different
thing.

Someone will suggest going to a very closed web based bug tracking
system.  That has been tried.  But it has its own set of negatives
associated with it.  That is why the email based debbugs is so
attractive.

> Emacs bug reports appear on several other sites that are not under our
> control, and further obscuring debbugs.gnu.org will have zero impact on
> them. For example, the gnu.emacs.bugs newsgroup (how I wish it would go
> away), and gmane.org, which uses the same <at> mechanism.

I also wish the newsgroup gateway would go away.  I really wish it had
never been implemented.

> So no matter what we do on debbugs.gnu.org, we cannot promise that
> reporting an Emacs bug will never lead to you getting a spam email.
> Sorry.

And the same thing for sending to any mailing list under the gnu.org
umbrella.  It just isn't possible.

Bob




Information forwarded to help-debbugs <at> gnu.org:
bug#14811; Package debbugs.gnu.org. (Thu, 25 Jul 2013 16:57:01 GMT) Full text and rfc822 format available.

Message #16 received at 14811 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: ua2y-rti1 <at> spamex.com, 14811 <at> debbugs.gnu.org
Subject: Re: bug#14811: Debbugs <at> spam countermeasure inadequate
Date: Thu, 25 Jul 2013 12:55:55 -0400
I've now fully removed the (non debbugs.gnu.org) email addresses on
the _static_ bug web-pages (eg http://debbugs.gnu.org/db/14/14811.html).
These are the only pages that get indexed by search engines.

BTW, a study that one person did (admittedly, it's 5 years old now)
suggests that methods like " <at> " were >~ 99% effective at the time:

http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/

Personally, I think it still strikes the right balance between
inconveniencing legitimate users and spam harvesters.

I am considering inserting a "debbugs-remove" component (or somesuch) to
all non-debbugs addresses on the dynamic (ie, cgi) bug web pages, but am
not sure it is worth the effort. Those pages are not indexed by search
engines, and they contain links to the mbox files, which I am absolutely
not going to obfuscate.




This bug report was last modified 10 years and 279 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.