Re: [Asrg] Spam button scenarios

Daniel Feenberg <feenberg@nber.org> Mon, 08 February 2010 13:00 UTC

Return-Path: <feenberg@nber.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 407273A71D5 for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 05:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.379
X-Spam-Level:
X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, UNPARSEABLE_RELAY=0.001]
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 zsHMB5ig1zcb for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 05:00:17 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 5B05E3A71BC for <asrg@irtf.org>; Mon, 8 Feb 2010 05:00:17 -0800 (PST)
Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.3/8.13.8) with ESMTP id o18D1Dev014417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Feb 2010 08:01:14 -0500 (EST) (envelope-from feenberg@nber.org)
Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id o18CxqAp021812; Mon, 8 Feb 2010 07:59:52 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o18CxpZc021809; Mon, 8 Feb 2010 07:59:52 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Mon, 8 Feb 2010 07:59:50 -0500 (EST)
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <alpine.BSF.2.00.1002080111310.16135@simone.lan>
Message-ID: <Pine.GSO.4.64.1002080753250.17361@nber6.nber.org>
References: <alpine.BSF.2.00.1002080111310.16135@simone.lan>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20100207 #3447574, check: 20100208 clean
Subject: Re: [Asrg] Spam button scenarios
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: Mon, 08 Feb 2010 13:00:18 -0000

On Mon, 8 Feb 2010, John R. Levine wrote:

> Here's some scenarios in which I'm not sure what the best thing is to do.
>
> A) User has multiple incoming accounts, presses the spam button, and the 
> outbound MSA doesn't match the incoming account.  Hence the report goes via 
> unrelated third parties that might snoop on it.  Do we care?  The user has 
> said it's spam, after all.
>

The user trusts his good outgoing mail to that MTA - why should she not 
trust her spam to the same MTA?

> B) Assume a model in which the spam reporting address is determined per 
> account, e.g., fetched from the POP or IMAP server via an extension.  The 
> user for whatever reason moves a message from account A into the IMAP mailbox 
> for account B and then hits the spam button, which sends the report to B, 
> even though the message was from A.  Do we care?  It's the user's fault, 
> although I can think of some simple configurations that would cause that, 
> e.g., MUA based spam filter that puts all the junk into the Junk folder on 
> the first IMAP account.
>

The ARF system at the MTA may examine the headers to make sure the report 
came through it or it has the potential to process ARF reports possibly 
intended for another MTA. Howeever, this is not a serious mistake, if it 
is one at all. If MTA A revises its content filter based on what it learns 
from a spam sent through MTA B, then no harm has been done.

> C) I have a Gmail account and a Yahoo account.  The Gmail account is set up 
> to fetch my Yahoo mail so I can see it all in one place.  I use Gmail's IMAP 
> server to read my mail.  (I really do this, by the way.)  I hit the spam 
> button.  Who should get the report?
>
> 1) Gmail since that's who I picked it up from
> 2) Yahoo since that's where the spam was sent
> 3) Gmail but they should also forward the report to Yahoo
>

GMAIL is your MUA. It should report to Yahoo, but I don't see any harm in 
it acting on the information itself. Lots of MUAs have built in spam 
filters - it is perfectly reasonable that the TIS button help those 
filters.

Daniel Feenberg