From sm@resistor.net Sat Oct 1 16:38:45 2011 Return-Path: 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 3719421F8D13 for ; Sat, 1 Oct 2011 16:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 u73mXDj9pKNn for ; Sat, 1 Oct 2011 16:38:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F19FA21F8D10 for ; Sat, 1 Oct 2011 16:38:30 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p91NfMZY022110 for ; Sat, 1 Oct 2011 16:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1317512487; bh=oy8pWsX4uiwZSd0qnoNbu/pCDdEtUf0jqkrNLHS5pDs=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=SFmEQFIAG9BCAwpywIkWfX0gtncNNSRMIkDo+i8yvMxgDoMrTZMeHUX4Y/jCYXoMU 6sOWXJ9gzMxEUWXNO6SuuBPmGYRHQNOp1f0EelBRTk3srqByV0J8bNF4mYgPGPtsIW wPKrc4L+WTvKw3ric9k7Y+mEqHX4KL3YQq7d0mW0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1317512487; bh=oy8pWsX4uiwZSd0qnoNbu/pCDdEtUf0jqkrNLHS5pDs=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=qZXEir7Fs67C5AUiT3btDd/CgH/F9VVMmFcIlP3HZw32AEyMNw1ZNu8dAlRSKlzVf CIjOJHgfsisNX7AE7I/HuMxRI2r/EwrYdF09gbdmjSI+8npAhE/UIajpNm8XBBc7LA JUd44tGOvPuxGawfXl5aXPgnhBJ8yFCFK6aEOMf4= Message-Id: <6.2.5.6.2.20111001154456.09b03df0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Oct 2011 16:38:34 -0700 To: marf@ietf.org From: SM In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 23:38:45 -0000 At 12:58 13-09-2011, Barry Leiba wrote: >Let's say that this now officially starts working-group last call on >draft-ietf-marf-authfailure-report-02 ( In the Abstract: "This memo registers an extension report type to ARF to be used for reporting forensic information about messages that fail one or more message authentication schemes in use by the purported sender of the message." The term purported sender sounds like one borrowed from SPF. DKIM does not use such a term. I suggest reusing some wording from ARF such as "to report feedback about received email" or use the text from the Introduction section. In Section 3: "The current report format defined in [ARF] lacks some specific features required to do effective sender authentication reporting." I don't think that "sender authentication reporting" is the appropriate term. Please let me know if the comment is unclear and I will expand on it. "Authentication-Results: This field MUST be formatted as defined in [AUTH-RESULTS], except that it MUST include explicit results for both DKIM and SPF." John Levine already commented on this. "Reported-Domain: As specified in [ARF]. This field MUST appear exactly once." This is an optional field in ARF which can appear more than once. "If this information is either not available at the time the report is generated, or the generating ADMD's policy requires it be redacted, a value of 0.0.0.0 MUST be used." Why must 0.0.0.0 be used? In Section 3.2.1: "policy: The message was not delivered to the intended inbox due to authentication failure. The specific action taken is not specified." The term "policy" is confusing. is this a "discard"? In Section 3.3: "The DKIM-ADSP-DNS field MUST be included in the report." What is the DKIM-ADSP-DNS field? Section 7.4 discusses about Envelope Sender Selection. I suggest reusing the idea from Section 5 of RFC 5965 as it is easier to build upon ARF. The DKIM reference should be updated to RFC 6376. MAIL should be updated to RFC 5322. In Appendix B: Please point to the relevant RFC instead of http://www.mipassoc.org/arf/ Regards, -sm From johnl@taugh.com Sun Oct 2 08:55:56 2011 Return-Path: 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 0821E21F858D for ; Sun, 2 Oct 2011 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, NO_RELAYS=-0.001] 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 NxtPpyOAU+mG for ; Sun, 2 Oct 2011 08:55:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3788A21F858C for ; Sun, 2 Oct 2011 08:55:54 -0700 (PDT) Received: (qmail 19823 invoked from network); 2 Oct 2011 15:58:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=4d6e.4e888a3c.k1110; bh=a6OZj6Elmpo4LiKEePI77E//er3w2KZ9j6wPuu+he5I=; b=jcDVGoHl72HdLQHUU882kFD0LpNaDcHpZ4PQ5XMyA7vWOYRo+ZpXiItNKWFqajl+OyteJtVZKAPslLghRKINTIKxoAemlY+uBPbqe/Gllw1JijMhQEuZ0kxmLgPVquL18gASq4OXQZzzj0rPNwrmw/iEFP/5Rit7Efor5kvFdUE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=4d6e.4e888a3c.k1110; bh=a6OZj6Elmpo4LiKEePI77E//er3w2KZ9j6wPuu+he5I=; b=I6GF+vfooKphkUV/7y2okkR84WxdBiZsaud27bMmJooK970hx6WEy6o179xkDz35jXt2MI/cCssAdeTZCrOLZ0LybQnnyN3CnexFUjJCnuT9Ot/CB6S5vSuUElkC+iK+pi2TDBsnmcK3fJhuImybPwTC8gpesJKpO9HIhwlg5nY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Oct 2011 15:58:30 -0000 Date: 2 Oct 2011 11:58:52 -0400 Message-ID: From: "John R Levine" To: "ARF mailing list" User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 15:55:56 -0000 I presume the motivation for this is that you have a few people who want to use it to debug DKIM failures. That's perfectly reasonable, but if people already know each other, they can use private agreements with no need to standardize anything. This strikes me as a poor thing to standardize for a variety of reasons. One is that the number of people debugging a protocol is less by many orders of magnitude than the number who are just using it, and to the users, debugging features are just cruft. Also, to some extent this is an invitation to mailbomb anyone who uses it, and as Steve noted, the people who you'd most want to implement this, the ones who are smashing signatures on the way in, are the least likely to do so. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Sun Oct 2 22:58:15 2011 Return-Path: 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 E7CA021F87F0 for ; Sun, 2 Oct 2011 22:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.973 X-Spam-Level: X-Spam-Status: No, score=-102.973 tagged_above=-999 required=5 tests=[AWL=-0.374, 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 I9stnpsUQ+B1 for ; Sun, 2 Oct 2011 22:58:15 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2116321F87C9 for ; Sun, 2 Oct 2011 22:58:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 2 Oct 2011 23:01:16 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 2 Oct 2011 23:01:15 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyAk7OdV7f+/fxuSGmHXxkdModj6wA/aGQQ Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: <6.2.5.6.2.20111001154456.09b03df0@resistor.net> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 05:58:16 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Saturday, October 01, 2011 4:39 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > In Section 3: >=20 > "The current report format defined in [ARF] lacks some specific > features required to do effective sender authentication reporting." >=20 > I don't think that "sender authentication reporting" is the > appropriate term. Please let me know if the comment is unclear and I > will expand on it. Yes, please. In particular, do you have an alternate suggestion? > "Reported-Domain: As specified in [ARF]. This field MUST appear > exactly once." >=20 > This is an optional field in ARF which can appear more than once. Indeed, but this is essentially creating a profile of ARF (by creating a ne= w feedback type) for the purpose of reporting messages that fail authentica= tion checks. I don't think there's anything wrong with saying "for this pr= ofile, Reported-Domain is mandatory". > In Section 3.2.1: >=20 > "policy: The message was not delivered to the intended inbox due > to authentication failure. The specific action taken is not > specified." >=20 > The term "policy" is confusing. is this a "discard"? It's not specified what actually happened. The term is recycled from RFC54= 51, where "policy" basically means "other, per local policy configuration",= such as rejecting a signature because "l=3D" is in use (i.e., not required= by DKIM, but certainly legal at the discretion of the receiver). > In Section 3.3: >=20 > "The DKIM-ADSP-DNS field MUST be included in the report." >=20 > What is the DKIM-ADSP-DNS field? It's defined in 6.2. -MSK From msk@cloudmark.com Sun Oct 2 23:10:14 2011 Return-Path: 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 89D5821F87FC for ; Sun, 2 Oct 2011 23:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 BE6nJRITijgJ for ; Sun, 2 Oct 2011 23:10:14 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0621F87D6 for ; Sun, 2 Oct 2011 23:10:14 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 2 Oct 2011 23:13:15 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 2 Oct 2011 23:13:14 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: Acx/ot7q+GdkklSyQAunaD+UO9S1cAB76HiA Message-ID: References: <20110930185734.33110.qmail@joyce.lan> In-Reply-To: <20110930185734.33110.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 06:10:14 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEgMTE6 NTggQU0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4g U3ViamVjdDogUmU6IFttYXJmXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1 cmUtcmVwb3J0LTAxLnR4dA0KPiANCj4gU29ycnkgbm90IHRvIGdldCB0byB0aGlzIHNvb25lci4g IFRoaXMgZHJhZnQgaGFzIHByb2JsZW1zLiAgSXQncw0KPiBub3QgcmVhZHkgdG8gc2hpcC4NCj4g DQo+IFNlYyAzLjEgc2F5cyBhIHJlcG9ydCBNVVNUIGluY2x1ZGUgZXhwbGljaXQgYXV0aCByZXN1 bHRzIGZvciBib3RoIERLSU0NCj4gYW5kIFNQRi4gIFdlbGwsIG5vLiAgSSBkb24ndCBjaGVjayBT UEYsIHNvIGlmIHBlb3BsZSBhcmUgb25seSBnb2luZyB0bw0KPiBhY2NlcHQgREtJTSBmYWlsdXJl IHJlcG9ydHMgaWYgdGhleSBhbHNvIHNheSBzb21ldGhpbmcgYWJvdXQgU1BGLA0KPiB0aGV5J3Jl IG5vdCBnb2luZyB0byBnZXQgYW55IHJlcG9ydHMgZnJvbSBtZS4gIEkgZXhwZWN0IHBlb3BsZSB3 aG8NCj4gY2hlY2sgU1BGIGJ1dCBub3QgREtJTSBmZWVsIHRoZSBzYW1lIHdheSwgcGFydGljdWxh cmx5IGZvciB0aGUgbGFyZ2UNCj4gZnJhY3Rpb24gb2YgbWFpbCB0aGF0IGhhcyBubyBES0lNIHNp Z25hdHVyZXMgdG8gY2hlY2suICBTdWdnZXN0IGp1c3QNCj4gcmVtb3ZpbmcgdGhpcyBjbGF1c2Us IGFuZCBsZXQgcGVvcGxlIHJlcG9ydCB3aGF0IHRoZXkncmUgcmVwb3J0aW5nLg0KDQpJJ20gZ2Vu dGx5IGtpY2tpbmcgbXlzZWxmIG5vdyBmb3Igbm90IGhhdmluZyBpbmNsdWRlZCByZXBvcnRpbmcg cmVzdWx0IGNvZGVzIGluIFJGQzU0NTEgZm9yICJub3QgY2hlY2tlZCIuDQoNCkkgdGhpbmsgdGhl IGludGVudCBoZXJlIChhcyBJIG1lbnRpb25lZCB0byBTTSkgaXMgdGhhdCB0aGlzIGlzIHJlYWxs eSBhIHNwZWNpZmljIHByb2ZpbGUgZm9yIEFSRiB1c2UsIGNyZWF0aW5nIGEgbmV3IGZlZWRiYWNr IHR5cGUsIHRoYXQgb3JpZ2luYXRlcyB3aXRoIHNpdGVzIHRoYXQgZG8gY2hlY2sgYm90aDsgaWYg eW91IGRvbid0IGNoZWNrIGJvdGgsIHlvdSBzaW1wbHkgd291bGRuJ3QgdXNlIHRoaXMgZmVlZGJh Y2sgdHlwZS4gIEl0IGRpZG4ndCBvY2N1ciB0byBtZSB3aGVuIEkgY3JhZnRlZCB0aGUgb3JpZ2lu YWwgdmVyc2lvbnMgb2YgdGhpcyB3b3JrIHRoYXQgdGhlcmUgbWlnaHQgYmUgc2l0ZXMgdGhhdCBk b24ndCwgYW5kIHRoYXQgdGhlcmUncyBubyB3YXkgdG8gc2F5IGV4cGxpY2l0bHkgIkkgZG9u4oCZ dCBjaGVjayB7REtJTSxTUEZ9LiINCg0KSSByZWFsaXplIG5vdyB0aGF0IGFwcHJvYWNoIHdhcyBt YXliZSBhIGJpdCBsaW1pdGluZy4NCg0KUGVyaGFwcyBvbmUgc29sdXRpb24gbWlnaHQgYmUgdG8g Z28gcmVnaXN0ZXIgIm5vdC1jaGVja2VkIiB1bmRlciBSRkM1NDUxIGZvciBib3RoIFNQRiBhbmQg REtJTSwgYW5kIHRoZW4gdGhpcyBjb3VsZCBiZSBtYW5kYXRvcnkuICBUaGF0IHNlZW1zIG92ZXJr aWxsIHRob3VnaCwgdW5sZXNzIHdlIGNhbiBkZWNpZGUgd2UgcmVhbGx5IHdhbnQgdGhhdCAob3Ig dGhhdCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBkbyByZWdhcmRsZXNzKS4NCg0KRmFpbGlu ZyB0aGF0LCBpdCBkb2VzIHNlZW0gdG8gbWFrZSBzZW5zZSB0byByZWR1Y2UgdGhpcyB0byAiTVVT VCByZXBvcnQgYXQgbGVhc3Qgb25lIG9mLi4uIg0KDQo+IE9yaWdpbmFsLUVudmVsb3BlLUlEIGFu ZCBPcmlnaW5hbC1NYWlsLUZyb206IHNhbWUgaXNzdWUsIHRoZXkncmUgbm90DQo+IHJlbGV2YW50 IHRvIERLSU0sIGFuZCBieSB0aGUgdGltZSBJIGNoZWNrIERLSU0sIGl0J3Mgb2Z0ZW4gYWZ0ZXIg U01UUA0KPiBpcyBvdmVyIGFuZCB0aGUgZW52ZWxvcGUgaXNuJ3QgZGlyZWN0bHkgYXZhaWxhYmxl LiAgU3VnZ2VzdCBpdCBzYXkNCj4gdGhleSBTSE9VTEQgYmUgaW5jbHVkZWQgaWYgdGhleSBhcmUg YXZhaWxhYmxlLg0KDQpUaGF0IG1ha2VzIHNlbnNlIHRvIG1lLCBvciBTSE9VTEQgaWYgeW91J3Jl IHJlcG9ydGluZyBTUEYuDQoNCj4gU291cmNlLUlQOiBzYW1lIHByb2JsZW0uICBJZiB5b3UgZG9u J3QgaGF2ZSB0aGUgc291cmNlIElQLCBqdXN0IGxlYXZlDQo+IGl0IG91dCwgZG9uJ3QgbGllLiAg KEFuZCAwLjAuMC4wIGlzIHRvdGFsbHkgb2xkdGhpbmsuICBUaGUgdmFsdWUgSSdtDQo+IG5vdCBn b2luZyB0byBpbmNsdWRlIGlzIDo6LikNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgb25lLg0KDQo+IE1l c3NhZ2UtSUQ6IHRoaXMgaXMganVzdCB3cm9uZywgUkZDIDU5NjUgZG9lcyBub3QgcmVwb3J0IGl0 Lg0KDQpJIGRvbid0IGFncmVlIHdpdGggdGhpcyBvbmUuICBXaGF0J3Mgd3Jvbmcgd2l0aCBhZGRp bmcgdGhpcyBoZXJlIGV2ZW4gdGhvdWdoIFJGQzU5NjUgZG9lc24ndCBpbmNsdWRlIGl0Pw0KDQpU byBtZSB0aGUgc3Ryb25nZXIgYXJndW1lbnQgaXMgdGhhdCBSRkM1MzIyIGRvZXNuJ3QgcmVxdWly ZSBpdCwgc28gdGhpcyBjYW4ndCBlaXRoZXIuDQoNCj4gMy4yLjE6IERlbGl2ZXJ5LXJlc3VsdDog d2hhdCBJIGRvIHdpdGggbXkgbWFpbCBpcyBub25lIG9mIHlvdXIgYnVzaW5lc3MuDQo+IFRoaXMg ZmllbGQgaGFzIHRvIGJlIG9wdGlvbmFsLg0KDQpBZ3JlZS4NCg0KPiAzLjM6IFdoeSBqdXN0IHNw ZiByYXRoZXIgdGhhbiBzcGYtZmFpbCwgc3BmLXNvZnRmYWlsLCBzcGYtdGVtcGVycm9yLA0KPiBv ciBzcGYtcGVybWVycm9yPyBJZiB5b3UncmUgcmVwb3J0aW5nIGFuIFNQRiBwcm9ibGVtLCB5b3Ug cHJlc3VtYWJseQ0KPiBrbm93IHdoYXQgeW91ciBTUEYgY2hlY2tlciByZXR1cm5lZC4NCg0KU2Vl bXMgcmVhc29uYWJsZSwgdGhvdWdoIHRoZSBhcHBsaWNhdGlvbnMgZm9yIHRoaXMgSSBjYW4gdGhp bmsgb2YgZG9uJ3QgbmVjZXNzYXJpbHkgY2FyZSwgYW5kIHNvIHRoZSBkZXRhaWwgb2YgdGhlIGZh aWx1cmUgY291bGQgYmUgaW5jbHVkZWQgaW4gYSBjb21tZW50Lg0KDQo+IDQ6IFNQRi1ETlMuICBJ ZiB5b3UncmUgZ29pbmcgdG8gcmV0dXJuIGEgc25hcHNob3Qgb2YgdGhlIFNQRiByZWNvcmQsDQo+ IHNob3VsZG4ndCB5b3UgYWxzbyByZXR1cm4gYWxsIHRoZSByZWNvcmRzIGl0IGluY2x1ZGVkPw0K DQpBZ3JlZS4NCg0KLU1TSyAoYXMgcGFydGljaXBhbnQpDQo= From msk@cloudmark.com Sun Oct 2 23:16:00 2011 Return-Path: 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 9A22521F86C1 for ; Sun, 2 Oct 2011 23:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 7rUr2dtOOj2J for ; Sun, 2 Oct 2011 23:16:00 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3388921F850B for ; Sun, 2 Oct 2011 23:16:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 2 Oct 2011 23:19:01 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 2 Oct 2011 23:19:00 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: Acx/vjpHQpF1idvyTligQE59TX8TzwB1ZFIg Message-ID: References: <20110930185734.33110.qmail@joyce.lan> <23551164.Qt3FNA7XI6@scott-latitude-e6320> In-Reply-To: <23551164.Qt3FNA7XI6@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 06:16:00 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Friday, September 30, 2011 3:14 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > Does requiring the canonicalized header/body be included in the report ob= viate > the ability to remove data as described in paragraph 5? I think the fact= that > these include data that one might want to redact is worth a mention in > security considerations. Also, if one is going to redact and then re- > canonicalize then providing the data is pointless. So if a sender wants = to > fully redact information there's no benefit to including them. They shou= ld > only be included if they can be sent unmodified without violating the > receiver's privacy requirements. The original intent of the canonicalized header/body fields is to allow a s= ender, who keeps the same data at the time of signing, can compare it again= st the receiver's copy of the same data to tell how the signed part of a me= ssage was altered in transit. When doing DKIM debugging, redaction clobber= s any hope of finding the real problem. This is definitely appropriate for= coverage in Security Considerations. With respect to the warning that most implementations will just report "oth= er" a lot of the time, I think it's fair to say that's fine: For sites that= agree between themselves that they trust each other and trust the transmis= sion channel, they can agree to send unredacted, detailed reports, and this= document says how to do so; for those that do not and have privacy concern= s, the spec should accommodate those cases as well. -MSK From johnl@iecc.com Mon Oct 3 03:43:55 2011 Return-Path: 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 E7F2421F8B33 for ; Mon, 3 Oct 2011 03:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.116 X-Spam-Level: X-Spam-Status: No, score=-111.116 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 nhe6kRORimUq for ; Mon, 3 Oct 2011 03:43:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5213721F8B29 for ; Mon, 3 Oct 2011 03:43:55 -0700 (PDT) Received: (qmail 62838 invoked from network); 3 Oct 2011 10:46:52 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 3 Oct 2011 10:46:52 -0000 Received: (qmail 47101 invoked from network); 3 Oct 2011 10:46:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Oct 2011 10:46:52 -0000 Date: 3 Oct 2011 10:46:30 -0000 Message-ID: <20111003104630.2235.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 10:43:56 -0000 >Perhaps one solution might be to go register "not-checked" under RFC5451 >for both SPF and DKIM, and then this could be mandatory. That seems >overkill though, unless we can decide we really want that (or that it >would be a good idea to do regardless). I don't understand what the problem is with people reporting what they report. If they checked both, fine, if not, well, what's wrong with that? >> Message-ID: this is just wrong, RFC 5965 does not report it. > >I don't agree with this one. What's wrong with adding this here even >though RFC5965 doesn't include it? What's the point? Neither SPF nor DKIM use it. It's in the copy of the message if you want it, just like all the other headers. R's, John From vesely@tana.it Mon Oct 3 04:19:43 2011 Return-Path: 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 BE7FD21F8B0A for ; Mon, 3 Oct 2011 04:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[AWL=0.092, 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 JKXl9DJWF7e2 for ; Mon, 3 Oct 2011 04:19:39 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4450821F8AE6 for ; Mon, 3 Oct 2011 04:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1317640958; bh=Gy0Hzbzu+MvURXMUS2MhsOd9TSg/gpoylQppTAr8j2Q=; l=1485; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lOPCq0gA50VOZFTNHZjZ45f+gNxpkKvwL579k5keSkaUQtylXthhAJ4Ubj6+D1ZUm 0wyzFdMMdtSPMEJ004qegRSRbkylvtrblMpQCaBh0U84yaRdo5SRj289DpA7fagHb2 /ZEhXM2LdVVulZoG/5STl/fIYcP5XWL85h5rYiik= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 03 Oct 2011 13:22:38 +0200 id 00000000005DC039.000000004E899AFE.00002640 Message-ID: <4E899AFE.2020401@tana.it> Date: Mon, 03 Oct 2011 13:22:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: marf@ietf.org References: <20110930185734.33110.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 11:19:43 -0000 On 03/Oct/11 08:13, Murray S. Kucherawy wrote: > > I'm gently kicking myself now for not having included reporting > result codes in RFC5451 for "not checked". The General Description in RFC 5451 makes it clear that methods that were not applied deserve no "method=result" statement. That spec does not mandate that _all_ methods be reported, thus leaving it ambiguous whether unreported methods are not implemented at all or omitted for any other reason. IMHO, that's good as it is. > I think the intent here (as I mentioned to SM) is that this is > really a specific profile for ARF use, creating a new feedback > type, that originates with sites that do check both; if you don't > check both, you simply wouldn't use this feedback type. It didn't > occur to me when I crafted the original versions of this work that > there might be sites that don't, and that there's no way to say > explicitly "I don’t check {DKIM,SPF}." I'm unable to see why these methods need to coexist for reporting just one of them. Even MTAs that usually check both, may bail out some checks in particular cases. Furthermore, to report a message that simultaneously fails both DKIM and SPF, one needs to send two separate authfailure reports anyway, since the Auth-Failure field must appear exactly once (but it is missing in the example, BTW.) > I realize now that approach was maybe a bit limiting. Authfailure reporting is non-extensible by design, while RFC 5451 is. From sm@resistor.net Mon Oct 3 10:34:07 2011 Return-Path: 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 A348921F8C94 for ; Mon, 3 Oct 2011 10:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 lBFbXToLIVAJ for ; Mon, 3 Oct 2011 10:34:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D79EB21F8C8F for ; Mon, 3 Oct 2011 10:34:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p93Hb2Wi027786 for ; Mon, 3 Oct 2011 10:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1317663427; bh=jbIYeWf3q341EMv146hlNJd9b8en+5zRod4OyeA7J58=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=eYV0SSLJNtfRb2df5wxNYu3og/5wlFzW8nyWPsxlt2TZr9X0r0Z3H0xsUIxb3gYw4 /pfLb65gw8ow3BSJ5qTlaAa/re+xerHMI9b0qPX+uGzkDOPilCU0bBfXUj0hscFDhp nBR+EYWx2aMLOeAgn80IsjsLCoE8iFB5Z/ttDVOA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1317663427; bh=jbIYeWf3q341EMv146hlNJd9b8en+5zRod4OyeA7J58=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=oCqQDCZ4CfJl4gVVGPRODXbAsIHP2m0cVeX24OVhxySZ84IK5h1TjeEghlbgiOr+0 mW2yS3C0FFJaYC2OGCWMPmR5fX4X853HkMesBCaabPINIg2MFZK4Ln4Tu2YKoe/5nF nQk/llXHa7yI5rVQL+418t7C66+2te2JSty9r50U= Message-Id: <6.2.5.6.2.20111003092535.08569780@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Oct 2011 09:51:53 -0700 To: marf@ietf.org From: SM In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 17:34:07 -0000 Hi Murray, At 23:01 02-10-2011, Murray S. Kucherawy wrote: >Yes, please. In particular, do you have an alternate suggestion? The draft is an extension of ARF which uses the Authentication-Results header field. I suggest reusing the RFC 5451 approach to avoid problematic terms: This memo registers an extension report type to ARF to be used for reporting forensic information about messages that fail one or more message authentication effort. BTW, you used "effort" and "checks". I noticed that Authentication-Results (Section 3.1) can appear only once. A message may have one or more such header fields. >Indeed, but this is essentially creating a profile of ARF (by >creating a new feedback type) for the purpose of reporting messages >that fail authentication checks. I don't think there's anything >wrong with saying "for this profile, Reported-Domain is mandatory". There may be more than one "Reported-Domain". It is about the same problem as Authentication-Results. Do you want one report for each occurrence or do you want one report per message? In the first case, we are reporting failures whereas the second case is about delivery status (Section 3.2.1). >It's not specified what actually happened. The term is recycled >from RFC5451, where "policy" basically means "other, per local >policy configuration", such as rejecting a signature because "l=" is >in use (i.e., not required by DKIM, but certainly legal at the >discretion of the receiver). RFC 5451 states that: "The message was signed but the signature or signatures were not acceptable to the verifier." This is not an authentication failure (Section 3.2.1). BTW, ARF was initially designed as a format for reporting email abuse. This draft seems to be tackling deliverability even though that is not mentioned explicitly. If I understood the charter correctly, the aim was to specify integration of ARF in DKIM-aware environments and to generate phishing reports. For example, if someone is generating a "fake" DKIM-Signature header, the domain being "phished" can receive reports of such occurrences. There are times when it may a technical glitch instead of a phish, e.g. DKIM signature not verifying. The report can convey debugging information to identify such issues. There isn't any discussion in the draft about the problem being addressed. The document comes out as trying to report back as much information as possible without any explanation. Regards, -sm From msk@cloudmark.com Mon Oct 3 11:04:09 2011 Return-Path: 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 89B5D21F8CEC for ; Mon, 3 Oct 2011 11:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 QuicIwGh0tFv for ; Mon, 3 Oct 2011 11:04:09 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD8D21F8CEA for ; Mon, 3 Oct 2011 11:04:09 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 3 Oct 2011 11:07:11 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 3 Oct 2011 11:07:10 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyBvshogJwfkRRZQ02fcUklIOtiKQAOBuWg Message-ID: References: <20110930185734.33110.qmail@joyce.lan> <4E899AFE.2020401@tana.it> In-Reply-To: <4E899AFE.2020401@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:04:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYXJmLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptYXJmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGVzc2FuZHJv IFZlc2VseQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMDMsIDIwMTEgNDoyMyBBTQ0KPiBUbzog bWFyZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW21hcmZdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtbWFyZi1hdXRoZmFpbHVyZS1yZXBvcnQtMDEudHh0DQo+IA0KPiBUaGUgR2VuZXJhbCBEZXNj cmlwdGlvbiBpbiBSRkMgNTQ1MSBtYWtlcyBpdCBjbGVhciB0aGF0IG1ldGhvZHMgdGhhdA0KPiB3 ZXJlIG5vdCBhcHBsaWVkIGRlc2VydmUgbm8gIm1ldGhvZD1yZXN1bHQiIHN0YXRlbWVudC4gIFRo YXQgc3BlYyBkb2VzDQo+IG5vdCBtYW5kYXRlIHRoYXQgX2FsbF8gbWV0aG9kcyBiZSByZXBvcnRl ZCwgdGh1cyBsZWF2aW5nIGl0IGFtYmlndW91cw0KPiB3aGV0aGVyIHVucmVwb3J0ZWQgbWV0aG9k cyBhcmUgbm90IGltcGxlbWVudGVkIGF0IGFsbCBvciBvbWl0dGVkIGZvcg0KPiBhbnkgb3RoZXIg cmVhc29uLiAgSU1ITywgdGhhdCdzIGdvb2QgYXMgaXQgaXMuDQoNClRoZSBhYnNlbmNlIG9mICJz cGY9IiBpbiBhbiBBdXRoZW50aWNhdGlvbi1SZXN1bHRzIGZpZWxkIGRvZXNuJ3Qgc2F5IGFueXRo aW5nIGFib3V0IFNQRiB3b3JrIGRvbmUgYXQgdGhlIHZlcmlmaWVyLiAgQ291bGQgYmUgdGhhdCBp dCB3YXMgdGVzdGVkIGFuZCB1bnJlcG9ydGVkIGZvciBhbGwgSSBrbm93LiAgSWYgdGhlIHZlcmlm aWVyIHdhbnRzIHRvIHNheSBleHBsaWNpdGx5ICJJIGRpZG4ndCBjaGVjayB0aGlzIiwgdGhlcmUn cyBubyBtZWNoYW5pc20gdG8gZG8gdGhhdCByaWdodCBub3cuDQoNCj4gQXV0aGZhaWx1cmUgcmVw b3J0aW5nIGlzIG5vbi1leHRlbnNpYmxlIGJ5IGRlc2lnbiwgd2hpbGUgUkZDIDU0NTEgaXMuDQoN CkkgZG9uJ3QgYWdyZWUgYXQgYWxsIHdpdGggdGhlIGZpcnN0IHBhcnQgb2YgdGhhdCBzdGF0ZW1l bnQuDQo= From msk@cloudmark.com Mon Oct 3 16:07:44 2011 Return-Path: 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 20B1721F8CD0 for ; Mon, 3 Oct 2011 16:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 CtOblLGOPWl7 for ; Mon, 3 Oct 2011 16:07:43 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE62321F8CCF for ; Mon, 3 Oct 2011 16:07:43 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 3 Oct 2011 16:10:47 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 3 Oct 2011 16:10:46 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyBucRdTxdfovBRRQG3jg7fjAsVSwAZ2upQ Message-ID: References: <20111003104630.2235.qmail@joyce.lan> In-Reply-To: <20111003104630.2235.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 23:07:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDExIDM6NDcg QU0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4gU3Vi amVjdDogUmU6IFttYXJmXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUt cmVwb3J0LTAxLnR4dA0KPiANCj4gPj4gTWVzc2FnZS1JRDogdGhpcyBpcyBqdXN0IHdyb25nLCBS RkMgNTk2NSBkb2VzIG5vdCByZXBvcnQgaXQuDQo+ID4NCj4gPkkgZG9uJ3QgYWdyZWUgd2l0aCB0 aGlzIG9uZS4gIFdoYXQncyB3cm9uZyB3aXRoIGFkZGluZyB0aGlzIGhlcmUgZXZlbg0KPiA+dGhv dWdoIFJGQzU5NjUgZG9lc24ndCBpbmNsdWRlIGl0Pw0KPiANCj4gV2hhdCdzIHRoZSBwb2ludD8g IE5laXRoZXIgU1BGIG5vciBES0lNIHVzZSBpdC4gIEl0J3MgaW4gdGhlIGNvcHkgb2YNCj4gdGhl IG1lc3NhZ2UgaWYgeW91IHdhbnQgaXQsIGp1c3QgbGlrZSBhbGwgdGhlIG90aGVyIGhlYWRlcnMu DQoNCkkgdGhvdWdodCB0aGUgaWRlYSBpcyB0aGF0IHRoZSBzZWNvbmQgTUlNRSBwYXJ0IG9mIGEg bXVsdGlwYXJ0L3JlcG9ydCBpbmNsdWRlcyB0aGluZ3MgdGhhdCBtaWdodCBiZSBrZXlzIHRvIHNl YXJjaGluZyBsb2dzIG9yIG90aGVyd2lzZSB1bmlxdWVseSBpZGVudGlmeWluZyB0aGUgbWVzc2Fn ZSBhdCB0aGUgc2VuZGVyJ3Mgc2lkZSwgYXMgd2VsbCBhcyBpbmNsdWRpbmcgdGhlIHRlY2huaWNh bCBzcGVjaWZpY3Mgb2YgdGhlIHJlcG9ydC4NCg0KQnV0IHlvdSdyZSByaWdodCB0aGF0IGl0J3Mg ZHVwbGljYXRlZCBkYXRhIGlmIHRoZSB0aGlyZCBwYXJ0IGlzIGluY2x1ZGVkLCBhbmQgZm9yIEFS RiBpdCBhbHdheXMgaXMuDQo= From johnl@iecc.com Mon Oct 3 18:55:52 2011 Return-Path: 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 9984D21F8E57 for ; Mon, 3 Oct 2011 18:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.118 X-Spam-Level: X-Spam-Status: No, score=-111.118 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 MTcs5xvmSG6N for ; Mon, 3 Oct 2011 18:55:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0307221F8E47 for ; Mon, 3 Oct 2011 18:55:51 -0700 (PDT) Received: (qmail 96678 invoked from network); 4 Oct 2011 01:58:55 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 4 Oct 2011 01:58:55 -0000 Received: (qmail 46824 invoked from network); 4 Oct 2011 01:58:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Oct 2011 01:58:55 -0000 Date: 4 Oct 2011 01:58:32 -0000 Message-ID: <20111004015832.8492.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 01:55:52 -0000 >> What's the point? Neither SPF nor DKIM use it. It's in the copy of >> the message if you want it, just like all the other headers. > >I thought the idea is that the second MIME part of a multipart/report >includes things that might be keys to searching logs or otherwise >uniquely identifying the message at the sender's side, as well as >including the technical specifics of the report. It never has in the past. As we said in RFC 5965: This section is intended to convey meta-data about the report in question that may not be readily available from the included email message itself. >But you're right that it's duplicated data if the third part is >included, and for ARF it always is. Exactly. The second section is "here's why we hate this message", not "here's the message you sent." R's, John PS: Is someone planning to revise the draft and try to fix it? From msk@cloudmark.com Mon Oct 3 21:31:28 2011 Return-Path: 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 CF05721F8EDF for ; Mon, 3 Oct 2011 21:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3SHE7+xFmEPJ for ; Mon, 3 Oct 2011 21:31:27 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F121F8ED6 for ; Mon, 3 Oct 2011 21:31:27 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 3 Oct 2011 21:34:25 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 3 Oct 2011 21:34:24 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyCOTCJijb0Omk1QiqKwZANf5aiPwAFagbw Message-ID: References: <20111004015832.8492.qmail@joyce.lan> In-Reply-To: <20111004015832.8492.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 04:31:28 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDAzLCAyMDExIDY6NTkg UE0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4gU3Vi amVjdDogUmU6IFttYXJmXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUt cmVwb3J0LTAxLnR4dA0KPiANCj4gUFM6IElzIHNvbWVvbmUgcGxhbm5pbmcgdG8gcmV2aXNlIHRo ZSBkcmFmdCBhbmQgdHJ5IHRvIGZpeCBpdD8NCg0KSW4gcHJvZ3Jlc3MuDQo= From hfontana@ecertsystems.com Mon Oct 3 21:33:01 2011 Return-Path: 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 7C2DA21F8EEB for ; Mon, 3 Oct 2011 21:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 keXoXrOTXcXK for ; Mon, 3 Oct 2011 21:33:00 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id C40C821F8EE8 for ; Mon, 3 Oct 2011 21:33:00 -0700 (PDT) Received: by pzk37 with SMTP id 37so304550pzk.9 for ; Mon, 03 Oct 2011 21:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:disposition-notification-to; bh=fINzFwGRG7cj6Yx1hThrcXukrDAgRQaxISaol2cQQM8=; b=J40lhAze9ANWwwQt9f5FqtjKNWqgmWh7QfhpI2TfPNGVNTgLyOLaLtueiq/WEOuLsr vJXCfkVG6Tp4rSih5IFrHvW9ctWRPLijUgF/aIoIlSEOR8IWy1DUXOFRm8Ga76MBhU1N Roa6WNa7BIJNgnFG94NiQ85wez1FhW3x0E/Hc= Received: by 10.68.35.1 with SMTP id d1mr6636866pbj.55.1317702964902; Mon, 03 Oct 2011 21:36:04 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id h5sm60755994pbq.11.2011.10.03.21.36.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Oct 2011 21:36:03 -0700 (PDT) From: "Hilda Fontana" To: "'Murray S. Kucherawy'" , References: <20111004015832.8492.qmail@joyce.lan> In-Reply-To: Date: Mon, 3 Oct 2011 21:35:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwvyxnWKKkGmFpH/KTNFXTUfLU5AHrXGZZAXpXV3eUh/ICsA== Content-Language: en-us Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 04:33:01 -0000 Thanks guys - I am gathering all the changes and am going to do a revision best I can. H > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Monday, October 03, 2011 9:34 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt > > > -----Original Message----- > > From: John Levine [mailto:johnl@taugh.com] > > Sent: Monday, October 03, 2011 6:59 PM > > To: marf@ietf.org > > Cc: Murray S. Kucherawy > > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt > > > > PS: Is someone planning to revise the draft and try to fix it? > > In progress. > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 4 11:03:33 2011 Return-Path: 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 19C7021F8C89 for ; Tue, 4 Oct 2011 11:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 LMWd0Qhkna-m for ; Tue, 4 Oct 2011 11:03:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6821F8C82 for ; Tue, 4 Oct 2011 11:03:31 -0700 (PDT) Received: by wwf22 with SMTP id 22so847694wwf.13 for ; Tue, 04 Oct 2011 11:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bJ3QEwCoFg5yk6AKRxvU6X5wu7fEDyKP3v0+F1X/Axg=; b=UZnIiY6PXDW0ub04SUy0jpPo2o9YanU020C3hd07+Kfcxuna6abUlXad2AvWivBypu wU1IsnmuPGHO81M9H0Q0yoyFlFXhy/S3biZ+VLsC+QhKySYuec2QbpTbRiy6rdE258Kt JYrO2batRjPZP8TWLQtihgutpD/yvLCoY7sEs= Received: by 10.227.11.81 with SMTP id s17mr1845923wbs.62.1317751597071; Tue, 04 Oct 2011 11:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 4 Oct 2011 11:05:57 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20111001154456.09b03df0@resistor.net> References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> From: Frank Ellermann Date: Tue, 4 Oct 2011 20:05:57 +0200 Message-ID: To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:03:33 -0000 On 2 October 2011 01:38, SM wrote: > The term purported sender sounds like one borrowed from SPF. Not really, did you confuse this with the "PRA" in Sender-ID? The "PRA" concept was not adopted or acknowledged in the later RFCs 4409bis and 5321. My somewhat irregular summary would be that nobody was thrilled by the fine print of a "Resent-Sender". >=A0DKIM does not use such a term. IIRC at some point in time DKIM tackled "authors" (5322-From), and whatever that is, it is certainly not always the "sender", let alone the PRA. But for ordinary humans not knowing these infamous terminology difficulties "purported sender" might be vague enough to cover the different concepts (?). BTW, the draft does not mention Sender-ID at all. I take this as another indication that this "experiment" is now obsolete; RFC 4407 (PRA) was cute, but RFC 4405 (SUBMITTER) was a "FUSSP". -Frank From msk@cloudmark.com Tue Oct 4 11:56:29 2011 Return-Path: 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 2B65721F8E5C for ; Tue, 4 Oct 2011 11:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=-0.368, 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 lgobnrM3f7bK for ; Tue, 4 Oct 2011 11:56:28 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id B854C21F8E5A for ; Tue, 4 Oct 2011 11:56:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 4 Oct 2011 11:59:34 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 11:59:32 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyCwF4ijzj7uH+ST7mFXv9G3kaEzwABzC2w Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:56:29 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of F= rank Ellermann > Sent: Tuesday, October 04, 2011 11:06 AM > To: SM > Cc: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > BTW, the draft does not mention Sender-ID at all. I take this > as another indication that this "experiment" is now obsolete; > RFC 4407 (PRA) was cute, but RFC 4405 (SUBMITTER) was a "FUSSP". I don't think MARF is in a position to be able to make that statement expli= citly. Further, since we appear to be in agreement that the authentication= results reported by this draft should include only those things that were = actually tested, and not a fixed set, it seems including a "sender-id" resu= lt is on the table. From sm@resistor.net Tue Oct 4 11:59:24 2011 Return-Path: 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 68A6A21F8D1B for ; Tue, 4 Oct 2011 11:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 suoH-T1MEtCc for ; Tue, 4 Oct 2011 11:59:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA7A21F8C1D for ; Tue, 4 Oct 2011 11:59:21 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p94J2ICG007378; Tue, 4 Oct 2011 12:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1317754944; bh=G8u71BCTPxGr2gaWBIfnUspZNo3g+D9HmDMgAvg0hI0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=kayro9TAZz0JP5Opbde5eycA9FhJeiymohoTkAJpp4Tylk4qhqreDHgsMXTeyeA74 JN+/Q9+tVwYjwebgUi5ByygNSatFVTYLGl+fyokFnqRR2MEG/NfkYcb5fLucHVxAmH 013qZWKYjfa41HGMnHIXLvJYQNswgSjiOMAKT9c0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1317754944; bh=G8u71BCTPxGr2gaWBIfnUspZNo3g+D9HmDMgAvg0hI0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=zlY24K2Sq10DU7q+WIdYAuZeNUFE8FFBVs2+DNVCzfdxbzvvzi3q3IuqOGw579re0 RL0Vf7jDTxZY3i4jJj+pe4Ul8WjorNG07qOyw3eTUml2ms3B/FQ9OgTrcbvyrCSiZZ A6NJvx2Y5csnKMM5fuxROjkKtiHeo5gjOsWFAuu8= Message-Id: <6.2.5.6.2.20111004111911.0a955720@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 04 Oct 2011 12:01:06 -0700 To: Frank Ellermann From: SM In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 18:59:24 -0000 Hi Frank, At 11:05 04-10-2011, Frank Ellermann wrote: >Not really, did you confuse this with the "PRA" in Sender-ID? Yes, it could be. >IIRC at some point in time DKIM tackled "authors" (5322-From), >and whatever that is, it is certainly not always the "sender", >let alone the PRA. But for ordinary humans not knowing these >infamous terminology difficulties "purported sender" might be >vague enough to cover the different concepts (?). It is difficult to cover different concepts like SPF and DKIM. The former is a test on the reverse-path whereas the latter provides a means to verify the hash affixed to a message. I focused on the Authentication-Results angle as it is simpler to take its results as input instead of getting into the details of what SPF, DKIM or any other mechanism does or does not do. Regards, -sm From sklist@kitterman.com Tue Oct 4 12:18:43 2011 Return-Path: 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 77E7421F8F76 for ; Tue, 4 Oct 2011 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 EZSA+NUvvUgY for ; Tue, 4 Oct 2011 12:18:42 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7283121F8F75 for ; Tue, 4 Oct 2011 12:18:42 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id A0F6A38C143; Tue, 4 Oct 2011 15:21:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317756107; bh=XrRbwG3qi2jJsz43FQ4GvNmVYWbcpwT1jgX1ygNlf4U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=HsdVV6Kf+L4qGUr7xEJuWatrvmGWhEQHXRTSFfJOXQto7LAI9hKoiQTWszWRd3nYO lcNjY4V9EgUdBkjdsMcS1GFLW7xyceCmgj87TuyKdVTpnIF31zaYCUHozrGXi1C0kI b7v5zemRERMXFmjMlbmTfzKn07/nj2d+ugPNrfgM= From: Scott Kitterman To: marf@ietf.org Date: Tue, 04 Oct 2011 14:21:46 -0500 Message-ID: <3867829.uIboUR4TA1@scott-latitude-e6320> User-Agent: KMail/4.7.1 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:18:43 -0000 On Tuesday, October 04, 2011 11:59:32 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Frank Ellermann Sent: Tuesday, October 04, 2011 11:06 AM > > To: SM > > Cc: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > BTW, the draft does not mention Sender-ID at all. I take this > > as another indication that this "experiment" is now obsolete; > > RFC 4407 (PRA) was cute, but RFC 4405 (SUBMITTER) was a "FUSSP". > > I don't think MARF is in a position to be able to make that statement > explicitly. Further, since we appear to be in agreement that the > authentication results reported by this draft should include only those > things that were actually tested, and not a fixed set, it seems including a > "sender-id" result is on the table. Does it have a constituency? There are quite a number of auth methods covered in auth-results that we don't cover and I don't think we should extend beyone SPF/DKIM unless someone needs it. Scott K From msk@cloudmark.com Tue Oct 4 12:22:35 2011 Return-Path: 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 7E95321F8BAC for ; Tue, 4 Oct 2011 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=-0.367, 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 FCkqyTaRjrRb for ; Tue, 4 Oct 2011 12:22:35 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5B70521F8B4B for ; Tue, 4 Oct 2011 12:22:24 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 4 Oct 2011 12:25:30 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 12:25:29 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyCyuAxTHYFtppFTiSvtWFr9XUnWgAAEFHQ Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <3867829.uIboUR4TA1@scott-latitude-e6320> In-Reply-To: <3867829.uIboUR4TA1@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:22:35 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Tuesday, October 04, 2011 12:22 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > Does it have a constituency? There are quite a number of auth methods co= vered > in auth-results that we don't cover and I don't think we should extend be= yone > SPF/DKIM unless someone needs it. If we're insisting that we not say you have to report specific ones, then b= eing completely agnostic seems the right path to me. From dotzero@gmail.com Tue Oct 4 12:26:14 2011 Return-Path: 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 0FC7A21F8FAA for ; Tue, 4 Oct 2011 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nMoN0XD7Vle6 for ; Tue, 4 Oct 2011 12:26:13 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8309121F8FA2 for ; Tue, 4 Oct 2011 12:26:13 -0700 (PDT) Received: by qyk32 with SMTP id 32so3167829qyk.10 for ; Tue, 04 Oct 2011 12:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V8/6va5oCwUv+71+6ZX82pHZt/zFWmUQmd8Roj4DQ9U=; b=rrRnBjluxLGPklUFNACHFgbOC9xxXMd0VqXW/+lpcGj50Pw2IyC+CmAYaFVjAJJPji pJOH/nrwqePZe/Aft7cwrZrWPp37n4rRPmsTQeWF0Z38KcRBKWLaoh1ZVxreva+F6sqB urN20694US0C8wUCzmCiWAjW2agNQD7Hj3BY8= MIME-Version: 1.0 Received: by 10.229.37.135 with SMTP id x7mr1370281qcd.18.1317756559137; Tue, 04 Oct 2011 12:29:19 -0700 (PDT) Received: by 10.229.114.69 with HTTP; Tue, 4 Oct 2011 12:29:19 -0700 (PDT) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <3867829.uIboUR4TA1@scott-latitude-e6320> Date: Tue, 4 Oct 2011 15:29:19 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:26:14 -0000 On Tue, Oct 4, 2011 at 3:25 PM, Murray S. Kucherawy wro= te: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Scott Kitterman >> Sent: Tuesday, October 04, 2011 12:22 PM >> To: marf@ietf.org >> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.tx= t >> >> Does it have a constituency? =A0There are quite a number of auth methods= covered >> in auth-results that we don't cover and I don't think we should extend b= eyone >> SPF/DKIM unless someone needs it. > > If we're insisting that we not say you have to report specific ones, then= being completely agnostic seems the right path to me. > +1 From sklist@kitterman.com Tue Oct 4 12:45:08 2011 Return-Path: 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 2BD0B21F8D25 for ; Tue, 4 Oct 2011 12:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 9wFolfNYe2G4 for ; Tue, 4 Oct 2011 12:45:07 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 11FFD21F8D1A for ; Tue, 4 Oct 2011 12:45:06 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7A03838C143; Tue, 4 Oct 2011 15:48:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317757691; bh=dbxibLJZw3FgdUYly+5nZ6CfEZD5k+GGum+D9SBMjdE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=N8m3pqPNRWlgnkVo2Gh33p/ABlZrn5jVWeHBPBJQQZOVYUvRQyZUF3FBOsnm0pL0N STLAlxHQRQm1iGk0yBkA6IqB0kILNo1jBXMwBhHoGevb4XLqpyzfNo2n83Zh/CV3pC 87LHsm7gnk3M8O9x88eICVODvGhDKN+svGAvLUck= From: Scott Kitterman To: marf@ietf.org Date: Tue, 04 Oct 2011 14:48:09 -0500 Message-ID: <2118622.RQF7xAMxy8@scott-latitude-e6320> User-Agent: KMail/4.7.1 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <3867829.uIboUR4TA1@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:45:08 -0000 On Tuesday, October 04, 2011 12:25:29 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman > > Sent: Tuesday, October 04, 2011 12:22 PM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > Does it have a constituency? There are quite a number of auth methods > > covered in auth-results that we don't cover and I don't think we should > > extend beyone SPF/DKIM unless someone needs it. > > If we're insisting that we not say you have to report specific ones, then > being completely agnostic seems the right path to me. I don't see how that follows. Perhaps the method specific stuff needs to move to the method specific draft so that if someone wants to (later) do a sender-id draft then the can do it. I'd rather ignore it, but I think making it easier for someone who cares enough about sender-id (or method foo) can do so works too. I don't think overcomplicating the current effort is a good idea. Scott K From msk@cloudmark.com Tue Oct 4 12:59:09 2011 Return-Path: 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 01AC021F8DAE for ; Tue, 4 Oct 2011 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.365, 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 ENm8hddnaTT7 for ; Tue, 4 Oct 2011 12:59:08 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8155821F8DB5 for ; Tue, 4 Oct 2011 12:59:08 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 4 Oct 2011 13:02:14 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 13:02:13 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyCzo8xgkAMe+MQRs6ZMZnhS+EzVAAAXHDw Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <3867829.uIboUR4TA1@scott-latitude-e6320> <2118622.RQF7xAMxy8@scott-latitude-e6320> In-Reply-To: <2118622.RQF7xAMxy8@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 19:59:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Tuesday, October 04, 2011 12:48 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > > If we're insisting that we not say you have to report specific ones, th= en > > being completely agnostic seems the right path to me. >=20 > I don't see how that follows. > > Perhaps the method specific stuff needs to move to the method specific dr= aft so > that if someone wants to (later) do a sender-id draft then the can do it.= I'd > rather ignore it, but I think making it easier for someone who cares enou= gh > about sender-id (or method foo) can do so works too. I don't think > overcomplicating the current effort is a good idea. With the changes you and John proposed to the document in WGLC, the require= ment to report DKIM and SPF results even if you don't check them is gone, a= nd furthermore you don't have to include the other fields that are irreleva= nt to what you did check. It seems to me that leaves us in an agnostic pla= ce with respect to which message authentication methods you're choosing to = execute and report, which satisfies what you and John were after while also= enabling one to report a "sender-id" result. What am I missing with this thinking? From sklist@kitterman.com Tue Oct 4 13:36:37 2011 Return-Path: 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 2CF8221F8C89 for ; Tue, 4 Oct 2011 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 6QnTmCxETPFh for ; Tue, 4 Oct 2011 13:36:36 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 73CF221F8C61 for ; Tue, 4 Oct 2011 13:36:36 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id B0AFC38C143; Tue, 4 Oct 2011 16:39:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317760781; bh=l1WcawASTA3aZsgI8Zxa38c5zSurNKx2tQeOLloNOkI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KHOiT4DRX9e+W92Elclq/7MQU53vNXe5vp8G1XuZjGNa6L2BKx4c0nYSDissqnp4g gTdZy/K3E/NqelFmuRE1f8Ut4oX9tdQR/Dh0kwdtpOER2b9onpJjeUAdBqFRd58N+K iF0SUGcwTlZC8Z1en5SwZRUA2V/R4iEn8jQOhEkM= From: Scott Kitterman To: marf@ietf.org Date: Tue, 04 Oct 2011 15:39:38 -0500 Message-ID: <4440346.fQuy630bCo@scott-latitude-e6320> User-Agent: KMail/4.7.1 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <2118622.RQF7xAMxy8@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:36:37 -0000 On Tuesday, October 04, 2011 01:02:13 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman > > Sent: Tuesday, October 04, 2011 12:48 PM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > > If we're insisting that we not say you have to report specific ones, > > > then being completely agnostic seems the right path to me. > > > > I don't see how that follows. > > > > Perhaps the method specific stuff needs to move to the method specific > > draft so that if someone wants to (later) do a sender-id draft then the > > can do it. I'd rather ignore it, but I think making it easier for > > someone who cares enough about sender-id (or method foo) can do so > > works too. I don't think overcomplicating the current effort is a good > > idea. > > With the changes you and John proposed to the document in WGLC, the > requirement to report DKIM and SPF results even if you don't check them is > gone, and furthermore you don't have to include the other fields that are > irrelevant to what you did check. It seems to me that leaves us in an > agnostic place with respect to which message authentication methods you're > choosing to execute and report, which satisfies what you and John were > after while also enabling one to report a "sender-id" result. > > What am I missing with this thinking? I'm not understanding who plans to use sender-id and why add that and not all the other auth-results? Wd do need to define what to do with results for auth-methods one doesn't implement or understand (ignore them). I don't want to force implementers to deal with having to write code for methods they aren't interested in. It's been 5 years since I took a serious look at the Sender ID specs. I do not know how well the SPF modifier proposed in a Sender ID record. There are some subtle differences between the two record types and someone who was interested enough in Sender ID to investigate it should take a look before we move forward on it. Scott K From msk@cloudmark.com Tue Oct 4 13:44:26 2011 Return-Path: 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 B634921F8D3D for ; Tue, 4 Oct 2011 13:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 FzH0fsZypH5e for ; Tue, 4 Oct 2011 13:44:26 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD821F8D39 for ; Tue, 4 Oct 2011 13:44:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 4 Oct 2011 13:47:10 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 13:47:09 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyC1cAYBDKJLuryQtiL/t138XBScQAANT1A Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <2118622.RQF7xAMxy8@scott-latitude-e6320> <4440346.fQuy630bCo@scott-latitude-e6320> In-Reply-To: <4440346.fQuy630bCo@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:44:26 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, October 04, 2011 1:40 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > I'm not understanding who plans to use sender-id and why add that and not= all > the other auth-results? By removing the limitation on which results get reported, we are in effect = adding all the other ones, at the option of the reporting site. That's wha= t I meant by "agnostic". From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 4 15:09:09 2011 Return-Path: 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 B906421F8F20 for ; Tue, 4 Oct 2011 15:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 lWwT2PrYqH5i for ; Tue, 4 Oct 2011 15:09:08 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7980721F8F08 for ; Tue, 4 Oct 2011 15:09:08 -0700 (PDT) Received: by wwf22 with SMTP id 22so1085583wwf.13 for ; Tue, 04 Oct 2011 15:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VLQSpXA19ZKmFHTenUreOd9r9AlwZmSHt6u4Ppn4F4E=; b=aXoq5Weks21Xj3Udc+Ad10g7gcy7RCWBGK33k+bUS7E3RvIN7XsXnpggDJ17WhbbRN dAswckKb0q3RL+22qiM9mTYRKP3GSe5Sb0Hx5Ey5plBwCfajx9nHtWNqTOqsQeAjYpUO Gff5ftfI8Uy06dD7N81Ttdl7wQUCnRhkHSWHI= Received: by 10.227.19.141 with SMTP id a13mr2218758wbb.62.1317766334089; Tue, 04 Oct 2011 15:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 4 Oct 2011 15:11:34 -0700 (PDT) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> From: Frank Ellermann Date: Wed, 5 Oct 2011 00:11:34 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:09:09 -0000 On 4 October 2011 20:59, Murray S. Kucherawy wrote: [Sender-ID obsolete] > I don't think MARF is in a position to be able to make that > statement explicitly. I was only surprised how the draft managed this *implicitly*. > it seems including a "sender-id" result is on the table. Maybe the IESG will add one of their interesting notes about the (in)compatibilities of STD 4409bis "MAY add sender" and RFC 4407 "PRA". SPF FAIL reports are also weird, SPF FAIL should be rejected, getting rid of the backscatter is the main point of SPF FAIL. There SHOULD NOT be a way how the "purported senders" could "opt-in" to SPF FAIL reports, because that is the point of SPF SOFTFAIL. The [CFWS] in the ABNF makes me also nervous for the known reasons. -Frank From msk@cloudmark.com Tue Oct 4 15:11:21 2011 Return-Path: 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 93AEC21F8F15 for ; Tue, 4 Oct 2011 15:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 22syxox-fwcu for ; Tue, 4 Oct 2011 15:11:21 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 328BA21F8EF2 for ; Tue, 4 Oct 2011 15:11:21 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 4 Oct 2011 15:14:27 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 15:14:26 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyC4q/W4ZZ2xG0CQ4eXIIUfuI3F6QAAChMQ Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:11:21 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Tuesday, October 04, 2011 3:12 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > Maybe the IESG will add one of their interesting notes about > the (in)compatibilities of STD 4409bis "MAY add sender" and > RFC 4407 "PRA". I doubt it. I think the notes affixed to RFCs 4406-4408 are sufficient, or= they would've also added the same note to RFC5451. From dotis@mail-abuse.org Tue Oct 4 16:53:25 2011 Return-Path: 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 9F1C721F8D18 for ; Tue, 4 Oct 2011 16:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=-0.853, 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 jNVUgsMOVJzk for ; Tue, 4 Oct 2011 16:53:25 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE621F8D0D for ; Tue, 4 Oct 2011 16:53:23 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 0116F3B006D for ; Tue, 4 Oct 2011 23:56:26 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 053E9A9443B for ; Tue, 4 Oct 2011 23:56:28 +0000 (UTC) Message-ID: <4E8B9D26.3020503@mail-abuse.org> Date: Tue, 04 Oct 2011 16:56:22 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <2118622.RQF7xAMxy8@scott-latitude-e6320> <4440346.fQuy630bCo@scott-latitude-e6320> In-Reply-To: <4440346.fQuy630bCo@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 23:53:25 -0000 On 10/4/11 1:39 PM, Scott Kitterman wrote: > On Tuesday, October 04, 2011 01:02:13 PM Murray S. Kucherawy wrote: >> With the changes you and John proposed to the document in WGLC, the >> requirement to report DKIM and SPF results even if you don't check them is >> gone, and furthermore you don't have to include the other fields that are >> irrelevant to what you did check. It seems to me that leaves us in an >> agnostic place with respect to which message authentication methods you're >> choosing to execute and report, which satisfies what you and John were >> after while also enabling one to report a "sender-id" result. >> >> What am I missing with this thinking? > I'm not understanding who plans to use sender-id and why add that and not all > the other auth-results? > > Wd do need to define what to do with results for auth-methods one doesn't > implement or understand (ignore them). I don't want to force implementers to > deal with having to write code for methods they aren't interested in. > > It's been 5 years since I took a serious look at the Sender ID specs. I do > not know how well the SPF modifier proposed in a Sender ID record. There are > some subtle differences between the two record types and someone who was > interested enough in Sender ID to investigate it should take a look before we > move forward on it. First, the term authentication does not describe what can be deduced from the application of either DKIM or SPF. DKIM verifies a domain signed a portion of a message. DKIM verification does not confirm the domain submitted the message to the unsolicited recipient, the common reason for issuing feedback. Some view SPF as a method for domains to authorize the return path to ensure DSNs. Some receivers extend this authorization as a potentially inaccurate method for assessing accountability. While accountability could be safely extended to the EHLO, it might be inaccurately extended to the Mail From (return path), or the PRA. When based upon the Mail From or the PRA, SPF verification will not reliably select domains accountable for messages. It is fairly common for domains to share common outbound MTAs. Disputes about whether SPF applies to the Mail From or to the PRA as delineated from an SPF address list confound the accuracy of the deductions. Feedback should attempt to report what the purported domain intended. After all, SPF syntax often fails to exclude possible mis-interpretations. Did the purported domain expect their authorization to apply to the: 1 - EHLO 2 - Return Path 3 - PRA If so, how was such intent confirmed? Critical aspects related DKIM/SPF feedback should clarify any remaining ambiguity within the reporting scheme. To better assure against any remaining ambiguity, there should be some type of indication whether the MARF source-IP address was used in the SPF confirmation. This information is not normally included in the Authentication-Results headers. SPF allows for non-address confirmation methods, but disambiguating this issue has been missed in the MARF report details. There should also be confirmation what message element was used to confirm the purported domain as well. -Doug From sklist@kitterman.com Tue Oct 4 22:02:54 2011 Return-Path: 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 5004421F8ABE for ; Tue, 4 Oct 2011 22:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 EzN929H2X7AY for ; Tue, 4 Oct 2011 22:02:53 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7D21F8562 for ; Tue, 4 Oct 2011 22:02:52 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 607FB38C143; Wed, 5 Oct 2011 01:05:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317791158; bh=fLiI0aSEMc67+W8esvSGv2e2EJEdf3EJZ+X68x9g/6I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Yi2s4PIaAOH+r/60kDg/WLLDSIqY3uUDvLRSqNfQnqsLV+PTRB8J7MOxwbeY9uzgW 4LZ6+AlCBc67ngbNmfhsAbxAqK9MYteixLGEPsBVRiH6oEpdpD9hNlYBkrqjznUsns lOPB0Pk6ytBxr0xngu7sj8uTjyAwzj+vI2ftpRus= From: Scott Kitterman To: marf@ietf.org Date: Wed, 05 Oct 2011 00:05:50 -0500 Message-ID: <1507769.MCPVjvD4o9@scott-latitude-e6320> User-Agent: KMail/4.7.1 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <4440346.fQuy630bCo@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 05:02:54 -0000 On Tuesday, October 04, 2011 01:47:09 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Tuesday, October 04, 2011 1:40 PM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > I'm not understanding who plans to use sender-id and why add that and > > not all the other auth-results? > > By removing the limitation on which results get reported, we are in effect > adding all the other ones, at the option of the reporting site. That's > what I meant by "agnostic". No. I think not. Both paragraph 3.2 and 3.3 have DKIM and SPF specific requirements that are not sufficient for other authentication types. Yes, the actual header might refer to other types, but without the additional diagnostic information in from 3.2/3.3. At the very least sender-id would have to be added to the list of authentication failure types in 3.3 (I propose we not do this and just focus on DKIM/SPF). BTW, looking at this again has caused me to notice that spf-dns isn't referred to anywhere in 3.2/3.3. There should be a 3.2.3 for SPF reports that requires spf-dns fields for all SPF records used to process the message. Scott K From msk@cloudmark.com Tue Oct 4 22:12:55 2011 Return-Path: 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 BB92421F8672 for ; Tue, 4 Oct 2011 22:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.463 X-Spam-Level: X-Spam-Status: No, score=-103.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 yiGOwT0Q1Rkv for ; Tue, 4 Oct 2011 22:12:55 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5146F21F862F for ; Tue, 4 Oct 2011 22:12:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 4 Oct 2011 22:15:58 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 4 Oct 2011 22:15:56 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyDHILPI6jEzOe9TMW4km6Bpa/rwwAAEn8A Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <4440346.fQuy630bCo@scott-latitude-e6320> <1507769.MCPVjvD4o9@scott-latitude-e6320> In-Reply-To: <1507769.MCPVjvD4o9@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 05:12:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, October 04, 2011 10:06 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > No. I think not. Both paragraph 3.2 and 3.3 have DKIM and SPF specific > requirements that are not sufficient for other authentication types. Yes,= the > actual header might refer to other types, but without the additional > diagnostic information in from 3.2/3.3. Right. So if you're reporting for DKIM, there are extra provisions include= d to allow relaying of meta-data specific to that method. If you want don'= t want to report on DKIM, you leave out the relevant fields. If you want t= o report on something else, you'd have to craft an update to this document. For SPF, I don't think there's any meta-data that needs its own field in th= is kind of report, since Authentication-Results would carry that informatio= n already. So we're already there. > At the very least sender-id would have to be added to the list of > authentication failure types in 3.3 (I propose we not do this and just fo= cus > on DKIM/SPF). If we want to be complete about it, perhaps 3.3 should become an IANA actio= n to create a registry for authentication failure types. Then someone want= ing to add support for Sender-ID or some other method could register a new = failure mode and all the various extra fields that it requires (if any). But you're probably right (as is John) that "spf" should probably be broken= out, since there are more than one DKIM failure mode enumerated already. Does that sound right? -MSK From johnl@iecc.com Wed Oct 5 05:58:29 2011 Return-Path: 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 F289921F8CDC for ; Wed, 5 Oct 2011 05:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.12 X-Spam-Level: X-Spam-Status: No, score=-111.12 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 KhPzh8vGRPiP for ; Wed, 5 Oct 2011 05:58:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9321F8CD9 for ; Wed, 5 Oct 2011 05:58:27 -0700 (PDT) Received: (qmail 85614 invoked from network); 5 Oct 2011 13:01:34 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 5 Oct 2011 13:01:34 -0000 Received: (qmail 45025 invoked from network); 5 Oct 2011 13:01:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Oct 2011 13:01:34 -0000 Date: 5 Oct 2011 13:01:11 -0000 Message-ID: <20111005130111.65001.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 12:58:29 -0000 >For SPF, I don't think there's any meta-data that needs its own field in >this kind of report, since Authentication-Results would carry that >information already. So we're already there. I would want the included DNS records. R's, John From msk@cloudmark.com Wed Oct 5 07:24:02 2011 Return-Path: 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 2F5FE21F8E00 for ; Wed, 5 Oct 2011 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 Hbq07RrBtrbZ for ; Wed, 5 Oct 2011 07:24:00 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id D190321F8DFA for ; Wed, 5 Oct 2011 07:23:58 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 5 Oct 2011 07:27:05 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 5 Oct 2011 07:27:03 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyDXuoFPq7hGPVuTjmOiHNFDrBkpQAC+Qhg Message-ID: References: <20111005130111.65001.qmail@joyce.lan> In-Reply-To: <20111005130111.65001.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:24:02 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA1LCAyMDExIDY6 MDEgQU0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4g U3ViamVjdDogUmU6IFttYXJmXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1 cmUtcmVwb3J0LTAxLnR4dA0KPiANCj4gPkZvciBTUEYsIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBh bnkgbWV0YS1kYXRhIHRoYXQgbmVlZHMgaXRzIG93biBmaWVsZCBpbg0KPiA+dGhpcyBraW5kIG9m IHJlcG9ydCwgc2luY2UgQXV0aGVudGljYXRpb24tUmVzdWx0cyB3b3VsZCBjYXJyeSB0aGF0DQo+ ID5pbmZvcm1hdGlvbiBhbHJlYWR5LiAgU28gd2UncmUgYWxyZWFkeSB0aGVyZS4NCj4gDQo+IEkg d291bGQgd2FudCB0aGUgaW5jbHVkZWQgRE5TIHJlY29yZHMuDQoNCkFoLCByaWdodCwgYnV0IHRo YXQncyBhbHJlYWR5IGluIHRoZSBkcmFmdCB0b28uDQoNCg== From sklist@kitterman.com Wed Oct 5 07:39:20 2011 Return-Path: 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 48F8821F8D6A for ; Wed, 5 Oct 2011 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 xpjyxV6p7+RE for ; Wed, 5 Oct 2011 07:39:15 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8410A21F8D75 for ; Wed, 5 Oct 2011 07:39:15 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id BB6FE38C108; Wed, 5 Oct 2011 10:42:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317825743; bh=oEqPD9lyUgDhxABHAqJ8br7Pqi4dYV8fz1dqs7FzAnw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pVW3f1Lm1ft13ONqXocLO8kYmiMCXbyysqmXs7xvJeMAt1RN9O+/80uqOi9naKNeN Uf1c+bz6gQ14FKOzsuTHFda/ddN8S1kkPoD0eJFPX5x7nqWwfZyFRwNGxziXeTtP3A ONQGbbv///UePNIf8a/c2gLZu4TvrA53BaAOU5X4= From: Scott Kitterman To: marf@ietf.org Date: Wed, 05 Oct 2011 09:42:15 -0500 Message-ID: <73245296.PyMlRmgRMA@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <1507769.MCPVjvD4o9@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:39:20 -0000 On Tuesday, October 04, 2011 10:15:56 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Tuesday, October 04, 2011 10:06 PM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > No. I think not. Both paragraph 3.2 and 3.3 have DKIM and SPF specific > > requirements that are not sufficient for other authentication types. > > Yes, the actual header might refer to other types, but without the > > additional diagnostic information in from 3.2/3.3. > > Right. So if you're reporting for DKIM, there are extra provisions included > to allow relaying of meta-data specific to that method. If you want don't > want to report on DKIM, you leave out the relevant fields. If you want to > report on something else, you'd have to craft an update to this document. > > For SPF, I don't think there's any meta-data that needs its own field in > this kind of report, since Authentication-Results would carry that > information already. So we're already there. Providing the DNS records is what would make this really useful. I'd like to see that required for this report type (as I tried to put in my last mail and John suggested). > > At the very least sender-id would have to be added to the list of > > authentication failure types in 3.3 (I propose we not do this and just > > focus on DKIM/SPF). > > If we want to be complete about it, perhaps 3.3 should become an IANA action > to create a registry for authentication failure types. Then someone > wanting to add support for Sender-ID or some other method could register a > new failure mode and all the various extra fields that it requires (if > any). I think this document could be made more generic pretty easily by leveraging the IANA registries that were created by RFC 5451. I think it's reasonable to allow for reports for any authentication type listed in: http://www.iana.org/assignments/email-auth/email-auth.xml And then result codes would come from: http://www.iana.org/assignments/email-auth/email-auth.xml There is a bit of a problem here that the registry doesn't match the RFC 4408 results exactly (fail versus hardfail). That's a bit unfortunate, but the train has left the station. I think this draft should match 5451 terminology. The only SPF faliure type that I think needs to be broken out is temperror. For that type you want the DNS RCODE and query type (TXT versus SPF) and the domain name being looked up to support trouble shooting. I think that this is probably true for all DNS based auth methods. I don't think another IANA registry is needed. I'd like to see this draft add a method independent response for temperror (as above) that should serve for any auth method. I'd like to see 3.2 have an SPF specific requirement for including the record(s) used to process the message. Later RFCs could deal with other methods listed in the registry and add method specific requirements. Since they would encapsulate the method they were dealing with, I don't think a registry is needed. > But you're probably right (as is John) that "spf" should probably be broken > out, since there are more than one DKIM failure mode enumerated already. > > Does that sound right? Only for temperror (and I don't think that's actually SPF specific) as the DNS record(s) and IP address is what you want for all the other failure types. Scott K From sklist@kitterman.com Wed Oct 5 07:48:13 2011 Return-Path: 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 2831021F8B42 for ; Wed, 5 Oct 2011 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 EvVS97wW4m93 for ; Wed, 5 Oct 2011 07:48:08 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9B58821F8B2E for ; Wed, 5 Oct 2011 07:48:08 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8696138C108; Wed, 5 Oct 2011 10:51:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317826276; bh=hz1MyXVK84/bz1nsIT/irtAPFRtgzHO7BPex9QoSnbI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BmckHav6V2QcfapcIv6X/mHixNd6K7+CODeTqOpanBJKPoZLsfB+EySCCOkQiANxJ smaA1UyKNAu2R59FDx29U6ccrR6sLM0RrUMUoHE7rhp4R4qLjvU9bdMKHcOHbDIXpV aavkD9iXQTgpAtFAV0Z2jQ12qJqKXPF1QkGTYn9I= From: Scott Kitterman To: marf@ietf.org Date: Wed, 05 Oct 2011 09:48:19 -0500 Message-ID: <2154859.oQhx2Gfm39@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20111005130111.65001.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:48:13 -0000 On Wednesday, October 05, 2011 07:27:03 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: John Levine [mailto:johnl@taugh.com] > > Sent: Wednesday, October 05, 2011 6:01 AM > > To: marf@ietf.org > > Cc: Murray S. Kucherawy > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > >For SPF, I don't think there's any meta-data that needs its own field > > >in > > >this kind of report, since Authentication-Results would carry that > > >information already. So we're already there. > > > > I would want the included DNS records. > > Ah, right, but that's already in the draft too. It's in the ABNF, but no where referenced, so sort of. We should make it required. Scott K From johnl@iecc.com Wed Oct 5 08:40:47 2011 Return-Path: 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 4E63D21F8D7B for ; Wed, 5 Oct 2011 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.122 X-Spam-Level: X-Spam-Status: No, score=-111.122 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 9yqBWY1jkUUa for ; Wed, 5 Oct 2011 08:40:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 876BA21F8CE6 for ; Wed, 5 Oct 2011 08:40:46 -0700 (PDT) Received: (qmail 91638 invoked from network); 5 Oct 2011 15:43:53 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 5 Oct 2011 15:43:53 -0000 Received: (qmail 34803 invoked from network); 5 Oct 2011 15:43:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Oct 2011 15:43:53 -0000 Date: 5 Oct 2011 15:43:29 -0000 Message-ID: <20111005154329.4577.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <2154859.oQhx2Gfm39@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:40:47 -0000 >> > I would want the included DNS records. >> >> Ah, right, but that's already in the draft too. > >It's in the ABNF, but no where referenced, so sort of. We should make it >required. I see SPF-DNS: "something" Let's say you were reporting an SPF failure for microsoft.com. There is a TXT record at microsoft.com which is an SPF record that has four include's. There is another TXT record that looks like some base64. Can you show what the DNS part of the ARF report would look like? R's, John From johnl@iecc.com Wed Oct 5 08:48:54 2011 Return-Path: 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 05E4A21F8CF2 for ; Wed, 5 Oct 2011 08:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.123 X-Spam-Level: X-Spam-Status: No, score=-111.123 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 58g9x69OowoR for ; Wed, 5 Oct 2011 08:48:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6266C21F8CEA for ; Wed, 5 Oct 2011 08:48:53 -0700 (PDT) Received: (qmail 92036 invoked from network); 5 Oct 2011 15:51:59 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 5 Oct 2011 15:51:59 -0000 Received: (qmail 38268 invoked from network); 5 Oct 2011 15:51:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Oct 2011 15:51:59 -0000 Date: 5 Oct 2011 15:51:35 -0000 Message-ID: <20111005155135.4833.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <73245296.PyMlRmgRMA@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:48:54 -0000 >The only SPF faliure type that I think needs to be broken out is temperror. Given the complexity of the rules for interpreting SPF records, it's not out of the question that a reported failure could be due to the reporter interpreting them wrong. For example, each of the included SPF records at microsoft.com ends with ~all, which isn't supposed to end the SPF check, but I wouldn't be surprised if there were some code somewhere that gets it wrong. If you're going to return a different result for tempfail, what reason is there not to return whatever result the SPF checker returned, rather than combining the other various kinds of failures? >For that type you want the DNS RCODE and query type (TXT versus SPF) and the >domain name being looked up to support trouble shooting. I think that this is >probably true for all DNS based auth methods. You're probably right, but it's starting to feel like feature creep. R's, John From sklist@kitterman.com Wed Oct 5 11:12:04 2011 Return-Path: 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 2BA3121F8C0E for ; Wed, 5 Oct 2011 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 lN1dp+eP1Sza for ; Wed, 5 Oct 2011 11:12:03 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1A21F8C0D for ; Wed, 5 Oct 2011 11:12:03 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7AE0038C108; Wed, 5 Oct 2011 14:15:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317838511; bh=8WB2/QoVchvtk9GDPN2fCrkjSKlugfBH8dzGrIdMD00=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EqFpRxgyCdOLqKYaeSqQ+dQUsRlDG7lvaEjaDGA1HsmfnuJ31BQ14R6z2MaXTND6S zaJ5JW2RYBE5aCCmYdd2JJ0keS2CIfGNCQgp7kG8qcltLSf7ty+rOtlHvzVvdTOwik 6Py/LUR6Egw/6hhcSReSHIgtAmAhYa2PdAbvejM8= From: Scott Kitterman To: marf@ietf.org Date: Wed, 05 Oct 2011 13:15:04 -0500 Message-ID: <2484320.816u5PLtCi@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: <20111005155135.4833.qmail@joyce.lan> References: <20111005155135.4833.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:12:04 -0000 On Wednesday, October 05, 2011 03:51:35 PM John Levine wrote: > >The only SPF faliure type that I think needs to be broken out is > >temperror. > Given the complexity of the rules for interpreting SPF records, it's not > out of the question that a reported failure could be due to the reporter > interpreting them wrong. For example, each of the included SPF records > at microsoft.com ends with ~all, which isn't supposed to end the SPF > check, but I wouldn't be surprised if there were some code somewhere that > gets it wrong. > > If you're going to return a different result for tempfail, what reason > is there not to return whatever result the SPF checker returned, rather > than combining the other various kinds of failures? I think temperror for all the relevant auth methods refers to some kind of DNS error, so it's different. Other than that, I think the SPF results all need the same information (result and record(s)), so I don't think they need to be broken out. > >For that type you want the DNS RCODE and query type (TXT versus SPF) and > >the domain name being looked up to support trouble shooting. I think > >that this is probably true for all DNS based auth methods. > > You're probably right, but it's starting to feel like feature creep. Agreed. It would be nice, but it's not essential. If we don't provide DNS information for temperror, then there's no need to break out the different types of SPF failures the information you want is the same, the record (and what domain it was from). I think it would be generally useful, but it is added complexity. I'm not sure if it's worth it. Which brings up another point: spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF should probably be: spf-dns = "SPF-DNS:" [CFWS] domain ":" [CFWS] quoted-string [CFWS] CRLF so in the case of multiple records being returned it's clear where they came from. Scott K From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 12:17:40 2011 Return-Path: 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 C44901F0C63 for ; Wed, 5 Oct 2011 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 SRrr5eSfXhzb for ; Wed, 5 Oct 2011 12:17:40 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21C961F0C54 for ; Wed, 5 Oct 2011 12:17:39 -0700 (PDT) Received: by wwn22 with SMTP id 22so6841517wwn.1 for ; Wed, 05 Oct 2011 12:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VKLr5NzHdsNWnfb4YOqx/tHClHAFZfb6ETg60lBlqmw=; b=URCaN3LuCrxc0cuYyWW8Z3XK2/2CYf1SgiPJV/VHM3iZaJP0cWY4bX+YY0pkhVauUD fbB4lT2/WVUnBrX2on/CXp/55aICdkcz5AgWumtdc8830efxHfXX/oLU1fltCTPk3kli kKV4TNj7LSbO0otJ1PlTmMhBRa8SRp4iO9BGA= Received: by 10.227.200.15 with SMTP id eu15mr3469375wbb.77.1317842448149; Wed, 05 Oct 2011 12:20:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 12:20:08 -0700 (PDT) In-Reply-To: <20111005130111.65001.qmail@joyce.lan> References: <20111005130111.65001.qmail@joyce.lan> From: Frank Ellermann Date: Wed, 5 Oct 2011 21:20:08 +0200 Message-ID: To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:17:40 -0000 On 5 October 2011 15:01, John Levine wrote: [SPF report] > I would want the included DNS records. You're supposed to know what included policies in your SPF policy do. I have no problem with adding the info in the reports, but I don't see the point yet. Are you talking about unexpected or even temporary changes of included 3rd party policies? -Frank From johnl@taugh.com Wed Oct 5 12:40:53 2011 Return-Path: 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 F23AD11E80D9 for ; Wed, 5 Oct 2011 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 8-a++SKco6aL for ; Wed, 5 Oct 2011 12:40:52 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1007311E80C2 for ; Wed, 5 Oct 2011 12:40:51 -0700 (PDT) Received: (qmail 1961 invoked from network); 5 Oct 2011 19:43:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7a8.4e8cb37e.k1110; bh=oq/kkGwH51fx9HVTKqzAQ8CfClAVcjEYC9Opdlw0WwM=; b=NOhGQo2YQbF+l4MAvxao6cew2HxOXDO/ckyo2tDUxpdwPzNko6Y3c6bKJ8d1PRayaYt9CbuUq9rgccFYJt0dxPB9uSHCT70J16HvgwCJ3u+YnFFFwjqVrq2mtMrq4RuRLlRbINCcySi6/A2RsGgnboiiuPieXfmZImYbZtkAS6I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7a8.4e8cb37e.k1110; bh=oq/kkGwH51fx9HVTKqzAQ8CfClAVcjEYC9Opdlw0WwM=; b=RAGuw7ZgzRmj1ZxzV+yrLwVzkMr5HJqFFnaKReXnqLtV5YygUFwM5I8bSU/NnmRQRBCadlHu/dTRxLAgZ+yAsup50+na1d6jJ4bCZ7eklNG3jkxVefNNbN8rW9vCFwg5TuV+cHDig1wo+tKJfB2BtPFPlJ5L/nOWME2Ie66H57U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Oct 2011 19:43:35 -0000 Date: 5 Oct 2011 15:43:54 -0400 Message-ID: From: "John R Levine" To: "Frank Ellermann" In-Reply-To: References: <20111005130111.65001.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ARF mailing list Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:40:53 -0000 > [SPF report] >> I would want the included DNS records. > > You're supposed to know what included policies in your SPF policy > do. Of course, but you cannot always assume that the SPF records that people see are the ones you think you published. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From jdfalk-lists@cybernothing.org Wed Oct 5 13:41:02 2011 Return-Path: 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 CF06B11E8109 for ; Wed, 5 Oct 2011 13:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 lxnxl4JZWE+G for ; Wed, 5 Oct 2011 13:41:02 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4105A11E80F1 for ; Wed, 5 Oct 2011 13:41:02 -0700 (PDT) Received: from [192.168.11.37] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p95Ki7VO022766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 5 Oct 2011 13:44:09 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Wed, 5 Oct 2011 13:44:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:41:02 -0000 On Oct 4, 2011, at 3:11 PM, Frank Ellermann wrote: > SPF FAIL reports are also weird, SPF FAIL should be rejected, > getting rid of the backscatter is the main point of SPF FAIL. >=20 > There SHOULD NOT be a way how the "purported senders" could > "opt-in" to SPF FAIL reports, because that is the point of > SPF SOFTFAIL. The [CFWS] in the ABNF makes me also nervous > for the known reasons. Some sites don't reject on SPF FAIL alone, preferring to add that datum = to a scoring or reputation system to determine what to do with the = message. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 5 18:35:23 2011 Return-Path: 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 1E84A1F0C52 for ; Wed, 5 Oct 2011 18:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 ztMTPII5+RJk for ; Wed, 5 Oct 2011 18:35:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9811F0C54 for ; Wed, 5 Oct 2011 18:35:22 -0700 (PDT) Received: by wwf22 with SMTP id 22so2429691wwf.13 for ; Wed, 05 Oct 2011 18:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zOPQc7C4hBNLdTGeBPufmQlegDhJ5xpgHtXqEnw/wxI=; b=T6q5aW9FbouHUs5de/jP+prWvJrzT8d9S4u1UBrZwL7geAO0jKJqYKPHfvAj9qiVUk TzVg1Xi8VdDDxvCRZwd36IuCXW19IPSo5Cg2x4OQdXvZ7IWOCuQfIlhpRquVErokba2a 1poINjBXKIW39LkAWu1quS21jPov/gPopXOHQ= Received: by 10.227.11.81 with SMTP id s17mr205194wbs.62.1317865111114; Wed, 05 Oct 2011 18:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 5 Oct 2011 18:37:51 -0700 (PDT) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> From: Frank Ellermann Date: Thu, 6 Oct 2011 03:37:51 +0200 Message-ID: To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 01:35:23 -0000 On 5 October 2011 22:44, J.D. Falk wrote: > Some sites don't reject on SPF FAIL alone, preferring to add that > datum to a scoring or reputation system to determine what to do > with the message. That's their choice. I'd still claim that this is "lossy" (sender with a broken policy will never know that his mail rots in some junk folder and will be eventually purged.) If the sender wants to debug such issues they can use SOFTFAIL, and hopefully get reports. The concept of a FAIL report confuses me, because it's at odds with the SPF FAIL semantics. As you said this would anyway only affect receivers accepting FAIL. BTW, SPF already permits a kind of tracking based on its "exists:" mechanism not directly depending on the receiver policy. (Unless "we never evaluate 'exists:'" is a part of this receiver policy.) I'm no fan of these baroque SPF features, but they exist, and the draft should mention that SPF FAIL reports are a rather odd idea. -Frank From msk@cloudmark.com Wed Oct 5 21:45:04 2011 Return-Path: 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 255F111E808B for ; Wed, 5 Oct 2011 21:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.962 X-Spam-Level: X-Spam-Status: No, score=-103.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 ylA0Fi2abDL0 for ; Wed, 5 Oct 2011 21:45:03 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9312411E8082 for ; Wed, 5 Oct 2011 21:45:03 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 5 Oct 2011 21:48:12 -0700 From: "Murray S. Kucherawy" To: ARF mailing list Date: Wed, 5 Oct 2011 21:48:12 -0700 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting feedback Thread-Index: AcyBHDWp6YCfwClIQGePMxELXY1ApACohuCw Message-ID: References: In-Reply-To: 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] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 04:45:04 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn R Levine > Sent: Sunday, October 02, 2011 8:59 AM > To: ARF mailing list > Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback >=20 > I presume the motivation for this is that you have a few people who want = to use > it to debug DKIM failures. That's perfectly reasonable, but if people al= ready > know each other, they can use private agreements with no need to standard= ize > anything. That is indeed the prime motivation. It also has helped to have this sort = of information around so that future implementations can add similar debugg= ing features, as this expedites the exchange of exactly the kind of data th= at's needed to find problems. So you're right that the target population is small, but the need to intero= perate properly in that context out of the starting gate is pretty valuable= . But, admittedly, there's not much harm to getting it wrong, or indeed no= t doing it at all. > This strikes me as a poor thing to standardize for a variety of reasons. = One is > that the number of people debugging a protocol is less by many orders of > magnitude than the number who are just using it, and to the users, debugg= ing > features are just cruft. Would it perhaps be better to make it Informational rather than Standards T= rack? It's been in use (though with the aforementioned small audience) for= several years now, so it at least seems useful to write it down. > Also, to some extent this is an invitation to > mailbomb anyone who uses it, True, but that could also be argued about email addresses in SOA records, R= FC2142 reporting addresses, etc. I think that ship has sailed. -MSK From msk@cloudmark.com Wed Oct 5 21:45:09 2011 Return-Path: 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 B0DB911E80AC for ; Wed, 5 Oct 2011 21:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.77 X-Spam-Level: X-Spam-Status: No, score=-98.77 tagged_above=-999 required=5 tests=[AWL=-4.559, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044, 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 bZquz0qi2scV for ; Wed, 5 Oct 2011 21:45:08 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B8E1711E80AB for ; Wed, 5 Oct 2011 21:45:08 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 5 Oct 2011 21:48:18 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 5 Oct 2011 21:48:18 -0700 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting feedback Thread-Index: Acx/pen7WTucZqtBSWeaRHTBXT38hgEGSBpg Message-ID: References: <8BF70BBB-4AC7-4E8F-A22B-3B2DEBDB1893@wordtothewise.com> In-Reply-To: <8BF70BBB-4AC7-4E8F-A22B-3B2DEBDB1893@wordtothewise.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] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 04:45:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Friday, September 30, 2011 12:20 PM > To: Message Abuse Report Format working group > Subject: [marf] draft-ietf-marf-dkim-reporting feedback >=20 > 1. Who would want it and their existing alternatives. >=20 > This seems to be a feature that will primarily be of interest to bulk > emailers. Those senders are interested in many facets of email > delivery, and have existing networks of probe addresses at many ISPs > which they use to monitor email delivery. Those probe networks can > already give them most of the same information that this would provide, > without any requirement for support by the receiving ISP. The main motivation (for me, at least) is implementers that need to debug u= nexplained failures. Setting up a test address at a problem site can help,= but doesn't always as doing so presumes what happens between (for example)= DKIM validation and mailbox retrieval makes no changes to the message, and= that's not always the case. > 2. Where in the delivery path does it detect errors, and whether > organizations causing errors are likely to deploy this sort of code >=20 > It seems to be intended to detect DKIM-invalidating modifications "at > the receiver", I would say "at or before the receiver" is more precise. > as it's fairly easy for a sender to identify problems > that are near to them. Receivers who have a "non-DKIM-clean" delivery > path seem like the least likely receivers to add additional DKIM/ADSP- > specific baggage to their delivery path - so I'm not sure that > something like this would be likely to be deployed at the receiving > ISPs where the feedback would likely need to be generated. Unless it's > intended for MUA deployment, maybe? MUAs could also do it, to be sure. I'm not sure I understand the rest of w= hat you're saying here; why would a receiver with a "dirty" delivery path n= ot want to identify the problem? Surely they'd start to get pressure from = signers that want to get valid signatures through delivery. > 3. Implementation nits >=20 > 3a. Inconsistent flags for in-band reporting >=20 > There are some nits too. You can ask for a magic cookie in the > rejection string using rs=3D - which is good, as that can be handled well > by existing delivery log monitoring tracking. But rs=3D is not valid > unless there's an r=3D field that's asking for reports to be sent to a > specific address. r=3D is being overloaded as both a boolean ("do some > sort of reporting") and as a parameter to one particular sort of > reporting (via sending an email). Unless that's there for backwards > compatibility I'd be tempted to split the two. That'd be OK with me. For backward compatibility, I'd probably leave "r=3D= " as a reporting address and add some other key tag for declaring that repo= rting is requested. > 3b. Does this define an email address for reports, or just a local > part? >=20 > r=3D "MUST be a dkim-quoted-printable string containing an e-mail > address", yet it "MUST be interpreted as a local part only". The > examples tell me that it's just a local part, and doesn't have an "@" > sign in it, but the spec should probably be clarified. Fair enough. > 4. Sampling may be useful, but probably not if it can only be applied > identically to all receivers >=20 > I don't see ri=3D as being particularly useful given the way I expect > this would be used, as that value is shared across all receivers. I'm > either going to want a report about every failure, or I'm going to want > summary reports. If Gmail are having very rare DKIM failures on my mail > - one in a million, say - I'm going to want to see every one. If > Earthlink are breaking everything I send, I'm going to want summary > reports. I can't get both, so I'm going to end up leaving it set to "0" > and summarizing at my end. If it were in the format of "no more than X > reports every Y seconds" it might make more immediate sense than simply > reporting every n-th message, maybe. That would also avoid the problems > in 8.3 and would allow the sender more control over the issues in 8.5. That change would be fine as well. Interesting point about per-receiver ra= tes though; hadn't thought of that. > 5. In-band advertising vs out-of-band vs overloading DKIM >=20 > For many use cases this functionality could be handled by in-band > advertising (e.g. a "DKIM-Errors-To: foo@bar.com" header). Interesting idea as well. What do others think? > It could also be handled via a separate DNS lookup, rather than > overloading the existing DKIM key record. I'm trying to piggyback on retrieving the key record. At the time this was= designed, most of the squawking about DKIM's load (especially with ADSP ri= ght behind it) had to do with the DNS load it would create. > Does the increase in size of the DKIM key record cause significant cost > (especially in the case where it causes the already large key record to > expand so that it's over the size that can be efficiently / reliably > handled over UDP)? That was actually a secondary motivation for constraining "r=3D" to be a lo= cal-part only. In my own observations, there are keys that pass the TCP li= mit and those that don't, but very few are close, which means "r=3D" wouldn= 't usually be the thing that pushes a record over the limit. > 6. Would something broader be more useful? >=20 > This is very specific to DKIM or ADSP failures. If it is useful for the > sender to be notified of one sort of authentication failure, they'll > probably be interested in notification of other failures (SPF?). Yep, and that's why there's also an "spf-reporting" draft. The issue, thou= gh, is that for a failure of DKIM, a different set of data is useful for de= bugging versus an SPF failure. That seems to suggest different extension d= ocuments is an appropriate path. > 7. Would something narrower be as useful? >=20 > The rs=3D magic cookie in the rejection string seems like the most useful > part of this. At large ISPs almost all rejections are handled during > the SMTP session, and DKIM checking is happening at the external MX, > not at an internal handoff. In the larger picture I'd say that's probably the most visible part of this= work, but I don't think it's the most valuable for debugging failures. Th= e canonicalized forms of the header/body at the receiver is what's most imp= ortant in that case. > Rather than specifying an out-of-band asynchronous notification via > email at all, would this concept be just as useful if it only included > the magic cookie in the rejection string? It's not everything I'm after, at least. Perhaps there should be two repor= ting modes, one that only involves the "rs=3D" and one that involves return= ing the data needed for debugging? > (If I were starting from scratch rather than doing something specific > for DKIM, I probably wouldn't add all this to the DKIM key record or > the ADSP record at all - I'd use a separate name space to stash the > data in, so that if you were to see a DKIM auth failure from me, you'd > do a query for > "mta3.cloudmark.com.dkim._authenticationfailure.wordtothewise.com" and > do what that TXT record asked. Creative use of wildcarding would let me > set a general "I'd like to know about it" policy, while setting much > more verbose reporting while I was diagnosing delivery to a particular > recipient ISP. And I'd also be able to have > "*.spf._authenticationfailure.wordtothewise.com", > "*.adsp._authenticationfailure.wordtothewise.com" and so on. But that's > a whole other discussion.) It's a discussion worth having. Other than wanting to shorten "_authentica= tionfailure", I'd like to explore it a little. I'm worried about backward = compatibility with the work as-is though, where "r=3D" is a DKIM key record= tag. This would require replacing all of that code. -MSK From sklist@kitterman.com Wed Oct 5 22:07:51 2011 Return-Path: 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 1E41C21F8591 for ; Wed, 5 Oct 2011 22:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 5Mg4mTAUBqY3 for ; Wed, 5 Oct 2011 22:07:50 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 33C3121F858D for ; Wed, 5 Oct 2011 22:07:50 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 5E89538C110; Thu, 6 Oct 2011 01:10:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317877858; bh=fi4tZxbOQX5+O16UPUEYIQ8DKWJcs6JpAASvJsfz3C0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=I44uNSD4dG9J6xrN8dJky7bdp8fuE8CcXa8g/DMjxVhTNGWrsCU39fbDaSlX6fLNR s23jlRtQYlHtHItoiypAL5/rVwFsM8U7NIrNwog4keftJaYd9ABm59Y69IOjrOmy99 VjrH813eLtZhz/iM+aRFpnDkznGb9/RfFmc+hjHU= From: Scott Kitterman To: marf@ietf.org Date: Thu, 06 Oct 2011 00:10:55 -0500 Message-ID: <1473360.4orhUjFNDR@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <8BF70BBB-4AC7-4E8F-A22B-3B2DEBDB1893@wordtothewise.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] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 05:07:51 -0000 On Wednesday, October 05, 2011 09:48:18 PM Murray S. Kucherawy wrote: > > 5. In-band advertising vs out-of-band vs overloading DKIM > > > > > > > > For many use cases this functionality could be handled by in-band > > advertising (e.g. a "DKIM-Errors-To: foo@bar.com" header). > > Interesting idea as well. What do others think? I thought we concluded that we wanted the reporting address to be localpart only plus the signing domain to preclude people using these records as a vector to mail bomb somebody else. If so, that would be true for this approach too. Since this is a message with a failed signature, I don't know if that content is valid, whereas if it's in the DNS record, then I know (modulo DNS spoofing) that it's provided by the domain owner. From a security/reliability perspective I think in-band is much weaker. Scott K From msk@cloudmark.com Wed Oct 5 22:31:07 2011 Return-Path: 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 942C721F8CAF for ; Wed, 5 Oct 2011 22:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=-0.348, 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 uBXOrfy0vTbn for ; Wed, 5 Oct 2011 22:31:06 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7B21F8C8C for ; Wed, 5 Oct 2011 22:31:06 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 5 Oct 2011 22:34:16 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 5 Oct 2011 22:34:15 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyDbQMjtGscDsaNSB+zG+XwmLkpiAAfE/hA Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <1507769.MCPVjvD4o9@scott-latitude-e6320> <73245296.PyMlRmgRMA@scott-latitude-e6320> In-Reply-To: <73245296.PyMlRmgRMA@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 05:31:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, October 05, 2011 7:42 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > I think this document could be made more generic pretty easily by leverag= ing > the IANA registries that were created by RFC 5451. I think it's reasonab= le to > allow for reports for any authentication type listed in: >=20 > http://www.iana.org/assignments/email-auth/email-auth.xml >=20 > And then result codes would come from: >=20 > http://www.iana.org/assignments/email-auth/email-auth.xml I agree. > There is a bit of a problem here that the registry doesn't match the RFC = 4408 > results exactly (fail versus hardfail). That's a bit unfortunate, but th= e > train has left the station. I think this draft should match 5451 > terminology. An erratum was opened against RFC5451 about this too. Maybe this would be = a good time to update the registry accordingly. > The only SPF faliure type that I think needs to be broken out is temperro= r. > For that type you want the DNS RCODE and query type (TXT versus SPF) and = the > domain name being looked up to support trouble shooting. I think that th= is is > probably true for all DNS based auth methods. >=20 > I don't think another IANA registry is needed. Agree here too. > I'd like to see this draft add a method independent response for temperro= r (as > above) that should serve for any auth method. >=20 > I'd like to see 3.2 have an SPF specific requirement for including the > record(s) used to process the message. Can you propose some text changes? From msk@cloudmark.com Wed Oct 5 22:31:40 2011 Return-Path: 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 59FA721F8CDC for ; Wed, 5 Oct 2011 22:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 NaZDkD25m9zy for ; Wed, 5 Oct 2011 22:31:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C114C21F8C8C for ; Wed, 5 Oct 2011 22:31:39 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 5 Oct 2011 22:34:49 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 5 Oct 2011 22:34:48 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyDbkBtjf74gXuHQHSPZOsAsQWz5AAe1wyg Message-ID: References: <20111005130111.65001.qmail@joyce.lan> <2154859.oQhx2Gfm39@scott-latitude-e6320> In-Reply-To: <2154859.oQhx2Gfm39@scott-latitude-e6320> 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 05:31:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, October 05, 2011 7:48 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > > > I would want the included DNS records. > > > > Ah, right, but that's already in the draft too. >=20 > It's in the ABNF, but no where referenced, so sort of. We should make it > required. Yeah, I just noticed that. Agreed. From msk@cloudmark.com Wed Oct 5 22:34:19 2011 Return-Path: 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 7AB7A21F8CDC for ; Wed, 5 Oct 2011 22:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=-0.348, 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 5eil9Ye1DuVK for ; Wed, 5 Oct 2011 22:34:19 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79D21F8CDB for ; Wed, 5 Oct 2011 22:34:19 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 5 Oct 2011 22:37:27 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 5 Oct 2011 22:37:26 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcyDyK4YYMXGskVaQWqpyrFYWotvGQAISYmw Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: 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] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 05:34:19 -0000 While discussing all of these points, can we start providing specific text = changes for Hilda to incorporate? The next version is going to be a pretty= substantial set of changes, so we may as well start trying to reach consen= sus on specific text. I'll prepare some tomorrow and send it along while I'm on a cross-country f= light. Hopefully others can do the same. -MSK, wearing both hats for this one From shmuel+gen@patriot.net Thu Oct 6 05:28:43 2011 Return-Path: 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 1F5F221F8C22 for ; Thu, 6 Oct 2011 05:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 EoliaVALBxiQ for ; Thu, 6 Oct 2011 05:28:42 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51B21F8C1F for ; Thu, 6 Oct 2011 05:28:42 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.239]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 5BA13F580A9 for ; Thu, 6 Oct 2011 08:20:31 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 05 Oct 2011 18:02:59 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111006122033.5BA13F580A9@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 12:28:43 -0000 In , on 10/05/2011 at 09:20 PM, Frank Ellermann said: >You're supposed to know what included policies in your SPF policy >do. If you never change them. If you change them then you'd want to know whether the reporter had seen the old version or the new. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From hfontana@ecertsystems.com Thu Oct 6 07:33:36 2011 Return-Path: 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 976C321F8CF4 for ; Thu, 6 Oct 2011 07:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 948b12L2D7Bi for ; Thu, 6 Oct 2011 07:33:36 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 14FFB21F8C22 for ; Thu, 6 Oct 2011 07:33:35 -0700 (PDT) Received: by pzk37 with SMTP id 37so7169845pzk.9 for ; Thu, 06 Oct 2011 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=TjGaaJgOYt1UEVDb3otmPBkGO45YBinTCTsGWcwEZdo=; b=gsL6S6QIQvRMuPVyiZDB0oHyudgByA06y5J+hU2ZWhR6SbO/vRcLFpGgEOi1Yjk2ka rzrvop4B4fZL5RrTJbA7J29/E0KObr5u1CciCyGN+jLFHm2m7GLsN0Ro07+OmaEHWVsU Z3+zBlhtux4nlGhdFA1Rre1tlZO8eetz+LvGE= Received: by 10.68.31.132 with SMTP id a4mr6350013pbi.26.1317911806616; Thu, 06 Oct 2011 07:36:46 -0700 (PDT) Received: from [192.168.1.68] (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id h5sm20097123pbq.11.2011.10.06.07.36.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Oct 2011 07:36:44 -0700 (PDT) References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8G4) From: Hfontana Date: Thu, 6 Oct 2011 07:36:40 -0700 To: "Murray S. Kucherawy" Cc: Message Abuse Report Format working group Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:33:36 -0000 Thanks Murray that would be very helpful. On Oct 5, 2011, at 10:37 PM, "Murray S. Kucherawy" wrote= : > While discussing all of these points, can we start providing specific text= changes for Hilda to incorporate? The next version is going to be a pretty= substantial set of changes, so we may as well start trying to reach consens= us on specific text. >=20 > I'll prepare some tomorrow and send it along while I'm on a cross-country f= light. Hopefully others can do the same. >=20 > -MSK, wearing both hats for this one > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From iesg-secretary@ietf.org Thu Oct 6 09:01:36 2011 Return-Path: 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 3D63F1F0C41; Thu, 6 Oct 2011 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 RDszlMdA2ieK; Thu, 6 Oct 2011 09:01:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89A1F0C45; Thu, 6 Oct 2011 09:01:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006160135.31686.63499.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 09:01:35 -0700 Cc: marf mailing list , marf chair , RFC Editor Subject: [marf] Protocol Action: 'Email Feedback Report Type Value : not-spam' to Proposed Standard (draft-ietf-marf-not-spam-feedback-03.txt) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 16:01:36 -0000 The IESG has approved the following document: - 'Email Feedback Report Type Value : not-spam' (draft-ietf-marf-not-spam-feedback-03.txt) as a Proposed Standard This document is the product of the Messaging Abuse Reporting Format Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ Technical Summary This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report a message that was mistakenly marked as spam. Working Group Summary The Working Group found this a simple and non-controversial extension. Document Quality This extension is added to parallel similar capabilities in the mobile equivalent of ARF, known as SpamRep. In that light, there are existing implementations on the mobile side, and this work seeks to maintain the same parallelism that otherwise already exists. Thus, the requirement for this capability has already received thorough review and assent within the OMA. Personnel Murray S. Kucherawy is the document shepherd. Pete Resnick is the responsible AD. From johnl@iecc.com Thu Oct 6 17:01:09 2011 Return-Path: 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 4AB0121F8C1E for ; Thu, 6 Oct 2011 17:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.125 X-Spam-Level: X-Spam-Status: No, score=-112.125 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 y6Bcuhg5NvDM for ; Thu, 6 Oct 2011 17:01:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AB70421F8C1D for ; Thu, 6 Oct 2011 17:01:08 -0700 (PDT) Received: (qmail 65360 invoked from network); 7 Oct 2011 00:04:19 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 7 Oct 2011 00:04:19 -0000 Received: (qmail 66066 invoked from network); 7 Oct 2011 00:04:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Oct 2011 00:04:19 -0000 Date: 7 Oct 2011 00:03:57 -0000 Message-ID: <20111007000357.69888.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 00:01:09 -0000 >Would it perhaps be better to make it Informational rather than >Standards Track? It's been in use (though with the aforementioned >small audience) for several years now, so it at least seems useful to >write it down. Sure. That gives people a place to start in the (to me, unlikely) event that there's enough demand for this to standardize it. >> Also, to some extent this is an invitation to >> mailbomb anyone who uses it, > >True, but that could also be argued about email addresses in SOA >records, RFC2142 reporting addresses, etc. I think that ship has >sailed. I suppose you're right, there. R's, John From johnl@iecc.com Thu Oct 6 19:41:12 2011 Return-Path: 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 578F111E807F for ; Thu, 6 Oct 2011 19:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.147 X-Spam-Level: X-Spam-Status: No, score=-111.147 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 12XlDe7JdR0W for ; Thu, 6 Oct 2011 19:41:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7A21F8B07 for ; Thu, 6 Oct 2011 19:41:11 -0700 (PDT) Received: (qmail 71095 invoked from network); 7 Oct 2011 02:44:21 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 7 Oct 2011 02:44:21 -0000 Received: (qmail 18629 invoked from network); 7 Oct 2011 02:44:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Oct 2011 02:44:21 -0000 Date: 7 Oct 2011 02:43:59 -0000 Message-ID: <20111007024359.58175.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Text for draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 02:41:12 -0000 I'm still a little unclear about what's supposed to happen if you're reporting multiple failures, but here's some suggestions for the single failure case: In 3.1: Authentication-Results: This field MUST be formatted as defined in [AUTH-RESULTS]. This field MUST appear at least once, and it is RECOMMENDED that the corresponding header fields be copied directly from the message about which a report is being generated. Original-Envelope-Id: As specified in [ARF]. This field SHOULD appear if the relevant data are available. Original-Mail-From: As specified in [ARF]. This field SHOULD appear if the relevant data are available. Source-IP: As specified in [ARF]. This field SHOULD appear if the relevant data are available. Delete Message-ID section Delivery-Result: As specified in Section 3.2.1. This field is optional and MUST NOT appear more than once. Add DKIM-DNS. DKIM-DNS: A copy of the DKIM key record retrieved from the DNS. This field SHOULD be present if the relevant data are available. Note that the record name can be deduced from the DKIM-Domain and DKIM-Selector values. SPF-DNS: Copies of the DNS records used to evaluate an SPF result. This field SHOULD appear at least once for SPF results, unless the result was due to no records were available and MAY occur multiple times if the primary SPF record included other records. In 3.3, take out the failures that don't happen in the current DKIM, granularity I think. Replace the "spf" result with the list of results in section 2.5 of RFC 4408. Section 4, change the spf-dns to include the record name: spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] quoted-string [CFWS] CRLF Section 6, update to reflect changed names and values. From sklist@kitterman.com Thu Oct 6 19:42:45 2011 Return-Path: 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 F107E21F8906 for ; Thu, 6 Oct 2011 19:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 tSi8FQdaXHIk for ; Thu, 6 Oct 2011 19:42:45 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0421F8888 for ; Thu, 6 Oct 2011 19:42:45 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6B3A138C112; Thu, 6 Oct 2011 22:45:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317955555; bh=tUGQfTBDAvg+4RXG9EBxz+eW8z4St138da3vTPguwJk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OdGLlr+m10KlwCqn/2N9yf9efJE9xUoeDaGIz5cDaz4EHm4+GGLNrB1XXP0auJMmU b6Yv/FhmpEO3zmvEJexnHrDJL78t/w1pj/SbOAE6nfl2udf7BHFOpohx4p2XnHjLrg C+w7CflXMC/sIEh2NwuD/dMEpdzhqpwSTiOztRGU= From: Scott Kitterman To: marf@ietf.org Date: Thu, 06 Oct 2011 21:45:53 -0500 Message-ID: <1664306.ksJsbNgP4s@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <73245296.PyMlRmgRMA@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1393651.gVAu0KJqNH" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 02:42:46 -0000 --nextPart1393651.gVAu0KJqNH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, October 05, 2011 10:34:15 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, October 05, 2011 7:42 AM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > I think this document could be made more generic pretty easily by > > leveraging the IANA registries that were created by RFC 5451. I think > > it's reasonable to allow for reports for any authentication type listed > > in: > > > > http://www.iana.org/assignments/email-auth/email-auth.xml > > > > And then result codes would come from: > > > > http://www.iana.org/assignments/email-auth/email-auth.xml > > I agree. > > > There is a bit of a problem here that the registry doesn't match the RFC > > 4408 results exactly (fail versus hardfail). That's a bit unfortunate, > > but the train has left the station. I think this draft should match > > 5451 terminology. > > An erratum was opened against RFC5451 about this too. Maybe this would be a > good time to update the registry accordingly. I think so. The difference will won't get better with age. > > The only SPF faliure type that I think needs to be broken out is > > temperror. For that type you want the DNS RCODE and query type (TXT > > versus SPF) and the domain name being looked up to support trouble > > shooting. I think that this is probably true for all DNS based auth > > methods. > > > > I don't think another IANA registry is needed. > > Agree here too. > > > I'd like to see this draft add a method independent response for > > temperror (as above) that should serve for any auth method. > > > > I'd like to see 3.2 have an SPF specific requirement for including the > > record(s) used to process the message. > > Can you propose some text changes? Here's a crack at changes for 3.2. Scott K --nextPart1393651.gVAu0KJqNH Content-Disposition: attachment; filename="patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="patch" --- draft-ietf-marf-authfailure-report-02.txt 2011-09-08 21:14:14.000000000 -0500 +++ draft-ietf-marf-authfailure-report-02.txt.new 2011-10-06 21:40:35.161212801 -0500 @@ -256,11 +256,6 @@ Arrival-Date: As specified in [ARF]. This field MUST appear exactly once. - Source-IP: As specified in [ARF]. This field MUST appear exactly - once. If this information is either not available at the time the - report is generated, or the generating ADMD's policy requires it - be redacted, a value of 0.0.0.0 MUST be used. - Message-ID: As specified in [ARF]. This field MUST appear exactly once. @@ -349,6 +344,18 @@ DKIM-Selector: The selector of the signature that failed verification, taken from the "s=" tag of the signature. +3.2.3. Required for SPF Reports + + SPF-DNS: The domain(s) and related SPF record(s) used to make the + SPF evalutation. MUST appear one or more times. In addition to + the primary record used, additional records used due to make the + evaluation due to include mechanisms or redirect modifiers MUST + also be included. + + Source-IP: As specified in [ARF]. This field MUST appear exactly + once unless the IP address is not available + + 3.3. Authentication Failure Types The list of defined authentication failure types, used in the "Auth- @@ -427,7 +434,7 @@ dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS] quoted-string [CFWS] CRLF - spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF + spf-dns = "SPF-DNS:" [CFWS] domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF --nextPart1393651.gVAu0KJqNH-- From msk@cloudmark.com Thu Oct 6 21:50:14 2011 Return-Path: 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 8261521F8B85 for ; Thu, 6 Oct 2011 21:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WvSHsgO2z2E5 for ; Thu, 6 Oct 2011 21:50:11 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8221F8B7B for ; Thu, 6 Oct 2011 21:50:11 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 6 Oct 2011 21:53:23 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 6 Oct 2011 21:53:22 -0700 Thread-Topic: Suggested changes to draft-ietf-marf-authfailure-report Thread-Index: AcyElrfJkd2bvlteSEulFAA7O6eh1A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C45D9EEEEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 04:50:14 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C45D9EEEEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To aid Hilda in preparing an update, here are some of the changes I think c= onsensus appears to support with respect to a revision of draft-ietf-marf-a= uthfailure-report. Please let me know if I have any of it wrong. Some of = these are point notes and not exact text changes, but should be enough for = her to make the edits. Abstract - New text: "This memo registers an extension report type to ARF f= or use in reporting messages that fail one or more authentication checks pe= rformed on receipt of a message, with the option to include forensic inform= ation describing the specifics of the failure." Section 1 - New text: "[ARF] defines a message format for sending reports of= abuse in the messaging infrastructure, with an eye towards automating both= the generation and consumption of those reports. There is now also a desi= re to use extend the ARF format to include reporting of messages that fail = to authenticate using known authentication methods, as these are sometimes = evidence of abuse that can be detected and reported through automated means= . The same mechanism can be used to convey forensic information about the = specific reason the authentication method failed. Thus, this memo presents= such extensions to the Abuse Reporting Format to allow for detailed report= ing of message authentication failures." Section 3.1 - Authentication-Results MUST appear at least once, and SHOULD rep= ort all methods that were tested by the entity generating the report. It M= UST be formatted according to [AUTH-RESULTS]. - Original-Envelope-Id SHOULD be included exactly once if it is av= ailable to the entity generating the report. - Original-Mail-From and Source-IP SHOULD be included exactly once= for SPF, or for other methods that evaluate authentication during the SMTP= phase. Remove the stuff about 0.0.0.0. - Delete Message-ID, as it is available in the third part of the r= eport. - Delete Arrival-Date, as it's not relevant to DKIM or SPF specifi= cally, and can be inferred from both report generation time and the Receive= d fields in the third part of the report. - Reported-Domain MUST appear at least once (not exactly once). - Delivery-Result is OPTIONAL, MUST NOT appear more than once. If= present, it SHOULD indicate the outcome, etc. Section 3.2.2 - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body to ne= w section 3.2.3. New Section 3.2.3: Optional for DKIM reports - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body here. - Add a paragraph that says DKIM-Canonicalized-Header and DKIM-Can= onicalized-Body MUST NOT include redacted data. The data presented there h= ave to be exactly the canonicalized header and body as defined by [DKIM] an= d computed at the verifier. This is because these fields are intended to a= id in identifying message alterations that invalidate DKIM signatures in tr= ansit. Including redacted data in them renders the data unusable. (See al= so Section 5 and Section 7.6 for further discussion.) New Section 3.2.4: Required for ADSP Reports - DKIM-ADSP-DNS: Includes the ADSP record discovered and applied b= y the entity generating this report. - New Section 3.2.5: Required for SPF Reports - SPF-DNS MUST appear once for every query to an SPF record that w= as done, to enable the reporting of included fields and where they came fro= m. The ABNF in Section 4 changes; see below. Section 3.3 - The new set of failure modes is: dkim-adsp, dkim-bodyhash, dkim-= revoked, dkim-signature, spf-fail, spf-softfail, spf-permerror. "granulari= ty" is no longer a valid DKIM result, so it should be deleted. The descrip= tive text can stay for the DKIM ones, and the SPF ones can be copy-and-past= ed accordingly (should be fairly straightforward). Section 4 - SPF-DNS ABNF changes to: { "txt" / "spf" } [FWS] ":" [FWS] domai= n [FWS] ":" [FWS] quoted-string Section 5 - Delete the second paragraph. This seems to be a sufficient pari= ng down given the other new text about it that I've suggested here. Section 7.1 - Correct spelling of "implementers". Section 7.4 - Replace with: "In the case of transmitted reports in the form of= a new message, it is necessary to consider the construction and transmissi= on of the message so as to avoid amplification attacks, deliberate or other= wise. See Section 5 of [ARF] for further information." New Section 7.6: Redaction Of Data In DKIM Reports - Suggested text: "This memo requires that the canonicalized heade= r and body be returned without being subject to redaction when a DKIM failu= re is being reported. This is necessary to ensure that the returned canoni= calized forms are useful for debugging as they must be compared to the equi= valent form at the signer. If a message is altered in transit, and the ret= urned data are also redacted, the redacted portion and the altered portion = may overlap, rendering the comparison results meaningless. However, unreda= cted data can leak information the reporting entity considers to be private= . It is for this reason the return of the canonicalized forms is rendered = optional." Appendix A - Add the names of people that contributed to this feedback, altho= ugh they get wrist-slapped for waiting until the last minute to do so. :) Appendix B - Replace the URL in the example with "RFC5965". -MSK --_000_F5833273385BB34F99288B3648C4F06F19C45D9EEEEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To aid Hilda in = preparing an update, here are some of the changes I think consensus appears= to support with respect to a revision of draft-ietf-marf-authfailure-repor= t.  Please let me know if I have any of it wrong.  Some of these = are point notes and not exact text changes, but should be enough for her to= make the edits.

 

