Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt

"Murray S. Kucherawy" <msk@cloudmark.com> Tue, 24 January 2012 05:49 UTC

Return-Path: <msk@cloudmark.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 EEB5F21F84B3 for <marf@ietfa.amsl.com>; Mon, 23 Jan 2012 21:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level:
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Pl7t6i8IHCMZ for <marf@ietfa.amsl.com>; Mon, 23 Jan 2012 21:49:08 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB821F84D5 for <marf@ietf.org>; Mon, 23 Jan 2012 21:49:08 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 21:49:08 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 21:49:08 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "marf@ietf.org" <marf@ietf.org>
Date: Mon, 23 Jan 2012 21:49:07 -0800
Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt
Thread-Index: AczaWt0OxRhWLMe1QNikOi+1TyQpPQAAAcKA
Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7D966@EXCH-C2.corp.cloudmark.com>
References: <20120124054123.11631.40183.idtracker@ietfa.amsl.com>
In-Reply-To: <20120124054123.11631.40183.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt
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, 24 Jan 2012 05:49:10 -0000

> -----Original Message-----
> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Monday, January 23, 2012 9:41 PM
> To: i-d-announce@ietf.org
> Cc: marf@ietf.org
> Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 
> 	Title           : Extensions to DKIM for Failure Reporting
> 	Author(s)       : Murray S. Kucherawy
> 	Filename        : draft-ietf-marf-dkim-reporting-04.txt
> 	Pages           : 18
> 	Date            : 2012-01-23
> 
>    This memo presents extensions to the DomainKeys Identified Mail
>    (DKIM) specification to allow for detailed reporting of message
>    authentication failures in an on-demand fashion.

Changes since the previous version:

- some language tightening with respect to "sender", "signer", etc.

- don't reference the SPF reporting document; they may evolve separately, and there's no need for them to hold each other up

- move all the broken signature reporting into the signature itself by making them extension DKIM-Signature tags, rather than putting them in the key records in the DNS; the revised design doesn't require DNS queries for failed signatures that don't otherwise need them

- remove "rf" (report format) tag for both DKIM and ADSP; assume all generated reports will use ARF

- rename "ri" (report interval) to "rp" (report percentage) for both DKIM and ADSP

- move report generation normative stuff out of Security Considerations and into its own section that covers report generation syntax and transport issues; reference draft-ietf-marf-authfailure-report accordingly

- other minor copy editing

Fresh reviews and other comments are most welcome.

-MSK