Re: [Asrg] Spam button scenarios

Ian Eiloart <> Mon, 08 February 2010 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80AFA3A738F for <>; Mon, 8 Feb 2010 05:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id agv47xJ0jubp for <>; Mon, 8 Feb 2010 05:02:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 585F13A7398 for <>; Mon, 8 Feb 2010 05:02:10 -0800 (PST)
Received: from ([]:52867) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXIXLC-000D3T-4W for; Mon, 08 Feb 2010 13:03:12 +0000
Date: Mon, 08 Feb 2010 13:03:12 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <alpine.BSF.2.00.1002080111310.16135@simone.lan>
References: <alpine.BSF.2.00.1002080111310.16135@simone.lan>
Originator-Info: login-token=Mulberry:01gDUUsemWghbBomgT7Fvzqock5q01C+Nb9aA=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] Spam button scenarios
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: Mon, 08 Feb 2010 13:02:11 -0000

--On 8 February 2010 01:28:59 -0500 "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.

Snooping might well be an issue, for example, it might be a false positive 
where the actual message contains confidential information. The reporter is 
using a system that supposedly communicates with their service provider. 
Reporting a message to the mailstore operator (who can already read it from 
the mailstore) is a lot less sensitive than forwarding it to the operator 
of a third party mailstore.

What else might we care about? That we're failing to actually report the 
message? That we're spamming the unrelated third party? That the unrelated 
third party's automatic processor might generate an onward report about an 
unrelated message?

> 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?

We don't care as much. The message is already visible to the operator of 
the second mailstore.

>  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.
> 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

This is already a problem with simple forwarding. I get ARF reports from 
AOL for messages that originated elsewhere, but were forwarded by my SMTP 

The answer, I think, is that the report should go to Gmail, and they should 
forward the report to Yahoo if they're sure of the origin of the mail. If 
they're fetching it using POP or IMAP, that's the case. Otherwise some kind 
of feedback loop is required (or SPF or DKIM matches).

> R's,
> John
> _______________________________________________
> Asrg mailing list

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see