Re: [Asrg] Adding a spam button to MUAs

Douglas Otis <dotis@mail-abuse.org> Wed, 16 December 2009 22:51 UTC

Return-Path: <dotis@mail-abuse.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E1E3A69FB for <asrg@core3.amsl.com>; Wed, 16 Dec 2009 14:51:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.19
X-Spam-Level:
X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiDoNTgrUKcK for <asrg@core3.amsl.com>; Wed, 16 Dec 2009 14:51:20 -0800 (PST)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 9969E3A67AF for <asrg@irtf.org>; Wed, 16 Dec 2009 14:51:20 -0800 (PST)
Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 54CE6A9443C for <asrg@irtf.org>; Wed, 16 Dec 2009 22:51:04 +0000 (UTC)
Message-ID: <4B296458.5070603@mail-abuse.org>
Date: Wed, 16 Dec 2009 14:51:04 -0800
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: asrg@irtf.org
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <20091216014800.GA29103@gsp.org> <DBF77720-200E-4846-949F-924388F9CC15@blighty.com> <20091216120742.GA28622@gsp.org> <20091216185904.3B9032421D@panix5.panix.com>
In-Reply-To: <20091216185904.3B9032421D@panix5.panix.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Adding a spam button to MUAs
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2009 22:51:21 -0000

On 12/16/09 10:59 AM, Seth wrote:

>> There's the zombie problem.  There is no way for anyone or anything
>> external to an end-user's system to know whether the button click
>> (or equivalent event) was generated by a user or by software working
>> at the behest of the new owner of the user's former system.  Given
>> that the zombie problem is epidemic and presently unstoppable,
>> widescale deployment of any such mechanism will lead to its use by
>> zombie-resident malware as soon as it's advantageous for abusers to
>> do so. Thus, anyone proposing such a "report as spam" mechanism on a
>> large scale must also include in their proposal a workable plan for
>> solving the zombie problem.
>
> How would it be advantageous for a zombie to report as spam?  Report
> as non-spam, sure, to game the filters.  But with the data being noisy
> to begin with, zombies adding noise don't have much effect; they might
> require tuning of the filters.

Users without 0wned systems might still attempt to unsubscribe from 
spoofed subscriptions and be asked for passwords they never set, and 
then attempt to guess it anyway. There are also risks related to browser 
vulnerabilities that would be avoided by offering a "this is junk" 
button that invokes an unsubscribe service, even for user who have 
initially confirmed the subscription.

To avoid complaints, a web page associated with an email account could 
allow users a means to confirm their desire to unsubscribe, or just have 
user authentication included in the "this is junk" transaction, which 
might simply mean placement into the "junk" folder.  As such, it would 
be in the interest of list administrators to unsubscribe "unwanted" 
email based upon this feedback.

This feedback should not be confused with "spam" email feedback. 
Recently, new developers within our company confused these two 
categories and caused a number of complaints.  It is important to 
understand the difference between "unwanted" and "spam-trap" as 
determined by the source of the feedback.

Spammers will surely abuse any control mechanism in an effort to cause 
user complaints.  User complaints will cause the mechanism to be 
abandoned as being too expensive.  Users that are 0wned will likely be 
detected with spam-trap feedback, as well as through other mal activity.

Any effort to utilize email feedback MUST understand the difference 
between a general category of "unwanted" and feedback from "spam-traps" 
that are able to differentiate between "auto-responses" and DSNs.

-Doug