Re: [marf] Gen-ART review: draft-ietf-marf-as-13

Alessandro Vesely <vesely@tana.it> Tue, 17 April 2012 12:32 UTC

Return-Path: <vesely@tana.it>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8069D21F855F for <marf@ietfa.amsl.com>; Tue, 17 Apr 2012 05:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV-hHbHOX6Ih for <marf@ietfa.amsl.com>; Tue, 17 Apr 2012 05:32:03 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CFE9121F84D3 for <marf@ietf.org>; Tue, 17 Apr 2012 05:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1334665921; bh=B6rx7Sl7HzZUSXJeWLWXMn/0LFzSwS96IAm2eev31HM=; l=2082; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=ItfeXJoXP/MLNcfcL7R0TVYqZ4NJ77aBQejC8axsTQYSMeiDD4ljN58kJqZx1DVjh chenDLPeyF8VfcJZPyJN3cmRJLuOHtKZohDtvk5ylIpmyG1DEL+KExLF845x3y15sj wSMYRqLWCJs3ioVP8764eo8xzPuw/PXrRuHQSqAY=
Received: from [192.168.8.53] (bob75-8-88-169-117-39.fbx.proxad.net [88.169.117.39]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 17 Apr 2012 14:31:59 +0200 id 00000000005DC045.000000004F8D62C0.00007F9C
Message-ID: <4F8D62BC.5060908@tana.it>
Date: Tue, 17 Apr 2012 14:31:56 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnXEnqmOcszw4KcXOcs_Z-C+zwhtC2tpdr73YQqjQmX3ZQ@mail.gmail.com> <9452079D1A51524AA5749AD23E0039280F0958@exch-mbx901.corp.cloudmark.com> <CABkgnnVW4gk51__4gTR_C9eJG5OpaN4PiDr7Rj+tw=bonqgJ_A@mail.gmail.com>
In-Reply-To: <CABkgnnVW4gk51__4gTR_C9eJG5OpaN4PiDr7Rj+tw=bonqgJ_A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "marf@ietf.org" <marf@ietf.org>
Subject: Re: [marf] Gen-ART review: draft-ietf-marf-as-13
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 12:32:07 -0000

(apologies for possibly double post)
On Tue 17/Apr/2012 08:03:07 +0200 Martin Thomson wrote:
> On 13 April 2012 12:14, Murray S. Kucherawy <msk@cloudmark.com> wrote:
>>> Section 6.1, point 1 cannot be an interoperability requirement if there
>>> isn't a mechanism provided.
>> Existing implementations generally support this capability, but they all
>> have different ways of doing so.  Thus, there's (currently) no standard
>> way to do it.  Our ADs thus suggested the text that's there.
> 
> It's the unsolicited case that bothers me here.  Is there some sort of
> general advice that can be given on how to implement this for an
> unsolicited report? Or are these existing implementations so radically
> different that is tricky?  (That would be interesting in and of
> itself.)

One possibility for an FBL shop is to have the human-readable part of an ARF
report point to a web site that allows some auto-authentication, e.g. based
on the URL itself but possibly complemented with the IP address of the
client, assuming the visit may come from a company network.  That way,
Mailbox Providers can check that someone looked at the report, and illustrate
the capabilities of their FBL shop.

For 6.1/1 in particular, the report-sender could check 5XX reply codes and
suspend sending for YY time, where the values of XX and YY were acquired at
its interactive FBL shop.  In general, the relationship between the ESP and
the MP will turn into a sort of private agreement, more or less as described
in RFC 6449 --except that the ESP gets a prompt to sign up in the form of an
unsolicited report.

This seems to be a slowly emerging pattern.  Other bits related to 6.3/3 are
being put in place.  See e.g.,
http://www.ripe.net/ripe/policies/proposals/2011-06

Note that RIRs don't have the same standardizing power as the IETF.  This AS
thus plays a role in that framework, allowing that reporting pattern to
emerge a little bit more.  An emerged FBL pattern means experience which, in
turn, is needed before complete details can be fully standardized.

Hth