Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Wed, 03 February 2010 09:54 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 E74EE28C0F7 for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 01:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.564
X-Spam-Level:
X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, 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 75rRGUL5pb78 for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 01:54:13 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A55503A686D for <asrg@irtf.org>; Wed, 3 Feb 2010 01:54:13 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 03 Feb 2010 10:54:50 +0100 id 00000000005DC03C.000000004B6947EA.0000711C
Message-ID: <4B6947EA.60505@tana.it>
Date: Wed, 03 Feb 2010 10:54:50 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
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> <4B68133A.6040104@tana.it> <4B686886.6010402@nortel.com>
In-Reply-To: <4B686886.6010402@nortel.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: Wed, 03 Feb 2010 09:54:15 -0000

On 02/Feb/10 19:01, Chris Lewis wrote:
> Alessandro Vesely wrote:
>> An ARF received at a domain's "abuse@" mailbox may arrive from an
>> authenticated client, and it won't be DKIM-signed in that case.
>> However, the abusive message being reported may have signatures.
>>
>> Or it may arrive from a third party. A third party presumably rewrites
>> both the boilerplate and the machine-readable parts, and I would
>> expect it DKIM-signs them. An MTA should only receive reports where
>> the Reported-Domain field indicates its own domain. Generic operators
>> may also receive reports that they are supposed to "forward"
>> --possibly rewriting and signing the first two parts in turn.
>
> I was referring on the _client_ trusting the header its front end would
> have inserted to indicate where/how to send a report. If we only add
> these headers at the receiving end, the receiving end zaps all prior
> instances of the TiS header and inserts its own, and the client knows
> that the receiving end inserts this header, then there's only the issue
> of the client roaming somewhere else and getting a forward.

The receiving end does not /have/ to zap prior instances of the same 
field. It filters off any maliciously forged Authentication-Results 
bearing its own authserv-id, but they wouldn't have provided a 
different target anyway. Users who receive considerable traffic 
through a forwarding MTA may wish to enable its authserv-id as well. 
When reporting such a message as spam, a MUA may send multiple copies. 
Semantically, that's fine. However, the last MX should avoid to route 
a second AR to the forwarder, in this case. (See picture in 
http://wiki.asrg.sp.am/wiki/Abuse_Reporting)

> Your above appears to be on the abuse@ mailbox (or whatever) deciding to
> trust the report it got from the client. That's a different affair.

In general, a (trusted) report from a client should reach the 
originating domain, whose operators can make the best use of it, 
assuming they're honest. It seems advisable that clients delegate such 
routing decisions to their servers. The servers, in turn, delegate 
that to some other trusted operator, unless they have specific 
arrangements with the reported domain. I tend to consider this 
indirection a consequence of the MSA/MX design.

>> Perhaps an MTA should verify on its own that an AR is correct. For
>> authenticated clients, it may check its receive log. For reports
>> routed by third parties, it may also verify its own signatures.
>
> That might be an option, but that ties the abuse@ rather more intimately
> and automatically to the MTAs (and their logs etc) than you'd like.
>
> I wouldn't necessarily want the MTA to handle abuse@ reports. Eg: you
> have multiple MTAs. You want a central report point, and let _it_ know
> how to propagate the choices it's going to make, and don't insist that
> it necessarily has logs (or logs timely enough) to do real-time
> verifies. Best not to design it with that much close-coupling _not_
> required.

I agree we must not specify how to do verifications. It may be a 
custom local filter, as it supposedly knows where to find the logs or 
whatever it needs. It may even be possible to filter ARF messages in 
transit through an MSA, such as at the last MX case above: the trust 
that the user has conferred can be acknowledged by filling, say, the 
Reporting-MTA field.

As for tying an MTA to abuse reports handling, I think it is the most 
convenient choice. The kind of spam that we may be able to control by 
properly routing ARs does not require the immediateness of HTTP.