Abstract

 <= /o:p>

-      =     New text: “This memo regis= ters an extension report type to ARF for use in reporting messages that fai= l one or more authentication checks performed on receipt of a message, with= the option to include forensic information describing the specifics of the= failure.”

 

Section 1

 =

-      = ;    New text: “[ARF] defines = a message format for sending reports of abuse in the messaging infrastructu= re, with an eye towards automating both the generation and consumption of t= hose reports.  There is now also a desire to use extend the ARF format= to include reporting of messages that fail to authenticate using known aut= hentication methods, as these are sometimes evidence of abuse that can be d= etected and reported through automated means.  The same mechanism can = be used to convey forensic information about the specific reason the authen= tication method failed.  Thus, this memo presents such extensions to t= he Abuse Reporting Format to allow for detailed reporting of message authen= tication failures.”

 

Section 3.1

=  

-    =       Authentication-Resul= ts MUST appear at least once, and SHOULD report all methods that were teste= d by the entity generating the report.  It MUST be formatted according= to [AUTH-RESULTS].

-  = ;        Origina= l-Envelope-Id SHOULD be included exactly once if it is available to the ent= ity generating the report.

-&nb= sp;         Original-Mail-From and Source-IP SHOULD be included exactly once for SPF, = or for other methods that evaluate authentication during the SMTP phase.&nb= sp; Remove the stuff about 0.0.0.0.

