Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <> Thu, 10 December 2009 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73C903A6850 for <>; Thu, 10 Dec 2009 10:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.587
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GUMlOGifwGbE for <>; Thu, 10 Dec 2009 10:25:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E388C3A6A2B for <>; Thu, 10 Dec 2009 10:25:54 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by with esmtp; Thu, 10 Dec 2009 19:25:42 +0100 id 00000000005DC02F.000000004B213D26.00001313
Message-ID: <>
Date: Thu, 10 Dec 2009 19:25:42 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Adding a spam button to MUAs
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: 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"

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.