Re: [Asrg] Iteration #3.

Steve Atkins <> Fri, 05 February 2010 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E2813A6DE6 for <>; Fri, 5 Feb 2010 11:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.521
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b0KJfgZDsDIq for <>; Fri, 5 Feb 2010 11:28:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C09873A69F7 for <>; Fri, 5 Feb 2010 11:28:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 57A974F856E for <>; 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 <>
In-Reply-To: <>
Date: Fri, 5 Feb 2010 11:29:43 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Anti-Spam Research Group - IRTF <>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [Asrg] Iteration #3.
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: 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.


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.