-          <= ![endif]>Delete Message-ID, as it is available in the third part of the rep= ort.

-    &n= bsp;     Delete Arrival-Date, a= s it’s not relevant to DKIM or SPF specifically, and can be inferred = from both report generation time and the Received fields in the third part = of the report.

-  &nbs= p;       Reported-Dom= ain MUST appear at least once (not exactly once).

-          <= /span>Delivery-Result is OPTIONAL, MUST NOT appear more th= an once.  If present, it SHOULD indicate the outcome, etc.<= /p>

 

Section 3= .2.2

 

-          Move DKIM-Canonicalized-Header and DKIM-Canonicalized-B= ody to new section 3.2.3.

 

New Section 3.2.3: Optional for DKIM reports

 

-          Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body her= e.

-    &nbs= p;     Add a paragraph that say= s DKIM-Canonicalized-Header and DKIM-Canonicalized-Body MUST NOT include re= dacted data.  The data presented there have to be exactly the canonica= lized header and body as defined by [DKIM] and computed at the verifier.&nb= sp; This is because these fields are intended to aid in identifying message= alterations that invalidate DKIM signatures in transit.  Including re= dacted data in them renders the data unusable.  (See also Section 5 an= d Section 7.6 for further discussion.)

<= o:p> 

New Section 3.2.4: Required for AD= SP Reports

 

