Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Thu, 10 December 2009 18:25 UTC

Return-Path: <vesely@tana.it>
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 73C903A6850 for <asrg@core3.amsl.com>; Thu, 10 Dec 2009 10:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.587
X-Spam-Level:
X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, 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 GUMlOGifwGbE for <asrg@core3.amsl.com>; Thu, 10 Dec 2009 10:25:55 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E388C3A6A2B for <asrg@irtf.org>; Thu, 10 Dec 2009 10:25:54 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 10 Dec 2009 19:25:42 +0100 id 00000000005DC02F.000000004B213D26.00001313
Message-ID: <4B213D26.2040903@tana.it>
Date: Thu, 10 Dec 2009 19:25:42 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20091209202807.81190.qmail@simone.iecc.com>
In-Reply-To: <20091209202807.81190.qmail@simone.iecc.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Thu, 10 Dec 2009 18:25:56 -0000

>> If the mail is forwarded at the user's request (e.g. college alumni 
>> forwarding-only addresses), then the server to report it to is the one 
>> that received it from outside the user's forwarding chain.

The concept of _server responsible for accepting a message_ is what we 
  should use here. There may be multiple ones. How to validate them, 
etcetera, may be defined afterwards (that's the stance of RFC 5451.)

> The web mail systems haven't solved that problem, so I don't think we
> need to, either.  Any forwarder of any size has FBLs set up, so it will
> get reports about forwarded mail via the target system.  That works OK
> for me.

Not all forwarding targets provide for a FBL. Web mail and FBLs are 
local arrangements that can hardly be standardized so that they scale 
well to any mail system. I don't see many European FBLs, for example...

> Short of a mythical global reputation system, I don't see how one could
> divert reports to forwarders without also diverting them to spammers who
> pretend to be forwarders.

I thought such _mythical global reputation system_ is what we are 
researching right now. IMHO there is a necessary relationship between 
abuse reports and MGRSs: V can meaningfully vouch for X only if V can 
monitor _all_ ARs originating from mail emitted by X. (see "A Vouch By 
Feedback proposal" 
http://www.ietf.org/mail-archive/web/asrg/current/msg15679.html)

Even a user-trusted authserv-id validated against Received lines can 
be used to divert ARs: for example Alice may configure X as a trusted 
server, but mail to Alice@Y with forged Authentication-Results and 
Received header fields may still fool her MUA. While this may not be a 
problem now, as Steve said, it feels safer to be able to avoid it, 
just in case it will.