Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05

Scott Kitterman <sklist@kitterman.com> Mon, 06 February 2012 11:57 UTC

Return-Path: <sklist@kitterman.com>
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 B872121F8633 for <marf@ietfa.amsl.com>; Mon, 6 Feb 2012 03:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599]
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 N7RAPQqCeDrF for <marf@ietfa.amsl.com>; Mon, 6 Feb 2012 03:57:16 -0800 (PST)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1030D21F8609 for <MARF@ietf.org>; Mon, 6 Feb 2012 03:57:15 -0800 (PST)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0C96620E4126; Mon, 6 Feb 2012 06:57:15 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328529435; bh=PR6wKXeqNBpOvhpWCKr5E79GZG5twB1tN9oMdolj9tQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=a5fVV3HNBMezzRNFZmPV+b3CMIj0oJ6Yc185jlwPljoZ7uQwEqjhpl4cnq1hn5r0v 6En+/pgrfXsSnW14IyQn4wnvsXUrBL7kgSI/ETDGi5xQWQF9a0AfZeTvhY1LHyDYb3 iijAfuOX5Fzj9UwtB8xXey4/ve8fp3GrfWfvFubc=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E1A6420E408E; Mon, 6 Feb 2012 06:57:14 -0500 (EST)
From: Scott Kitterman <sklist@kitterman.com>
To: Message Abuse Report Format working group <MARF@ietf.org>
Date: Mon, 06 Feb 2012 06:57:13 -0500
Message-ID: <6781615.bvN8lPaFUn@scott-latitude-e6320>
User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; )
In-Reply-To: <CAC4RtVC2aZHGwA7TQnShTq3Gkj2zk19rDHqdcG+R7+w=MPUdLQ@mail.gmail.com>
References: <F5833273385BB34F99288B3648C4F06F19C9A7DBCE@EXCH-C2.corp.cloudmark.com> <a02b052d-bd63-4df3-9973-fa26be7b57a7@email.android.com> <CAC4RtVC2aZHGwA7TQnShTq3Gkj2zk19rDHqdcG+R7+w=MPUdLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05
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: Mon, 06 Feb 2012 11:57:16 -0000

On Sunday, February 05, 2012 02:31:14 PM Barry Leiba wrote:
> > Why the AS draft? There are tons of non-spam auth failures. These are
> often the most interesting ones.
> 
> > If this belongs in the AS draft then it's probably misnamed.
> 
> I'm confused by both of the last two sentences... I don't see the
> antecedents to "these", "this", and "it's".

These are auth failure arfs.  This is the text from the DKIM and SPF drafts 
being proposed be consolidated into the AS draft and it's is the AS draft.

> As to "Why the AS [document]?", It's because that document is an
> "applicability statement" for the work being done with MARF.  An AS is a
> standards-track document that describes how to use the underlying protocols
> (as opposed to a TS (technical specification), which defines the
> protocol(s)).  Part of using the protocols involves dealing with feedback
> loops, reporting, failures, ans so on.
> 
> We decided to split certain details off into separate documents, for
> various reasons, but it all fits into the "applicability statement" box,
> and it makes sense to put the common bits into the AS document.

For auth failure reports we (tried to anyway) put the common bits needed to 
extend arf to send messages about authentication failures in draft-ietf-marf-
authfailure-report.  If there is further factoring to be done from the DKIM 
and SPF drafts, that's where it seems to be sensible to put it (I know that's 
procedurally complex at this point).

I don't think what's being discussed fits a draft about anti-spam.  Anti-spam 
and auth failure are different concepts.  In many cases the most interesting 
(to the sender) cases are the ones where legitimate messages failed 
authentication.  There are also interesting authentication failure cases where 
the message is spam, but it's certainly not limited to that.

It would seem odd to me to have to go read an RFC about anti-spam in order to 
implement authentication failure reporting, so if what's in the anti-spam 
draft is really necessary to authentication failure reporting, then I suspect 
it is misnamed.

That's a longer (and hopefully clearer) version of what I was trying to 
communicate yesterday.

Scott K