Re: [Asrg] Adding a spam button to MUAs

Nathaniel Borenstein <> Wed, 16 December 2009 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98A4E3A6A9C for <>; Wed, 16 Dec 2009 15:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.584
X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uhz4G07bUGwM for <>; Wed, 16 Dec 2009 15:21:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5A27D3A6A94 for <>; Wed, 16 Dec 2009 15:21:14 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1NL3BB-00035Q-Nx for; Wed, 16 Dec 2009 18:21:13 -0500
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <> <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
From: Nathaniel Borenstein <>
Date: Wed, 16 Dec 2009 18:20:56 -0500
To: Anti-Spam Research Group - IRTF <>
X-Mailer: Apple Mail (2.1077)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2009 23:21:15 -0000

I've tried hard to resist chiming in on this, but can't help myself.

I suggest that the issue of defining or identifying spam is a red herring and a huge distraction from actual progress.  The real issue is identifying mail that a specific user does not want.  When defined this way, it subsumes the spam problem, but it also maps more directly onto the user's action with a spam/junk button.  In this view, if a user clicks the spam/junk button for messages that we email gurus don't consider "spam," that's just fine -- each user is the expert in defining "junk" for their own mailbox.

As volumes continue to increase, I believe email streams need to be viewed more like intelligent news feeds -- we need to use sophisticated per-user information to choose which items to pass on to the user and which to block.  The spam/junk button can be very useful input to that process.  But there's more to it than that -- once we start doing our spam filtering with individual recipients in mind, we can do a lot of things right that we can't now.  For example, after twenty years of using spam filters, I still get spam in Chinese or Russian, languages I don't understand at all, because the spam filters know nothing about me as an individual.  Similarly, I'm sure that plenty of people in China get spam in English that seems obviously irrelevant to them.  This drives me nuts, because it would be so easy to fix if our filtering was done with even a minimal knowledge about the individual recipient.

In short, the real need is for user-focused email filtering to subsume our current notion of spam filtering.  Viewed that way, I think a spam/junk button would be an obvious win.   But it should be part of a broader interface (yes, an authenticated one, most likely) by which individuals could interact with their email filters, e.g. to say which languages they do and don't understand, or even which topics they were and weren't interested in receiving unsolicited messages about.  (Who knows, maybe there's even someone out there who doesn't want most spam but is desperate to enlarge the size of their private body parts; shouldn't they be able to communicate that fact to their filters?)  -- Nathaniel

On Dec 16, 2009, at 5:51 PM, Douglas Otis wrote:

> 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
> _______________________________________________
> Asrg mailing list