Re: [Asrg] Spam button scenarios

Ian Eiloart <> Mon, 08 February 2010 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A5753A73D8 for <>; Mon, 8 Feb 2010 06:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CR74FSLC6aSH for <>; Mon, 8 Feb 2010 06:18:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DBC6A3A73B9 for <>; Mon, 8 Feb 2010 06:18:51 -0800 (PST)
Received: from ([]:57379) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXJ153-0004CZ-6Z for; Mon, 08 Feb 2010 14:19:51 +0000
Date: Mon, 08 Feb 2010 14:19:51 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <alpine.BSF.2.00.1002080111310.16135@simone.lan> <>
Originator-Info: login-token=Mulberry:01ZBY1IM13o4Wlg4mC0DzXi6iTyo5Wesc82YE=;
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 14:18:53 -0000

--On 8 February 2010 07:59:50 -0500 Daniel Feenberg <> 

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

It's a different case. We're sending email to an address at that MTA, and 
drawing attention to it.

The main problem here, though, is that the user thinks they're reporting 
spam, but in fact they're generating it.

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

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