-         = ; DKIM-ADSP-DNS: Includes the ADSP record discovere= d and applied by the entity generating this report.

-         = ;  

New Sec= tion 3.2.5: Required for SPF Reports

 

-    &nb= sp;     SPF-DNS MUST appear onc= e for every query to an SPF record that was done, to enable the reporting o= f included fields and where they came from.  The ABNF in Section 4 cha= nges; see below.

 

Section 3.3

&nbs= p;

-     &nb= sp;    The new set of failure modes = is: dkim-adsp, dkim-bodyhash, dkim-revoked, dkim-signature, spf-fail, spf-s= oftfail, spf-permerror.  “granularity” is no longer a vali= d DKIM result, so it should be deleted.  The descriptive text can stay= for the DKIM ones, and the SPF ones can be copy-and-pasted accordingly (sh= ould be fairly straightforward).

&n= bsp;

Section 4

 

-   &= nbsp;      SPF-DNS ABNF ch= anges to: { “txt” / “spf” } [FWS] “:” [= FWS] domain [FWS] “:” [FWS] quoted-string

 

Section 5

-     &n= bsp;    Delete the second paragraph.=   This seems to be a sufficient paring down given the other new text a= bout it that I’ve suggested here.

=  

Section 7.1

 

- &n= bsp;        Corr= ect spelling of “implementers”.

 

Section 7.4

 

- =          Re= place with: “In the case of transmitted reports in the form of a new = message, it is necessary to consider the construction and transmission of t= he message so as to avoid amplification attacks, deliberate or otherwise.&n= bsp; See Section 5 of [ARF] for further information.”

<= p class=3DMsoNormal> 

New Section 7= .6: Redaction Of Data In DKIM Reports

 

-    &n= bsp;     Suggested text: “= ;This memo requires that the canonicalized header and body be returned with= out being subject to redaction when a DKIM failure is being reported. = This is necessary to ensure that the returned canonicalized forms are usef= ul for debugging as they must be compared to the equivalent form at the sig= ner.  If a message is altered in transit, and the returned data are al= so redacted, the redacted portion and the altered portion may overlap, rend= ering the comparison results meaningless.  However, unredacted data ca= n leak information the reporting entity considers to be private.  It i= s for this reason the return of the canonicalized forms is rendered optiona= l.”

 

Appendix A

 

-      &nbs= p;   Add the names of people that contrib= uted to this feedback, although they get wrist-slapped for waiting until th= e last minute to do so.  J

 

Appendix B

 

