Re: [Asrg] Iteration #3.

Dave CROCKER <dhc@dcrocker.net> Fri, 05 February 2010 19:22 UTC

Return-Path: <dhc@dcrocker.net>
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 F27463A68E8 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 dhP+mtey2poh for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:22:01 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id F138C28C117 for <asrg@irtf.org>; Fri, 5 Feb 2010 11:22:00 -0800 (PST)
Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o15JMk26019531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <asrg@irtf.org>; Fri, 5 Feb 2010 11:22:52 -0800
Message-ID: <4B6C7000.5060207@dcrocker.net>
Date: Fri, 05 Feb 2010 11:22:40 -0800
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4B6C6D35.1050101@nortel.com>
In-Reply-To: <4B6C6D35.1050101@nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10361/Fri Feb 5 08:44:47 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Feb 2010 11:22:52 -0800 (PST)
Subject: Re: [Asrg] Iteration #3.
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net, 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:22:02 -0000

On 2/5/2010 11:10 AM, Chris Lewis wrote:
> 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".

+1

This greatly simplifies the model and the specification details.  At that, there 
is still plenty to debate.  (I'm not going into the details of what I happen to 
this is the 'plenty' because the higher-level concern is creating a simplified, 
focused effort.)


> 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.

+ 0.5.

I suspect this will be much more difficult to work on, because I suspect there 
is far less de facto industry consensus on the topic.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net