[Asrg] Iteration #3.

"Chris Lewis" <clewis@nortel.com> Fri, 05 February 2010 19:10 UTC

Return-Path: <CLEWIS@nortel.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 452CE3A6DC0 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:10:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.505
X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id c1AOyMKXFBw4 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:10:15 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com []) by core3.amsl.com (Postfix) with ESMTP id 1D94A3A6DC7 for <asrg@ietf.org>; Fri, 5 Feb 2010 11:10:14 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com []) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15JAxl19451 for <asrg@ietf.org>; Fri, 5 Feb 2010 19:10:59 GMT
Received: from zrtphx5h0.corp.nortel.com ([]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 14:10:57 -0500
Received: from [] ( by zrtphx5h0.corp.nortel.com ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 5 Feb 2010 14:10:57 -0500
Message-ID: <4B6C6D35.1050101@nortel.com>
Date: Fri, 5 Feb 2010 14:10:45 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: ASRG <asrg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Feb 2010 19:10:57.0496 (UTC) FILETIME=[F25CE580:01CAA696]
Subject: [Asrg] Iteration #3.
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: Fri, 05 Feb 2010 19:10:16 -0000

We've more-or-less reset the discussion to emailing ARF reports (most 
people are satisfied with emailed ARF reports without other options)..

I think we need to reset it again, yet further.  The reason being that 
the discussion touches too many pieces at once, and the 
security/practicality issues of remotely-specified ARF destinations are 
obscuring the fact that why bother with specifying them at all?  Let the 
user's ARF handling service do it.  We need to very specifically 
disentangle MUA/MTA functions and simplify yet again.

So we get rid of inband abuse report instructions altogether.

I propose two specifications:

1) a spec for MUAs that says nothing more than "if the TiS button is 
pushed, the selected email[s] get sent in ARF format to <some standard 
address>, via the usual mail submission methods it uses".  I recommend, 
so as to not stomp/overload existing naming conventions, that it be 
"arf@arf.<domain in the RCPT TO that reached the user>".  Or, "ar", or 
whatever.  I don't care what it is (if you really don't want to use 
"arf") as long as it doesn't collide with existing conventions and 
standards.  Eg: IMAP/POP/SMTP/SPAM et. al. are unacceptable.

This also allows <domain> to use DNS to map them to somewhere else entirely.


2) a followon spec that specifies what goes on at arf@arf.<domain>" in 
terms of remote report forwarding (if any).  Rather than relying on 
inband ARF destination signalling, I think we should consider doing 
something with DNS ala SPF/SenderID and DKIM.

Astute readers will notice that (1) is a trivially simple MUA hack, and 
that (2) isn't necessary for many installations wanting TiS info (for 
filter tuning) and don't forward them anywhere.