Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <iane@sussex.ac.uk> Wed, 03 February 2010 13:09 UTC

Return-Path: <iane@sussex.ac.uk>
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 CCD923A68A7 for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 05:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, 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 C1SlvGHEL7fE for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 05:09:23 -0800 (PST)
Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id C8EDE3A685A for <asrg@irtf.org>; Wed, 3 Feb 2010 05:09:21 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:56103) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KX9OK6-000I2G-E5 for asrg@irtf.org; Wed, 03 Feb 2010 13:09:42 +0000
Date: Wed, 03 Feb 2010 13:09:41 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <6ED765A6FA316CD5CB3ABAF9@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <e0c581531002021629r1c54c2bdy8d550c410497f677@mail.gmail.com>
References: <20100201145903.30670.qmail@simone.iecc.com> <3741B85B916D847C703F2724@lewes.staff.uscs.susx.ac.uk> <A50C736E-EE14-4213-B99D-DD58C669FDAC@blighty.com> <100201092326.ZM5487@torch.brasslantern.com> <4B67ADC2.4080204@nortel.com> <1265090468.19504.22.camel@darkstar.netcore.co.in> <e0c581531002021629r1c54c2bdy8d550c410497f677@mail.gmail.com>
Originator-Info: login-token=Mulberry:01cEhTH9mpwYSxtaeB3G7jvcaS1sB0edNu5bM=; token_authority=support@its.sussex.ac.uk
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] 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, 03 Feb 2010 13:09:24 -0000

--On 2 February 2010 18:29:45 -0600 Al Iverson <aiverson@spamresource.com> 
wrote:

> On Tue, Feb 2, 2010 at 12:01 AM, ram <ram@netcore.co.in> wrote:
>
>> The MUA must also have proper time outs so as to cut-off malicious fbl
>> urls
>
> And any sort of FBL-via-MUA process should be opt-in, as well.
> Checking only for a signature means bad guys signing mail can direct
> where the feedback goes when you hit "this is spam." That data could
> be misused to confirm email addresses, telling a spammer "we got a
> live one" and making the email address worth selling.
>
> Come to think of it, I don't think this should be core MUA
> functionality. Even though I work for an ESP and would want the
> feedback, I see too much opportunity for abuse. I'd rather see
> third-party "report spam" plugins wherein that third party can make
> the determination on where and whether or not to route a report. If
> that third party doesn't trust or know about the sender, a report
> would hopefully not be sent.
>

This is one reason to support an IMAP extension. If the communication is 
between the authenticated user and the IMAP server, then there doesn't seem 
to be room for abuse of the abuse reporting mechanism.

Granted, if the client machine is compromised then all bets are off.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/