-        &= nbsp; Replace the URL in the example with “RF= C5965”.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C45D9EEEEXCHC2corpclo_-- From hfontana@ecertsystems.com Fri Oct 7 08:31:46 2011 Return-Path: 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 9F59F21F8C19 for ; Fri, 7 Oct 2011 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 MwYMzgv0-Jb9 for ; Fri, 7 Oct 2011 08:31:42 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF0521F87D6 for ; Fri, 7 Oct 2011 08:31:41 -0700 (PDT) Received: by yxt33 with SMTP id 33so4564856yxt.31 for ; Fri, 07 Oct 2011 08:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language :disposition-notification-to; bh=D0T1lJGNw75csLviw2kUwQ075OsSt5dkJ5J9BOP+fuQ=; b=XTbEIgTEaZXqYnJZXk0cII9EH/93FTCZNSHDbIS5KMQ7w2aAY8EkNKdNvaXfLl1ClV eoRdZBZb05rHeDzRTVeNqiF1izDvElI35sUNSkKIEzK48pc5eRsMvPpGAuBwV4GZjrHY HSOri4OHTLys2ZIBi1R6LYZ9np11DbDLZ9DAs= Received: by 10.68.56.225 with SMTP id d1mr14810890pbq.109.1318001695047; Fri, 07 Oct 2011 08:34:55 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id p4sm32331408pbs.6.2011.10.07.08.34.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 08:34:52 -0700 (PDT) From: "Hilda Fontana" To: "'Murray S. Kucherawy'" , "'Message Abuse Report Format working group'" References: In-Reply-To: Date: Fri, 7 Oct 2011 08:34:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CC84CB.EC615110" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGeQl0NXdOR5Bx1M4HRP4+M425egJXNiAHw Content-Language: en-us Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:31:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01CC84CB.EC615110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Murray and everyone for your input. I shall put a draft together with these changes and get it posted as soon as I can. From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, October 06, 2011 9:53 PM To: Message Abuse Report Format working group Subject: [marf] Suggested changes to draft-ietf-marf-authfailure-report To aid Hilda in preparing an update, here are some of the changes I think consensus appears to support with respect to a revision of draft-ietf-marf-authfailure-report. Please let me know if I have any of it wrong. Some of these are point notes and not exact text changes, but should be enough for her to make the edits. Abstract - New text: "This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure." Section 1 - New text: "[ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye towards automating both the generation and consumption of those reports. There is now also a desire to use extend the ARF format to include reporting of messages that fail to authenticate using known authentication methods, as these are sometimes evidence of abuse that can be detected and reported through automated means. The same mechanism can be used to convey forensic information about the specific reason the authentication method failed. Thus, this memo presents such extensions to the Abuse Reporting Format to allow for detailed reporting of message authentication failures." Section 3.1 - Authentication-Results MUST appear at least once, and SHOULD report all methods that were tested by the entity generating the report. It MUST be formatted according to [AUTH-RESULTS]. - Original-Envelope-Id SHOULD be included exactly once if it is available to the entity generating the report. - Original-Mail-From and Source-IP SHOULD be included exactly once for SPF, or for other methods that evaluate authentication during the SMTP phase. Remove the stuff about 0.0.0.0. - Delete Message-ID, as it is available in the third part of the report. - Delete Arrival-Date, as it's not relevant to DKIM or SPF specifically, and can be inferred from both report generation time and the Received fields in the third part of the report. - Reported-Domain MUST appear at least once (not exactly once). - Delivery-Result is OPTIONAL, MUST NOT appear more than once. If present, it SHOULD indicate the outcome, etc. Section 3.2.2 - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body to new section 3.2.3. New Section 3.2.3: Optional for DKIM reports - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body here. - Add a paragraph that says DKIM-Canonicalized-Header and DKIM-Canonicalized-Body MUST NOT include redacted data. The data presented there have to be exactly the canonicalized header and body as defined by [DKIM] and computed at the verifier. This is because these fields are intended to aid in identifying message alterations that invalidate DKIM signatures in transit. Including redacted data in them renders the data unusable. (See also Section 5 and Section 7.6 for further discussion.) New Section 3.2.4: Required for ADSP Reports - DKIM-ADSP-DNS: Includes the ADSP record discovered and applied by the entity generating this report. - New Section 3.2.5: Required for SPF Reports - SPF-DNS MUST appear once for every query to an SPF record that was done, to enable the reporting of included fields and where they came from. The ABNF in Section 4 changes; see below. Section 3.3 - The new set of failure modes is: dkim-adsp, dkim-bodyhash, dkim-revoked, dkim-signature, spf-fail, spf-softfail, spf-permerror. "granularity" is no longer a valid DKIM result, so it should be deleted. The descriptive text can stay for the DKIM ones, and the SPF ones can be copy-and-pasted accordingly (should be fairly straightforward). Section 4 - SPF-DNS ABNF changes to: { "txt" / "spf" } [FWS] ":" [FWS] domain [FWS] ":" [FWS] quoted-string Section 5 - Delete the second paragraph. This seems to be a sufficient paring down given the other new text about it that I've suggested here. Section 7.1 - Correct spelling of "implementers". Section 7.4 - Replace with: "In the case of transmitted reports in the form of a new message, it is necessary to consider the construction and transmission of the message so as to avoid amplification attacks, deliberate or otherwise. See Section 5 of [ARF] for further information." New Section 7.6: Redaction Of Data In DKIM Reports - Suggested text: "This memo requires that the canonicalized header and body be returned without being subject to redaction when a DKIM failure is being reported. This is necessary to ensure that the returned canonicalized forms are useful for debugging as they must be compared to the equivalent form at the signer. If a message is altered in transit, and the returned data are also redacted, the redacted portion and the altered portion may overlap, rendering the comparison results meaningless. However, unredacted data can leak information the reporting entity considers to be private. It is for this reason the return of the canonicalized forms is rendered optional." Appendix A - Add the names of people that contributed to this feedback, although they get wrist-slapped for waiting until the last minute to do so. J Appendix B - Replace the URL in the example with "RFC5965". -MSK ------=_NextPart_000_002B_01CC84CB.EC615110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Murray and everyone for your input.  = I shall put a draft together with these changes and get it posted as = soon as I can. 

 

From:= = marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Thursday, October 06, 2011 9:53 = PM
To: Message Abuse Report Format working = group
Subject: [marf] Suggested changes to = draft-ietf-marf-authfailure-report

 

To aid Hilda = in preparing an update, here are some of the changes I think consensus = appears to support with respect to a revision of = draft-ietf-marf-authfailure-report.  Please let me know if I have = any of it wrong.  Some of these are point notes and not exact text = changes, but should be enough for her to make the = edits.

 

Abstract

 

-          = New text: “This memo registers an = extension report type to ARF for use in reporting messages that fail one = or more authentication checks performed on receipt of a message, with = the option to include forensic information describing the specifics of = the failure.”

 

Section = 1

 

-          = New text: “[ARF] defines a message format = for sending reports of abuse in the messaging infrastructure, with an = eye towards automating both the generation and consumption of those = reports.  There is now also a desire to use extend the ARF format = to include reporting of messages that fail to authenticate using known = authentication methods, as these are sometimes evidence of abuse that = can be detected and reported through automated means.  The same = mechanism can be used to convey forensic information about the specific = reason the authentication method failed.  Thus, this memo presents = such extensions to the Abuse Reporting Format to allow for detailed = reporting of message authentication failures.”

 

Section = 3.1

 

-          = Authentication-Results MUST appear at least = once, and SHOULD report all methods that were tested by the entity = generating the report.  It MUST be formatted according to = [AUTH-RESULTS].

-          = Original-Envelope-Id SHOULD be included exactly = once if it is available to the entity generating the = report.

-          = Original-Mail-From and Source-IP SHOULD be = included exactly once for SPF, or for other methods that evaluate = authentication during the SMTP phase.  Remove the stuff about = 0.0.0.0.

-          = Delete Message-ID, as it is available in the = third part of the report.

-          = Delete Arrival-Date, as it’s not relevant = to DKIM or SPF specifically, and can be inferred from both report = generation time and the Received fields in the third part of the = report.

-          = Reported-Domain MUST appear at least once (not = exactly once).

-          = Delivery-Result is OPTIONAL, MUST NOT appear = more than once.  If present, it SHOULD indicate the outcome, = etc.

 

Section 3.2.2

 

-          = Move DKIM-Canonicalized-Header and = DKIM-Canonicalized-Body to new section 3.2.3.

 

New Section = 3.2.3: Optional for DKIM reports

 

-          = Move DKIM-Canonicalized-Header and = DKIM-Canonicalized-Body here.

-          = Add a paragraph that says = DKIM-Canonicalized-Header and DKIM-Canonicalized-Body MUST NOT include = redacted data.  The data presented there have to be exactly the = canonicalized header and body as defined by [DKIM] and computed at the = verifier.  This is because these fields are intended to aid in = identifying message alterations that invalidate DKIM signatures in = transit.  Including redacted data in them renders the data = unusable.  (See also Section 5 and Section 7.6 for further = discussion.)

 

New Section 3.2.4: Required for ADSP = Reports

 

-          = DKIM-ADSP-DNS: Includes the ADSP record = discovered and applied by the entity generating this = report.

-          =  

New = Section 3.2.5: Required for SPF Reports

 

-          = SPF-DNS MUST appear once for every query to an = SPF record that was done, to enable the reporting of included fields and = where they came from.  The ABNF in Section 4 changes; see = below.

 

Section 3.3

 

-          = The new set of failure modes is: dkim-adsp, = dkim-bodyhash, dkim-revoked, dkim-signature, spf-fail, spf-softfail, = spf-permerror.  “granularity” is no longer a valid DKIM = result, so it should be deleted.  The descriptive text can stay for = the DKIM ones, and the SPF ones can be copy-and-pasted accordingly = (should be fairly straightforward).

 

Section = 4

 

-          = SPF-DNS ABNF changes to: { “txt” / = “spf” } [FWS] “:” [FWS] domain [FWS] = “:” [FWS] quoted-string

 

Section 5

-          = Delete the second paragraph.  This seems to = be a sufficient paring down given the other new text about it that = I’ve suggested here.

 

Section = 7.1

 

-          = Correct spelling of = “implementers”.

 

Section = 7.4

 

-          = Replace with: “In the case of transmitted = reports in the form of a new message, it is necessary to consider the = construction and transmission of the message so as to avoid = amplification attacks, deliberate or otherwise.  See Section 5 of = [ARF] for further information.”

 

New Section = 7.6: Redaction Of Data In DKIM Reports

 

-          = Suggested text: “This memo requires that = the canonicalized header and body be returned without being subject to = redaction when a DKIM failure is being reported.  This is necessary = to ensure that the returned canonicalized forms are useful for debugging = as they must be compared to the equivalent form at the signer.  If = a message is altered in transit, and the returned data are also = redacted, the redacted portion and the altered portion may overlap, = rendering the comparison results meaningless.  However, unredacted = data can leak information the reporting entity considers to be = private.  It is for this reason the return of the canonicalized = forms is rendered optional.”

 

Appendix = A

 

-          = Add the names of people that contributed to this = feedback, although they get wrist-slapped for waiting until the last = minute to do so.  J

 

Appendix = B

 

-          = Replace the URL in the example with = “RFC5965”.

 

-MSK

------=_NextPart_000_002B_01CC84CB.EC615110-- From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Oct 7 14:33:51 2011 Return-Path: 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 0EB7421F8AD2 for ; Fri, 7 Oct 2011 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 GoAkzaGJWtny for ; Fri, 7 Oct 2011 14:33:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBE21F8726 for ; Fri, 7 Oct 2011 14:33:50 -0700 (PDT) Received: by wyg24 with SMTP id 24so1407653wyg.31 for ; Fri, 07 Oct 2011 14:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=f+Wic1ua3ekeCvjg+2Dmk+uSTjj8lb+pG0GqoLV6JEY=; b=P6MYocECXmsLI2XR90YwuYxZ+9tW358gLGkXqH2qpIEimgO2afCN/yIltNWlHktTkY R2OnV8bdup0mwtBRldpKTkBGoMBZYMIcB9H1b37O81P9ayitb3e2xCgM+lf+sI1uaYfm Wx07TtdauGAzT+9aM195nLzzK+de+6dn7SnuI= Received: by 10.227.200.15 with SMTP id eu15mr3026126wbb.77.1318023424164; Fri, 07 Oct 2011 14:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Fri, 7 Oct 2011 14:36:24 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Fri, 7 Oct 2011 23:36:24 +0200 Message-ID: To: Hilda Fontana Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 21:33:51 -0000 On 7 October 2011 17:34, Hilda Fontana wrote: > Thanks Murray and everyone for your input.=A0 I shall put a draft > together with these changes and get it posted as soon as I can. >> Please let me know if I have any of it wrong. >> New text: =93This memo registers an extension report type to ARF >> for use in reporting messages that fail one or more authentication >> checks performed on receipt of a message [...] Maybe s/suthentication/authorization or authentication/ to address one concern of Doug Otis. I'd really prefer to stay out of these terminology nits, but if adding 20 characters helps to get rid of one recycled vintage 2006 dispute... -Frank From bhill@paypal-inc.com Fri Oct 7 16:07:33 2011 Return-Path: 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 07C3A21F8B2E for ; Fri, 7 Oct 2011 16:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8] 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 Em7pUHhbREE9 for ; Fri, 7 Oct 2011 16:07:27 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id EE00421F8888 for ; Fri, 7 Oct 2011 16:07:26 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: From:To:Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:Return-Path: X-CFilter; b=D3CWeWyHrTbdTvRdnTeOLOWz00UA1ZU7uAQae8jcMzvOfxpPLHgEGWeK y+KMvMrQmpm05E5eZ19lYjaPQtdcUj+9ZEb6XXB8XshfvgcHFXKAsMVLO NWmOsbjSMlcDaVF; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1318029042; x=1349565042; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w+gU79WWugtJqX8oeW3TeszVyTibtMgowLCDzF+2hHg=; b=FLuJrybX/oOEv+uxaQuHwSkVeeWpxBOllrkBD2VZlB2lsUXxYn5W6H3z pDdnMXuSLEyIKy5fao/oy9/LlywflYlGkffH2oUwSHNArwGhtiDe0qmJI 0j2tL4Gbf14bKqq; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.68,505,1312182000"; d="scan'208";a="4184725" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 07 Oct 2011 16:10:37 -0700 Received: from DEN-MEXHT-004.corp.ebay.com (10.241.17.60) by DEN-EXMHT-005.corp.ebay.com (10.241.17.171) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 7 Oct 2011 17:10:37 -0600 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-004.corp.ebay.com ([10.241.17.60]) with mapi; Fri, 7 Oct 2011 17:10:37 -0600 From: "Hill, Brad" To: "Murray S. Kucherawy" , ARF mailing list Date: Fri, 7 Oct 2011 17:10:36 -0600 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting feedback Thread-Index: AcyBHDWp6YCfwClIQGePMxELXY1ApACohuCwAGG22SA= Message-ID: <213E0EC97FE58F469BB618245B3118BB55343A5D21@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: wqM1EpZPzKKvMlHQOvvCRw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 23:07:33 -0000 PayPal would plan to implement and would like to see this on Standards Trac= k. "Debugging" is often an edge use case, but it isn't for financial insti= tutions relying on email delivery for required notifications, etc. The abi= lity to debug and receive feedback is almost a precondition of adoption. = Standardization of reporting ensures that that it can be supported in commo= n email products and participation can be extended beyond custom implementa= tions based on private agreements. Brad Hill Senior Member of Technical Staff PayPal bhill@paypal.com=20 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Wednesday, October 05, 2011 9:48 PM > To: ARF mailing list > Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback >=20 > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf > > Of John R Levine > > Sent: Sunday, October 02, 2011 8:59 AM > > To: ARF mailing list > > Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback > > > > I presume the motivation for this is that you have a few people who > > want to use it to debug DKIM failures. That's perfectly reasonable, > > but if people already know each other, they can use private agreements > > with no need to standardize anything. >=20 > That is indeed the prime motivation. It also has helped to have this sor= t of > information around so that future implementations can add similar > debugging features, as this expedites the exchange of exactly the kind of > data that's needed to find problems. >=20 > So you're right that the target population is small, but the need to > interoperate properly in that context out of the starting gate is pretty > valuable. But, admittedly, there's not much harm to getting it wrong, or > indeed not doing it at all. >=20 > > This strikes me as a poor thing to standardize for a variety of > > reasons. One is that the number of people debugging a protocol is less > > by many orders of magnitude than the number who are just using it, and > > to the users, debugging features are just cruft. >=20 > Would it perhaps be better to make it Informational rather than Standards > Track? It's been in use (though with the aforementioned small audience) = for > several years now, so it at least seems useful to write it down. >=20 > > Also, to some extent this is an invitation to mailbomb anyone who uses > > it, >=20 > True, but that could also be argued about email addresses in SOA records, > RFC2142 reporting addresses, etc. I think that ship has sailed. >=20 > -MSK > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From sklist@kitterman.com Fri Oct 7 16:23:33 2011 Return-Path: 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 E760C21F8B83 for ; Fri, 7 Oct 2011 16:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 fGJmhXbn8Ewl for ; Fri, 7 Oct 2011 16:23:33 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 430A821F8B74 for ; Fri, 7 Oct 2011 16:23:33 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 5E86338C12D; Fri, 7 Oct 2011 19:26:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1318030007; bh=+Jf6DFaKDPlsJCJhbC01x/lVDOmZunxk5bPm8iQ7adI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DXJA5dzZIE/wQVEn/+1tEfpXMf001aNI+xI9ttA5RTQtLe2ODTrtwg9Lqa7r2NCmI N0Rw+L02m6QlTZAd+WxSWIFbhSJq7dvb8AvHBaSICeLOZw7lzzcP47IbWdjFlDTicr z72pNBf2BuvIxZx1cbFCxjeDC+TJQ7TjerKt0Hlk= From: Scott Kitterman To: marf@ietf.org Date: Fri, 07 Oct 2011 18:26:41 -0500 Message-ID: <9439558.Mi3WcRdWWW@scott-latitude-e6320> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 23:23:34 -0000 On Friday, October 07, 2011 11:36:24 PM Frank Ellermann wrote: > On 7 October 2011 17:34, Hilda Fontana wrote: > > Thanks Murray and everyone for your input. I shall put a draft > > together with these changes and get it posted as soon as I can. > >=20 > >> Please let me know if I have any of it wrong. > >>=20 > >> New text: =E2=80=9CThis memo registers an extension report type to= ARF > >> for use in reporting messages that fail one or more authentication= > >> checks performed on receipt of a message >=20 > [...] >=20 > Maybe s/suthentication/authorization or authentication/ to address > one concern of Doug Otis. I'd really prefer to stay out of these > terminology nits, but if adding 20 characters helps to get rid of > one recycled vintage 2006 dispute... The header field we are basing this on is called authentication results= . That=20 ship already sailed. Changing it to something else will be more confusing for everyone !Doug= . -1 Scott K From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Fri Oct 7 16:54:12 2011 Return-Path: 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 8690F21F8C12 for ; Fri, 7 Oct 2011 16:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 b8B06w0hqUfh for ; Fri, 7 Oct 2011 16:54:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3BBC21F8B35 for ; Fri, 7 Oct 2011 16:54:11 -0700 (PDT) Received: by wyg24 with SMTP id 24so1483465wyg.31 for ; Fri, 07 Oct 2011 16:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JA9fPr3YYPDDWlmJt5KqEIvrKM/2dD+vC8CwaeytxO0=; b=x3aeh9cejlgvUIueEWS9xZxQmKTZfB5vqi1IJPbqz1L6g/BAv9FMZbrht9u3Oztkkc IThUp/2wwRKnrpR5R2NDboeQ1/1gGu6w6Z8FxVwEAbMu1PeANBG2/0w8oF6HpQhY2iaA Dbj4TvNtHbzMjaiciCryxoj7+w0wiTzUbM7Q8= Received: by 10.216.135.34 with SMTP id t34mr109662wei.62.1318031846104; Fri, 07 Oct 2011 16:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Fri, 7 Oct 2011 16:56:46 -0700 (PDT) In-Reply-To: <9439558.Mi3WcRdWWW@scott-latitude-e6320> References: <9439558.Mi3WcRdWWW@scott-latitude-e6320> From: Frank Ellermann Date: Sat, 8 Oct 2011 01:56:46 +0200 Message-ID: To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 23:54:12 -0000 On 8 October 2011 01:26, Scott Kitterman wrote: > The header field we are basing this on is called authentication > results. =A0That ship already sailed. > Changing it to something else will be more confusing for everyone > !Doug. > -1 ACK. Besides RFC 4408 always uses the "correct term" for everyone including Doug. His broken record^W^Wsuggestion to change "policy" into "script" can be evaluated for 4008bis. -Frank From msk@cloudmark.com Fri Oct 7 20:19:44 2011 Return-Path: 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 CDD8821F8B2B for ; Fri, 7 Oct 2011 20:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=-0.344, 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 BE4Ke+-NbpK5 for ; Fri, 7 Oct 2011 20:19:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9919421F8669 for ; Fri, 7 Oct 2011 20:19:41 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 7 Oct 2011 20:22:50 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 7 Oct 2011 20:22:49 -0700 Thread-Topic: [marf] Suggested changes to draft-ietf-marf-authfailure-report Thread-Index: AcyFSJr5IuRI9K+eSnKH2wZx/cRTzgAIOUVQ Message-ID: References: <9439558.Mi3WcRdWWW@scott-latitude-e6320> In-Reply-To: <9439558.Mi3WcRdWWW@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 03:19:45 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYXJmLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptYXJmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTY290dCBLaXR0 ZXJtYW4NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDA3LCAyMDExIDQ6MjcgUE0NCj4gVG86IG1h cmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYXJmXSBTdWdnZXN0ZWQgY2hhbmdlcyB0byBk cmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0DQo+IA0KPiBUaGUgaGVhZGVyIGZpZWxk IHdlIGFyZSBiYXNpbmcgdGhpcyBvbiBpcyBjYWxsZWQgYXV0aGVudGljYXRpb24NCj4gcmVzdWx0 cy4gIFRoYXQgc2hpcCBhbHJlYWR5IHNhaWxlZC4NCg0KSSBhZ3JlZS4NCg== From vesely@tana.it Sat Oct 8 03:46:52 2011 Return-Path: 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 DAECD21F8A69 for ; Sat, 8 Oct 2011 03:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=0.087, 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 0kwx1oX6bbBY for ; Sat, 8 Oct 2011 03:46:52 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0693721F85AE for ; Sat, 8 Oct 2011 03:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318071005; bh=VuVzfx3xHoEtF6VTpirJnbskB91zmmu5N8zU6j2UYWQ=; l=1094; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Sg8edn3wYRTP1ULR4De8XnSsUymWaay5yz+c4kquWThvu3KeN4aV3yPjojFA7aWMq 77bHb6m+fvtX5nyC1VP0rZX+E03ls/93QnZlSWnzsHh9CFscKPx1Cl5pUa0jjyDYK5 fN2q+PZg2+PNY5lrpid5WwoumX3h17PWukFGNa+s= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 08 Oct 2011 12:50:05 +0200 id 00000000005DC039.000000004E902ADD.000053C9 Message-ID: <4E902ADE.2010502@tana.it> Date: Sat, 08 Oct 2011 12:50:06 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111001154456.09b03df0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 10:46:53 -0000 On 06/Oct/11 03:37, Frank Ellermann wrote: > The concept of a FAIL report confuses me, because it's at odds with > the SPF FAIL semantics. As you said this would anyway only affect > receivers accepting FAIL. There seems to be a semantic crossover here. On the one hand, some operators understand SPF as a means to ensure proper deliverability of any bounce that might occur, avoiding backscatter. On the other hand, ARF can be understood as an extension of DSN designed to overcome its restrictions, both target address and content. If an MTA rejects a message because of SPF FAIL, this may result in a bounce issued by the relay. OTOH, the same MTA may notice that domain owners are providing a fixed bounce address for SPF FAIL, and thus may safely issue the bounce itself. That is to say, we may alter the semantics of FAIL so as to allow both choices on equal standing. For example, some domain owners might be interested in tracking abuse of their domain name for forensic purposes, which may result in a stronger anti-spam effect than just avoiding the delivery. From vesely@tana.it Sat Oct 8 03:50:24 2011 Return-Path: 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 1FF3C21F8ABC for ; Sat, 8 Oct 2011 03:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.033 X-Spam-Level: X-Spam-Status: No, score=-4.033 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 DtUsUQTfeWsR for ; Sat, 8 Oct 2011 03:50:22 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C33F021F8AB0 for ; Sat, 8 Oct 2011 03:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318071216; bh=GK7X5naF6qP/wus33nqWfTAdMGDDluv6jGUiKZAJB34=; l=899; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BFfasgKpm8huJHr8YOAsMYaOCFB8aDyDgnGEde0GRHPngQXujW4R+f74QyXi+mdVG Qaeod0FdJrb7NEibmwmPdFV89FiKv/OP7Bb/cqR8nZt2dH2emy5cKGKBhNR4hdgiTU +Dy2oMOSWZVKJ2WPaplTvDnLbabmNYhMkzYQRJgw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 08 Oct 2011 12:53:36 +0200 id 00000000005DC039.000000004E902BB0.0000641F Message-ID: <4E902BB0.5010002@tana.it> Date: Sat, 08 Oct 2011 12:53:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <213E0EC97FE58F469BB618245B3118BB55343A5D21@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <213E0EC97FE58F469BB618245B3118BB55343A5D21@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 10:50:24 -0000 On 08/Oct/11 01:10, Hill, Brad wrote: > PayPal would plan to implement and would like to see this on > Standards Track. Thanks for this declaration of intent. > "Debugging" is often an edge use case, but it isn't for financial > institutions relying on email delivery for required notifications, > etc. The ability to debug and receive feedback is almost a > precondition of adoption. Yes, if we mean not only debugging of code, but also of configurations. In addition, monitoring how users comply with policies is quite a different case than debugging. For example, a domain may monitor what its users post to mailing lists like this[*]. Do we address all cases in the same way? [*] if the following triggers an ARF: Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass header.i=@ietf.org; dkim-adsp=fail header.from=bhill@paypal-inc.com From internet-drafts@ietf.org Sat Oct 8 23:43:10 2011 Return-Path: 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 27E3321F8C43; Sat, 8 Oct 2011 23:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.764 X-Spam-Level: X-Spam-Status: No, score=-101.764 tagged_above=-999 required=5 tests=[AWL=0.836, 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 dCwrguB+M7EF; Sat, 8 Oct 2011 23:43:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78A321F8B89; Sat, 8 Oct 2011 23:43:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111009064309.9490.13212.idtracker@ietfa.amsl.com> Date: Sat, 08 Oct 2011 23:43:09 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 06:43:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-03.txt Pages : 20 Date : 2011-10-08 This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-03.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-03.txt From msk@cloudmark.com Mon Oct 10 10:45:44 2011 Return-Path: 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 A007221F8669 for ; Mon, 10 Oct 2011 10:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 vKIH92mD2tTn for ; Mon, 10 Oct 2011 10:45:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 00E5521F8591 for ; Mon, 10 Oct 2011 10:45:43 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 10 Oct 2011 10:45:38 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 10 Oct 2011 10:45:37 -0700 Thread-Topic: New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyGlZ3HoHfBSpRdTuWpDbAziBepcgA3NQPA Message-ID: References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> In-Reply-To: <20111009064309.9490.90309.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:45:44 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogU2F0dXJk YXksIE9jdG9iZXIgMDgsIDIwMTEgMTE6NDMgUE0NCj4gVG86IG1hcmYtY2hhaXJzQHRvb2xzLmll dGYub3JnOyBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0QHRvb2xzLmlldGYub3Jn OyBwcmVzbmlja0BxdWFsY29tbS5jb20NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIC0gZHJhZnQtaWV0Zi1tYXJmLWF1dGhmYWlsdXJlLXJlcG9ydC0wMy50eHQNCj4gDQo+IE5l dyB2ZXJzaW9uICgtMDMpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgZHJhZnQtaWV0Zi1tYXJmLWF1 dGhmYWlsdXJlLXJlcG9ydC0wMy50eHQuDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtbWFyZi1hdXRoZmFpbHVyZS1yZXBvcnQtMDMudHh0DQo+IA0KPiBE aWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0LTAzDQoNCjxwYXJ0aWNp cGFudD4NCkdvaW5nIG92ZXIgdGhlIGRpZmYsIEkgc3BvdCB0aGUgZm9sbG93aW5nOg0KDQoxLiBJ bnRyb2R1Y3Rpb246DQoNCglzL3VzZSBleHRlbmQvZXh0ZW5kLw0KDQoJcy9mYWlsIHRvIGF1dGhl bnRpY2F0ZS9mYWlsIGV2YWx1YXRpb24vDQoNCjMuMS4gTmV3IEFSRiBGZWVkYmFjayBUeXBlDQoN CglzL29uY2UgaWYgaXQvb25jZSBpZiBpdCBpcy8gKG9yIGp1c3QgIm9uY2UgaWYiKQ0KDQoJcy8z LjIuMSBpcyBPUFRJT05BTCwgTVVTVCBOT1QvMy4yLjEuICBJdCBpcyBPUFRJT05BTCwgYnV0IE1V U1QgTk9ULw0KDQozLjIuMy4gT3B0aW9uYWwgRm9yIERLSU0gUmVwb3J0cw0KDQoJTW92ZSB0aGUg ZGVzY3JpcHRpdmUgcGFyYWdyYXBoIHRvIHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24gcmF0aGVyIHRo YW4gdGhlIGJlZ2lubmluZy4NCg0KQi4xLiBFeGFtcGxlIFVzZSBvZiBBUkYgRXh0ZW5zaW9uIEhl YWRlcnMNCg0KCVdoYXQgd2FzIHRoZSByZWFzb24gZm9yIHJlcGxhY2luZyB0aGUgZXhhbXBsZSB0 aGF0IHdhcyB0aGVyZT8NCg0KCURlbGl2ZXJlZC1UbyBpc24ndCBhIGtub3duIGhlYWRlciBmaWVs ZCBhbmQgc2hvdWxkIGJlIGRlbGV0ZWQuDQoNCglUaGUgUmVjZWl2ZWQtU1BGIGxpbmUgaXNuJ3Qg cHJvcGVybHkgd3JhcHBlZC4gIEFsc28gc2luY2UgU1BGIGlzIHBsYW5uaW5nIHRvIHN3aXRjaCB0 bw0KCUF1dGhlbnRpY2F0aW9uLVJlc3VsdHMsIGl0IHNob3VsZCBwb3NzaWJseSBiZSByZW1vdmVk IGFzIGl0J3MgcmVkdW5kYW50IHRvIHRoZSBsaW5lDQoJYmVsb3cgaXQgYW55d2F5Lg0KDQoJQ2hh bmdlIGFsbCB0aGUgZXhhbXBsZSBkb21haW4gbmFtZXMgdG8gZW5kIGluICJleGFtcGxlIiwgb3Ig YmUgc3BlY2lmaWNhbGx5ICJleGFtcGxlLmNvbSIsDQoJImV4YW1wbGUubmV0Iiwgb3IgImV4YW1w bGUub3JnIi4NCg0KCVRoZSBleGFtcGxlIGlzIG1pc3NpbmcgYSBNSU1FLVZlcnNpb24gaGVhZGVy IGZpZWxkLg0KDQoJSW4gdGhlIGZpcnN0IE1JTUUgcGFydCwgIihHTVQpIiBzaG91bGQgcHJvYmFi bHkgYmUgcHJlY2VkZWQgYnkgYSBzcGFjZS4NCg0KCUknbSBub3Qgc3VyZSB3aGF0ICJDb250ZW50 LURpc3Bvc2l0aW9uOiBpbmxpbmUiIG1lYW5zIGZvciB0aGUgcGFydHMgb2YgYW4gQVJGIG1lc3Nh Z2UuDQo8L3BhcnRpY2lwYW50Pg0KDQpFdmVyeW9uZSBlbHNlIHRoYXQgd2VpZ2hlZCBpbiwgcGxl YXNlIHJldmlldyB0aGUgbmV3IHZlcnNpb24gYW5kIGNvbW1lbnQuDQoNCi1NU0sNCg0KCQ0K From msk@cloudmark.com Mon Oct 10 10:46:59 2011 Return-Path: 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 82C5B21F8C20 for ; Mon, 10 Oct 2011 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 D1r3DXV0du-e for ; Mon, 10 Oct 2011 10:46:59 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3874421F8C11 for ; Mon, 10 Oct 2011 10:46:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 10 Oct 2011 10:46:58 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 10 Oct 2011 10:46:58 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyGlZ3HoHfBSpRdTuWpDbAziBepcgA3NQPAAACGymA= Message-ID: References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> In-Reply-To: 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:46:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Monday, October 10, 2011 10:46 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Change all the example domain names to end in "example", or be specifica= lly "example.com", > "example.net", or "example.org". See RFC2606 for further details. -MSK From vesely@tana.it Mon Oct 10 14:12:05 2011 Return-Path: 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 8690C21F8BE8 for ; Mon, 10 Oct 2011 14:12:05 -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 T55DM424sOGV for ; Mon, 10 Oct 2011 14:12:04 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A558221F8BDE for ; Mon, 10 Oct 2011 14:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318281123; bh=CnJFHJR5ZQB+DLDWUBKZ3a6+L9njpy/IwpIyfrKxRnU=; l=931; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YoAgfAQxN6IDlpCeCHR+0tBmyP0nBLLxPV2gyEqAbXY5Wxg/vQRJix+9pOhXirj+h cp54zzbSKI5Q6/cvADV5if5l5epewkGCZXx52d2vCOkj4QoSRrgZeNAic8vjaewDYI 4MqZp7on+rRoqIirXPTSOG9e2W3FbNqRFp4rKWtY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 10 Oct 2011 23:12:03 +0200 id 00000000005DC03F.000000004E935FA3.00002320 Message-ID: <4E935FA2.5000606@tana.it> Date: Mon, 10 Oct 2011 23:12:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:12:05 -0000 On 10/Oct/11 19:45, Murray S. Kucherawy wrote: > B.1. Example Use of ARF Extension Headers > > What was the reason for replacing the example that was there? IMHO, the example in -03 is better than the previous one. It would be useful to see also examples with DNS records. > The Received-SPF line isn't properly wrapped. Also since SPF is planning to switch to > Authentication-Results, it should possibly be removed as it's redundant to the line > below it anyway. The Authentication-Results is also badly wrapped. > Everyone else that weighed in, please review the new version and comment. The Auth-Failure field is missing from feedback-report. Authentication-Results is also missing from feedback-record, which might be alright since it is already in rfc822-headers. The spec in section 3.1 does not agree with this reasoning, though. (And the User-Agent's /version looks different than Version:) From msk@cloudmark.com Mon Oct 10 14:20:50 2011 Return-Path: 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 1E9A221F8C8E for ; Mon, 10 Oct 2011 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 R200pHRIfgZD for ; Mon, 10 Oct 2011 14:20:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B72C321F8C88 for ; Mon, 10 Oct 2011 14:20:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 10 Oct 2011 14:20:45 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 10 Oct 2011 14:20:43 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyHkUVtndGL6qjfTv+5SpyqSLW2VAAAQQWQ Message-ID: References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> <4E935FA2.5000606@tana.it> In-Reply-To: <4E935FA2.5000606@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 21:20:50 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, October 10, 2011 2:12 PM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Authentication-Results is also missing from feedback-record, which > might be alright since it is already in rfc822-headers. The spec in > section 3.1 does not agree with this reasoning, though. What's important here (to my mind) is that A-R has to be present in the rep= ort not just in the included message/header, because there might be more th= an one in the latter. The one(s) generated by the reporting host are the = ones that need to be in the second MIME part of the report. From vesely@tana.it Tue Oct 11 00:20:38 2011 Return-Path: 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 EE03D21F8A96 for ; Tue, 11 Oct 2011 00:20:37 -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 nAALvIz2YkOQ for ; Tue, 11 Oct 2011 00:20:37 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EC3C221F8A7D for ; Tue, 11 Oct 2011 00:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318317633; bh=6/VZoUEVnAJ1D8VJnaEU3H5ByEfjmWqHLBcmy1ZLdBU=; l=1249; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kdBf6FiRVx2cFORHViiqKH512Hgs2B75I+sWclEwFu+rc3TLHpgUlD0JF8/YFZGXB znFgoNyjl9LshHzjpuhOzv3P2CqBpSHk5Kz2ahDoI/j9cFSI2ax87A9sxTjmUKA3Fg 8J8fffLBJS+HE1MrWqdxRP+cVXA5ZwJKW5ZP4n60= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 11 Oct 2011 09:20:33 +0200 id 00000000005DC039.000000004E93EE41.000027F1 Message-ID: <4E93EE41.601@tana.it> Date: Tue, 11 Oct 2011 09:20:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> <4E935FA2.5000606@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:20:38 -0000 On 10/Oct/11 23:20, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf.org On Behalf Of Alessandro Vesely >> >> Authentication-Results is also missing from feedback-record, which >> might be alright since it is already in rfc822-headers. The spec in >> section 3.1 does not agree with this reasoning, though. > > What's important here (to my mind) is that A-R has to be present in > the report not just in the included message/header, because there > might be more than one in the latter. The one(s) generated by the > reporting host are the ones that need to be in the second MIME part > of the report. Good point. As an alternative, we could identify the report-triggering results by reference, letting generators declare their authserv-id. For example, adding the following line in the second part of the current example: Authentication-Server-Id: mta1011.mail.tp2.someisp.com This alternative may allow a generator to piecewise write the A-R fields directly to the relevant stream, rather than building them in memory. At the recipient's, this alternative just prevents the embarrassment of choice; e.g., what if the second part's A-R fields seem to differ from their third part's correlatives? From shmuel+gen@patriot.net Tue Oct 11 07:44:16 2011 Return-Path: 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 D458821F8DCB for ; Tue, 11 Oct 2011 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 9ze0EALu8RpS for ; Tue, 11 Oct 2011 07:44:16 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1226121F8DD0 for ; Tue, 11 Oct 2011 07:44:15 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.152]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id E645EF5809A for ; Tue, 11 Oct 2011 10:32:57 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Tue, 11 Oct 2011 08:18:49 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111011143258.E645EF5809A@smtp.patriot.net> Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:44:16 -0000 In , on 10/10/2011 at 10:46 AM, "Murray S. Kucherawy" said: >> Change all the example domain names to end in "example", or be specifically "example.com", >> "example.net", or "example.org". AFAIK, "example" is defined only as a SLD, so the example domain names should end in "example.*" or "invalid". >>or be specifically "example.com", "example.net", or >>"example.org". But *not* "example". -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From johnl@iecc.com Tue Oct 11 08:28:24 2011 Return-Path: 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 D152721F8BB1 for ; Tue, 11 Oct 2011 08:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 pruQI7K5oRyJ for ; Tue, 11 Oct 2011 08:28:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01B21F8E52 for ; Tue, 11 Oct 2011 08:28:24 -0700 (PDT) Received: (qmail 93613 invoked from network); 11 Oct 2011 15:28:22 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 11 Oct 2011 15:28:22 -0000 Received: (qmail 58781 invoked from network); 11 Oct 2011 15:28:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Oct 2011 15:28:22 -0000 Date: 11 Oct 2011 15:28:00 -0000 Message-ID: <20111011152800.5920.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20111011143258.E645EF5809A@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:28:24 -0000 >But *not* "example". Sigh. Please read RFC 2606. R's, John From msk@cloudmark.com Tue Oct 11 10:39:44 2011 Return-Path: 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 6F2CD21F8F02 for ; Tue, 11 Oct 2011 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 ZiIbIacJ83b5 for ; Tue, 11 Oct 2011 10:39:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id F41AF21F8EFE for ; Tue, 11 Oct 2011 10:39:43 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 11 Oct 2011 10:39:43 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 11 Oct 2011 10:39:42 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyH5k5/Bf13KxXmQ5WJCsCWOjWh2QAVjATA Message-ID: References: <20111009064309.9490.90309.idtracker@ietfa.amsl.com> <4E935FA2.5000606@tana.it> <4E93EE41.601@tana.it> In-Reply-To: <4E93EE41.601@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:39:44 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, October 11, 2011 12:21 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Good point. As an alternative, we could identify the > report-triggering results by reference, letting generators declare > their authserv-id. For example, adding the following line in the > second part of the current example: >=20 > Authentication-Server-Id: mta1011.mail.tp2.someisp.com >=20 > This alternative may allow a generator to piecewise write the A-R > fields directly to the relevant stream, rather than building them in > memory. At the recipient's, this alternative just prevents the > embarrassment of choice; e.g., what if the second part's A-R fields > seem to differ from their third part's correlatives? There's nothing requiring a verifier to affix an A-R field in the first pla= ce, nor is there any guarantee that the verifier has properly stripped forg= eries. Thus, what's in the second part is exactly what you're suggesting, = and is possibly more reliable than what's in the third part. Moreover, the= copy that's in the third part might be extracted before the local one is e= ven added. It's right where it is, and doesn't need modification. From johnl@iecc.com Tue Oct 11 21:11:38 2011 Return-Path: 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 72D9921F8C9C for ; Tue, 11 Oct 2011 21:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.899 X-Spam-Level: X-Spam-Status: No, score=-109.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 Dw4oTaO6z6RV for ; Tue, 11 Oct 2011 21:11:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C328521F8C34 for ; Tue, 11 Oct 2011 21:11:37 -0700 (PDT) Received: (qmail 52093 invoked from network); 12 Oct 2011 04:11:34 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 12 Oct 2011 04:11:34 -0000 Received: (qmail 62190 invoked from network); 12 Oct 2011 04:11:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Oct 2011 04:11:34 -0000 Date: 12 Oct 2011 04:11:12 -0000 Message-ID: <20111012041112.66464.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 04:11:38 -0000 This draft is a great improvement. I would strongly suggest changing the text to say there must be exactly one authentication-results header in the report. If there's more than one, particularly if there are multiple DKIM failures, there's no way to tell which other parts of the report go with which a-r header. Note that multiple DKIM failures could easily have multiple reported domains, multiple auth-failure, dkim-domain, dkim-identity, dkim-selector, dkim-canonicalized-header, and dkim-canonicalized body. (Remember that there are two different ways to canonicalize each.) Rather than inventing complex rules about which item goes with which report, if you have three failures, send three reports. R's, John From dotis@mail-abuse.org Wed Oct 12 00:51:02 2011 Return-Path: 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 0DD2D21F8B4C for ; Wed, 12 Oct 2011 00:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 SqyMKxeaAzVJ for ; Wed, 12 Oct 2011 00:51:01 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5921F8B46 for ; Wed, 12 Oct 2011 00:51:01 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 990CF308101 for ; Wed, 12 Oct 2011 07:50:59 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 6FA7FA9443C for ; Wed, 12 Oct 2011 07:50:59 +0000 (UTC) Message-ID: <4E9546E0.7010409@mail-abuse.org> Date: Wed, 12 Oct 2011 00:50:56 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <9439558.Mi3WcRdWWW@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:51:03 -0000 On 10/7/11 4:56 PM, Frank Ellermann wrote: > On 8 October 2011 01:26, Scott Kitterman wrote: >> The header field we are basing this on is called authentication >> results. That ship already sailed. >> Changing it to something else will be more confusing for everyone >> !Doug. >> -1 > ACK. Besides RFC 4408 always uses the "correct term" for everyone > including Doug. His broken record^W^Wsuggestion to change "policy" > into "script" can be evaluated for 4008bis. Nothing has changed. Bulk senders don't care about risks, just turning a profit. But... 10 macro mechanisms x 10 resolutions per connection represents a hazard, especially when confronting IPv4 in a growing IPv6 world. How can defensive strategies deal with shared translation mechanisms without causing significant disruption? Distributing the potential of SPF derived transactions emitted by libraries applying script-like macro expansions represent a real risk of enabling distributed denial of services. The underlying mechanism of such attacks will be difficult to identify and impossible to defend against, that can target any domain not even present within the message. Also too many forget SPF is _not_ an Authentication mechanism. SPF can offer pass results unrelated to the source IP address also not captured in Authentication-Results headers. Those making use of SPF need to be repeatedly reminded of SPF limitations and risks. For example, SPF selected by Mail From or PRA can not be used to validate receivers of feedback. Requiring DKIM headers not be redacted also provides spammers a sure place to encode spamtrap locations. Another don't care for bulk senders. Lack of SPF authentication and lack of sender/recipient information applied against DKIM signatures means a system based on these two protocols will make it impossible for smaller domains to receive equitable treatment. Equitable treatment demands _all_ accountable sources be authenticated as having sourced the message directed to a recipient that considered it to be unsolicited and undesired. Larger domains are naturally protected by complaints making them "too big to block" and immune against reputation attacks. -Doug From msk@cloudmark.com Wed Oct 12 10:43:17 2011 Return-Path: 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 74F7021F8C98 for ; Wed, 12 Oct 2011 10:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 AKskm9nvbmE4 for ; Wed, 12 Oct 2011 10:43:17 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 120E921F8C82 for ; Wed, 12 Oct 2011 10:43:17 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 12 Oct 2011 10:43:16 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 12 Oct 2011 10:43:15 -0700 Thread-Topic: [marf] Suggested changes to draft-ietf-marf-authfailure-report Thread-Index: AcyIs7rc+hZwQo1BTsyZK2n+qOLjRgAUdKpA Message-ID: References: <9439558.Mi3WcRdWWW@scott-latitude-e6320> <4E9546E0.7010409@mail-abuse.org> In-Reply-To: <4E9546E0.7010409@mail-abuse.org> 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] Suggested changes to draft-ietf-marf-authfailure-report X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:43:17 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of D= ouglas Otis > Sent: Wednesday, October 12, 2011 12:51 AM > To: marf@ietf.org > Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-repo= rt >=20 > 10 macro mechanisms x 10 resolutions per connection represents a hazard, > especially when confronting IPv4 in a growing IPv6 world. How can > defensive strategies deal with shared translation mechanisms without > causing significant disruption? Distributing the potential of SPF > derived transactions emitted by libraries applying script-like macro > expansions represent a real risk of enabling distributed denial of > services. The underlying mechanism of such attacks will be difficult to > identify and impossible to defend against, that can target any domain > not even present within the message. > [...] Concerns about SPF aren't appropriate fodder for discussion of this draft. = Both this draft and RFC5451 make it clear that those issues belong to thos= e protocols, and don't need to be re-hashed yet again in this forum. They = are off-topic. > Also too many forget SPF is _not_ an Authentication mechanism. SPF can > offer pass results unrelated to the source IP address also not captured > in Authentication-Results headers. Those making use of SPF need to be > repeatedly reminded of SPF limitations and risks. For example, SPF > selected by Mail From or PRA can not be used to validate receivers of > feedback. This is covered in RFC5451, to which this draft already refers. > Requiring DKIM headers not be redacted also provides spammers a sure > place to encode spamtrap locations. Another don't care for bulk > senders. This, however, is something this group should consider and comment on. Please stick to reviewing the specific content of this draft. Concerns you= have with SPF or DKIM should be addressed elsewhere. -MSK, as co-chair From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 12 11:51:50 2011 Return-Path: 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 B79C521F8AB0 for ; Wed, 12 Oct 2011 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 a-l+vMumBdel for ; Wed, 12 Oct 2011 11:51:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10B2B21F84DC for ; Wed, 12 Oct 2011 11:51:49 -0700 (PDT) Received: by wwf22 with SMTP id 22so362886wwf.13 for ; Wed, 12 Oct 2011 11:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=BEdTjpUcT+Pv86rPNG33fXNM/Sackj7jNZ681M55Ggc=; b=hVbXnoSC2fqWpBjKu8zlAXodcJCW2RyozNkkpwPqVmVHAcJqgJn0a8/Sr02qBv7yFN XCRt74qAoVNB4w7eFi0QQ1nezj2KAOp1KbOhOgaJHe1KOXmbiWNQK/S59bsJZ9Hy9ZqO xwYJvjaOByRo2K8yx/zak6rSt4guOC0XwiLHw= Received: by 10.227.11.75 with SMTP id s11mr96904wbs.62.1318445509184; Wed, 12 Oct 2011 11:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 12 Oct 2011 11:51:09 -0700 (PDT) In-Reply-To: References: <4E622001.8010904@tana.it> From: Frank Ellermann Date: Wed, 12 Oct 2011 20:51:09 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:51:50 -0000 On 9 September 2011, Murray S. Kucherawy wrote: >=A0So instead of Alessandro going ahead with his document (and it > would be weird for this group to produce two BCPs on the same > topic), we should review what he says and then propose text > that JD should add to the AS and then see if any of it gets > consensus. > Sound good? Dunno. If I understand Alessandro's I-D correctly it is about something that could be implemented in say ThunderBird. Is that okay for a "BCP" and/or "AS"? -Frank From msk@cloudmark.com Wed Oct 12 12:05:31 2011 Return-Path: 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 681D721F84A5 for ; Wed, 12 Oct 2011 12:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 vu9EkHPcoJHC for ; Wed, 12 Oct 2011 12:05:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 072CF21F84A4 for ; Wed, 12 Oct 2011 12:05:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 12 Oct 2011 12:05:30 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 12 Oct 2011 12:05:29 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyIlQwT/r10rkXSRFu8FciIN3aTVQAfIuFQ Message-ID: References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: <20111012041112.66464.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:05:31 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAxMSwgMjAxMSA5OjEx IFBNDQo+IFRvOiBtYXJmQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IFN1 YmplY3Q6IFJlOiBbbWFyZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1t YXJmLWF1dGhmYWlsdXJlLXJlcG9ydC0wMy50eHQNCj4gDQo+IFRoaXMgZHJhZnQgaXMgYSBncmVh dCBpbXByb3ZlbWVudC4NCj4gDQo+IEkgd291bGQgc3Ryb25nbHkgc3VnZ2VzdCBjaGFuZ2luZyB0 aGUgdGV4dCB0byBzYXkgdGhlcmUgbXVzdCBiZSBleGFjdGx5DQo+IG9uZSBhdXRoZW50aWNhdGlv bi1yZXN1bHRzIGhlYWRlciBpbiB0aGUgcmVwb3J0LiAgSWYgdGhlcmUncyBtb3JlIHRoYW4NCj4g b25lLCBwYXJ0aWN1bGFybHkgaWYgdGhlcmUgYXJlIG11bHRpcGxlIERLSU0gZmFpbHVyZXMsIHRo ZXJlJ3Mgbm8gd2F5DQo+IHRvIHRlbGwgd2hpY2ggb3RoZXIgcGFydHMgb2YgdGhlIHJlcG9ydCBn byB3aXRoIHdoaWNoIGEtciBoZWFkZXIuDQo+IA0KPiBOb3RlIHRoYXQgbXVsdGlwbGUgREtJTSBm YWlsdXJlcyBjb3VsZCBlYXNpbHkgaGF2ZSBtdWx0aXBsZSByZXBvcnRlZCBkb21haW5zLA0KPiBt dWx0aXBsZSBhdXRoLWZhaWx1cmUsIGRraW0tZG9tYWluLCBka2ltLWlkZW50aXR5LCBka2ltLXNl bGVjdG9yLA0KPiBka2ltLWNhbm9uaWNhbGl6ZWQtaGVhZGVyLCBhbmQgZGtpbS1jYW5vbmljYWxp emVkIGJvZHkuICAoUmVtZW1iZXIgdGhhdA0KPiB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCB3YXlz IHRvIGNhbm9uaWNhbGl6ZSBlYWNoLikNCj4gDQo+IFJhdGhlciB0aGFuIGludmVudGluZyBjb21w bGV4IHJ1bGVzIGFib3V0IHdoaWNoIGl0ZW0gZ29lcyB3aXRoIHdoaWNoDQo+IHJlcG9ydCwgaWYg eW91IGhhdmUgdGhyZWUgZmFpbHVyZXMsIHNlbmQgdGhyZWUgcmVwb3J0cy4NCg0KQW4gQXV0aGVu dGljYXRpb24tUmVzdWx0cyBmaWVsZCBjYW4gbGlzdCBzZXZlcmFsIGRpZmZlcmVudCBES0lNIGZh aWx1cmVzIGlmIHRoZSBtZXNzYWdlIHdhcyBtdWx0aXBseSBkZWZpbmVkLiAgVGhhdCBtYWtlcyB0 aGUgb3RoZXIgREtJTS0qIGZpZWxkcyBpbXBvcnRhbnQsIGFzIHRoZXkgbWFrZSBpdCBjbGVhciB3 aGljaCBvbmUgdGhlIHJlcG9ydCBpcyBjb3ZlcmluZy4NCg0KSXQgd291bGQgYmUgZWFzeSB0byBn cm91cCByZXBlYXRlZCBES0lNLSogZmllbGRzIHRvZ2V0aGVyLCBzZXBhcmF0ZWQgYnkgYmxhbmsg bGluZXMsIHRvIGFsbG93IHJlbGF5aW5nIERLSU0gZm9yZW5zaWNzIGFib3V0IGVhY2gsIGJ1dCBz ZXBhcmF0ZWx5LiAgSXMgdGhhdCB0b28gY29tcGxleD8NCg== From johnl@iecc.com Wed Oct 12 23:15:19 2011 Return-Path: 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 CC34521F8AFF for ; Wed, 12 Oct 2011 23:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 vPdlXuvMCzM2 for ; Wed, 12 Oct 2011 23:15:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BB79B21F877F for ; Wed, 12 Oct 2011 23:15:18 -0700 (PDT) Received: (qmail 95590 invoked from network); 13 Oct 2011 06:15:17 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 13 Oct 2011 06:15:17 -0000 Received: (qmail 24325 invoked from network); 13 Oct 2011 06:15:17 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Oct 2011 06:15:17 -0000 Date: 13 Oct 2011 06:14:55 -0000 Message-ID: <20111013061455.73257.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 06:15:19 -0000 >An Authentication-Results field can list several different DKIM >failures if the message was multiply defined. That makes the other >DKIM-* fields important, as they make it clear which one the report >is covering. >It would be easy to group repeated DKIM-* fields together, separated >by blank lines, to allow relaying DKIM forensics about each, but >separately. Is that too complex? Hmmn. We already allow multiple groups each consisting of an auth-res header each followed by some other stuff. I suppose we could define subgroups consisting of auth-failure, then dkim-domain, then other stuff. But I worry that people will get it wrong. Presumably an a-r could report multiple failures but you only send a report for the one that is likely to be of interest to the report target, so we need to be sure that the target can tell which failure all the subgroup stuff refers to. I see that the ABNF in section 4 of the draft doesn't update the feedback-report ABNF in section 3.5 of RFC 5965. It better do that or there's no place in an ARF report where the new lines can occur. R's, John From msk@cloudmark.com Wed Oct 12 23:24:43 2011 Return-Path: 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 8500F21F8AF3 for ; Wed, 12 Oct 2011 23:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 N9F-gIxtLlX1 for ; Wed, 12 Oct 2011 23:24:40 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECED21F8AF2 for ; Wed, 12 Oct 2011 23:24:40 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 12 Oct 2011 23:24:39 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 12 Oct 2011 23:24:38 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyJb356c7X7u7QjSWevz3CEkhrJBgAAJhQQ Message-ID: References: <20111013061455.73257.qmail@joyce.lan> In-Reply-To: <20111013061455.73257.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 06:24:43 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDExIDEx OjE1IFBNDQo+IFRvOiBtYXJmQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+ IFN1YmplY3Q6IFJlOiBbbWFyZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0 Zi1tYXJmLWF1dGhmYWlsdXJlLXJlcG9ydC0wMy50eHQNCj4gDQo+IEhtbW4uICBXZSBhbHJlYWR5 IGFsbG93IG11bHRpcGxlIGdyb3VwcyBlYWNoIGNvbnNpc3Rpbmcgb2YgYW4gYXV0aC1yZXMNCj4g aGVhZGVyIGVhY2ggZm9sbG93ZWQgYnkgc29tZSBvdGhlciBzdHVmZi4gIEkgc3VwcG9zZSB3ZSBj b3VsZCBkZWZpbmUNCj4gc3ViZ3JvdXBzIGNvbnNpc3Rpbmcgb2YgYXV0aC1mYWlsdXJlLCB0aGVu IGRraW0tZG9tYWluLCB0aGVuIG90aGVyDQo+IHN0dWZmLiAgQnV0IEkgd29ycnkgdGhhdCBwZW9w bGUgd2lsbCBnZXQgaXQgd3JvbmcuICBQcmVzdW1hYmx5IGFuIGEtcg0KPiBjb3VsZCByZXBvcnQg bXVsdGlwbGUgZmFpbHVyZXMgYnV0IHlvdSBvbmx5IHNlbmQgYSByZXBvcnQgZm9yDQo+IHRoZSBv bmUgdGhhdCBpcyBsaWtlbHkgdG8gYmUgb2YgaW50ZXJlc3QgdG8gdGhlIHJlcG9ydCB0YXJnZXQs IHNvDQo+IHdlIG5lZWQgdG8gYmUgc3VyZSB0aGF0IHRoZSB0YXJnZXQgY2FuIHRlbGwgd2hpY2gg ZmFpbHVyZSBhbGwgdGhlDQo+IHN1Ymdyb3VwIHN0dWZmIHJlZmVycyB0by4NCg0KVGhlIG90aGVy IGlkZWEgSSBoYWQgYm9ycm93cyBmcm9tIGEgTUlNRSBleHRlbnNpb246DQoNCkF1dGhlbnRpY2F0 aW9uLVJlc3VsdHMqMDogLi4uDQpES0lNLURvbWFpbiowOiAuLi4NCkRLSU0tU2VsZWN0b3IqMDog Li4uDQoNCkF1dGhlbnRpY2F0aW9uLVJlc3VsdHMqMTogLi4uDQpES0lNLURvbWFpbioxOiAuLi4N CkRLSU0tU2VsZWN0b3IqMTogLi4uDQoNCk5vdCBwcmV0dHksIGJ1dCBpdCB3b3VsZCB3b3JrLg0K DQpJJ20gYSBsaXR0bGUgd29ycmllZCBhYm91dCB0aGUgInNlbmQgb25lIHJlcG9ydCBwZXIgYXV0 aGVudGljYXRpb24gZmFpbHVyZSIgYmVjYXVzZSBpZiBJIHNlbmQgYSBtZXNzYWdlIHdpdGggdHdl bnR5IGJvZ3VzIHNpZ25hdHVyZXMgYmVhcmluZyB5b3VyIGRvbWFpbiBuYW1lLCB0aGF0J3MgYW4g YW1wbGlmaWNhdGlvbiBhdHRhY2suDQoNCj4gSSBzZWUgdGhhdCB0aGUgQUJORiBpbiBzZWN0aW9u IDQgb2YgdGhlIGRyYWZ0IGRvZXNuJ3QgdXBkYXRlIHRoZQ0KPiBmZWVkYmFjay1yZXBvcnQgQUJO RiBpbiBzZWN0aW9uIDMuNSBvZiBSRkMgNTk2NS4gIEl0IGJldHRlciBkbyB0aGF0DQo+IG9yIHRo ZXJlJ3Mgbm8gcGxhY2UgaW4gYW4gQVJGIHJlcG9ydCB3aGVyZSB0aGUgbmV3IGxpbmVzIGNhbiBv Y2N1ci4NCg0KSXQncyBjb3ZlcmVkIGJ5ICJleHQtZmllbGQiIGluIFNlY3Rpb24gMy41IG9mIFJG QzU5NjUsIGlzbid0IGl0Pw0K From johnl@iecc.com Wed Oct 12 23:31:51 2011 Return-Path: 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 480C421F8AF3 for ; Wed, 12 Oct 2011 23:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 6MnTa40FixSV for ; Wed, 12 Oct 2011 23:31:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6C21F89B8 for ; Wed, 12 Oct 2011 23:31:50 -0700 (PDT) Received: (qmail 1221 invoked from network); 13 Oct 2011 06:31:50 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 13 Oct 2011 06:31:50 -0000 Received: (qmail 34361 invoked from network); 13 Oct 2011 06:31:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Oct 2011 06:31:50 -0000 Date: 13 Oct 2011 06:31:28 -0000 Message-ID: <20111013063128.77326.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 06:31:51 -0000 >The other idea I had borrows from a MIME extension: > >Authentication-Results*0: ... >DKIM-Domain*0: ... >DKIM-Selector*0: ... > >Authentication-Results*1: ... >DKIM-Domain*1: ... >DKIM-Selector*1: ... > >Not pretty, but it would work. Yuck. >I'm a little worried about the "send one report per authentication >failure" because if I send a message with twenty bogus signatures >bearing your domain name, that's an amplification attack. I suppose, although if I want to mailbomb you indirectly, it's not noticably harder to send 20 messages each with one bogus signature. Until now, all of the major use of ARF was to send back mail to the actual sender, so you could never get more reports than you sent mail. This thing solicits reports of mail sent by other people so the risk of indirect mailbomb is in inherent in it. >> I see that the ABNF in section 4 of the draft doesn't update the >> feedback-report ABNF in section 3.5 of RFC 5965. It better do that >> or there's no place in an ARF report where the new lines can occur. > >It's covered by "ext-field" in Section 3.5 of RFC5965, isn't it? Not if they're supposed to go into the repeating groups. R's, John From msk@cloudmark.com Thu Oct 13 00:15:40 2011 Return-Path: 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 C667F21F847F for ; Thu, 13 Oct 2011 00:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 rSf15HZmCtma for ; Thu, 13 Oct 2011 00:15:39 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7021F84CC for ; Thu, 13 Oct 2011 00:15:39 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 13 Oct 2011 00:15:38 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 13 Oct 2011 00:15:38 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyJccsV/F9XbnOERaiGK2G/5EnFAAABgKXg Message-ID: References: <20111013063128.77326.qmail@joyce.lan> In-Reply-To: <20111013063128.77326.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 07:15:40 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDExIDEx OjMxIFBNDQo+IFRvOiBtYXJmQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+ IFN1YmplY3Q6IFJlOiBbbWFyZl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0 Zi1tYXJmLWF1dGhmYWlsdXJlLXJlcG9ydC0wMy50eHQNCj4gDQo+ID5JJ20gYSBsaXR0bGUgd29y cmllZCBhYm91dCB0aGUgInNlbmQgb25lIHJlcG9ydCBwZXIgYXV0aGVudGljYXRpb24NCj4gPmZh aWx1cmUiIGJlY2F1c2UgaWYgSSBzZW5kIGEgbWVzc2FnZSB3aXRoIHR3ZW50eSBib2d1cyBzaWdu YXR1cmVzDQo+ID5iZWFyaW5nIHlvdXIgZG9tYWluIG5hbWUsIHRoYXQncyBhbiBhbXBsaWZpY2F0 aW9uIGF0dGFjay4NCj4gDQo+IEkgc3VwcG9zZSwgYWx0aG91Z2ggaWYgSSB3YW50IHRvIG1haWxi b21iIHlvdSBpbmRpcmVjdGx5LCBpdCdzIG5vdA0KPiBub3RpY2FibHkgaGFyZGVyIHRvIHNlbmQg MjAgbWVzc2FnZXMgZWFjaCB3aXRoIG9uZSBib2d1cyBzaWduYXR1cmUuDQo+IFVudGlsIG5vdywg YWxsIG9mIHRoZSBtYWpvciB1c2Ugb2YgQVJGIHdhcyB0byBzZW5kIGJhY2sgbWFpbCB0byB0aGUN Cj4gYWN0dWFsIHNlbmRlciwgc28geW91IGNvdWxkIG5ldmVyIGdldCBtb3JlIHJlcG9ydHMgdGhh biB5b3Ugc2VudCBtYWlsLg0KPiBUaGlzIHRoaW5nIHNvbGljaXRzIHJlcG9ydHMgb2YgbWFpbCBz ZW50IGJ5IG90aGVyIHBlb3BsZSBzbyB0aGUgcmlzaw0KPiBvZiBpbmRpcmVjdCBtYWlsYm9tYiBp cyBpbiBpbmhlcmVudCBpbiBpdC4NCg0KU291bmRzIGxpa2UgZm9kZGVyIGZvciBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyB0aGVuLg0KDQo+ID5JdCdzIGNvdmVyZWQgYnkgImV4dC1maWVsZCIgaW4g U2VjdGlvbiAzLjUgb2YgUkZDNTk2NSwgaXNuJ3QgaXQ/DQo+IA0KPiBOb3QgaWYgdGhleSdyZSBz dXBwb3NlZCB0byBnbyBpbnRvIHRoZSByZXBlYXRpbmcgZ3JvdXBzLg0KDQpPb3BzLCByaWdodC4N Cg0K From hfontana@ecertsystems.com Thu Oct 13 09:51:14 2011 Return-Path: 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 902D621F84B1 for ; Thu, 13 Oct 2011 09:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9ypXhLq54tAf for ; Thu, 13 Oct 2011 09:51:14 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FC21F84D7 for ; Thu, 13 Oct 2011 09:51:11 -0700 (PDT) Received: by qadb12 with SMTP id b12so266193qad.31 for ; Thu, 13 Oct 2011 09:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:disposition-notification-to; bh=XYwzaapjWnx7btVNfnKsHwi4CMR2Gu3p68N6d2S9F4c=; b=X4y4XxnTIpZLDwjbT8TM7a+Eo/aBZJfzKeka2F8R97n/4OHvw/IAiCnptyRomBmCoV LsEKE8yn0MaPeSCTfW9DIzEQ+h7U9NwTsT4gsbtEkh8PLLJUxaqycHWmbFSoCX3Sycfq 5YBex4ESM6hnWlhyVrSF3s7L7XhBBIXq4Icog= Received: by 10.68.11.138 with SMTP id q10mr10163328pbb.37.1318524668898; Thu, 13 Oct 2011 09:51:08 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id o6sm13172668pbb.1.2011.10.13.09.51.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 09:51:07 -0700 (PDT) From: "Hilda Fontana" To: "'John Levine'" , References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: <20111012041112.66464.qmail@joyce.lan> Date: Thu, 13 Oct 2011 09:50:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+ox1ZXmhKejDKdqc3eVKI3ihBYZWWSZmQ Content-Language: en-us Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 16:51:14 -0000 " Rather than inventing complex rules about which item goes with which report, if you have three failures, send three reports" I think there is going to be a lot of push back for multiple failure reports per email - would definitely be better to find the best way to specify the multiple failures within one email for the email that had the failures in it. - i.e. one to one > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > John Levine > Sent: Tuesday, October 11, 2011 9:11 PM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure- > report-03.txt > > This draft is a great improvement. > > I would strongly suggest changing the text to say there must be exactly one > authentication-results header in the report. If there's more than one, > particularly if there are multiple DKIM failures, there's no way to tell which > other parts of the report go with which a-r header. > > Note that multiple DKIM failures could easily have multiple reported > domains, multiple auth-failure, dkim-domain, dkim-identity, dkim-selector, > dkim-canonicalized-header, and dkim-canonicalized body. (Remember that > there are two different ways to canonicalize each.) > > Rather than inventing complex rules about which item goes with which > report, if you have three failures, send three reports. > > R's, > John > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From johnl@taugh.com Thu Oct 13 10:41:39 2011 Return-Path: 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 0BE6121F8B31 for ; Thu, 13 Oct 2011 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Z7+8xFtt5m0W for ; Thu, 13 Oct 2011 10:41:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6650E21F8ACC for ; Thu, 13 Oct 2011 10:41:37 -0700 (PDT) Received: (qmail 4729 invoked from network); 13 Oct 2011 17:41:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1278.4e9722d0.k1110; bh=mKOBlwwMjCRUN/XkGHfETzU3OKyGrw1odrwNUnScqYY=; b=kitVsWYoS40QmU4JzhMaU4g172YXIIneydvk5j0UohKos7xNOwDtUpzXZO6w/tVILH65iS8l30yKz0rWJe4t9Naa/TJXZMkplLidvLVH8f/QirBSgdcBXtUcOiJaEARvs9oyD3tizFcF22dAO8aCU/DLezR+CWRolNMkpQGFF5M= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1278.4e9722d0.k1110; bh=mKOBlwwMjCRUN/XkGHfETzU3OKyGrw1odrwNUnScqYY=; b=yTUqTATIeSJUxme7Ebx8zCzNfdRWeCl2YsFgrxWwzwdGcCa/XQKUlGWpp1syPyginELhO6cuJd6wX3NqigTGLz831Ky1uxDJFo85lnYkQoWAp/X9tjOB6mep3AQRQGWGCNftv9AgUvdPsYD+2dvq/iEk0nkYD4chuJIw08mPb2E= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Oct 2011 17:41:13 -0000 Date: 13 Oct 2011 13:41:35 -0400 Message-ID: From: "John R Levine" To: "Hilda Fontana" In-Reply-To: References: <20111012041112.66464.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ARF mailing list Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:41:39 -0000 > " Rather than inventing complex rules about which item goes with which > report, if you have three failures, send three reports" > > I think there is going to be a lot of push back for multiple failure reports > per email Keeping in mind that these are primarily intended for computers rather than people to read, what problem does multiple reports cause? They all contain a copy of the same message, if you want to correlate them, the programming is trivial. R's, John From vesely@tana.it Fri Oct 14 08:43:54 2011 Return-Path: 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 E8EEC21F8C87 for ; Fri, 14 Oct 2011 08:43:54 -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 gZHMiKBNNQHn for ; Fri, 14 Oct 2011 08:43:54 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3522B21F8C80 for ; Fri, 14 Oct 2011 08:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318607032; bh=4oGlqdYn800vOouEqZL42VqWEGJk9rOElNLP4lTbH4w=; l=879; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LTLHtk5hkYvwXsaaVHne1KzGv4s2cFkpU/UNFnr4Pmbwqvn3J+szl/jXZGn3zW373 p+qVdTTN60nLthJ8f1oiQQOaxIW8E1sp4lmW/RUGsX97zBBLpi6LrEoVtK21UFwDGx oCWATfPSbrROpapR19DfS+0RcCZcyJFpuscqDMLY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 14 Oct 2011 17:43:52 +0200 id 00000000005DC04B.000000004E9858B8.00001CBE Message-ID: <4E9858B6.8000306@tana.it> Date: Fri, 14 Oct 2011 17:43:50 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111013061455.73257.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:43:55 -0000 On 13/Oct/11 08:24, Murray S. Kucherawy wrote: > > The other idea I had borrows from a MIME extension: > > Authentication-Results*0: ... > DKIM-Domain*0: ... > DKIM-Selector*0: ... > > Authentication-Results*1: ... > DKIM-Domain*1: ... > DKIM-Selector*1: ... If we stick to the "exactly one" A-R record, why would we need more fields? Each "resinfo" line already has all the information we need, already correctly grouped --except for selectors, we miss header.s if we don't want to retrieve s= from the third part, in the signature having the corresponding header.b. The only other data is the TXT RRs the verifier found. We ought to devise a format that allows as many of these as needed, with each repeated field including the query as well. It'd be a nuisance to require different formatting according to the purpose of each RFC 1035 packet. jm2c From hfontana@ecertsystems.com Fri Oct 14 12:07:56 2011 Return-Path: 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 80DDF21F8D27 for ; Fri, 14 Oct 2011 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HkRO-zXzhJw7 for ; Fri, 14 Oct 2011 12:07:55 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id E36B821F8CF5 for ; Fri, 14 Oct 2011 12:07:55 -0700 (PDT) Received: by pzk37 with SMTP id 37so6251627pzk.9 for ; Fri, 14 Oct 2011 12:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:disposition-notification-to; bh=Frvsw/saWtO9JvUkrg0bJ/wNIboU26Tv+dTZbmbxoYI=; b=ZUsh8oXiBhk69J5fYJroDurspFbqBcTDeoaZ7tlZoCiw3X/6PnqORPp2EG/YBSEiDz ubQpx3VdJNVXAU3dfJwmpyOrcmADU9//WLm2HH6+WIfhoOSefSxBLW2yfliLuVbmlxGH PCLI2xl/mme5Ll110FbE/V9/JXqe/vXSt9rMw= Received: by 10.68.74.106 with SMTP id s10mr18537078pbv.78.1318619275567; Fri, 14 Oct 2011 12:07:55 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id z3sm25627734pbu.7.2011.10.14.12.07.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 12:07:54 -0700 (PDT) From: "Hilda Fontana" To: "'John R Levine'" References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: Date: Fri, 14 Oct 2011 12:07:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqEU4Co18J0tgb2xFivY7Ts64RGAG+ox1ZAll4AIwCnRGmp5QLfNXw Content-Language: en-us Cc: 'ARF mailing list' Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:07:56 -0000 > Keeping in mind that these are primarily intended for computers rather than > people to read, what problem does multiple reports cause? They all contain > a copy of the same message, if you want to correlate them, the programming > is trivial. I totally agree I was thinking more of the push back from those generating them rather than those receiving them. > -----Original Message----- > From: John R Levine [mailto:johnl@taugh.com] > Sent: Thursday, October 13, 2011 10:42 AM > To: Hilda Fontana > Cc: ARF mailing list > Subject: RE: [marf] New Version Notification - draft-ietf-marf-authfailure- > report-03.txt > > > " Rather than inventing complex rules about which item goes with which > > report, if you have three failures, send three reports" > > > > I think there is going to be a lot of push back for multiple failure > > reports per email > > Keeping in mind that these are primarily intended for computers rather than > people to read, what problem does multiple reports cause? They all contain > a copy of the same message, if you want to correlate them, the programming > is trivial. > > R's, > John From msk@cloudmark.com Fri Oct 14 12:33:20 2011 Return-Path: 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 C063B21F8DA1 for ; Fri, 14 Oct 2011 12:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 iDCbFvzUAqZ4 for ; Fri, 14 Oct 2011 12:33:20 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A721F8C9E for ; Fri, 14 Oct 2011 12:33:19 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 14 Oct 2011 12:33:13 -0700 From: "Murray S. Kucherawy" To: 'ARF mailing list' Date: Fri, 14 Oct 2011 12:33:12 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AQJqEU4Co18J0tgb2xFivY7Ts64RGAG+ox1ZAll4AIwCnRGmp5QLfNXwgAAHIpA= Message-ID: References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:33:20 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of H= ilda Fontana > Sent: Friday, October 14, 2011 12:08 PM > To: 'John R Levine' > Cc: 'ARF mailing list' > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > > Keeping in mind that these are primarily intended for computers rather = than > > people to read, what problem does multiple reports cause? They all con= tain > > a copy of the same message, if you want to correlate them, the programm= ing > > is trivial. >=20 > I totally agree I was thinking more of the push back from those generatin= g > them rather than those receiving them. Can we get some commentary from others on this? I'd like to get a measure = for where consensus falls. Since this is the only current point of discuss= ion, we might be close to being able to WGLC it again. From jdfalk-lists@cybernothing.org Fri Oct 14 12:42:30 2011 Return-Path: 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 2627421F8D7A for ; Fri, 14 Oct 2011 12:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bf2af4pDRKx8 for ; Fri, 14 Oct 2011 12:42:29 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E021F8CF4 for ; Fri, 14 Oct 2011 12:42:29 -0700 (PDT) Received: from [192.168.11.37] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9EJgPUd004914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2011 12:42:28 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Fri, 14 Oct 2011 12:42:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111012041112.66464.qmail@joyce.lan> To: ARF mailing list X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:42:30 -0000 On Oct 14, 2011, at 12:33 PM, Murray S. Kucherawy wrote: > Can we get some commentary from others on this? I'd like to get a = measure for where consensus falls. Since this is the only current point = of discussion, we might be close to being able to WGLC it again. I'd like to see what happens in the real world before we start inventing = complex, ugly kludges that only apply to what I expect will be extremely = rare edge cases. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Fri Oct 14 12:43:29 2011 Return-Path: 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 3002921F8CF4 for ; Fri, 14 Oct 2011 12:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.735 X-Spam-Level: X-Spam-Status: No, score=-102.735 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 SO6qhpmH84L4 for ; Fri, 14 Oct 2011 12:43:28 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CD21F8B5E for ; Fri, 14 Oct 2011 12:43:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 14 Oct 2011 12:43:28 -0700 From: "Murray S. Kucherawy" To: ARF mailing list Date: Fri, 14 Oct 2011 12:43:27 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyKqWo2lKj0vb1MTtWjHEriUHSRGwAAA6Hg Message-ID: References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:43:29 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Friday, October 14, 2011 12:42 PM > To: ARF mailing list > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > I'd like to see what happens in the real world before we start > inventing complex, ugly kludges that only apply to what I expect will > be extremely rare edge cases. Is that a vote in favour of just sending one report for each type of failur= e? From johnl@taugh.com Fri Oct 14 14:23:42 2011 Return-Path: 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 23CAA21F8C65 for ; Fri, 14 Oct 2011 14:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 9RevAT-eJyuu for ; Fri, 14 Oct 2011 14:23:41 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 613DF21F8C60 for ; Fri, 14 Oct 2011 14:23:41 -0700 (PDT) Received: (qmail 11459 invoked from network); 14 Oct 2011 21:23:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2cc2.4e98a85b.k1110; bh=aCv+MDDr+ILBmzmdonAy0R0QQhwzYXNzrY2/5DR39q0=; b=BjU2ktpNvhg38YFudfqpLC7/2qy0qcfEG+EbPH9E1dj2RBdTiJZbQDy3ZkVFR7sX6sElflCjz2m2smUbOedNjYk3VeOz0gE5Dm5SQ2H4J9V3NWTPUkugIQJ7QtArKYlU5QmsI//NwS1/sucfvDratkXUIAbL9LOJsYCqNU0CuxY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2cc2.4e98a85b.k1110; bh=aCv+MDDr+ILBmzmdonAy0R0QQhwzYXNzrY2/5DR39q0=; b=zivXi866eJLYSXxgZQe1YccMSti+hW3EALfHI+EQn0GaoQpm0pI+20V8WvASlPBaUCeWdkJgQZgYeME8Hm8IX4Vin8tTrwgL/tDBylqpqqgxx47/IFnidNOxp3UOqkqasEzpTQybVmz76OJB5r3UVc1czmcTzYWjwgA8BoPr+2k= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Oct 2011 21:23:16 -0000 Date: 14 Oct 2011 17:23:38 -0400 Message-ID: From: "John R Levine" To: "Hilda Fontana" In-Reply-To: References: <20111012041112.66464.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'ARF mailing list' Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 21:23:42 -0000 > I totally agree I was thinking more of the push back from those generating > them rather than those receiving them. Well, OK. Given that ARF messages are invariably generated by software rather than by people, what problem is caused by them generating two or three messages to report multiple failures rather than one? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Fri Oct 14 17:01:28 2011 Return-Path: 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 E070621F8B58 for ; Fri, 14 Oct 2011 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dttO7DOnXxTs for ; Fri, 14 Oct 2011 17:01:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id F0F8A21F8B51 for ; Fri, 14 Oct 2011 17:01:27 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 14 Oct 2011 17:01:27 -0700 From: "Murray S. Kucherawy" To: 'ARF mailing list' Date: Fri, 14 Oct 2011 17:01:26 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyKt44xf0kfM3/YRuq8uXL7qDCjfwAFdIWQ Message-ID: References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 00:01:29 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn R Levine > Sent: Friday, October 14, 2011 2:24 PM > To: Hilda Fontana > Cc: 'ARF mailing list' > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > > I totally agree I was thinking more of the push back from those generat= ing > > them rather than those receiving them. >=20 > Well, OK. Given that ARF messages are invariably generated by software > rather than by people, what problem is caused by them generating two or > three messages to report multiple failures rather than one? I have to say I agree that the idea of sending one report for every DKIM/SP= F failure on a message is un-pretty, but it's less un-pretty than the two s= yntactical alternatives that have been put forward in this thread. -MSK, as participant From vesely@tana.it Sat Oct 15 05:46:04 2011 Return-Path: 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 1A4ED21F84B3 for ; Sat, 15 Oct 2011 05:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, 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 BKW-qaN8J7TS for ; Sat, 15 Oct 2011 05:46:03 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4B21F84B0 for ; Sat, 15 Oct 2011 05:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318682760; bh=tZ4gpCy6XoPi4J9ig2W5gGJY74rgq995D/cDNYvqn3Y=; l=2347; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=jGBYoF3zc2DWre/T68dFTxY7T7QCQ7IndMaP4PAPm20atZ41fKrR9w7CFD04vJ8w4 NuifdCalBQj1x2PonjEdTwGB8Q4X+c0Ly5y62lMLGxYjdXrwYk5qhluKOkPaPDw/Xu Y8eXFvM9Px7PL1wwwCMVSK64B7EPZ0BqPZEdIXIw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 15 Oct 2011 14:46:00 +0200 id 00000000005DC03F.000000004E998088.0000057F Message-ID: <4E998087.3070705@tana.it> Date: Sat, 15 Oct 2011 14:45:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 12:46:04 -0000 On 15/Oct/11 02:01, Murray S. Kucherawy wrote: > > I have to say I agree that the idea of sending one report for every > DKIM/SPF failure on a message is un-pretty, but it's less un-pretty > than the two syntactical alternatives that have been put forward in > this thread. I'm not clear on what two syntactical alternatives you mean, since I proposed two myself http://www.ietf.org/mail-archive/web/marf/current/msg01403.html http://www.ietf.org/mail-archive/web/marf/current/msg01418.html My concept of un-pretty is having redundant data, as it brings uncertainty on how to process it. Thus, my first proposal was to drop A-R from the second part. John then proposed to have exactly one A-R in the second part. You then proposed to store the other data in repeating groups of fields. My second proposal then was to have exactly one A-R field that includes one "resinfo" stanza for each failed check, dropping the three method-specific multiple fields defined in Section 3.2.2, since the values that they convey can be stuffed in the relevant resinfo. For example: Authentication-Results: authserv-id.example; dkim=fail header.d=DKIM-Domain-0.example header.i=DKIM-Identity-0@dkim-domain-0.example header.s=DKIM-Selector-0.example; dkim=fail header.d=DKIM-Domain-1.example header.i=DKIM-Identity-1@dkim-domain-1.example header.s=DKIM-Selector-1.example header.b=MAynEEdThis/asWeLL==; (...) Except header.s, all that is already specified, especially the grouping. DKIM-Canonicalized-Header/Body don't need to be repeated, and any DNS entry can be recognized by its query part. What's wrong with this? Rather than specifying those fields (DKIM-Domain, DKIM-Identity, and DKIM-Selector) Section 3.2.2 can define header.s and recall the other required tags for DKIM resinfos, while Section 3.1 can further constrain how the second part's A-R should be composed, for example The "authserv-id" token of the Authentication-Results field in the second part SHOULD match the corresponding token of any Authentication-Results field in the third part that was added by the reporting verifier, and MUST NOT match the corresponding token of any Authentication-Results fields in the third part that had been added by some other verifiers. (Ouch, this text is /really/ un-pretty...) From sklist@kitterman.com Sat Oct 15 08:31:00 2011 Return-Path: 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 5CD8721F85A4 for ; Sat, 15 Oct 2011 08:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RqLdDgopz0Sp for ; Sat, 15 Oct 2011 08:30:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF81621F8569 for ; Sat, 15 Oct 2011 08:30:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 78CFE20E40FA; Sat, 15 Oct 2011 11:30:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1318692657; bh=uC9O+r6iMkChk5TvOErm4h+2mfaYaUFYJnLJMmjvb0s=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EnM/HEc3cnSx3kk7uFq+MwT9nbdxWWstolsYAX6+AIivdtgY5Y23cjnPfmxwBzIZ6 vCrA70hFv4HS/+ZE3jp8Votj+tw4tLGeI71e44ZgIs5WY4PPfjW7A1oFc96o6ShSQ7 kfnz9ZX46gb0V/zZ+uJVJt7oZC/b02IoUgB2dTBU= Received: from [192.168.111.113] (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 5411F20E4081; Sat, 15 Oct 2011 11:30:57 -0400 (EDT) Message-ID: <4E99A730.6020206@kitterman.com> Date: Sat, 15 Oct 2011 11:30:56 -0400 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111012041112.66464.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 15:31:00 -0000 On 10/14/2011 05:23 PM, John R Levine wrote: >> I totally agree I was thinking more of the push back from those >> generating >> them rather than those receiving them. > > Well, OK. Given that ARF messages are invariably generated by software > rather than by people, what problem is caused by them generating two or > three messages to report multiple failures rather than one? The one complication I can think of is that if there is the potential for getting multiple messages, there's no way to tell if you are going to get more. I agree that correlating multiple reports about a single message into a single "meta-report" for local use would not be a problem. The problem might be knowing when you had gotten all the reports you were going to get so you could do that processing. Scott K From johnl@iecc.com Sat Oct 15 10:12:33 2011 Return-Path: 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 CEA9021F8B19 for ; Sat, 15 Oct 2011 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.874 X-Spam-Level: X-Spam-Status: No, score=-110.874 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 IPL3sMHB4EHL for ; Sat, 15 Oct 2011 10:12:33 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4626E21F8AF1 for ; Sat, 15 Oct 2011 10:12:32 -0700 (PDT) Received: (qmail 28069 invoked from network); 15 Oct 2011 17:12:31 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 15 Oct 2011 17:12:31 -0000 Received: (qmail 20510 invoked from network); 15 Oct 2011 17:12:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Oct 2011 17:12:31 -0000 Date: 15 Oct 2011 17:12:06 -0000 Message-ID: <20111015171206.6021.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E99A730.6020206@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 17:12:33 -0000 >The one complication I can think of is that if there is the potential >for getting multiple messages, there's no way to tell if you are going >to get more. If that were really a problem (it's not clear to me why it would be), it wouldn't be hard to invent a line like Group-Count: with a hint of how many related reports were sent to the same target at about the same time. My impression is that you're more likely to want to correlate multiple reports about similar failures to different messages rather than different failures to one message. R's, John From sklist@kitterman.com Sat Oct 15 11:52:28 2011 Return-Path: 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 8D6AE21F8AB8 for ; Sat, 15 Oct 2011 11:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9ebm77SioYGb for ; Sat, 15 Oct 2011 11:52:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E921F84D7 for ; Sat, 15 Oct 2011 11:52:26 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id EF924D0407E; Sat, 15 Oct 2011 13:52:25 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1318704746; bh=VsUlwPOWzrtN41pbrIw5LzwW980dYUK7/zrxCSnw8fA=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=MqYX9tXp5s+h69/T3j7wrLU9qM0uuEksuJTpoM9nPMYk77eKQ9KMTm3mTXqQlFGeX k+mmgDrWK/sq/DFzmbHkGcRmuXzJpl/aOGBtZCxjnmrrx50zVdlT7Z1/DxGjByPlJ6 aa8XHSWa+HszCYrv3YGYZfKtKixF4Pgy3u1ItXHI= Received: from [192.168.111.101] (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 mailout03.controlledmail.com (Postfix) with ESMTPSA id B1924D04052; Sat, 15 Oct 2011 13:52:25 -0500 (CDT) References: <20111015171206.6021.qmail@joyce.lan> User-Agent: K-9 Mail for Android In-Reply-To: <20111015171206.6021.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 15 Oct 2011 14:52:36 -0400 To: marf@ietf.org Message-ID: <95d04651-79fb-405e-9f94-35a93cbef526@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 18:52:28 -0000 John Levine wrote: >>The one complication I can think of is that if there is the potential >>for getting multiple messages, there's no way to tell if you are going > >>to get more. > >If that were really a problem (it's not clear to me why it would be), >it wouldn't be hard to invent a line like Group-Count: with a hint of >how many related reports were sent to the same target at about the >same time. > >My impression is that you're more likely to want to correlate multiple >reports about similar failures to different messages rather than >different failures to one message. In my experience it's generally about trying to associate failure types and sources. Having information about multiple authentication types can be helpful in this. Having all the facts about one message arrive together feels right from an system perspective. It's either arrived or not and there's no need to consider partial availability of data. OTOH, it may just be a minor corner case. I suspect that all the information in one mail makes this RFC a bit more complicated, but it will make some types of implementations that make use of this data less complex and subject to race conditions. Scott K From msk@cloudmark.com Sat Oct 15 20:09:23 2011 Return-Path: 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 1EEEF21F844B for ; Sat, 15 Oct 2011 20:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 2Fl4ZKxZiyl7 for ; Sat, 15 Oct 2011 20:09:22 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA2C21F844C for ; Sat, 15 Oct 2011 20:09:22 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 15 Oct 2011 20:09:21 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 15 Oct 2011 20:09:20 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyLOGjEuT1Cjcm0SpqNwRm5p89c7wAd6Bfw Message-ID: References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> In-Reply-To: <4E998087.3070705@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 03:09:23 -0000 > -----Original Message----- > From: Alessandro Vesely [mailto:vesely@tana.it] > Sent: Saturday, October 15, 2011 5:46 AM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > On 15/Oct/11 02:01, Murray S. Kucherawy wrote: > > > > I have to say I agree that the idea of sending one report for every > > DKIM/SPF failure on a message is un-pretty, but it's less un-pretty > > than the two syntactical alternatives that have been put forward in > > this thread. >=20 > I'm not clear on what two syntactical alternatives you mean, since I > proposed two myself > http://www.ietf.org/mail-archive/web/marf/current/msg01403.html Maybe I'm just not understanding it, but this one doesn't seem to address t= he question we're discussing. > http://www.ietf.org/mail-archive/web/marf/current/msg01418.html This one does, but it doesn't take into consideration the canonicalized DKI= M content fields, which might need to be repeated. > My concept of un-pretty is having redundant data, as it brings > uncertainty on how to process it. Thus, my first proposal was to drop > A-R from the second part. John then proposed to have exactly one A-R > in the second part. You then proposed to store the other data in > repeating groups of fields. My second proposal then was to have > exactly one A-R field that includes one "resinfo" stanza for each > failed check, dropping the three method-specific multiple fields > defined in Section 3.2.2, since the values that they convey can be > stuffed in the relevant resinfo. For example: >=20 > Authentication-Results: authserv-id.example; > dkim=3Dfail > header.d=3DDKIM-Domain-0.example > header.i=3DDKIM-Identity-0@dkim-domain-0.example > header.s=3DDKIM-Selector-0.example; > dkim=3Dfail > header.d=3DDKIM-Domain-1.example > header.i=3DDKIM-Identity-1@dkim-domain-1.example > header.s=3DDKIM-Selector-1.example > header.b=3DMAynEEdThis/asWeLL=3D=3D; > (...) >=20 > Except header.s, all that is already specified, especially the > grouping. DKIM-Canonicalized-Header/Body don't need to be repeated, > and any DNS entry can be recognized by its query part. You're right, we'd have to register "header.s" as something Authentication-= Results can report. But you're also right that this would be enough to ind= icate results for multiple signatures, since that's what "header.b" was add= ed to do. However, the canonicalized fields might need to be repeated, depending on w= hether different signatures use different canonicalizations or whether "l= =3D" is in use. That's the complicated part. > Rather than specifying those fields (DKIM-Domain, DKIM-Identity, and > DKIM-Selector) Section 3.2.2 can define header.s and recall the other > required tags for DKIM resinfos, while Section 3.1 can further > constrain how the second part's A-R should be composed, for example >=20 > The "authserv-id" token of the Authentication-Results field in > the second part SHOULD match the corresponding token of any > Authentication-Results field in the third part that was added by > the reporting verifier, and MUST NOT match the corresponding > token of any Authentication-Results fields in the third part that > had been added by some other verifiers. I'm not clear on why we'd need to say this. Isn't the specification of the= authserv-id already sufficiently clear, and it's obvious you'd need to use= it properly and consistently for it to be meaningful? Then again, if the recipient of this reports trusts who sent it, then the a= uthserv-id doesn't really matter. -MSK From vesely@tana.it Sun Oct 16 06:59:59 2011 Return-Path: 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 4190921F88B7 for ; Sun, 16 Oct 2011 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.344 X-Spam-Level: X-Spam-Status: No, score=-4.344 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, 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 7g3bSNfGstCE for ; Sun, 16 Oct 2011 06:59:58 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 34E2321F88A0 for ; Sun, 16 Oct 2011 06:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318773595; bh=xoemYrWs2sB49tul6rqfJyPKIXaoNvhD4ss4yNG+FfU=; l=3762; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MpWY+/MusD5c8oFTwlQStaFtlbb15Eop/+UKQYadhj5RN8puMWl0MPN9EbEQKEfSV 1DkvtAtepRzdd5P5EH2znQLfv2iIf5Z7XqBs68UBo7ekjBgv8/OmwJS7YWciSU1gxK mPSdyMKmANMoeLtmVbLw6FB8DJGlHCawIpUwYMsk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 16 Oct 2011 15:59:55 +0200 id 00000000005DC045.000000004E9AE35B.000064B1 Message-ID: <4E9AE35A.2040406@tana.it> Date: Sun, 16 Oct 2011 15:59:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 13:59:59 -0000 On 16/Oct/11 05:09, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Alessandro Vesely >> >> Authentication-Results: authserv-id.example; >> dkim=fail >> header.d=DKIM-Domain-0.example >> header.i=DKIM-Identity-0@dkim-domain-0.example >> header.s=DKIM-Selector-0.example; >> dkim=fail >> header.d=DKIM-Domain-1.example >> header.i=DKIM-Identity-1@dkim-domain-1.example >> header.s=DKIM-Selector-1.example >> header.b=MAynEEdThis/asWeLL==; > [...] > > However, the canonicalized fields might need to be repeated, > depending on whether different signatures use different > canonicalizations or whether "l=" is in use. That's the > complicated part. Correct, I missed different canonicalizations. Body canonicalizations are not signature-specific and at most two of them are needed, thus we can get away with something like DKIM-Canonicalized-Body: relaxed: BLAHBLAH.... DKIM-Canonicalized-Body: simple: blahblah.... Tag l= doesn't play, unless we want to report hashes too. Instead, header canonicalization depends on both the h= and c= tags. Quoting the sig-h-tag is cumbersome, and makes it difficult for recipients to find the canonicalization they are looking for. A possible solution may be to repeat the value of header.b, as a pointer into the relevant signature DKIM-Canonicalized-Header: 12345678: BLAHblah.... If we don't need to optimize for reporting many signatures, we can use the latter syntax also for the body, for the sake of uniformity. Actually, we can as well use this syntax for any DKIM field. >> The "authserv-id" token of the Authentication-Results field in >> the second part SHOULD match the corresponding token of any >> Authentication-Results field in the third part that was added by >> the reporting verifier, and MUST NOT match the corresponding >> token of any Authentication-Results fields in the third part that >> had been added by some other verifiers. > > I'm not clear on why we'd need to say this. Nor am I, honestly. I just point out that some similar consideration ought to be addressed. > Isn't the specification of the authserv-id already sufficiently > clear, and it's obvious you'd need to use it properly and > consistently for it to be meaningful? Yes, you're right, RFC 5451, Section 2.3 says The authentication identifier field provides a unique identifier that refers to the authenticating service within a given ADMD. The uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and must pertain to exactly that one ADMD. But what are the relationships among authenticating service, verifier, and reporter? > Then again, if the recipient of this reports trusts who sent it, > then the authserv-id doesn't really matter. It's only use, AFAICS, is to relate the A-R in the second part with one or more A-Rs in the reported message, which may be not obvious in some edge cases. While the generation of debugging reports --those sporting DNS RRs-- has to be integrated within the verifier, reports sent for policy tracking purposes can also be sent by agents further down a message's path. Policy methods, such as SPF, VBR, and ADSP, are more plausible than DKIM for policy tracking purposes. A reporting agent of this kind probably relies on existing A-R fields, part of which it copies to the second part's A-R. However, it may or may not wish to disclose the id(s) of those report-triggering A-R fields. In that scenario, since RFC 5451's "authenticating service" may relate to either the actual verifier or to a service that uses it, the reporting agent is entitled to either reuse the authserv-id in the message's A-R it relies on, or set its own unique id. From msk@cloudmark.com Tue Oct 18 16:20:13 2011 Return-Path: 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 1A1A821F84D9 for ; Tue, 18 Oct 2011 16:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 B0bC-LqdnqFF for ; Tue, 18 Oct 2011 16:20:12 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id A97C221F84D8 for ; Tue, 18 Oct 2011 16:20:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 18 Oct 2011 16:20:12 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 18 Oct 2011 16:20:10 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyMC/FRtl1FLs17SyqiHnW45WnbcgB4EKCQ Message-ID: References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> In-Reply-To: <4E9AE35A.2040406@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:20:13 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Sunday, October 16, 2011 7:00 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Correct, I missed different canonicalizations. Body canonicalizations > are not signature-specific and at most two of them are needed, thus we > can get away with something like >=20 > DKIM-Canonicalized-Body: relaxed: > BLAHBLAH.... > DKIM-Canonicalized-Body: simple: > blahblah.... >=20 > Tag l=3D doesn't play, unless we want to report hashes too. That's not true; if "l=3D" is there in one signature and not in another, th= en those two will produce different canonicalized bodies, even if they use = the same canonicalization. > It's only use, AFAICS, is to relate the A-R in the second part with > one or more A-Rs in the reported message, which may be not obvious in > some edge cases. Actually in the context of the report, I would trust the report's A-R and n= one of the quoted ones. I know for certain where it originated. And in th= at sense, the "authserv-id" doesn't really matter here. From msk@cloudmark.com Tue Oct 18 16:22:45 2011 Return-Path: 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 99F7921F8AA8 for ; Tue, 18 Oct 2011 16:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 UbtFRYe9Uu+s for ; Tue, 18 Oct 2011 16:22:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B179321F8A70 for ; Tue, 18 Oct 2011 16:22:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 18 Oct 2011 16:22:44 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 18 Oct 2011 16:22:43 -0700 Thread-Topic: Consensus on the multiple reports point Thread-Index: AcyN7NaN+b3mj56QQ76bk3pJXuCP2w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C14AF0EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Consensus on the multiple reports point X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:22:45 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14AF0EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Can I please get a reading of WG consensus on the issue of sending multiple= reports for a multiply-signed message? This is the only remaining issue b= efore doing a second (perhaps short) WGLC on draft-ietf-marf-authfailure-re= port and then preparing to send it to the IESG. There were other editorial= issues, mostly from me, that don't appear to be contentious since nobody e= lse has commented on them, so that's where we're at. I know John is in favour of this (it was his idea), and it gets a +1 from m= e as participant since all of the syntax-related solutions we've considered= thus far have substantial drawbacks. Hilda had some reservations on the g= rounds that report generators might not like it much. I'd like to see more= opinions registered. -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F19C6C14AF0EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /o:p>

 

Can= I please get a reading of WG consensus on the issue of sending multiple re= ports for a multiply-signed message?  This is the only remaining issue= before doing a second (perhaps short) WGLC on draft-ietf-marf-authfailure-= report and then preparing to send it to the IESG.  There were other ed= itorial issues, mostly from me, that don’t appear to be contentious s= ince nobody else has commented on them, so that’s where we’re a= t.

 

I know John is in favour of this (it was his idea), and it gets a +1 f= rom me as participant since all of the syntax-related solutions we’ve= considered thus far have substantial drawbacks.  Hilda had some reser= vations on the grounds that report generators might not like it much. = I’d like to see more opinions registered.

 

-MSK, as co-chair

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14AF0EXCHC2corpclo_-- From steve@wordtothewise.com Tue Oct 18 16:28:31 2011 Return-Path: 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 A7AC621F8AF2 for ; Tue, 18 Oct 2011 16:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4ukaon4tsjpB for ; Tue, 18 Oct 2011 16:28:31 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 253AC21F8AF1 for ; Tue, 18 Oct 2011 16:28:31 -0700 (PDT) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id AC3AD2DEC3 for ; Tue, 18 Oct 2011 16:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1318980510; bh=kIjy3YhOEHO/cNpjHl3bapuoULGsOCovUBaQKKZKgQA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=KIZEuaQ4Hw4wc50Prgi68jUzAq7XQkDKnQIng3nhazMqKO216EyiSAMKe2xTI2sB6 FJGLDBvfd9lY/pY8kTJdLNFgvMwkwV14TsfR1QwCuVRJe1p6BDlfFc9Rs+HAZ+6Kfl XkdgKHQAaE35cHTZepQH2YFuttuTVy0G0rIN7UrA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Tue, 18 Oct 2011 16:28:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Consensus on the multiple reports point X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:28:31 -0000 On Oct 18, 2011, at 4:22 PM, Murray S. Kucherawy wrote: > Hello all, > =20 > Can I please get a reading of WG consensus on the issue of sending = multiple reports for a multiply-signed message? This is the only = remaining issue before doing a second (perhaps short) WGLC on = draft-ietf-marf-authfailure-report and then preparing to send it to the = IESG. There were other editorial issues, mostly from me, that don=92t = appear to be contentious since nobody else has commented on them, so = that=92s where we=92re at. > =20 > I know John is in favour of this (it was his idea), and it gets a +1 = from me as participant since all of the syntax-related solutions we=92ve = considered thus far have substantial drawbacks. Hilda had some = reservations on the grounds that report generators might not like it = much. I=92d like to see more opinions registered. Multiple reports for multiple failed signatures seems the least bad = solution. +1 from me. Cheers, Steve From vesely@tana.it Wed Oct 19 04:07:34 2011 Return-Path: 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 3B8AC21F85AA for ; Wed, 19 Oct 2011 04:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, 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 Q2UxwMlxHQl9 for ; Wed, 19 Oct 2011 04:07:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96021F85A8 for ; Wed, 19 Oct 2011 04:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319022446; bh=LU/nz3IiCG3NBc1K9tCLliFXFz7kXC9nyNIER/fe21s=; l=1989; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DspTTAEtYzpIQ2wB+9HgLaMfQiW6e/E5zQUQBaW2PmYqFWFgvEchiLXUNGaoNCBXb 3EzQpEz2/G3JqQq/K7avlh0wszA93hU1xzrCp6zE11Hmus4GVZNs3EEW72kzX7L6Ym ftNxtaOjJVzyGxbcNRcimnHww+7FLnJregKBeNmM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 19 Oct 2011 13:07:26 +0200 id 00000000005DC03F.000000004E9EAF6E.000012D8 Message-ID: <4E9EAF6D.6020008@tana.it> Date: Wed, 19 Oct 2011 13:07:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:07:34 -0000 On 19/Oct/11 01:20, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> DKIM-Canonicalized-Body: relaxed: >> BLAHBLAH.... >> DKIM-Canonicalized-Body: simple: >> blahblah.... >> >> Tag l= doesn't play, unless we want to report hashes too. > > That's not true; if "l=" is there in one signature and not in > another, then those two will produce different canonicalized > bodies, even if they use the same canonicalization. Not formally. Section 3.4 of RFC 6376 specifies canonicalization with no mention of l=. OTOH, Section 3.7 says In hash step 1, the Signer/Verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and /then/ truncated to the length specified in the "l=" tag. [emphasis added] Does the definition of DKIM-Canonicalized-Body in Section 3.2.3 have to specify that "the canonicalized body MAY be truncated to a length greater or equal to the value of (the highest) l="? >> [Authser-id]'s only use, AFAICS, is to relate the A-R in the second >> part with one or more A-Rs in the reported message, which may be not >> obvious in some edge cases. > > Actually in the context of the report, I would trust the report's > A-R and none of the quoted ones. I know for certain where it > originated. And in that sense, the "authserv-id" doesn't really > matter here. I agree that it is sound to have the results of apposite checks in the report's A-R. That really depends on how the report's A-R is going to be specified. One possibility is to implement a meaning of "here's why I'm sending this report". Such semantics would exclude, for example, spf=pass if the reported failure is a broken signature. Indeed, that's not relevant for debugging, and for generic policy tracking it might be as good to know as, say, Received: fields. In any case, the contents of the report's A-R ought to be specified and exemplified in the I-D, IMHO. From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 19 05:30:26 2011 Return-Path: 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 91EB921F8B77 for ; Wed, 19 Oct 2011 05:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, 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 9A9abCrZcFAO for ; Wed, 19 Oct 2011 05:30:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E759521F8AFB for ; Wed, 19 Oct 2011 05:30:25 -0700 (PDT) Received: by wwe6 with SMTP id 6so1657163wwe.13 for ; Wed, 19 Oct 2011 05:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=c8DiR8Iv3ut22s4y82ebsvJ7ZlsfGM39/ukzl9bAZhk=; b=VQ5a48ZEmN15lfV21+Q5mcrE4AHHt7m8RwCiifrXEBUb61iPqD7MtVu37q7kZgtrXJ x7VMU1hRQv05r1/Xx3Jnb4QiDHS+urBkxd0iauiz0iV0jCAH92AyztA+kns+YL6PNf2Z Zvh23ZdhdP5OJsNP+Su/PPA8V8xn07FtkEHCw= Received: by 10.216.165.136 with SMTP id e8mr2346650wel.60.1319027425069; Wed, 19 Oct 2011 05:30:25 -0700 (PDT) Received: from [10.161.31.135] ([89.204.137.135]) by mx.google.com with ESMTPS id e7sm9553225wbh.12.2011.10.19.05.30.23 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 05:30:24 -0700 (PDT) Message-ID: <4E9EC2DD.5030604@gmail.com> Date: Wed, 19 Oct 2011 14:30:21 +0200 From: Frank Ellermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [marf] Consensus on the multiple reports point X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:30:26 -0000 On 2011-10-19 01:22, Murray S. Kucherawy wrote: > Can I please get a reading of WG consensus on the issue > of sending multiple reports for a multiply-signed message? My somewhat uninformed € 0,01: Multi is more KISS, and I normally prefer KISS over "let's save some bandwidth". -Frank From msk@cloudmark.com Wed Oct 19 06:56:34 2011 Return-Path: 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 7B18D21F8B10 for ; Wed, 19 Oct 2011 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 yVbNsndNBQmW for ; Wed, 19 Oct 2011 06:56:33 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id B9A1D21F8AF3 for ; Wed, 19 Oct 2011 06:56:33 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 19 Oct 2011 06:56:33 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 19 Oct 2011 06:56:31 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyOT09hat46SqbTRxqfllNB8XYkIAAFoYJA Message-ID: References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> In-Reply-To: <4E9EAF6D.6020008@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 13:56:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, October 19, 2011 4:07 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Not formally. Section 3.4 of RFC 6376 specifies canonicalization with > no mention of l=3D. OTOH, Section 3.7 says >=20 > In hash step 1, the Signer/Verifier MUST hash the message body, > canonicalized using the body canonicalization algorithm specified in > the "c=3D" tag and /then/ truncated to the length specified in the "l=3D= " > tag. [emphasis added] >=20 > Does the definition of DKIM-Canonicalized-Body in Section 3.2.3 have > to specify that "the canonicalized body MAY be truncated to a length > greater or equal to the value of (the highest) l=3D"? I don't see how that emphasis is important. The canonicalized form is trun= cated by whatever "l=3D" says, if it's present. If two signatures use the = same canonicalization and have the same "l=3D" value (or absence thereof), = then the body canonicalization is the same. In any other case, they're dif= ferent. For the common factoring you're after to work, you'd need a way to= say "this canonicalized for applies to this set of signatures, but not the= others". That sounds like it could get horribly messy. > > Actually in the context of the report, I would trust the report's > > A-R and none of the quoted ones. I know for certain where it > > originated. And in that sense, the "authserv-id" doesn't really > > matter here. >=20 > I agree that it is sound to have the results of apposite checks in the > report's A-R. That really depends on how the report's A-R is going to > be specified. One possibility is to implement a meaning of "here's > why I'm sending this report". Such semantics would exclude, for > example, spf=3Dpass if the reported failure is a broken signature. > Indeed, that's not relevant for debugging, and for generic policy > tracking it might be as good to know as, say, Received: fields. >=20 > In any case, the contents of the report's A-R ought to be specified > and exemplified in the I-D, IMHO. Isn't it safe to assume any negative result in the A-R portion is the reaso= n for sending the report? For example, if you give me one in this context = that's "spf=3Dpass dkim=3Dfail", I'll know why you're sending it. Maybe you can craft an example that shows what ambiguity you're trying to r= esolve? From vesely@tana.it Wed Oct 19 11:25:02 2011 Return-Path: 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 33C8F1F0C6F for ; Wed, 19 Oct 2011 11:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.418 X-Spam-Level: X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=0.301, 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 NXASfQSgNJzf for ; Wed, 19 Oct 2011 11:25:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7231F0C49 for ; Wed, 19 Oct 2011 11:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319048700; bh=IrH+XjHBhlbp2UEo6oIs/d6Uu++1waSO1WOXvrauqno=; l=1318; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ftApW9OmffVmE7ZVxOUuu0sftU/r+78FiDz9BC2xSQpqsDZFpgtG+DTzpi8beW0ek v4Jw7y6qTCwY4DcY6XLuhgVwA3ENYWJiS8R7NTFDz7OVA+IVK2uplJ05biCKQp9fI+ 5sS/ZnKKXqSSSNX1QiNv837ris4s7DXecf2tOzlo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 19 Oct 2011 20:25:00 +0200 id 00000000005DC035.000000004E9F15FC.00001202 Message-ID: <4E9F15FB.6050905@tana.it> Date: Wed, 19 Oct 2011 20:24:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:25:02 -0000 On 19/Oct/11 15:56, Murray S. Kucherawy wrote: > > The canonicalized form is truncated by whatever "l=" says, if it's > present. If two signatures use the same canonicalization and have > the same "l=" value (or absence thereof), then the body > canonicalization is the same. In any other case, they're > different. For the common factoring you're after to work, you'd > need a way to say "this canonicalized for applies to this set of > signatures, but not the others". That sounds like it could get > horribly messy. DKIM-Canonicalized-Body is not required, but that is not the same as saying that the first part of it suffices. For example, if l=0 or the body is empty, the spec says it should be canonicalized to a CRLF. >> In any case, the contents of the report's A-R ought to be specified >> and exemplified in the I-D, IMHO. > > Isn't it safe to assume any negative result in the A-R portion is > the reason for sending the report? Sure, but "negative" ought to be defined, and it should be comparable with the ro= values defined by the relevant per-method specs (which may change between report generation and reception.) With multiple reports, can the Auth-Failure field help determining why a report was generated? It is important for people who need to fine tune their ro=. From msk@cloudmark.com Wed Oct 19 11:37:45 2011 Return-Path: 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 3FE0611E80B2 for ; Wed, 19 Oct 2011 11:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 S5wpTSi5nXbR for ; Wed, 19 Oct 2011 11:37:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id D0F9D11E808A for ; Wed, 19 Oct 2011 11:37:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 19 Oct 2011 11:37:44 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 19 Oct 2011 11:37:43 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyOjGy/u1/6aignTwGHA5oK2W1cXgAAHyMQ Message-ID: References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> In-Reply-To: <4E9F15FB.6050905@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:37:45 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, October 19, 2011 11:25 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > DKIM-Canonicalized-Body is not required, but that is not the same as > saying that the first part of it suffices. For example, if l=3D0 or the > body is empty, the spec says it should be canonicalized to a CRLF. If it's included, it has to be complete or it's not useful. If "l=3D0" or = the body is empty, DKIM-Canonicalized-Body (if included) must be the base64= encoding of a CRLF, because that's the canonicalized body in that instance= . Section 3.2.3 in the -03 draft talks about this. The content of that field is the canonicalized form of the body specified p= er the signature that's being reported. DKIM specifies how to do that; thi= s document doesn't have to, other than to require the base64 encoding of it= for transport. > Sure, but "negative" ought to be defined, and it should be comparable > with the ro=3D values defined by the relevant per-method specs (which > may change between report generation and reception.) I suppose that can't hurt. Something like this: 3.1: Authentication-Results: MUST appear exactly once. It MUST be formatted= according to [AUTH-RESULTS], and MUST reflect only a single authentication failure= . To report multiple failures for a single message, multiple reports MUST be gene= rated. We could also include a note that says "failure" doesn't include stuff like= temp-failures, but I don't think that's really necessary. > With multiple reports, can the Auth-Failure field help determining why > a report was generated? It is important for people who need to fine > tune their ro=3D. Indeed, Auth-Failure is the only way to know why the report was generated, = as far as I can tell. We can't reference the other drafts from this one as it'll be published fir= st, unless there's some reason that they all need to go out together. From vesely@tana.it Thu Oct 20 08:44:25 2011 Return-Path: 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 CA30C21F8AED for ; Thu, 20 Oct 2011 08:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.456 X-Spam-Level: X-Spam-Status: No, score=-4.456 tagged_above=-999 required=5 tests=[AWL=0.263, 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 LBSgpU3Lvlh1 for ; Thu, 20 Oct 2011 08:44:25 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0736321F889A for ; Thu, 20 Oct 2011 08:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319125463; bh=QPRBcy/IH+md68c/3jH67Tmmud6+QP9g0Cm/dgH+5Bk=; l=2543; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ffe910W+tboi47mPgtbjsMWGc9AFUePB85IvSjErZ1j9R9y8nGBVfWoEeNGYYjJ1V uoPyldaVwNn5SUqxzPMZyG8rY9qXUsgSWLjXD1cQ888V/9vAhnSZ+P5wfNOPstu58B OYHVW/ULVdReFzjqzKGdD5LcB3usfyCbTlOEV2TA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 20 Oct 2011 17:44:22 +0200 id 00000000005DC039.000000004EA041D6.00004010 Message-ID: <4EA041D6.3090409@tana.it> Date: Thu, 20 Oct 2011 17:44:22 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:44:25 -0000 On 19/Oct/11 20:37, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> DKIM-Canonicalized-Body is not required, but that is not the same as >> saying that the first part of it suffices. For example, if l=0 or the >> body is empty, the spec says it should be canonicalized to a CRLF. > > If it's included, it has to be complete or it's not useful. If > "l=0" or the body is empty, DKIM-Canonicalized-Body (if included) > must be the base64 encoding of a CRLF, because that's the > canonicalized body in that instance. All right, I think the amount of guesswork is minimal (e.g. what if l=1?) and the recipient should be prepared to "massage" the datum anyway, according to what format was saved on signing, for comparison. >> Sure, but "negative" ought to be defined, and it should be comparable >> with the ro= values defined by the relevant per-method specs (which >> may change between report generation and reception.) > > I suppose that can't hurt. Something like this: > > 3.1: > > Authentication-Results: MUST appear exactly once. It MUST be formatted according to > [AUTH-RESULTS], and MUST reflect only a single authentication failure. To report > multiple failures for a single message, multiple reports MUST be generated. > > We could also include a note that says "failure" doesn't include > stuff like temp-failures, but I don't think that's really > necessary. However, SPF reporting (sect 4.1) has the following for ro= e Reports are requested for messages that produced an SPF result of "TempError" or "PermError. >> With multiple reports, can the Auth-Failure field help determining why >> a report was generated? It is important for people who need to fine >> tune their ro=. > > Indeed, Auth-Failure is the only way to know why the report was > generated, as far as I can tell. Yes, if "Auth-Failure: spf" and "spf=temperror" in A-R, then the recipient knows it was ro= in their SPF record to trigger the report. Constraining A-R further would only make sense if we wanted to avoid multiple reports. > We can't reference the other drafts from this one as it'll be > published first, unless there's some reason that they all need to > go out together. There is also no reason why the drafts should be published independently, since defining further failure types, e.g. VBR, will need to redefine stuff in authfailure-report anyway. IMHO, we should feel free to reference the drafts from one another if that improves clarity. From msk@cloudmark.com Thu Oct 20 11:16:57 2011 Return-Path: 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 6A00921F8AF6 for ; Thu, 20 Oct 2011 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 Dv29hYVUl8XS for ; Thu, 20 Oct 2011 11:16:56 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id C3ADF21F8AF1 for ; Thu, 20 Oct 2011 11:16:56 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 20 Oct 2011 11:16:56 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 20 Oct 2011 11:16:55 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyPPyY/h02A7I8uTAaogMUR2tWr6QAFN8sA Message-ID: References: <20111012041112.66464.qmail@joyce.lan> <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> In-Reply-To: <4EA041D6.3090409@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:16:57 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, October 20, 2011 8:44 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf- > authfailure-report-03.txt >=20 > > If it's included, it has to be complete or it's not useful. If > > "l=3D0" or the body is empty, DKIM-Canonicalized-Body (if included) > > must be the base64 encoding of a CRLF, because that's the > > canonicalized body in that instance. >=20 > All right, I think the amount of guesswork is minimal (e.g. what if > l=3D1?) and the recipient should be prepared to "massage" the datum > anyway, according to what format was saved on signing, for comparison. So you're saying DKIM-Canonicalized-Body should always be the complete body= , and receivers of these reports should apply the truncation based on the "= l=3D" found in the third MIME part? That seems a little convoluted to me. > > We can't reference the other drafts from this one as it'll be > > published first, unless there's some reason that they all need to > > go out together. >=20 > There is also no reason why the drafts should be published > independently, since defining further failure types, e.g. VBR, will > need to redefine stuff in authfailure-report anyway. IMHO, we should > feel free to reference the drafts from one another if that improves > clarity. I disagree. This format is completely useful even if none of the reporting= extensions drafts ever get published. The opposite is not true. That was= one of the advantages of breaking the omnibus draft into these four or fiv= e smaller pieces. From vesely@tana.it Fri Oct 21 04:40:15 2011 Return-Path: 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 4381821F8B0E for ; Fri, 21 Oct 2011 04:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[AWL=0.234, 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 4-XzRj2+Kl5U for ; Fri, 21 Oct 2011 04:40:14 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6655221F84A4 for ; Fri, 21 Oct 2011 04:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319197212; bh=tRmh2/20rH3ThRgbV7MmarUXRgxV4Q6bhwrANQJnosY=; l=1698; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=b7+iBmEY4rU75m2ttcwHZCDoiXhUuNiI9I8fXDzskQKc2waSlZXnmUk3DwqLGxn/4 Er1rfT6SUG3DkKPAWL5KTzANU00PgYNAsrkl7kr/KnorB16Z0Q2gHRizTN2bbXir8O ECCEGG742DxzY0skOCG6ThNZaZqih61N+z4R8kdE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 21 Oct 2011 13:40:12 +0200 id 00000000005DC049.000000004EA15A1C.00007563 Message-ID: <4EA15A1B.5060509@tana.it> Date: Fri, 21 Oct 2011 13:40:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:40:15 -0000 On 20/Oct/11 20:16, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> All right, I think the amount of guesswork is minimal (e.g. what if >> l=1?) and the recipient should be prepared to "massage" the datum >> anyway, according to what format was saved on signing, for comparison. > > So you're saying DKIM-Canonicalized-Body should always be the > complete body, and receivers of these reports should apply the > truncation based on the "l=" found in the third MIME part? That > seems a little convoluted to me. However convoluted it may seem, that's the formal definition that DKIM gives of the body canonicalization algorithms. Of course, both signers and verifiers know it is useless to canonicalize parts of the body that don't contribute to the hash. By skipping useless parts, they obtain the same result "as if" they had carried out a full body canonicalization and then truncation. Report generators are in a different position, because what used to be an intermediate result is now visible. Pedantic programmers may conclude that they need to send the whole body by reasoning as I did above (uh... does that mean I'm pedantic?) You yourself adapted to write CRLF for an empty body, l=0 notwithstanding. What I'm saying is that if we want it to be clear and indisputable that DKIM-Canonicalized-Body may/must be limited to the amount of text that contributes to the hash, we have to say so. > This format is completely useful even if none of the reporting > extensions drafts ever get published. The opposite is not true. Admitted. That may be an advantage, even though it comes at the expenses of method-orientation. From hfontana@ecertsystems.com Fri Oct 21 08:10:35 2011 Return-Path: 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 AE8FE1F0C5A for ; Fri, 21 Oct 2011 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 UYtT9qJtoVlV for ; Fri, 21 Oct 2011 08:10:09 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD201F0C53 for ; Fri, 21 Oct 2011 08:10:09 -0700 (PDT) Received: by qyk34 with SMTP id 34so605333qyk.10 for ; Fri, 21 Oct 2011 08:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:disposition-notification-to; bh=vYopzzVUDa4oxnNyVSaTpQ4FKVjJ91JJbbQIgEX/0/M=; b=gOzW51IJ74WVJRQsriQTsA1CHXRzax9MY24PZ/xlnYZr0tJgs5LP6/bA44GuC/Dujv 0emyYd3jT5Nhu/M/V1Uf7Arpsk7N0/8jhVKc9uWGIYPjIKnFujYbwBM8T7BDEhLfD5eD sbFVQ9tp0kivc2HUSDw+Yj6xbfEHIScv8ch0g= Received: by 10.68.13.135 with SMTP id h7mr28499917pbc.75.1319209805127; Fri, 21 Oct 2011 08:10:05 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id y4sm31404990pbe.4.2011.10.21.08.10.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Oct 2011 08:10:03 -0700 (PDT) From: "Hilda Fontana" To: "'Alessandro Vesely'" , References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> In-Reply-To: <4EA15A1B.5060509@tana.it> Date: Fri, 21 Oct 2011 08:09:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqEU4Co18J0tgb2xFivY7Ts64RGAJZeACMAp0RpqcCTi19OQEoTz9sAmEpd7kDPLK6lgGvkUc2AZY6ckAC3L+TqQEP2XceAY0HRmgCkXWEKAGoyrDqAiGXUYwBpoVBjAM4y4Fdkzu1N2A= Content-Language: en-us Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:10:35 -0000 All, I'd really like to get a final consensus of the changes for the next draft. So far I have the minor changes, including the updates needed to the example. Is it fair to say we have consensus on the one report per failure? What is the final verdict on the DKIM-Canonicalized-Body? How should it be phrased in the doc? Thanks H > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Friday, October 21, 2011 4:40 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure- > report-03.txt > > On 20/Oct/11 20:16, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > >> > >> All right, I think the amount of guesswork is minimal (e.g. what if > >> l=1?) and the recipient should be prepared to "massage" the datum > >> anyway, according to what format was saved on signing, for comparison. > > > > So you're saying DKIM-Canonicalized-Body should always be the complete > > body, and receivers of these reports should apply the truncation based > > on the "l=" found in the third MIME part? That seems a little > > convoluted to me. > > However convoluted it may seem, that's the formal definition that DKIM > gives of the body canonicalization algorithms. Of course, both signers and > verifiers know it is useless to canonicalize parts of the body that don't > contribute to the hash. By skipping useless parts, they obtain the same > result "as if" they had carried out a full body canonicalization and then > truncation. > > Report generators are in a different position, because what used to be an > intermediate result is now visible. Pedantic programmers may conclude that > they need to send the whole body by reasoning as I did above (uh... does > that mean I'm pedantic?) You yourself adapted to write CRLF for an empty > body, l=0 notwithstanding. > > What I'm saying is that if we want it to be clear and indisputable that DKIM- > Canonicalized-Body may/must be limited to the amount of text that > contributes to the hash, we have to say so. > > > This format is completely useful even if none of the reporting > > extensions drafts ever get published. The opposite is not true. > > Admitted. That may be an advantage, even though it comes at the expenses > of method-orientation. > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Fri Oct 21 12:30:56 2011 Return-Path: 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 7834221F8B49 for ; Fri, 21 Oct 2011 12:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 BlweqM8OZftK for ; Fri, 21 Oct 2011 12:30:56 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id F2BDD21F8B3F for ; Fri, 21 Oct 2011 12:30:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 21 Oct 2011 12:30:55 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 21 Oct 2011 12:30:54 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyP5jcnMb2QqyJgSl6DGGz6Zm8vYgAQCnjg Message-ID: References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> In-Reply-To: <4EA15A1B.5060509@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:30:56 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, October 21, 2011 4:40 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > On 20/Oct/11 20:16, Murray S. Kucherawy wrote: > > So you're saying DKIM-Canonicalized-Body should always be the > > complete body, and receivers of these reports should apply the > > truncation based on the "l=3D" found in the third MIME part? That > > seems a little convoluted to me. >=20 > However convoluted it may seem, that's the formal definition that DKIM > gives of the body canonicalization algorithms. Of course, both > signers and verifiers know it is useless to canonicalize parts of the > body that don't contribute to the hash. By skipping useless parts, > they obtain the same result "as if" they had carried out a full body > canonicalization and then truncation. I agree that you can do it either way; the hash is the same through either = method. However, determining the "l=3D" (truncation point) for hash comput= ation by diving into the third MIME part of the report is probably not a go= od design. To mitigate this, we either specify that DKIM-Canonicalized-Bod= y is truncated per "l=3D", or we have to add a DKIM-Canonicalized-Length fi= eld to tell the report recipient where to truncate the canonicalized body w= hen using the result (or both, though that's redundant). I'd be fine with = either. > Report generators are in a different position, because what used to be > an intermediate result is now visible. Pedantic programmers may > conclude that they need to send the whole body by reasoning as I did > above (uh... does that mean I'm pedantic?) You yourself adapted to > write CRLF for an empty body, l=3D0 notwithstanding. The implementation I have holds the canonicalized header and body in their = entirety, but the latter is truncated per "l=3D" if present. It handles "l= =3D0" and the empty body per the RFC. > What I'm saying is that if we want it to be clear and indisputable > that DKIM-Canonicalized-Body may/must be limited to the amount of text > that contributes to the hash, we have to say so. I'm fine with that; I think it's simpler, and it's extremely convenient for= my implementation. :-) So I suggest the DKIM-Canonicalized-Body description be amended like so: DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body of the message as generated by the verifier. The encoded content MUST be limited to those bytes that contribute to the DKIM body hash (i.e., the value of the "l=3D" tag; see Section 3.7 of [DKIM]). Does that work for you? -MSK From msk@cloudmark.com Fri Oct 21 12:32:54 2011 Return-Path: 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 1555821F8B6D for ; Fri, 21 Oct 2011 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 LTMWNPMWEO9W for ; Fri, 21 Oct 2011 12:32:53 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B715621F8B49 for ; Fri, 21 Oct 2011 12:32:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 21 Oct 2011 12:32:53 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 21 Oct 2011 12:32:52 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AQJqEU4Co18J0tgb2xFivY7Ts64RGAJZeACMAp0RpqcCTi19OQEoTz9sAmEpd7kDPLK6lgGvkUc2AZY6ckAC3L+TqQEP2XceAY0HRmgCkXWEKAGoyrDqAiGXUYwBpoVBjAM4y4Fdkzu1N2CAAExywA== Message-ID: References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> In-Reply-To: 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:32:54 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of H= ilda Fontana > Sent: Friday, October 21, 2011 8:10 AM > To: 'Alessandro Vesely'; marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Is it fair to say we have consensus on the one report per failure? I believe there's rough consensus supporting one report per failure. > What is the final verdict on the DKIM-Canonicalized-Body? How should it = be > phrased in the doc? I just proposed a replacement description. If there are no objections, we = can run with it. I'll start a second WGLC on your -04 when I see it, but please wait a few d= ays in case anyone else wants to chime in on either issue. -MSK From vesely@tana.it Sat Oct 22 04:52:39 2011 Return-Path: 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 BCBF121F8AFE for ; Sat, 22 Oct 2011 04:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.508 X-Spam-Level: X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[AWL=0.211, 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 5y9KubKUIg2o for ; Sat, 22 Oct 2011 04:52:39 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3021F8AAF for ; Sat, 22 Oct 2011 04:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319284357; bh=Qg9TRB3o9GUTTHgC7cDYJ5/+hRT2DZQnQcguzWEcjRs=; l=1710; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Clh9Bj1UO3iU8ESGDos4VO+oX6OSRtNOGw4prk8SCaV393XvG93UEFo+zreQc6B3Q 7PpR5lXV5I52bH4QesjVKU3Ib9W8nqH62CAe2V1We5DiXHc9rRz4x8cQxjSJLcO2cT fpJRPkYXic32LHB1AHn0xt+I1bYUbU2KmkuKSAD8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 22 Oct 2011 13:52:37 +0200 id 00000000005DC033.000000004EA2AE85.00003BA1 Message-ID: <4EA2AE84.9000400@tana.it> Date: Sat, 22 Oct 2011 13:52:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 11:52:39 -0000 On 21/Oct/11 17:09, Hilda Fontana wrote: > > I'd really like to get a final consensus of the changes for the next draft. > So far I have the minor changes, including the updates needed to the > example. Is it ok for the example to start at the first column? Usually lines start with three spaces... > Is it fair to say we have consensus on the one report per failure? There are different cases, e.g: *straight case* The sending domain signs twice, e.g. to experiment different parameters, but it uses the same selector. Hence the r= address is the same for both failures. If both signatures fail, the report generator can tell how many messages it is going to send. *possibly unrelated* The sending domain defines SPF, DKIM, and ADSP. If some of them fail, the report generator would have to compare the relevant email addresses in order to tell if reports are destined to the same operator. *modular case* The receiving domain performs multiple checks, but they are all handled by different software modules, and thus result in multiple A-R fields. Possibly, generators should be configured to send reports to an internal mailbox where they are reassembled, modified, or counted. Such report-tweaking internal mailbox can also be used for setting fields like Delivery-Result. For example, the MX server that carries out the checks can be configured to send the reports to the MDA that decides about delivery; the MDA then forwards the report to the final destination, which is still written in the included DNS records. > What is the final verdict on the DKIM-Canonicalized-Body? How should it be > phrased in the doc? I'm happy with the text Murray proposed. From msk@cloudmark.com Sat Oct 22 08:27:53 2011 Return-Path: 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 5FD9C21F8669 for ; Sat, 22 Oct 2011 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JYeVTn1PuEfT for ; Sat, 22 Oct 2011 08:27:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id F36BE21F85C7 for ; Sat, 22 Oct 2011 08:27:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 22 Oct 2011 08:27:51 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 22 Oct 2011 08:27:50 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyQsR42xM3Q0GDpSfCVBB+eHwB/kQAHe9LQ Message-ID: References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> <4EA2AE84.9000400@tana.it> In-Reply-To: <4EA2AE84.9000400@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 15:27:53 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, October 22, 2011 4:53 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > Is it ok for the example to start at the first column? Usually lines > start with three spaces... Yes, the examples should be indented slightly inside the
and tags. > > Is it fair to say we have consensus on the one report per failure? >=20 > There are different cases, e.g: > [...] I'm not really sure what you're going after here. Do you have specific tex= t changes you want to propose? From vesely@tana.it Sat Oct 22 10:57:47 2011 Return-Path: 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 132A021F8551 for ; Sat, 22 Oct 2011 10:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_12=0.6, 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 zTOkFSPXMaUO for ; Sat, 22 Oct 2011 10:57:46 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E23EE21F84DF for ; Sat, 22 Oct 2011 10:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319306264; bh=LuuD4OhRbWT4JGht6lZ907FHm068EGcOVaWDRbPJ6LI=; l=1219; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GyTk+lXPkA9e6xgQTFkjn2ErCNS42zjMs1M7UWx9Zc+mmg5LV+mdv8atc5+WZgC/n qqzgaHqrkVVutqvONQ9QpPQND5HWwcLaXEdxtQn7F7YsdNGhul0sH8RSsj/xKYOr29 toLMZeYFjFQB1fBX5kV7a//J+6CT5S7OVHDVuf+s= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 22 Oct 2011 19:57:44 +0200 id 00000000005DC039.000000004EA30418.00006942 Message-ID: <4EA30417.1060601@tana.it> Date: Sat, 22 Oct 2011 19:57:43 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> <4EA2AE84.9000400@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 17:57:47 -0000 On 22/Oct/11 17:27, Murray S. Kucherawy wrote: > >>> Is it fair to say we have consensus on the one report per failure? >> >> There are different cases, e.g: >> [...] > > I'm not really sure what you're going after here. Do you have > specific text changes you want to propose? I don't. We only discussed reporting multiple broken signatures, and apparently concluded that it is too much of a complication for a case that ordinarily does not happen. (Some domains sometimes sign twice; you may want to run something like this to find out: SELECT d.name, s1.domain, count(*) FROM signatures AS s1, signatures AS s2, domains AS d WHERE s1.message = s2.message AND s1.domain = s2.domain AND s1.id != s2.id AND d.id = s1.domain GROUP BY s1.domain; ) However, having two separate reports for a DKIM failure and the consequent ADSP failure, provided the r='s match, looks overly verbose. What do we want to do in such cases? In addition, forwarding from a central host may be a technique worth being mentioned, although it's quite expensive compared to syslog. It may be used for vetting and internal auditing, besides updating delivery-results, reckoning ri=, and the like. Worth? From msk@cloudmark.com Sat Oct 22 16:00:07 2011 Return-Path: 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 00D3F21F8713 for ; Sat, 22 Oct 2011 16:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1, 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 HM1euEiW3ZX8 for ; Sat, 22 Oct 2011 16:00:06 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0C21F86EC for ; Sat, 22 Oct 2011 16:00:06 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 22 Oct 2011 14:43:40 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 22 Oct 2011 14:43:39 -0700 Thread-Topic: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcyQ5B/3BXvIJMEyRmmuxilXrUSmewAHwvgg Message-ID: References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> <4EA2AE84.9000400@tana.it> <4EA30417.1060601@tana.it> In-Reply-To: <4EA30417.1060601@tana.it> 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] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 23:00:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, October 22, 2011 10:58 AM > To: marf@ietf.org > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailur= e-report-03.txt >=20 > I don't. We only discussed reporting multiple broken signatures, and > apparently concluded that it is too much of a complication for a case > that ordinarily does not happen. (Some domains sometimes sign twice; > you may want to run something like this to find out: >=20 > SELECT d.name, s1.domain, count(*) > FROM signatures AS s1, signatures AS s2, domains AS d > WHERE s1.message =3D s2.message > AND s1.domain =3D s2.domain > AND s1.id !=3D s2.id > AND d.id =3D s1.domain > GROUP BY s1.domain; > ) I have no doubt that there are some domains that sign twice, either on purp= ose or accidentally. The DKIM RFC even contains allusions to the practice.= But I don't see how that leads to changes to the text we have now. > However, having two separate reports for a DKIM failure and the > consequent ADSP failure, provided the r=3D's match, looks overly > verbose. What do we want to do in such cases? Send three reports. Consensus appears to be that this is easier than comin= g up with some crazy syntax to try to keep it all contained in one report, = especially when these are meant to be machine-processed and not handled by = humans; it's not much of a burden. > In addition, forwarding from a central host may be a technique worth > being mentioned, although it's quite expensive compared to syslog. It > may be used for vetting and internal auditing, besides updating > delivery-results, reckoning ri=3D, and the like. Worth? We haven't prevented that kind of design with the text that's there now, so= I don't think any changes are needed there either. It would be an odd thi= ng to do, but the current text doesn't block it. I think we're ready for another WGLC, unless you have other cases you'd lik= e to explore. -MSK From vesely@tana.it Sun Oct 23 07:27:50 2011 Return-Path: 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 1F5F121F8A97 for ; Sun, 23 Oct 2011 07:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=0.201, 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 bvTAmLOIDFak for ; Sun, 23 Oct 2011 07:27:49 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7D21F899D for ; Sun, 23 Oct 2011 07:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1319380067; bh=br8UAJJlteFiEurdlvVYcj6XfbIsYsy64dAnndTVlCU=; l=1825; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=UbswwQLspyEhqUGCCckL+q7HS4y0qLHT8uYUFJA6apxLwjd3aFIzm9FeIQzPu6kpq VKCd1MHYmojBTQ+w5CcHCZz+clOQbR5LXidZn8ER8Iv83c6lnlW5QmoIUNzR+ANZRI X9wdc6lhviHVLixH44fPQkRGToOEH1HxBwbQkfxw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 23 Oct 2011 16:27:47 +0200 id 00000000005DC03F.000000004EA42463.00001F3E Message-ID: <4EA42462.2050301@tana.it> Date: Sun, 23 Oct 2011 16:27:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4E998087.3070705@tana.it> <4E9AE35A.2040406@tana.it> <4E9EAF6D.6020008@tana.it> <4E9F15FB.6050905@tana.it> <4EA041D6.3090409@tana.it> <4EA15A1B.5060509@tana.it> <4EA2AE84.9000400@tana.it> <4EA30417.1060601@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 14:27:50 -0000 On 22/Oct/11 23:43, Murray S. Kucherawy wrote: > > Send three reports. Consensus appears to be that this is easier > than coming up with some crazy syntax to try to keep it all > contained in one report, especially when these are meant to be > machine-processed and not handled by humans; it's not much of a > burden. Agreed, even though some cases don't need a different syntax. >> In addition, forwarding from a central host may be a technique worth >> being mentioned, although it's quite expensive compared to syslog. It >> may be used for vetting and internal auditing, besides updating >> delivery-results, reckoning ri=, and the like. Worth? > > We haven't prevented that kind of design with the text that's there > now, so I don't think any changes are needed there either. It > would be an odd thing to do, but the current text doesn't block > it. Perhaps it looks odd because I conflated a number of things. Let's postpone delivery-results, reassembling, and ri=. Would it be helpful to have some text like the following appended to Section 7.3? Alternatively, report generators can accept a configuration parameter that instructs them to generate reports only in certain cases and/or to send them to a mailbox different than the one discovered in the DNS. The latter is supposedly an internal mailbox whose operator, either human or automatic, can examine what data is being sent to whom before allowing or denying the report to proceed. The destination address discovered in the DNS is still available in the relevant header field saved in the second MIME part of the report, thus forwarding-after-vetting can be automatically assisted. > I think we're ready for another WGLC, unless you have other cases > you'd like to explore. I'm looking forward to -04. From sklist@kitterman.com Mon Oct 24 07:53:23 2011 Return-Path: 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 D1AC521F8E3E for ; Mon, 24 Oct 2011 07:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 259Ic+jHDYMu for ; Mon, 24 Oct 2011 07:53:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB921F8E39 for ; Mon, 24 Oct 2011 07:53:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1C15120E4128; Mon, 24 Oct 2011 10:53:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1319467995; bh=z4RA6O33oSrYEK6R4GqThEV1PIbQecw3645nYPm8WyA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pv/tFkAx9gCrG9jFmKWEtAg2kgr9lXRgvHNtrMt96m05IAAa1P/4uGWc8K7siw7mH w/zditkiUJuGVMjsdx1apVxAXhZnNIC9momRyXghSseo9dlHkPqKjCtzckG0/fg7gj puqs+S2l4CvLPCfxIpElapMMd/S7s+CVL3ppN2j4= Received: from [192.168.111.113] (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 E91C120E4084; Mon, 24 Oct 2011 10:53:14 -0400 (EDT) Message-ID: <4EA57BDA.90505@kitterman.com> Date: Mon, 24 Oct 2011 10:53:14 -0400 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111009064309.9490.13212.idtracker@ietfa.amsl.com> In-Reply-To: <20111009064309.9490.13212.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:53:23 -0000 On 10/09/2011 02:43 AM, internet-drafts@ietf.org wrote: > 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 : Authentication Failure Reporting using the Abuse Report Format > Author(s) : Hilda L. Fontana > Filename : draft-ietf-marf-authfailure-report-03.txt > Pages : 20 > Date : 2011-10-08 ... I think this is much better, but still a few nits: para 2.2 (I think) also needs to list FWS as an imported definition. It is listed in 3.2 as imported from DKIM. para 3.2.3: I think for DKIM-Canonicalized-Header and DKIM-Canonicalized-Body, instead of saying they can't include redacted data, it should to be "SHOULD be included unless inclusion would involved redacted data in which case they MUST NOT be included." I don't think these fields make sense under any circumstances once they have been redacted. para 3.2.5: I think this needs rewording. Current: > SPF-DNS MUST appear once for every query to an SPF record that was > done, to enable the reporting of included fields and where they came > from. The ABNF in Section 4 changes; see below. proposed: > SPF-DNS MUST appear once for every SPF record used to obtain the SPF result. I'm not sure that's clear, but I think it a step in the right direction. para 8.1: The reference to [MAIL] to use RFC 2822 should be updated to 5322. Scott K From internet-drafts@ietf.org Mon Oct 24 08:29:30 2011 Return-Path: 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 94F4021F8D6E; Mon, 24 Oct 2011 08:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Gy3YvNlmJdWA; Mon, 24 Oct 2011 08:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DED21F8D13; Mon, 24 Oct 2011 08:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024152930.21341.87942.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 08:29:30 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:29:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : SPF Authentication Failure Reporting using the Abuse Rep= ort Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-02.txt Pages : 14 Date : 2011-10-24 This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-02.txt From sklist@kitterman.com Mon Oct 24 08:35:31 2011 Return-Path: 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 2AE9E21F8DC4 for ; Mon, 24 Oct 2011 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GUgIzRe+g0Wz for ; Mon, 24 Oct 2011 08:35:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 45EBD21F8DC5 for ; Mon, 24 Oct 2011 08:35:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BF1F820E4128; Mon, 24 Oct 2011 11:35:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1319470529; bh=16OQU1TuFpDTDDTZwInJRtv9B5VOV0LUAKBM2bQii8E=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ieKZq3fV5tCwakMyVwjLjDJgBAHMKDMn9gtcjYMA4kt2s2piHSY8yP6/yTt8Dz2sI /qK8qXhH/4uUnoRJMGCIkbF1RJZLxTOz2ziaNEDa2UoLGzu5vN0PB3t0uJxYZKrSXg c2hQgxTxOtnXnXAZqQq6mrUZ+jc8umyBdvYCQKo8= Received: from [192.168.111.113] (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 9ECC620E4084; Mon, 24 Oct 2011 11:35:29 -0400 (EDT) Message-ID: <4EA585C0.4060009@kitterman.com> Date: Mon, 24 Oct 2011 11:35:28 -0400 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111024152930.21341.87942.idtracker@ietfa.amsl.com> In-Reply-To: <20111024152930.21341.87942.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 15:35:31 -0000 On 10/24/2011 11:29 AM, internet-drafts@ietf.org wrote: > 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 : SPF Authentication Failure Reporting using the > Abuse Report Format Author(s) : Scott Kitterman Filename > : draft-ietf-marf-spf-reporting-02.txt Pages : 14 Date > : 2011-10-24 After I posted the -01 draft I had a few comments, but I decided to wait on addressing them until I felt like draft-ietf-marf-authfailure-report was reasonably stable in case functionality moved from that draft into this one. I feel like we're there now. I think that the draft I just posted addresses the open comments, including (most critically) spelling Murray's correctly. Scott K From internet-drafts@ietf.org Mon Oct 24 11:16:32 2011 Return-Path: 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 9E5DC21F8C44; Mon, 24 Oct 2011 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 JoGA0seMPa3Z; Mon, 24 Oct 2011 11:16:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2A221F8BF0; Mon, 24 Oct 2011 11:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111024181631.20960.36801.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2011 11:16:31 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:16:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-04.txt Pages : 20 Date : 2011-10-24 This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-04.txt From msk@cloudmark.com Tue Oct 25 03:05:16 2011 Return-Path: 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 7A23621F8B50 for ; Tue, 25 Oct 2011 03:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 lC5PHVBAabMx for ; Tue, 25 Oct 2011 03:05:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id D083F21F8B4B for ; Tue, 25 Oct 2011 03:05:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 25 Oct 2011 03:05:11 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 25 Oct 2011 03:05:10 -0700 Thread-Topic: I-D Action: draft-ietf-marf-authfailure-report-04.txt Thread-Index: AcySeRYmuYsgQHotSCCK4GeErtKuWQAhAaAw Message-ID: References: <20111024181631.20960.36801.idtracker@ietfa.amsl.com> In-Reply-To: <20111024181631.20960.36801.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-authfailure-report-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:05:16 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Monday, October 24, 2011 11:17 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-authfailure-report-04.txt >=20 > 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. >=20 > Title : Authentication Failure Reporting using the Abuse Repor= t Format > Author(s) : Hilda L. Fontana > Filename : draft-ietf-marf-authfailure-report-04.txt > Pages : 20 > Date : 2011-10-24 >=20 > This memo registers an extension report type to ARF for use in > reporting messages that fail one or more authentication checks > performed on receipt of a message, with the option to include > forensic information describing the specifics of the failure. I know there's already some feedback on this version, but it's pretty minor= (so far). So I'd like to call this the beginning of a second Working Grou= p Last Call on this draft, ending Friday, November 11th. So please, another round of reviews and feedback, with an eye toward gettin= g this ready for sending it to the IESG. -MSK, as co-chair From msk@cloudmark.com Tue Oct 25 03:09:14 2011 Return-Path: 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 68B1521F8C4F for ; Tue, 25 Oct 2011 03:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 DgmBjRxiNeei for ; Tue, 25 Oct 2011 03:09:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E6E2D21F8C49 for ; Tue, 25 Oct 2011 03:09:13 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 25 Oct 2011 03:09:13 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 25 Oct 2011 03:09:12 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-03.txt Thread-Index: AcySXK/DGUgzXbukQT+JFsxBl9C5VQAoOsNQ Message-ID: References: <20111009064309.9490.13212.idtracker@ietfa.amsl.com> <4EA57BDA.90505@kitterman.com> In-Reply-To: <4EA57BDA.90505@kitterman.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-authfailure-report-03.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:09:14 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Monday, October 24, 2011 7:53 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-03.txt >=20 > On 10/09/2011 02:43 AM, internet-drafts@ietf.org wrote: > > 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 : Authentication Failure Reporting using the Abuse Rep= ort Format > > Author(s) : Hilda L. Fontana > > Filename : draft-ietf-marf-authfailure-report-03.txt Just for the sake of being pedantic, -04 is current. > ... >=20 > I think this is much better, but still a few nits: >=20 > para 2.2 (I think) also needs to list FWS as an imported definition. It > is listed in 3.2 as imported from DKIM. I agree; moving this to 2.2 is neater. Good catch. > para 3.2.3: I think for DKIM-Canonicalized-Header and > DKIM-Canonicalized-Body, instead of saying they can't include redacted > data, it should to be "SHOULD be included unless inclusion would > involved redacted data in which case they MUST NOT be included." I > don't think these fields make sense under any circumstances once they > have been redacted. That makes sense. Also, this paragraph is incorrectly indented. Looks lik= e it needs to be moved outside the element. > para 3.2.5: I think this needs rewording. Current: >=20 > > SPF-DNS MUST appear once for every query to an SPF record that was > > done, to enable the reporting of included fields and where they came > > from. The ABNF in Section 4 changes; see below. >=20 > proposed: >=20 > > SPF-DNS MUST appear once for every SPF record used to obtain the SPF= result. Looks like this one got included in -04. > para 8.1: The reference to [MAIL] to use RFC 2822 should be updated to > 5322. Ditto. From barryleiba.mailing.lists@gmail.com Tue Oct 25 05:04:29 2011 Return-Path: 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 68D9321F8A66 for ; Tue, 25 Oct 2011 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 csCNzLh5bhQQ for ; Tue, 25 Oct 2011 05:04:29 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD90F21F8672 for ; Tue, 25 Oct 2011 05:04:28 -0700 (PDT) Received: by gyh20 with SMTP id 20so498729gyh.31 for ; Tue, 25 Oct 2011 05:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=WwJsnLmPSA6mP9KDqAPUmgW6VrQBZ/e0o36mrhb8OcU=; b=Cw13jxkJ1w7ibe30nVCm/ONqnuxjQ+JLdUFWy6O0SDwJq5jrKZ8wYfRGP78iYyHP43 F8dWedeGGL8poIAIhkqspH1vIbo+aw6Rb/EeCgtAcTb+8T6gIAslE0A90EqNQdMxQUYU 3zMx6fdnHc8G8modL1ODpzvF5vXQ2UX8PVyEQ= MIME-Version: 1.0 Received: by 10.236.181.34 with SMTP id k22mr21754385yhm.42.1319544268471; Tue, 25 Oct 2011 05:04:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.250.14 with HTTP; Tue, 25 Oct 2011 05:04:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 08:04:28 -0400 X-Google-Sender-Auth: eE07_PIF5SIAcihzg6QLmFlhY_o Message-ID: From: Barry Leiba To: "marf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Consensus on the multiple reports point X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 12:04:29 -0000 > Can I please get a reading of WG consensus on the issue of sending multiple > reports for a multiply-signed message? A little late, here (sorry), but: I also favour multiple reports. I think it's more important to keep things simple and not to overload/pollute the protocols, and that any grumbling from operators about generating or processing multiple reports has to be minor. Unless someone can make a real case that many operators will simply not participate if we use multiple reports, that clearly wins. Barry, as participant From internet-drafts@ietf.org Tue Oct 25 16:28:47 2011 Return-Path: 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 07B8A1F0C90; Tue, 25 Oct 2011 16:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 wwV+mW6uVbTL; Tue, 25 Oct 2011 16:28:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921BC1F0C8A; Tue, 25 Oct 2011 16:28:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025232846.25593.75588.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 16:28:46 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:28:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Redaction of Potentially Sensitive Data from Mail Abuse = Reports Author(s) : J.D. Falk Filename : draft-ietf-marf-redaction-01.txt Pages : 5 Date : 2011-10-25 Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-redaction-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-redaction-01.txt From jdfalk-lists@cybernothing.org Tue Oct 25 16:36:37 2011 Return-Path: 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 15AA611E80F8 for ; Tue, 25 Oct 2011 16:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 P6niiRp44BfV for ; Tue, 25 Oct 2011 16:36:36 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7646E11E8095 for ; Tue, 25 Oct 2011 16:36:36 -0700 (PDT) Received: from [192.168.11.38] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9PNaXj2018849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 16:36:35 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20111025232846.25593.37383.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 16:36:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111025232846.25593.37383.idtracker@ietfa.amsl.com> To: ARF mailing list X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] New Version Notification for draft-ietf-marf-redaction-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 23:36:37 -0000 On Oct 25, 2011, at 4:28 PM, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-marf-redaction-01.txt has been = successfully submitted by J.D. Falk and posted to the IETF repository. This is identical to -00, which expired a week or so ago (oops.) It seems like most of the objections/concerns regarding this draft have = focused on section 2, the Recommended Practice. I'm not in a position = to effectively defend that section; like the rest of the draft, it was = copied from draft-ietf-marf-dkim-reporting when that document was split. I'd hoped that other Recommended Practices might be added to the draft, = but none have been offered thus far. So...should we remove section 2 entirely? If the consensus is to keep = it, perhaps someone more familiar with that specific method could take = over authorship of the draft. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Wed Oct 26 00:44:03 2011 Return-Path: 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 271A221F8B07 for ; Wed, 26 Oct 2011 00:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 J6KnX+H3Nl8d for ; Wed, 26 Oct 2011 00:44:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B28F821F8B06 for ; Wed, 26 Oct 2011 00:43:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 00:43:59 -0700 From: "Murray S. Kucherawy" To: ARF mailing list Date: Wed, 26 Oct 2011 00:43:59 -0700 Thread-Topic: [marf] New Version Notification for draft-ietf-marf-redaction-01.txt Thread-Index: AcyTbvRJdN58lELsSdOo5HQOvhGA8QAQ/peg Message-ID: References: <20111025232846.25593.37383.idtracker@ietfa.amsl.com> In-Reply-To: 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] New Version Notification for draft-ietf-marf-redaction-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 07:44:03 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Tuesday, October 25, 2011 4:37 PM > To: ARF mailing list > Subject: Re: [marf] New Version Notification for draft-ietf-marf-redactio= n-01.txt >=20 > It seems like most of the objections/concerns regarding this draft have > focused on section 2, the Recommended Practice. I'm not in a position > to effectively defend that section; like the rest of the draft, it was > copied from draft-ietf-marf-dkim-reporting when that document was > split. >=20 > I'd hoped that other Recommended Practices might be added to the draft, > but none have been offered thus far. >=20 > So...should we remove section 2 entirely? If the consensus is to keep > it, perhaps someone more familiar with that specific method could take > over authorship of the draft. I must've missed it. What are the arguments with what Section 2 says, and/= or what other alternatives have been proposed? From jdfalk-lists@cybernothing.org Wed Oct 26 14:21:07 2011 Return-Path: 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 0925421F841B for ; Wed, 26 Oct 2011 14:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 CIwTDsjIM0Lo for ; Wed, 26 Oct 2011 14:21:06 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7251121F8A57 for ; Wed, 26 Oct 2011 14:21:06 -0700 (PDT) Received: from [192.168.11.46] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9QLL2k9031794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 14:21:04 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Wed, 26 Oct 2011 14:21:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C4C01AB-E2CA-4D40-9166-3285D6DA2A6A@cybernothing.org> References: <20111025232846.25593.37383.idtracker@ietfa.amsl.com> To: ARF mailing list X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] New Version Notification for draft-ietf-marf-redaction-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:21:07 -0000 On Oct 26, 2011, at 12:43 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of J.D. Falk >> Sent: Tuesday, October 25, 2011 4:37 PM >> To: ARF mailing list >> Subject: Re: [marf] New Version Notification for = draft-ietf-marf-redaction-01.txt >>=20 >> It seems like most of the objections/concerns regarding this draft = have >> focused on section 2, the Recommended Practice. I'm not in a = position >> to effectively defend that section; like the rest of the draft, it = was >> copied from draft-ietf-marf-dkim-reporting when that document was >> split. >>=20 >> I'd hoped that other Recommended Practices might be added to the = draft, >> but none have been offered thus far. >>=20 >> So...should we remove section 2 entirely? If the consensus is to = keep >> it, perhaps someone more familiar with that specific method could = take >> over authorship of the draft. >=20 > I must've missed it. What are the arguments with what Section 2 says, = and/or what other alternatives have been proposed? https://www.ietf.org/mail-archive/web/marf/current/msg01266.html https://www.ietf.org/mail-archive/web/marf/current/msg01048.html https://www.ietf.org/mail-archive/web/marf/current/msg01047.html https://www.ietf.org/mail-archive/web/marf/current/msg01042.html I could swear there was more, but can't find it in the archives now. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Sat Oct 29 23:42:27 2011 Return-Path: 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 669E01F0C36 for ; Sat, 29 Oct 2011 23:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.26 X-Spam-Level: X-Spam-Status: No, score=-103.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7h5ZAj7AaWBw for ; Sat, 29 Oct 2011 23:42:26 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E47D51F0C35 for ; Sat, 29 Oct 2011 23:42:26 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 29 Oct 2011 23:42:26 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 29 Oct 2011 23:42:25 -0700 Thread-Topic: [marf] draft-jdfalk-marf-redaction Thread-Index: AcvgsQzbzJhWamo8R0KTGHdVml5+TS2HU1Lw Message-ID: References: <4D7B66FB.3040202@tana.it> In-Reply-To: <4D7B66FB.3040202@tana.it> 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] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 06:42:27 -0000 Revisiting this very old thread to get some momentum going... > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, March 12, 2011 4:29 AM > To: marf@ietf.org > Subject: Re: [marf] draft-jdfalk-marf-redaction >=20 > What strings should be identified as private data? I'd suggest to > redact atoms, rather than strings that contain special characters. "atoms" in the ABNF sense? Or what exactly do you mean here? > How do consumers identify redacted parts? Are they expected to be > able to verify DKIM signatures after replacing the redacted parts? > (Don't they need the redaction key to check they identified each part > correctly?) Why might there be a need to identify redacted parts? That sounds like a m= achine parsing problem. Is there some reason a parser would need to identi= fy segments that were redacted? Certainly submitting something redacted means DKIM can't be verified. But = I don't think that's a concern; there has to be some understanding that ret= urning redacted information prevents any kind of useful DKIM activity on th= e original (returned) message. The authfailure-report document also covers= this. If a consumer had the redaction key, then there's not much point in redacti= ng at all. > What about line length limits? Should the encoded hash be truncated > to the length of the redacted token? No; if you redact one byte, then you truncate the hash at one byte. Huge c= ollision worry. > After private data has been identified, should it be redacted in the > whole message, that is, including the body? For example, I think I > can hide some text . > Should we standardize such practice, since we are at it? I think I'd prefer to let the report generator decide. > We should explicitly say what parts should never be redacted. This > includes header fields names, boundaries, and most parts of /some/ > fields, for example DKIM signatures possibly except z=3D, Received > fields possibly except "for" clauses. I'd be fine with limiting it so that header field names, or any parts of th= e message that constitute structure (media types, for example) SHOULD NOT b= e redacted. Or, at least, I can't see that being a problem. > As a security consideration, I'd mention that the scope of redaction > is limited to casual eavesdropper, including low-privileged abuse > teams staffers. Using logs or purposely added opaque fields, one can > learn who were the original recipients, which is the reason why abuse > messages are sent in the first place. That sounds reasonable as well. From msk@cloudmark.com Sat Oct 29 23:51:58 2011 Return-Path: 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 CF3A21F0C35 for ; Sat, 29 Oct 2011 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 nYv7HSU4EZeK for ; Sat, 29 Oct 2011 23:51:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AE21F84AB for ; Sat, 29 Oct 2011 23:51:58 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 29 Oct 2011 23:51:58 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 29 Oct 2011 23:51:58 -0700 Thread-Topic: [marf] draft-jdfalk-marf-redaction Thread-Index: AcvduEsWQyVl0Xu5QdelFFKNPXXM+i5F1H6Q Message-ID: References: In-Reply-To: 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] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 06:51:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Tuesday, March 08, 2011 9:43 AM > To: Message Abuse Report Format working group > Subject: [marf] draft-jdfalk-marf-redaction >=20 > I was in the mood for xml the other day, so I took section 10 of draft- > ietf-marf-dkim-reporting and added the minimum necessary additional > text and formatting to make it a stand-alone draft: >=20 > http://tools.ietf.org/html/draft-jdfalk-marf-redaction-00 >=20 > (Oops, just noticed I forgot to acknowledge the original authors. Many > apologies; that'll be fixed in the next version.) >=20 > My thought is that by making this a stand-alone Informational RFC, > it'll be easy to reference from other documents. >=20 > Any thoughts? Commenting on the -01 version: As Alessandro pointed out, one might want to redact anything in the message= , not just local-parts. Section 2 already says that, but the paragraph at = the end also seems focused on the idea that user-ids are all that gets cove= red. That paragraph should be more generic. Also, Section 2 should include a SHOULD NOT with respect to redacting porti= ons of the message that define its structure, namely header field names and= parts of the MIME structure like boundary strings and media types. Section 3 should include a paragraph reflecting Alessandro's point about pr= ivileged users (e.g., users with access to logs) possibly being able to ded= uce private information in correlation with redacted bits of a message. The IESG lately cringes at specific endorsement of SHA1 or MD5. I suggest c= hanging "SHA1" to something more general like "any acceptable hash/digest a= lgorithm". Since this technique is in production use in a few places (Mike from Facebo= ok said so earlier in this thread, for example, and we know of other MAAWG = members doing so as well), and since the target status is Informational, ma= ybe this one is also getting close to being WGLC-able. Comments? -MSK From shmuel+gen@patriot.net Sun Oct 30 13:12:36 2011 Return-Path: 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 81B7521F8B76 for ; Sun, 30 Oct 2011 13:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 0+3r7li7Vaiu for ; Sun, 30 Oct 2011 13:12:36 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2021F8B65 for ; Sun, 30 Oct 2011 13:12:35 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.81]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id E8FA0F58113 for ; Sun, 30 Oct 2011 16:00:33 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 30 Oct 2011 16:18:31 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111030200036.E8FA0F58113@smtp.patriot.net> Subject: Re: [marf] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 20:12:36 -0000 In , on 10/29/2011 at 11:42 PM, "Murray S. Kucherawy" said: >"atoms" in the ABNF sense? Presumably in either[1] the RFC 5321 or the RFC 5322 sense: Atom = 1*atext atext = ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / ; characters not including "$" / "%" / ; specials. Used for atoms. "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] [1] Differing in whether to allow CFWS -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Sun Oct 30 15:06:06 2011 Return-Path: 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 32E9321F8BBB for ; Sun, 30 Oct 2011 15:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.276 X-Spam-Level: X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 swqEtwMMFHti for ; Sun, 30 Oct 2011 15:06:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8194E21F8BB8 for ; Sun, 30 Oct 2011 15:05:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 30 Oct 2011 15:05:59 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 30 Oct 2011 15:05:59 -0700 Thread-Topic: [marf] draft-jdfalk-marf-redaction Thread-Index: AcyXQEmyxofmwv6FSOGcL/N2dxF00wAD7P3w Message-ID: References: <20111030200036.E8FA0F58113@smtp.patriot.net> In-Reply-To: <20111030200036.E8FA0F58113@smtp.patriot.net> 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] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 22:06:06 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Sunday, October 30, 2011 2:19 PM > To: marf@ietf.org > Subject: Re: [marf] draft-jdfalk-marf-redaction >=20 > >"atoms" in the ABNF sense? >=20 > Presumably in either[1] the RFC 5321 or the RFC 5322 sense: Yes, I know what "atoms" means, but I don't understand why it would be appr= opriate to require that one redact each atom individually. That's why I'm = asking. From vesely@tana.it Mon Oct 31 11:20:21 2011 Return-Path: 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 669E821F8C72 for ; Mon, 31 Oct 2011 11:20:21 -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 2pje2wPXvHZf for ; Mon, 31 Oct 2011 11:20:20 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 845B421F8BAB for ; Mon, 31 Oct 2011 11:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1320085217; bh=twfLkeMI68Rcx9vKGL6a3uUOv3JI+eOQ7EES2jjTNHM=; l=959; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=crWRmTGLIu+N8awyJdEApk8/jSPA0pNc5zHWSFcspFh3dFW2Fq06wjtf6fShdP5Iu 25WFBvlxI6huP0w9b0GdfJJrYR1w1qKf0am7FHX6UMv5HVuNVj87N1os1t5FtcsYAW khcoByV3V8X398bX3zPptjX0PL8QbWHSVCCr8nqE= Received: from [193.0.27.158] (dhcp-27-158.ripemtg.ripe.net [193.0.27.158]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 31 Oct 2011 19:20:16 +0100 id 00000000005DC039.000000004EAEE6E0.00005033 Message-ID: <4EAEE6D3.8000400@tana.it> Date: Mon, 31 Oct 2011 19:20:03 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20111030200036.E8FA0F58113@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:20:21 -0000 On 30.10.2011 23:05, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Shmuel Metz >> Sent: Sunday, October 30, 2011 2:19 PM >> To: marf@ietf.org >> Subject: Re: [marf] draft-jdfalk-marf-redaction >> >>> "atoms" in the ABNF sense? >> >> Presumably in either[1] the RFC 5321 or the RFC 5322 sense: > > Yes, I know what "atoms" means, but I don't understand why it would be > appropriate to require that one redact each atom individually. That's why > I'm asking. IIRC, I was trying to make sense of 2. Identify string(s) (such as local-parts of email addresses) in a message that need to be redacted. Call this the "private data". It is the most difficult part of the task. Doing it too liberally may make the whole header unusable, and redacting each atom individually is an easy criterion to avoid that. (Well, it looks easy to specify, at least.) From shmuel+gen@patriot.net Mon Oct 31 12:07:11 2011 Return-Path: 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 F05461F0CCD for ; Mon, 31 Oct 2011 12:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 FUM0nCuqLPzv for ; Mon, 31 Oct 2011 12:07:11 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 93B991F0C8C for ; Mon, 31 Oct 2011 12:07:10 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.116]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 9EAAEF58118 for ; Mon, 31 Oct 2011 14:55:19 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Mon, 31 Oct 2011 12:08:59 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111031185519.9EAAEF58118@smtp.patriot.net> Subject: Re: [marf] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:07:12 -0000 In , on 10/30/2011 at 03:05 PM, "Murray S. Kucherawy" said: >Yes, I know what "atoms" means, but I don't understand why it would >be appropriate to require that one redact each atom individually. >That's why I'm asking. You asked '"atoms" in the ABNF sense? Or what exactly do you mean here?',[1]. You didn't ask why it was appropriate to redact only atoms. [1] RFC 5234 doesn't define atom. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Mon Oct 31 13:27:27 2011 Return-Path: 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 7BBA011E822D for ; Mon, 31 Oct 2011 13:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.281 X-Spam-Level: X-Spam-Status: No, score=-103.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JdrwM+Vc0Rvh for ; Mon, 31 Oct 2011 13:27:27 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6411E8234 for ; Mon, 31 Oct 2011 13:27:26 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 31 Oct 2011 13:27:26 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 31 Oct 2011 13:27:29 -0700 Thread-Topic: [marf] draft-jdfalk-marf-redaction Thread-Index: AcyX+cTB/DHyqrzqQw6XeWT5P9eqNAAEUYgg Message-ID: References: <20111030200036.E8FA0F58113@smtp.patriot.net> <4EAEE6D3.8000400@tana.it> In-Reply-To: <4EAEE6D3.8000400@tana.it> 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] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:27:27 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, October 31, 2011 11:20 AM > To: marf@ietf.org > Subject: Re: [marf] draft-jdfalk-marf-redaction >=20 > IIRC, I was trying to make sense of >=20 > 2. Identify string(s) (such as local-parts of email addresses) in a > message that need to be redacted. Call this the "private data". >=20 > It is the most difficult part of the task. Doing it too liberally may ma= ke > the whole header unusable, and redacting each atom individually is an eas= y > criterion to avoid that. (Well, it looks easy to specify, at least.) Possibly, but since "foo@bar.com" consists of four atoms, you end up with s= omething like this if you want to encode an email address: [redacted-encoding1][redacted-encoding2][redacted-encoding3][redacted-encod= ing4] That seems excessive. From msk@cloudmark.com Mon Oct 31 14:46:34 2011 Return-Path: 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 9981011E82E7 for ; Mon, 31 Oct 2011 14:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.287 X-Spam-Level: X-Spam-Status: No, score=-103.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 xFLoZ6xaCEkE for ; Mon, 31 Oct 2011 14:46:33 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6A911E82D5 for ; Mon, 31 Oct 2011 14:46:33 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 31 Oct 2011 14:46:17 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 31 Oct 2011 14:46:19 -0700 Thread-Topic: [marf] draft-jdfalk-marf-redaction Thread-Index: AcvhaV4JNN7e3xVJRJ+QX8+MZ1gzJi2rPLVg Message-ID: References: <4D7B66FB.3040202@tana.it> <4D7C9CAB.5080101@ntlworld.com> In-Reply-To: <4D7C9CAB.5080101@ntlworld.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] draft-jdfalk-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:46:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= acqui Caren-home > Sent: Sunday, March 13, 2011 3:30 AM > To: marf@ietf.org > Subject: Re: [marf] draft-jdfalk-marf-redaction >=20 > I would recommend that redaction be based upon the anti-spam score the > orginal message gets and what level of trust you place in the MSP. >=20 > > Just mumbling... >=20 > Given the fiasco while trying to report abusive (inline image heavy to bo= tnet/scraper > spamtraps) spam to messagelabs I would recommend redaction of all identif= ying marks > when dealing with a spamtrap of obvious spam. > This includes the "name" part of the recipent which is being used by some= commercial > spammers (including the said ML spammer) as a unique "tag" back into thie= r list. Such > tricks are being used by spammers and some bulk MSP's who buy in lists an= d wish to > detect the spamtraps hit. Even worse are the list cleanse businesses who = are using said > tricks to generate lists of know spamtraps for resale or reuse to cleanse= commercial > list data. I am afraid that detecting spamtraps is big business and peopl= e like ML > seem to be quite happy to help paying "customers" detect them. I'm inclined to say the choice of when and what things to redact should be = left as a policy decision. If we have suggestions or examples, that's fine= to include in an informational sense, but we should go no further.