Re: [Asrg] Iteration #3.

Steve Atkins <steve@blighty.com> Fri, 05 February 2010 19:28 UTC

Return-Path: <steve@blighty.com>
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 9E2813A6DE6 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level:
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 b0KJfgZDsDIq for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:28:52 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id C09873A69F7 for <asrg@irtf.org>; Fri, 5 Feb 2010 11:28:52 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 57A974F856E for <asrg@irtf.org>; Fri, 5 Feb 2010 11:29:44 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <steve@blighty.com>
In-Reply-To: <4B6C6D35.1050101@nortel.com>
Date: Fri, 05 Feb 2010 11:29:43 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <505F1889-5D8B-4B96-BD2D-1F2B40605C20@blighty.com>
References: <4B6C6D35.1050101@nortel.com>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [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:28:53 -0000

On Feb 5, 2010, at 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".  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.

+1 for "MUA sends a report in ARF format to <some address>"

What that address should be, and how the MUA should discover it without manual configuration, is the interesting bit.

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

-1.

It's a can of worms buried in a rathole behind a bikeshed that needs painting.

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

Cheers,
  Steve