From vesely@tana.it Sun Jan 1 04:07:53 2012 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 B6A5121F84F8 for ; Sun, 1 Jan 2012 04:07:53 -0800 (PST) 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 Hy6zPZbCjdsw for ; Sun, 1 Jan 2012 04:07:53 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E035A21F84FB for ; Sun, 1 Jan 2012 04:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325419669; bh=kxypd2lWyhoQl0112+UKTp/4rlGR/qZwdvuldzMlOHM=; l=1252; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Rw4jDhSKacAQu4FHB0HaFtldlh9ri6e0tJO1gH7N54hn1iZynGcbxx8H2qbr0B6cB PUiYPRNPvYsE3dnB/5lyqsRR8fFgJP1s1ZepCsALRRhRyta4/+Ych1ylCw8AqSmkAT aWkF68ZDQ2AsINiQUhAmMNVrsy0JzK81L/+UnwU0= Received: from [109.115.164.45] ([109.115.164.45]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 01 Jan 2012 13:07:46 +0100 id 00000000005DC035.000000004F004C93.000023FC Message-ID: <4F004C7E.4020400@tana.it> Date: Sun, 01 Jan 2012 13:07:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111231152509.55169.qmail@joyce.lan> In-Reply-To: <20111231152509.55169.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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: Sun, 01 Jan 2012 12:07:53 -0000 On 31.12.2011 16:25, John Levine wrote: > This seems way, way, over-detailed for an Applicability Statement. > > As I understand it, and AS is intended to answer basic questions about > "what do you use this for"? In the case of ARF, the answer is that > mostly you use it in private FBLs, but we've found that you can also > use it for normal abuse reports. That's it. I don't think we should feel constrained by formal purism. The document's usability won't be compromised if we mix a few technical specifications in it. For Security Considerations in particular, we should note possible weaknesses if they are relevant to abuse reporting. I'd rather discuss their merit than their formal role. > When we have more experience with using ARF in abuse reports, we might > put some of this stuff in a BCP, but since I don't know anyone other > than me who has much experience using them in abuse reports, that > seems rather premature. I agree there's a number of techniques we never tried. IMHO, such kind of stuff belongs to reporting-discovery, be it destined to PS, Experimental, or (gasp) oblivion. For example, how should network providers handle the complaints sent to their RIR-published abuse mailboxes? Happy 2012 From shmuel+gen@patriot.net Sun Jan 1 08:33:49 2012 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 0315611E809A for ; Sun, 1 Jan 2012 08:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 GMqFGNGxf-AE for ; Sun, 1 Jan 2012 08:33:48 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 64D4211E8073 for ; Sun, 1 Jan 2012 08:33:48 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.118]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id EE6EDF580A1 for ; Sun, 1 Jan 2012 11:20:13 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 31 Dec 2011 19:50:24 -0500 To: marf@ietf.org In-Reply-To: <4EFEF84D.9080709@tana.it> Mail-Copies-To: nobody 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: <20120101162014.EE6EDF580A1@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.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: Sun, 01 Jan 2012 16:33:49 -0000 In <4EFEF84D.9080709@tana.it>, on 12/31/2011 at 12:55 PM, Alessandro Vesely said: >As there is no non-invasive established method to prove subscriptions >(yet) I don't think it could make much sense to suggest to carry out >such kind of check, e.g. by asking each user to reconfirm >subscription. An audit is less invasive than terminating them for violating the TOS. If they want to preserve their reputation then they need to deal with an acknowledged policy contravention, not just request listwashing. The audit need not involve requesting each user to reconfirm. -- 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 Sun Jan 1 11:26:37 2012 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 B94FF21F8BDE for ; Sun, 1 Jan 2012 11:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.253 X-Spam-Level: X-Spam-Status: No, score=-105.253 tagged_above=-999 required=5 tests=[AWL=-4.513, BAYES_20=-0.74, 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 TVCfrlRfmoDj for ; Sun, 1 Jan 2012 11:26:37 -0800 (PST) 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 276C321F8BD8 for ; Sun, 1 Jan 2012 11:26:36 -0800 (PST) Received: (qmail 62876 invoked from network); 1 Jan 2012 19:26:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Jan 2012 19:26:32 -0000 Date: 1 Jan 2012 19:26:10 -0000 Message-ID: <20120101192610.16720.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4F004C7E.4020400@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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: Sun, 01 Jan 2012 19:26:37 -0000 >> As I understand it, and AS is intended to answer basic questions about >> "what do you use this for"? In the case of ARF, the answer is that >> mostly you use it in private FBLs, but we've found that you can also >> use it for normal abuse reports. That's it. > >I don't think we should feel constrained by formal purism. The document's >usability won't be compromised if we mix a few technical specifications in >it. I really don't want to add the sort of speculative stuff you've been suggesting. There are a lot of ways to use abuse reports, and beyond some very general advice like don't assume that all reporters are competent or that all reports are necessarily relevant, it is extremely presumptuous for us to assume we know what goes on inside other people's mail systems. R's, John From msk@cloudmark.com Sun Jan 1 22:37:06 2012 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 178A021F84B0 for ; Sun, 1 Jan 2012 22:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 hc5sDtjyddUy for ; Sun, 1 Jan 2012 22:37:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8820221F8880 for ; Sun, 1 Jan 2012 22:37:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 1 Jan 2012 22:36:56 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 1 Jan 2012 22:37:01 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 1 Jan 2012 22:37:10 -0800 Thread-Topic: [marf] Document status(es) Thread-Index: AczHq0mOW2iRd8dHT06Es18yutoGeQBbUr6g Message-ID: References: <4EFEEAF2.9050109@tana.it> In-Reply-To: <4EFEEAF2.9050109@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] Document status(es) 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, 02 Jan 2012 06:37:06 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, December 31, 2011 2:59 AM > To: marf@ietf.org > Subject: Re: [marf] Document status(es) >=20 > My understanding is that redaction is sometimes necessary or useful, > but even then the WG has no final solutions. We just propose an > algorithm, and thus the document is informative. If aiming at PS > implies devising a protocol for thoroughly redacting messages, I > suggest we don't. I don't think the redaction document has any such lofty goals. It's a tech= nique that can be applied that is both effective and useful (at least, just= as effective and more useful than replacing the sensitive stuff with "xxxx= xxxx"). And it's starting to see some uptake already. "Thoroughly redacting messages" seems to me to be the same thing as not sen= ding a report at all; any complaint you make, no matter how small, could po= tentially reveal something. From vesely@tana.it Mon Jan 2 05:26:57 2012 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 3DB7E21F8C46 for ; Mon, 2 Jan 2012 05:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[AWL=0.465, 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 lIlKZR3-otZp for ; Mon, 2 Jan 2012 05:26:56 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5012F21F8C41 for ; Mon, 2 Jan 2012 05:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325510813; bh=2TlNAjZZsJQMwKnPGGQ7G9miathckzW3TFHYfr6ohTg=; l=1048; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fhz7l3zARB+K01CKasoeK8tr0HErUjF+w04/IoDotNVnVdyqDDbAmhvaxjuEf9l4R rVSgqgsuHFC17tTrMLqWNvrcC/Br3U1MZXENXDMz36sJY/sq/iKMJnWfDPwKKeojhd e0m4iE40ByG4jeJMq12L5e1yhalh2p6e6pSx8y+k= Received: from [109.113.131.126] ([109.113.131.126]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 02 Jan 2012 14:26:50 +0100 id 00000000005DC042.000000004F01B09B.0000663F Message-ID: <4F01B080.9080201@tana.it> Date: Mon, 02 Jan 2012 14:26:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EFEEAF2.9050109@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] Document status(es) 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, 02 Jan 2012 13:26:57 -0000 On 02.01.2012 07:37, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> If aiming at PS implies devising a protocol for thoroughly redacting >> messages, I suggest we don't. > > I don't think the redaction document has any such lofty goals. Indeed, it doesn't even say in what cases redaction is applicable. It only recalls that Precisely how this is done is unspecified in [ARF] as it will generally be a matter of local policy. That specification does admonish generators against being too over-zealous with this practice, as obscuring too much data makes the report non-actionable. The second sentence seems to be construed for an Informational doc that talks about a Standard. Should it be amended if changing status to PS? Or maybe the document should state that it specifies the algorithm only, so that it is clear that no other goals are intended. I see no other corners that may deserve attention when turning to PS. BTW, s/identity of then end user/identity of the end user/. From msk@cloudmark.com Mon Jan 2 21:37:24 2012 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 0F92F21F8529 for ; Mon, 2 Jan 2012 21:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 xVmS7El2fQ7u for ; Mon, 2 Jan 2012 21:37:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 454DA21F8487 for ; Mon, 2 Jan 2012 21:37:23 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Jan 2012 21:37:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 2 Jan 2012 21:37:22 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 2 Jan 2012 21:37:31 -0800 Thread-Topic: Document status(es) Thread-Index: AczGWh/zWObWO1IITDuTIVxu7EnLyADfxfww 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] Document status(es) 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, 03 Jan 2012 05:37:24 -0000 In case there are people not watching the list due to the holidays, I'll wa= it a couple of days before moving ahead, but I think consensus is leaning t= oward changing the redaction document to Proposed Standard, and then reques= ting a second IETF Last Call on both of them. If those Last Calls are init= iated by the end of Wednesday, they will complete in time for their current= ly-scheduled 1/19 IESG Evaluations. I've prepared an updated redaction document with that in mind, and I'll wor= k with Hilda to get an updated authfailure-report document ready as well, t= aking into account the IESG and Gen-ART feedback we've received so far. If there are any other opinions about a way forward (or just more support f= or the apparent preferred path), please say so soon. -MSK From sm@resistor.net Tue Jan 3 02:08:47 2012 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 6D6A321F858B for ; Tue, 3 Jan 2012 02:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 jF06lXAnsMVt for ; Tue, 3 Jan 2012 02:08:45 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB121F8587 for ; Tue, 3 Jan 2012 02:08:45 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q03A8dqi001443 for ; Tue, 3 Jan 2012 02:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325585324; i=@resistor.net; bh=zIULycfPCpnRZvwNa02BkvUc27S/hHf/cASWmb8+idE=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wQMJOA++h0z37SOD92TfN+iNkbkEuoRLSmfnAPhbykgYDAl+78zEII/MaXxkAK2kA 7RiPeKYIa+5ZFuw6MGI0wyS1thJ/oKSB1PlYxAnpq9ctpShGqFv6pVFjV2YUs1LQrE neYTFp1ywi+SD1W23xwWuB0zhzD4TDD+Eypr6caw= Message-Id: <6.2.5.6.2.20120103014349.098e8608@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 02:02:09 -0800 To: marf@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] Document status(es) 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, 03 Jan 2012 10:08:47 -0000 At 21:37 02-01-2012, Murray S. Kucherawy wrote: >In case there are people not watching the list due to the holidays, >I'll wait a couple of days before moving ahead, but I think >consensus is leaning toward changing the redaction document to >Proposed Standard, and then requesting a second IETF Last Call on >both of them. If those Last Calls are initiated by the end of >Wednesday, they will complete in time for their currently-scheduled >1/19 IESG Evaluations. My preference is to keep the references as they are now and go for the second Last Call with the usual downref disclaimer. draft-ietf-marf-redaction-03 documents a practice. Regards, -sm From presnick@qualcomm.com Tue Jan 3 08:10:50 2012 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 0F45221F84CF for ; Tue, 3 Jan 2012 08:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 TGeK0++UP8m3 for ; Tue, 3 Jan 2012 08:10:45 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7530E21F84FD for ; Tue, 3 Jan 2012 08:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1325607045; x=1357143045; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F03283B.4050203@qualcomm.com>|Date:=20Tu e,=203=20Jan=202012=2010:09:31=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20SM=20|CC:=20< marf@ietf.org>|Subject:=20Re:=20[marf]=20Document=20statu s(es)|References:=20=09=20<6. 2.5.6.2.20120103014349.098e8608@resistor.net> |In-Reply-To:=20<6.2.5.6.2.20120103014349.098e8608@resist or.net>|Content-Type:=20text/plain=3B=20charset=3D"ISO-88 59-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207 bit|X-Originating-IP:=20[172.30.48.1]; bh=EoQNt8vVexC7HNc8Bn4B8j9gYP7OqkgGCsmS6R5+xq0=; b=g5Z8xeFTRShkUgxKGnGEJdAP/3N1Wxg8R77vOaUztsmvTWU/qp8ZaJGR +arf0kzMj/kBNM7nU/VBtzSfj4wAzewuPaKA592dijPDp/U/ZgLZijxfE V0YCll2PlS2xQvbuFlHuSFTyyvjNmb6rdtPwq7KmysMJ1gQ10J0zS3XUl Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6577"; a="151693134" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 03 Jan 2012 08:10:32 -0800 X-IronPort-AV: E=Sophos;i="4.71,450,1320652800"; d="scan'208";a="156900784" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Jan 2012 08:10:29 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 3 Jan 2012 08:09:31 -0800 Message-ID: <4F03283B.4050203@qualcomm.com> Date: Tue, 3 Jan 2012 10:09:31 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120103014349.098e8608@resistor.net> In-Reply-To: <6.2.5.6.2.20120103014349.098e8608@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: marf@ietf.org Subject: Re: [marf] Document status(es) 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, 03 Jan 2012 16:10:50 -0000 On 1/3/12 4:02 AM, SM wrote: > My preference is to keep the references as they are now and go for the > second Last Call with the usual downref disclaimer. > draft-ietf-marf-redaction-03 documents a practice. The redaction document *proposes* a *standard* way of doing redaction. Indeed, the document specifically says that previous practices for redaction cause problems operationally and therefore it *proposes* a better way for everyone to do it. Furthermore, authfailure-report is clearly referring to this practice in a normative way. I am having a hard time understanding how this "documented practice" is not a "proposed standard" and why I should not last call it that way. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sm@resistor.net Tue Jan 3 09:09:21 2012 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 C71A621F85BD for ; Tue, 3 Jan 2012 09:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 y6wTvUpq-loD for ; Tue, 3 Jan 2012 09:09:19 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 727DA21F85AD for ; Tue, 3 Jan 2012 09:09:19 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q03H9Cud021670; Tue, 3 Jan 2012 09:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325610557; i=@resistor.net; bh=PdNTsYCmM92geJMbb9LilfZM9a8Jt9rapGD4lHkEk/c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Y73kQ4wokFw8kgSoC/dFRcNezPIHflNw+iY9tF/ZxZOHFZ6+qVpeYB+MFRpcUx0dp JYUrJNuslaJJu6hlElfTRQI8e1k8iWSBhnB4PRc4yXHA9eD+D2DVvBNQU3YjfLCBvM YegbwQrzvfe5KdKfcxLHKtH6noNQQsR0RCtt/nJs= Message-Id: <6.2.5.6.2.20120103082135.0b863d58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 08:56:17 -0800 To: Pete Resnick From: SM In-Reply-To: <4F03283B.4050203@qualcomm.com> References: <6.2.5.6.2.20120103014349.098e8608@resistor.net> <4F03283B.4050203@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Document status(es) 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, 03 Jan 2012 17:09:21 -0000 Hi Pete, At 08:09 03-01-2012, Pete Resnick wrote: >The redaction document *proposes* a *standard* way of doing >redaction. Indeed, the document specifically says that previous >practices for redaction cause problems operationally and therefore >it *proposes* a better way for everyone to do it. Based on the above argument, draft-ietf-marf-redaction-03 fits within "proposed standard". Regards, -sm From internet-drafts@ietf.org Tue Jan 3 09:49:53 2012 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 DEDD711E80A0; Tue, 3 Jan 2012 09:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Z0UkXf1RYsdd; Tue, 3 Jan 2012 09:49:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689711E8098; Tue, 3 Jan 2012 09:49:53 -0800 (PST) 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.64p1 Message-ID: <20120103174953.27970.92401.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 09:49:53 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-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, 03 Jan 2012 17:49:54 -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 M. Kucherawy Filename : draft-ietf-marf-redaction-04.txt Pages : 7 Date : 2012-01-03 Email messages often contain information that 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. [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to enable him to complete the publication process on behalf of J.D. Falk. Please remove Murray from the author list prior to publication.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-redaction-04.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-04.txt From msk@cloudmark.com Tue Jan 3 09:51:35 2012 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 1DB1A21F848A for ; Tue, 3 Jan 2012 09:51:35 -0800 (PST) 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 Pe81DIvxi11U for ; Tue, 3 Jan 2012 09:51:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79F21F8482 for ; Tue, 3 Jan 2012 09:51:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 09:51:28 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 3 Jan 2012 09:51:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 3 Jan 2012 09:51:31 -0800 Thread-Topic: [marf] Document status(es) Thread-Index: AczKOnTvN7iorr4ZS0aACJSWPZXYrQABckxQ Message-ID: References: <6.2.5.6.2.20120103014349.098e8608@resistor.net> <4F03283B.4050203@qualcomm.com> <6.2.5.6.2.20120103082135.0b863d58@resistor.net> In-Reply-To: <6.2.5.6.2.20120103082135.0b863d58@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] Document status(es) 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, 03 Jan 2012 17:51:35 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Tuesday, January 03, 2012 8:56 AM > To: Pete Resnick > Cc: marf@ietf.org > Subject: Re: [marf] Document status(es) >=20 > Hi Pete, > At 08:09 03-01-2012, Pete Resnick wrote: > >The redaction document *proposes* a *standard* way of doing redaction. > >Indeed, the document specifically says that previous practices for > >redaction cause problems operationally and therefore it *proposes* a > >better way for everyone to do it. >=20 > Based on the above argument, draft-ietf-marf-redaction-03 fits within > "proposed standard". Accordingly, I've posted a new version if draft-ietf-marf-redaction that se= eks Standards Track status. Pete, LC at your discretion. -MSK From sm@resistor.net Tue Jan 3 12:11:37 2012 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 F032D21F84D7 for ; Tue, 3 Jan 2012 12:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 U+BR7tWBXyGF for ; Tue, 3 Jan 2012 12:11:33 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B822611E809D for ; Tue, 3 Jan 2012 12:11:33 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q03KBRPc009652; Tue, 3 Jan 2012 12:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325621492; i=@resistor.net; bh=148uu8+zkHMTJsH+zPgoJJlgGuzXG9CtGaOw7Ay19kI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=2x+q3jfw6GSYWv+HC+vvuq+PrmQjU0FBsvdWSPHRNFBrDazwnid3D/bOQFNJtxZP7 CfRZfHOn4uzcnLYxW76ZHFRq9sPbDuvHIDypJPGBlV94pfRwpMiL0MTgLdduwAOUdJ D+U7ZGyHybRuewdpfiYyNF7sqGzGSBbVrOgVWG0g= Message-Id: <6.2.5.6.2.20120103113844.0b840708@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 12:11:23 -0800 To: Alessandro Vesely From: SM In-Reply-To: <4EFC5F35.8020805@tana.it> References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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, 03 Jan 2012 20:11:37 -0000 Hi Alessandro, At 04:38 29-12-2011, Alessandro Vesely wrote: >Sections 6 and 7 are dedicated to solicited feedback. However, there >is a number of points that should be valid also for unsolicited >reports. If the order is not important, the common points could be >put in a common section. Specifically, for the sending part, Section >6, here's the points I think should be common and why: It's the beginning of the year. I have some difficulty understanding what changes you suggested. >the provided ARF fields. This concept needs to be stated, though. >The beginning of the third paragraph of Section 8 can be changed so as >to read like so: > > Recipients of unsolicited ARF reports SHOULD, in general, handle them > the same way as any other abuse reports. However, they can take > advantage of the ARF format to automate processing. Lacking [etc.] I don't understand what change you are asking for as there is such text in Section 8. Could you ask the editor of the document to generate a revision with your changes as it would be easier to read and comment? BTW, as this draft is about an applicability statement, I would expect it to be clear about how the technical specifications it references should be used. Text such as "Provider generating the reports SHOULD NOT assume that the operator receiving" is more of an assumption that the key word will "make things happen" than some requirement that will help in the deployment of the specifications. In my opinion, the document needs much more work to be ready for a Last Call. Thanks, -sm From msk@cloudmark.com Tue Jan 3 13:48:14 2012 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 94DC011E8100 for ; Tue, 3 Jan 2012 13:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 9jY-PgCEcY5j for ; Tue, 3 Jan 2012 13:48:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FB11E80E9 for ; Tue, 3 Jan 2012 13:48:14 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 13:48:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 3 Jan 2012 13:48:13 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 3 Jan 2012 13:48:23 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-02.txt Thread-Index: AczKU+dOWbldn8JATku/kirrCpr9zwADW79Q Message-ID: References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> <6.2.5.6.2.20120103113844.0b840708@resistor.net> In-Reply-To: <6.2.5.6.2.20120103113844.0b840708@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] I-D Action: draft-ietf-marf-as-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, 03 Jan 2012 21:48:14 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Tuesday, January 03, 2012 12:11 PM > To: Alessandro Vesely > Cc: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt >=20 > In my opinion, the document needs much more work to be ready for a Last > Call. Do you have specific changes to draft-ietf-marf-as-02 you would like to see= ? From sm@resistor.net Tue Jan 3 15:06:25 2012 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 5B0FB11E80B5 for ; Tue, 3 Jan 2012 15:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 ESFg90PEXCVP for ; Tue, 3 Jan 2012 15:06:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C50D711E80AF for ; Tue, 3 Jan 2012 15:06:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q03N6HgJ006750 for ; Tue, 3 Jan 2012 15:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325631982; i=@resistor.net; bh=n5uEFYtdlvDC53SQIC3/6J1BVHVB3MLLY1478AVcXkA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=C1STdIpt/XDef6DSoeQAUC2WiMdrzXzQWjqF657Ij70KOXky8zPTPRqyGRpG6HoCT LFx++zxNaq/BelEDltH+OzKp5LXhLe51EffgNkny5q7luVBZetvwY/FGT8Z5CjCjY6 As4zLX5lRRJJHCa4T6YajzncTpnfUe8N8escLzQk= Message-Id: <6.2.5.6.2.20120103143306.0aa6ebf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Jan 2012 14:43:16 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> <6.2.5.6.2.20120103113844.0b840708@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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, 03 Jan 2012 23:06:25 -0000 Hi Murray, At 13:48 03-01-2012, Murray S. Kucherawy wrote: >Do you have specific changes to draft-ietf-marf-as-02 you would like to see? It's easier for me if I do not to suggest text at this stage as I would like to review the draft if there is a publication request. Regards, -sm From internet-drafts@ietf.org Tue Jan 3 16:58:05 2012 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 63D1D11E80C6; Tue, 3 Jan 2012 16:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 AV5H-sbImxmK; Tue, 3 Jan 2012 16:58:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D505C11E80BD; Tue, 3 Jan 2012 16:58:04 -0800 (PST) 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.64p1 Message-ID: <20120104005804.28749.6956.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 16:58:04 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.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, 04 Jan 2012 00:58:05 -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-08.txt Pages : 20 Date : 2012-01-03 This memo registers an extension report type to the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-08.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-08.txt From sklist@kitterman.com Tue Jan 3 18:50:18 2012 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 3A87421F84D2 for ; Tue, 3 Jan 2012 18:50:18 -0800 (PST) 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 iW7CNlnB+0qC for ; Tue, 3 Jan 2012 18:50:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41121F84C4 for ; Tue, 3 Jan 2012 18:50:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6B44F20E4100; Tue, 3 Jan 2012 21:50:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325645415; bh=wWhqvP6aa+Sa7JHohIdqvMwTV0cJP3dfZysXQ4jr4Js=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZYF90wk/Ai9rMBXXjkTIuuqS6eBWjJlHiipVdZ1CaEaw6GtbWqBBRUK7EMIAIPk0s ruLyZX7dyi1gaWl4weJUVCLbHUBXeiWr8WODRMd0Eq5NXTZZr6PHH85brrvsXzAm8h u6KNr/K9RgnK6KerxLnYFbMpdCrJMQ65DkAZ5sW0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 49A4720E409F; Tue, 3 Jan 2012 21:50:15 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 03 Jan 2012 21:50:14 -0500 Message-ID: <11336597.8i0Rl6knkK@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <20120104005804.28749.6956.idtracker@ietfa.amsl.com> References: <20120104005804.28749.6956.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] I-D Action: draft-ietf-marf-authfailure-report-08.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, 04 Jan 2012 02:50:18 -0000 On Tuesday, January 03, 2012 04:58:04 PM 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-08.txt > Pages : 20 > Date : 2012-01-03 I've lost track of the bidding. Is this the draft supposed to discuss the SPF downref or is that done separately as part of the last call? Scott K From msk@cloudmark.com Tue Jan 3 19:07:41 2012 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 7B5E621F84E2 for ; Tue, 3 Jan 2012 19:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Pb6PKhwAP-ZA for ; Tue, 3 Jan 2012 19:07:41 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2374E21F8448 for ; Tue, 3 Jan 2012 19:07:41 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 19:07:35 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 3 Jan 2012 19:07:40 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 3 Jan 2012 19:07:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.txt Thread-Index: AczKi5pJkkVHBHXrT+qeJcsWuHLx/wAAjbQQ Message-ID: References: <20120104005804.28749.6956.idtracker@ietfa.amsl.com> <11336597.8i0Rl6knkK@scott-latitude-e6320> In-Reply-To: <11336597.8i0Rl6knkK@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] I-D Action: draft-ietf-marf-authfailure-report-08.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, 04 Jan 2012 03:07:41 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, January 03, 2012 6:50 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.txt >=20 > I've lost track of the bidding. Is this the draft supposed to discuss > the SPF downref or is that done separately as part of the last call? The IETF-wide Last Call announcement has to point out the downref. That's = what was missed, necessitating a repeat of that part of the process. This version doesn't change anything about the downref, but rather just inc= orporates all the IESG feedback we'd received thus far. From vesely@tana.it Wed Jan 4 01:33:22 2012 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 9F4AC21F86C5 for ; Wed, 4 Jan 2012 01:33:22 -0800 (PST) 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 GF+oaA+glzjO for ; Wed, 4 Jan 2012 01:33:22 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C229C21F86B6 for ; Wed, 4 Jan 2012 01:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325669599; bh=Gxtvx+R0SZ4tFIm2UeOfW5/fnMyEuBI+C4bzJF3DbJU=; l=326; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=UpbO9QqTy7lM2GS99wVaIB35Q2F8Zo1yNFD1hfjJ+oVvK1qEZjEW/KKs7X6IHBGkB vWQZXO4jJcRhyDd9lHV6c5V/hUBpvSBFvhqgRrZVx0BU9w7dPeGTSF2QA86SHVxh9y WygIGidKpq6hV1wW3/EKTieO+RrtWpMxK6QZfIfU= Received: from [109.115.193.47] ([109.115.193.47]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 04 Jan 2012 10:33:17 +0100 id 00000000005DC033.000000004F041CDE.000028B9 Message-ID: <4F041CCB.5090707@tana.it> Date: Wed, 04 Jan 2012 10:32:59 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20120104005804.28749.6956.idtracker@ietfa.amsl.com> <11336597.8i0Rl6knkK@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.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, 04 Jan 2012 09:33:22 -0000 On 04.01.2012 04:07, Murray S. Kucherawy wrote: > This version doesn't change anything about the downref, but rather just > incorporates all the IESG feedback we'd received thus far. I'd be curious to learn the rationale for allowing comments everywhere in SPF-DNS fields. Doesn't that gratuitously complicate parsing? From vesely@tana.it Wed Jan 4 05:29:09 2012 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 0749C21F8688 for ; Wed, 4 Jan 2012 05:29:09 -0800 (PST) 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 brf+v4+HwuER for ; Wed, 4 Jan 2012 05:29:08 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C788621F864E for ; Wed, 4 Jan 2012 05:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325683746; bh=d3tggc3V5WScMrb+4nices1sTtFbUaXwenqP8xfOj1I=; l=2303; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Z0R3EAKqD1mMpmT3StGCoNXq9Mm9BsGXEGjP1tcz5svPudXqfXl81D3d3K8HH2ifa kcexu5xOnBQ/PIsCrw67Msft/bBf3BIlNFC0FbJpYFb9PvfdJA/vBaYnY9TpXDbhuF jp89sxieeyFzWuTGvJUXR60RFPF8qjuXPLviaPJM= Received: from [109.115.193.47] ([109.115.193.47]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 04 Jan 2012 14:29:04 +0100 id 00000000005DC039.000000004F045421.00005D64 Message-ID: <4F04540B.8070200@tana.it> Date: Wed, 04 Jan 2012 14:28:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> <6.2.5.6.2.20120103113844.0b840708@resistor.net> In-Reply-To: <6.2.5.6.2.20120103113844.0b840708@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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: Wed, 04 Jan 2012 13:29:09 -0000 On 03.01.2012 21:11, SM wrote: > At 04:38 29-12-2011, Alessandro Vesely wrote: >> Sections 6 and 7 are dedicated to solicited feedback. However, there >> is a number of points that should be valid also for unsolicited >> reports. If the order is not important, the common points could be >> put in a common section. > > It's the beginning of the year. I have some difficulty understanding what > changes you suggested. Moving the paragraphs from those numbered lists would alter their numeration. Personally, I don't like them to be numbered, since the numbers bear no special meaning. The subcompact feature worsens their appearance by suggesting some sort of indivisibility. I tend to associate that style with some (mis)conceptions about ASes, and IMHO is unnecessary. If denumbered, some of those paragraphs could be moved in a new section to be entitled, say, "Handling Common to Both Solicited and Unsolicited Reports". >> [Manual vs automated processing] concept needs to be stated, though. >> The beginning of the third paragraph of Section 8 can be changed so as >> to read like so: >> >> Recipients of unsolicited ARF reports SHOULD, in general, handle them >> the same way as any other abuse reports. However, they can take >> advantage of the ARF format to automate processing. Lacking [etc.] > > I don't understand what change you are asking for as there is such text in > Section 8. Yup, I just inserted the second sentence. > Could you ask the editor of the document to generate a revision with your > changes as it would be easier to read and comment? I would post a patch, but I cannot find the xml anymore. So Murray has to insert those two snippets of text, if he likes to, from my previous message http://www.ietf.org/mail-archive/web/marf/current/msg01605.html I'd guess that's possible, since the concept was discussed already here http://www.ietf.org/mail-archive/web/marf/current/msg01223.html And the converse concept was discussed after I asked whether MUAs should allow users to edit the human readable part, about here http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000411.html > In my opinion, the document needs much more work to be ready for a Last Call. +1, for the "unsolicited" part in particular From msk@cloudmark.com Wed Jan 4 09:01:01 2012 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 2F3F421F8790 for ; Wed, 4 Jan 2012 09:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 uZaGsGryLwzj for ; Wed, 4 Jan 2012 09:00:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D60A321F8781 for ; Wed, 4 Jan 2012 09:00:59 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 09:00:49 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 4 Jan 2012 09:00:54 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 4 Jan 2012 09:00:52 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.txt Thread-Index: AczKw+gAwxK4skjzS3+C9p7pgP2s6wAPmLng Message-ID: References: <20120104005804.28749.6956.idtracker@ietfa.amsl.com> <11336597.8i0Rl6knkK@scott-latitude-e6320> <4F041CCB.5090707@tana.it> In-Reply-To: <4F041CCB.5090707@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] I-D Action: draft-ietf-marf-authfailure-report-08.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, 04 Jan 2012 17:01:01 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, January 04, 2012 1:33 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-08.txt >=20 > On 04.01.2012 04:07, Murray S. Kucherawy wrote: > > This version doesn't change anything about the downref, but rather > > just incorporates all the IESG feedback we'd received thus far. >=20 > I'd be curious to learn the rationale for allowing comments everywhere > in SPF-DNS fields. Doesn't that gratuitously complicate parsing? Quite simply, the Gen-ART reviewer pointed out that all of the other ABNF d= efinitions we have used CFWS instead of FWS, except SPF-DNS, so it's been u= pdated to match. From internet-drafts@ietf.org Wed Jan 4 14:43:02 2012 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 5A3F611E80F4; Wed, 4 Jan 2012 14:43:02 -0800 (PST) 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=[AWL=0.000, 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 GDu-tPlmmowL; Wed, 4 Jan 2012 14:43:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D939311E80E8; Wed, 4 Jan 2012 14:43:01 -0800 (PST) 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.64p1 Message-ID: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 14:43:01 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 04 Jan 2012 22:43:02 -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-09.txt Pages : 21 Date : 2012-01-04 This memo registers an extension report type to the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-09.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-09.txt From sklist@kitterman.com Wed Jan 4 15:11:33 2012 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 617A321F87CA for ; Wed, 4 Jan 2012 15:11:33 -0800 (PST) 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 fjTtLYEJzlb1 for ; Wed, 4 Jan 2012 15:11:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3590021F8573 for ; Wed, 4 Jan 2012 15:11:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 915B420E4100; Wed, 4 Jan 2012 18:11:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325718688; bh=yURAF4erik1sBccl/aSMXtnQ4d957/ffxK5jIQMMqHE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=in4TuhaKN3Lk0mOj8pECTTOc3p1hra5SeExNsxUlZxl3R0QCTsEwcpbsKHloPgui2 tH6zUQGWUK+PgzAiw8h/+SgmY0WVqhCGi7v09gFCqj9cPKMfmqMylfysVRHSc19Pod X8P7SXdMctUG0WkCH37DuUoq7q4MOkSNGtFk8gOg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 76AB820E4081; Wed, 4 Jan 2012 18:11:28 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 04 Jan 2012 18:11:27 -0500 Message-ID: <2663045.bBsYJTni1c@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> References: <20120104224301.27158.77714.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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 04 Jan 2012 23:11:33 -0000 I'm sorry I didn't notice this before, but I think that: spf: The evaluation of the author domain's SPF record produced a "fail", "softfail", "temperror" or "permerror" result. should also include "none". For some policy scenarios that would be considered a failure, so we ought to be able to express it. Scott K From msk@cloudmark.com Wed Jan 4 15:16:45 2012 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 E2BCE21F87F4 for ; Wed, 4 Jan 2012 15:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 MfsMQa84txIy for ; Wed, 4 Jan 2012 15:16:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3F21F87F3 for ; Wed, 4 Jan 2012 15:16:45 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 15:16:36 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 4 Jan 2012 15:16:41 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 4 Jan 2012 15:16:40 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczLNjUoQSyrwhv0Qi2okmiXpQ6jtAAAKWGQ Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> In-Reply-To: <2663045.bBsYJTni1c@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 04 Jan 2012 23:16:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 04, 2012 3:11 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report- > 09.txt >=20 > I'm sorry I didn't notice this before, but I think that: >=20 > spf: The evaluation of the author domain's SPF record produced a > "fail", "softfail", "temperror" or "permerror" result. >=20 > should also include "none". For some policy scenarios that would be > considered a failure, so we ought to be able to express it. Wouldn't you assert "fail" in that case? From sklist@kitterman.com Wed Jan 4 15:20:51 2012 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 50D7B11E8106 for ; Wed, 4 Jan 2012 15:20:51 -0800 (PST) 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 GHiNmfwOueyA for ; Wed, 4 Jan 2012 15:20:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 964BE11E80DB for ; Wed, 4 Jan 2012 15:20:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 31A2120E4100; Wed, 4 Jan 2012 18:20:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325719250; bh=+oO/pTYzJ8pvqGKDindo4/IEx+vdB5D+9VniT+oRNSc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=GRNv3Zai6M4lTFTrMyVkY5ZeKXBUth05PrXO0QCazDXHD76aEPNZFuljwW7/LhyHv bdc4zIMR8IYjf5Y3bybj4pmBnBsQWceXTFh/DFdg8eqNCwjIMlOnQZ06gC7gzYCK/M shf+Dp3mjrnA2X32nOCqY6kzAM/IN9WjW2Ysf468= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 173D120E4081; Wed, 4 Jan 2012 18:20:49 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 04 Jan 2012 18:20:49 -0500 Message-ID: <7095702.92rLM2pOu0@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 04 Jan 2012 23:20:51 -0000 On Wednesday, January 04, 2012 03:16:40 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, January 04, 2012 3:11 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report- > > 09.txt > > > > I'm sorry I didn't notice this before, but I think that: > > spf: The evaluation of the author domain's SPF record produced a > > > > "fail", "softfail", "temperror" or "permerror" result. > > > > should also include "none". For some policy scenarios that would be > > considered a failure, so we ought to be able to express it. > > Wouldn't you assert "fail" in that case? No. I'm describing a case where from a policy perspective any SPF result !pass would be considered a failure of authentication (a mail stream that is expected to be 100% authenticated). In this case the SPF result = none, but it's still a failure of authentication (and yes, such mail streams do exist in production). Scott K From msk@cloudmark.com Wed Jan 4 15:26:05 2012 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 A522211E8111 for ; Wed, 4 Jan 2012 15:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 JOM3-HsrZwdT for ; Wed, 4 Jan 2012 15:26:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3686811E80DB for ; Wed, 4 Jan 2012 15:26:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 15:25:59 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 4 Jan 2012 15:26:04 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 4 Jan 2012 15:26:03 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczLN4GuyRSsMgqPRZqCOtUz84MQmgAAGMvg Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> <7095702.92rLM2pOu0@scott-latitude-e6320> In-Reply-To: <7095702.92rLM2pOu0@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 04 Jan 2012 23:26:05 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 04, 2012 3:21 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > No. I'm describing a case where from a policy perspective any SPF > result !pass would be considered a failure of authentication (a mail > stream that is expected to be 100% authenticated). In this case the > SPF result =3D none, but it's still a failure of authentication (and yes, > such mail streams do exist in production). Right, so what I'm saying is that for the case where a "typical" installati= on might report "none", for policy reasons you could instead report "fail".= It's not a change to the SPF evaluation mechanism, just how you report it= . The one case where this breaks down is where you want to be able to detect = the difference yet treat them the same way. From iesg-secretary@ietf.org Wed Jan 4 16:07:45 2012 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 D243A1F0C46; Wed, 4 Jan 2012 16:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 HHYb7cO7W6yJ; Wed, 4 Jan 2012 16:07:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CAF1F0C38; Wed, 4 Jan 2012 16:07:45 -0800 (PST) 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.64p1 Message-ID: <20120105000745.19575.37843.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 16:07:45 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 05 Jan 2012 00:07:46 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' as a Proposed Standard Note: This document was previously considered for Informational, but it is now being considered as a Proposed Standard after comments from the previous Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information that 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. [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to enable him to complete the publication process on behalf of J.D. Falk. Please remove Murray from the author list prior to publication.] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Jan 4 16:08:26 2012 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 35B5B1F0C51; Wed, 4 Jan 2012 16:08:26 -0800 (PST) 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=[AWL=0.119, 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 bUrxfzn9ZlgK; Wed, 4 Jan 2012 16:08:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F221F0C44; Wed, 4 Jan 2012 16:08:25 -0800 (PST) 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.64p1 Message-ID: <20120105000825.19399.86375.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 16:08:25 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 05 Jan 2012 00:08:26 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Authentication Failure Reporting using the Abuse Report Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo registers an extension report type to the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report/ No IPR declarations have been submitted directly on this I-D. This I-D normatively references Experimental RFC 4408. From msk@cloudmark.com Wed Jan 4 16:10:03 2012 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 AFD9221F874F for ; Wed, 4 Jan 2012 16:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 3Ol-fqDQN4-A for ; Wed, 4 Jan 2012 16:09:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0B21F8558 for ; Wed, 4 Jan 2012 16:09:58 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 16:09:52 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 4 Jan 2012 16:09:57 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 4 Jan 2012 16:09:56 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczLNjUoQSyrwhv0Qi2okmiXpQ6jtAAB3lIw Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> In-Reply-To: <2663045.bBsYJTni1c@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 00:10:03 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 04, 2012 3:11 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > I'm sorry I didn't notice this before, but I think that: >=20 > spf: The evaluation of the author domain's SPF record produced a > "fail", "softfail", "temperror" or "permerror" result. >=20 > should also include "none". For some policy scenarios that would be > considered a failure, so we ought to be able to express it. Maybe a simpler thing to say overall is: spf: The evaluation of the author domain's SPF record produced a failing re= sult, meaning either an actual SPF failure (e.g., "fail", "softfail", "temp= error", or "permerror") or any other result that was not acceptable for loc= al policy reasons. ? From sklist@kitterman.com Wed Jan 4 16:13:13 2012 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 8575F21F87A1 for ; Wed, 4 Jan 2012 16:13:13 -0800 (PST) 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 hVhXCbG2V1Cp for ; Wed, 4 Jan 2012 16:13:12 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A009521F879F for ; Wed, 4 Jan 2012 16:13:12 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id F2D2DD04082; Wed, 4 Jan 2012 18:13:10 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325722391; bh=132QjiuUYienG4eAoIZiDIzfkjU5+WisMFZng9Uk16s=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=L6CU7raxwiYASkIHDV+l20Pgd90shTIYigbtNJUvweMiVliKqUGbp9e4pFSBO5an0 5UDsXdXiMgdofugfgOiaHEFbJK+1Bi4ECPKsmxEZfhOUPTjChd6zXAslw+76rp0xgc LpoffM++neRdSc6vz+tzM513QobgVH8PGrJ3qNoo= Received: from 236.sub-97-164-214.myvzw.com (236.sub-97-164-214.myvzw.com [97.164.214.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 94C78D04025; Wed, 4 Jan 2012 18:13:06 -0600 (CST) References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> <7095702.92rLM2pOu0@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 04 Jan 2012 19:12:13 -0500 To: "marf@ietf.org" Message-ID: <34fb832d-5a7e-41e6-a38a-d7465af953b9@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 00:13:13 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Scott Kitterman >> Sent: Wednesday, January 04, 2012 3:21 PM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: >draft-ietf-marf-authfailure-report-09.txt >> >> No. I'm describing a case where from a policy perspective any SPF >> result !pass would be considered a failure of authentication (a mail >> stream that is expected to be 100% authenticated). In this case the >> SPF result = none, but it's still a failure of authentication (and >yes, >> such mail streams do exist in production). > >Right, so what I'm saying is that for the case where a "typical" >installation might report "none", for policy reasons you could instead >report "fail". It's not a change to the SPF evaluation mechanism, just >how you report it. > >The one case where this breaks down is where you want to be able to >detect the difference yet treat them the same way. Then there's also no way to tell which case it is from the header. I don't think that solves the problem. Scott K From vesely@tana.it Thu Jan 5 04:57:54 2012 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 6BE6D21F85B3 for ; Thu, 5 Jan 2012 04:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DYtQTtbugMHH for ; Thu, 5 Jan 2012 04:57:53 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23621F8600 for ; Thu, 5 Jan 2012 04:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325768272; bh=s77+MLPybVze33Gd0rMtL2g9IeZLZVkaVH7/l+EgB5U=; l=1083; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DX2C8veaa+vH9AAGHXDqh6QTn3B8dDYLWMNsYdAKtHYmc8oq+qeTPEolLbzeByIxH GFObu3I/rlPuVGfimXSG+g4mrgYLa6kCZAPBhOuTo6AQoXBA1IA7GgnJ2v0K/TjlPP ds/lbflerBySp8l1zBUkhIXGGtjhSz0u3Bdk/qII= Received: from [109.115.205.6] ([109.115.205.6]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 05 Jan 2012 13:57:50 +0100 id 00000000005DC033.000000004F059E4F.00001813 Message-ID: <4F059E44.909@tana.it> Date: Thu, 05 Jan 2012 13:57:40 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 12:57:54 -0000 On 05.01.2012 01:09, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Scott Kitterman > >> I'm sorry I didn't notice this before, but I think that: >> >> spf: The evaluation of the author domain's SPF record produced a >> "fail", "softfail", "temperror" or "permerror" result. >> >> should also include "none". For some policy scenarios that would be >> considered a failure, so we ought to be able to express it. > > Maybe a simpler thing to say overall is: > > spf: The evaluation of the author domain's SPF record produced a failing > result, meaning either an actual SPF failure (e.g., "fail", "softfail", > "temperror", or "permerror") or any other result that was not acceptable > for local policy reasons. That may work for me. I'd keep it even more generic, e.g. spf: The evaluation of the author domain's SPF (or TXT) record produced a result that was not acceptable, unusual, or anyhow conspicuous under the provisions of the relevant reporting agreement. Either way, I think that can cover any future SPF extension as well. jm2c From msk@cloudmark.com Thu Jan 5 09:10:53 2012 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 D5AED21F87B9 for ; Thu, 5 Jan 2012 09:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 P2VSyp2LAB0k for ; Thu, 5 Jan 2012 09:10:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B00BD21F878E for ; Thu, 5 Jan 2012 09:10:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 09:10:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 5 Jan 2012 09:10:32 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 5 Jan 2012 09:10:30 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczLqaWGa4T39AEdSv+zpGhCXG8VRgAIwhfA Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <2663045.bBsYJTni1c@scott-latitude-e6320> <4F059E44.909@tana.it> In-Reply-To: <4F059E44.909@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 17:10:53 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, January 05, 2012 4:58 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > That may work for me. I'd keep it even more generic, e.g. >=20 > spf: The evaluation of the author domain's SPF (or TXT) record produced= a > result that was not acceptable, unusual, or anyhow conspicuous under= the > provisions of the relevant reporting agreement. Even simpler: spf: The evaluation of the author domain's SPF record produced something ot= her than a "pass" result, which the report generator considers to be a repo= rtable incident. This can include the usual set of failure results, or any= result that is considered a failure under local policy constraints. From sklist@kitterman.com Thu Jan 5 14:40:39 2012 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 CDD1021F88D1 for ; Thu, 5 Jan 2012 14:40:39 -0800 (PST) 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 fSd0Wwiie1gF for ; Thu, 5 Jan 2012 14:40:39 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8C21F88CE for ; Thu, 5 Jan 2012 14:40:39 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2FAF520E4100; Thu, 5 Jan 2012 17:40:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325803238; bh=Rlnx6Tp0Jqxy1IlGw8CMJS09pBg+z5BFo+vSfzGRXxU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Zd611A/b1TC3RFz1xwHhrgIRLCm4dABvB06+jAweWC6wCUV2p1lQ60uOsk9xSE6cU 8lSbYOdOFA/PpWD9evfCrB6qMH+SQR+I2PhDOSr87DofEcqS7SqV6kZZKIRQVVxWgN Ud3aceUjrnr54iGElwXWhxy1Xy3h/cD5Yqay/ZBM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 155DD20E4091; Thu, 5 Jan 2012 17:40:37 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 05 Jan 2012 17:40:37 -0500 Message-ID: <7257012.LKUiY3D6qM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <4F059E44.909@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 22:40:40 -0000 On Thursday, January 05, 2012 09:10:30 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Alessandro Vesely Sent: Thursday, January 05, 2012 4:58 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: > > draft-ietf-marf-authfailure-report-09.txt > > > > That may work for me. I'd keep it even more generic, e.g. > > > > spf: The evaluation of the author domain's SPF (or TXT) record > > produced a> > > result that was not acceptable, unusual, or anyhow conspicuous > > under the provisions of the relevant reporting agreement. > > Even simpler: > > spf: The evaluation of the author domain's SPF record produced something > other than a "pass" result, which the report generator considers to be a > reportable incident. This can include the usual set of failure results, or > any result that is considered a failure under local policy constraints. I think it's a mistake to report non-SPF results as SPF result. This includes policy overrides or the results of some hypothetical SPF extension. That the message is intended to communicate some kind of failure is implicit in the message type. The data element we are discussing is for SPF results and should only include those (and it should include all of them). Scott K From msk@cloudmark.com Thu Jan 5 14:58:22 2012 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 4562B21F88D6 for ; Thu, 5 Jan 2012 14:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 Q6vxyBv04+vU for ; Thu, 5 Jan 2012 14:58:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D755B21F88D3 for ; Thu, 5 Jan 2012 14:58:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 14:58:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 5 Jan 2012 14:58:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 5 Jan 2012 14:58:20 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczL+xG3dAjYt5BpRbKLZX0tNxjaHAAAcmRg Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <4F059E44.909@tana.it> <7257012.LKUiY3D6qM@scott-latitude-e6320> In-Reply-To: <7257012.LKUiY3D6qM@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 22:58:22 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Thursday, January 05, 2012 2:41 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > > spf: The evaluation of the author domain's SPF record produced > > something other than a "pass" result, which the report generator > > considers to be a reportable incident. This can include the usual set > > of failure results, or any result that is considered a failure under lo= cal policy constraints. >=20 > I think it's a mistake to report non-SPF results as SPF result. This > includes policy overrides or the results of some hypothetical SPF > extension. I'm specifically trying to enable your "none" case without calling it out, = because I don't want to have to add another non-pass code later. "pass" is= really the only case that isn't reportable, so the above language seems to= cover all the possibilities without enumerating them. > That the message is intended to communicate some kind of failure is > implicit in the message type. The data element we are discussing is > for SPF results and should only include those (and it should include > all of them). The data element we're talking about is the Auth-Failure field, which is on= ly used to indicate which module reported some kind of result that is repor= table. The specific result reported will be carried in the Authentication-= Results: field. From sklist@kitterman.com Thu Jan 5 15:07:50 2012 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 0A4B321F88A7 for ; Thu, 5 Jan 2012 15:07:50 -0800 (PST) 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 zVUtG7X3caiL for ; Thu, 5 Jan 2012 15:07:49 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB821F88A5 for ; Thu, 5 Jan 2012 15:07:49 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBA3F20E4100; Thu, 5 Jan 2012 18:07:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325804868; bh=peiA9eTG4AFYOKvcVDfZWwE0NEXNlR4Q84UNafKeFIc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=f2NzrBrYekCSatZ0BajU5HtTdICVILfCJ4sm56rI03XC8ih4RIo22XXH3/3lKvkal ZQiRj7nL8PibJF6arftXFDuu8nMbSgybJwg33CBoI7mIjvHbTw6BujpKvC6WxWwNjK ktNKlS3DJLoZDOUI2YUuUTjIGxtFoUuzNzF+t0ok= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD2CD20E4091; Thu, 5 Jan 2012 18:07:48 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 05 Jan 2012 18:07:48 -0500 Message-ID: <8096362.pfOZlslJ9Q@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <7257012.LKUiY3D6qM@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 23:07:50 -0000 On Thursday, January 05, 2012 02:58:20 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Thursday, January 05, 2012 2:41 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: > > draft-ietf-marf-authfailure-report-09.txt > > > > > spf: The evaluation of the author domain's SPF record produced > > > something other than a "pass" result, which the report generator > > > considers to be a reportable incident. This can include the usual > > > set > > > of failure results, or any result that is considered a failure under > > > local policy constraints.> > > I think it's a mistake to report non-SPF results as SPF result. This > > includes policy overrides or the results of some hypothetical SPF > > extension. > > I'm specifically trying to enable your "none" case without calling it out, > because I don't want to have to add another non-pass code later. "pass" is > really the only case that isn't reportable, so the above language seems to > cover all the possibilities without enumerating them. Except you've got all the other non-pass SPF results already, so the list would be complete (it's not an open ended list). It seems far simpler to me to add the one missing one than dance around it. Scott K From msk@cloudmark.com Thu Jan 5 15:10:06 2012 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 4FE0021F85A7 for ; Thu, 5 Jan 2012 15:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 gaaUgLy7VhEG for ; Thu, 5 Jan 2012 15:10:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 665E821F88A5 for ; Thu, 5 Jan 2012 15:10:01 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 15:09:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 5 Jan 2012 15:09:57 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 5 Jan 2012 15:09:56 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczL/to54qUWDFIDS7KWpcCFFiZOxgAAB9NQ Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <7257012.LKUiY3D6qM@scott-latitude-e6320> <8096362.pfOZlslJ9Q@scott-latitude-e6320> In-Reply-To: <8096362.pfOZlslJ9Q@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 23:10:06 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Thursday, January 05, 2012 3:08 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > Except you've got all the other non-pass SPF results already, so the list > would be complete (it's not an open ended list). It seems far simpler t= o me > to add the one missing one than dance around it. True, but that presumes the list will never be extended. You're more of an SPF expert than I am, so I'm happy to concede the point i= f you agree with that presumption. From sklist@kitterman.com Thu Jan 5 15:15:54 2012 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 CC95C21F88C3 for ; Thu, 5 Jan 2012 15:15:54 -0800 (PST) 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 x99mFRR4qp9w for ; Thu, 5 Jan 2012 15:15:54 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3067D21F88BE for ; Thu, 5 Jan 2012 15:15:54 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 76F6C20E4100; Thu, 5 Jan 2012 18:15:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325805353; bh=ysGrTYNs4jF6u8m+IgbSgz1smYzLsfi56lep0dzDal8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fCN/B5aJJe/XPL9Yy2lrc4EloDAx4Gb8pxu5rHmDlIrzuaUYX23l+59eF1KsfVL/K N5YZbf/L8kKA7DcCucgxYLzhiJJgIliPamMyCTJeM6LvTgnjJx8xRAzEBH5pCndDOZ ujXrvZ7qH4i5yYQnkNClIIhGH5PNeXospEw4QZsM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5CD0420E4091; Thu, 5 Jan 2012 18:15:53 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 05 Jan 2012 18:15:52 -0500 Message-ID: <73668038.9fhxNCgVWl@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <8096362.pfOZlslJ9Q@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 23:15:54 -0000 On Thursday, January 05, 2012 03:09:56 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Thursday, January 05, 2012 3:08 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: > > draft-ietf-marf-authfailure-report-09.txt > > > > Except you've got all the other non-pass SPF results already, so the > > list > > would be complete (it's not an open ended list). It seems far simpler > > to me to add the one missing one than dance around it. > > True, but that presumes the list will never be extended. > > You're more of an SPF expert than I am, so I'm happy to concede the point if > you agree with that presumption. Assuming (and I think it's a safe assumption) that SPFbis sticks with interoperability with current deployments as a goal, it can't change. Fundamentally, if the results codes codes change now, it's not really SPF v1 anymore. I think it's a safe presumption for the next 5 - 10 years and probably much longer. Scott K From msk@cloudmark.com Thu Jan 5 15:30:26 2012 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 B886C11E807A for ; Thu, 5 Jan 2012 15:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Qcipjjp81v8F for ; Thu, 5 Jan 2012 15:30:26 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F38F011E8071 for ; Thu, 5 Jan 2012 15:30:25 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 15:30:19 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 5 Jan 2012 15:30:25 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 5 Jan 2012 15:30:24 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt Thread-Index: AczL//wFKMj/d73sQyOJqCSFQxJp4gAAdiyQ Message-ID: References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <8096362.pfOZlslJ9Q@scott-latitude-e6320> <73668038.9fhxNCgVWl@scott-latitude-e6320> In-Reply-To: <73668038.9fhxNCgVWl@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] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 23:30:26 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Thursday, January 05, 2012 3:16 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt >=20 > Assuming (and I think it's a safe assumption) that SPFbis sticks with > interoperability with current deployments as a goal, it can't change. > Fundamentally, if the results codes codes change now, it's not really > SPF v1 anymore. I think it's a safe presumption for the next 5 - 10 > years and probably much longer. Then how about: spf: The evaluation of the author domain's SPF record produced a "none", "f= ail", "softfail", "temperror" or "permerror" result. ("none" is not strict= ly a failure per [SPF], but a service that demands successful SPF evaluatio= ns of clients could treat it like a failure.) ? From sklist@kitterman.com Thu Jan 5 15:37:05 2012 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 E6C9321F88F5 for ; Thu, 5 Jan 2012 15:37:05 -0800 (PST) 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 6dMweIH+pcsU for ; Thu, 5 Jan 2012 15:37:03 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id AB3F721F88F9 for ; Thu, 5 Jan 2012 15:37:03 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 75F0FD04082; Thu, 5 Jan 2012 17:37:02 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325806622; bh=98BU26DCPQQuE/nkHxH9aix0avlmSsaJAttE38I3uTY=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=njFSwc5hyik9RVNWfMKf/43PFZGz4gHgNDP0IoJ4uZaOzkRk6+kx3zULbGhtm902U OtjUwNC8/qmUS2H9E42iZ86yRpQt50fXGTaQ7yPejo9J/DFmF1IeXgcrJlgYoaaRkP kWJTb2DIfOgTeAJV8089kZbPtyWV0WJDtXXvIurw= Received: from 101.sub-97-10-203.myvzw.com (101.sub-97-10-203.myvzw.com [97.10.203.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D109FD04026; Thu, 5 Jan 2012 17:37:01 -0600 (CST) References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <8096362.pfOZlslJ9Q@scott-latitude-e6320> <73668038.9fhxNCgVWl@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 05 Jan 2012 18:37:10 -0500 To: "marf@ietf.org" Message-ID: <91c0e83c-655b-4c77-b357-6348788874c1@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 05 Jan 2012 23:37:06 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of >> Scott Kitterman >> Sent: Thursday, January 05, 2012 3:16 PM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: >draft-ietf-marf-authfailure-report-09.txt >> >> Assuming (and I think it's a safe assumption) that SPFbis sticks with >> interoperability with current deployments as a goal, it can't change. >> Fundamentally, if the results codes codes change now, it's not really >> SPF v1 anymore. I think it's a safe presumption for the next 5 - 10 >> years and probably much longer. > >Then how about: > >spf: The evaluation of the author domain's SPF record produced a >"none", "fail", "softfail", "temperror" or "permerror" result. ("none" >is not strictly a failure per [SPF], but a service that demands >successful SPF evaluations of clients could treat it like a failure.) > >? Looks good. Thanks, Scott K From hfontana@ecertsystems.com Thu Jan 5 20:26:00 2012 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 4A8DE21F878E for ; Thu, 5 Jan 2012 20:26:00 -0800 (PST) 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 edyJDWUsUAXf for ; Thu, 5 Jan 2012 20:25:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94AC021F8780 for ; Thu, 5 Jan 2012 20:25:59 -0800 (PST) Received: by iabz21 with SMTP id z21so2168005iab.31 for ; Thu, 05 Jan 2012 20:25:59 -0800 (PST) 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=jRRmZklpxQ1UnUqzI7uG88qwlrQWC6OTubSoEtBmUws=; b=eoumynM6Wy+tb1GXNF71+KOCnzmX7HGI4abLJbqaISDJSvzWmb6u6MZm9b7MpxaSGr 2+dPLy0VXg4EXLch1DlgWsFg0QXHHLk0kj0BnqLh9xscQTyQ/2hjluGZU+FZrtf1os3C EyelZIjnlnsOUgrh23I6hemCwNgoLM8oe/PYo= Received: by 10.50.106.201 with SMTP id gw9mr6129941igb.17.1325823959240; Thu, 05 Jan 2012 20:25:59 -0800 (PST) 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 lu10sm105628119igc.0.2012.01.05.20.25.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 20:25:58 -0800 (PST) References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <8096362.pfOZlslJ9Q@scott-latitude-e6320> <73668038.9fhxNCgVWl@scott-latitude-e6320> <91c0e83c-655b-4c77-b357-6348788874c1@email.android.com> In-Reply-To: <91c0e83c-655b-4c77-b357-6348788874c1@email.android.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <3BF08A26-3C8E-4B2E-867E-8BB573E1208B@ecertsystems.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (9A405) From: Hfontana Date: Thu, 5 Jan 2012 20:25:53 -0800 To: Scott Kitterman , "hilda@hfontana.com" Cc: "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 06 Jan 2012 04:26:00 -0000 On Jan 5, 2012, at 3:37 PM, Scott Kitterman wrote: > > > "Murray S. Kucherawy" wrote: > >>> -----Original Message----- >>> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >> Of >>> Scott Kitterman >>> Sent: Thursday, January 05, 2012 3:16 PM >>> To: marf@ietf.org >>> Subject: Re: [marf] I-D Action: >> draft-ietf-marf-authfailure-report-09.txt >>> >>> Assuming (and I think it's a safe assumption) that SPFbis sticks with >>> interoperability with current deployments as a goal, it can't change. >>> Fundamentally, if the results codes codes change now, it's not really >>> SPF v1 anymore. I think it's a safe presumption for the next 5 - 10 >>> years and probably much longer. >> >> Then how about: >> >> spf: The evaluation of the author domain's SPF record produced a >> "none", "fail", "softfail", "temperror" or "permerror" result. ("none" >> is not strictly a failure per [SPF], but a service that demands >> successful SPF evaluations of clients could treat it like a failure.) >> >> ? > > Looks good. > > Thanks, > > Scott K +1 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Fri Jan 6 12:59:48 2012 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 08A6E21F876D for ; Fri, 6 Jan 2012 12:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, 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 WKSBLJz91T65 for ; Fri, 6 Jan 2012 12:59:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E941B21F8758 for ; Fri, 6 Jan 2012 12:59:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 6 Jan 2012 12:59:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 6 Jan 2012 12:59:46 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 6 Jan 2012 12:59:45 -0800 Thread-Topic: Use of hashes in draft-ietf-marf-redaction Thread-Index: AczMth6cf7mKZqPFRV2JRYhIiAbxLw== 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_F5833273385BB34F99288B3648C4F06F19C6C15781EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Use of hashes in draft-ietf-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: Fri, 06 Jan 2012 20:59:48 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15781EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The redaction and authfailure-report documents are now in their second IETF= Last Calls. So far, so good. We can expect a comment from the IESG wondering why in the redaction docume= nt we didn't specify a particular hash algorithm. My reply so far (i.e., i= nformally) is that it's not necessary. The agent generating the reports ca= n select whatever hash it wants to use; if it's willing to risk collisions = at the cost of cheaper processing, it can pick the weaker hashes. If it's = satisfied with ROT13, it could even use that. The point here is to obscure= the original string to the satisfaction of the report generator while allo= wing the report receiver to observe that multiple reports are referring to = the same end user. The report receiver can then apply whatever tricks it w= ants to use to track the report back to the offending user once it gets a c= ollection of such reports. Basically, the usual concerns about a collision= attack don't apply to this use of hashes since the same party that produce= s the hashes also consumes them. So two questions: 1) Is that a reasonable reply? 2) Should the above be added as an Appendix? The AD I spoke to seems happy with this, and suggests that adding such text= would help but it's not strictly necessary. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15781EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The redaction an= d authfailure-report documents are now in their second IETF Last Calls.&nbs= p; So far, so good.

 

We can expect a comment from the IESG wondering why i= n the redaction document we didn’t specify a particular hash algorith= m.  My reply so far (i.e., informally) is that it’s not necessar= y.  The agent generating the reports can select whatever hash it wants= to use; if it’s willing to risk collisions at the cost of cheaper pr= ocessing, it can pick the weaker hashes.  If it’s satisfied with= ROT13, it could even use that.  The point here is to obscure the orig= inal string to the satisfaction of the report generator while allowing the = report receiver to observe that multiple reports are referring to the same = end user.  The report receiver can then apply whatever tricks it wants= to use to track the report back to the offending user once it gets a colle= ction of such reports.  Basically, the usual concerns about a collisio= n attack don’t apply to this use of hashes since the same party that = produces the hashes also consumes them.

=  

So two questions:

1) Is th= at a reasonable reply?

 =

2) Should the above be added as an Appendix?<= /o:p>

 

The= AD I spoke to seems happy with this, and suggests that adding such text wo= uld help but it’s not strictly necessary.

 

-MSK

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15781EXCHC2corpclo_-- From johnl@iecc.com Fri Jan 6 15:12:07 2012 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 9874021F860D for ; Fri, 6 Jan 2012 15:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.604 X-Spam-Level: X-Spam-Status: No, score=-105.604 tagged_above=-999 required=5 tests=[AWL=-3.005, 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 Aqfo64YiDPkO for ; Fri, 6 Jan 2012 15:12:07 -0800 (PST) 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 02F4D21F85CE for ; Fri, 6 Jan 2012 15:12:06 -0800 (PST) Received: (qmail 63396 invoked from network); 6 Jan 2012 23:12:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jan 2012 23:12:05 -0000 Date: 6 Jan 2012 23:11:43 -0000 Message-ID: <20120106231143.54285.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] Use of hashes in draft-ietf-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: Fri, 06 Jan 2012 23:12:07 -0000 > Basically, the usual concerns about a collision attack don't apply to this > use of hashes since the same party that produces the hashes also consumes them. Right. A spec like this needs to define the parameters needed to interoperate, and the hash isn't one of them. Also, anyone who spends five seconds thinking about the threat model should realize that people will reverse engineer the hashed names by using other info about the messages to figure out what message was sent to whom, and anything that isn't trivially reversible (sorry, rot13) is adequate. >1) Is that a reasonable reply? Yes. >2) Should the above be added as an Appendix? Don't see why. Perhaps we could do a separate BCP called something like "Excessive preoccupation with low level technical nits considered harmful." R's, John From vesely@tana.it Sat Jan 7 03:57:11 2012 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 0B1AA21F8563 for ; Sat, 7 Jan 2012 03:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 wgjSXBn19XHF for ; Sat, 7 Jan 2012 03:57:10 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3C21F855E for ; Sat, 7 Jan 2012 03:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325937428; bh=xJPmgHFisjf43I2iO87Y81GFSpLk3bp17p3MsDq4sEk=; l=1547; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MV49Z9GPydKSQt13Gy7whxYfsxLrB/SrmA7iDEC6TwITEGvOfJBaZSgMFtcv6uieN ENb+/k/oVLDAvKM4388Eenru03gHke+OyKEwm7TPRozmWu0oekGI8TSMzg7OiSy5y8 EHgwDVGFfhpHndgh+0+FG8apQrxgA7jJX9QYyOOQ= 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, 07 Jan 2012 12:57:08 +0100 id 00000000005DC039.000000004F083314.000012BB Message-ID: <4F083313.8070804@tana.it> Date: Sat, 07 Jan 2012 12:57:07 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20120104224301.27158.77714.idtracker@ietfa.amsl.com> <8096362.pfOZlslJ9Q@scott-latitude-e6320> <73668038.9fhxNCgVWl@scott-latitude-e6320> <91c0e83c-655b-4c77-b357-6348788874c1@email.android.com> In-Reply-To: <91c0e83c-655b-4c77-b357-6348788874c1@email.android.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.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, 07 Jan 2012 11:57:11 -0000 On 06/Jan/12 00:37, Scott Kitterman wrote: > "Murray S. Kucherawy" wrote: >> >>> Assuming (and I think it's a safe assumption) that SPFbis sticks with >>> interoperability with current deployments as a goal, it can't change. Julian's SPF scope adds no results, but I think they'll have to be reported with a different method. For a shot in the dark: Authentication-Results: authserv-id.example; spf=pass smtp.mailfrom=example.org; spf-scope=fail scope-id=hdr-from header.from=example.com To clarify, spf-scope would have to be registered at IANA's for the above to be correct. By contrast, the values of the Auth-Failure field, such as the "spf" we're talking about, don't have a IANA register. >>Then how about: >> >>spf: The evaluation of the author domain's SPF record produced a >>"none", "fail", "softfail", "temperror" or "permerror" result. ("none" >>is not strictly a failure per [SPF], but a service that demands >>successful SPF evaluations of clients could treat it like a failure.) >> >>? > > Looks good. I liked better Murray's previous text. This one is acceptable as long as it doesn't imply that "SPF evaluations" have to be carried out according to [SPF] only. Thus a report could set the following in its 2nd part: Feedback-Type: auth-failure Auth-Failure: spf Authentication-Results: authserv-id.example; spf-scope=fail scope-id=hdr-from header.from=example.com (Note that the value "spf" is in a different field than keywords listed in its definition.) From vesely@tana.it Sat Jan 7 04:28:19 2012 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 09CEB21F84B5 for ; Sat, 7 Jan 2012 04:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=0.132, 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 EatpULMRwaQg for ; Sat, 7 Jan 2012 04:28:18 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3F25421F8496 for ; Sat, 7 Jan 2012 04:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325939297; bh=RJ2RZrXYcHaw9MGiScclENrtrhj5qHWvk4V0l3vZW5E=; l=686; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IQ6J+e5PVYi4JMv5NGgHnCE6mQanR/n9+oV5Fr3oCa7D/NzZKDD6YgZD8saVE6OJ8 GOo9jP00c+XOVGwBGaaUx/kSEi3mi9nTZoParrvjMffm7vAOWhUDtC7NVO32QOO2pQ ZTmB76c77MXb58eKZKdDAu0PVRFl4T7rhsfarvXQ= 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, 07 Jan 2012 13:28:17 +0100 id 00000000005DC035.000000004F083A61.0000199D Message-ID: <4F083A60.8070102@tana.it> Date: Sat, 07 Jan 2012 13:28:16 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Use of hashes in draft-ietf-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: Sat, 07 Jan 2012 12:28:19 -0000 On 06/Jan/12 21:59, Murray S. Kucherawy wrote: > > The point here is to obscure the original string to the > satisfaction of the report generator while allowing the report > receiver to observe that multiple reports are referring to the > same end user. Yes, indeed ARF recommends the /identity hash/ --that replaces a string with itself. SHA1 is exemplified in Appendix A, anyway. > Basically, the usual concerns about a collision attack don’t apply > to this use of hashes since the same party that produces the hashes > also consumes them. Replacing a string with "xxxxxxxx" gives better protection by preventing any correlation. That has a 100% collision rate. From shmuel+gen@patriot.net Sat Jan 7 15:14:10 2012 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 1800F21F84AE for ; Sat, 7 Jan 2012 15:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_40=-0.185] 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 zNxeBzzK7Bmw for ; Sat, 7 Jan 2012 15:14:09 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 811E521F8455 for ; Sat, 7 Jan 2012 15:14:09 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.235]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id F013DF5808C for ; Sat, 7 Jan 2012 18:00:26 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 07 Jan 2012 17:47:08 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120107230027.F013DF5808C@smtp.patriot.net> Subject: Re: [marf] Use of hashes in draft-ietf-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: Sat, 07 Jan 2012 23:14:10 -0000 In , on 01/06/2012 at 12:59 PM, "Murray S. Kucherawy" said: >So two questions: >1) Is that a reasonable reply? Yes. The question of specifying a particular hash has been hashed to death here, and the consensus seems clear. >2) Should the above be added as an Appendix? Yes. -- 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 david.black@emc.com Tue Jan 10 18:44:43 2012 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 231A321F847C; Tue, 10 Jan 2012 18:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KfruPwjNhBJW; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3E21F8499; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iWxI019520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 21:44:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 10 Jan 2012 21:44:19 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iIN1003220; Tue, 10 Jan 2012 21:44:18 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Tue, 10 Jan 2012 21:44:18 -0500 From: To: , , , Date: Tue, 10 Jan 2012 21:44:16 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 10 Jan 2012 19:49:36 -0800 Cc: presnick@qualcomm.com, david.black@emc.com, marf@ietf.org Subject: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 02:44:43 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in= the review. This draft specifies a method for redacting information from email abuse re= ports (e.g., hiding the local part [user] of an email address), while still allow= ing correlation of the redacted information across related abuse reports from t= he same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that= this redaction technique effectively hides the redacted information. The redact= ion technique is to concatenate a secret string (called the "redaction key") to= the information to be redacted, apply "any hashing/digest algorithm", convert t= he output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectiv= ely hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string ("redaction key") consists= of a single ASCII character, and a short email local part is being redacted, the= n the output is highly vulnerable to dictionary and brute force attacks because o= nly 6 bits of entropy are added (the result may look secure, but it's not). Beyond th= is extreme example, this is a potentially real concern - e.g., applying the rule of th= umb that ASCII text contains 4-5 bits of entropy per character, the example in Appen= dix A uses a "redaction key" of "potatoes" that injects at most 40 bits of entrop= y - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of sho= rt input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change "any hashing/digest algorithm" to require use of a secure hash, a= nd explain what is meant by "secure hash" in the security considerations sect= ion. 2) Require a minimum length of the "redaction key" string, and strongly sug= gest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printa= ble ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significan= tly less). >From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the "redaction key" down to a bina= ry key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopt= ing it. [2] The second open issue is absence of security considerations for the red= action key. The security considerations section needs to caution that the redacti= on key is a secret key that must be managed and protected as a secret key. Disclo= sure of a redaction key removes the redaction from all reports that used that ke= y. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that "anonymization" is a better description of wh= at this draft is doing (as opposed to "redaction"), particularly as the result= is intended to be correlatable via string match across reports from the same s= ource. idnits 2.12.13 didn't find any nits. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From johnl@iecc.com Tue Jan 10 20:38:27 2012 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 F078B11E808A for ; Tue, 10 Jan 2012 20:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.435 X-Spam-Level: X-Spam-Status: No, score=-104.435 tagged_above=-999 required=5 tests=[AWL=-1.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 dDT8UKJSzOZX for ; Tue, 10 Jan 2012 20:38:26 -0800 (PST) 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 4FD0211E8080 for ; Tue, 10 Jan 2012 20:38:26 -0800 (PST) Received: (qmail 95435 invoked from network); 11 Jan 2012 04:38:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Jan 2012 04:38:25 -0000 Date: 11 Jan 2012 04:38:02 -0000 Message-ID: <20120111043802.89674.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: david.black@emc.com Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 04:38:27 -0000 >Please resolve these comments along with any other Last Call comments you may receive. Hi. I'm not one of the authors, but these issues have come up before. >There are two important ways in which this technique could fail to effectively hide >the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. Not really. These are feedback reports, in which a recipient system is sending back complaints that include copies of mail to the system that originally sent it. Any sender that keeps logs of outgoing mail, which is all of them these days, need only use the time stamps and sequence numbers in the headers, or any other per-recipient data in the header or body of the message, to look it up in their own logs to see who they sent it to. This is a fundamental limitation of feedback reports. I can tell you from experience that I've done this to figure out who to take off a list when their ISP tries to redact the complaint, and it's not hard. So in practice, even if the hash were extremely weak, nobody would care because there are easier ways to recover the address. Complaint reporting systems like Spamcop have been trying for years to redact complaints enough that senders can't "listwash" (remove complainers from spam lists), and experience has shown that it's basically impossible. This hack is really just to make life a little easier for senders who track complaint rates by recipient or recipient system, since 1 complaint each from N people means something different than N complaints from one person. It sounds like the security considerations didn't explain this adequately. Perhaps it would be better to fix the document to explain more clearly why redaction is fundamentally weak rather than to worry about what's akin to a steel lock on a cardboard box. R's, John From msk@cloudmark.com Tue Jan 10 20:40:45 2012 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 28D2F11E808A; Tue, 10 Jan 2012 20:40:45 -0800 (PST) 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 R2PyupSmiN2N; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA311E8080; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 20:40:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 20:40:43 -0800 From: "Murray S. Kucherawy" To: "david.black@emc.com" , "ietf@cybernothing.org" , "gen-art@ietf.org" , "ietf@ietf.org" Date: Tue, 10 Jan 2012 20:40:42 -0800 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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 Cc: "presnick@qualcomm.com" , "marf@ietf.org" Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 04:40:45 -0000 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Tuesday, January 10, 2012 6:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. > [1] The first open issue is the absence of security guidance to ensure th= at this > redaction technique effectively hides the redacted information. The reda= ction > technique is to concatenate a secret string (called the "redaction key") = to the > information to be redacted, apply "any hashing/digest algorithm", convert= the output > to base64 and use that base64 string to replace the redacted information. > [...] >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash,= and > explain what is meant by "secure hash" in the security considerations se= ction. > 2) Require a minimum length of the "redaction key" string, and strongly s= uggest > (SHOULD) that it be randomly generated (e.g., by running sufficient outp= ut > of an entropy-rich random number generator through a base64 converter). >=20 > For the latter change, figure out the amount of entropy that should be us= ed > for redaction - the recommended string length will be larger because prin= table > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in ea= ch > 8-bit character, and human-written text such as this message has signific= antly > less). >=20 > From a pure security perspective, use of HMAC with specified secure hashe= s > (SHA2-family) and an approach of hashing the "redaction key" down to a bi= nary > key for HMAC would be a stronger approach. I suggest that authors conside= r > approach, but there may be practical usage concerns that suggest not > adopting it. These are all good points. My gut reaction is to say that this is all good= advice and entirely correct but probably goes a little far for the problem= space we're trying to address. Thus, my inclination is to make the follow= ing changes (subject to WG consensus): - add all of this advice to Security Considerations, with forward reference= s to it elsewhere in the document - make a SHOULD suggestion as to the minimum redaction key length (instead = of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a = requirement) Would those be sufficient? > [2] The second open issue is absence of security considerations for the r= edaction > key. The security considerations section needs to caution that the redac= tion key > is a secret key that must be managed and protected as a secret key. > Disclosure of a redaction key removes the redaction from all reports that= used > that key. As part of this, guidance should be provided on when and how to= change > the redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Also a good point. I don't think this is the right place to introduce advi= ce about key rotation and the like as those are well-discussed concepts, so= instead Security Considerations can simply make reference to such material= elsewhere. I'll go find some. I know there's stuff like that in RFC6376 = (DKIM) but I'm sure there are better ones. > Editorial Nit: I believe that "anonymization" is a better description of = what > this draft is doing (as opposed to "redaction"), particularly as the resu= lt is > intended to be correlatable via string match across reports from the > same source. Fair enough. We can add a sentence to that effect in the Introduction. To the MARF working group: Please let me know if the above suggestions suff= ice (reply only to the marf list, please). I will summarize and have a new= version ready to publish when LC closes, and make sure David sees it aroun= d the same time. -MSK From sklist@kitterman.com Tue Jan 10 20:57:22 2012 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 B34C61F0C3E for ; Tue, 10 Jan 2012 20:57:22 -0800 (PST) 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 LAxZ3aK3wEEG for ; Tue, 10 Jan 2012 20:57:22 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 005631F0C36 for ; Tue, 10 Jan 2012 20:57:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F30D820E410A; Tue, 10 Jan 2012 23:57:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326257840; bh=VV1gLWiohwTtfsdB07aanDGA/eHA99viuh6Va8P6oqM=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=WZugu1Ng7SwxQnzmY7xIaiSdiNmbiwCSZM+cyL90wodVZYZ2peAGUyzYwWzIJqd7s fprZAdMcazdwA9/6pAeVw2jgQ7WZuXPIY0p5DisUgn/nBxlKN/jJQKIYGXxOOrXbvZ btmyC4blgqhRfcDUT+gG1RwhpFvC0mCvYpxiqv68= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD3B620E409F; Tue, 10 Jan 2012 23:57:19 -0500 (EST) From: Scott Kitterman To: "marf@ietf.org" Date: Tue, 10 Jan 2012 23:57:18 -0500 Message-ID: <1724639.H4nc38FoQx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] Authentication Results module for Python 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, 11 Jan 2012 04:57:22 -0000 I don't remember if I've mentioned this before (sorry if this is a duplicate), but there is a Python module available for generating and parsing A-R headers per RFC 5451, see https://launchpad.net/pypolicyd-spf . If you're doing a project that needs A-R in Python, hopefully this will make life easier. Scott K From msk@cloudmark.com Tue Jan 10 21:30:14 2012 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 9F63121F847C for ; Tue, 10 Jan 2012 21:30:14 -0800 (PST) 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 6l8Znr7pgXdj for ; Tue, 10 Jan 2012 21:30:13 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D76521F847B for ; Tue, 10 Jan 2012 21:30:13 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 21:30:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 21:30:12 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 10 Jan 2012 21:30:11 -0800 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQAFuexg Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 05:30:14 -0000 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Tuesday, January 10, 2012 6:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; > ietf@ietf.org > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. > [...] John and I collaborated on the following edits. Please indicate whether or= not you approve, and suggest any adjustments needed. I'll include them in= a revision right after IETF LC closes. http://www.blackops.org/~msk/marf.html -MSK From sklist@kitterman.com Tue Jan 10 21:37:39 2012 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 DD37C11E8097 for ; Tue, 10 Jan 2012 21:37:38 -0800 (PST) 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 PCmA9P7O+bkd for ; Tue, 10 Jan 2012 21:37:37 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 95CC711E8094 for ; Tue, 10 Jan 2012 21:37:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1C38320E410A; Wed, 11 Jan 2012 00:37:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326260257; bh=BcFl/0NI0g5Oqh2AP+7OHN+0ci7UN8KWXvmRQTE5KR0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ciQ7SO7PpJoGzcBAMPRyvvti7nmB0iMWaGoe7eL1VhtffQ2BvS5WEGwN5qVIiiPkF jqlck3wCE4zOZIu22lAveESgNO5TT6GjBMJl/Kp4P5rLKqpl/sohqPCE/NyJ11kvLq 7Ztw2xn4Et5W2mAspTi+SclbtsnsRI8AVQ04/6oI= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DFBC920E409F; Wed, 11 Jan 2012 00:37:36 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 11 Jan 2012 00:37:35 -0500 Message-ID: <1796323.RCyXJjPkHT@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 05:37:39 -0000 On Tuesday, January 10, 2012 09:30:11 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Tuesday, January 10, 2012 6:44 PM > > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; > > ietf@ietf.org > > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > > Subject: Gen-ART review of draft-ietf-marf-redaction-04 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > [...] > > John and I collaborated on the following edits. Please indicate whether or > not you approve, and suggest any adjustments needed. I'll include them in > a revision right after IETF LC closes. > > http://www.blackops.org/~msk/marf.html Looks good to me. Scott K From david.black@emc.com Tue Jan 10 22:57:00 2012 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 1D1E821F8823 for ; Tue, 10 Jan 2012 22:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3xN1z0UO3HcZ for ; Tue, 10 Jan 2012 22:56:59 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9B21F8776 for ; Tue, 10 Jan 2012 22:56:58 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B6uveE009087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 01:56:57 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 01:56:51 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B6uo9O008990; Wed, 11 Jan 2012 01:56:50 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Wed, 11 Jan 2012 01:56:50 -0500 From: To: , Date: Wed, 11 Jan 2012 01:56:48 -0500 Thread-Topic: [marf] Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQGwKoiiwqbdXdT1+tKDZuTmOPUwAEmBnQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D8A@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <20120111043802.89674.qmail@joyce.lan> In-Reply-To: <20120111043802.89674.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 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 11 Jan 2012 05:28:46 -0800 Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 06:57:00 -0000 SGkgSm9obiwNCg0KPiBIaS4gIEknbSBub3Qgb25lIG9mIHRoZSBhdXRob3JzLCBidXQgdGhlc2Ug aXNzdWVzIGhhdmUgY29tZSB1cCBiZWZvcmUuDQoNClRoYW5rIHlvdSAtIEkgYXBwcmVjaWF0ZSB0 aGUgYWRkaXRpb25hbCBleHBsYW5hdGlvbiBhbmQgY29udGV4dC4NCg0KPiBJdCBzb3VuZHMgbGlr ZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlkbid0IGV4cGxhaW4gdGhpcw0KPiBhZGVx dWF0ZWx5LiAgUGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZml4IHRoZSBkb2N1bWVudCB0 byBleHBsYWluDQo+IG1vcmUgY2xlYXJseSB3aHkgcmVkYWN0aW9uIGlzIGZ1bmRhbWVudGFsbHkg d2Vhaw0KDQpUaGF0IHdvdWxkIGRlZmluaXRlbHkgYmUgdXNlZnVsLCBhcyBJIGRpZG4ndCBmaW5k IGVub3VnaCBpbmZvcm1hdGlvbiBpbiB0aGUNCmRyYWZ0IHRvIGhlbHAgbWUgdW5kZXJzdGFuZCB3 aGF0IGxldmVsIG9mIHNlY3VyaXR5IGlzIGFwcHJvcHJpYXRlIGFuZCB3aHkuDQoNCj4gdG8gZXhw bGFpbg0KPiBtb3JlIGNsZWFybHkgd2h5IHJlZGFjdGlvbiBpcyBmdW5kYW1lbnRhbGx5IHdlYWsg cmF0aGVyIHRoYW4gdG8gd29ycnkNCj4gYWJvdXQgd2hhdCdzIGFraW4gdG8gYSBzdGVlbCBsb2Nr IG9uIGEgY2FyZGJvYXJkIGJveC4NCg0KQXMgSSBub3RlZCBpbiB0aGUgcmV2aWV3LCB0aGUgSE1B QyBtZWNoYW5pc20gbWF5IG5vdCBiZSBhcHByb3ByaWF0ZSwgYnV0DQpJIGRvIHRoaW5rIHRoYXQg c29tZSBvZiB0aGUgZHJhZnQgY29udGVudCBvdWdodCB0byBiZSBzdHJlbmd0aGVuZWQgdG8gcHJv aGliaXQNCmNsZWFybHkgd3JvbmcgdGhpbmdzIHN1Y2ggYXMgdGhlIHR3byBleGFtcGxlcyBpbiB0 aGUgcmV2aWV3ICgiYSIgYXMgcmVkYWN0aW9uDQprZXksIENSQyBhcyBoYXNoL2RpZ2VzdCkuDQoN ClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBKb2huIExldmluZSBbbWFpbHRvOmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVHVlc2RheSwg SmFudWFyeSAxMCwgMjAxMiAxMTozOCBQTQ0KPiBUbzogbWFyZkBpZXRmLm9yZw0KPiBDYzogQmxh Y2ssIERhdmlkDQo+IFN1YmplY3Q6IFJlOiBbbWFyZl0gR2VuLUFSVCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1tYXJmLXJlZGFjdGlvbi0wNA0KPiANCj4gPlBsZWFzZSByZXNvbHZlIHRoZXNlIGNvbW1l bnRzIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB5b3UgbWF5IHJlY2Vp dmUuDQo+IA0KPiBIaS4gIEknbSBub3Qgb25lIG9mIHRoZSBhdXRob3JzLCBidXQgdGhlc2UgaXNz dWVzIGhhdmUgY29tZSB1cCBiZWZvcmUuDQo+IA0KPiA+VGhlcmUgYXJlIHR3byBpbXBvcnRhbnQg d2F5cyBpbiB3aGljaCB0aGlzIHRlY2huaXF1ZSBjb3VsZCBmYWlsIHRvIGVmZmVjdGl2ZWx5IGhp ZGUNCj4gPnRoZSByZWRhY3RlZCBpbmZvcm1hdGlvbjoNCj4gPgktIFRoZSBzZWNyZXQgc3RyaW5n IG1heSBpbmplY3QgaW5zdWZmaWNpZW50IGVudHJvcHkuDQo+ID4JLSBUaGUgaGFzaGluZy9kaWdl c3QgYWxnb3JpdGhtIG1heSBiZSB3ZWFrLg0KPiANCj4gTm90IHJlYWxseS4gIFRoZXNlIGFyZSBm ZWVkYmFjayByZXBvcnRzLCBpbiB3aGljaCBhIHJlY2lwaWVudCBzeXN0ZW0NCj4gaXMgc2VuZGlu ZyBiYWNrIGNvbXBsYWludHMgdGhhdCBpbmNsdWRlIGNvcGllcyBvZiBtYWlsIHRvIHRoZSBzeXN0 ZW0NCj4gdGhhdCBvcmlnaW5hbGx5IHNlbnQgaXQuICBBbnkgc2VuZGVyIHRoYXQga2VlcHMgbG9n cyBvZiBvdXRnb2luZyBtYWlsLA0KPiB3aGljaCBpcyBhbGwgb2YgdGhlbSB0aGVzZSBkYXlzLCBu ZWVkIG9ubHkgdXNlIHRoZSB0aW1lIHN0YW1wcyBhbmQNCj4gc2VxdWVuY2UgbnVtYmVycyBpbiB0 aGUgaGVhZGVycywgb3IgYW55IG90aGVyIHBlci1yZWNpcGllbnQgZGF0YSBpbg0KPiB0aGUgaGVh ZGVyIG9yIGJvZHkgb2YgdGhlIG1lc3NhZ2UsIHRvIGxvb2sgaXQgdXAgaW4gdGhlaXIgb3duIGxv Z3MgdG8NCj4gc2VlIHdobyB0aGV5IHNlbnQgaXQgdG8uICBUaGlzIGlzIGEgZnVuZGFtZW50YWwg bGltaXRhdGlvbiBvZiBmZWVkYmFjaw0KPiByZXBvcnRzLg0KPiANCj4gSSBjYW4gdGVsbCB5b3Ug ZnJvbSBleHBlcmllbmNlIHRoYXQgSSd2ZSBkb25lIHRoaXMgdG8gZmlndXJlIG91dCB3aG8NCj4g dG8gdGFrZSBvZmYgYSBsaXN0IHdoZW4gdGhlaXIgSVNQIHRyaWVzIHRvIHJlZGFjdCB0aGUgY29t cGxhaW50LCBhbmQNCj4gaXQncyBub3QgaGFyZC4gIFNvIGluIHByYWN0aWNlLCBldmVuIGlmIHRo ZSBoYXNoIHdlcmUgZXh0cmVtZWx5IHdlYWssDQo+IG5vYm9keSB3b3VsZCBjYXJlIGJlY2F1c2Ug dGhlcmUgYXJlIGVhc2llciB3YXlzIHRvIHJlY292ZXIgdGhlDQo+IGFkZHJlc3MuICBDb21wbGFp bnQgcmVwb3J0aW5nIHN5c3RlbXMgbGlrZSBTcGFtY29wIGhhdmUgYmVlbiB0cnlpbmcNCj4gZm9y IHllYXJzIHRvIHJlZGFjdCBjb21wbGFpbnRzIGVub3VnaCB0aGF0IHNlbmRlcnMgY2FuJ3QgImxp c3R3YXNoIg0KPiAocmVtb3ZlIGNvbXBsYWluZXJzIGZyb20gc3BhbSBsaXN0cyksIGFuZCBleHBl cmllbmNlIGhhcyBzaG93biB0aGF0DQo+IGl0J3MgYmFzaWNhbGx5IGltcG9zc2libGUuDQo+IA0K PiBUaGlzIGhhY2sgaXMgcmVhbGx5IGp1c3QgdG8gbWFrZSBsaWZlIGEgbGl0dGxlIGVhc2llciBm b3Igc2VuZGVycyB3aG8NCj4gdHJhY2sgY29tcGxhaW50IHJhdGVzIGJ5IHJlY2lwaWVudCBvciBy ZWNpcGllbnQgc3lzdGVtLCBzaW5jZSAxDQo+IGNvbXBsYWludCBlYWNoIGZyb20gTiBwZW9wbGUg bWVhbnMgc29tZXRoaW5nIGRpZmZlcmVudCB0aGFuIE4NCj4gY29tcGxhaW50cyBmcm9tIG9uZSBw ZXJzb24uDQo+IA0KPiBJdCBzb3VuZHMgbGlrZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg ZGlkbid0IGV4cGxhaW4gdGhpcw0KPiBhZGVxdWF0ZWx5LiAgUGVyaGFwcyBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gZml4IHRoZSBkb2N1bWVudCB0byBleHBsYWluDQo+IG1vcmUgY2xlYXJseSB3aHkg cmVkYWN0aW9uIGlzIGZ1bmRhbWVudGFsbHkgd2VhayByYXRoZXIgdGhhbiB0byB3b3JyeQ0KPiBh Ym91dCB3aGF0J3MgYWtpbiB0byBhIHN0ZWVsIGxvY2sgb24gYSBjYXJkYm9hcmQgYm94Lg0KPiAN Cj4gUidzLA0KPiBKb2huDQoNCg== From david.black@emc.com Tue Jan 10 23:38:58 2012 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 98A1A21F884A; Tue, 10 Jan 2012 23:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hVL1roMscuMS; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AA66921F8846; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cksC029723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 02:38:47 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 02:38:33 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cTgd021556; Wed, 11 Jan 2012 02:38:29 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 11 Jan 2012 02:38:28 -0500 From: To: , , , Date: Wed, 11 Jan 2012 02:38:26 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQAAZ2BJA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D8B@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 11 Jan 2012 05:28:46 -0800 Cc: presnick@qualcomm.com, marf@ietf.org Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 07:38:58 -0000 Hi Murray, Thanks for the quick response. > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. =20 That sounds reasonable to me, and I like John Levine's suggestion to add ma= terial to explain more about the level of security that is appropriate for this problem space= and why. In light of such an explanation, an HMAC-based mechanism could well be overkill. > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) I have a hard time believing that the examples used in the review ("a" as t= he redaction key, CRC as the hash) are ever acceptable, and for that reason, I think a c= ouple of MUSTs would be in order to prohibit that sort of nonsense. In particular: - I think there ought to be a MUST minimum length requirement on the redaction key string to prevent really short ones. - I think use of a secure hash ought to be a MUST to prevent use of CRC and other bad ideas. That could be accompanied by additional guidance that may or may not be "SH= OULDs", e.g., suggest a SHA2 hash as a good secure hash, suggest use of a longer string t= han the minimum requirement. > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. > > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. That would be fine - introducing the concept of key rotation as a means to = reduce the impact of key compromise accompanied by a reference to a longer explanation elsewhere see= ms reasonable. Thanks, --David > -----Original Message----- > From: Murray S. Kucherawy [mailto:msk@cloudmark.com] > Sent: Tuesday, January 10, 2012 11:41 PM > To: Black, David; ietf@cybernothing.org; gen-art@ietf.org; ietf@ietf.org > Cc: marf@ietf.org; presnick@qualcomm.com > Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Tuesday, January 10, 2012 6:44 PM > > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@= ietf.org > > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, thanks for the review. >=20 > > [1] The first open issue is the absence of security guidance to ensure = that this > > redaction technique effectively hides the redacted information. The re= daction > > technique is to concatenate a secret string (called the "redaction key"= ) to the > > information to be redacted, apply "any hashing/digest algorithm", conve= rt the output > > to base64 and use that base64 string to replace the redacted informatio= n. > > [...] > > > > I suggest a couple of changes: > > 1) Change "any hashing/digest algorithm" to require use of a secure has= h, and > > explain what is meant by "secure hash" in the security considerations = section. > > 2) Require a minimum length of the "redaction key" string, and strongly= suggest > > (SHOULD) that it be randomly generated (e.g., by running sufficient ou= tput > > of an entropy-rich random number generator through a base64 converter)= . > > > > For the latter change, figure out the amount of entropy that should be = used > > for redaction - the recommended string length will be larger because pr= intable > > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in = each > > 8-bit character, and human-written text such as this message has signif= icantly > > less). > > > > From a pure security perspective, use of HMAC with specified secure has= hes > > (SHA2-family) and an approach of hashing the "redaction key" down to a = binary > > key for HMAC would be a stronger approach. I suggest that authors consi= der > > approach, but there may be practical usage concerns that suggest not > > adopting it. >=20 > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. Thus, my > inclination is to make the following changes (subject to WG consensus): >=20 > - add all of this advice to Security Considerations, with forward referen= ces to it elsewhere in the > document > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) >=20 > Would those be sufficient? >=20 > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. >=20 > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. >=20 > > Editorial Nit: I believe that "anonymization" is a better description o= f what > > this draft is doing (as opposed to "redaction"), particularly as the re= sult is > > intended to be correlatable via string match across reports from the > > same source. >=20 > Fair enough. We can add a sentence to that effect in the Introduction. >=20 > To the MARF working group: Please let me know if the above suggestions su= ffice (reply only to the marf > list, please). I will summarize and have a new version ready to publish = when LC closes, and make sure > David sees it around the same time. >=20 > -MSK From paul.hoffman@vpnc.org Wed Jan 11 11:02:48 2012 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 E70B921F852F; Wed, 11 Jan 2012 11:02:48 -0800 (PST) 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 xmsPyCy0PuVz; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21F84D4; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BJ2kd0059299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 12:02:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Date: Wed, 11 Jan 2012 11:02:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> To: IETF Discussion X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Wed, 11 Jan 2012 11:07:57 -0800 Cc: gen-art@ietf.org, marf@ietf.org Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 19:02:49 -0000 On Jan 10, 2012, at 6:44 PM, = wrote: > [1] The first open issue is the absence of security guidance to ensure = that this > redaction technique effectively hides the redacted information. The = redaction > technique is to concatenate a secret string (called the "redaction = key") to the > information to be redacted, apply "any hashing/digest algorithm", = convert the output > to base64 and use that base64 string to replace the redacted = information. >=20 > There are two important ways in which this technique could fail to = effectively hide > the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. >=20 > To take an extreme example, if the secret string ("redaction key") = consists of a > single ASCII character, and a short email local part is being = redacted, then the > output is highly vulnerable to dictionary and brute force attacks = because only 6 bits > of entropy are added (the result may look secure, but it's not). = Beyond this extreme > example, this is a potentially real concern - e.g., applying the rule = of thumb that > ASCII text contains 4-5 bits of entropy per character, the example in = Appendix A > uses a "redaction key" of "potatoes" that injects at most 40 bits of = entropy - > is that sufficient for email redaction purposes? >=20 > To take a silly example, if a CRC is used as the hash with that sort = of short input, > the result is not particularly difficult to invert. >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure = hash, and > explain what is meant by "secure hash" in the security = considerations section. Simply saying "any hash algorithm listed in [FIPS180-3]" is precise and = sufficient. > 2) Require a minimum length of the "redaction key" string, and = strongly suggest > (SHOULD) that it be randomly generated (e.g., by running = sufficient output > of an entropy-rich random number generator through a base64 = converter). Proposal: "The redaction key SHOULD be based on at least 64 bits of = pseudo-random input that is converted to base64". > [2] The second open issue is absence of security considerations for = the redaction > key. The security considerations section needs to caution that the = redaction key > is a secret key that must be managed and protected as a secret key. = Disclosure > of a redaction key removes the redaction from all reports that used = that key. Agree. > As part of this, guidance should be provided on when and how to change = the > redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Disagree, given that we have absolutely no idea how systems that use = this will work operationally. Simply telling them "if it is no longer = secret, you're hosed" is sufficient. --Paul Hoffman From sm@resistor.net Wed Jan 11 11:50:41 2012 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 6063E21F84F5; Wed, 11 Jan 2012 11:50:41 -0800 (PST) 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=[AWL=0.000, 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 0on2hh3+H8cF; Wed, 11 Jan 2012 11:50:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF821F84F3; Wed, 11 Jan 2012 11:50:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0BJoTsG014962; Wed, 11 Jan 2012 11:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326311436; i=@resistor.net; bh=P/QL1U+E812ocBWJFlglwAiQx/51Q3iWIN49ZNK0JJ8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vH84mbHasBOfd1qJ41w0Uj4cFl/swBxBc0Qd/Y4EPtwix9vcNIN76Ez5dYNdwypd5 sgqBIQDsjPsW7wXLhdpAqSuB+abo7eNzV8YlnNPHqfyO71Mq0jnTfymIWgl7/jFeRf w7e68PP6yekAVJRawnLfO3loEnrD/NFlMydsgWjc= Message-Id: <6.2.5.6.2.20120111112546.0c105678@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 11:50:20 -0800 To: david.black@emc.com From: SM In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc. com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 19:50:41 -0000 Hi David, At 18:44 10-01-2012, david.black@emc.com wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please I appreciate that you have spent your time and effort in performing the review. I find the review useful. > From a pure security perspective, use of HMAC with specified secure hashes >(SHA2-family) and an approach of hashing the "redaction key" down to a binary >key for HMAC would be a stronger approach. I suggest that authors consider >approach, but there may be practical usage concerns that suggest >not adopting it. > >[2] The second open issue is absence of security considerations for >the redaction >key. The security considerations section needs to caution that the >redaction key >is a secret key that must be managed and protected as a secret >key. Disclosure >of a redaction key removes the redaction from all reports that used that key. >As part of this, guidance should be provided on when and how to change the >redaction key in order to limit the effects of loss of secrecy for a single >redaction key. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. Regards, -sm From david.black@emc.com Wed Jan 11 12:52:16 2012 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 C594321F8533; Wed, 11 Jan 2012 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bHtTnlnLbzDm; Wed, 11 Jan 2012 12:52:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BD21F85D5; Wed, 11 Jan 2012 12:52:15 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKqAAZ025206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 15:52:12 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 15:52:02 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKq12u024049; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Wed, 11 Jan 2012 15:52:01 -0500 From: To: Date: Wed, 11 Jan 2012 15:51:58 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQmns3tJWBjqmEQUeESbIBILYfNwABuHzw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <6.2.5.6.2.20120111112546.0c105678@resistor.net> In-Reply-To: <6.2.5.6.2.20120111112546.0c105678@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 X-EMM-MHVC: 1 Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 20:52:16 -0000 Hi, Thanks for the response - I appreciate the perspective. > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. At a minimum, I like John Levine's suggestion that the draft explain the level of security required for redaction in practice. Such an explanation could help illuminate whether the secure hash (the example in the draft uses SHA-1) is for obfuscation purposes vs. actual security. Absent such an explanation, I saw the use of a secure hash and inferred the existence of actual security requirements. If that was an incorrect inference, then text should be added to the draft to avoid having other readers make similarly incorrect inferences. Thanks, --David > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, January 11, 2012 2:50 PM > To: Black, David > Cc: marf@ietf.org; gen-art@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, > At 18:44 10-01-2012, david.black@emc.com wrote: > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please >=20 > I appreciate that you have spent your time and effort in performing > the review. I find the review useful. >=20 > > From a pure security perspective, use of HMAC with specified secure has= hes > >(SHA2-family) and an approach of hashing the "redaction key" down to a b= inary > >key for HMAC would be a stronger approach. I suggest that authors consid= er > >approach, but there may be practical usage concerns that suggest > >not adopting it. > > > >[2] The second open issue is absence of security considerations for > >the redaction > >key. The security considerations section needs to caution that the > >redaction key > >is a secret key that must be managed and protected as a secret > >key. Disclosure > >of a redaction key removes the redaction from all reports that used that= key. > >As part of this, guidance should be provided on when and how to change t= he > >redaction key in order to limit the effects of loss of secrecy for a sin= gle > >redaction key. >=20 > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. >=20 > Regards, > -sm >=20 From sm@resistor.net Wed Jan 11 13:16:38 2012 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 DD24011E80B2; Wed, 11 Jan 2012 13:16:38 -0800 (PST) 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=[AWL=0.000, 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 fIB6udQNS7r4; Wed, 11 Jan 2012 13:16:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3770411E8074; Wed, 11 Jan 2012 13:16:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0BLGUVa005928; Wed, 11 Jan 2012 13:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326316596; i=@resistor.net; bh=2xi/6d3QoAOBAkFfR2WvFMhLgvSfgM2Yj3s0C7zLbPg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=aMCSzqf+Wj8V7ClYdw0ZjUo+bVWQTQY4Gh3whtiJf9NIOXB6T3fTyMoa9WENY6CZD uLpQ++KXLDeByzeoFN0t44yWYFSkDlEIutGUClSUxaA8qArESqoyKaIibtNRPfzUf6 SFC/cmstk/bEqYQkI/v1bGkZO1wgaMkITbCEY6WU= Message-Id: <6.2.5.6.2.20120111130905.0c07cff0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 13:15:12 -0800 To: david.black@emc.com From: SM In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc. com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <6.2.5.6.2.20120111112546.0c105678@resistor.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, marf@ietf.org Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 21:16:39 -0000 Hi David, At 12:51 11-01-2012, david.black@emc.com wrote: >At a minimum, I like John Levine's suggestion that the draft explain >the level of security required for redaction in practice. Such an >explanation could help illuminate whether the secure hash (the >example in the draft uses SHA-1) is for obfuscation purposes >vs. actual security. It would help to have an explanation along the line of John Levine's suggestion. >Absent such an explanation, I saw the use of a secure hash and inferred >the existence of actual security requirements. If that was an incorrect >inference, then text should be added to the draft to avoid having >other readers make similarly incorrect inferences. Agreed. Regards, -sm From msk@cloudmark.com Wed Jan 11 15:16:55 2012 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 849ED11E8099 for ; Wed, 11 Jan 2012 15:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 FzUb+QuShiYO for ; Wed, 11 Jan 2012 15:16:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7590411E8074 for ; Wed, 11 Jan 2012 15:16:54 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 15:16:43 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 15:16:50 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 11 Jan 2012 15:16:50 -0800 Thread-Topic: [marf] Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQIyRs8FtCkWhZQBea6DbTdtanFAAk6Hhw Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <1796323.RCyXJjPkHT@scott-latitude-e6320> In-Reply-To: <1796323.RCyXJjPkHT@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] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 23:16:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, January 10, 2012 9:38 PM > To: marf@ietf.org > Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 >=20 > > John and I collaborated on the following edits. Please indicate > > whether or not you approve, and suggest any adjustments needed. I'll > > include them in a revision right after IETF LC closes. > > > > http://www.blackops.org/~msk/marf.html >=20 > Looks good to me. Thanks for that. Just to make sure our bases are all covered, the Gen-ART = reviewer is pushing a little on the idea of saying the use of a secure hash= ought to be a SHOULD, while we're currently using "suggested" given the no= n-critical use of security here. So just to get it on the record, do we prefer the "suggested" language, or = is a SHOULD more appropriate? -MSK From sklist@kitterman.com Wed Jan 11 15:19:01 2012 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 67DDB11E8099 for ; Wed, 11 Jan 2012 15:19:01 -0800 (PST) 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 l++MMixs+r7G for ; Wed, 11 Jan 2012 15:19:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C40EB11E8074 for ; Wed, 11 Jan 2012 15:19:00 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4A1AB20E410A; Wed, 11 Jan 2012 18:19:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326323940; bh=TufOlf3SZnIA2JCbmqjYhI+795DNkHWazTR7jgWTxWU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YS2a2oY7+QkFgj5W1iezmABMCTVkKzFmuPyR0v7m1Qu8ZQn0Rqd5aK4LanvUtkNgj uJDHJGhZq8PBjLhj0SdLdW3CAK5vQpMbmkc0nxeS2Gf5De4DLdGm2kZqmu0ERvvuUU moRziO1v2FGUnHyuD4Psm/lfM9UneS8FlV317yTE= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 06E7920E4081; Wed, 11 Jan 2012 18:18:59 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 11 Jan 2012 18:18:57 -0500 Message-ID: <4415302.hZLupArRfY@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <1796323.RCyXJjPkHT@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] Gen-ART review of draft-ietf-marf-redaction-04 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, 11 Jan 2012 23:19:01 -0000 On Wednesday, January 11, 2012 03:16:50 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Tuesday, January 10, 2012 9:38 PM > > To: marf@ietf.org > > Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 > > > > > John and I collaborated on the following edits. Please indicate > > > whether or not you approve, and suggest any adjustments needed. > > > I'll > > > include them in a revision right after IETF LC closes. > > > > > > http://www.blackops.org/~msk/marf.html > > > > Looks good to me. > > Thanks for that. Just to make sure our bases are all covered, the Gen-ART > reviewer is pushing a little on the idea of saying the use of a secure hash > ought to be a SHOULD, while we're currently using "suggested" given the > non-critical use of security here. > > So just to get it on the record, do we prefer the "suggested" language, or > is a SHOULD more appropriate? I don't think the SHOULD is needed for interoperability or for security, so I think suggested is fine. Scott K From shmuel+gen@patriot.net Wed Jan 11 18:51:36 2012 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 C9F0A11E8075 for ; Wed, 11 Jan 2012 18:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 rPY7shEYGEty for ; Wed, 11 Jan 2012 18:51:36 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4B21F85C2 for ; Wed, 11 Jan 2012 18:51:35 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.3]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 8F989F5808F for ; Wed, 11 Jan 2012 21:37:45 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 11 Jan 2012 21:34:07 -0500 To: marf@ietf.org In-Reply-To: <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org> Mail-Copies-To: nobody 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: <20120112023745.8F989F5808F@smtp.patriot.net> Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 12 Jan 2012 02:51:36 -0000 In <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org>, on 01/11/2012 at 11:02 AM, Paul Hoffman said: >Proposal: "The redaction key SHOULD be based on at least 64 bits of >pseudo-random input that is converted to base64". Agree with the first part; disagree with mentioning BASE64 except as an 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 msk@cloudmark.com Wed Jan 11 19:07:37 2012 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 6CF7311E80C6 for ; Wed, 11 Jan 2012 19:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KEQg1r+Lywnl for ; Wed, 11 Jan 2012 19:07:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60211E80C5 for ; Wed, 11 Jan 2012 19:07:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 19:07:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 19:07:33 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 11 Jan 2012 19:07:31 -0800 Thread-Topic: [marf] Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQ1SHfliVsD91sQPStwNFe3BK8uAAAhVkg Message-ID: References: <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org> <20120112023745.8F989F5808F@smtp.patriot.net> In-Reply-To: <20120112023745.8F989F5808F@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] Gen-ART review of draft-ietf-marf-redaction-04 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, 12 Jan 2012 03:07:37 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, January 11, 2012 6:34 PM > To: marf@ietf.org > Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 >=20 > In <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org>, on 01/11/2012 > at 11:02 AM, Paul Hoffman said: >=20 > >Proposal: "The redaction key SHOULD be based on at least 64 bits of > >pseudo-random input that is converted to base64". >=20 > Agree with the first part; disagree with mentioning BASE64 except as an > example. Unless I misunderstand the mechanisms, I think the mention of base64 is sup= erfluous anyway since the entropy applies to the hash step, not to the 7-bi= t encoding of the result. From steve@wordtothewise.com Wed Jan 11 19:28:07 2012 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 7D7C421F86E1 for ; Wed, 11 Jan 2012 19:28:07 -0800 (PST) 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 815rKgETzhQt for ; Wed, 11 Jan 2012 19:28:06 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5B521F86E0 for ; Wed, 11 Jan 2012 19:28:06 -0800 (PST) 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 C84C32EAFF for ; Wed, 11 Jan 2012 19:28:03 -0800 (PST) From: Steve Atkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 19:28:00 -0800 Message-Id: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [marf] Some thoughts on draft-ietf-marf-as-02 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, 12 Jan 2012 03:28:07 -0000 Some comments on = https://datatracker.ietf.org/doc/draft-ietf-marf-as/?include_text=3D1 Most of the document looks fine, but I have some concerns about the = sections that deal with unsolicited reports. Section 5. Solicited and Unsolicited Reports "Scored high by spam filters" really isn't a good reason to send an = abuse report. Sending mail that "looks like" spam according to a = mechanical content filter isn't an AUP violation, and reports about it = aren't going to be actionable as there's nothing wrong with sending mail = with a high spamassassin score. While, arguably, reports of mail that = "looks like" spam might be a basis for investigation by an abuse desk as = to whether a customer is doing something wrong it's not a very useful = basis - if there is a source of mail on your network that's found = offensive by recipients, you'll find out fairly quickly by receiving = informed abuse reports, manually or from this-is-spam-button driven = feedback loops, so reports of mail that "looks like" spam aren't going = to provide much data that the abuse desk won't already have via other = channels.=20 Non-actionable reports - whether they be false positives or not - reduce = the efficiency of an abuse desk. Let's just not mention reports of mail = scored high by spam filters, and quietly leave it as part of "anything = else the sender considers". (Automated reports of spam-like content may well be useful as part of an = "avoid false positives" sort of feedback loop, but not as an abuse = report. And automated reports of mail that has virus or malware content = might be appropriate, even though spam-like content isn't.) The DKIM signer of a message is definitely a good target for solicited = reports as part of a feedback loop. For unsolicited reports it's much = less clear that that's the case. There are some mechanical reasons - the = d=3D value is an identifier for reputation, not a domain intended to = receive email, so we don't want to imply that = abuse@transactional.blighty.com is automatically a good place to report = mail that's signed with d=3Dtransactional.blighty.com. In a broader = sense, though, it's likely that the DKIM signing domain is the author of = the mail - and if the mail is objectionable, they're often the least = useful place to notify. In the case of mail sent through an ESP, the = DKIM d=3D domain is likely to end up at the customer, rather than at the = ESP where it's more likely to be handled correctly. That's one instance of a more general issue of sending automated, = unsolicited reports. Identifying an appropriate recipient for a report = is *hard* to do automatically, while "shotgunning" reports to multiple = email addresses because one of them might be appropriate is unhelpful. = Sending them in a format that's intended primarily to be = machine-readable and handled automatically by the entity receiving the = reports leads to the problem of knowing what email address at what = entity is intended to handle machine-readable reports. There's no = standard for it, and there's a risk that those machine-readable reports = will be discarded or ignored if they're sent to role addresses chosen at = random.=20 Section 8 discusses this issue again, and somewhat better. Would it make = sense to move the mention of DKIM to section 8, where it would be in a = better context? Section 7. Receiving and Processing Complaint-Based Solicited Reports "Point 3 - Mail operators SHOULD utilize an automated system to receive = and process these reports".=20 That's really an engineering and operational decision. If I only receive = two or three ARF reports a day, and my MUA or ticketing system can = display them correctly, then handling them as part of my usual customer = support / abuse desk workflow is likely to be more reliable (and much = less expensive to implement) than an automated system. An ARF based FBL = is still of value to me, but automating it would be a poor decision. RFC = 6449 Section 4.4 says pretty much that. I think we'd be better just = pointing people at that section of RFC 6449, rather than saying that = automation is a SHOULD. Section 8. Generating and Handling Unsolicited Reports Is authentication failure abusive? If it is, we should say why (and in = what context). If not, it shouldn't be in this document. I'm not sure it's true that "even recipient systems that haven't asked = for ARF format reports handle them at least as well as any other format = such as plain text, with or without a copy of the message attached." I know for sure that there are ticketing systems in use that don't = handle anything other than plain text particularly well. They will not = handle ARF reports as well as they would handle plain text.=20 Unexpected multipart/* formats (such as the multipart/report type used = by ARF) aren't necessarily going to be handled well even by MIME aware = MUAs. Similarly, message/feedback-report isn't necessarily going to be = handled well by MIME aware MUAs. As an example, here's a snapshot of an ARF report displayed by Mail.app: = https://skitch.com/steveatkins/g2bkt/inbox-27642-messages-33-unread And here's one displayed by gmail: = https://skitch.com/steveatkins/g2bck/inbox-27642-messages-33-unread And Outlook Express: https://skitch.com/steveatkins/g2bpj/192.168.80.89 All three of those are more sophisticated than the web-based ticketing = systems commonly used at smaller ISPs. (Alpine, OTOH, displayed it just fine - = https://skitch.com/steveatkins/g2bq8/steve-infrastructure-mail ) Ticketing systems are one of the last bits of the email system that = don't handle MIME particularly robustly, if at all, and abuse desks are = (quite reasonably) wary of clicking on attachments - all attachments, = including attached message/rfc822. Quite a few ISPs (including national = US ISPs) ask reporters explicitly to not forward email as an attachment, = rather to paste the headers and body of the mail being reported into a = new message, due to either tool limitations or a policy not to open = attachments for security reasons.=20 Everybody can handle the lowest common denominator of text/plain, but = that's about it. So=85 I don't think it's valid to say that recipient systems that are = not advertised to accept ARF will render ARF format messages in a way = that will lead to them being handled. At the very least, anyone sending = unsolicited messages in ARF format must assume that recipients will not = be able to see the ARF metadata, and should include all information = needed in human readable format in the first, text/plain section of the = report. Also, they should ensure that the report is readable when viewed = as plain text, to give low end ticketing systems as much help as = possible - that might includes advice on appropriate MIME encoding and = choice of character sets and so on. And they should be aware that the = report may be discarded or ignored due to it's format. I don't think that experience purely of sending unsolicited ARF reports = can really lead to the claim that all recipients handle them well - as = the recipients that *don't* handle them well are simply going to discard = or ignore the report, rather than trying to work out why it was sent. = Abuse desks generally have more than enough actionable reports in their = queue to waste time trying to decipher ones that they can't read. IIRC, John includes a link to a web-based rendering of each report in = the plain text part of the unsolicited reports he sends out (not a bad = idea, if you have the infrastructure for it), so they may be more widely = readable by abuse desks than an ARF format report would be. Cheers, Steve From vesely@tana.it Wed Jan 11 23:46:27 2012 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 64FED21F860E for ; Wed, 11 Jan 2012 23:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=0.071, 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 IZtBYLEZ7TDD for ; Wed, 11 Jan 2012 23:46:26 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 88A7A21F85F3 for ; Wed, 11 Jan 2012 23:46:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326354383; bh=WNE5wcFdv9H2n071lMJRUcenW35120wxCTEa5gye3+4=; l=1040; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=AfCB26l13OPG7wvNxylSJDOPuWIbFFDbM/CDda15ZCD8Q7jwUYToQJVa4drGR5fka yAICsWO9nW+VIZV5G2INXjRUA1kBY4CZvyRqY8k5+HZ/BBRF5fKJpMeDIF1SGsW+WO U91YiMOfvR2DP/d5nIY9nHTeP/8mnds2eE7iqCso= 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, 12 Jan 2012 08:46:23 +0100 id 00000000005DC039.000000004F0E8FCF.00003AD1 Message-ID: <4F0E8FCF.7090202@tana.it> Date: Thu, 12 Jan 2012 08:46:23 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <1796323.RCyXJjPkHT@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04 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, 12 Jan 2012 07:46:27 -0000 On 12/Jan/12 00:16, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Scott Kitterman >> >>> John and I collaborated on the following edits. Please indicate >>> whether or not you approve, and suggest any adjustments needed. I'll >>> include them in a revision right after IETF LC closes. >>> >>> http://www.blackops.org/~msk/marf.html >> >> Looks good to me. +1 > Thanks for that. Just to make sure our bases are all covered, the > Gen-ART reviewer is pushing a little on the idea of saying the use > of a secure hash ought to be a SHOULD, while we're currently using > "suggested" given the non-critical use of security here. > > So just to get it on the record, do we prefer the "suggested" > language, or is a SHOULD more appropriate? Saying "a secure hash is RECOMMENDED" (rather than "suggested") doesn't really change the meaning, but makes the whole section overly compelling. To counter-balance that, I'd borrow some text from John's post --such as the phrase "a steel lock on a cardboard box". From johnl@iecc.com Wed Jan 11 23:52:08 2012 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 BE13821F84C5 for ; Wed, 11 Jan 2012 23:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.355 X-Spam-Level: X-Spam-Status: No, score=-104.355 tagged_above=-999 required=5 tests=[AWL=-1.756, 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 MMiPIGaiiOWI for ; Wed, 11 Jan 2012 23:52:08 -0800 (PST) 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 2417D21F84D0 for ; Wed, 11 Jan 2012 23:52:07 -0800 (PST) Received: (qmail 90912 invoked from network); 12 Jan 2012 07:52:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Jan 2012 07:52:06 -0000 Date: 12 Jan 2012 07:51:44 -0000 Message-ID: <20120112075144.6553.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 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, 12 Jan 2012 07:52:08 -0000 >I'm not sure it's true that "even recipient systems that haven't asked >for ARF format reports handle them at least as well as any other format >such as plain text, with or without a copy of the message attached." > >I know for sure that there are ticketing systems in use that don't >handle anything other than plain text particularly well. They will not >handle ARF reports as well as they would handle plain text. Oh, sure, but I also used to get a certain number of "please send this as an attachement." I didn't say it works flawlessly, just that in my experience, at least, it's no worse than anything else. I'm also getting a trickle of responses saying "ARF? Great, we handle that automatically." > Quite a few ISPs (including national >US ISPs) ask reporters explicitly to not forward email as an attachment, Still? I can't rememnber the last time I got a request to resend with the message pasted in from an ISP I'd ever heard of. R's, John From shmuel+gen@patriot.net Thu Jan 12 07:19:20 2012 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 8285421F862F for ; Thu, 12 Jan 2012 07:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 m7T54sxnRjSi for ; Thu, 12 Jan 2012 07:19:19 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1C21F862A for ; Thu, 12 Jan 2012 07:19:19 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.249]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id BAB71F58089 for ; Thu, 12 Jan 2012 10:05:28 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 12 Jan 2012 09:54:40 -0500 To: marf@ietf.org In-Reply-To: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> Mail-Copies-To: nobody 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: <20120112150528.BAB71F58089@smtp.patriot.net> Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 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, 12 Jan 2012 15:19:20 -0000 In <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com>, on 01/11/2012 at 07:28 PM, Steve Atkins said: >Quite a few ISPs (including national US ISPs) ask reporters >explicitly to not forward email as an attachment, rather to paste the >headers and body of the mail being reported into a new message, While others reject it as spam unless you put it in an attachment :-( >Everybody can handle the lowest common denominator of text/plain, Would that it were true. -- 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 shmuel+gen@patriot.net Thu Jan 12 07:19:24 2012 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 953C321F8631 for ; Thu, 12 Jan 2012 07:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 zMtnNt4PcgX8 for ; Thu, 12 Jan 2012 07:19:24 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0DE21F8630 for ; Thu, 12 Jan 2012 07:19:21 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.249]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 61DDAF5808F for ; Thu, 12 Jan 2012 10:05:31 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 12 Jan 2012 10:18:20 -0500 To: Message Abuse Report Format working group Mail-Copies-To: nobody 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: <20120112150532.61DDAF5808F@smtp.patriot.net> Subject: [marf] Perl tool for constructing current MARF reports? 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, 12 Jan 2012 15:19:24 -0000 There is a Perl module, Email::ARF, for constructing and parsing ARF reports, but it predates the RFC, although the last chage was 2011-03-24, after the RFC. Does anybody know whether it fully supports RFC5965, or know of an equivalent that does? -- 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 vesely@tana.it Thu Jan 12 08:32:37 2012 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 8196021F8503 for ; Thu, 12 Jan 2012 08:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.068, 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 vzdBO8Cipr5x for ; Thu, 12 Jan 2012 08:32:36 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 49BDF21F8505 for ; Thu, 12 Jan 2012 08:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326385955; bh=BD+eQHFNqwTuHl7gtSHlHEkEVmulZBK/qfPUnOiy/34=; l=5083; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Tv7TVZZFyDRlJ5WB7+I6wFczoCWXZS0tanAXNdKJkPLJXhvVXOL9fjwj5vf5l6g7K S+mWtQkPy2KxNCvSnz5j99f+dWCAPaYWPDhv8c5zxEl3oOUx5HAjuOWTFvvM3zG3xM D1R+5tM7N0Qhtkg2aIaLSFgEl+vGn8ROMR0FhvBU= 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, 12 Jan 2012 17:32:35 +0100 id 00000000005DC04B.000000004F0F0B23.00003CF3 Message-ID: <4F0F0B22.5030900@tana.it> Date: Thu, 12 Jan 2012 17:32:34 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> In-Reply-To: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 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, 12 Jan 2012 16:32:37 -0000 On 12/Jan/12 04:28, Steve Atkins wrote: > Some comments on https://datatracker.ietf.org/doc/draft-ietf-marf-as/?include_text=1 Thank you, Steve. Glad to read from you again on this list. > Section 5. Solicited and Unsolicited Reports > > "Scored high by spam filters" really isn't a good reason to send an > abuse report. Yet, for good messages, that use case of ARF would very closely resemble the intended use of its ancestor NDN. > Sending mail that "looks like" spam according to a mechanical > content filter isn't an AUP violation, and reports about it aren't > going to be actionable as there's nothing wrong with sending mail > with a high spamassassin score. [...] > > Non-actionable reports - whether they be false positives or not - > reduce the efficiency of an abuse desk. Let's just not mention > reports of mail scored high by spam filters, and quietly leave it > as part of "anything else the sender considers". So this is a case where it is useful to know whether the report-trigger was auto or manual. Previous mumbling is here: http://www.ietf.org/mail-archive/web/marf/current/msg01233.html > (Automated reports of spam-like content may well be useful as part > of an "avoid false positives" sort of feedback loop, but not as an > abuse report. This reasoning seems to imply it is better to add a new Feedback-Type rather than a new field with a human/auto indication. (Assuming we won't then need, say, a manually-discovered-virus type.) > The DKIM signer of a message is definitely a good target for > solicited reports as part of a feedback loop. For unsolicited > reports it's much less clear that that's the case. There are some > mechanical reasons - the d= value is an identifier for reputation, > not a domain intended to receive email, so we don't want to imply > that abuse@transactional.blighty.com is automatically a good place > to report mail that's signed with d=transactional.blighty.com. That can be covered by reporting-discovery. > In a broader sense, though, it's likely that the DKIM signing > domain is the author of the mail - and if the mail is > objectionable, they're often the least useful place to notify. In > the case of mail sent through an ESP, the DKIM d= domain is likely > to end up at the customer, rather than at the ESP where it's more > likely to be handled correctly. IMHO, ESPs should keep current and apply BCP 167. > That's one instance of a more general issue of sending automated, > unsolicited reports. Identifying an appropriate recipient for a > report is *hard* to do automatically, while "shotgunning" reports > to multiple email addresses because one of them might be > appropriate is unhelpful. Sending them in a format that's intended > primarily to be machine-readable and handled automatically by the > entity receiving the reports leads to the problem of knowing what > email address at what entity is intended to handle machine-readable > reports. There's no standard for it, and there's a risk that those > machine-readable reports will be discarded or ignored if they're > sent to role addresses chosen at random. Reporting-discovery can only cover authenticated mail (DKIM and/or SPF). For the rest, only the relay's IP address can be a meaningful automated feedback target, AFAICS. But then we'd also need to tell network providers what to do when they receive ARF messages at their abuse-mailboxes, since they are neither authors nor senders. > Section 7. Receiving and Processing Complaint-Based Solicited Reports > > "Point 3 - Mail operators SHOULD utilize an automated system to > receive and process these reports". > > That's really an engineering and operational decision. If I only > receive two or three ARF reports a day, and my MUA or ticketing > system can display them correctly, then handling them as part of my > usual customer support / abuse desk workflow is likely to be more > reliable (and much less expensive to implement) than an automated > system. An ARF based FBL is still of value to me, but automating it > would be a poor decision. How about 3. Mail operators are urged to utilize a system that understands ARF messages and displays and processes them adequately, along the guidelines of Section 4 of [RFC6449]. Automated systems SHOULD receive and process these reports as discussed in Section 4.4 of [RFC6449]. ? > I don't think that experience purely of sending unsolicited ARF > reports can really lead to the claim that all recipients handle > them well - as the recipients that *don't* handle them well are > simply going to discard or ignore the report, rather than trying to > work out why it was sent. Senders of unsolicited reports need some kind of acknowledgment, sometimes, especially from new consumers that are not yet well characterized. Not boilerplate, but a few crisply handwritten lines that help to decide whether to continue sending, or stop for the time being. Would such actions then turn the FBL into a "solicited" one? From msk@cloudmark.com Sat Jan 14 20:49:30 2012 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 A928C21F848B; Sat, 14 Jan 2012 20:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 GWQkBS9-fsBU; Sat, 14 Jan 2012 20:49:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4C69721F847B; Sat, 14 Jan 2012 20:49:30 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 14 Jan 2012 20:49:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 14 Jan 2012 20:49:29 -0800 From: "Murray S. Kucherawy" To: Alexey Melnikov Date: Sat, 14 Jan 2012 20:49:32 -0800 Thread-Topic: Gen-ART last call review of draft-ietf-marf-authfailure-report-09 Thread-Index: AczS4N+RyGJDADV3QrKDDeen5J1jDgAX5Jrg Message-ID: References: <4F11B97D.30705@isode.com> In-Reply-To: <4F11B97D.30705@isode.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 Cc: "gen-art@ietf.org" , The IESG , Message Abuse Report Format working group Subject: Re: [marf] Gen-ART last call review of draft-ietf-marf-authfailure-report-09 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, 15 Jan 2012 04:49:30 -0000 Hi Alexey, thanks for the review. > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Sent: Saturday, January 14, 2012 9:21 AM > To: Hilda L. Fontana; Murray S. Kucherawy; Pete Resnick > Cc: gen-art@ietf.org; The IESG > Subject: Gen-ART last call review of draft-ietf-marf-authfailure-report-0= 9 >=20 > Document: draft-ietf-marf-authfailure-report-09 > Reviewer: Alexey Melnikov > Review Date: 2012-01-14 > IETF LC End Date: 2012-01-18 > IESG Telechat date: 2012-01-19 >=20 > Summary: This draft is ready for publication as a standard RFC, but a > couple of minor issues remain. >=20 > Major issues: None > Minor issues: >=20 > 2.2. Base 64 >=20 > Sorry for missing this earlier, but RFC 4648, Section 4 is a better > reference for base64. (Don't forget the section reference, because RFC > 4648 has 2 base64 alphabets.) I think that's reasonable. > In Section 4: >=20 > > spf-dns =3D "SPF-DNS:" : { "txt" / "spf" } [CFWS] ":" [CFWS] domain > > [CFWS] ":" [CFWS] quoted-string CRLF >=20 > I think you are still missing [CFWS] before "txt" and another one > before CRLF. >=20 > Also, you should use "(" and ")" instead of "{" and "}", as the two > latter are not valid according to ABNF syntax. >=20 > To summarize, I think you should use: >=20 > spf-dns =3D "SPF-DNS:" : [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS] > domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF Almost; the errant unquoted (and thus meaningless) colon before the CFWS ha= s to come out too. We'll do that for -10. Thanks again, -MSK From msk@cloudmark.com Mon Jan 16 15:44:08 2012 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 9E86721F86EB for ; Mon, 16 Jan 2012 15:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 qNwUGbQaJAVV for ; Mon, 16 Jan 2012 15:44:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE421F8602 for ; Mon, 16 Jan 2012 15:44:07 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Jan 2012 15:43:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 16 Jan 2012 15:44:07 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 16 Jan 2012 15:44:08 -0800 Thread-Topic: DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczT7Tt6XFnsq4H1S+2gsZeVFFlMlQAunIqA Message-ID: 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: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 16 Jan 2012 23:44:08 -0000 One of the security area directors has placed a DISCUSS on the above draft.= The working group needs to talk about the issue raised and determine how = to proceed. The specific issue is that a simple hash over a key prepended to the data t= o be redacted is not a strong security measure. Although we've mentioned t= hat this isn't much of a concern in our case in the proposed new text, the = complaint has reappeared. For example, the simple key-hash solution is sus= ceptible to a few simple recovery attacks. Among other things, the concern is that doing something like this on the st= andards track might lead future efforts to believe this mechanism is suffic= ient for arbitrary data protection when it is not. The proposals going forward appear to be: a) Instead of a hash of key + data, replace the algorithm with HMAC, as def= ined in RFC2104. b) Add even more explanatory text so that the reader has it clear that we a= re not attempting to completely secure something here, and acknowledge full= y that there are weaknesses in our algorithm. (The Wikipedia page for HMAC= gives a pretty good description of the comparison and attacks.) c) Attempt to argue that it's good enough as it is, and that's how we want = it. Comments, please. -MSK From kathleen.moriarty@emc.com Mon Jan 16 16:14:38 2012 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 DF6DF21F86CE for ; Mon, 16 Jan 2012 16:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 7oikrBbxBEFw for ; Mon, 16 Jan 2012 16:14:38 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4945021F85BB for ; Mon, 16 Jan 2012 16:14:38 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0H0EZGC002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2012 19:14:35 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 16 Jan 2012 19:14:20 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0H0EKbP004590; Mon, 16 Jan 2012 19:14:20 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Mon, 16 Jan 2012 19:14:19 -0500 From: To: , Date: Mon, 16 Jan 2012 19:14:18 -0500 Thread-Topic: DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczT7Tt6XFnsq4H1S+2gsZeVFFlMlQAunIqAAAFNbVA= 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 X-EMM-MHVC: 1 Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 00:14:39 -0000 I vote for a or b, but I have not been active in the mailing list. Thanks, Kathleen -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Monday, January 16, 2012 6:44 PM To: Message Abuse Report Format working group Subject: [marf] DISCUSS on draft-ietf-marf-redaction-04 One of the security area directors has placed a DISCUSS on the above draft.= The working group needs to talk about the issue raised and determine how = to proceed. The specific issue is that a simple hash over a key prepended to the data t= o be redacted is not a strong security measure. Although we've mentioned t= hat this isn't much of a concern in our case in the proposed new text, the = complaint has reappeared. For example, the simple key-hash solution is sus= ceptible to a few simple recovery attacks. Among other things, the concern is that doing something like this on the st= andards track might lead future efforts to believe this mechanism is suffic= ient for arbitrary data protection when it is not. The proposals going forward appear to be: a) Instead of a hash of key + data, replace the algorithm with HMAC, as def= ined in RFC2104. b) Add even more explanatory text so that the reader has it clear that we a= re not attempting to completely secure something here, and acknowledge full= y that there are weaknesses in our algorithm. (The Wikipedia page for HMAC= gives a pretty good description of the comparison and attacks.) c) Attempt to argue that it's good enough as it is, and that's how we want = it. Comments, please. -MSK _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From steve@wordtothewise.com Mon Jan 16 16:42:50 2012 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 6260B21F85AE for ; Mon, 16 Jan 2012 16:42:50 -0800 (PST) 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 ZA4BESgILp13 for ; Mon, 16 Jan 2012 16:42:49 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id D989121F85A5 for ; Mon, 16 Jan 2012 16:42:49 -0800 (PST) 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 A50CF2DECF for ; Mon, 16 Jan 2012 16:42:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Mon, 16 Jan 2012 16:42:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9F647D63-D0BC-4355-8A7A-0CBE160557DA@wordtothewise.com> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 00:42:50 -0000 On Jan 16, 2012, at 3:44 PM, Murray S. Kucherawy wrote: > One of the security area directors has placed a DISCUSS on the above = draft. The working group needs to talk about the issue raised and = determine how to proceed. >=20 > The specific issue is that a simple hash over a key prepended to the = data to be redacted is not a strong security measure. Although we've = mentioned that this isn't much of a concern in our case in the proposed = new text, the complaint has reappeared. For example, the simple = key-hash solution is susceptible to a few simple recovery attacks. >=20 > Among other things, the concern is that doing something like this on = the standards track might lead future efforts to believe this mechanism = is sufficient for arbitrary data protection when it is not. >=20 > The proposals going forward appear to be: >=20 > a) Instead of a hash of key + data, replace the algorithm with HMAC, = as defined in RFC2104. >=20 > b) Add even more explanatory text so that the reader has it clear that = we are not attempting to completely secure something here, and = acknowledge fully that there are weaknesses in our algorithm. (The = Wikipedia page for HMAC gives a pretty good description of the = comparison and attacks.) >=20 > c) Attempt to argue that it's good enough as it is, and that's how we = want it. >=20 > Comments, please. b, kinda. I'd like to add an alternative hash with the following algorithm: 1. ROT13 2. Suffix with a semicolon That way "steve@blighty.com" would translate to "fgrir;@blighty.com" That makes the email address illegal, so it cannot be mailed = accidentally, and also means it can't be unthinkingly copied and pasted = into a message (or made usefully clickable by a zealous MUA or...).=20 For many purposes, that is a strong enough hash. For this particular = purpose it might be considered a better choice than SHA* by some = participants, simply because it is reversible and so will allow the = recipient of a report to take action that they might not otherwise be = able to do. OK, it's a slightly frivolous suggestion, but clarifying that the = encoding used only needs to be as strong as the entity redacting the = message wants it to be might avoid all the concerns about security.=20 The only thing that's required for the redaction not to break incident = aggregation workflow - and hence be better than xxxxxx@ - is for it to = be a 1:1 encoding. Beyond that, the choice of strength of encoding - on = the spectrum between the identity hash ("steve" -> "steve") and an = arbitrary mapping maintained privately by the report generator ("steve" = -> "4783256") - is a policy choice made by the report generator. Cheers, Steve From shmuel+gen@patriot.net Mon Jan 16 18:59:01 2012 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 CDFB121F85D1 for ; Mon, 16 Jan 2012 18:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 yeSXbpRPPvcs for ; Mon, 16 Jan 2012 18:59:01 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3912E21F85CD for ; Mon, 16 Jan 2012 18:59:01 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.52]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id A2E06F580A3 for ; Mon, 16 Jan 2012 21:45:02 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 16 Jan 2012 19:48:37 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120117024502.A2E06F580A3@smtp.patriot.net> Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 02:59:01 -0000 In , on 01/16/2012 at 03:44 PM, "Murray S. Kucherawy" said: >b) Add even more explanatory text so that the reader has it clear >that we are not attempting to completely secure something here, and >acknowledge fully that there are weaknesses in our algorithm. (The >Wikipedia page for HMAC gives a pretty good description of the >comparison and attacks.) That's my preferred option. -- 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 sklist@kitterman.com Mon Jan 16 19:18:32 2012 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 C659321F8603 for ; Mon, 16 Jan 2012 19:18:32 -0800 (PST) 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 l5ZJBEjM3mkC for ; Mon, 16 Jan 2012 19:18:32 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 32F6821F854F for ; Mon, 16 Jan 2012 19:18:32 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CCF4120E40B1; Mon, 16 Jan 2012 22:18:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326770309; bh=Gx5RdZApoYZJJN5c5v303IMJYX9DZVwf6XBwQwLKkh0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=QHpxOEvJ3MyJLadJtwiLXEi5dt0Ytgdz5BN0w+wIM02qAwYljN3Ei3JqNxsY9Uyrc KZMZeSPFxRhCKOTr55tT+4VbeXktIbtmfiKZzGGNx+rdqdwDsduNuG0BKV4L7JpdC4 EXHwNUv90/NngzX6DF8jY6gN+WvMkA8ln/lz8fzw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ACBFF20E408E; Mon, 16 Jan 2012 22:18:29 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 16 Jan 2012 22:18:29 -0500 Message-ID: <2174297.fZ14yGBs1Q@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 03:18:32 -0000 On Monday, January 16, 2012 03:44:08 PM Murray S. Kucherawy wrote: ... > b) Add even more explanatory text so that the reader has it clear that we > are not attempting to completely secure something here, and acknowledge > fully that there are weaknesses in our algorithm. (The Wikipedia page for > HMAC gives a pretty good description of the comparison and attacks.) > > c) Attempt to argue that it's good enough as it is, and that's how we want > it. ... Either B or C would be my preference. Scott K From johnl@iecc.com Mon Jan 16 21:18:54 2012 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 3954221F858E for ; Mon, 16 Jan 2012 21:18:54 -0800 (PST) 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=-2.091, BAYES_05=-1.11, 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 uI0vPEl85ux4 for ; Mon, 16 Jan 2012 21:18:53 -0800 (PST) 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 89EBF21F8589 for ; Mon, 16 Jan 2012 21:18:53 -0800 (PST) Received: (qmail 43061 invoked from network); 17 Jan 2012 05:18:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Jan 2012 05:18:50 -0000 Date: 17 Jan 2012 05:18:28 -0000 Message-ID: <20120117051828.1523.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] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 05:18:54 -0000 >b) Add even more explanatory text so that the reader has it clear that we are not attempting to completely >secure something here, and acknowledge fully that there are weaknesses in our algorithm. (The Wikipedia page >for HMAC gives a pretty good description of the comparison and attacks.) > >c) Attempt to argue that it's good enough as it is, and that's how we want it. Since, as we all know, this is an argument about the thickness of a steel door that is securing a cardboard box, my preference is for C. If they're adamant, B would be OK. This is kind of an unusual application for hashing, since the goal is to leak some information. Many measures that make sense in secure environments, notably key rotation, would be counterproductive here. Also, it doesn't even have to be a hash. If I kept a database of mail recipients, and used the record number in the database, that would work just as well. R's, John From vesely@tana.it Tue Jan 17 09:17:41 2012 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 ED53D21F859B for ; Tue, 17 Jan 2012 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=0.105, 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 bYkSM1pGZGCA for ; Tue, 17 Jan 2012 09:17:40 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89821F8579 for ; Tue, 17 Jan 2012 09:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326820658; bh=YC1/ZtIo6dR08/Z3l0fi5UDFJcvG+vhl9Pk7ap37oio=; l=1292; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=HVgcTgFZtfG39NMjpOgT9z5AM00RwRA+McvjK+3yYbLS3/7qVPoh32R5+udyFmiJu t77E8B2SGa8zGy7pI6YGSIr+wlbf9BGifzEFAxKB/3ZZzYn25MqzaDNnE3ePDPtvyM PgU/gAXSPFvYaz2PywzIEhUEJ+7xzXikyvmVI4oE= 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, 17 Jan 2012 18:17:38 +0100 id 00000000005DC042.000000004F15AD32.0000394B Message-ID: <4F15AD31.9000402@tana.it> Date: Tue, 17 Jan 2012 18:17:37 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <9F647D63-D0BC-4355-8A7A-0CBE160557DA@wordtothewise.com> In-Reply-To: <9F647D63-D0BC-4355-8A7A-0CBE160557DA@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 17 Jan 2012 17:17:41 -0000 On 17/Jan/12 01:42, Steve Atkins wrote: > On Jan 16, 2012, at 3:44 PM, Murray S. Kucherawy wrote: >> >> b) Add even more explanatory text so that the reader has it clear >> that we are not attempting to completely secure something here, >> and acknowledge fully that there are weaknesses in our algorithm. >> (The Wikipedia page for HMAC gives a pretty good description of >> the comparison and attacks.) I see no reason why HMAC wouldn't be an acceptable choice. However, I'd like the phrase "steel lock on a cardboard box" to be part of any paragraph (of that I-D) where "HMAC" will appear. It should be clarified that the algorithm is somewhat unimportant, as long as it's (almost) 1:1. ROT13, using the (hashed) record number, or slightly truncating base64 strings (any padding "=" in particular) are alternatives that could be mentioned in order to convey that idea. > 1. ROT13 > 2. Suffix with a semicolon > > That way "steve@blighty.com" would translate to "fgrir;@blighty.com" > > That makes the email address illegal, so it cannot be mailed > accidentally, and also means it can't be unthinkingly copied and > pasted into a message (or made usefully clickable by a zealous MUA > or...). +1 for the semicolon, cute way to mark diligent 1:1 redaction! From msk@cloudmark.com Tue Jan 17 11:51:45 2012 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 4672911E808D for ; Tue, 17 Jan 2012 11:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.016, 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 nAVpsyWDUx6r for ; Tue, 17 Jan 2012 11:51:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4656511E807F for ; Tue, 17 Jan 2012 11:51:44 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 17 Jan 2012 11:51:35 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 17 Jan 2012 11:51:43 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 17 Jan 2012 11:51:42 -0800 Thread-Topic: Last Calls ending tomorrow Thread-Index: AczVUW+Die6znTdxTGWf0HSanFh3CA== 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_F5833273385BB34F99288B3648C4F06F19C6C158C7EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Last Calls ending tomorrow 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, 17 Jan 2012 19:51:45 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C158C7EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF-wide Last Calls for draft-ietf-marf-redaction and draft-ietf-authf= ailure-report end tomorrow afternoon. In response to IESG comments (includ= ing the open DISCUSS) and the various reviews by the area review teams, I h= ave the following two change sets prepared. I plan to get them posted (wit= h Hilda's help, of course) tomorrow as soon as the LCs close so that they'r= e ready for Thursday's IESG telechat. For draft-ietf-marf-redaction: http://www.blackops.org/~msk/marf.html For draft-ietf-marf-authfailure-report: http://www.blackops.org/~msk/marf2.= html I believe all of these changes are either innocuous or already have working= group consensus, so I'm only concerned about anyone that might disagree. = Absent any objection, I'll post them as scheduled tomorrow afternoon. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C158C7EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IETF-wide La= st Calls for draft-ietf-marf-redaction and draft-ietf-authfailure-report en= d tomorrow afternoon.  In response to IESG comments (including the ope= n DISCUSS) and the various reviews by the area review teams, I have the fol= lowing two change sets prepared.  I plan to get them posted (with Hild= a’s help, of course) tomorrow as soon as the LCs close so that they&#= 8217;re ready for Thursday’s IESG telechat.

 

For draft-ietf-marf-red= action: http://www.black= ops.org/~msk/marf.html

For draft-iet= f-marf-authfailure-report: http://www.blackops.org/~msk/marf2.html

 

I believe all of these ch= anges are either innocuous or already have working group consensus, so I= 217;m only concerned about anyone that might disagree.  Absent any obj= ection, I’ll post them as scheduled tomorrow afternoon.

 

-MSK

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C158C7EXCHC2corpclo_-- From internet-drafts@ietf.org Wed Jan 18 10:28:14 2012 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 4CFA621F876E; Wed, 18 Jan 2012 10:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 C-7m1wKpQJ11; Wed, 18 Jan 2012 10:28:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37521F8716; Wed, 18 Jan 2012 10:27:56 -0800 (PST) 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.64p1 Message-ID: <20120118182756.869.96505.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 10:27:56 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-05.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, 18 Jan 2012 18:28:14 -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 M. Kucherawy Filename : draft-ietf-marf-redaction-05.txt Pages : 8 Date : 2012-01-18 Email messages often contain information that 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-05.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-05.txt From internet-drafts@ietf.org Wed Jan 18 14:53:46 2012 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 A712B11E80D3; Wed, 18 Jan 2012 14:53:46 -0800 (PST) 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 6D5bK7t1o5-h; Wed, 18 Jan 2012 14:53:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21A911E80B9; Wed, 18 Jan 2012 14:53:45 -0800 (PST) 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.64p1 Message-ID: <20120118225345.17574.66217.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 14:53:45 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-10.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, 18 Jan 2012 22:53:46 -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-10.txt Pages : 21 Date : 2012-01-18 This memo registers an extension report type to the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-10.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-10.txt From presnick@qualcomm.com Thu Jan 19 15:53:14 2012 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 517CE21F8568 for ; Thu, 19 Jan 2012 15:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 78aZq-1adT5D for ; Thu, 19 Jan 2012 15:53:13 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC721F858E for ; Thu, 19 Jan 2012 15:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327017193; x=1358553193; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F18ACA8.2010309@qualcomm.com>|Date:=20Th u,=2019=20Jan=202012=2015:52:08=20-0800|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20Message=20Abuse=20Report=20Format =20working=20group=20|Subject:=20Re:=20[ma rf]=20DISCUSS=20on=20draft-ietf-marf-redaction-04 |References:=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=xMBQHqEbhWToNGqIrK/pZkwNWAtss5SQ+LCCeOvbgsU=; b=TK/2kINxyCe/p5MHGlL27UMvG27zYOaLYd0MLwjSsYARxqa/aj0loMQD hqw4uL5tuYIavnZAbro+8inhbUIaykSkNhtCe6hZYBHe6UMR1G2/6pTjW Vob4XBsa726bCohNprhcJchCFv7Qk+Q7U6pJfzM+TvgICthnywIqGaIa6 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6594"; a="154168271" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 19 Jan 2012 15:53:13 -0800 X-IronPort-AV: E=Sophos;i="4.71,536,1320652800"; d="scan'208";a="188493150" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 19 Jan 2012 15:53:13 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 19 Jan 2012 15:53:08 -0800 Message-ID: <4F18ACA8.2010309@qualcomm.com> Date: Thu, 19 Jan 2012 15:52:08 -0800 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 19 Jan 2012 23:53:14 -0000 On 1/16/12 3:44 PM, Murray S. Kucherawy wrote: > One of the security area directors has placed a DISCUSS on the above draft. The working group needs to talk about the issue raised and determine how to proceed. > > The specific issue is that a simple hash over a key prepended to the data to be redacted is not a strong security measure. Although we've mentioned that this isn't much of a concern in our case in the proposed new text, the complaint has reappeared. For example, the simple key-hash solution is susceptible to a few simple recovery attacks. > > Among other things, the concern is that doing something like this on the standards track might lead future efforts to believe this mechanism is sufficient for arbitrary data protection when it is not. > > The proposals going forward appear to be: > > a) Instead of a hash of key + data, replace the algorithm with HMAC, as defined in RFC2104. > > b) Add even more explanatory text so that the reader has it clear that we are not attempting to completely secure something here, and acknowledge fully that there are weaknesses in our algorithm. (The Wikipedia page for HMAC gives a pretty good description of the comparison and attacks.) > > c) Attempt to argue that it's good enough as it is, and that's how we want it. > I wanted to give you all the summary of the DISCUSSion on the IESG call so that you can decide what you would like to do, but I'd also personally like to understand the WG's position. So first on my questions: The argument against (a) seems to be "HMAC is overkill because the data can be retrieved other ways." Indeed, one of the (perhaps sarcastic) claims was that ROT13 would be as useful as the simple hash. But if there is any truth to these arguments, it leads me to ask: Why even bother with redaction at all? Why not write a document that says, "Redaction is stupid because all of the data can be retrieved by other means and when you do it stupidly (like with X's), it screws up our ability to do useful things with the report."? If it's truly a cardboard box, why not say, "Don't put a lock on this!"? If the answer is, "because people insist on putting a lock on", then I think it's reasonable for someone to say, "Hey, the lock you're selling to these people is either made of cardboard itself, or everyone has a key, or whatever, and you had either better tell them about that, or just sell them a real lock." In other words, I don't see any harm in using HMAC, other than it's as much of a waste of time as doing a simple hash or ROT13 or nothing at all. So could someone explain why choosing HMAC is any more silly than doing the hash? Or why there is any objection to doing HMAC (since it isn't hard to do)? That said, as of today's telechat, the IESG in general (and Stephen in particular, who holds the DISCUSS) are fine with either (a) or (b) and Stephen will clear his DISCUSS and I will approve the document once you do one or the other in the doc. But do understand that (b) means explaining that MD5 is a bad plan, and empty data is a bad plan, and all of the other caveats of using a simple hash. If the WG is willing to put that stff into security considerations, nobody is going to hold up the document. On the other hand, we will be left wondering, cause it seems a bit silly not to just use HMAC. But it is up to the WG. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From david.black@emc.com Thu Jan 19 16:10:46 2012 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 D2E7E21F86F4; Thu, 19 Jan 2012 16:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.886 X-Spam-Level: X-Spam-Status: No, score=-108.886 tagged_above=-999 required=5 tests=[AWL=1.713, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 L4CLdJHhqqSz; Thu, 19 Jan 2012 16:10:46 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E166C21F86F2; Thu, 19 Jan 2012 16:10:45 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K0AZDZ016597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 19:10:36 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 19 Jan 2012 19:10:27 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K0APxC012700; Thu, 19 Jan 2012 19:10:26 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Thu, 19 Jan 2012 19:10:25 -0500 From: To: , , , Date: Thu, 19 Jan 2012 19:10:24 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-05 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQG/Hm+w Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1028@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com, david.black@emc.com, marf@ietf.org Subject: [marf] Gen-ART review of draft-ietf-marf-redaction-05 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, 20 Jan 2012 00:10:47 -0000 Based on discussion with the authors, the -05 version of this draft resolve= s the issues raised in the Gen-ART review of the -04 version. An important eleme= nt of the approach taken to issue [1] has been to explain why the security requir= ements for redaction are significantly weaker than the strength of the secure hash= es that are suggested by the draft. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, January 10, 2012 9:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: Black, David; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, please > see the FAQ at . >=20 > Please resolve these comments along with any other Last Call comments you= may receive. >=20 > Document: draft-ietf-marf-redaction-04 > Reviewer: David L. Black > Review Date: January 10, 2012 > IETF LC End Date: January 18, 2011 > IESG Telechat Date: January 19, 2011 >=20 > Summary: This draft is on the right track but has open issues, described = in the review. >=20 > This draft specifies a method for redacting information from email abuse = reports > (e.g., hiding the local part [user] of an email address), while still all= owing > correlation of the redacted information across related abuse reports from= the same > source. The draft is short, clear, and well written. >=20 > There are two open issues: >=20 > [1] The first open issue is the absence of security guidance to ensure th= at this > redaction technique effectively hides the redacted information. The reda= ction > technique is to concatenate a secret string (called the "redaction key") = to the > information to be redacted, apply "any hashing/digest algorithm", convert= the output > to base64 and use that base64 string to replace the redacted information. >=20 > There are two important ways in which this technique could fail to effect= ively hide > the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. >=20 > To take an extreme example, if the secret string ("redaction key") consis= ts of a > single ASCII character, and a short email local part is being redacted, t= hen the > output is highly vulnerable to dictionary and brute force attacks because= only 6 bits > of entropy are added (the result may look secure, but it's not). Beyond = this extreme > example, this is a potentially real concern - e.g., applying the rule of = thumb that > ASCII text contains 4-5 bits of entropy per character, the example in App= endix A > uses a "redaction key" of "potatoes" that injects at most 40 bits of entr= opy - > is that sufficient for email redaction purposes? >=20 > To take a silly example, if a CRC is used as the hash with that sort of s= hort input, > the result is not particularly difficult to invert. >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash,= and > explain what is meant by "secure hash" in the security considerations se= ction. > 2) Require a minimum length of the "redaction key" string, and strongly s= uggest > (SHOULD) that it be randomly generated (e.g., by running sufficient outp= ut > of an entropy-rich random number generator through a base64 converter). >=20 > For the latter change, figure out the amount of entropy that should be us= ed > for redaction - the recommended string length will be larger because prin= table > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in ea= ch > 8-bit character, and human-written text such as this message has signific= antly > less). >=20 > From a pure security perspective, use of HMAC with specified secure hashe= s > (SHA2-family) and an approach of hashing the "redaction key" down to a bi= nary > key for HMAC would be a stronger approach. I suggest that authors conside= r > approach, but there may be practical usage concerns that suggest not ado= pting it. >=20 > [2] The second open issue is absence of security considerations for the r= edaction > key. The security considerations section needs to caution that the redac= tion key > is a secret key that must be managed and protected as a secret key. Disc= losure > of a redaction key removes the redaction from all reports that used that = key. > As part of this, guidance should be provided on when and how to change th= e > redaction key in order to limit the effects of loss of secrecy for a sing= le > redaction key. >=20 > Editorial Nit: I believe that "anonymization" is a better description of = what > this draft is doing (as opposed to "redaction"), particularly as the resu= lt is > intended to be correlatable via string match across reports from the same= source. >=20 > idnits 2.12.13 didn't find any nits. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From msk@cloudmark.com Thu Jan 19 16:20:12 2012 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 E0C4221F85F6 for ; Thu, 19 Jan 2012 16:20:12 -0800 (PST) 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 9bkfEgqCMSZL for ; Thu, 19 Jan 2012 16:20:12 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 888EF21F8597 for ; Thu, 19 Jan 2012 16:20:11 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jan 2012 16:20:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 19 Jan 2012 16:20:09 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 19 Jan 2012 16:20:09 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXBYUhSwvsaTQDTrqmp8pMpB+NeAAAMj0w Message-ID: References: <4F18ACA8.2010309@qualcomm.com> In-Reply-To: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 00:20:13 -0000 As a participant, I don't have any particular skin in this argument, so I'l= l go with consensus, which I'm supposed to do as co-chair anyway. :-) The one thing not mentioned so far is the fact that there's tell of sites t= hat have implemented the H (hash-key) scheme as we currently have it, versu= s HMAC. More specifically, there's one large European ISP that has said th= ey have implemented what the -04 version of this draft said. I don't know = if there are others, nor do I know if they are tracking this work well enou= gh to know they should change if the WG decides to move to HMAC. We can't argue, though, that this creates an interop concern with the exist= ing deployed base, because there's no actual interoperation in the traditio= nal client/server sense here; if one party is doing it with H and one is do= ing it with HMAC, they're going to get the same results in the end anyway, = minus a few possible paths to stealing the redaction key (even though, as w= e've said, there are easier ways to mount that attack) in the HMAC case. -MSK From msk@cloudmark.com Thu Jan 19 16:47:02 2012 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 63D7821F84FE for ; Thu, 19 Jan 2012 16:47:02 -0800 (PST) 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 OSrwBkJQ3UFm for ; Thu, 19 Jan 2012 16:47:02 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF521F84CF for ; Thu, 19 Jan 2012 16:47:01 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jan 2012 16:46:52 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 19 Jan 2012 16:47:01 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 19 Jan 2012 16:47:00 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXBYUhSwvsaTQDTrqmp8pMpB+NeAABkyWg Message-ID: References: <4F18ACA8.2010309@qualcomm.com> In-Reply-To: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 00:47:02 -0000 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Thursday, January 19, 2012 3:52 PM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > If the answer is, "because people insist on putting a lock on", then I > think it's reasonable for someone to say, "Hey, the lock you're selling > to these people is either made of cardboard itself, or everyone has a > key, or whatever, and you had either better tell them about that, or > just sell them a real lock." In other words, I don't see any harm in > using HMAC, other than it's as much of a waste of time as doing a > simple hash or ROT13 or nothing at all. It's my understanding that "people insist" is indeed the answer. It's a ch= ecklist item that local policy imposes. The simple string substitution red= action that first appeared made the feedback system work less well because = it made correlation impossible, and this is the proposed solution. It's no= t meant to be bulletproof, just good enough to satisfy both the policy peop= le that wand some kind of redaction and the technical people that have to f= ind a non-destructive way to do it. > So could someone explain why choosing HMAC is any more silly than doing > the hash? It's not more silly. The point is that H is good enough to achieve the abo= ve goals. If there's a scale from 0 to N where the goal is achieved at, sa= y, 5, H gets us to 5 while HMAC gets us to 10000. It just seems like overk= ill, especially since mounting an attack against H is probably more expensi= ve than just log trolling. > Or why there is any objection to doing HMAC (since it isn't > hard to do)? I don't recall any objection beyond the above. > But it is up to the WG. Yup. I'm ready to make whichever change gets consensus. -MSK From barryleiba.mailing.lists@gmail.com Thu Jan 19 17:07:20 2012 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 153AB21F858F for ; Thu, 19 Jan 2012 17:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.822 X-Spam-Level: X-Spam-Status: No, score=-102.822 tagged_above=-999 required=5 tests=[AWL=0.155, 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 XztJDonU1qJc for ; Thu, 19 Jan 2012 17:07:19 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA72721F858B for ; Thu, 19 Jan 2012 17:07:18 -0800 (PST) Received: by ggnr5 with SMTP id r5so25977ggn.31 for ; Thu, 19 Jan 2012 17:07:18 -0800 (PST) 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:cc:content-type; bh=ooEpeD26+6V9mUVj5VIS6hGdVQ64sNhIyVKs799Q/Fw=; b=L7J/hjeURJY8Adu1vT7JW5gkCMpJ+M/2gwGWkNLJ6L+JpwK/at/7Tj3PaFDPShrJxR +ZUDa08rb6Mj0l7wgVBFdh+A4hbpno/jfOsSO/ttWPH3IUUNsdewqbkZreN+ITApMr+K OasmqDLaGcWFZfIfLZAVUcBYq9ZBLYq5Qz3VI= MIME-Version: 1.0 Received: by 10.101.155.14 with SMTP id h14mr7698176ano.25.1327021637170; Thu, 19 Jan 2012 17:07:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Thu, 19 Jan 2012 17:07:17 -0800 (PST) In-Reply-To: <4F18ACA8.2010309@qualcomm.com> References: <4F18ACA8.2010309@qualcomm.com> Date: Thu, 19 Jan 2012 20:07:17 -0500 X-Google-Sender-Auth: UC-TiUTbsEWHcYE9uQL_7cXizSk Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 01:07:20 -0000 > Indeed, one of the (perhaps sarcastic) claims was > that ROT13 would be as useful as the simple hash. But if there is any truth > to these arguments, it leads me to ask: Why even bother with redaction at > all? Why not write a document that says, "Redaction is stupid because all of > the data can be retrieved by other means and when you do it stupidly (like > with X's), it screws up our ability to do useful things with the report."? > If it's truly a cardboard box, why not say, "Don't put a lock on this!"? > > If the answer is, "because people insist on putting a lock on" Yes, as Murray has said. But this reminds me, and perhaps you (Pete) can talk with Stephen and Sean about this: Several (as opposed to a few) IETF meetings ago, there was discussion (from a presentation by EKR, if I remember correctly) about the usefulness of defining what is *specifically* an INSECURE hash. Do something like, say, re-define MD5 and call it "IHA-1" (Insecure Hash Algorithm 1). Then it could be used in cases where a hash was needed, but there was no security need for the hash, and no one would say, "Oh! Oh! You can't use MD5! It's too weak and vulnerable! Oh!" (Think Arnold Horshack here, for those young enough to understand the reference.) This is exactly one of those use cases. But we never defined any IHA-1, and so we have to either say, "Use any damned hash you want (CRC included, to use David Black's silly example from the GenART review), because it doesn't matter, and if *you* want to make it more secure, because, you know, your local policy demands it, well, then, that's fine, and you know how to do it," or else succumb to pressure to kick it into crypto orbit with HMAC because "It's not hard." Go back and read EKR's slides from SAAG at IETF 73: http://www.ietf.org/proceedings/73/slides/saag-0.pdf ...and tell me that it really matters that we say *anything* about what hash to use. Barry , then I think > it's reasonable for someone to say, "Hey, the lock you're selling to these > people is either made of cardboard itself, or everyone has a key, or > whatever, and you had either better tell them about that, or just sell them > a real lock." In other words, I don't see any harm in using HMAC, other than > it's as much of a waste of time as doing a simple hash or ROT13 or nothing > at all. > > So could someone explain why choosing HMAC is any more silly than doing the > hash? Or why there is any objection to doing HMAC (since it isn't hard to > do)? > > That said, as of today's telechat, the IESG in general (and Stephen in > particular, who holds the DISCUSS) are fine with either (a) or (b) and > Stephen will clear his DISCUSS and I will approve the document once you do > one or the other in the doc. But do understand that (b) means explaining > that MD5 is a bad plan, and empty data is a bad plan, and all of the other > caveats of using a simple hash. If the WG is willing to put that stff into > security considerations, nobody is going to hold up the document. On the > other hand, we will be left wondering, cause it seems a bit silly not to > just use HMAC. > > But it is up to the WG. > > pr > > -- > Pete Resnick > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From sklist@kitterman.com Thu Jan 19 20:03:11 2012 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 229C321F84D9 for ; Thu, 19 Jan 2012 20:03:11 -0800 (PST) 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 7PjdNaxus3B1 for ; Thu, 19 Jan 2012 20:03:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 241C521F8497 for ; Thu, 19 Jan 2012 20:03:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CCF3C20E40B7; Thu, 19 Jan 2012 23:03:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327032187; bh=mr9Grc+zVpbOrVQIKimk6jzdc0bDHwk2YbT0MbGEWlo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=alpQ9orAVmgPbkwkq06ES8zQ+bm4dN55VDQRjgN1XFHV6PwfK/unUdaKboJ4Cy1e1 V8veC+IBkj7opTIdUb4BUE1vS9Omg9+0W9xSqRj4l4PvZAJ148pVdsj2c6CyS4lhB9 ViDtgWb1kgwH02bzLWJ7D6b5OytANDF+Iv7j16Ms= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ADF5320E40A4; Thu, 19 Jan 2012 23:03:07 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 19 Jan 2012 23:03:03 -0500 Message-ID: <4256895.zqe0nyDCYF@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 04:03:11 -0000 On Thursday, January 19, 2012 04:47:00 PM Murray S. Kucherawy wrote: > > So could someone explain why choosing HMAC is any more silly than doing > > the hash? > > It's not more silly. The point is that H is good enough to achieve the > above goals. If there's a scale from 0 to N where the goal is achieved at, > say, 5, H gets us to 5 while HMAC gets us to 10000. It just seems like > overkill, especially since mounting an attack against H is probably more > expensive than just log trolling. > > Or why there is any objection to doing HMAC (since it isn't > > hard to do)? > > I don't recall any objection beyond the above. My objection is it's overkill. Over specifying because someone is afraid that someday someone may point to this as an example to be insecure when it does matter is a silly reason. Scott K From johnl@iecc.com Thu Jan 19 20:05:21 2012 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 3C17021F853D for ; Thu, 19 Jan 2012 20:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.356 X-Spam-Level: X-Spam-Status: No, score=-107.356 tagged_above=-999 required=5 tests=[AWL=2.354, BAYES_05=-1.11, 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 TzUEeVAmeVLC for ; Thu, 19 Jan 2012 20:05:20 -0800 (PST) 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 40D2E21F8584 for ; Thu, 19 Jan 2012 20:05:20 -0800 (PST) Received: (qmail 51784 invoked from network); 20 Jan 2012 04:05:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jan 2012 04:05:19 -0000 Date: 20 Jan 2012 04:04:57 -0000 Message-ID: <20120120040457.43320.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4F18ACA8.2010309@qualcomm.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: presnick@qualcomm.com Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 04:05:21 -0000 > If it's truly a cardboard box, why not say, "Don't put a lock on this!"? Lawyers, of course. But having talked to some of the people who do redaction, it's not quite as stupid as it might seem. The party that originally sent the mail can in most cases figure out who they sent message to, either by comparing logs or by looking at other clues in the message. People who didn't send the message generally can't. So in the not uncommon case that you're sending FBL data to a provider which has customers who run their own mail servers, the customers who sent the mail can de-redact if the provider forwards them the reports. The provider can't, but can still use the hash to help figure out whether their customers are misbehaving. >So could someone explain why choosing HMAC is any more silly than doing >the hash? Or why there is any objection to doing HMAC (since it isn't >hard to do)? It just seems pointless. The suggestions for key rotation were actively misguided. R's, John From msk@cloudmark.com Thu Jan 19 23:16:04 2012 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 653DD21F85DB for ; Thu, 19 Jan 2012 23:16:04 -0800 (PST) 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 9B7gRaiRvGc2 for ; Thu, 19 Jan 2012 23:16:03 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E430721F85D2 for ; Thu, 19 Jan 2012 23:16:03 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jan 2012 23:16:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.23.1.2]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 19 Jan 2012 23:16:03 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 19 Jan 2012 23:16:03 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXD91xJjb0vidFRGusrRNKiHQfgQAMxMWA Message-ID: References: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 07:16:04 -0000 Would a path forward be to do this?: 1) Change the algorithm in Section 2 to use HMAC. 2) Add a Section 2.1 that talks about extant implementation(s) that use onl= y H, even though it's known to be attackable, because (reasons to tolerate = the vulnerabilities that we've already given). From barryleiba.mailing.lists@gmail.com Fri Jan 20 09:54:17 2012 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 97B6A21F8637 for ; Fri, 20 Jan 2012 09:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=0.145, 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 u3CCFQuREtMR for ; Fri, 20 Jan 2012 09:54:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8430221F850D for ; Fri, 20 Jan 2012 09:53:53 -0800 (PST) Received: by yhnn12 with SMTP id n12so433907yhn.31 for ; Fri, 20 Jan 2012 09:53:53 -0800 (PST) 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:cc:content-type; bh=NpJGGjaJbcbeP9k9ZokUkaWFNWS9lVX+Ykebf3OuZg8=; b=w2obA66KeYEstmrBDEoCrgbuJB1btHYfJXjH7frYizFQZpAG4/3O9T28MwrE7N+UO6 1MnWVIpjQ8pSNE7mUk2FmqfAp96TP5gTJzrdCvuvRctEWjRj0YkXnF0+0Y7pVOkNbov+ W1CE+bI/lfwaLvviv9dpqfvEDu5/0+aftRfUU= MIME-Version: 1.0 Received: by 10.236.152.35 with SMTP id c23mr46621938yhk.58.1327082033187; Fri, 20 Jan 2012 09:53:53 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Fri, 20 Jan 2012 09:53:53 -0800 (PST) In-Reply-To: References: <4F18ACA8.2010309@qualcomm.com> Date: Fri, 20 Jan 2012 12:53:53 -0500 X-Google-Sender-Auth: HodG-8QrTXYMnUHOCMQC1_YpOtI Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 17:54:17 -0000 > Would a path forward be to do this?: > > 1) Change the algorithm in Section 2 to use HMAC. My objection to that path forward is that there's NO interoperability benefit given by prescribing any hash function. What this document does for interoperability is define a mechanism that, if used consistently, will provide the interop we want/need. It only matters that the redactor consistently use the same hashing. It doesn't matter AT ALL *what* that hashing is. I think it's not a good idea to over-specify. I think the way forward is to explain why we don't need cryptographic security here, and why the specific hash function chosen doesn't matter, as long as the redacted value stays the same for the same unredacted input. And that's all. Barry From msk@cloudmark.com Fri Jan 20 10:06:25 2012 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 09ED521F84D0 for ; Fri, 20 Jan 2012 10:06:25 -0800 (PST) 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 2-7JtHH7papk for ; Fri, 20 Jan 2012 10:06:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4B12F21F8475 for ; Fri, 20 Jan 2012 10:06:24 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 10:06:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 20 Jan 2012 10:06:23 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 10:06:22 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXnHzJHihQ7Yo3TvO/wbqfhrSb1wAASbvA Message-ID: References: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 18:06:25 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Friday, January 20, 2012 9:54 AM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > I think the way forward is to explain why we don't need cryptographic > security here, and why the specific hash function chosen doesn't > matter, as long as the redacted value stays the same for the same > unredacted input. And that's all. What do you think might be missing from the current Security Considerations= to nail this point home to the IESG's satisfaction? Basically, I thought = we'd done this already in -05. From shmuel+gen@patriot.net Fri Jan 20 10:28:01 2012 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 6F57021F855A for ; Fri, 20 Jan 2012 10:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_40=-0.185] 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 CcGNgwhBAFIZ for ; Fri, 20 Jan 2012 10:28:00 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 27DCB21F854A for ; Fri, 20 Jan 2012 10:27:45 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.237]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 6B650F58095 for ; Fri, 20 Jan 2012 13:13:43 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 20 Jan 2012 13:03:20 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120120181343.6B650F58095@smtp.patriot.net> Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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: Fri, 20 Jan 2012 18:28:01 -0000 In , on 01/20/2012 at 12:53 PM, Barry Leiba said: >I think the way forward is to explain why we don't need cryptographic >security here, and why the specific hash function chosen doesn't >matter, as long as the redacted value stays the same for the same >unredacted input. And that's all. ++ -- 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 sklist@kitterman.com Fri Jan 20 10:34:41 2012 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 6E9C721F8587 for ; Fri, 20 Jan 2012 10:34:41 -0800 (PST) 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 vbY8eDSyGaGr for ; Fri, 20 Jan 2012 10:34:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B422121F8579 for ; Fri, 20 Jan 2012 10:34:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D2D4A20E40B7; Fri, 20 Jan 2012 13:34:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327084479; bh=9jxItBz86NkIHuyy9SM8ZqH9rO6IoyuJrrgpcJj3+1c=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TK8pmd8/kLEKoEOxV5nrg1jgVVCJ+uWOD+TtroEjOsYxRCmfVHvik/JHetyKfxEgX pMlHbkzF4cbcCayv3UcBRuKCydJ2Ur57rjUVeLAk1Xk3+sX+00SepodeqhxFu/bf5p fX5JzPsCYqGsX3NK8tz2vxpp3awdyzy+nKVfLDzE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B3DEB20E4083; Fri, 20 Jan 2012 13:34:39 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 20 Jan 2012 13:34:39 -0500 Message-ID: <3918290.zWERXGxWRJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 18:34:41 -0000 On Friday, January 20, 2012 10:06:22 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: barryleiba.mailing.lists@gmail.com > > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > > Sent: Friday, January 20, 2012 9:54 AM > > To: Murray S. Kucherawy > > Cc: Message Abuse Report Format working group > > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 > > > > I think the way forward is to explain why we don't need cryptographic > > security here, and why the specific hash function chosen doesn't > > matter, as long as the redacted value stays the same for the same > > unredacted input. And that's all. > > What do you think might be missing from the current Security Considerations > to nail this point home to the IESG's satisfaction? Basically, I thought > we'd done this already in -05. If this issue, AIUI, is that someone is worried that later this will be referenced in an inappropriate way, I'm not sure what would satisfy that. I think it's already clear. Scott K From barryleiba.mailing.lists@gmail.com Fri Jan 20 10:35:10 2012 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 E2F0621F8579 for ; Fri, 20 Jan 2012 10:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.84 X-Spam-Level: X-Spam-Status: No, score=-102.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 nGJHJnPY6UqM for ; Fri, 20 Jan 2012 10:35:09 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8F7821F859B for ; Fri, 20 Jan 2012 10:35:08 -0800 (PST) Received: by yhnn12 with SMTP id n12so459255yhn.31 for ; Fri, 20 Jan 2012 10:35:08 -0800 (PST) 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:cc:content-type :content-transfer-encoding; bh=yKyvjDr9rzUIHq8J8/n7MPRJS0wWauKCsmbS4UiHh/w=; b=RbzbNUPeKnKdjiNMmb6ieNqUZ3N0GsEa4Iy+W5sCNxZB/gDPhIyf7mLriraSRWoKmZ rWhh48wO77szHf9IkDo+3mMuLWuyfND2y697x+fmPtovri3YxiOompuE9sKaPqUSz2EP 1qDaVQXfFsWSzGDejvqot/jfkGeyZ8Ce3L3VY= MIME-Version: 1.0 Received: by 10.236.152.35 with SMTP id c23mr46898091yhk.58.1327084508367; Fri, 20 Jan 2012 10:35:08 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Fri, 20 Jan 2012 10:35:08 -0800 (PST) In-Reply-To: References: <4F18ACA8.2010309@qualcomm.com> Date: Fri, 20 Jan 2012 13:35:08 -0500 X-Google-Sender-Auth: ZwkgOfl57iKjx8HR0CE6iGT3Hgg Message-ID: From: Barry Leiba 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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 18:35:11 -0000 >> I think the way forward is to explain why we don't need cryptographic >> security here, and why the specific hash function chosen doesn't >> matter, as long as the redacted value stays the same for the same >> unredacted input. =A0And that's all. > > What do you think might be missing from the current Security Consideratio= ns > to nail this point home to the IESG's satisfaction? =A0Basically, I thoug= ht we'd > done this already in -05. I'd thought so, as well, so I don't know the answer to your question. I'll be happy to try tossing out some text. Another thought occurred to me, from what Pete has said: Pete's question is, "Why NOT use HMAC?" That's the wrong question; it's the IESG overstepping its authority, if they insist that that's the question. The IESG is objecting to what the working group has come up with, and the burden is on them to show that what we have is not sufficient FOR THIS USE CASE. The question isn't, "Why NOT use HMAC?" The correct question is, "For our use case, WHY REQUIRE HMAC? What does it give us that is necessary for our use case?" The amount of "security" in the redaction is ENTIRELY up to the redactor. Given this spec, the redactor is welcome to use HMAC if they want to -- if they or their lawyers think they need that level of confidence that it can't be deciphered. Depending upon the redactor's sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC, or, hey, just base64-encode the plain-text string if all you want is to keep it away from idle eyes. It makes no sense for this spec to declare anything in this regard. Barry From msk@cloudmark.com Fri Jan 20 10:49:41 2012 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 9761E21F864F for ; Fri, 20 Jan 2012 10:49:41 -0800 (PST) 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 4iCjRt7rk90h for ; Fri, 20 Jan 2012 10:49:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 24D1A21F864A for ; Fri, 20 Jan 2012 10:49:40 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 10:49:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 20 Jan 2012 10:49:38 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 10:49:37 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXoj02lsjeYM+tSbyE/uN6mJC5GgAAU83g Message-ID: References: <4F18ACA8.2010309@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 18:49:41 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Friday, January 20, 2012 10:35 AM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > The amount of "security" in the redaction is ENTIRELY up to the > redactor. Given this spec, the redactor is welcome to use HMAC if they > want to -- if they or their lawyers think they need that level of > confidence that it can't be deciphered. Depending upon the redactor's > sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC, > or, hey, just base64-encode the plain-text string if all you want is to > keep it away from idle eyes. >=20 > It makes no sense for this spec to declare anything in this regard. Does that mean, in Section 2, we could replace steps 1 through 4 with somet= hing more generic, like simply "Apply any isomorphic transformation to each= instance of private data in this message", and suggest a range of possibil= ities from base64 to rot13 to CRC32 to H to HMAC, depending on the site's n= eeds, perhaps with requisite admonition to be aware of the strengths and we= aknesses of each? That would mean Section 3 becomes a lot simpler as well. From sm@resistor.net Fri Jan 20 11:00:41 2012 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 1E53321F8656 for ; Fri, 20 Jan 2012 11:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 VXaXJDEjNwDs for ; Fri, 20 Jan 2012 11:00:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65521F85ED for ; Fri, 20 Jan 2012 11:00:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0KJ0WF9000952; Fri, 20 Jan 2012 11:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327086037; i=@resistor.net; bh=lkjubnCjfAakeraTMKoFKy1V0/O4dOXbrAGS9/55jIc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cHXUS7qB9qN+5/kgds9HjlX9z11ZYbpJf6B49IkmKXVhnOBtfaghohFh/Uu+8Nnr4 Bq2uDHBaN+qN8cD1oYbxBxftbNZ2fGsXB98vNeOVcJs+uAeg7nahyA7muicPOVUH2Q sTWC0WcxoeO/RVwyneMaXJZIyAQICnrUc7S5xD7A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327086037; i=@resistor.net; bh=lkjubnCjfAakeraTMKoFKy1V0/O4dOXbrAGS9/55jIc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=EaOjqU6YSF1i81W/YCWr7/X2yVwP6vHU+IGwnE9mEPQBRfoXdghAN0bpKhV1ZHJfa ca/JalJIRLFgkTFYjDcn7o+BfKWDms/GTxOGaj4PhSyeuCySiLbcqZCBu4DelaiHLY 1k5RbYuZs32uONFodEi96rv50jnVXpwOfBEXsW60= Message-Id: <6.2.5.6.2.20120120104822.0a010078@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Jan 2012 10:57:59 -0800 To: Scott Kitterman From: SM In-Reply-To: <3918290.zWERXGxWRJ@scott-latitude-e6320> References: <3918290.zWERXGxWRJ@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 19:00:41 -0000 Hi Scott, At 10:34 20-01-2012, Scott Kitterman wrote: >If this issue, AIUI, is that someone is worried that later this will be >referenced in an inappropriate way, I'm not sure what would satisfy that. I >think it's already clear. I don't think so. One of the points mentioned by Murray [1] was: "the concern is that doing something like this on the standards track might lead future efforts to believe this mechanism is sufficient for arbitrary data protection when it is not." One of the questions asked by the Responsible AD [2] was: "why there is any objection to doing HMAC (since it isn't hard to do)?" The text from the DISCUSS is: "I don't think that's ok. I think you want HMAC() and not H(). If I could supply a redactor with a zero length "private" string, e.g. message with a header field like "To: @example.org" then the redactor will send H(redaction-key) which can then allow (via hash-continuation) checking if any value matches a value from an output here. If the alphabet for sensitive values has N characters then I can also send "To: "+char[i]+"@example.org" for each i and then play the continuation game on that. Same for two character prefixes etc. (2) I can also use this to validate guesses of the redaction key value. I need to think about how one might avoid that or if its possible to avoid that." Regards, -sm 1. http://www.ietf.org/mail-archive/web/marf/current/msg01681.html 2. http://www.ietf.org/mail-archive/web/marf/current/msg01691.html From barryleiba.mailing.lists@gmail.com Fri Jan 20 11:04:31 2012 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 2393221F85ED for ; Fri, 20 Jan 2012 11:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=0.129, 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 kUxUWQBazXeT for ; Fri, 20 Jan 2012 11:04:30 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA7121F85A1 for ; Fri, 20 Jan 2012 11:04:30 -0800 (PST) Received: by yenm3 with SMTP id m3so482674yen.31 for ; Fri, 20 Jan 2012 11:04:30 -0800 (PST) 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:cc:content-type :content-transfer-encoding; bh=nzqJdo6si0P5QQ4kbmQOoGozT+oLA1QtQVW7r5P9lhw=; b=wgTOTp1nDGE8iTppHJ25wrUB1jdrnZ8Z+aq0Oy1yjNtkiLc2TCQ6QZqh4/XkhxXYL6 hMGr/PMNBYfSMIzjjkSpd3gPnxPQSWxsVIy5/doTUcDxh9XFmJht8dGMPl8CS/4QPrbY uCg8bNOXQS2rXeJdCt+a+LTygvMrJBk83xs9k= MIME-Version: 1.0 Received: by 10.236.139.193 with SMTP id c41mr47653231yhj.24.1327086270206; Fri, 20 Jan 2012 11:04:30 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.114.13 with HTTP; Fri, 20 Jan 2012 11:04:30 -0800 (PST) In-Reply-To: References: <4F18ACA8.2010309@qualcomm.com> Date: Fri, 20 Jan 2012 14:04:30 -0500 X-Google-Sender-Auth: mkAKqjABwbyMkVjE6Mzhb-Ewrso Message-ID: From: Barry Leiba 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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 19:04:31 -0000 >> The amount of "security" in the redaction is ENTIRELY up to the >> redactor. =A0Given this spec, the redactor is welcome to use HMAC if the= y >> want to -- if they or their lawyers think they need that level of >> confidence that it can't be deciphered. =A0Depending upon the redactor's >> sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC, >> or, hey, just base64-encode the plain-text string if all you want is to >> keep it away from idle eyes. >> >> It makes no sense for this spec to declare anything in this regard. > > Does that mean, in Section 2, we could replace steps 1 through 4 with som= ething > more generic, like simply "Apply any isomorphic transformation to each in= stance > of private data in this message", and suggest a range of possibilities fr= om base64 > to rot13 to CRC32 to H to HMAC, depending on the site's needs, perhaps wi= th > requisite admonition to be aware of the strengths and weaknesses of each? > > That would mean Section 3 becomes a lot simpler as well. That would work for me. Barry From steve@wordtothewise.com Fri Jan 20 11:04:57 2012 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 12F1D21F85ED for ; Fri, 20 Jan 2012 11:04:57 -0800 (PST) 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 x-i0X9WI0yq2 for ; Fri, 20 Jan 2012 11:04:56 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7221F85A1 for ; Fri, 20 Jan 2012 11:04:56 -0800 (PST) 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 C77232DECF for ; Fri, 20 Jan 2012 11:04:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Fri, 20 Jan 2012 11:04:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> References: <4F18ACA8.2010309@qualcomm.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 19:04:57 -0000 On Jan 20, 2012, at 10:49 AM, Murray S. Kucherawy wrote: >>=20 >> The amount of "security" in the redaction is ENTIRELY up to the >> redactor. Given this spec, the redactor is welcome to use HMAC if = they >> want to -- if they or their lawyers think they need that level of >> confidence that it can't be deciphered. Depending upon the = redactor's >> sensibilities, they are also welcome to use plain SHA1, or MD5, or = CRC, >> or, hey, just base64-encode the plain-text string if all you want is = to >> keep it away from idle eyes. >>=20 >> It makes no sense for this spec to declare anything in this regard. >=20 > Does that mean, in Section 2, we could replace steps 1 through 4 with = something more generic, like simply "Apply any isomorphic transformation = to each instance of private data in this message", and suggest a range = of possibilities from base64 to rot13 to CRC32 to H to HMAC, depending = on the site's needs, perhaps with requisite admonition to be aware of = the strengths and weaknesses of each? I think that would improve it in general, as well as avoiding some of = the supposed security concerns. Cheers, Steve From msk@cloudmark.com Fri Jan 20 11:08:22 2012 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 9113421F8693 for ; Fri, 20 Jan 2012 11:08:22 -0800 (PST) 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 jS7frO-TVtSS for ; Fri, 20 Jan 2012 11:08:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3344B21F8685 for ; Fri, 20 Jan 2012 11:08:22 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 11:08:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 20 Jan 2012 11:08:21 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 11:08:20 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXpmfnXgEbdMpDQQeN0nehAIY7sAAAG0Sw Message-ID: References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> In-Reply-To: <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 19:08:22 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Friday, January 20, 2012 11:05 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > I think that would improve it in general, as well as avoiding some of > the supposed security concerns. Pete, do you think this approach would fly? From sklist@kitterman.com Fri Jan 20 11:40:43 2012 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 2959C21F8646 for ; Fri, 20 Jan 2012 11:40:43 -0800 (PST) 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 Aolrp6NK-vHg for ; Fri, 20 Jan 2012 11:40:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B37221F8533 for ; Fri, 20 Jan 2012 11:40:42 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8C77020E40B7; Fri, 20 Jan 2012 14:40:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327088441; bh=gjKWKyxbcdvDO25BGe3cg4xj4jXlguYIcBBs6IyKngI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=F6MMo1Qz1TDylMIkOBqLD2ly7llklYCye251NdA8PafAXI3sYX8EopgodshqrYXk7 hph/G/TGIENOe4EbTkam78ii4nohmeoSLqxpwocnDaG/LOeW9WVBJH5CoPCK848fwt zsteiVYpwyeA/fajRyQ/4hP7m2iiEmWjlhs0ZxUU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7EFB120E4083; Fri, 20 Jan 2012 14:40:35 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 20 Jan 2012 14:40:35 -0500 Message-ID: <1733819.O9iBQtYzuY@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120120104822.0a010078@resistor.net> References: <3918290.zWERXGxWRJ@scott-latitude-e6320> <6.2.5.6.2.20120120104822.0a010078@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 19:40:43 -0000 On Friday, January 20, 2012 10:57:59 AM SM wrote: > Hi Scott, > > At 10:34 20-01-2012, Scott Kitterman wrote: > >If this issue, AIUI, is that someone is worried that later this will be > >referenced in an inappropriate way, I'm not sure what would satisfy that. > >I think it's already clear. > > I don't think so. One of the points mentioned by Murray [1] was: > > "the concern is that doing something like this on the standards > track might lead future efforts to believe this mechanism is > sufficient for arbitrary data protection when it is not." > > One of the questions asked by the Responsible AD [2] was: > > "why there is any objection to doing HMAC (since it isn't hard to do)?" > > The text from the DISCUSS is: > > "I don't think that's ok. I think you want HMAC() and not H(). > > If I could supply a redactor with a zero length "private" string, > e.g. message with a header field like "To: @example.org" then the > redactor will send H(redaction-key) which can then allow (via > hash-continuation) checking if any value matches a value from an > output here. > > If the alphabet for sensitive values has N characters > then I can also send "To: "+char[i]+"@example.org" for > each i and then play the continuation game on that. > Same for two character prefixes etc. > > (2) I can also use this to validate guesses of the redaction > key value. I need to think about how one might avoid that > or if its possible to avoid that." > > Regards, > -sm > > 1. http://www.ietf.org/mail-archive/web/marf/current/msg01681.html > 2. http://www.ietf.org/mail-archive/web/marf/current/msg01691.html Thanks for the clarification. Scott K From msk@cloudmark.com Fri Jan 20 15:08:35 2012 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 32D9D21F858D for ; Fri, 20 Jan 2012 15:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 9XvMstKIOiLh for ; Fri, 20 Jan 2012 15:08:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 56E7F21F8587 for ; Fri, 20 Jan 2012 15:08:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 15:08:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 20 Jan 2012 15:08:33 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 15:08:33 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXpmfnXgEbdMpDQQeN0nehAIY7sAAAG0SwAAhPAOA= Message-ID: References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.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 Cc: Stephen Farrell Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 23:08:35 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Friday, January 20, 2012 11:08 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > Pete, do you think this approach would fly? Stephen, Barry and I like the proposed changes visible now at http://www.bl= ackops.org/~msk/marf.html. This would clear the discuss and allow publicat= ion as long as Pete also agrees. MARF participants, please review this and provide any feedback, including s= upport or requested changes. I'll post it Monday morning unless I hear som= e objection. I need to adjust the bit around the mention of encoding non-ASCII stuff bec= ause it might also be necessary to base64-encode redacted data if the redac= ted form includes spaces, but that's a very minor change. -MSK From presnick@qualcomm.com Fri Jan 20 15:40:26 2012 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 A64F921F8565 for ; Fri, 20 Jan 2012 15:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PzrQm1hsoEAr for ; Fri, 20 Jan 2012 15:40:25 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id B225921F84EE for ; Fri, 20 Jan 2012 15:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327102825; x=1358638825; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F19FB51.9040001@qualcomm.com>|Date:=20Fr i,=2020=20Jan=202012=2017:40:01=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20Message=20Abuse=20Report=20Format =20working=20group=20|Subject:=20Re:=20[ma rf]=20DISCUSS=20on=20draft-ietf-marf-redaction-04 |References:=20=09<4F18ACA8.2010309@qualcom m.com>=09=09=09=09< F5833273385BB34F99288B3648C4F06F19C89DFA9D@EXCH-C2.corp.c loudmark.com>=09=09=09<9BA32 BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com>=20|In-Reply-To:=20|Content-Type:=20 text/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflow ed|Content-Transfer-Encoding:=207bit|X-Originating-IP:=20 [172.30.48.1]; bh=aEoqh2fmLNYv7f64XQv96g5QKxrlutREoZjE882AhTo=; b=Udd1zMXlu+bxc0EKFlfVJqutpgbuZuwirj+etUybv2OsEhwgNeKrLpsI EBBfT3EPEfZzAWt89QKpb12B248ApcXYvemvUUb5fyQv4UT58wL4RqPmH XeTgPkLDw6MvMp24vt1RfRebXVNqci4vSMD9mIAp7gFfcvwLlgXYhK5cM c=; X-IronPort-AV: E=McAfee;i="5400,1158,6595"; a="156806136" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 20 Jan 2012 15:40:24 -0800 X-IronPort-AV: E=Sophos;i="4.71,542,1320652800"; d="scan'208";a="241940769" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Jan 2012 15:40:11 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 20 Jan 2012 15:40:04 -0800 Message-ID: <4F19FB51.9040001@qualcomm.com> Date: Fri, 20 Jan 2012 17:40:01 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 23:40:26 -0000 On 1/20/12 1:08 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Steve Atkins >> Sent: Friday, January 20, 2012 11:05 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >> >> I think that would improve it in general, as well as avoiding some of >> the supposed security concerns. >> > Pete, do you think this approach would fly? > Sorry for not getting back to you earlier; tied up in meetings all afternoon. But you did hear back from Stephen: This would address his concerns. This way, you're not saying that H is a good idea for redaction without explaining the limited meaning of "redaction" that this document anticipates. I would like to see a "MAY" appear somewhere in section 3 of your proposed text to indicate that the choice of algorithm is a protocol option. (E.g., "An implementation MAY choose one of ROT13, CRC32, MD5, H, HMAC, or any transformation that has a reasonably low likelihood of collision...blah...blah...blah..."). And I think you're likely to need references for the example algorithms you do give, and maybe a a quick line about the features of each, (e.g., "ROT13 (manually invertible, but visually obscure), CRC32 (invertible by code, but not simply by a human), ..."). But I think this is perfectly reasonable. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From msk@cloudmark.com Fri Jan 20 15:53:05 2012 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 B996121F86D6 for ; Fri, 20 Jan 2012 15:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 sOydyMjDabne for ; Fri, 20 Jan 2012 15:53:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2021F86D5 for ; Fri, 20 Jan 2012 15:53:02 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 15:53:01 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 20 Jan 2012 15:53:01 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 15:53:00 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXzOXjtKF6Tam3QL2CnC7yUPy9FgAAUmvg Message-ID: References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> <4F19FB51.9040001@qualcomm.com> In-Reply-To: <4F19FB51.9040001@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 23:53:05 -0000 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, January 20, 2012 3:40 PM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > Sorry for not getting back to you earlier; tied up in meetings all > afternoon. But you did hear back from Stephen: This would address his > concerns. This way, you're not saying that H is a good idea for > redaction without explaining the limited meaning of "redaction" that > this document anticipates. I would like to see a "MAY" appear somewhere > in section 3 of your proposed text to indicate that the choice of > algorithm is a protocol option. (E.g., "An implementation MAY choose > one of ROT13, CRC32, MD5, H, HMAC, or any transformation that has a > reasonably low likelihood of collision...blah...blah...blah..."). And I > think you're likely to need references for the example algorithms you > do give, and maybe a a quick line about the features of each, (e.g., > "ROT13 (manually invertible, but visually obscure), CRC32 (invertible > by code, but not simply by a human), ..."). But I think this is > perfectly reasonable. I doubt there's a formal definition of ROT13 anywhere, but I'll look for th= e rest. If anyone has references handy, please do post them and save me th= e time of going to track them down. The list I would use would include at least these, which need references: - ROT13 - CRC32 - MD5 - SHA (already have the FIPS-180 reference) - H - HMAC (already cite an RFC for this one) - full encryption a la what openssl can do (does this have a formal name an= d a good reference?) From msk@cloudmark.com Fri Jan 20 15:58:34 2012 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 1A5B921F869D for ; Fri, 20 Jan 2012 15:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 k2c82lveIq5l for ; Fri, 20 Jan 2012 15:58:33 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1B14821F86A8 for ; Fri, 20 Jan 2012 15:58:20 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 20 Jan 2012 15:58:19 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 20 Jan 2012 15:58:19 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 20 Jan 2012 15:58:18 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczXzOXjtKF6Tam3QL2CnC7yUPy9FgAAdh7g Message-ID: References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> <4F19FB51.9040001@qualcomm.com> In-Reply-To: <4F19FB51.9040001@qualcomm.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] DISCUSS on draft-ietf-marf-redaction-04 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, 20 Jan 2012 23:58:34 -0000 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, January 20, 2012 3:40 PM > To: Murray S. Kucherawy > Cc: Message Abuse Report Format working group > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > Sorry for not getting back to you earlier; tied up in meetings all > afternoon. But you did hear back from Stephen: This would address his > concerns. This way, you're not saying that H is a good idea for > redaction without explaining the limited meaning of "redaction" that > this document anticipates. I would like to see a "MAY" appear somewhere > in section 3 of your proposed text to indicate that the choice of > algorithm is a protocol option. (E.g., "An implementation MAY choose > one of ROT13, CRC32, MD5, H, HMAC, or any transformation that has a > reasonably low likelihood of collision...blah...blah...blah..."). And I > think you're likely to need references for the example algorithms you > do give, and maybe a a quick line about the features of each, (e.g., > "ROT13 (manually invertible, but visually obscure), CRC32 (invertible > by code, but not simply by a human), ..."). But I think this is > perfectly reasonable. (Oops, wasn't quite done yet.) I'm not clear on the suggestion about MAY. We already present the choice; = a MAY here would mean you can opt not to do any of these, which isn't redac= tion at all, and this whole memo doesn't apply. From presnick@qualcomm.com Fri Jan 20 16:03:33 2012 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 C154D21F869D for ; Fri, 20 Jan 2012 16:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4EOTGG0fcV9I for ; Fri, 20 Jan 2012 16:03:33 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D039C21F8659 for ; Fri, 20 Jan 2012 16:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327104212; x=1358640212; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1A0049.4040008@qualcomm.com>|Date:=20Fr i,=2020=20Jan=202012=2018:01:13=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20"Murray=20S.=20Kucherawy"=20,=20Message=20Abuse=20Report=20Format=0D=0A=20wor king=20group=20|Subject:=20Re:=20[marf]=20 DISCUSS=20on=20draft-ietf-marf-redaction-04|References: =20=09<4F18ACA8.2010309@qualcomm.com>=09=09=09=09=20|In-Reply-To:=20 |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=pdsltC2Sb4OTugWRHUk+tWd7oX7s9UdErH8WbRZAAEg=; b=h12Sz4Kcctg5eryvQpxfYUXqaZ0VNbg5UU9yUKLnG1NQrYLkMNZblnMQ D8qg8ZiTC5RryPUKbfLN2XF74gdHRYTcsE6U4/NipZ3J7W79tL+9m627V OKiJiMmclXRKmWeekp7AZTncv1Lw0ULlC2zv9JtTE+EELhG88FUJvwVbX M=; X-IronPort-AV: E=McAfee;i="5400,1158,6595"; a="154497272" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 20 Jan 2012 16:03:32 -0800 X-IronPort-AV: E=Sophos;i="4.71,542,1320652800"; d="scan'208";a="241955696" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Jan 2012 16:03:32 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 20 Jan 2012 16:01:16 -0800 Message-ID: <4F1A0049.4040008@qualcomm.com> Date: Fri, 20 Jan 2012 18:01:13 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 21 Jan 2012 00:03:33 -0000 OBE if you go with the new path, but to follow up: On 1/20/12 12:35 PM, Barry Leiba wrote: >>> I think the way forward is to explain why we don't need cryptographic >>> security here, and why the specific hash function chosen doesn't >>> matter, as long as the redacted value stays the same for the same >>> unredacted input. And that's all. >>> >> What do you think might be missing from the current Security Considerations >> to nail this point home to the IESG's satisfaction? Basically, I thought we'd >> done this already in -05. >> > I'd thought so, as well, so I don't know the answer to your question. > I'll be happy to try tossing out some text. > > Another thought occurred to me, from what Pete has said: > > Pete's question is, "Why NOT use HMAC?" > > That's the wrong question; it's the IESG overstepping its authority, > if they insist that that's the question. The IESG is objecting to > what the working group has come up with... > You will note that I quite carefully and explicitly split my questions about the WG's intent from the IESG's DISCUSS questions. The question of "Why NOT use HMAC?" was mine. The IESG did not ask that question and in no way overstepped its authority. *I* thought it important to understand why the WG was choosing not to use HMAC (and answer I really haven't gotten, but again, it sounds like it's moot). The IESG DISCUSSion said, "Either you need to use HMAC or explain the failings with H ('IHA') so that readers understand what they do and do not get with H." That is perfectly within bounds. > and the burden is on them to > show that what we have is not sufficient FOR THIS USE CASE. Sorry, no. I suspect that the issue really is that the document does not sufficiently define the use case to make it clear that H (or anything in particular) is appropriate. That's why one of the solutions given was, "Explain the limitations of H". If the use case was simply, "not easily reversible by a human", BASE64 is perfectly reasonable and H is probably overkill. But the document did not outline the use case and left open the question of what was necessary. > The correct question is, "For our use case, WHY REQUIRE HMAC? What > does it give us that is necessary for our use case?" > Again, the IESG did not require you to use HMAC. It was either use HMAC, or make clear the limitations of H. I think that defining the use case would have also sufficed (though perhaps gotten some quizzical looks about, "Then why not just use BASE64?", but without the DISCUSS.) > The amount of "security" in the redaction is ENTIRELY up to the > redactor. Given this spec, the redactor is welcome to use HMAC if > they want to -- if they or their lawyers think they need that level of > confidence that it can't be deciphered. Depending upon the redactor's > sensibilities, they are also welcome to use plain SHA1, or MD5, or > CRC, or, hey, just base64-encode the plain-text string if all you want > is to keep it away from idle eyes. > > It makes no sense for this spec to declare anything in this regard. > I think that is correct and on what we all agree. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From johnl@iecc.com Fri Jan 20 16:03:46 2012 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 AA7D421F86A8 for ; Fri, 20 Jan 2012 16:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.17 X-Spam-Level: X-Spam-Status: No, score=-108.17 tagged_above=-999 required=5 tests=[AWL=3.029, 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 Bc7YnnEp43li for ; Fri, 20 Jan 2012 16:03:44 -0800 (PST) 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 C4E7821F8659 for ; Fri, 20 Jan 2012 16:03:43 -0800 (PST) Received: (qmail 61698 invoked from network); 21 Jan 2012 00:03:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jan 2012 00:03:43 -0000 Date: 21 Jan 2012 00:03:21 -0000 Message-ID: <20120121000321.85588.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] DISCUSS on draft-ietf-marf-redaction-04 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, 21 Jan 2012 00:03:46 -0000 >> algorithm is a protocol option. (E.g., "n...blah...blah...blah...A"). I'd suggest not stepping back into the tarpit, and say An implementation MAY choose any transformation that has a reasonably low likelihood of collision. Leave it at that. R's, John PS: http://catb.org/~esr/jargon/html/R/rot13.html From presnick@qualcomm.com Fri Jan 20 16:12:43 2012 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 5449D21F86D6 for ; Fri, 20 Jan 2012 16:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hdTxesAszU2q for ; Fri, 20 Jan 2012 16:12:41 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB621F86C9 for ; Fri, 20 Jan 2012 16:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327104761; x=1358640761; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1A02D8.2070701@qualcomm.com>|Date:=20Fr i,=2020=20Jan=202012=2018:12:08=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20Message=20Abuse=20Report=20Format =20working=20group=20|Subject:=20Re:=20[ma rf]=20DISCUSS=20on=20draft-ietf-marf-redaction-04 |References:=20=09<4F18ACA8.2010309@qualcom m.com>=09=09=09=09< F5833273385BB34F99288B3648C4F06F19C89DFA9D@EXCH-C2.corp.c loudmark.com>=09=09=09<9BA32 BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com>=09=09<4F19FB51.9040001@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=AxP3A7ke3Rg939ZAXnwxF8FQzm0DUgLOj0pKZR1+v2Q=; b=lpcjmLCgQGlCQ9tGl3IZBvVWZMQ/eY1hjUTqOTUAgy4nVlr8YsHD3HTa qTvdjHfalRk6Vly7/jKpq/V4V2X+byfYcPuWVGHHuQPzvE/M8sy5PPK0q T6k6fFWg2PgtS5cBkygxKCTmIv9PszjSiDMBBsKuQAOIFO6a8u1M44WBT Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6595"; a="156818918" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 20 Jan 2012 16:12:41 -0800 X-IronPort-AV: E=Sophos;i="4.71,542,1320652800"; d="scan'208";a="118996945" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Jan 2012 16:12:40 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 20 Jan 2012 16:12:10 -0800 Message-ID: <4F1A02D8.2070701@qualcomm.com> Date: Fri, 20 Jan 2012 18:12:08 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4F18ACA8.2010309@qualcomm.com> <9BA32BCF-39E8-44B1-BFE5-56467ECCADA1@wordtothewise.com> <4F19FB51.9040001@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 21 Jan 2012 00:12:43 -0000 On 1/20/12 5:58 PM, Murray S. Kucherawy wrote: > I'm not clear on the suggestion about MAY. We already present the choice; a MAY here would mean you can opt not to do any of these, which isn't redaction at all, and this whole memo doesn't apply. > "MAY choose A, B, or C" is not equivalent to "MAY choose A, B, C, or none of the above". For example, from RFC 5321: Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. In this case, I'm not sure what opting to not do any of those might mean. On the other hand, I'm also fine with John Levine's suggestion: An implementation MAY choose any transformation that has a reasonably low likelihood of collision. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sklist@kitterman.com Fri Jan 20 16:34:11 2012 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 7DF0D21F86B2 for ; Fri, 20 Jan 2012 16:34:11 -0800 (PST) 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 FdY1t+iChOGW for ; Fri, 20 Jan 2012 16:34:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CB42021F8611 for ; Fri, 20 Jan 2012 16:34:10 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2214720E40B7; Fri, 20 Jan 2012 19:34:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327106049; bh=dOMpPMg1RKlvgeXvhFT7V4ntaUQ5z4NkEDJKb/NCn5A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TlFYjOOOSkOWiw1hm+d1KqujkRFXeo2bi+O1WAfHzenBPHM8AeYUHIaUVJopI/CNm gIksPXjZf43jpCkuto8J27l9kkK5GJF9q/AhroZKdyYm+8TsdufhHS+VY9aL3xahDF K+spH+KTUhmFAMHO+6YO9Bb+ZggWm0MTRk9nbyoU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0268020E405D; Fri, 20 Jan 2012 19:34:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 20 Jan 2012 19:34:08 -0500 Message-ID: <5981542.ZeaAyGZrjJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 21 Jan 2012 00:34:11 -0000 On Friday, January 20, 2012 03:08:33 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Murray S. Kucherawy > > Sent: Friday, January 20, 2012 11:08 AM > > To: Message Abuse Report Format working group > > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 > > > > Pete, do you think this approach would fly? > > Stephen, Barry and I like the proposed changes visible now at > http://www.blackops.org/~msk/marf.html. This would clear the discuss and > allow publication as long as Pete also agrees. > > MARF participants, please review this and provide any feedback, including > support or requested changes. I'll post it Monday morning unless I hear > some objection. > > I need to adjust the bit around the mention of encoding non-ASCII stuff > because it might also be necessary to base64-encode redacted data if the > redacted form includes spaces, but that's a very minor change. Seems reasonable to me. Scott K From barryleiba@gmail.com Sat Jan 21 09:15:59 2012 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 8BF6B21F8505 for ; Sat, 21 Jan 2012 09:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.861 X-Spam-Level: X-Spam-Status: No, score=-102.861 tagged_above=-999 required=5 tests=[AWL=0.116, 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 HjSbqRR88lMK for ; Sat, 21 Jan 2012 09:15:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09E1A21F8504 for ; Sat, 21 Jan 2012 09:15:35 -0800 (PST) Received: by obbwc12 with SMTP id wc12so2140741obb.31 for ; Sat, 21 Jan 2012 09:15:35 -0800 (PST) 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:cc:content-type; bh=G4vWtqOjx7iZX2jD+Aj885HZI3hV5/9f7fs4Y0GfkxA=; b=vNCtWDEt0coJVFo/LFQtGTnAq2XN7pjhvBFHs9KLCL+s/x64zrdRNmwbaBNzfBBHjZ 5SS8Ee1COvaZOBBa/tcQRXUAQGEpVzE1bwKtOIB2w7OFQVAWCQ5804TTGujf8mWmPA4y m1tlpCzMaKpYxyzUdLG7HA3zsP42duWW/q7PM= MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr2050512obl.79.1327166135704; Sat, 21 Jan 2012 09:15:35 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.55.137 with HTTP; Sat, 21 Jan 2012 09:15:35 -0800 (PST) In-Reply-To: <4F1A0049.4040008@qualcomm.com> References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> Date: Sat, 21 Jan 2012 12:15:35 -0500 X-Google-Sender-Auth: FDHGSP0B3eAG9dPo3HYLO7t3egw Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 21 Jan 2012 17:15:59 -0000 >> Another thought occurred to me, from what Pete has said: >> >> Pete's question is, "Why NOT use HMAC?" >> >> That's the wrong question; it's the IESG overstepping its authority, >> if they insist that that's the question. The IESG is objecting to >> what the working group has come up with... > > You will note that I quite carefully and explicitly split my questions about > the WG's intent from the IESG's DISCUSS questions. The question of "Why NOT > use HMAC?" was mine. The IESG did not ask that question and in no way > overstepped its authority. Ah, sorry. I will note that either you weren't careful and explicit enough or (more likely) I simply missed it. I was committing a bit of hyperbole here, and didn't really think the IESG was going over the edge... but I did think the "explain why you won't use HMAC, or else use HMAC" think was what was required to clear the DISCUSS position. As it turns out, what was really needed was for us to better explain what the redaction is trying to do, so it's clear why the specific encoding doesn't matter and needn't be specified here. And, of course, that *is* reasonable for the IESG to ask. That done, all is well. Please forgive me for being inappropriately inflammatory in my hyperbolicness. Probably I was a little grumpy at the time, as well. Barry, who will now get back to chairing quietly in his chair From presnick@qualcomm.com Sun Jan 22 10:01:53 2012 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 AFF5F21F846F for ; Sun, 22 Jan 2012 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NvcYQgivW5pI for ; Sun, 22 Jan 2012 10:01:53 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DD21F845A for ; Sun, 22 Jan 2012 10:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327255312; x=1358791312; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1C4F0D.6090205@qualcomm.com>|Date:=20Su n,=2022=20Jan=202012=2012:01:49=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20Message=20Abuse=20Report=20Format=20wor king=20group=20|Subject:=20Re:=20[marf]=20 DISCUSS=20on=20draft-ietf-marf-redaction-04|References: =20=09<4F18ACA8.2010309@qualcomm.com>=09=09=09=09=09=09<4F1A0049.4040008@qualcomm.com> =20|In-Reply-To:=20|Content-Type: =20text/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Df lowed|Content-Transfer-Encoding:=207bit|X-Originating-IP: =20[172.30.48.1]; bh=WQWSrnKSohGVQgYRaX4Kd7dL6Ihon39e9b4hYE/rwMg=; b=VOc6Q7Id3dxnnW6Y1Zl/wlCQdSvJbHr+LT2y3d4chWVBMy5JzKFeGyl0 a5iBHFXeLibNmXW9U0LYxYW+ilbEwwOb0oauS3HDUK3rfFSVFS7Qguini h6Ogn6Mh0uGD7kNqoSFEO+GWKAA3Kk954l/pOOY4cIwahtN7M1Pv1aacK k=; X-IronPort-AV: E=McAfee;i="5400,1158,6597"; a="154777267" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 22 Jan 2012 10:01:52 -0800 X-IronPort-AV: E=Sophos;i="4.71,551,1320652800"; d="scan'208";a="157132514" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Jan 2012 10:01:52 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 22 Jan 2012 10:01:51 -0800 Message-ID: <4F1C4F0D.6090205@qualcomm.com> Date: Sun, 22 Jan 2012 12:01:49 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 22 Jan 2012 18:01:53 -0000 So, let me answer your message in reverse: On 1/21/12 11:15 AM, Barry Leiba wrote: > Barry, who will now get back to chairing quietly in his chair > Please don't. I hope (indeed *want*) serious technical pushback to the IESG from WG members and chairs when any AD (myself included) makes a technical claim that might be wrong. In this case, pushing back on Stephen for asking for HMAC was entirely appropriate: The fact is that HMAC *is* overkill for this protocol, but we (the WG) hadn't yet clearly spelled out why in the document, and the fact that we were using a hash algorithm muddied the waters, because it was probably overkill as well and made it look like we needed something more than we did. As you said: > As it turns out, what was really needed was for us to better explain > what the redaction is trying to do, so it's clear why the specific > encoding doesn't matter and needn't be specified here. And, of > course, that *is* reasonable for the IESG to ask. That done, all is > well. > So, technical pushing back on this was good and I want more of that. The only thing that I was concerned about was your statement that this was an "overstepping its authority" situation. As I expect you know, I take these sorts of appeal-worthy process things pretty darn seriously. If you (or anyone) think something is going a-foul of process (especially the IESG overstepping authority), please bring that to me immediately. In particular, don't throw it into the middle of a technical discussion on a WG list. Aside from it not being the best venue, it also can get things rather contentious rather quickly. I do want to hear about and discuss these things, and as you said, perhaps I wasn't careful enough in my message to keep the "Pete questions" separated enough from the "IESG issues", but let's all try to keep those discussions cleanly separated. > Please forgive me for being inappropriately inflammatory in my > hyperbolicness. Probably I was a little grumpy at the time, as well. > No need for apology, and completely forgiven. I will also ask for a bit of forgiveness myself, as I was also likely grumpier than necessary due to being a bit sick this past week (food poisoning blows), and having spent my recovery time on an IESG telechat. But my intention was not to be scolding, and I'm sorry that it came off that way. > Ah, sorry. I will note that either you weren't careful and explicit > enough or (more likely) I simply missed it. I was committing a bit of > hyperbole here, and didn't really think the IESG was going over the > edge... but I did think the "explain why you won't use HMAC, or else > use HMAC" think was what was required to clear the DISCUSS position. > A misunderstanding, and I think we're all on the correct page now. Your (perhaps not sufficiently) humble servant. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dhc@dcrocker.net Sun Jan 22 10:51:45 2012 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 3FFC721F855A for ; Sun, 22 Jan 2012 10:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.766 X-Spam-Level: X-Spam-Status: No, score=-6.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 zo7aVAFMEAqI for ; Sun, 22 Jan 2012 10:51:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8542721F852F for ; Sun, 22 Jan 2012 10:51:44 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0MIpXMR023784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jan 2012 10:51:39 -0800 Message-ID: <4F1C5AAC.8030509@dcrocker.net> Date: Sun, 22 Jan 2012 10:51:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Pete Resnick References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> In-Reply-To: <4F1C4F0D.6090205@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 22 Jan 2012 10:51:39 -0800 (PST) Cc: Barry Leiba , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 22 Jan 2012 18:51:45 -0000 On 1/22/2012 10:01 AM, Pete Resnick wrote: > I hope (indeed *want*) serious technical pushback to the IESG from > WG members and chairs when any AD (myself included) makes a technical claim that > might be wrong. I'll suggest that "pushback", per se, is the tactical point. The strategic point is the dual obligation for: 1) the AD to be (more?) clear about their underlying concerns and not just assert the problem or the solution they think will resolve it, as well as the requirement that they engage in a /direct/ dialogue with the working group, and 2) the working group to be (more?) clear about its underlying goals and requirements, as well as engaging in real and constructive dialogue with the AD(s) toward a useful resolution, rather than merely one that pacifies the ADs. I have more than my share of just getting pissed off at ADs who lodge vague and even inappropriate Discusses and can attest that while pushing back is fine, indulging in being pissed off is never helpful, even when they warrant the reaction. (That's meant merely to mark an extreme, not claim it applied here.) Unfortunately, my review of the current wg's mailing list record shows quite a bit less of #1 than there should be, IMO, in spite of Pete's active, follow-on participation. (And I note that the Discuss is not yet cleared...) Stephen has not engaged directly. Now it well might be that Pete has been an adequate surrogate, but forgive me, it is Stephen who holds the Discuss. It really is essential that a wg not be forced to guess what will satisfy ADs who hold Discusses. As a matter of due diligence, I'll also ask folks whether they believe the modifications to the specification retain its previous level of utility and pedagogy as a specification, for strangers out there in implementation land who lack the background from participating in the working group? I ask this because sometimes handling the one point raised by a Discuss alters the answer for other aspects of the spec... > So, technical pushing back on this was good and I want more of that. The only > thing that I was concerned about was your statement that this was an > "overstepping its authority" situation. If one reviews Stephen's Discuss, one sees an engineer asserting the details of an alternative solution, with what is really none of the underlying concepts or issues that might justify it. However the concerns in the underlying stuff are the real substance. Perhaps my reading comprehension is inadequate here, but I simply don't see the material a working group ought to be given, to permit serious dialogue. Forgive me, but that really /is/ overstepping (or understepping) the role of the IESG at this stage, IMO, even if the suggestion is the right one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Sun Jan 22 11:46:16 2012 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 E2F9F21F853A for ; Sun, 22 Jan 2012 11:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.629 X-Spam-Level: X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 fOeLGBb-bknk for ; Sun, 22 Jan 2012 11:46:14 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C431721F852F for ; Sun, 22 Jan 2012 11:46:14 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0MJjqlJ014627; Sun, 22 Jan 2012 11:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327261568; i=@resistor.net; bh=gyfC4wyG5h8dvd2BFcNUHhfHYMZKCF2I6mE9uAaycDU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=oosFTk+fI3umAzaVSKM/7l8ukm/lTgor2lwh1y7jI23uwZCBhW7WqtBRiAQB6bVdp YdHqYweSgR6oOjO5DK0wfqWPtTJy4HUs1XoSa0/oNajjzhsNUdV/fxX0L02Cy/EJu1 8UQlOtwtsFDO/aYlM7/Mhcw1SZs51rSv24NethtA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327261568; i=@resistor.net; bh=gyfC4wyG5h8dvd2BFcNUHhfHYMZKCF2I6mE9uAaycDU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=u8do4PNNWzPSvS41SbSBvSP6dh0vmUFrwKcxxE8vPUmj26eTYBaRE882LeWoefQDU Yl2/YEOuUvmGINV0u9w7KzqUvq6NTWWv9bMr6KEfYmDndSP/Kj9BaFjnYLUgiRqLhi dDdxCRm6StlbgI3+S4WncJhZTAGmiPtvNw2FKQ1o= Message-Id: <6.2.5.6.2.20120122111048.0c971bc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Jan 2012 11:41:11 -0800 To: dcrocker@bbiw.net From: SM In-Reply-To: <4F1C5AAC.8030509@dcrocker.net> References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 22 Jan 2012 19:46:17 -0000 Hi Dave, At 10:51 22-01-2012, Dave CROCKER wrote: >As a matter of due diligence, I'll also ask folks whether they >believe the modifications to the specification retain its previous >level of utility and pedagogy as a specification, for strangers out >there in implementation land who lack the background from >participating in the working group? I ask this because sometimes >handling the one point raised by a Discuss alters the answer for >other aspects of the spec... The title of the draft is "Redaction of Potentially Sensitive Data from Mail Abuse Reports". The draft is about addressing the following: "Previous redaction practices, such as replacing local-parts of addresses with a uniform string like "xxxxxxxx", often frustrates any kind of prioritizing or grouping of reports." The desired outcome is to allowing grouping of reports. What the specifications ends up doing is trying to protect "Potentially Sensitive Data". I found version -03 useful for strangers as it basically recommends to use a hash/digest instead of "xxxxxxxx". The most important point in that version was: "it is extremely unlikely that report generation software could ever be created to recognize all of the different ways that private information may be expressed through human written language" Regards, -sm From sm@resistor.net Sun Jan 22 14:02:26 2012 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 5FA5121F858E for ; Sun, 22 Jan 2012 14:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 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 ryjfJs54j2li for ; Sun, 22 Jan 2012 14:02:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC98321F8585 for ; Sun, 22 Jan 2012 14:02:21 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0MM1xqm022906; Sun, 22 Jan 2012 14:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327269735; i=@resistor.net; bh=0nlBXn2WZ7z5kujdDHlppWXXryZOEQmuOSlNprsvgag=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=CYTxoI/t1bgrtgycZDVNOqp7wN1ILlRU7y9Uew0gTpROElNKtuXivnS5AEo3ZkfQ8 IKNlUPeOEiLV/dRFlUHX84uDLxd9Wqs5g0dLTLTDtJVMSeqspY6qw4mMLcdKYzTW/H Jn1iZ3olFwkO9Oxt47V9mqZMRfHRDdfIA/0IKOwY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327269735; i=@resistor.net; bh=0nlBXn2WZ7z5kujdDHlppWXXryZOEQmuOSlNprsvgag=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=XDKGt0GkbXdKcbtfFph6MxNkK4t/u/MX/awUxSf1KgpiC6gj/5FhhGPAau/pjD8kZ ItH9/ORkiDhbFgdnVN9eZ8Rwarm7CWWrGEwq3RC/TDKIPJLU6x4ETtpYLo03jMarbG 5jOk4ZSrgTqEHFV+HF1vR+/GznCigWG0lwAcgl4E= Message-Id: <6.2.5.6.2.20120122135018.09da1ff0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Jan 2012 14:01:11 -0800 To: Barry Leiba From: SM In-Reply-To: References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 22 Jan 2012 22:02:26 -0000 Hi Barry, At 09:15 21-01-2012, Barry Leiba wrote: >Barry, who will now get back to chairing quietly in his chair I fully support the WG co-chair. I found your advice useful; for example: "As it turns out, what was really needed was for us to better explain what the redaction is trying to do, so it's clear why the specific encoding doesn't matter and needn't be specified here. And, of course, that *is* reasonable for the IESG to ask. That done, all is well." Regards, -sm From presnick@qualcomm.com Sun Jan 22 16:21:48 2012 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 1FD3E21F84B8 for ; Sun, 22 Jan 2012 16:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9h79yXXiYekE for ; Sun, 22 Jan 2012 16:21:47 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E223521F8433 for ; Sun, 22 Jan 2012 16:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327278106; x=1358814106; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1CA7F8.6050703@qualcomm.com>|Date:=20Su n,=2022=20Jan=202012=2018:21:12=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20CROCKER=20,=20Barry=20Leiba=20,=0D=0A=09Message=20Abuse=20Report=20F ormat=20working=20group=20|Subject:=20Re: =20[marf]=20DISCUSS=20on=20draft-ietf-marf-redaction-04 |References:=20=09<4F18ACA8.2010309@qualcom m.com>=09=09=09=09< F5833273385BB34F99288B3648C4F06F19C89DFA9D@EXCH-C2.corp.c loudmark.com>=09=09<4F1A0049.4040008@qualc omm.com>=09=09<4F1C4F0D.6090205@qualcomm.com> =20<4F1C5AAC.8030509@dcrocker.net>|In-Reply-To:=20<4F1C5A AC.8030509@dcrocker.net>|Content-Type:=20text/plain=3B=20 charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=igqoRVRLild+95UgaNGxDTvZh2Llg0AEQhm+2mdc4+8=; b=fDyl1qmuKDF/4gmXbRepwjGYHe9pxlFJFZdzzNz7Ni0ylPFUs1/28Dmj ueiwIwBLbhwzif/X2gDMhoRa06j69MoTycoGHVQ9kU5EtrE7HYlxkqK1o pJzIi16ZcfOR3/c51CPgVZI+KnPfyNbX2RWISBQmkwsZ68aCgxlCh7P53 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6597"; a="154805818" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 22 Jan 2012 16:21:46 -0800 X-IronPort-AV: E=Sophos;i="4.71,551,1320652800"; d="scan'208";a="242894469" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Jan 2012 16:21:46 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 22 Jan 2012 16:21:15 -0800 Message-ID: <4F1CA7F8.6050703@qualcomm.com> Date: Sun, 22 Jan 2012 18:21:12 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> In-Reply-To: <4F1C5AAC.8030509@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Barry Leiba , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 00:21:48 -0000 I think Dave is exactly right on just about everything here. I have a couple of issues with the details of some of the logistics, but it is in the details. For those who want to see my thoughts on sausage making, continue below. On 1/22/12 12:51 PM, Dave CROCKER wrote: > I'll suggest that "pushback", per se, is the tactical point. I should have been more clear that I intended exactly your strategic point: Engage. > The strategic point is the dual obligation for: > > 1) the AD to be (more?) clear about their underlying concerns and > not just assert the problem or the solution they think will resolve > it, as well as the requirement that they engage in a /direct/ dialogue > with the working group, and > > 2) the working group to be (more?) clear about its underlying goals > and requirements, as well as engaging in real and constructive > dialogue with the AD(s) toward a useful resolution, rather than merely > one that pacifies the ADs. Absolutely agree on both counts. How that direct dialogue occurs is an interesting question; more on that below. But the AD's concerns must be clear, and the WG should look to address the concern (even if addressing it is, "we have documented that we understand the concern and we feel it is not a problem we will solve), not just appease. > I have more than my share of just getting pissed off at ADs who lodge > vague and even inappropriate Discusses and can attest that while > pushing back is fine, indulging in being pissed off is never helpful, > even when they warrant the reaction. (That's meant merely to mark an > extreme, not claim it applied here.) +1! > Unfortunately, my review of the current wg's mailing list record shows > quite a bit less of #1 than there should be, IMO, in spite of Pete's > active, follow-on participation. Yup. And in this case, I think that, until I jumped in, #2 wasn't going so well either. (That is, Stephen's DISCUSS comment was -- and unfortunately is still written as -- "H has problems; you want HMAC", and the WG's response was, "HMAC is overkill", instead of figuring out that the problem was the lack of clear text on the use case, and the solution being to clarify the use case, and probably state that neither H nor HMAC was necessary.) > (And I note that the Discuss is not yet cleared...) An unfortunate side effect of there not being an appropriate tool. ADs, both the ones issuing the DISCUSSes and the ones managing the WG getting the DISCUSSes, have turned the ballot position into an issue tracker. That's dumb and needs to be fixed. But I'm guilty of this too. A long and different discussion I'm happy to have in some other forum. > Stephen has not engaged directly. Now it well might be that Pete has > been an adequate surrogate, but forgive me, it is Stephen who holds > the Discuss. So let me talk a bit about direct engagement. It's not the standard thing for the IESG now, but you're going to see more of it soon. During the last WG chair lunch, we had a discussion about copying all ballot DISCUSSes and COMMENTs to the WG mailing list and I think this is exactly the right thing to do. My plan is to, on a case by case basis at first, add the WG list to the magic field in the datatracker to which such comments go. The only issue is that this has to be reasonably managed. First, keep in mind that ADs make lots of comments (DISCUSSes and otherwise) and it would be quite a lot of mail for an AD to get if they got the full flood from every mailing list they sent a comment to, especially because so many of us make a slew of comments all during the telechat week. (Yeah, we're pretty poor planners.) So when we do direct engagement, I'm going to ask a bit of forbearance from the WG and try to avoid flooding the poor schlump AD who made a comment with a huge number of messages. But that's just a matter of being a bit more "conservative in what they send" when an AD is in the mix. (And I'm only talking about volume, not tone. :-) ) We can figure out how to do that. Second, note that currently all DISCUSS and COMMENT messages and all of their replies are Cc'ed to the IESG list. Just flipping the switch on would be potentially a *lot* of email to the IESG list. So we may want to figure out a way to split the "WG is mulling this over" messages from the "we have a response to this" messages. Finally, the current model has the AD directly engaging with *only* the editors and the chairs. Sometimes that's helpful because having only a few people chatting with the AD to understand the AD's issue is often easier than having the entire WG have that conversation. But that also means that sometimes the chairs or the editors come up with solutions to the AD's issue that the WG wouldn't buy into. (Jeez, I hope that's rare.) Bringing everyone into the conversation is again going to require a little mental shift so that people (WG chairs especially) get used to how to manage these conversations. All of these are simply (?!) cultural changes about how direct engagement will work. I think direct engagement is a *much* better model, but it does have side effects, and I want to make sure that those side effects don't cause a backlash against doing so. Right now, the model is "only do direct engagement once there's a problem", which is the wrong model. But I want to minimize heartburn while getting to the right model. So, with all that said, I'm happy to get Stephen directly engaged on this particular topic, though I think we now have a pretty good handle on what the issue is and how to deal with it. I'll leave it to the chairs to tell me what level of involvement they think is good at this point. > It really is essential that a wg not be forced to guess what will > satisfy ADs who hold Discusses. +1. > As a matter of due diligence, I'll also ask folks whether they believe > the modifications to the specification retain its previous level of > utility and pedagogy as a specification, for strangers out there in > implementation land who lack the background from participating in the > working group? I ask this because sometimes handling the one point > raised by a Discuss alters the answer for other aspects of the spec... You bet! > If one reviews Stephen's Discuss, one sees an engineer asserting the > details of an alternative solution, with what is really none of the > underlying concepts or issues that might justify it. However the > concerns in the underlying stuff are the real substance. > > Perhaps my reading comprehension is inadequate here, but I simply > don't see the material a working group ought to be given, to permit > serious dialogue. In retrospect, I completely agree. Stephen's DISCUSS comment is how to address what he believes the issue to be, not a discussion of what the issue really is. If his assessment of the issue is correct, that might be a real timesaver, but if it's wrong, well, we get to where we are now. > Forgive me, but that really /is/ overstepping (or understepping) the > role of the IESG at this stage, IMO, even if the suggestion is the > right one. I agree with understepping, not overstepping. We've all gotten into bad patterns with the goal of helping things move faster. (You will note that the IESG Statement on DISCUSS Criteria talks about always making DISCUSS comments "actionable".) As I said above, when it works, great, but when it doesn't, it causes bad feelings. In this case, Stephen wasn't trying to force a particular technical solution, and therefore I don't think he was exceeding his authority. But neither he nor the WG initially figured out what the real problem was, and that's a shortcoming in what happened. Thanks for a good analysis, as well as an opportunity to talk about what I'd like to do to address these problems. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From sm@resistor.net Sun Jan 22 17:41:12 2012 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 77F0221F85D2 for ; Sun, 22 Jan 2012 17:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 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 icSmrpShE0UY for ; Sun, 22 Jan 2012 17:41:11 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3121F85D1 for ; Sun, 22 Jan 2012 17:41:11 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0N1f1Jx012579; Sun, 22 Jan 2012 17:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327282868; i=@resistor.net; bh=CHETXpnt9WscOy1W0ROaLaXBgIsAIhkNVPTqeb784AE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=emBIra8dpEn9A3xRlfUI/MJwfCz+JpCOK915I6FRIFuap3BLcKQTJGdZ6Rxppg2UP k9h4JfSnoDQSHrD4rE1dp9fMtCPHIkAPoK/S/WcoAdlef/tfQcikbgE6yFkwgXC0H8 2jiMqcYVrRwG2DwvulqmkHBDhx5GNj1zVP2pQoSQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327282868; i=@resistor.net; bh=CHETXpnt9WscOy1W0ROaLaXBgIsAIhkNVPTqeb784AE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=zooeOx7CEWG2nkY0VqetOjYhETs4qDrJ/xnkX/CQSDfnwjwV/ZFRp4ENby76osQyb Vx8AYUgQGUmSBqzMFeUyRJYHIOlpqsAqwk8HvwdHpklk917uWvI5MQvie4HrDoWWus B9FlU/fhtGbkwWIRDu3CZ++FDhb4nhtcaSniAAPg= Message-Id: <6.2.5.6.2.20120122171723.09241f88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 22 Jan 2012 17:40:25 -0800 To: Pete Resnick From: SM In-Reply-To: <4F1CA7F8.6050703@qualcomm.com> References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 01:41:12 -0000 Hi Pete, At 16:21 22-01-2012, Pete Resnick wrote: >I should have been more clear that I intended exactly your strategic >point: Engage. And try to sift thought the misunderstandings. >Yup. And in this case, I think that, until I jumped in, #2 wasn't >going so well either. (That is, Stephen's DISCUSS comment was -- and >unfortunately is still written as -- "H has problems; you want >HMAC", and the WG's response was, "HMAC is overkill", instead of >figuring out that the problem was the lack of clear text on the use >case, and the solution being to clarify the use case, and probably >state that neither H nor HMAC was necessary.) You were trying to address the DISCUSS comment. >So let me talk a bit about direct engagement. It's not the standard >thing for the IESG now, but you're going to see more of it soon. >During the last WG chair lunch, we had a discussion about copying >all ballot DISCUSSes and COMMENTs to the WG mailing list and I think >this is exactly the right thing to do. My plan is to, on a case by >case basis at first, add the WG list to the magic field in the >datatracker to which such comments go. The only issue is that this >has to be reasonably managed. A WG Chair can always copy the DISCUSS and COMMENT to the WG mailing list. This is the type of information that might be useful on the relevant wiki. >Second, note that currently all DISCUSS and COMMENT messages and all >of their replies are Cc'ed to the IESG list. Just flipping the >switch on would be potentially a *lot* of email to the IESG list. So >we may want to figure out a way to split the "WG is mulling this >over" messages from the "we have a response to this" messages. If "we" used our discretion to cut down Cc to relevant information, it might help. >All of these are simply (?!) cultural changes about how direct >engagement will work. I think direct engagement is a *much* better >model, but it does have side effects, and I It's a lot of work. >In retrospect, I completely agree. Stephen's DISCUSS comment is how >to address what he believes the issue to be, not a discussion of >what the issue really is. If his assessment of the issue is correct, >that might be a real timesaver, but if it's wrong, well, we get to >where we are now. Yes. And it is an eye-opener on how the average reader might read the document. I suggest following up on the cultural change on another list if you believe it is worth pursuing. Regards, -sm From barryleiba@gmail.com Sun Jan 22 18:39:02 2012 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 674F321F85CC for ; Sun, 22 Jan 2012 18:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.871 X-Spam-Level: X-Spam-Status: No, score=-102.871 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Z1n0Mh0TuzIS for ; Sun, 22 Jan 2012 18:39:01 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC821F859A for ; Sun, 22 Jan 2012 18:38:56 -0800 (PST) Received: by obbwc12 with SMTP id wc12so3018159obb.31 for ; Sun, 22 Jan 2012 18:38:56 -0800 (PST) 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:cc:content-type; bh=auKJA7ajUHVn3lglJr/zwrAI1USTEW/uAzYih65CctM=; b=O2mipdFf10RMD3lYYm5shJHZKHGd2retsFmoEMYtJKMIFv+eQNLIRALoswEH+FxWAB ndn/RVj6r2+DcqqGYF6xqju/IgKXnNJipUnRfA4ZG4srGhnP1UtYp1HskqGDr+j17mzZ ScMCB0xxbCaMGEdq3QgpkH1A766UqCog50bl8= MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr6234818obv.69.1327286335949; Sun, 22 Jan 2012 18:38:55 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.55.137 with HTTP; Sun, 22 Jan 2012 18:38:55 -0800 (PST) In-Reply-To: <4F1CA7F8.6050703@qualcomm.com> References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> Date: Sun, 22 Jan 2012 21:38:55 -0500 X-Google-Sender-Auth: MoIoBV6gd3iHlEWEw-IgDTi80fI Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: multipart/alternative; boundary=f46d0447a08f91cb6204b728ee99 Cc: "dcrocker@bbiw.net" , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 02:39:02 -0000 --f46d0447a08f91cb6204b728ee99 Content-Type: text/plain; charset=ISO-8859-1 > So let me talk a bit about direct engagement. It's not the standard thing for > the IESG now, but you're going to see more of it soon. During the last WG > chair lunch, we had a discussion about copying all ballot DISCUSSes and > COMMENTs to the WG mailing list and I think this is exactly the right thing to do. > My plan is to, on a case by case basis at first, add the WG list to the magic field > in the datatracker to which such comments go. The only issue is that this has to > be reasonably managed. Let me, as a WG chair, urge you NOT to do it that way, but to let the chairs handle the decision of what needs to go to active WG discussion and when. By all means, chat with your chairs and tell us what you expect. But let us manage the WG discussions. If a chair isn't being open enough for you, have further discussion. You always have the option of forcing the issue by doing what you suggest above if the chairs don't handle it as you'd like. The majority of the non-DISCUSS comments are dealt with by such minor editorial changes that opening the discussion up to WG comments will likely inundate the entire IESG unnecessarily (consider, say 5 comments each on 20 documents in one week, and a few vocal and unstoppable WG participants for each). Perhaps every approved doc should go back to its WG for a week for validation, to be sure they see the final edits AND the RFC Editor notes that the AD put there -- you do want those openly discussed by the WG, too, right? Even many DISCUSS comments are resolved with what will clearly be non-controversial edits, which should well be reviewed by the WG, but which don't need to have the WG engaged in the discussion. The doc shepherd needs to have the responsibility of taking it to the WG as appropriate. In this case, in fact, Murray did bring the discussion to the WG, without your needing to force it. Whatever we think of how the discussion went, not having it in front of the WG when it should have been was NOT one of the problems. > So, with all that said, I'm happy to get Stephen directly engaged on this particular > topic, though I think we now have a pretty good handle on what the issue is and > how to deal with it. I'll leave it to the chairs to tell me what level of involvement > they think is good at this point. I don't think any involvement by Stephen is needed at this point: he's already confirmed that he's happy with this version and will clear his DISCUSS. And, so everyone knows, Stephen was engaged and responsive with the authors and chairs, as we discussed options. The issue is that he wasn't engaged with the WG when the chairs brought the discussion here. That's likely in part because we didn't CC him when we did that -- I have no reason to think that he'd have avoided it if we'd asked him to be here. Barry, chair --f46d0447a08f91cb6204b728ee99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > So let me talk a bit about direct engagement. It's not the standar= d thing for
> the IESG now, but you're going to see more of it s= oon. During the last WG
> chair lunch, we had a discussion about cop= ying all ballot DISCUSSes and
> COMMENTs to the WG mailing list and I think this is exactly the right = thing to do.
> My plan is to, on a case by case basis at first, add = the WG list to the magic field
> in the datatracker to which such co= mments go. The only issue is that this has to
> be reasonably managed.

Let me, as a WG chair, urge you NOT to d= o it that way, but to let the chairs handle the decision of what needs to g= o to active WG discussion and when. =A0By all means, chat with your chairs = and tell us what you expect. =A0But let us manage the WG discussions. =A0If= a chair isn't being open enough for you, have further discussion. =A0Y= ou always have the option of forcing the issue by doing what you suggest ab= ove if the chairs don't handle it as you'd like.

The majority of the non-DISCUSS comments are dealt with by such minor e= ditorial changes that opening the discussion up to WG comments will likely = inundate the entire IESG unnecessarily (consider, say 5 comments each on 20= documents in one week, and a few vocal and unstoppable WG participants for= each). =A0Perhaps every approved doc should go back to its WG for a week f= or validation, to be sure they see the final edits AND the RFC Editor notes= that the AD put there -- you do want those openly discussed by the WG, too= , right?

Even many DISCUSS comments are resolved with what will clearly be non-c= ontroversial edits, which should well be reviewed by the WG, but which don&= #39;t need to have the WG engaged in the discussion. =A0The doc shepherd ne= eds to have the responsibility of taking it to the WG as appropriate.

In this case, in fact, Murray did bring the discussion to the WG, witho= ut your needing to force it. =A0Whatever we think of how the discussion wen= t, not having it in front of the WG when it should have been was NOT one of= the problems.

> So, with all that said, I'm happy to get Stephen directly enga= ged on this particular
> topic, though I think we now have a pretty g= ood handle on what the issue is and
> how to deal with it. I'll l= eave it to the chairs to tell me what level of involvement
> they think is good at this point.

I don't think any involve= ment by Stephen is needed at this point: he's already confirmed that he= 's happy with this version and will clear his DISCUSS. =A0And, so every= one knows, Stephen was engaged and responsive with the authors and chairs, = as we discussed options. =A0The issue is that he wasn't engaged with th= e WG when the chairs brought the discussion here. =A0That's likely in p= art because we didn't CC him when we did that -- I have no reason to th= ink that he'd have avoided it if we'd asked him to be here.

Barry, chair
--f46d0447a08f91cb6204b728ee99-- From msk@cloudmark.com Sun Jan 22 21:13:39 2012 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 C2E9D21F85F6 for ; Sun, 22 Jan 2012 21:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 nrSLVEFZ-3KS for ; Sun, 22 Jan 2012 21:13:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0A21F85F1 for ; Sun, 22 Jan 2012 21:13:39 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 22 Jan 2012 21:13:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 22 Jan 2012 21:13:38 -0800 From: "Murray S. Kucherawy" To: Pete Resnick , "dcrocker@bbiw.net" Date: Sun, 22 Jan 2012 21:13:38 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczZZQAShtimD0YTQ7y2h21c2YhlWwAJG/ig Message-ID: References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> In-Reply-To: <4F1CA7F8.6050703@qualcomm.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 Cc: Barry Leiba , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 05:13:39 -0000 One more perspective to throw into the mix... I found this DISCUSS experience frustrating for two reasons: 1) My own interpretation of the way our options were presented was: "You ca= n either (a) change to HMAC, or (b) stick with your way but explain why it'= s appropriate (and, quite honestly, we're going to set the bar on (b) very,= very high, so you may as well just do HMAC)." 2) Related to the above, I thought we /had/ done an appropriate job of expl= aining why H was enough for our purposes in this application, especially af= ter the Gen-ART review, but the IESG position didn't change; Stephen didn't= answer me more than once, and any other IESG reply I got showed that our p= oint wasn't being heard. I never understood why; maybe I wasn't making it = well, or maybe my facts are wrong. Either way, at times it felt like there= wasn't an "enough" that could be reached, which is obviously exasperating. Eventually Barry said something on the list that led me to the proposed com= promise, which brings us to text that the DISCUSS holder has accepted and I= 'll be posting soon. I'm comfortable with it inasmuch as we can get this o= verwith and it doesn't make existing implementations obsolete, but I think = the lack of specific implementation guidance might weaken it somewhat. But= I'm not interested in reopening that now. In terms of what I've learned from this experience, I'm willing to admit th= at a better vetting of the algorithm earlier on would've helped our cause; = either we would've switched to something more defensible or been able to pr= esent a decent defense from a technology standpoint (e.g., "we know about t= hese attacks, you should too, but really we're fine with it and here's why"= ). Lesson learned for next time. -MSK From msk@cloudmark.com Sun Jan 22 21:51:21 2012 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 ABB1A21F8528 for ; Sun, 22 Jan 2012 21:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 rHEslymKAVh9 for ; Sun, 22 Jan 2012 21:51:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 24B2421F849C for ; Sun, 22 Jan 2012 21:51:18 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 22 Jan 2012 21:51:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 22 Jan 2012 21:51:17 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 22 Jan 2012 21:51:18 -0800 Thread-Topic: Where we go from here Thread-Index: AczZkwaa8t8LLue5RXSNvE2Y0lXUGw== 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_F5833273385BB34F99288B3648C4F06F19C89DFAC6EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Where we go from here 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, 23 Jan 2012 05:51:21 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C89DFAC6EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With the imminent approval of the redaction draft, we are left with four cu= rrent documents. As we appear to be low on remaining steam, we need to dec= ide what to do with them. Barry and I are thinking that the working group = will meet in Paris at the end of March to tie up loose ends, and come in fo= r a landing shortly thereafter. What's below is my own current opinion on our documents, having observed th= e working group's current interest levels, consulting with Barry and Pete, = and knowing about other related IETF activity. 1) draft-ietf-marf-as ("Creation and Use of Email Feedback Reports: An Appl= icability Statement for the Abuse Reporting Format (ARF)") I believe this document is useful and possibly even important to get out th= ere. It's also the one closest to earning the labels "well-developed" and = "has consensus". We have some feedback on the current version that the wor= king group needs to process, and I hope we can do that in the coming few we= eks. I will also solicit a few more reviewers from outside MARF but within= the realm of abuse reporting and applicability statements. After that, I = think a Working Group Last Call would be in order, and then we can send it = to the IESG. 2) draft-ietf-marf-dkim-reporting ("Extensions to DKIM for Failure Reportin= g") Although the protocol specified here has been implemented in open source fo= r several years, there has been significant feedback within MARF on some po= ssible better ways to do it. I don't think the working group has the energ= y to invest in re-hashing it from the ground up and producing something wor= thy of the standards track that would then expect some widespread deploymen= t. Instead, I propose that this one be "parked", and eventually returned t= o "Individual" status and progressed outside of the working group, or perha= ps through APPSAWG if there's interest there, perhaps seeking Experimental = status. 3) draft-ietf-marf-spf-reporting ("SPF Authentication Failure Reporting usi= ng the Abuse Report Format") The feedback on the DKIM reporting draft makes me wonder if this one needs = to be revisited with a similar bent. Regardless, there will likely be more= energy for processing this one in the proposed "spfbis" working group rath= er than in MARF, so I suggest it be "parked", and if and when spfbis charte= rs (or re-charters) to take this on, it can pick up the work item. 4) draft-ietf-marf-reporting-discovery ("A DNS TXT Record for Advertising a= nd Discovering Willingness to Provide or Receive ARF Reports") This draft doesn't have a current champion. It also describes a protocol t= hat is not in any known open use, nor have we heard from anyone who plans t= o implement it. It's based on a proprietary protocol whose owner was seeki= ng to move it into open use, but currently doesn't have personnel to dedica= te to its advancement. I know there is a small amount of interest in MARF = to see this progress, but it also needs some significant interest from indu= stry, and we've seen no evidence of that at all. Accordingly, it is now a = "parked" working group document. It will expire later this month. I don't= believe we should continue to work on it. Feedback welcome. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C89DFAC6EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With the imminen= t approval of the redaction draft, we are left with four current documents.=   As we appear to be low on remaining steam, we need to decide what to= do with them.  Barry and I are thinking that the working group will m= eet in Paris at the end of March to tie up loose ends, and come in for a la= nding shortly thereafter.

  &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         

<= p class=3DMsoNormal>What’s below is my own current opinion on our doc= uments, having observed the working group’s current interest levels, = consulting with Barry and Pete, and knowing about other related IETF activi= ty.

 

1) draft-ietf-marf-as (“Creation and Use of Email Feedback Repo= rts: An Applicability Statement for the Abuse Reporting Format (ARF)”= )


I believe this document is useful = and possibly even important to get out there.  It’s also the one= closest to earning the labels “well-developed” and “has = consensus”.  We have some feedback on the current version that t= he working group needs to process, and I hope we can do that in the coming = few weeks.  I will also solicit a few more reviewers from outside MARF= but within the realm of abuse reporting and applicability statements. = ; After that, I think a Working Group Last Call would be in order, and then= we can send it to the IESG.

 =

2) draft-ietf-marf-dkim-reporting (“Ex= tensions to DKIM for Failure Reporting”)

 

Although the protocol spec= ified here has been implemented in open source for several years, there has= been significant feedback within MARF on some possible better ways to do i= t.  I don’t think the working group has the energy to invest in = re-hashing it from the ground up and producing something worthy of the stan= dards track that would then expect some widespread deployment.  Instea= d, I propose that this one be “parked”, and eventually returned= to “Individual” status and progressed outside of the working g= roup, or perhaps through APPSAWG if there’s interest there, perhaps s= eeking Experimental status.

 <= /o:p>

3) draft-ietf-marf-spf-reporting (“SPF = Authentication Failure Reporting using the Abuse Report Format”)=

 

Th= e feedback on the DKIM reporting draft makes me wonder if this one needs to= be revisited with a similar bent.  Regardless, there will likely be m= ore energy for processing this one in the proposed “spfbis” wor= king group rather than in MARF, so I suggest it be “parked”, an= d if and when spfbis charters (or re-charters) to take this on, it can pick= up the work item.

 

=

4) draft-ietf-marf-reporting-discovery (“A DNS T= XT Record for Advertising and Discovering Willingness to Provide or Receive= ARF Reports”)

 

This draft doesn’t have a current champion.&nb= sp; It also describes a protocol that is not in any known open use, nor hav= e we heard from anyone who plans to implement it.  It’s based on= a proprietary protocol whose owner was seeking to move it into open use, b= ut currently doesn’t have personnel to dedicate to its advancement.&n= bsp; I know there is a small amount of interest in MARF to see this progres= s, but it also needs some significant interest from industry, and we’= ve seen no evidence of that at all.  Accordingly, it is now a “p= arked” working group document.  It will expire later this month.=   I don’t believe we should continue to work on it.

 

Feedback w= elcome.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C89DFAC6EXCHC2corpclo_-- From sklist@kitterman.com Mon Jan 23 05:22:47 2012 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 C60DD21F871E for ; Mon, 23 Jan 2012 05:22:47 -0800 (PST) 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 02zAU3NwQaPL for ; Mon, 23 Jan 2012 05:22:47 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3343821F871B for ; Mon, 23 Jan 2012 05:22:47 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6A57720E40DA; Mon, 23 Jan 2012 08:22:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327324966; bh=tMAenATVHeXAK7mp0y6GaKXiWCyHme0hm0zgvAGw7qQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pvUdFLMSaHY2RWLNh3rsVrlBCPQH9u3YpmIZBZ78slWByi9i5L7Frx/njWmkXm7Uj 1GA5vmj133ACcKQxD+N/JfmCC1J2x0wzP6O+R+HkwbgIKwI95bhhTSn7C1pA0mYHhb OtWjY2O49afpvboy4SXT0ae0l32VQd5ZlEc02eZw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4C63620E408E; Mon, 23 Jan 2012 08:22:46 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 23 Jan 2012 08:22:45 -0500 Message-ID: <1527496.Y7FD2C1Apf@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Where we go from here 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, 23 Jan 2012 13:22:47 -0000 On Sunday, January 22, 2012 09:51:18 PM Murray S. Kucherawy wrote: > 3) draft-ietf-marf-spf-reporting ("SPF Authentication Failure Reporting > using the Abuse Report Format") > > The feedback on the DKIM reporting draft makes me wonder if this one needs > to be revisited with a similar bent. Regardless, there will likely be more > energy for processing this one in the proposed "spfbis" working group > rather than in MARF, so I suggest it be "parked", and if and when spfbis > charters (or re-charters) to take this on, it can pick up the work item. I would prefer to finish this. It's very close to done, there are no alternative approaches on the table, and it's currently out of scope for spfbis. The only significant issue to deal with is text for the downref. The rest is just minor stuff I've been waiting for us to be ready to pick up on this to do. Scott K From shmuel+gen@patriot.net Mon Jan 23 08:00:59 2012 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 0635121F87A9 for ; Mon, 23 Jan 2012 08:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-0.794, BAYES_40=-0.185] 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 CZ7jszy3A1aP for ; Mon, 23 Jan 2012 08:00:58 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 661F921F87A8 for ; Mon, 23 Jan 2012 08:00:58 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.169]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 90EF4F5808F for ; Mon, 23 Jan 2012 10:46:14 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 23 Jan 2012 08:19:40 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120123154640.90EF4F5808F@smtp.patriot.net> Subject: Re: [marf] Where we go from here 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, 23 Jan 2012 16:00:59 -0000 In , on 01/22/2012 at 09:51 PM, "Murray S. Kucherawy" said: >4) draft-ietf-marf-reporting-discovery ("A DNS TXT Record for >Advertising and Discovering Willingness to Provide or Receive ARF >Reports") I was planning to write code that used those data, but had some issues that I will bring up if a champion surfaces. I certainly see a need for at least the consumer side, although not necessarily in the same form. -- 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 shmuel+gen@patriot.net Mon Jan 23 08:01:11 2012 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 7084621F87B1 for ; Mon, 23 Jan 2012 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 qQJqRMvO5w0k for ; Mon, 23 Jan 2012 08:01:11 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 012AF21F87A8 for ; Mon, 23 Jan 2012 08:01:11 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.169]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 78716F5808F for ; Mon, 23 Jan 2012 10:46:57 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 23 Jan 2012 08:09:25 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120123154701.78716F5808F@smtp.patriot.net> Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 16:01:11 -0000 In , on 01/22/2012 at 09:38 PM, Barry Leiba said: >Even many DISCUSS comments are resolved with what will clearly be >non-controversial edits, A procedural question: is it necessary for multiple WG members to respond with "+1" to avoid an assumption of lack of interest? I tend to post only in response to drafts that I consider problematical or to issues that others have raised. -- 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 Jan 23 08:44:06 2012 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 E739421F86C2 for ; Mon, 23 Jan 2012 08:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 t4UKKmJKmxwF for ; Mon, 23 Jan 2012 08:44:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8D21F86C1 for ; Mon, 23 Jan 2012 08:44:06 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 08:44:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 08:44:05 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 08:44:04 -0800 Thread-Topic: [marf] DISCUSS on draft-ietf-marf-redaction-04 Thread-Index: AczZ6DtuIMeN8UWkQTmg4Ag5Tg66NgABbzqQ Message-ID: References: <20120123154701.78716F5808F@smtp.patriot.net> In-Reply-To: <20120123154701.78716F5808F@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] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 16:44:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, January 23, 2012 5:09 AM > To: marf@ietf.org > Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 >=20 > A procedural question: is it necessary for multiple WG members to > respond with "+1" to avoid an assumption of lack of interest? I tend to > post only in response to drafts that I consider problematical or to > issues that others have raised. The IETF likes to see a record of consensus and support for decisions it ma= kes, including publication of documents. A "+1" is better than nothing, bu= t ideal would be "I've read this, I agree with what it says, and I believe = it should go forward to publication" or words to that effect. Absent that, the statement of consensus or support for a document is far we= aker, and someone would be within his/her rights to claim there's no indica= tion of support justifying publication. In short, silent reviewers don't help anyone. -MSK From msk@cloudmark.com Mon Jan 23 08:44:43 2012 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 07E2421F86C2 for ; Mon, 23 Jan 2012 08:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ieRk4XQ3y-OP for ; Mon, 23 Jan 2012 08:44:42 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9E21F86C1 for ; Mon, 23 Jan 2012 08:44:42 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 08:44:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 08:44:41 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 08:44:40 -0800 Thread-Topic: [marf] Where we go from here Thread-Index: AczZ6DRMtlJLRErTT1y7ZR+bjFdNgwABgqFA Message-ID: References: <20120123154640.90EF4F5808F@smtp.patriot.net> In-Reply-To: <20120123154640.90EF4F5808F@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] Where we go from here 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, 23 Jan 2012 16:44:43 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Monday, January 23, 2012 5:20 AM > To: marf@ietf.org > Subject: Re: [marf] Where we go from here >=20 > >4) draft-ietf-marf-reporting-discovery ("A DNS TXT Record for > >Advertising and Discovering Willingness to Provide or Receive ARF > >Reports") >=20 > I was planning to write code that used those data, but had some issues > that I will bring up if a champion surfaces. I certainly see a need for > at least the consumer side, although not necessarily in the same form. That gets us half way there. We need to see interest from the producer sid= e too, and to date there has been none. From dcrocker@bbiw.net Mon Jan 23 08:55:06 2012 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 053D421F8734 for ; Mon, 23 Jan 2012 08:55:06 -0800 (PST) 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 xq41plsAAj87 for ; Mon, 23 Jan 2012 08:55:04 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72ACC21F872D for ; Mon, 23 Jan 2012 08:55:04 -0800 (PST) Received: from [192.168.1.9] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0NGsuVJ013352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 08:55:01 -0800 Message-ID: <4F1D90DE.1030800@bbiw.net> Date: Mon, 23 Jan 2012 08:54:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 23 Jan 2012 08:55:02 -0800 (PST) X-Mailman-Approved-At: Mon, 23 Jan 2012 08:56:07 -0800 Cc: Pete Resnick , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 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, 23 Jan 2012 16:55:06 -0000 On 1/22/2012 6:38 PM, Barry Leiba wrote: > > During the last WG > > chair lunch, we had a discussion about copying all ballot DISCUSSes and > > COMMENTs to the WG mailing list and I think this is exactly the right thing > to do. So do I. > Let me, as a WG chair, urge you NOT to do it that way, but to let the chairs > handle the decision of what needs to go to active WG discussion and when. This is the IETF model of roughly two decades. It has a basic flaw: The premise of the open IETF processes is that open collaboration means broad-based review, diverse perspectives and broad-based support for whatever is decided. Closed processes make it more likely that there will be narrower perspectives -- and therefore some aspect of the issue missed -- and less support. It actually makes an AD less accountable for their Discuss. It certainly puts more of a burden on working groups to guess at what the AD wants and guess at what will resolve matters. Working group discussion and other reviews are open and collaborative. All of the details, major and minor, for handling concerns is public and on the wg mailing list. Working groups already have the challenge of dealing with trivia, irritations, and basic disagreements. Why should the direct, specific objections of an AD be kept out of that forum? Or rather, why shouldn't the person lodging them be automatically required to take them directly to the working group? Why should ADs be immune from the requirement to take their concerns to the chartered forum that is established for conducting exactly such discussions? Further, AD Discusses are now publicly documented. So the step you are objecting to is a matter of convenience, not availability. And it streamlines the resolution process by eliminating the information gatekeeping by whoever is mediating between the AD and the working group: It puts the AD directly in front of the folks whose work is being challenged. The current model is that an AD lodges the Discuss but the direct reporting of the fact and the explanation is left to be mediated by a chair or author. There are cliches about the effects of having someone in the middle, trying to interpret things. > By > all means, chat with your chairs and tell us what you expect. But let us manage > the WG discussions. What you are calling for is not "managing wg discussion". It is gatekeeping the resolution process with the AD. That's an entirely different and far less healthy matter. > The majority of the non-DISCUSS comments are dealt with by such minor editorial > changes that opening the discussion up to WG comments will likely inundate the > entire IESG unnecessarily "The entire IESG"? I don't understand how this suddenly puts the entire IESG into the main flow of interaction between the AD who is blocking things and the wg that is being blocked. In any event, a Discuss is expensive for the wg. Why shouldn't it be expensive for the ADs lodging them? > Even many DISCUSS comments are resolved with what will clearly be > non-controversial edits, which should well be reviewed by the WG, but which > don't need to have the WG engaged in the discussion. This is a classic error in logic: The current mechanism often works adequately, so let's ignore the times it doesn't and let's ignore its inefficiencies an inequities. My core point is that the /design/ of the current process is inherently flawed: it violates the IETF's model for handling objections that pervades every other aspect of IETF work. > In this case, in fact, Murray did bring the discussion to the WG, without your > needing to force it. This places an undue burden on chairs and/or authors. Put the onus on the AD: lodge a Discuss and you will be directly accountable to /all/ of the people whose work you are blocking. You will then be required to explain and negotiate directly. ADs are smart folk. They often have extremely important and valid concerns. They often see a problem that really does need addressing. Make them pursue it in the forum where all other such matters get pursued: the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Jan 23 08:59:21 2012 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 DEB3021F8740 for ; Mon, 23 Jan 2012 08:59:21 -0800 (PST) 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 Ml9Iba6BxLJh for ; Mon, 23 Jan 2012 08:59:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6F221F8712 for ; Mon, 23 Jan 2012 08:59:21 -0800 (PST) Received: from [192.168.1.9] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0NGwtRn013452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 08:59:01 -0800 Message-ID: <4F1D91CE.1050805@dcrocker.net> Date: Mon, 23 Jan 2012 08:58:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 23 Jan 2012 08:59:01 -0800 (PST) Cc: Pete Resnick , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 23 Jan 2012 16:59:22 -0000 On 1/22/2012 6:38 PM, Barry Leiba wrote: > > During the last WG > > chair lunch, we had a discussion about copying all ballot DISCUSSes and > > COMMENTs to the WG mailing list and I think this is exactly the right thing > to do. So do I. > Let me, as a WG chair, urge you NOT to do it that way, but to let the chairs > handle the decision of what needs to go to active WG discussion and when. This is the IETF model of roughly two decades. It has a basic flaw: The premise of the open IETF processes is that open collaboration means broad-based review, diverse perspectives and broad-based support for whatever is decided. Closed processes make it more likely that there will be narrower perspectives -- and therefore some aspect of the issue missed -- and less support. It actually makes an AD less accountable for their Discuss. It certainly puts more of a burden on working groups to guess at what the AD wants and guess at what will resolve matters. Working group discussion and other reviews are open and collaborative. All of the details, major and minor, for handling concerns is public and on the wg mailing list. Working groups already have the challenge of dealing with trivia, irritations, and basic disagreements. Why should the direct, specific objections of an AD be kept out of that forum? Or rather, why shouldn't the person lodging them be automatically required to take them directly to the working group? Why should ADs be immune from the requirement to take their concerns to the chartered forum that is established for conducting exactly such discussions? Further, AD Discusses are now publicly documented. So the step you are objecting to is a matter of convenience, not availability. And it streamlines the resolution process by eliminating the information gatekeeping by whoever is mediating between the AD and the working group: It puts the AD directly in front of the folks whose work is being challenged. The current model is that an AD lodges the Discuss but the direct reporting of the fact and the explanation is left to be mediated by a chair or author. There are cliches about the effects of having someone in the middle, trying to interpret things. > By > all means, chat with your chairs and tell us what you expect. But let us manage > the WG discussions. What you are calling for is not "managing wg discussion". It is gatekeeping the resolution process with the AD. That's an entirely different and far less healthy matter. > The majority of the non-DISCUSS comments are dealt with by such minor editorial > changes that opening the discussion up to WG comments will likely inundate the > entire IESG unnecessarily "The entire IESG"? I don't understand how this suddenly puts the entire IESG into the main flow of interaction between the AD who is blocking things and the wg that is being blocked. In any event, a Discuss is expensive for the wg. Why shouldn't it be expensive for the ADs lodging them? > Even many DISCUSS comments are resolved with what will clearly be > non-controversial edits, which should well be reviewed by the WG, but which > don't need to have the WG engaged in the discussion. This is a classic error in logic: The current mechanism often works adequately, so let's ignore the times it doesn't and let's ignore its inefficiencies an inequities. My core point is that the /design/ of the current process is inherently flawed: it violates the IETF's model for handling objections that pervades every other aspect of IETF work. > In this case, in fact, Murray did bring the discussion to the WG, without your > needing to force it. This places an undue burden on chairs and/or authors. Put the onus on the AD: lodge a Discuss and you will be directly accountable to /all/ of the people whose work you are blocking. You will then be required to explain and negotiate directly. ADs are smart folk. They often have extremely important and valid concerns. They often see a problem that really does need addressing. Make them pursue it in the forum where all other such matters get pursued: the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Mon Jan 23 08:59:22 2012 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 9BEA221F8712; Mon, 23 Jan 2012 08:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 cXLT6Entu3fT; Mon, 23 Jan 2012 08:59:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1C21F8700; Mon, 23 Jan 2012 08:59:01 -0800 (PST) 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.64p1 Message-ID: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 08:59:01 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 16:59:23 -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 M. Kucherawy Filename : draft-ietf-marf-redaction-06.txt Pages : 8 Date : 2012-01-23 Email messages often contain information that 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-06.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-06.txt From presnick@qualcomm.com Mon Jan 23 09:35:28 2012 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 415E521F862A for ; Mon, 23 Jan 2012 09:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 S9vCzu9f+D7c for ; Mon, 23 Jan 2012 09:35:27 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4826B21F84A2 for ; Mon, 23 Jan 2012 09:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327340127; x=1358876127; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1D9A55.602@qualcomm.com>|Date:=20Mon, =2023=20Jan=202012=2011:35:17=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Dave=20CROCKER=20|CC:=20Barry=20Leiba=20, =20Message=20Abuse=20Report=20Format=20working=0D=0A=20gr oup=20|Subject:=20DISCUSS=20handling=20(Wa s:=20DISCUSS=20on=20draft-ietf-marf-redaction-04) |References:=20=09<4F18ACA8.2010309@qualcom m.com>=09=09=09=09< F5833273385BB34F99288B3648C4F06F19C89DFA9D@EXCH-C2.corp.c loudmark.com>=09=09<4F1A0049.4040008@qualc omm.com>=09=09<4F1C4F0D.6090205@qualcomm.com> =20<4F1C5AAC.8030509@dcrocker.net>=09<4F1CA7F8.6050703@qu alcomm.com>=09=20<4F1D90DE.1030800@bbiw.net> |In-Reply-To:=20<4F1D90DE.1030800@bbiw.net>|Content-Type: =20text/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Df lowed|Content-Transfer-Encoding:=207bit|X-Originating-IP: =20[172.30.39.5]; bh=992azpNmSy3mKKnEsDcvW6KL7uOJLgYT1OQRypeg8A0=; b=VIwVWBuGBPaTE0+Gm//+PqIDXmaTuIsG6FhRw9btGpcGHNjQszndO18I rx1p5dVXkCBE5R+e4FvASrJe5SoaUYYjdivzbhPg0geZEZHsSk1zu1Vc8 iBRNAV8tIVD4Y2L1/Ib5aoL1XsRu66hz4sScmNLSD1SsFalu6F9YCxGON I=; X-IronPort-AV: E=McAfee;i="5400,1158,6597"; a="157270721" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 23 Jan 2012 09:35:24 -0800 X-IronPort-AV: E=Sophos;i="4.71,556,1320652800"; d="scan'208";a="119002764" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Jan 2012 09:35:24 -0800 Received: from san-chumbone-aa_san-chumbone-r.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 23 Jan 2012 09:35:23 -0800 Message-ID: <4F1D9A55.602@qualcomm.com> Date: Mon, 23 Jan 2012 11:35:17 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Dave CROCKER References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> <4F1D90DE.1030800@bbiw.net> In-Reply-To: <4F1D90DE.1030800@bbiw.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Barry Leiba , Message Abuse Report Format working group Subject: [marf] DISCUSS handling (Was: DISCUSS on draft-ietf-marf-redaction-04) 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, 23 Jan 2012 17:35:28 -0000 This is probably something to be moved to a different list; I've at least changed the subject, since we're now on the general topic and not something specific to this WG. I'll ask for the chairs guidance, and if they want this moved off somewhere else we can do so. On 1/23/12 10:54 AM, Dave CROCKER wrote: > On 1/22/2012 6:38 PM, Barry Leiba wrote: > >> Let me, as a WG chair, urge you NOT to do it that way, but to let the >> chairs >> handle the decision of what needs to go to active WG discussion and when. As I said, this is a different thing than what we have been doing and I will not be doing so without first consulting with chairs and making sure they can and will manage the discussion reasonably. I'm not going to be springing this on anyone. But I do think that this needs to be done in the long run and, with proper preparation, I think it can be done reasonably. > The premise of the open IETF processes is that open collaboration > means broad-based review, diverse perspectives and broad-based support > for whatever is decided. > > Closed processes make it more likely that there will be narrower > perspectives -- and therefore some aspect of the issue missed -- and > less support. It actually makes an AD less accountable for their > Discuss. It certainly puts more of a burden on working groups to > guess at what the AD wants and guess at what will resolve matters. Right. One alternate means for doing this is moderating discussion. We are generally loathe to do moderated mailing list postings in the IETF unless things have gotten entirely out of hand in a WG, but we do allow it. If in particular instances chairs feel that a WG would be ill-served by a DISCUSS thread on the WG mailing list, moderation of the WG list (or a separate list specifically for the DISCUSS) could be put in place. That would leave things somewhat open. But I don't think this is ideal. Remember, this is a change in behavior for all of us, so we do have to make these kinds of changes with open eyes. > Further, AD Discusses are now publicly documented. Right. But the additional worry I have is that responses to it are *not* publicly documented (i.e., when chairs or editors reply to the AD for clarifications, potential resolutions, etc.) unless the AD takes the additional step to update their comments in the tracker. That certainly needs to change. So, even if it is a moderated discussion, we need to do something different to document that discussion. > So the step you are objecting to is a matter of convenience, not > availability. And it streamlines the resolution process by > eliminating the information gatekeeping by whoever is mediating > between the AD and the working group: It puts the AD directly in > front of the folks whose work is being challenged. This is dependent on the AD *and* the WG involved. An AD might bring up an issue that was clearly resolved by a WG many months (years!) ago. Without a bit of restraint by the WG, a lot of sturm und drong can be generated if folks don't just wait for the chair or cognizant AD to explain, "We are aware of that issue, discussed it at length in the WG, and resolved it in this way for the following reasons." (This, BTW, can happen whenever anyone outside the WG comes in to participate without the history, but AD DISCUSS ballots generate a lot more sturm und drong because of how late they happen in the process and how solidly they can knot things up.) So it's a bit more than convenience. It's sometimes manageability of the WG process. But it's not something that can't be handled. >> The majority of the non-DISCUSS comments are dealt with by such minor >> editorial >> changes that opening the discussion up to WG comments will likely >> inundate the >> entire IESG unnecessarily > > "The entire IESG"? I don't understand how this suddenly puts the > entire IESG into the main flow of interaction between the AD who is > blocking things and the wg that is being blocked. Because the current model is that all replies to the DISCUSS messages are Cc'ed directly to the IESG list. And the IESG often does engage in that DISCUSSion. So when we embark upon this model, we're going to have to adjust several things that we're doing to keep everyone sane. Again, it can all be handled, but we have to be clear with everyone how it goes. > In any event, a Discuss is expensive for the wg. Why shouldn't it be > expensive for the ADs lodging them? Indeed, and it's expensive for the IESG as a whole. However, while simply increasing the expense for everyone is one approach, it's probably not ideal. Again, I think having all AD comments (DISCUSS or COMMENT) go to the WG list is the preferred outcome, but it is a cultural change. I want to do it carefully and deliberately. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From msk@cloudmark.com Mon Jan 23 10:22:32 2012 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 8921E21F851E for ; Mon, 23 Jan 2012 10:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 mmkYTzJMZYA4 for ; Mon, 23 Jan 2012 10:22:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7921F84FF for ; Mon, 23 Jan 2012 10:22:31 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 10:22:31 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 23 Jan 2012 10:22:31 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 10:22:29 -0800 Thread-Topic: [marf] Some thoughts on draft-ietf-marf-as-02 Thread-Index: AczQ2jVUGarVPGSoRfiij2po7tZYIgJH+EyA Message-ID: References: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> In-Reply-To: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@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] Some thoughts on draft-ietf-marf-as-02 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, 23 Jan 2012 18:22:32 -0000 As participant: > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Wednesday, January 11, 2012 7:28 PM > To: Message Abuse Report Format working group > Subject: [marf] Some thoughts on draft-ietf-marf-as-02 >=20 > Section 5. Solicited and Unsolicited Reports > [...] > Non-actionable reports - whether they be false positives or not - > reduce the efficiency of an abuse desk. Let's just not mention reports > of mail scored high by spam filters, and quietly leave it as part of > "anything else the sender considers". I agree, and actually I agree enough that I would advocate for addition of = a SHOULD NOT. The question is one of wording. Perhaps: A report generator SHOULD NOT generate automated reports based on inline co= ntent analysis tools that apply subjective rules. This can cause reports t= hat, because of their subjective nature, are not actionable by report recei= vers, which wastes valuable operator time in processing them. > The DKIM signer of a message is definitely a good target for solicited > reports as part of a feedback loop. For unsolicited reports it's much > less clear that that's the case. There are some mechanical reasons - > the d=3D value is an identifier for reputation, not a domain intended to > receive email, so we don't want to imply that > abuse@transactional.blighty.com is automatically a good place to report > mail that's signed with d=3Dtransactional.blighty.com. In a broader > sense, though, it's likely that the DKIM signing domain is the author > of the mail - and if the mail is objectionable, they're often the least > useful place to notify. In the case of mail sent through an ESP, the > DKIM d=3D domain is likely to end up at the customer, rather than at the > ESP where it's more likely to be handled correctly. This is true, but I don't think that means the advice at the bottom of Sect= ion 5 is wrong, since it only suggests the DKIM-verified domain is a "reaso= nable candidate". Perhaps the right thing to do is describe cases where th= at'll be a good guess, but a wrong one. > That's one instance of a more general issue of sending automated, > unsolicited reports. Identifying an appropriate recipient for a report > is *hard* to do automatically, while "shotgunning" reports to multiple > email addresses because one of them might be appropriate is unhelpful. > Sending them in a format that's intended primarily to be machine- > readable and handled automatically by the entity receiving the reports > leads to the problem of knowing what email address at what entity is > intended to handle machine-readable reports. There's no standard for > it, and there's a risk that those machine-readable reports will be > discarded or ignored if they're sent to role addresses chosen at > random. >=20 > Section 8 discusses this issue again, and somewhat better. Would it > make sense to move the mention of DKIM to section 8, where it would be > in a better context? Yes, that seems reasonable. I also think Section 8 should start at "abuse@" (referenced in Section 7) a= s being the only reasonable default. > Section 7. Receiving and Processing Complaint-Based Solicited Reports >=20 > "Point 3 - Mail operators SHOULD utilize an automated system to receive > and process these reports". >=20 > That's really an engineering and operational decision. If I only > receive two or three ARF reports a day, and my MUA or ticketing system > can display them correctly, then handling them as part of my usual > customer support / abuse desk workflow is likely to be more reliable > (and much less expensive to implement) than an automated system. An ARF > based FBL is still of value to me, but automating it would be a poor > decision. RFC 6449 Section 4.4 says pretty much that. I think we'd be > better just pointing people at that section of RFC 6449, rather than > saying that automation is a SHOULD. Works for me. > Section 8. Generating and Handling Unsolicited Reports >=20 > Is authentication failure abusive? If it is, we should say why (and in > what context). If not, it shouldn't be in this document. There are cases where one might think it is, such as ADSP violations for si= tes that put a lot of faith in it, but it's not universal. Additional deta= il might be helpful there. > I'm not sure it's true that "even recipient systems that haven't asked > for ARF format reports handle them at least as well as any other format > such as plain text, with or without a copy of the message attached." >=20 > I know for sure that there are ticketing systems in use that don't > handle anything other than plain text particularly well. They will not > handle ARF reports as well as they would handle plain text. I imagine the text there envisions a system that handles in an automated fa= shion anything that it understands, and leaves the rest to operators to fig= ure out. > Unexpected multipart/* formats (such as the multipart/report type used > by ARF) aren't necessarily going to be handled well even by MIME aware > MUAs. Similarly, message/feedback-report isn't necessarily going to be > handled well by MIME aware MUAs. I don't think that paragraph means to include MUAs in the agents it's discu= ssing, but rather is referring to automated systems. Perhaps that should b= e made clearer here. > So... I don't think it's valid to say that recipient systems that are not > advertised to accept ARF will render ARF format messages in a way that > will lead to them being handled. At the very least, anyone sending > unsolicited messages in ARF format must assume that recipients will not > be able to see the ARF metadata, and should include all information > needed in human readable format in the first, text/plain section of the > report. Also, they should ensure that the report is readable when > viewed as plain text, to give low end ticketing systems as much help as > possible - that might includes advice on appropriate MIME encoding and > choice of character sets and so on. And they should be aware that the > report may be discarded or ignored due to it's format. I wouldn't object to including this advice while avoiding use of normative = language. That is, I wouldn't want to say "SHOULD put all the useful data = in the text/plain part of an ARF report", because then why bother at all? -MSK From internet-drafts@ietf.org Mon Jan 23 10:47:36 2012 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 0C5FB21F869C; Mon, 23 Jan 2012 10:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 c7OtlzLPuXKs; Mon, 23 Jan 2012 10:47:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3D21F85A5; Mon, 23 Jan 2012 10:47:35 -0800 (PST) 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.64p1 Message-ID: <20120123184735.2476.10443.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 10:47:35 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-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, 23 Jan 2012 18:47:36 -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 : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-03.txt Pages : 8 Date : 2012-01-23 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-03.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-as-03.txt From msk@cloudmark.com Mon Jan 23 10:49:09 2012 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 20DDF21F869C for ; Mon, 23 Jan 2012 10:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 kM1By1ACrwIT for ; Mon, 23 Jan 2012 10:49:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B75F321F8693 for ; Mon, 23 Jan 2012 10:49:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 10:49:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 10:49:08 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 23 Jan 2012 10:49:07 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-03.txt Thread-Index: AczZ/3qOZCETnmTaQf6k1GfGYQ0oJAAABTOQ Message-ID: References: <20120123184735.2476.10443.idtracker@ietfa.amsl.com> In-Reply-To: <20120123184735.2476.10443.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-as-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, 23 Jan 2012 18:49:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Monday, January 23, 2012 10:48 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-as-03.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 : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-03.txt > Pages : 8 > Date : 2012-01-23 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. Just folding in recent feedback and resetting the expiration clock, since t= his is now the main work item. Further review and comments, please. -MSK From steve@wordtothewise.com Mon Jan 23 11:10:15 2012 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 A5EDC21F86B5 for ; Mon, 23 Jan 2012 11:10:14 -0800 (PST) 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 hcIBv6Pn0JBD for ; Mon, 23 Jan 2012 11:10:13 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA821F86B0 for ; Mon, 23 Jan 2012 11:10:10 -0800 (PST) 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 4B4A92DECF for ; Mon, 23 Jan 2012 11:09:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Mon, 23 Jan 2012 11:09:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15062D3E-E99B-4A11-84AF-73909C11964B@wordtothewise.com> References: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 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, 23 Jan 2012 19:10:15 -0000 On Jan 23, 2012, at 10:22 AM, Murray S. Kucherawy wrote: > As participant: >>=20 >> Section 5. Solicited and Unsolicited Reports >> [...] >> Non-actionable reports - whether they be false positives or not - >> reduce the efficiency of an abuse desk. Let's just not mention = reports >> of mail scored high by spam filters, and quietly leave it as part of >> "anything else the sender considers". >=20 > I agree, and actually I agree enough that I would advocate for = addition of a SHOULD NOT. The question is one of wording. Perhaps: >=20 > A report generator SHOULD NOT generate automated reports based on = inline content analysis tools that apply subjective rules. This can = cause reports that, because of their subjective nature, are not = actionable by report receivers, which wastes valuable operator time in = processing them. This does overlap with malware detection, though. Malware detection is = based on subjective heuristics, and does have occasional false = positives, but I think a report of an IP address sending malware would = be considered actionable by an ISP abuse desk where a report of it = sending "spam" based on subjective heuristics wouldn't. I'm not sure what the distinction is other than "likely to be = actionable". >> The DKIM signer of a message is definitely a good target for = solicited >> reports as part of a feedback loop. For unsolicited reports it's much >> less clear that that's the case. There are some mechanical reasons - >> the d=3D value is an identifier for reputation, not a domain intended = to >> receive email, so we don't want to imply that >> abuse@transactional.blighty.com is automatically a good place to = report >> mail that's signed with d=3Dtransactional.blighty.com. In a broader >> sense, though, it's likely that the DKIM signing domain is the author >> of the mail - and if the mail is objectionable, they're often the = least >> useful place to notify. In the case of mail sent through an ESP, the >> DKIM d=3D domain is likely to end up at the customer, rather than at = the >> ESP where it's more likely to be handled correctly. >=20 > This is true, but I don't think that means the advice at the bottom of = Section 5 is wrong, since it only suggests the DKIM-verified domain is a = "reasonable candidate". =20 It's not wrong, but it's a bit misleading. Calling out a DKIM-verified = domain in particular as a good candidate suggests it's one that should = be used, even though it's often going to be a bad candidate and the = heuristics needed to work out whether it's appropriate or not aren't = trivial. > Perhaps the right thing to do is describe cases where that'll be a = good guess, but a wrong one. Perhaps. I think moving it to section 8 helps resolve the problem, as = the context is there. >> Section 8 discusses this issue again, and somewhat better. Would it >> make sense to move the mention of DKIM to section 8, where it would = be >> in a better context? >=20 > Yes, that seems reasonable. >=20 > I also think Section 8 should start at "abuse@" (referenced in Section = 7) as being the only reasonable default. Probably, yes. That leaves open the question of "which domain", though. = The existing wording is sensible, but very vague on implementation = details (sensibly - it's something tricky to do well, and non-trivial to = even do non-abusively). The more we try and get into details there, the = more we're going to hit problems. > Section 8. Generating and Handling Unsolicited Reports >>=20 >> Is authentication failure abusive? If it is, we should say why (and = in >> what context). If not, it shouldn't be in this document. >=20 > There are cases where one might think it is, such as ADSP violations = for sites that put a lot of faith in it, but it's not universal. = Additional detail might be helpful there. Yup. It's not obvious which cases this means, so we probably need more = detail if we're going to mention it. (Does this overlap with draft-ietf-marf-dkim-reporting and = draft-ietf-marf-spf-reporting?) >> I'm not sure it's true that "even recipient systems that haven't = asked >> for ARF format reports handle them at least as well as any other = format >> such as plain text, with or without a copy of the message attached." >>=20 >> I know for sure that there are ticketing systems in use that don't >> handle anything other than plain text particularly well. They will = not >> handle ARF reports as well as they would handle plain text. >=20 > I imagine the text there envisions a system that handles in an = automated fashion anything that it understands, and leaves the rest to = operators to figure out. Operators who are using typical MUAs or low-end CRM systems will have = difficulty handling ARF reports at all, and may only have convenient = access to the text/plain part of the message. If the intent is that the = report is acted on, it has to be able to be read and acted on by those = operators as well as by automation. >> Unexpected multipart/* formats (such as the multipart/report type = used >> by ARF) aren't necessarily going to be handled well even by MIME = aware >> MUAs. Similarly, message/feedback-report isn't necessarily going to = be >> handled well by MIME aware MUAs. >=20 > I don't think that paragraph means to include MUAs in the agents it's = discussing, but rather is referring to automated systems. Perhaps that = should be made clearer here. If you're sending solicited reports that's a sensible distinction. I'm = not sure it is in this context. >> So... I don't think it's valid to say that recipient systems that are = not >> advertised to accept ARF will render ARF format messages in a way = that >> will lead to them being handled. At the very least, anyone sending >> unsolicited messages in ARF format must assume that recipients will = not >> be able to see the ARF metadata, and should include all information >> needed in human readable format in the first, text/plain section of = the >> report. Also, they should ensure that the report is readable when >> viewed as plain text, to give low end ticketing systems as much help = as >> possible - that might includes advice on appropriate MIME encoding = and >> choice of character sets and so on. And they should be aware that the >> report may be discarded or ignored due to it's format. >=20 > I wouldn't object to including this advice while avoiding use of = normative language. That is, I wouldn't want to say "SHOULD put all the = useful data in the text/plain part of an ARF report", because then why = bother at all? You're sending unsolicited reports to people whose capabilities you have = fairly limited information about. You would like them to be able to = process that report using whatever system you happen to end up being = delivered to. That includes ARF-aware full automation in some cases, and = it includes very basic web-based MUAs (ticketing systems) in other = cases. If you want the report to be easily processed by the ARF-aware = automation then all the information needs to be available as ARF = metadata. If you want the report to be easily processed by an MUA then = it needs to be easily readable using a text/plain MUA. If you want it to be easily processed by both types of recipient, and = you don't know which you're sending it to, then it needs to both have = ARF metadata and be easily readable using a text/plain MUA. Anyone sending ARF-only reports with a non-actionable plain text part = today is making the same sort of decision as someone who sent = text/html-only email a decade ago. It's great for recipients who can = read it, but many can't. That doesn't mean that we need normative = language, but making it clear that if you're sending unsolicited reports = that are not readable by a text/plain level MUA you may well be wasting = your time and, more importantly, the time of the recipient of your = report is something we should probably mention. "Senders SHOULD NOT assume that the recipient of an unsolicited report = is able to make full use of an ARF format report. Unless the sender has = reason to believe that all recipients of an unsolicited report can = conveniently handle ARF format then they SHOULD ensure that the report = is clear and contains enough information to be handled appropriately = when viewed in a typical MUA or ticketing system." There's another can of worms - if we're talking about sending = unsolicited email to addresses guessed at via heuristics, do we also = want to talk about "MUST provide an easy way to opt-out of all future = reports"? Cheers, Steve From msk@cloudmark.com Mon Jan 23 11:24:15 2012 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 6426421F8535 for ; Mon, 23 Jan 2012 11:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 KdO1JonoDOIb for ; Mon, 23 Jan 2012 11:24:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC42821F8528 for ; Mon, 23 Jan 2012 11:24:14 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 11:24:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 11:24:14 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 11:24:12 -0800 Thread-Topic: [marf] Some thoughts on draft-ietf-marf-as-02 Thread-Index: AczaAqjByt/7liV7S/WbYByWis/yVwAARS1g Message-ID: References: <74FD4973-F0B2-4C86-BA47-DE83C311FF31@wordtothewise.com> <15062D3E-E99B-4A11-84AF-73909C11964B@wordtothewise.com> In-Reply-To: <15062D3E-E99B-4A11-84AF-73909C11964B@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] Some thoughts on draft-ietf-marf-as-02 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, 23 Jan 2012 19:24:15 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Monday, January 23, 2012 11:10 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Some thoughts on draft-ietf-marf-as-02 >=20 > > A report generator SHOULD NOT generate automated reports based on > > inline content analysis tools that apply subjective rules. This can > > cause reports that, because of their subjective nature, are not > > actionable by report receivers, which wastes valuable operator time in > > processing them. >=20 > This does overlap with malware detection, though. Malware detection is > based on subjective heuristics, and does have occasional false > positives, but I think a report of an IP address sending malware would > be considered actionable by an ISP abuse desk where a report of it > sending "spam" based on subjective heuristics wouldn't. >=20 > I'm not sure what the distinction is other than "likely to be > actionable". Ah, true. But reducing this to just talk about "likely to be actionable" f= ails to point out the very distinction you've made, which I think is a good= one. How about: OLD However, it is inadvisable to generate automated reports based on inline content analysis tools that apply subjective evaluation rules. This can cause reports that, because of their subjective nature, are not actionable by report receivers, which wastes valuable operator time in processing them. NEW However, it is inadvisable to generate automated reports based on inline content analysis tools that apply subjective evaluation rules, such as filters that attempt to classify spam or phishing. This can cause reports that, because of their subjective nature, are not actionable by report receivers, which wastes valuable operator time in processing them. By contrast, virus detection reports are far more likely to be actionable. > > This is true, but I don't think that means the advice at the bottom > > of Section 5 is wrong, since it only suggests the DKIM-verified domain > > is a "reasonable candidate". >=20 > It's not wrong, but it's a bit misleading. Calling out a DKIM-verified > domain in particular as a good candidate suggests it's one that should > be used, even though it's often going to be a bad candidate and the > heuristics needed to work out whether it's appropriate or not aren't > trivial. >=20 > > Perhaps the right thing to do is describe cases where that'll be a > > good guess, but a wrong one. >=20 > Perhaps. I think moving it to section 8 helps resolve the problem, as > the context is there. >=20 > > I also think Section 8 should start at "abuse@" (referenced in > > Section 7) as being the only reasonable default. >=20 > Probably, yes. That leaves open the question of "which domain", though. > The existing wording is sensible, but very vague on implementation > details (sensibly - it's something tricky to do well, and non-trivial > to even do non-abusively). The more we try and get into details there, > the more we're going to hit problems. Have a look at -03 (now posted) and see what you think. > > Section 8. Generating and Handling Unsolicited Reports > >> > >> Is authentication failure abusive? If it is, we should say why (and > >> in what context). If not, it shouldn't be in this document. > > > > There are cases where one might think it is, such as ADSP violations > > for sites that put a lot of faith in it, but it's not universal. > > Additional detail might be helpful there. >=20 > Yup. It's not obvious which cases this means, so we probably need more > detail if we're going to mention it. >=20 > (Does this overlap with draft-ietf-marf-dkim-reporting and draft-ietf- > marf-spf-reporting?) No, I don't think so. (And I think we should avoid doing so.) > >> I know for sure that there are ticketing systems in use that don't > >> handle anything other than plain text particularly well. They will > >> not handle ARF reports as well as they would handle plain text. > > > > I imagine the text there envisions a system that handles in an > > automated fashion anything that it understands, and leaves the rest to > > operators to figure out. >=20 > Operators who are using typical MUAs or low-end CRM systems will have > difficulty handling ARF reports at all, and may only have convenient > access to the text/plain part of the message. If the intent is that the > report is acted on, it has to be able to be read and acted on by those > operators as well as by automation. Have a look at -03 and see what you think. > There's another can of worms - if we're talking about sending > unsolicited email to addresses guessed at via heuristics, do we also > want to talk about "MUST provide an easy way to opt-out of all future > reports"? Yes, that's probably good to include as well. Absent objection, I'll add t= hat in -04. -MSK From dhc@dcrocker.net Mon Jan 23 11:29:52 2012 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 B700821F8535 for ; Mon, 23 Jan 2012 11:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.753 X-Spam-Level: X-Spam-Status: No, score=-6.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 wAT2fEUm9-HH for ; Mon, 23 Jan 2012 11:29:51 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9CB821F8528 for ; Mon, 23 Jan 2012 11:29:51 -0800 (PST) Received: from [192.168.1.9] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0NJTfDK016126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 11:29:47 -0800 Message-ID: <4F1DB524.4010202@dcrocker.net> Date: Mon, 23 Jan 2012 11:29:40 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Pete Resnick References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> <4F1D90DE.1030800@bbiw.net> <4F1D9A55.602@qualcomm.com> In-Reply-To: <4F1D9A55.602@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 23 Jan 2012 11:29:47 -0800 (PST) Cc: Barry Leiba , Dave CROCKER , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS handling (Was: DISCUSS on draft-ietf-marf-redaction-04) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 23 Jan 2012 19:29:52 -0000 On 1/23/2012 9:35 AM, Pete Resnick wrote: > This is probably something to be moved to a different list; glad to pursue it elsewhere, but felt that a direct response to this wg's chair was appropriate (too). > As I said, this is a different thing than what we have been doing and I will not > be doing so without first consulting with chairs and making sure they can and > will manage the discussion reasonably. As opposed to having chairs who won't? That is, while the tone of what you say sounds entirely reasonable, I suspect it's predicate actually isn't. Or rather, if there is claimed to be an inability to have reasonable list discussion, there's a much, much deeper problem. The problem will need attention, but it isn't really a justification for treating Discusses as different from other input to the wg. > Right. One alternate means for doing this is moderating discussion. We are > generally loathe to do moderated mailing list postings in the IETF unless things I believe IETF working groups are never moderated generically. That is, I believe they never assert control over /all/ messages before being circulated. Some /individuals/ have messages moderated, but not all messages from everyone, to the group. As a consequence, this tool in the arsenal again sounds superficially reasonable but probably isn't. The overriding problem with the model, here, is the assumption that the working group needs to be protected in this specific situation. What's missing is either the track record or the theory to justify this, other than extremely broad, vague and unfounded fears, I believe. > Remember, this is a change in behavior for all of us, so we do have to make > these kinds of changes with open eyes. Transitions need tailoring, yes, but let's be clear about the difference between the transition issues versus to steady-state, long-term issues. >> Further, AD Discusses are now publicly documented. > > Right. But the additional worry I have is that responses to it are *not* > publicly documented (i.e., when chairs or editors reply to the AD for > clarifications, potential resolutions, etc.) unless the AD takes the additional > step to update their comments in the tracker. Isn't it nice how conveniently all of this gets fixed by simply moving the process to the working group mailing list? >> So the step you are objecting to is a matter of convenience, not availability. >> And it streamlines the resolution process by eliminating the information >> gatekeeping by whoever is mediating between the AD and the working group: It >> puts the AD directly in front of the folks whose work is being challenged. > > This is dependent on the AD *and* the WG involved. An AD might bring up an issue > that was clearly resolved by a WG many months (years!) ago. Without a bit of > restraint by the WG, a lot of sturm und drong can be generated if folks don't In other words, unlike for anyone else who re-raises old, settled issues, we need to be especially protective of ADs? Again, the nature of the issue, here, isn't new. Old material being re-raised happens in wgs all the time. All that's different for a Discuss is giving an AD the authority to block things and then also believing the AD needs to be privileged out of directly interacting with the wg about it. The fear that the wg might get upset should not be a fear. It's a certainty that it will happen... sometimes. My response is: yes, that's part of the cost of having an AD fail to do due diligence before blocking a working group. Everyone else who re-raises old stuff suffers that cost, why shouldn't ADs? (If an AD wants to get educated properly before lodging a Discuss, they should do that offline.) > just wait for the chair or cognizant AD to explain, "We are aware of that issue, > discussed it at length in the WG, and resolved it in this way for the following > reasons." And indeed, that's quite reasonable. But again, it's reasonable /all/ the time, not just for ADs. > (This, BTW, can happen whenever anyone outside the WG comes in to > participate without the history, but AD DISCUSS ballots generate a lot more > sturm und drong because of how late they happen in the process and how solidly > they can knot things up.) Why should ADs be protected from it? > So it's a bit more than convenience. It's sometimes > manageability of the WG process. But it's not something that can't be handled. Your premise is that the sturm und drang makes the wg unmanageable. I'll claim that it makes for a more honest process because it makes more clear to the AD that they have overstepped, if they have. Or it makes more clear that the wg has/had a broken process. Either way, it's a more complete and accurate process. >>> The majority of the non-DISCUSS comments are dealt with by such minor editorial >>> changes that opening the discussion up to WG comments will likely inundate the >>> entire IESG unnecessarily >> >> "The entire IESG"? I don't understand how this suddenly puts the entire IESG >> into the main flow of interaction between the AD who is blocking things and >> the wg that is being blocked. > > Because the current model is that all replies to the DISCUSS messages are Cc'ed > directly to the IESG list.And the IESG often does engage in that DISCUSSion. Oh. Well, yeah, that probably needs to change, in some way, since yes the traffic volume on the topic is certain to be higher. Since it certainly seems like a good idea to make it easy for the rest of the IESG to be able to observe the process, while also being good to separate the traffic, I will suggest iesg-discuss-discussion@ietf.org[1] or somesuch as a separate iesg list to which such traffic is sent, in addition to the wg mailing list. That permits iesg fold to separate the traffic and handle it distinctly. >> In any event, a Discuss is expensive for the wg. Why shouldn't it be expensive >> for the ADs lodging them? > > Indeed, and it's expensive for the IESG as a whole. However, while simply > increasing the expense for everyone is one approach, it's probably not ideal. I'm not suggesting it as a goal. But the current model inherently imposes a large burden on the wg and relatively little on the person creating the block. Moving the primary venue to be the wg makes the handling of a discuss the same as handling any other topic -- ADs do not get an exemption -- although the desire to keep the rest of the iesg in the loop does provide a special wrinkle (see above.) > Again, I think having all AD comments (DISCUSS or COMMENT) go to the WG list is > the preferred outcome, but it is a cultural change. I want to do it carefully > and deliberately. +1 d/ [1] I'd have suggested iesg-discuss-discuss, but the IESG already uses the term "discuss-discuss" for something entirely different. -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Mon Jan 23 11:58:04 2012 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 0B83121F86AB for ; Mon, 23 Jan 2012 11:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=0.090, 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 LO77JxNiaQEp for ; Mon, 23 Jan 2012 11:58:03 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 367E221F8619 for ; Mon, 23 Jan 2012 11:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327348682; bh=dfFX5LD8+nUEEQ1ytRbBjoGFXE/WJ2hQMuiuo8wNcKc=; l=1004; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=C9KHdPAyLbNy3wmlTLPeFE0PrxNeCtEFiiWbXHY+YVpDPfBc8dM5+c/CR+U/b97ob r4wQ7ZM//+fDL30UtPcTHdqHLQdJDctBq5/XNd6Yb8JlBIGlAFtKboAKtinugIf5qc YeEpbwzBKDUxp46yutbT11J2PcGStC1vkC+iknqw= 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, 23 Jan 2012 20:58:02 +0100 id 00000000005DC033.000000004F1DBBCA.0000120D Message-ID: <4F1DBBC9.3010908@tana.it> Date: Mon, 23 Jan 2012 20:58:01 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> In-Reply-To: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 19:58:04 -0000 On 23/Jan/12 17:59, internet-drafts@ietf.org wrote: > Filename : draft-ietf-marf-redaction-06.txt > Date : 2012-01-23 I think that approach definitely solves the previous issue. Two points: First, step 4 of Section 2 could be merged with (or moved right after) step 1, as it involves the target set of the transformation and hence is part of it. The example that recalls SMTP requirements for local parts could be moved to Section 3 (BTW, the maximum length of 64 bytes could also be mentioned, so that both truncation and encoding become part of the transformation.) The point is that such choices logically belong to step 1, since they are not based on the output of the transformation of a given piece of private data. Second, Section 3 could mention that some transformations use a secret key and thereby recover the definition of "redaction key". All or some of the Key Management section, as well as the statement on its reasonable length, could then be recovered. jm2c From msk@cloudmark.com Mon Jan 23 12:13:27 2012 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 74E1421F86D1 for ; Mon, 23 Jan 2012 12:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 aHoe9Dd0eqvA for ; Mon, 23 Jan 2012 12:13:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6F321F86CF for ; Mon, 23 Jan 2012 12:13:19 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 12:13:19 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 23 Jan 2012 12:13:19 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 23 Jan 2012 12:13:17 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-redaction-06.txt Thread-Index: AczaCVWaF8Xuq5vZSYymBX7PNhGkLwAADamg Message-ID: References: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> <4F1DBBC9.3010908@tana.it> In-Reply-To: <4F1DBBC9.3010908@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] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 20:13:27 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, January 23, 2012 11:58 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.txt >=20 > First, step 4 of Section 2 could be merged with (or moved right after) > step 1, as it involves the target set of the transformation and hence > is part of it. > > The example that recalls SMTP requirements for local > parts could be moved to Section 3 (BTW, the maximum length of 64 bytes > could also be mentioned, so that both truncation and encoding become > part of the transformation.) The point is that such choices logically > belong to step 1, since they are not based on the output of the > transformation of a given piece of private data. I've already posted -06, unfortunately. I think it's better to just change "contains" to "can contain", and similar= ly "includes" to "can include". The specific rules for different tokens (e= .g., local-parts vs. domain names) might be a little different. For exampl= e, base64 won't work universally on domain names, but base32 would. So the= transformation needs to meet certain requirements, and so does the encodin= g. But those two requirement sets come from different places, so I prefer = the partitioning as we have it. As for the length, I think we should be more general and just say there may= be other constraints that also need to be observed in the replacement. > Second, Section 3 could mention that some transformations use a secret > key and thereby recover the definition of "redaction key". All or some > of the Key Management section, as well as the statement on its > reasonable length, could then be recovered. I don't think we want to get into the mechanics of various methods at all. = To some extent, that's what got us into trouble in the first place, and al= so those issues are very well described and understood in existing document= ation. We don't need to repeat any of that here. Since Stephen hasn't responded to -06 yet, I'll see if it's okay to do a -0= 7 with the above or if we should stick with what we have. -MSK From iesg-secretary@ietf.org Mon Jan 23 12:33:39 2012 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 AD79221F85F6; Mon, 23 Jan 2012 12:33:39 -0800 (PST) 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=[AWL=0.119, 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 M312SsK3DPpz; Mon, 23 Jan 2012 12:33:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED8821F8688; Mon, 23 Jan 2012 12:33:38 -0800 (PST) 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.64p1 Message-ID: <20120123203338.28654.46874.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 12:33:38 -0800 Cc: marf mailing list , marf chair , RFC Editor Subject: [marf] Protocol Action: 'Authentication Failure Reporting using the Abuse Report Format' to Proposed Standard (draft-ietf-marf-authfailure-report-10.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, 23 Jan 2012 20:33:39 -0000 The IESG has approved the following document: - 'Authentication Failure Reporting using the Abuse Report Format' (draft-ietf-marf-authfailure-report-10.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-authfailure-report/ Technical Summary 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. Working Group Summary This memo underwent two Working Group Last Calls because of the amount of last-minute feedback generated during the first. There was no controversy of note. Document Quality There is substantial deployment of ARF, upon which these extensions are based. There is one widely deployed open source implementation of the extension with more under development which will see widespread use. Reviewers and expressions of intent to support included PayPal and Hotmail. Personnel Murray S. Kucherawy is the Document Shepherd Pete Resnick is the Responsible Area Director From barryleiba.mailing.lists@gmail.com Mon Jan 23 12:57:06 2012 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 CF58F21F8526 for ; Mon, 23 Jan 2012 12:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.88 X-Spam-Level: X-Spam-Status: No, score=-103.88 tagged_above=-999 required=5 tests=[AWL=1.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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 YsbAgE6ihK7j for ; Mon, 23 Jan 2012 12:57:05 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1BE21F8523 for ; Mon, 23 Jan 2012 12:57:05 -0800 (PST) Received: by yenm3 with SMTP id m3so1596585yen.31 for ; Mon, 23 Jan 2012 12:57:05 -0800 (PST) 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:cc:content-type :content-transfer-encoding; bh=kQwcantWymXSblmeAqGT2bXnYH+ghcc8nuS9UWUSCXY=; b=b17pQcoX4BfwAlsxlHvDlqTX0plXOW40hUq5zdqAf8UhaYfD3+PekILA/N5iv3a5CP s3/QZg+fHdOTppuv9ZJZtVPuOVSxQQ4ksSdfYa/g7Y6yNGMyvi2KHO3a3SCb5GL97lZY Xz9PwqACgDRxtTTvhF70DQgoZi7p63mujHpVc= MIME-Version: 1.0 Received: by 10.236.173.7 with SMTP id u7mr14402158yhl.7.1327352225193; Mon, 23 Jan 2012 12:57:05 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 23 Jan 2012 12:57:05 -0800 (PST) In-Reply-To: <4F1D9A55.602@qualcomm.com> References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> <4F1D90DE.1030800@bbiw.net> <4F1D9A55.602@qualcomm.com> Date: Mon, 23 Jan 2012 15:57:05 -0500 X-Google-Sender-Auth: HoXR6SMWSo8Fw3ciwXKxxW0Vtig Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dave CROCKER , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS handling (Was: DISCUSS on draft-ietf-marf-redaction-04) 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, 23 Jan 2012 20:57:06 -0000 On Mon, Jan 23, 2012 at 11:58 AM, Dave CROCKER wrote: > =A0 =A0 The premise of the open IETF processes is that open collaboration= means > broad-based review, diverse perspectives and broad-based support for> wha= tever is decided. Which doesn't mean that every word is or needs to be written in real-time on a public WIKI with everyone watching. The editors usually go off and make changes, and the working group reviews those changes. I'm suggesting nothing more nor less here. > =A0 =A0 Closed processes make it more likely that there will be narrower > perspectives -- and therefore some aspect of the issue missed -- and less= > support. It actually makes an AD less accountable for their Discuss. I very much disagree with you. What a side discussion does is allow the editor(s) and the AD(s) to understand each other. I have similarly had side conversations with GenART reviewers, SecDir reviewers, and other working group participants. That those discussions didn't happen on the mailing list didn't compromise the process. It allowed us to work out an understanding, and allowed me, as editor, to propose some text, which the working group could review. > Working group discussion and other reviews are open and collaborative. = =A0All > of the details, major and minor, for handling concerns is public and on t= he> wg mailing list. And you NEVER, in any of your editing in, say, DKIM, went off and discussed things off the list? Every detail, major and minor, was on the list at every moment of its development? > directly to the working group? Why should ADs be immune from the requirem= ent > to take their concerns to the chartered forum that is established for> co= nducting exactly such discussions? No one has said that an AD shouldn't participate in a working-group discussion of the issues she brought up. All I've said is that the chairs, not the ADs, should manage the working group, its process, and its discussions. I've had quite a few DISCUSS comments on my documents, which (the comments) were resolved with one or two email messages, sometimes with no text changes at all (there was something the AD didn't understand). While I have no *objection* to the DISCUSS being posted to the mailing list, as a management point I see no reason to remove the judgment from the chairs' hands of how to handle the conversation. > Further, AD Discusses are now publicly documented. =A0So the step you are > objecting to is a matter of convenience, not availability. Exactly. Nothing hidden at all. > streamlines the resolution process by eliminating the information > gatekeeping by whoever is mediating between the AD and the working group: Nothing is "streamlined" when a minor clarification turns into (perhaps) a large number of messages from the working group copied to the entire IESG. > =A0It puts the AD directly in front of the folks whose work is being> cha= llenged. Ah, here we get to a key point: the assumption that a DISCUSS is adversarial. A DISCUSS does block progress of a document, but it's often NOT a "challenge". It's often simply a request to, well, discuss something briefly. It's also often an administrative mechanism -- as Pete said, a way of tracking something that needs to happen before the document goes to the RFC Editor. The working group can see them any time it wants to look; not all of them need to be explicitly brought to the WG for discussion. > "The entire IESG"? =A0I don't understand how this suddenly puts the entir= e > IESG into the main flow of interaction between the AD who is blocking thi= ngs> and the wg that is being blocked. Pete has answered this: the messages we're talking about are copied to the IESG mailing list. When the WG participants respond, they can remove that CC. We can all guess how often that will happen. > This is a classic error in logic: =A0The current mechanism often works > adequately, so let's ignore the times it doesn't and let's ignore its> in= efficiencies an inequities. Did I ever say anything about ignoring anything? I don't recall that. In fact, I said that when in the chair's judgment the discussion should go to (or at least be copied to) the WG, the chair can and should take it there. We've "hired" the chairs as managers, and they should be left to manage. > My core point is that the /design/ of the current process is inherently > flawed: =A0it violates the IETF's model for handling objections that perv= ades> every other aspect of IETF work. There's no question that the DISCUSS process is flawed. The question is whether automatically copying every DISCUSS and COMMENT to the WG mailing list is the (or "a") right way to fix it. I think it's not. >> In this case, in fact, Murray did bring the discussion to the WG, withou= t >> your needing to force it.> > This places an undue burden on chairs and/or authors. It's an "undue burden" on the chairs to manage their working groups? I can't agree. On Mon, Jan 23, 2012 at 12:35 PM, Pete Resnick wrot= e: > I'll ask for the chairs guidance, and if they want this > moved off somewhere else we can do so. I'm happy to continue this discussion here. I'm also happy if Pete or Dave wants to take it to a more open place, such as ietf@ietf.org. Or, perhaps before that, to wgchairs@ietf.org. > Right. One alternate means for doing this is moderating discussion. We ar= e > generally loathe to do moderated mailing list postings in the IETF unless > things have gotten entirely out of hand in a WG, but we do allow it. When I talk about the chairs moderating the discussion in this sense, I do NOT mean using a moderation queue in the list software. I'm talking about management. This, of course, relies on the WG participants' cooperation, and banning them for being uncooperative is rather extreme. > Right. But the additional worry I have is that responses to it are *not* > publicly documented (i.e., when chairs or editors reply to the AD for > clarifications, potential resolutions, etc.) unless the AD takes the > additional step to update their comments in the tracker. That certainly > needs to change. So, even if it is a moderated discussion, we need to do > something different to document that discussion. This is a key point, which we should deal with in some way. I don't think that putting all of the discussions on the WG mailing list is the right way to handle it. Perhaps having them copied to a discussion archive is the right answer. > This is dependent on the AD *and* the WG involved. An AD might bring up a= n > issue that was clearly resolved by a WG many months (years!) ago. Without= a > bit of restraint by the WG, a lot of sturm und drong can be generated Exactly one example. Scenario 1: DISCUSS message goes to editors and chairs. AD brings up issue X. Editor or shepherd replies, "WG discussed this at length, and closed the is= sue." AD says, "Ah, OK, thanks," and clears. Scenario 2: DISCUSS message goes to WG mailing list. AD brings up issue X. Five angry WG participants, sick to death of issue X, send angry responses, which go to the IESG. Two holdouts, who had prolonged the discussion endlessly before, take this as an invitation to rant about issue X again, sending it to the WG and the IESG. AD gets the message and clears, but lots of time was wasted. Scenario 3: DISCUSS message goes to editors and chairs. AD brings up issue X. Editor or shepherd replies, "WG discussed this at length, and closed the is= sue." AD says, "No, I don't think that's the right answer, and I won't clear." Shepherd posts the discussion to the WG mailing list. I'm sure you can see that I think scenarios 1 and 3 are the way things should work, and 2 is the one I want to avoid. The chairs are the ones most able to judge what will happen, and when it should be posted to the WG list. Barry From barryleiba.mailing.lists@gmail.com Mon Jan 23 13:03:11 2012 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 94B6621F86BD for ; Mon, 23 Jan 2012 13:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.053, 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 8Jb+ILFwaiJj for ; Mon, 23 Jan 2012 13:03:11 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1978621F86BB for ; Mon, 23 Jan 2012 13:03:11 -0800 (PST) Received: by yenm3 with SMTP id m3so1600614yen.31 for ; Mon, 23 Jan 2012 13:03:10 -0800 (PST) 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:cc:content-type; bh=g/Bvw9xejx4RcVY/SwZbB2/edYnheGFp5of9m7zVVis=; b=DMlukv0goDQOFlw1+jl7fysCBuWDZFxrwWgXLTXM24vmeyho/hWEIke3UNffGcGnWZ j4GnRMGOWKfNnkcT/Bsg+EHLRjJBsni7pq2kqV8OjhmSmLIs/UKG7eA6n69dso2a7+zy 90AIqlmGtZjUcsPSQLZDQh/P1/zwYl3z6qwVA= MIME-Version: 1.0 Received: by 10.236.182.232 with SMTP id o68mr4526723yhm.58.1327352590744; Mon, 23 Jan 2012 13:03:10 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 23 Jan 2012 13:03:10 -0800 (PST) In-Reply-To: References: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> <4F1DBBC9.3010908@tana.it> Date: Mon, 23 Jan 2012 16:03:10 -0500 X-Google-Sender-Auth: AqolBvi4_MF0zW8F5L20crl5hws Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 21:03:11 -0000 > Since Stephen hasn't responded to -06 yet, I'll see if it's okay to do a -07 with > the above or if we should stick with what we have. Revs are cheap; there's no reason we shouldn't post another version if consensus is for it. But consensus is not yet for it -- we've only heard from two participants. Others, please comment on this thread now. Barry, chair and shepherd From shmuel+gen@patriot.net Mon Jan 23 13:31:19 2012 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 9A6C321F8712 for ; Mon, 23 Jan 2012 13:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 B78XUZF+yDIm for ; Mon, 23 Jan 2012 13:31:19 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0447F21F8710 for ; Mon, 23 Jan 2012 13:31:18 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.252]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 35C72F58096 for ; Mon, 23 Jan 2012 16:17:10 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 23 Jan 2012 13:53:28 -0500 To: marf@ietf.org In-Reply-To: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> Mail-Copies-To: nobody 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: <20120123211711.35C72F58096@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.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: Mon, 23 Jan 2012 21:31:19 -0000 In <20120123165901.2202.63795.idtracker@ietfa.amsl.com>, on 01/23/2012 at 08:59 AM, internet-drafts@ietf.org said: >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-redaction-06.txt Should some text from 1. Introduction be replicated in the Abstract to keep the IESG happy? -- 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 shmuel+gen@patriot.net Mon Jan 23 13:31:22 2012 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 6C8B921F8718 for ; Mon, 23 Jan 2012 13:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, 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 obD11OT0uWSJ for ; Mon, 23 Jan 2012 13:31:22 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id EE99A21F871C for ; Mon, 23 Jan 2012 13:31:21 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.252]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id B8D01F58096 for ; Mon, 23 Jan 2012 16:17:13 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 23 Jan 2012 13:50:07 -0500 To: Message Abuse Report Format working group Mail-Copies-To: nobody 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: <20120123211714.B8D01F58096@smtp.patriot.net> Subject: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 23 Jan 2012 21:31:22 -0000 I believe that 5. Solicited and Unsolicited Reports should list the abuse address from the whois record of the source IP as a reasonable candidate for receiving feedback. If there is a PTR for that address, would an associated abuse address be a reasonable candidate for receiving feedback? If so, would it only be reasonable for FCrDNS? -- 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 Mon Jan 23 13:38:14 2012 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 77A2121F8616 for ; Mon, 23 Jan 2012 13:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.425 X-Spam-Level: X-Spam-Status: No, score=-109.425 tagged_above=-999 required=5 tests=[AWL=3.174, BAYES_00=-2.599, GB_I_INVITATION=-2, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_21=0.6, 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 a3wlYDi-rgtM for ; Mon, 23 Jan 2012 13:38:14 -0800 (PST) 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 909EE21F85A5 for ; Mon, 23 Jan 2012 13:38:13 -0800 (PST) Received: (qmail 90656 invoked from network); 23 Jan 2012 21:38:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Jan 2012 21:38:11 -0000 Date: 23 Jan 2012 21:37:49 -0000 Message-ID: <20120123213749.53396.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 23 Jan 2012 21:38:14 -0000 Since Scott says he wants to move this forward, here's some comments: In section 3, the r= option lets you specify an arbitrary address, which is an invitation to remote mailbombing. I have my doubts about the utility of inviting reports from random strangers, but if you're going to do it, make it just a local part so you can only mailbomb yourself. The rf= option specifies a report format. The only plausible report format described in an IETF standard is ARF, and it seems unlikely that there will others, so lose this option. If you want to make private arrangements to use non-standard formats, that's fine, but they don't go into the spec. The ri=N option asks senders to discard N/(N+1) of the reports they might generate. It's not clear to me what this is supposed to accomplish. If the goal is to limit the traffic, I'd suggest making it the maximum number of reports to send per minute or per hour. Keep in mind that people sending reports will do whatever they do, so hosts MUST be prepared to deal with whatever garbage reporters send. In 6.2, it correctly notes that an included SPF record might have an r= field, inviting all sorts of mischief. I'd suggest adjusting section 3 to say that the r= ri= and ro= options should be ignored in includes and perhaps in redirect records. I would shrink 6.3 somewhat and just say that the envelope of any report sent to an address found using the process in this document MUST have an envelope that produces an SPF Pass. R's, John From presnick@qualcomm.com Mon Jan 23 13:39:26 2012 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 4EC9321F8625 for ; Mon, 23 Jan 2012 13:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.535 X-Spam-Level: X-Spam-Status: No, score=-107.535 tagged_above=-999 required=5 tests=[AWL=1.063, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 vGbSIVGW75o0 for ; Mon, 23 Jan 2012 13:39:25 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4921F860F for ; Mon, 23 Jan 2012 13:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327354765; x=1358890765; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4F1DD30D.8030808@qualcomm.com>|Date:=20Mo n,=2023=20Jan=202012=2015:37:17=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20Dave=20CROCKER=20, =20Message=20Abuse=20Report=20Format=20working=0D=0A=20gr oup=20|Subject:=20Re:=20[marf]=20DISCUSS =20handling=20(Was:=20DISCUSS=20on=09draft-ietf-marf-reda ction-04)|References:=20=09<4F18ACA8.201030 9@qualcomm.com>=09=09=09=09=09=09<4F1A0049.4040 008@qualcomm.com>=09=09<4F1C4F0D.6090205@qualc omm.com>=20<4F1C5AAC.8030509@dcrocker.net>=09<4F1CA7F8.60 50703@qualcomm.com>=09=09<4F1D90DE.1030800 @bbiw.net>=20<4F1D9A55.602@qualcomm.com>=20 |In-Reply-To:=20|Content-Type:=20multipart/alt ernative=3B=0D=0A=09boundary=3D"------------0400060101090 00103020504"|X-Originating-IP:=20[172.30.48.1]; bh=ECiEiaaqrdw7i0ssPM0QYL9H/6wZCcnOavFI1HiwtGg=; b=c7Tqb3f+noR5FG/ZsIHyVqY70AOeBPSQHKkS/w7AOCngUptCcv3MvS+x Wug/YwA8U1zUMXgNVZha0QAjBsMqwnhaxB77zfldn/ny9fs9RRNWUlrpo svN0EPXnR4x4KTVN8uxDXHPbFITQrViJz59fhvXWelnqiJWsKAODAHxW0 k=; X-IronPort-AV: E=McAfee;i="5400,1158,6598"; a="157351553" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 23 Jan 2012 13:39:24 -0800 X-IronPort-AV: E=Sophos;i="4.71,556,1320652800"; d="scan'208,217";a="190144864" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Jan 2012 13:39:24 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 23 Jan 2012 13:37:24 -0800 Message-ID: <4F1DD30D.8030808@qualcomm.com> Date: Mon, 23 Jan 2012 15:37:17 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> <4F1D90DE.1030800@bbiw.net> <4F1D9A55.602@qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006010109000103020504" X-Originating-IP: [172.30.48.1] Cc: Dave CROCKER , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS handling (Was: DISCUSS on draft-ietf-marf-redaction-04) 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, 23 Jan 2012 21:39:26 -0000 --------------040006010109000103020504 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Skipping down to the end: On 1/23/12 2:57 PM, Barry Leiba wrote: >> This is dependent on the AD*and* the WG involved. An AD might bring up an >> issue that was clearly resolved by a WG many months (years!) ago. Without a >> bit of restraint by the WG, a lot of sturm und drong can be generated >> > Exactly one example. > > Scenario 1: > DISCUSS message goes to editors and chairs. AD brings up issue X. > Editor or shepherd replies, "WG discussed this at length, and closed the issue." > AD says, "Ah, OK, thanks," and clears. > > Scenario 2: > DISCUSS message goes to WG mailing list. AD brings up issue X. > Five angry WG participants, sick to death of issue X, send angry > responses, which go to the IESG. > Two holdouts, who had prolonged the discussion endlessly before, take > this as an invitation to rant about issue X again, sending it to the > WG and the IESG. > AD gets the message and clears, but lots of time was wasted. > > Scenario 3: > DISCUSS message goes to editors and chairs. AD brings up issue X. > Editor or shepherd replies, "WG discussed this at length, and closed the issue." > AD says, "No, I don't think that's the right answer, and I won't clear." > Shepherd posts the discussion to the WG mailing list. > > I'm sure you can see that I think scenarios 1 and 3 are the way things > should work, and 2 is the one I want to avoid. The chairs are the > ones most able to judge what will happen, and when it should be posted > to the WG list. > My contention is that with proper socialization of the WG, scenario 2 becomes, for all intents and purposes, scenario 1 or 3. That is, if the WG is restrained and managed well enough not to jump out of their skin when an AD posts a DISCUSS (or, for that matter, when a non-usual-WG-participant posts a message about a topic that his been decided), the post can go to the list, the chair or editor can say, "We discussed this at length, and closed the issue", the AD can respond in whichever way, and the discussion can continue as necessary. The bonus to scenario 2 + socialization is (a) there is an obvious archive where the discussion has taken place, and (b) the WG gets to see the comments and, if the chair or editor misunderstand the issue, another calm participant can pipe up, "Oh, that smart AD has said something especially insightful that we missed some months ago. I now see that I agree that we haven't solved this problem." And this is why I said I will not be springing this on anybody. We'll do it with a WG and chair that is prepared so we don't get five angry participants who are sick to death instantly committing public ritual suicide on the list. And as Dave said, such restraint should be going on with anyone who re-raises an old issue (chairs should take the lead on such folks, ADs or otherwise, and explain history, and others should be patient until that happens), and as Dave also said, we should expect that sometimes humans will be humans and a participant will get publicly obnoxious (toward an AD or other person) and we'll deal with that accordingly. The end goal is for ADs to be able post all of their comments to the WG list and for issues to get resolved appropriately without unwarranted fanfare. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 --------------040006010109000103020504 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Skipping down to the end:

On 1/23/12 2:57 PM, Barry Leiba wrote: 
This is dependent on the AD *and* the WG involved. An AD might bring up an
issue that was clearly resolved by a WG many months (years!) ago. Without a
bit of restraint by the WG, a lot of sturm und drong can be generated
    
Exactly one example.

Scenario 1:
DISCUSS message goes to editors and chairs.  AD brings up issue X.
Editor or shepherd replies, "WG discussed this at length, and closed the issue."
AD says, "Ah, OK, thanks," and clears.

Scenario 2:
DISCUSS message goes to WG mailing list.  AD brings up issue X.
Five angry WG participants, sick to death of issue X, send angry
responses, which go to the IESG.
Two holdouts, who had prolonged the discussion endlessly before, take
this as an invitation to rant about issue X again, sending it to the
WG and the IESG.
AD gets the message and clears, but lots of time was wasted.

Scenario 3:
DISCUSS message goes to editors and chairs.  AD brings up issue X.
Editor or shepherd replies, "WG discussed this at length, and closed the issue."
AD says, "No, I don't think that's the right answer, and I won't clear."
Shepherd posts the discussion to the WG mailing list.

I'm sure you can see that I think scenarios 1 and 3 are the way things
should work, and 2 is the one I want to avoid.  The chairs are the
ones most able to judge what will happen, and when it should be posted
to the WG list.

My contention is that with proper socialization of the WG, scenario 2 becomes, for all intents and purposes, scenario 1 or 3. That is, if the WG is restrained and managed well enough not to jump out of their skin when an AD posts a DISCUSS (or, for that matter, when a non-usual-WG-participant posts a message about a topic that his been decided), the post can go to the list, the chair or editor can say, "We discussed this at length, and closed the issue", the AD can respond in whichever way, and the discussion can continue as necessary. The bonus to scenario 2 + socialization is (a) there is an obvious archive where the discussion has taken place, and (b) the WG gets to see the comments and, if the chair or editor misunderstand the issue, another calm participant can pipe up, "Oh, that smart AD has said something especially insightful that we missed some months ago. I now see that I agree that we haven't solved this problem."

And this is why I said I will not be springing this on anybody. We'll do it with a WG and chair that is prepared so we don't get five angry participants who are sick to death instantly committing public ritual suicide on the list. And as Dave said, such restraint should be going on with anyone who re-raises an old issue (chairs should take the lead on such folks, ADs or otherwise, and explain history, and others should be patient until that happens), and as Dave also said, we should expect that sometimes humans will be humans and a participant will get publicly obnoxious (toward an AD or other person) and we'll deal with that accordingly.

The end goal is for ADs to be able post all of their comments to the WG list and for issues to get resolved appropriately without unwarranted fanfare.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
--------------040006010109000103020504-- From msk@cloudmark.com Mon Jan 23 14:18:40 2012 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 C2AEA21F865F for ; Mon, 23 Jan 2012 14:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 RN2PBFu6dz+O for ; Mon, 23 Jan 2012 14:18:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1021F85F6 for ; Mon, 23 Jan 2012 14:18:39 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 14:18:39 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 23 Jan 2012 14:18:39 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 14:18:38 -0800 Thread-Topic: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports Thread-Index: AczaFlxFwzqPmLT3RdCbK+erwwFyqwABjOjg Message-ID: References: <20120123211714.B8D01F58096@smtp.patriot.net> In-Reply-To: <20120123211714.B8D01F58096@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-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 23 Jan 2012 22:18:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, January 23, 2012 10:50 AM > To: Message Abuse Report Format working group > Subject: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Re= ports >=20 > I believe that 5. Solicited and Unsolicited Reports should list the > abuse address from the whois record of the source IP as a reasonable > candidate for receiving feedback. I have some concerns about doing this, since the reply from a WHOIS query i= s non-standard. Do we really want to say "apply some unspecified heuristic= to the WHOIS reply to get that address"? > If there is a PTR for that address, would an associated abuse address > be a reasonable candidate for receiving feedback? If so, would it only > be reasonable for FCrDNS? I don't think so. I don't think we want to start encouraging people to try= to find any domain to which to prepend "abuse@" to start sending reports. = DKIM is the exception, because a valid DKIM signature makes a strong state= ment the likes of "Yes, we handled this message." A PTR record, for exampl= e, does not. -MSK From steve@wordtothewise.com Mon Jan 23 14:45:09 2012 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 E5AE321F8605 for ; Mon, 23 Jan 2012 14:45:09 -0800 (PST) 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 SVhvLZognF9N for ; Mon, 23 Jan 2012 14:45:09 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0121F8604 for ; Mon, 23 Jan 2012 14:45:09 -0800 (PST) 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 1CD002DDE4 for ; Mon, 23 Jan 2012 14:45:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Mon, 23 Jan 2012 14:45:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <51406361-AA9B-4DD0-B99E-51B0D6FA1335@wordtothewise.com> References: <20120123211714.B8D01F58096@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 23 Jan 2012 22:45:10 -0000 On Jan 23, 2012, at 2:18 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Shmuel Metz >> Sent: Monday, January 23, 2012 10:50 AM >> To: Message Abuse Report Format working group >> Subject: [marf] draft-ietf-marf-as Section 5 Solicited and = Unsolicited Reports >>=20 >> I believe that 5. Solicited and Unsolicited Reports should list the >> abuse address from the whois record of the source IP as a reasonable >> candidate for receiving feedback. >=20 > I have some concerns about doing this, since the reply from a WHOIS = query is non-standard. Do we really want to say "apply some unspecified = heuristic to the WHOIS reply to get that address"? It's all heuristics. However, ARIN and RIPE at least have some structure = in their responses, including explicitly recorded abuse contacts. When = they exist (which they usually do) that does give you an IP address to = abuse address mapping - and while the contact is often too far up the = delegation tree to be the right contact, it's seldom an actively bad = contact: OrgAbuseHandle: ABUSE1036-ARIN OrgAbuseName: Abuse Department OrgAbusePhone: +1-510-580-4100 OrgAbuseEmail: abuse@he.net OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN >=20 >> If there is a PTR for that address, would an associated abuse address >> be a reasonable candidate for receiving feedback? If so, would it = only >> be reasonable for FCrDNS? >=20 > I don't think so. I don't think we want to start encouraging people = to try to find any domain to which to prepend "abuse@" to start sending = reports. DKIM is the exception, because a valid DKIM signature makes a = strong statement the likes of "Yes, we handled this message." A PTR = record, for example, does not. DKIM states that the owner of the d=3D hostname signed[1] the message. = That could mean anything between them being the spammer, to them being = the ISP of a end user with a compromised box. Whether that's an = appropriate entity to contact requires applying some heuristics, and = mapping that d=3D value to an appropriate email address requires some = more. In the case where an ESP is signing the mail sent by their customers = with a d=3D value inside the customers domain then there may not be an = abuse@X address for any given d=3DX or d=3DY.X, and even when there is = it's unlikely to be the right address to contact for abuse issues. = Simple heuristics based on ARIN or RIPE registry data are likely to be = much more accurate in that case. Cheers, Steve [1] Or delegated signing responsibility to, or...= From sklist@kitterman.com Mon Jan 23 14:51:45 2012 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 2FA4321F8661 for ; Mon, 23 Jan 2012 14:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_21=0.6] 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 qqT2GkWltJFs for ; Mon, 23 Jan 2012 14:51:44 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8A21F8649 for ; Mon, 23 Jan 2012 14:51:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 859D420E40DA; Mon, 23 Jan 2012 17:51:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327359103; bh=YHFQ0pdaaOd0Ja7p01ENN9e7MbbB/1UVxS0rznH15Pc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=NaFtCkb/POH35wS2i8s42ToLqpPr6EP/p9CNaHlTWLsC2znKy1uGELpaF95TR2RwD QnimL0QGAChXgUE6FxvFzjZL7KkjQT1xBVcKVhTggjROPLuI4ZFcHKf+c4bMQH4JFa ZRt+ZV8qp7ynK1fFT2Sh9u+ZYIh1LE78aeKSVq+g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6A58420E408E; Mon, 23 Jan 2012 17:51:43 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 23 Jan 2012 17:51:42 -0500 Message-ID: <1891722.Q3cj42kd9u@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120123213749.53396.qmail@joyce.lan> References: <20120123213749.53396.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-spf-reporting-02 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, 23 Jan 2012 22:51:45 -0000 On Monday, January 23, 2012 09:37:49 PM John Levine wrote: > Since Scott says he wants to move this forward, here's some comments: > > In section 3, the r= option lets you specify an arbitrary address, > which is an invitation to remote mailbombing. I have my doubts about > the utility of inviting reports from random strangers, but if you're > going to do it, make it just a local part so you can only mailbomb > yourself. I agree. I'd like to change this in -03. > The rf= option specifies a report format. The only plausible report > format described in an IETF standard is ARF, and it seems unlikely > that there will others, so lose this option. If you want to make > private arrangements to use non-standard formats, that's fine, but > they don't go into the spec. I'm fine with this. Since this is going into an IANA registry, the same RFC that defines the report type can define this. > The ri=N option asks senders to discard N/(N+1) of the reports they > might generate. It's not clear to me what this is supposed to > accomplish. If the goal is to limit the traffic, I'd suggest making > it the maximum number of reports to send per minute or per hour. Keep > in mind that people sending reports will do whatever they do, so hosts > MUST be prepared to deal with whatever garbage reporters send. Here I disagree. Assuming senders implement this as specified (and yes, I know they all won't) I think some kind of a global fractional rate is better than a per sender volume. In applications where I've seen similar things done in private arrangements, the goal is to get a statistically valid sample of data without putting excessing strain on sending or receiving systems. If you specify X per hour or Y perm minute then low volume senders will send at their normal rate while high volume senders throttle back. This skews the sample data. I find the current method a bit confusing to follow in English, but it would be easy enough to implement in code (I inherited it from the document split out). Describing the rate as a percentage of volume might be a little more understandable. I could see doing either. > In 6.2, it correctly notes that an included SPF record might have an > r= field, inviting all sorts of mischief. I'd suggest adjusting > section 3 to say that the r= ri= and ro= options should be ignored in > includes and perhaps in redirect records. I agree for include: as it's intended to cross administrative boundaries. Redirect is intended to be used within a single administrative structure and the target domain is the same as for the initial record (this is described in paragraph 6.1 of RFC 4408), so I think for redirect it is OK to process them. > I would shrink 6.3 somewhat and just say that the envelope of any > report sent to an address found using the process in this document > MUST have an envelope that produces an SPF Pass. You think that's better than <> for Mail From and HELO/EHLO that Pass? What about the rest of the text? Just ditch it? I'm not sure I'm following you here, so I'd appreciate it if you would amplify (with a proposed 6.3 text). Thanks for the review, Scott K From msk@cloudmark.com Mon Jan 23 15:11:25 2012 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 A792621F855D for ; Mon, 23 Jan 2012 15:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 WiHgMLHXCCzp for ; Mon, 23 Jan 2012 15:11:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C46A921F8557 for ; Mon, 23 Jan 2012 15:11:24 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 15:11:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 15:11:24 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 15:11:23 -0800 Thread-Topic: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports Thread-Index: AczaIK4QKrnshKxQSbyGN/Vym/4FagAAH9ZQ Message-ID: References: <20120123211714.B8D01F58096@smtp.patriot.net> <51406361-AA9B-4DD0-B99E-51B0D6FA1335@wordtothewise.com> In-Reply-To: <51406361-AA9B-4DD0-B99E-51B0D6FA1335@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-as Section 5 Solicited and Unsolicited Reports 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, 23 Jan 2012 23:11:25 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Monday, January 23, 2012 2:45 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicite= d Reports >=20 > It's all heuristics. However, ARIN and RIPE at least have some > structure in their responses, including explicitly recorded abuse > contacts. When they exist (which they usually do) that does give you an > IP address to abuse address mapping - and while the contact is often > too far up the delegation tree to be the right contact, it's seldom an > actively bad contact: >=20 > OrgAbuseHandle: ABUSE1036-ARIN > OrgAbuseName: Abuse Department > OrgAbusePhone: +1-510-580-4100 > OrgAbuseEmail: abuse@he.net > OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE1036-ARIN As long as there's some place we can point people to read a document that d= efines the syntax they use, I'm less apprehensive about doing so. Otherwis= e, saying "extract an abuse reporting address from this blob somehow" feels= too heuristic to be in a standards document, IMO. > >> If there is a PTR for that address, would an associated abuse address > >> be a reasonable candidate for receiving feedback? If so, would it > >> only be reasonable for FCrDNS? > > > > I don't think so. I don't think we want to start encouraging people > > to try to find any domain to which to prepend "abuse@" to start sending > > reports. DKIM is the exception, because a valid DKIM signature makes a > > strong statement the likes of "Yes, we handled this message." A PTR > > record, for example, does not. >=20 > DKIM states that the owner of the d=3D hostname signed[1] the message. > That could mean anything between them being the spammer, to them being > the ISP of a end user with a compromised box. Whether that's an > appropriate entity to contact requires applying some heuristics, and > mapping that d=3D value to an appropriate email address requires some > more. True, but DKIM makes a stronger statement than any other identifier extract= ed directly from the message. That's why I hold it, and maybe a domain ver= ified by SPF, as tolerable exceptions. Basically, I can't think of a case where it's actually inappropriate to try= , though it certainly could be the case that it's pointless to try. -MSK From sm@resistor.net Mon Jan 23 15:40:44 2012 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 4CB5C21F867B for ; Mon, 23 Jan 2012 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 5m18sCMWVETC for ; Mon, 23 Jan 2012 15:40:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23A21F8681 for ; Mon, 23 Jan 2012 15:40:41 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0NNeZtN017725 for ; Mon, 23 Jan 2012 15:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327362040; i=@resistor.net; bh=btW/gs8TWC8M1x7XYGjE3RQmFojE5LXy7x4/kY8yAcg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NY13PMaC3Yb2+rGXYXz9bb58YhQv6/pYQ7yUJEvDhbu5nZsaNDLAbKT4lXocttU1i HvnRndeYMM1syyn22TnIjmoIZDFGKXSIPrboPqV9zQSHD2ENLLERL55zfiypH1iRmR tGIL7eiIlfakqvzWn5nnt0nvZ0DydkSLaPfI+wOg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327362040; i=@resistor.net; bh=btW/gs8TWC8M1x7XYGjE3RQmFojE5LXy7x4/kY8yAcg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=LnpvXi1/w1aKVql5yJAl2Tf+AAwPLM0uDUYddk4nqCF3gWYl8HePGRRuij7zDMrsf vPp4nS8Z1K3eVtxmwaGl8ZYKwVch50L+ms5JIxmiq3hp66LQNEsSogYS3192u3K9zW J/kbZ43TYhZlZgrx+bxvxTeQoobSeDm7jv/jGhdk= Message-Id: <6.2.5.6.2.20120123153415.09c2b0b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2012 15:39:57 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20120123165901.2202.63795.idtracker@ietfa.amsl.com> <4F1DBBC9.3010908@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 23:40:44 -0000 At 12:13 23-01-2012, Murray S. Kucherawy wrote: >I think it's better to just change "contains" to "can contain", and >similarly "includes" to "can include". The specific rules for >different tokens (e.g., local-parts vs. domain names) might be a >little different. For example, base64 won't work universally on >domain names, but base32 would. So the transformation needs to meet >certain requirements, and so does the encoding. But those two >requirement sets come from different places, so I prefer the >partitioning as we have it. > >As for the length, I think we should be more general and just say >there may be other constraints that also need to be observed in the >replacement. That sounds fine. >I don't think we want to get into the mechanics of various methods >at all. To some extent, that's what got us into trouble in the >first place, and also those issues are very well described and >understood in existing documentation. We don't need to repeat any >of that here. +1 Regards, -sm From johnl@iecc.com Mon Jan 23 15:53:15 2012 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 BACDF21F8693 for ; Mon, 23 Jan 2012 15:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.798 X-Spam-Level: X-Spam-Status: No, score=-108.798 tagged_above=-999 required=5 tests=[AWL=2.401, 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 VMEQRLKMCAub for ; Mon, 23 Jan 2012 15:53:15 -0800 (PST) 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 1954E21F85EE for ; Mon, 23 Jan 2012 15:53:14 -0800 (PST) Received: (qmail 63551 invoked from network); 23 Jan 2012 23:53:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Jan 2012 23:53:13 -0000 Date: 23 Jan 2012 23:52:50 -0000 Message-ID: <20120123235250.58096.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] I-D Action: draft-ietf-marf-redaction-06.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, 23 Jan 2012 23:53:15 -0000 >I think it's better to just change "contains" to "can contain", and similarly >"includes" to "can include". The specific rules for different tokens (e.g., >local-parts vs. domain names) might be a little different. For example, base64 >won't work universally on domain names, but base32 would. So the transformation >needs to meet certain requirements, and so does the encoding. But those two >requirement sets come from different places, so I prefer the partitioning as we >have it. > >As for the length, I think we should be more general and just say there may be >other constraints that also need to be observed in the replacement. Sure. While you're at it there's a typo, date -> data. >> Second, Section 3 could mention that some transformations use a secret >> key and thereby recover the definition of "redaction key". All or some >> of the Key Management section, as well as the statement on its >> reasonable length, could then be recovered. > >I don't think we want to get into the mechanics of various methods at all. Please let that sleeping dog lie. R's, John From msk@cloudmark.com Mon Jan 23 16:35:39 2012 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 40B3021F8605 for ; Mon, 23 Jan 2012 16:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=1.013, 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 umSjRxW80m33 for ; Mon, 23 Jan 2012 16:35:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D0AD121F8604 for ; Mon, 23 Jan 2012 16:35:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 16:35:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 16:35:38 -0800 From: "Murray S. Kucherawy" To: ARF mailing list Date: Mon, 23 Jan 2012 16:35:37 -0800 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting feedback Thread-Index: AcyBHDWp6YCfwClIQGePMxELXY1ApBZE2vfA 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: Tue, 24 Jan 2012 00:35:39 -0000 I'm going back through this thread to try once more to get WG momentum on d= oing this work. If it fails, I'll look into taking it back to an individua= l submission and/or lowering it to "Experimental" status. Accordingly, I'm= brewing up a new version now. > -----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 >=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 already know each other, they can use private agreements > with no need to standardize anything. Actually, I think even private agreements to do this sort of work can benef= it from a standardized approach, because then software can be shipped with = the support in there, activated by the flip of a switch. In light of this.= .. > 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. ...I've added some text to Security Considerations that says if you want to= do this, you shouldn't do it automatically; rather, only actually pay atte= ntion to "r=3D" if "d=3D" matches a domain for which you've agreed to do re= porting. That should solve the mailbomb problem except for domains that wa= nt that kind of forensic information anyway. -MSK From johnl@iecc.com Mon Jan 23 16:42:54 2012 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 67EF621F8605 for ; Mon, 23 Jan 2012 16:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.553 X-Spam-Level: X-Spam-Status: No, score=-108.553 tagged_above=-999 required=5 tests=[AWL=2.046, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_21=0.6, 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 ZoGCPkkdTDxa for ; Mon, 23 Jan 2012 16:42:54 -0800 (PST) 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 D0BCD21F860E for ; Mon, 23 Jan 2012 16:42:53 -0800 (PST) Received: (qmail 87920 invoked from network); 24 Jan 2012 00:42:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 00:42:51 -0000 Date: 24 Jan 2012 00:42:29 -0000 Message-ID: <20120124004229.59773.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <1891722.Q3cj42kd9u@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-spf-reporting-02 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, 24 Jan 2012 00:42:54 -0000 >> The ri=N option asks senders to discard N/(N+1) of the reports they >> might generate. It's not clear to me what this is supposed to >> accomplish. >Here I disagree. Assuming senders implement this as specified (and yes, I know >they all won't) I think some kind of a global fractional rate is better than a >per sender volume. In applications where I've seen similar things done in >private arrangements, the goal is to get a statistically valid sample of data >without putting excessing strain on sending or receiving systems. If the goal is to get a sample rather than to rate limit, it makes sense. Please say that so you don't get the same complaint the next time someone looks at it. A percentage would be easier to explain and no harder to implement. >the target domain is the same as for the initial record (this is described in >paragraph 6.1 of RFC 4408), so I think for redirect it is OK to process them. Don't feel strongly either way. >> I would shrink 6.3 somewhat and just say that the envelope of any >> report sent to an address found using the process in this document >> MUST have an envelope that produces an SPF Pass. > >You think that's better than <> for Mail From and HELO/EHLO that Pass? What >about the rest of the text? Just ditch it? I'm not sure I'm following you >here, so I'd appreciate it if you would amplify (with a proposed 6.3 text). You say to use a null bounce address and a HELO with a domain that produces an SPF Pass. I say use whatever bounce address you want, but be sure that it produces an SPF Pass. I don't see any practical advantage to requiring a null bounce address. If it's not null, and the r= address doesn't work, the reporter might get the report bounced back, but if I were a reporter I'd prefer to know if my reports were going into the void so I could stop sending them. R's, John From msk@cloudmark.com Mon Jan 23 16:45:32 2012 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 8630321F8608 for ; Mon, 23 Jan 2012 16:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, 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 gPnt9Jezticq for ; Mon, 23 Jan 2012 16:45:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D908321F8605 for ; Mon, 23 Jan 2012 16:45:31 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 16:45:31 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 16:45:31 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 16:45:30 -0800 Thread-Topic: [marf] draft-ietf-marf-dkim-reporting feedback Thread-Index: Acx/pen7WTucZqtBSWeaRHTBXT38hhailQEQ 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: Tue, 24 Jan 2012 00:45:32 -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. My motivation is actually not bulk senders in particular. It's implementer= s that are trying to get their implementations to interoperate, and trying = to figure out why they don't. To be specific, this sort of thing was parti= cularly valuable when DKIM was young and one operator had installed some so= ftware but couldn't figure out why signatures were failing. Where the veri= fier doesn't have the knowledge or tools to track down the problem, the sig= ner has a way to request the forensic information needed via this mechanism= . > 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", 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? It's agnostic to the path. What it's able to give is "This message was cha= nged since delivery. Here's what we saw on receipt." And where a DKIM "z= =3D" tag is used, it's possible to show what part of the header changed wit= hout having to keep all sent headers around for a while. > 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. What's the specific objection to such overloading? > 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. Fixed. > 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. I've changed it to that syntax. (You and John concur on this point.) > 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). I've changed it to be a tag in the signature, rather than registering a who= le new header field. > It could also be handled via a separate DNS lookup, rather than > overloading the existing DKIM key record. Extra DNS traffic is exactly what I'm trying to avoid here. John suggested= putting it in the signature, which is even better; the previous design alw= ays went to the DNS even for messages that don't need it (because signature= didn't match the hash), but now the rules for going to DNS are tighter. > 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?). The work has been extended to support SPF through the spf-reporting draft a= nd corresponding changes to the authfailure-report draft. -MSK From msk@cloudmark.com Mon Jan 23 16:55:50 2012 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 36A8321F862F for ; Mon, 23 Jan 2012 16:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=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 AO71eP5iaxdj for ; Mon, 23 Jan 2012 16:55:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6321F852A for ; Mon, 23 Jan 2012 16:55:49 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 16:55:49 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 16:55:49 -0800 From: "Murray S. Kucherawy" To: Frank Ellermann Date: Mon, 23 Jan 2012 16:55:48 -0800 Thread-Topic: [marf] DKIM reporting Thread-Index: Acy1SNrRnIp7nkCLQ1iflemt2a2ccAk6QeMA 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 Cc: "marf@ietf.org" Subject: Re: [marf] DKIM reporting 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, 24 Jan 2012 00:55:50 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, December 07, 2011 5:29 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] DKIM reporting >=20 > Some quick observations: s/4871/6376/, s/sender/signer/ (or whatever > is state of the art in DKIM terminology), and maybe say "alleged > author" if that is the correct ADSP term. Fixed (though there were only a few). > It was straight forward to > find _where_ the marf-reporting-discovery will find its TXT, for marf- > dkim-reporting it took me some time to check RFCs 6376 + 5617. I think > (could be wrong) that I understand the ADSP part, but I'm less sure > about the DKIM part. Hopefully the DKIM part is simpler, since it doesn't involve DNS at all any= more. It's all now signature tags. > For ri=3D1 (non-zero) how long are receivers expected to wait for another > incident? If you want ri=3D9, and I get only 8 broken signatures within > a day, does this mean that you want no report because 8 is less than 9? The syntax of this has changed now to specify a count and an interval. The= thrust is for "X/Y" you specify you want no more than X reports in Y secon= ds. As long as sending another report now would not exceed that limit, sen= d away. > Or do you want no second report before I got 2*9 broken signatures, no > matter how long it takes? It is not clear for me why receivers would > ever wish to follow detailed instructions about their reports, even > including MUSTs and MUST NOTs in section 5. The point there is to give guidance on what to do if you're given a request= for a "foobar" report when you don't know what that is, just like in DKIM = we told people to ignore signature tags they don't know about. You're righ= t about the MUST NOT though. > For ADSP ro=3Du I'm not sure what it is, is this simply "all minus ro=3Ds= "? > Should the ADSP ro=3Du explanation (5.2) say "and" instead of "but"? Yes, fixed. > The rf=3Dsmtp + rs=3D... magic is apparently something in the direction o= f > the SPF exp=3D magic. Or maybe not, please add more than one example for > rf=3Dsmtp + rs=3D... tricks (or a pointer if this is explained elsewhere.= ) "rf" has been removed. > For ADSP + DKIM the marf-reporting stuff should fit into the relevant > TXT records, for SPF I'm not sure. If you (=3D the WG) intend to create > a general _report discovery mechanism it would be confusing to create > additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I > have no idea or opinion what's better (specific vs. general _report). Scott's handling the SPF stuff now, so I'll leave it to him to comment ther= e. -MSK From sklist@kitterman.com Mon Jan 23 17:07:01 2012 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 38EC021F84AF for ; Mon, 23 Jan 2012 17:07:01 -0800 (PST) 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 CJ8XG0wRRPEd for ; Mon, 23 Jan 2012 17:07:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE021F848F for ; Mon, 23 Jan 2012 17:07:00 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B4B47D04088; Mon, 23 Jan 2012 19:06:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327367219; bh=0b6zNoTtz+5Pijl7eQHaVO10ZC/rWGXyP80TUBjKJwE=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=lKy+2613eBOWL1WUDxu5MstgRyLoC8bF87Hk5qLt5l9i8HKd0gS8sfre1Ju5rKSvW 4JiW5nL1dFKdsJ3JMjXS5YxDu5p5lKPzXa8K9STS0voWSP1xSr4AHdICSSL+iylzge yd1DzZpaU5X0BHw2ViQ5SqthHV6KAYGuLhi2PvVM= Received: from 27.sub-97-252-9.myvzw.com (27.sub-97-252-9.myvzw.com [97.252.9.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB017D04025; Mon, 23 Jan 2012 19:06:58 -0600 (CST) References: <20120124004229.59773.qmail@joyce.lan> User-Agent: K-9 Mail for Android In-Reply-To: <20120124004229.59773.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 23 Jan 2012 20:07:07 -0500 To: marf@ietf.org Message-ID: <2737efea-c7e4-4d39-abe7-de26ba7ddc19@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 24 Jan 2012 01:07:01 -0000 John Levine wrote: ... >>> I would shrink 6.3 somewhat and just say that the envelope of any >>> report sent to an address found using the process in this document >>> MUST have an envelope that produces an SPF Pass. >> >>You think that's better than <> for Mail From and HELO/EHLO that Pass? > What >>about the rest of the text? Just ditch it? I'm not sure I'm >following you >>here, so I'd appreciate it if you would amplify (with a proposed 6.3 >text). > >You say to use a null bounce address and a HELO with a domain that >produces an SPF Pass. I say use whatever bounce address you want, but >be sure that it produces an SPF Pass. I don't see any practical >advantage to requiring a null bounce address. If it's not null, and >the r= address doesn't work, the reporter might get the report bounced >back, but if I were a reporter I'd prefer to know if my reports were >going into the void so I could stop sending them. The advantage of null mail from is no bounce loops. How would you feel about SHOULD use null mail from (with EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From, if not null, MUST pass SPF? Scott K From johnl@iecc.com Mon Jan 23 17:21:20 2012 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 4448221F861F for ; Mon, 23 Jan 2012 17:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.899 X-Spam-Level: X-Spam-Status: No, score=-108.899 tagged_above=-999 required=5 tests=[AWL=2.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 l5TBtEo97h-t for ; Mon, 23 Jan 2012 17:21:19 -0800 (PST) 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 4D8CB21F8615 for ; Mon, 23 Jan 2012 17:21:19 -0800 (PST) Received: (qmail 8353 invoked from network); 24 Jan 2012 01:21:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 01:21:18 -0000 Date: 23 Jan 2012 23:54:56 +0000 Message-ID: <20120123235456.61150.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Organization: Taughannock Networks, Trumansburg NY Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 24 Jan 2012 01:21:20 -0000 >I believe that 5. Solicited and Unsolicited Reports should list the >abuse address from the whois record of the source IP as a reasonable >candidate for receiving feedback. > >If there is a PTR for that address, would an associated abuse address >be a reasonable candidate for receiving feedback? If so, would it only >be reasonable for FCrDNS? Those are not unreasonable heuristics, but I think this is too far down in the weeds for an AS. Remember that standards are about what you have to do to interoperate, and the main interoperation advice here is to send mail to addresses that can do something useful with the reports. R's, John From johnl@iecc.com Mon Jan 23 17:26:25 2012 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 A109E21F8622 for ; Mon, 23 Jan 2012 17:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.949 X-Spam-Level: X-Spam-Status: No, score=-108.949 tagged_above=-999 required=5 tests=[AWL=2.250, 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 Xz+7dDx0qYR9 for ; Mon, 23 Jan 2012 17:26:25 -0800 (PST) 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 0FE4921F861F for ; Mon, 23 Jan 2012 17:26:24 -0800 (PST) Received: (qmail 11148 invoked from network); 24 Jan 2012 01:26:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 01:26:24 -0000 Date: 24 Jan 2012 01:26:02 -0000 Message-ID: <20120124012602.61337.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <2737efea-c7e4-4d39-abe7-de26ba7ddc19@email.android.com> 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-spf-reporting-02 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, 24 Jan 2012 01:26:25 -0000 >>You say to use a null bounce address and a HELO with a domain that >>produces an SPF Pass. I say use whatever bounce address you want, but >>be sure that it produces an SPF Pass. I don't see any practical >>advantage to requiring a null bounce address. If it's not null, and >>the r= address doesn't work, the reporter might get the report bounced >>back, but if I were a reporter I'd prefer to know if my reports were >>going into the void so I could stop sending them. > >The advantage of null mail from is no bounce loops. Right, and the disadvantage is no feedback if it's bouncing. >How would you feel about SHOULD use null mail from (with EHLO/HELO SPF pass), but >MUST avoid mail loops and Mail From, if not null, MUST pass SPF? Make it MAY use null bounce address and we have a deal. And whether or not it's null, it MUST pass SPF. R's, John From dotis@mail-abuse.org Mon Jan 23 17:47:55 2012 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 0D0C321F853A for ; Mon, 23 Jan 2012 17:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 KqO3nl7bHLKg for ; Mon, 23 Jan 2012 17:47:54 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7521621F8531 for ; Mon, 23 Jan 2012 17:47:54 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 6C66A17403F2 for ; Tue, 24 Jan 2012 01:47:53 +0000 (UTC) Message-ID: <4F1E0DC9.3030909@mail-abuse.org> Date: Mon, 23 Jan 2012 17:47:53 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120124012602.61337.qmail@joyce.lan> In-Reply-To: <20120124012602.61337.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 24 Jan 2012 01:47:55 -0000 On 1/23/12 5:26 PM, John Levine wrote: >>> You say to use a null bounce address and a HELO with a domain that >>> produces an SPF Pass. I say use whatever bounce address you want, but >>> be sure that it produces an SPF Pass. I don't see any practical >>> advantage to requiring a null bounce address. If it's not null, and >>> the r= address doesn't work, the reporter might get the report bounced >>> back, but if I were a reporter I'd prefer to know if my reports were >>> going into the void so I could stop sending them. >> The advantage of null mail from is no bounce loops. > Right, and the disadvantage is no feedback if it's bouncing. > >> How would you feel about SHOULD use null mail from (with EHLO/HELO SPF pass), but >> MUST avoid mail loops and Mail From, if not null, MUST pass SPF? > Make it MAY use null bounce address and we have a deal. And whether > or not it's null, it MUST pass SPF. Dear John, It would be a bad practice to require a protocol that defeats DNS/API caching by incorporating local-part macros that are of no value. Macros able to target a domain with a significant number of recipient generated transactions per message where the victim may not be evident within any referenced record or message. Is MUST not use local-part macros an ingredient of this mustard? Regards, Douglas Otis From sklist@kitterman.com Mon Jan 23 19:22:19 2012 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 37D6121F848F for ; Mon, 23 Jan 2012 19:22:19 -0800 (PST) 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 fUphGrK5wThD for ; Mon, 23 Jan 2012 19:22:18 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 86FCF21F848A for ; Mon, 23 Jan 2012 19:22:18 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 5DACCD04088; Mon, 23 Jan 2012 21:22:17 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327375337; bh=p1um8xCkCc/GuIkFdkgm/mQbVATnWud3wTSmqdRDghA=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=N3Mh+c82qq89ikrenvJIsqa6iTl8ulqL13zNle5Udw5nazXKka1VWR+6p1KAIS3Au S+Vce3HiPutsLRoRtNOfVd3MWFFSwxWydOv5kIHazFT+dhr0sfayqKyFTGlPq9gaHF IhYop0ClcHkm+ikKGh1F936ZpmfZL5XOg1s0YQxc= 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 D652ED0401E; Mon, 23 Jan 2012 21:22:16 -0600 (CST) References: <20120124012602.61337.qmail@joyce.lan> <4F1E0DC9.3030909@mail-abuse.org> User-Agent: K-9 Mail for Android In-Reply-To: <4F1E0DC9.3030909@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 23 Jan 2012 22:22:26 -0500 To: Douglas Otis ,marf@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 24 Jan 2012 03:22:19 -0000 Douglas Otis wrote: >On 1/23/12 5:26 PM, John Levine wrote: >>>> You say to use a null bounce address and a HELO with a domain that >>>> produces an SPF Pass. I say use whatever bounce address you want, >but >>>> be sure that it produces an SPF Pass. I don't see any practical >>>> advantage to requiring a null bounce address. If it's not null, >and >>>> the r= address doesn't work, the reporter might get the report >bounced >>>> back, but if I were a reporter I'd prefer to know if my reports >were >>>> going into the void so I could stop sending them. >>> The advantage of null mail from is no bounce loops. >> Right, and the disadvantage is no feedback if it's bouncing. >> >>> How would you feel about SHOULD use null mail from (with EHLO/HELO >SPF pass), but >>> MUST avoid mail loops and Mail From, if not null, MUST pass SPF? >> Make it MAY use null bounce address and we have a deal. And whether >> or not it's null, it MUST pass SPF. >Dear John, > >It would be a bad practice to require a protocol that defeats DNS/API >caching by incorporating local-part macros that are of no value. >Macros >able to target a domain with a significant number of recipient >generated >transactions per message where the victim may not be evident within any > >referenced record or message. Is MUST not use local-part macros an >ingredient of this mustard? No. This is no different than any other use of SPF. Scott K From sklist@kitterman.com Mon Jan 23 19:22:59 2012 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 A6D5E21F8630 for ; Mon, 23 Jan 2012 19:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 j7Rz8KnvgX13 for ; Mon, 23 Jan 2012 19:22:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 390FF21F850C for ; Mon, 23 Jan 2012 19:22:59 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D56EDD04088; Mon, 23 Jan 2012 21:22:58 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327375378; bh=PjyQQ1HaBnQ5uoOjBvE+ze4FZUpwHXhBWWEF9DTUtds=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=o/ObOxEBaj4cfU2PRrZpUdltUP9AQbmmnw4ShzaQ2jaDLzNmfNG0zj3bVFGYrjyI+ Hsz88e/C9hvmgrMY5vEE13rp4U7o29BikHfCbtwInBbcDtOpFlq9NEP5XLGUN7qIv4 5zGmYVM4Xz5KwolKF8//pi+xvobVXzjbt9G1/QDA= 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 A0496D0401E; Mon, 23 Jan 2012 21:22:58 -0600 (CST) References: <20120124012602.61337.qmail@joyce.lan> User-Agent: K-9 Mail for Android In-Reply-To: <20120124012602.61337.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 23 Jan 2012 22:23:10 -0500 To: marf@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 24 Jan 2012 03:22:59 -0000 John Levine wrote: >>>You say to use a null bounce address and a HELO with a domain that >>>produces an SPF Pass. I say use whatever bounce address you want, >but >>>be sure that it produces an SPF Pass. I don't see any practical >>>advantage to requiring a null bounce address. If it's not null, and >>>the r= address doesn't work, the reporter might get the report >bounced >>>back, but if I were a reporter I'd prefer to know if my reports were >>>going into the void so I could stop sending them. >> >>The advantage of null mail from is no bounce loops. > >Right, and the disadvantage is no feedback if it's bouncing. > >>How would you feel about SHOULD use null mail from (with EHLO/HELO SPF >pass), but >>MUST avoid mail loops and Mail From, if not null, MUST pass SPF? > >Make it MAY use null bounce address and we have a deal. And whether >or not it's null, it MUST pass SPF. > Sounds good. Scott K From shmuel+gen@patriot.net Mon Jan 23 20:33:04 2012 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 3092C21F85EA for ; Mon, 23 Jan 2012 20:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 anYYUyvJNg9j for ; Mon, 23 Jan 2012 20:33:03 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 95B0521F85E7 for ; Mon, 23 Jan 2012 20:33:03 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.7]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id BB4CFF5808F for ; Mon, 23 Jan 2012 23:18:54 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 23 Jan 2012 21:55:28 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120124041854.BB4CFF5808F@smtp.patriot.net> Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 24 Jan 2012 04:33:04 -0000 In , on 01/23/2012 at 02:18 PM, "Murray S. Kucherawy" said: >I have some concerns about doing this, since the reply from a WHOIS >query is non-standard. There is a common de facto standard of labels conting the word abuse. However, I was assuming that the usolicited ARF reports would be mostly semi-manually generated. >Do we really want to say "apply some unspecified heuristic to the >WHOIS reply to get that address"? Like parsing comments? BTDT,GTS. >I don't think we want to start encouraging people to try to find any >domain to which to prepend "abuse@" to start sending reports. I wasn't suggesting prepending abuse@ to the rDNS, I was asking about doing a whois on it or parent domains. -- 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 sklist@kitterman.com Mon Jan 23 20:42:43 2012 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 8C26621F853A for ; Mon, 23 Jan 2012 20:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6] 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 MSpobRwVqq1R for ; Mon, 23 Jan 2012 20:42:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8421F850D for ; Mon, 23 Jan 2012 20:42:42 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 32AF120E40DA; Mon, 23 Jan 2012 23:42:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327380162; bh=+DszqgRQZZp7wYWFSARz/WwI3JzfwUU/W5GF+uT0zfY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=brFU1DM8X8Lyud+Q3XLhCcDbOvB1pX3QygP1zdWj7NFjyEmZKVN8HdOHtPvW7K3bh bATH/IpYpqMGWnusr4L6gmbc4li55Yfay8UVM9tL7F+eK+98oGAdbUEedfAszYkojY L64Vg+XKtaAa0lHeczW+phlXKsGRWORMG8E7NRB4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 134B420E408E; Mon, 23 Jan 2012 23:42:41 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 23 Jan 2012 23:42:39 -0500 Message-ID: <3194404.3vdS34ylMH@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DKIM reporting 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, 24 Jan 2012 04:42:43 -0000 On Monday, January 23, 2012 04:55:48 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > > Sent: Wednesday, December 07, 2011 5:29 PM > > To: Murray S. Kucherawy > > Cc: marf@ietf.org > > Subject: Re: [marf] DKIM reporting > > > > Some quick observations: s/4871/6376/, s/sender/signer/ (or whatever > > is state of the art in DKIM terminology), and maybe say "alleged > > author" if that is the correct ADSP term. > > Fixed (though there were only a few). > > > It was straight forward to > > find _where_ the marf-reporting-discovery will find its TXT, for marf- > > dkim-reporting it took me some time to check RFCs 6376 + 5617. I think > > (could be wrong) that I understand the ADSP part, but I'm less sure > > about the DKIM part. > > Hopefully the DKIM part is simpler, since it doesn't involve DNS at all > anymore. It's all now signature tags. > > For ri=1 (non-zero) how long are receivers expected to wait for another > > incident? If you want ri=9, and I get only 8 broken signatures within > > a day, does this mean that you want no report because 8 is less than 9? > > The syntax of this has changed now to specify a count and an interval. The > thrust is for "X/Y" you specify you want no more than X reports in Y > seconds. As long as sending another report now would not exceed that > limit, send away. I think the discussion on the SPF draft re using a percentage instead of X/Y is germane for this draft as well. I think they should do it the same way (and I like a percentage better). > > Or do you want no second report before I got 2*9 broken signatures, no > > matter how long it takes? It is not clear for me why receivers would > > ever wish to follow detailed instructions about their reports, even > > including MUSTs and MUST NOTs in section 5. > > The point there is to give guidance on what to do if you're given a request > for a "foobar" report when you don't know what that is, just like in DKIM > we told people to ignore signature tags they don't know about. You're > right about the MUST NOT though. > > For ADSP ro=u I'm not sure what it is, is this simply "all minus ro=s"? > > Should the ADSP ro=u explanation (5.2) say "and" instead of "but"? > > Yes, fixed. > > > The rf=smtp + rs=... magic is apparently something in the direction of > > the SPF exp= magic. Or maybe not, please add more than one example for > > rf=smtp + rs=... tricks (or a pointer if this is explained elsewhere.) > > "rf" has been removed. > > > For ADSP + DKIM the marf-reporting stuff should fit into the relevant > > TXT records, for SPF I'm not sure. If you (= the WG) intend to create > > a general _report discovery mechanism it would be confusing to create > > additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I > > have no idea or opinion what's better (specific vs. general _report). > > Scott's handling the SPF stuff now, so I'll leave it to him to comment > there. I think the reporting modifiers we're proposing to add will only have a very modest impact on SPF record size and I've yet to run into a situation where overly large records were needed for SPF (people produce them all the time, but they can, IMO, always be redone to avoid the need). I don't see the modest expansion in record size as an issue. Scott K From msk@cloudmark.com Mon Jan 23 20:46:06 2012 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 7637921F86B6 for ; Mon, 23 Jan 2012 20:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 gkHmiCgifZk7 for ; Mon, 23 Jan 2012 20:46:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EF6D121F86AA for ; Mon, 23 Jan 2012 20:46:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 20:46:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 20:46:05 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 23 Jan 2012 20:46:05 -0800 Thread-Topic: [marf] DKIM reporting Thread-Index: AczaUp5RvejZArU1RuO1LcB28t2prwAAGHFw Message-ID: References: <3194404.3vdS34ylMH@scott-latitude-e6320> In-Reply-To: <3194404.3vdS34ylMH@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] DKIM reporting 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, 24 Jan 2012 04:46:06 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Monday, January 23, 2012 8:43 PM > To: marf@ietf.org > Subject: Re: [marf] DKIM reporting >=20 > I think the discussion on the SPF draft re using a percentage instead > of X/Y is germane for this draft as well. I think they should do it > the same way (and I like a percentage better). I agree, it's probably simpler all around. -MSK From msk@cloudmark.com Mon Jan 23 21:19:09 2012 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 5B73B21F8570 for ; Mon, 23 Jan 2012 21:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_43=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 uqrbfquR7pYS for ; Mon, 23 Jan 2012 21:19:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EDE9A21F856F for ; Mon, 23 Jan 2012 21:19:08 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 21:19:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 23 Jan 2012 21:19:08 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 23 Jan 2012 21:19:08 -0800 Thread-Topic: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports Thread-Index: AczaUUTy88nRDsawR424XuHnV4+xVAABkGqw Message-ID: References: <20120124041854.BB4CFF5808F@smtp.patriot.net> In-Reply-To: <20120124041854.BB4CFF5808F@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-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 24 Jan 2012 05:19:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, January 23, 2012 6:55 PM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicite= d Reports >=20 > >I have some concerns about doing this, since the reply from a WHOIS > >query is non-standard. >=20 > There is a common de facto standard of labels conting the word abuse. > However, I was assuming that the usolicited ARF reports would be mostly > semi-manually generated. It needs to be written down and reference-able for us to use it, in my opin= ion. > >Do we really want to say "apply some unspecified heuristic to the WHOIS > >reply to get that address"? >=20 > Like parsing comments? BTDT,GTS. What standard advocates parsing comments to extract actionable data? -MSK From internet-drafts@ietf.org Mon Jan 23 21:41:44 2012 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 07B0921F85D5; Mon, 23 Jan 2012 21:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 h1OW-VfmBV3V; Mon, 23 Jan 2012 21:41:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32721F85D0; Mon, 23 Jan 2012 21:41:23 -0800 (PST) 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.64p1 Message-ID: <20120124054123.11631.40183.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 21:41:23 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 05:41:44 -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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-04.txt Pages : 18 Date : 2012-01-23 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-04.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-dkim-reporting-04.txt From msk@cloudmark.com Mon Jan 23 21:49:10 2012 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 EEB5F21F84B3 for ; Mon, 23 Jan 2012 21:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl7t6i8IHCMZ for ; Mon, 23 Jan 2012 21:49:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB821F84D5 for ; Mon, 23 Jan 2012 21:49:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 23 Jan 2012 21:49:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 23 Jan 2012 21:49:08 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 23 Jan 2012 21:49:07 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt Thread-Index: AczaWt0OxRhWLMe1QNikOi+1TyQpPQAAAcKA Message-ID: References: <20120124054123.11631.40183.idtracker@ietfa.amsl.com> In-Reply-To: <20120124054123.11631.40183.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 05:49:10 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Monday, January 23, 2012 9:41 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt >=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 : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-04.txt > Pages : 18 > Date : 2012-01-23 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Changes since the previous version: - some language tightening with respect to "sender", "signer", etc. - don't reference the SPF reporting document; they may evolve separately, a= nd there's no need for them to hold each other up - move all the broken signature reporting into the signature itself by maki= ng them extension DKIM-Signature tags, rather than putting them in the key = records in the DNS; the revised design doesn't require DNS queries for fail= ed signatures that don't otherwise need them - remove "rf" (report format) tag for both DKIM and ADSP; assume all genera= ted reports will use ARF - rename "ri" (report interval) to "rp" (report percentage) for both DKIM a= nd ADSP - move report generation normative stuff out of Security Considerations and= into its own section that covers report generation syntax and transport is= sues; reference draft-ietf-marf-authfailure-report accordingly - other minor copy editing Fresh reviews and other comments are most welcome. -MSK From shmuel+gen@patriot.net Tue Jan 24 05:19:11 2012 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 E93C621F854C for ; Tue, 24 Jan 2012 05:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 f4rRfqkfC7yl for ; Tue, 24 Jan 2012 05:19:11 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD621F84D6 for ; Tue, 24 Jan 2012 05:19:11 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.150]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 2BBCEF5808F for ; Tue, 24 Jan 2012 08:05:01 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 24 Jan 2012 08:19:50 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120124130502.2BBCEF5808F@smtp.patriot.net> Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 24 Jan 2012 13:19:12 -0000 In , on 01/23/2012 at 09:19 PM, "Murray S. Kucherawy" said: >What standard advocates parsing comments to extract actionable data? No standard, I hope, just code. And, yes, it is a hack. I was thinking of text like Other uses for ARF involve reports sent between parties that don't know each other, with the recipient address typically being abuse@domain (see [RFC2142]), looked up via WHOIS, or using other heuristics. The reports may be manual, or automated due to hitting spam traps, scored high by spam filters, or anything else that the sender of the report considers to merit an abuse report. The abuse addresses in the whois records of the source IP and its FCrDNS are likely reasonable candidates for receiving fedback about the message, although automated parsing may be difficult. -- 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 Jan 24 05:30:00 2012 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 0280721F8551 for ; Tue, 24 Jan 2012 05:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.996 X-Spam-Level: X-Spam-Status: No, score=-108.996 tagged_above=-999 required=5 tests=[AWL=2.203, 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 MnWfYX1LiwQh for ; Tue, 24 Jan 2012 05:29:59 -0800 (PST) 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 F1F1B21F854C for ; Tue, 24 Jan 2012 05:29:58 -0800 (PST) Received: (qmail 75591 invoked from network); 24 Jan 2012 13:29:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 13:29:57 -0000 Date: 24 Jan 2012 13:29:35 -0000 Message-ID: <20120124132935.87921.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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:30:00 -0000 >- move all the broken signature reporting into the signature itself by making them >extension DKIM-Signature tags, rather than putting them in the key records in the >DNS; the revised design doesn't require DNS queries for failed signatures that >don't otherwise need them Let's say I put this line in the header of a bazillion messages in a spam run: DKIM-Signature: v=1; d=blackops.org; s=bogus; b=foo; bh=bar; h=baz; r=murray; I've just indirectly mailbombed you. Oops. The domain has to publish something about its willingness to get reports, not unlike the way that ADSP publishes a record about what to do if there's no signature that matches the From: domains. Perhaps something like this: _report._domainkey.blackops.org TXT "r=sendreportshere" It doesn't belong in the key record since, among other things, that would make it hard to debug failures due to missing or malformed key records. R's, John From scott@kitterman.com Tue Jan 24 06:53:26 2012 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 0502C21F85F4 for ; Tue, 24 Jan 2012 06:53:26 -0800 (PST) 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 pcKxzyZPSEkB for ; Tue, 24 Jan 2012 06:53:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF0E421F85DB for ; Tue, 24 Jan 2012 06:53:24 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 35A0F20E40DA; Tue, 24 Jan 2012 09:53:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327416804; bh=GI7i1my16u4hdwSJR2Q7ZsKYWBGlXnTUKV1KLZQN6Kg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=H1QhHad2b4/apMeU3wpjlojv0ElNT0RjCu6ZwzQxVAKm+XMI1GHaMQfQnXkGI+biZ jAC/o9aczi3LZ3nNA73tWwErp1U47suJsjVWfnGknVqTNBDABFAybT5SPAuunxCYPq kBILooCkGruOgkvdkIdCboxUAp7ApKnEEP4jOli0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 173EF20E406C; Tue, 24 Jan 2012 09:53:23 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 09:53:23 -0500 Message-ID: <9692760.VjyamvPSsx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124054123.11631.40183.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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:53:26 -0000 On Monday, January 23, 2012 09:49:07 PM Murray S. Kucherawy wrote: ... > - rename "ri" (report interval) to "rp" (report percentage) for both DKIM > and ADSP ... It looks like sig-ri-tag and adsp-ri-tag in the ABNF are still needing renaming. Scott K From sklist@kitterman.com Tue Jan 24 07:00:13 2012 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 7EB8D21F8627 for ; Tue, 24 Jan 2012 07:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 mAjDrDx4g4NB for ; Tue, 24 Jan 2012 07:00:12 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C895021F8611 for ; Tue, 24 Jan 2012 07:00:11 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6182F20E40DA; Tue, 24 Jan 2012 10:00:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327417211; bh=M9C2cdBAzajwIBLEBwqFW5EpBdd4P2ATlQO87UkPaQU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PxI4Eue9XWuAr2hkAmxnKV3YfGLtUE985YtD7oHMqSKbV5Blipm5XU5S/M7dOvwPJ BKeAwoivYfwlKa37TZ5lsuTl0TLz9HJfPT7Sikxa2CMUYYVFSBYnFKuzBStY3PZ7/D UoteeJE/yOulqGDHtrYjEXwK5gLMdj2eoO38Zfk4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 46CDE20E406C; Tue, 24 Jan 2012 10:00:11 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 10:00:10 -0500 Message-ID: <3076312.vJcWbVWg0z@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120124132935.87921.qmail@joyce.lan> References: <20120124132935.87921.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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:00:13 -0000 On Tuesday, January 24, 2012 01:29:35 PM John Levine wrote: > >- move all the broken signature reporting into the signature itself by > >making them extension DKIM-Signature tags, rather than putting them in > >the key records in the DNS; the revised design doesn't require DNS > >queries for failed signatures that don't otherwise need them > > Let's say I put this line in the header of a bazillion messages in a > spam run: > > DKIM-Signature: v=1; d=blackops.org; s=bogus; b=foo; bh=bar; h=baz; > r=murray; > > I've just indirectly mailbombed you. Oops. The domain has to publish > something about its willingness to get reports, not unlike the way that > ADSP publishes a record about what to do if there's no signature that > matches the From: domains. Perhaps something like this: I agree with it going in a DNS record, not in the signature for exactly the reasons you state. > _report._domainkey.blackops.org TXT "r=sendreportshere" > > It doesn't belong in the key record since, among other things, that > would make it hard to debug failures due to missing or malformed key > records. Isn't this perhaps overkill? As long as the key record isn't so broken one can't extract r=$STRING out of it, I think it's sufficient. OTOH, for key records that are missing entirely either because either someone forgot to publish it or the wrong selector is being used (I've seen both happen), there's no way around a separate record like this. I'm not sure what's best. Scott K From internet-drafts@ietf.org Tue Jan 24 07:32:18 2012 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 F0D0721F84D1; Tue, 24 Jan 2012 07:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 pZSkAAlx5gdw; Tue, 24 Jan 2012 07:32:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8DE21F8484; Tue, 24 Jan 2012 07:32:17 -0800 (PST) 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.64p1 Message-ID: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 07:32:17 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-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, 24 Jan 2012 15:32:18 -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-03.txt Pages : 15 Date : 2012-01-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-03.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-03.txt From sklist@kitterman.com Tue Jan 24 07:36:29 2012 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 67AA421F8592 for ; Tue, 24 Jan 2012 07:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 cl+abajs3wQP for ; Tue, 24 Jan 2012 07:36:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6A21F84BF for ; Tue, 24 Jan 2012 07:36:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 28D6420E40DA; Tue, 24 Jan 2012 10:36:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327419388; bh=mjLwGvT3k/0qgdXyH2gSMwR+SAObzHN7UBm+RifffvA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cIqNMP4nq3Vd4Qz1btJAiD73wdq1AqYMC3a5VEDcNX3YzB60+MOtgiMgOor4hLmk9 3NFpBXZ/1797iFaubL3YfjoNCUQLDLefBsijPk+iU1KMcFqE5o8IMm61vgpCf9tM3C 9iDyRiFmY1XViihcpiX2W8MAEkVgC5l6RYj3aoLA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0E60120E406C; Tue, 24 Jan 2012 10:36:27 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 10:36:27 -0500 Message-ID: <4628741.jAfMZy1Lx3@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> References: <20120124153217.13513.81965.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] I-D Action: draft-ietf-marf-spf-reporting-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, 24 Jan 2012 15:36:29 -0000 On Tuesday, January 24, 2012 07:32:17 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-03.txt > Pages : 15 > Date : 2012-01-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. Changes from the last version: * Updated the r= definition to only use localparts and append the SPF domain. * Removed the rf= (report format) modifier as there's only ARF. * Changed ri= (report interval) to rp= (report percentage) to match DKIM draft (and list discussion). * Added Neutral to the requested report types for completeness. * Deleted Reports From Unrelated Domains security consideration since it's resolved by the changes in this revision. * Added Forgeries and Automatic Generation to security considerations based on the text in the DKIM draft. * Updated IANA registry request, examples, and front matter for these changes. * Other minor updates Scott K From sklist@kitterman.com Tue Jan 24 07:39:18 2012 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 4D36421F84D7 for ; Tue, 24 Jan 2012 07:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 ul1Wt057eA-5 for ; Tue, 24 Jan 2012 07:39:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1821F84D3 for ; Tue, 24 Jan 2012 07:39:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 28ED220E40DA; Tue, 24 Jan 2012 10:39:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327419557; bh=t5owQjmRVoYFvLJ3UjwRK7Q/Gh17AfBqYddit9qXlfM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ECl/PuUw2Vk3ZiNCou0F7CMIG+qEZrW4kLulpp0sxvzYXVz8NFTFCERmDnv3Duet/ waEAo+ya6IPvbDq6BIz7iM3yOLzFI57bDlPlxoHrCs53WCKNDMohGwUgV0KUEuOguI 5bhq+Pyc3G0XKHjw6EF86wi6kaCIPLqG36Fasr8k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 09A1B20E406C; Tue, 24 Jan 2012 10:39:16 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 10:39:16 -0500 Message-ID: <4126007.l4N4XQoq9d@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4628741.jAfMZy1Lx3@scott-latitude-e6320> References: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> <4628741.jAfMZy1Lx3@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] I-D Action: draft-ietf-marf-spf-reporting-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, 24 Jan 2012 15:39:18 -0000 On Tuesday, January 24, 2012 10:36:27 AM Scott Kitterman wrote: > On Tuesday, January 24, 2012 07:32:17 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-03.txt > > Pages : 15 > > Date : 2012-01-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. > > Changes from the last version: > > * Updated the r= definition to only use localparts and append the SPF > domain. > * Removed the rf= (report format) modifier as there's only ARF. > * Changed ri= (report interval) to rp= (report percentage) to match DKIM > draft (and list discussion). > * Added Neutral to the requested report types for completeness. > * Deleted Reports From Unrelated Domains security consideration since it's > resolved by the changes in this revision. > * Added Forgeries and Automatic Generation to security considerations based > on the text in the DKIM draft. > * Updated IANA registry request, examples, and front matter for these > changes. > * Other minor updates Also reworked the envelope sender selection discussion based on John Levine's feedback ... Scott K From dhc@dcrocker.net Tue Jan 24 08:20:41 2012 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 CE08421F8634 for ; Tue, 24 Jan 2012 08:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_20=-0.74, 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 SV1Wh05rFkrd for ; Tue, 24 Jan 2012 08:20:40 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38B21F85C4 for ; Tue, 24 Jan 2012 08:20:40 -0800 (PST) Received: from [192.168.1.9] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0OGKQWC008966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jan 2012 08:20:32 -0800 Message-ID: <4F1EDA48.4050803@dcrocker.net> Date: Tue, 24 Jan 2012 08:20:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4F18ACA8.2010309@qualcomm.com> <4F1A0049.4040008@qualcomm.com> <4F1C4F0D.6090205@qualcomm.com> <4F1C5AAC.8030509@dcrocker.net> <4F1CA7F8.6050703@qualcomm.com> <4F1D90DE.1030800@bbiw.net> <4F1D9A55.602@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 24 Jan 2012 08:20:37 -0800 (PST) Cc: Pete Resnick , Message Abuse Report Format working group Subject: Re: [marf] DISCUSS handling (Was: DISCUSS on draft-ietf-marf-redaction-04) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 24 Jan 2012 16:20:42 -0000 On 1/23/2012 12:57 PM, Barry Leiba wrote: >The editors > usually go off and make changes, and the working group reviews those > changes. I'm suggesting nothing more nor less here. Actually, you are. You are suggesting that the negotiation between the AD and the wg chair/authors take place in private, only consulting the wg at the end. That's certainly the typical current mode for handling a Dicuss, but it is consistently a problem. The model you are endorsing treats the wg as a passive, post hoc reviewer. That's not the official view of the role of a wg in the IETF... >> Closed processes make it more likely that there will be narrower >> perspectives -- and therefore some aspect of the issue missed -- and less> support. It actually makes an AD less accountable for their Discuss. > > I very much disagree with you. What a side discussion does is allow > the editor(s) and the AD(s) to understand each other. It perhaps allows that, but that means that the wg does not gain the same understanding nor at the same time. It treats the authors and chairs as privileged to more information than the wg. The Discuss is with a wg product, not an author product. (FWIW I'll proffer my own theory that ADs who provide vague, incomplete or excessively narrow Discuss text or who prove to be unresponsive will tend to improve significantly, when they experience the broad and immediate feedback from a working group, rather than continuing to be permitted to conduct their Discuss activity out of the sunlight of that forum.) > I have > similarly had side conversations with GenART reviewers, SecDir > reviewers, and other working group participants. That those > discussions didn't happen on the mailing list didn't compromise the > process. It allowed us to work out an understanding, and allowed me, > as editor, to propose some text, which the working group could review. Side discussions are fine, but that's not really what you are promoting. You are promoting a parental process in which wg management filters the primary exchange with the AD. Once again, why is it reasonable to have a different process for resolving issues with ADs than for anyone else posting comments and challenges to the wg? > And you NEVER, in any of your editing in, say, DKIM, went off and > discussed things off the list? Every detail, major and minor, was on > the list at every moment of its development? Another error in logic both in form and extent. There is a difference between side -- that is, adjunct -- conversations that are sometimes held, versus formal, primary exchanges that are always conducted. (Your casting it in terms over 'every detail' moves towards hyperbole, which isn't helpful.) The current model is that the formal clarification and negotiation takes place in private. And, no, that's not the way wg work is done. That some side, private discussions might and do take place is fine here, as for all other situations, but not as the norm and not as the primary vehicle for resolving things. THAT is a major difference from the way the rest of wg business is conducted. > No one has said that an AD shouldn't participate in a working-group > discussion of the issues she brought up. All I've said is that the > chairs, not the ADs, should manage the working group, its process, and > its discussions. Requiring the AD with the Discuss to interact with the wg does not hand over management of the wg to them. Management by the chairs would remain unchanged. > I've had quite a few DISCUSS comments on my documents, which (the > comments) were resolved with one or two email messages, sometimes with > no text changes at all (there was something the AD didn't understand). So? > While I have no *objection* to the DISCUSS being posted to the > mailing list, as a management point I see no reason to remove the > judgment from the chairs' hands of how to handle the conversation. The current reality of standard working group process is that chairs do not have active control over the conduct of other wg interactions. Their "judgement" is relevant at a higher level than the gatekeeping of particular participants, absent misbehavior. Why does the interaction with an AD need to be different? >> Further, AD Discusses are now publicly documented. So the step you are >> objecting to is a matter of convenience, not availability. > > Exactly. Nothing hidden at all. Practically speaking, that's not true. First, the documentation is in a separate venue that is not typically visited and second because the interaction with the AD is offlist. Second, the negotiations are hidden. >> streamlines the resolution process by eliminating the information >> gatekeeping by whoever is mediating between the AD and the working group: > > Nothing is "streamlined" when a minor clarification turns into > (perhaps) a large number of messages from the working group copied to > the entire IESG. You are repeating the logic error: Some situations /might/ cause some problems; so use this as an excuse for ignoring the larger problems that generally /do/ occur. The meta-error is to look at one kind of problem, ignore its frequency or scale, but use its (occasional) existence as a basis for denying the import of other problems. That error is common in IETF debate. >> It puts the AD directly in front of the folks whose work is being> challenged. > > Ah, here we get to a key point: the assumption that a DISCUSS is > adversarial. A Discuss is an exercise of power. It blocks the progress of the document. It is one person -- typically someone with no history of the wg activity -- telling a small community that their work is not yet adequate. It is an AD saying NO (for now). One can be constructive or not, friendly or not, but that is inherently an adversarial process. It frequently produces the real and frequent wg tendency to want to appease the AD rather than worry about what makes for the best document. That some ADs are highly judicious and constructive about Discusses is fine, but it ignores that others are not. And nothing I'm proposing requires any discomfort in the process. It merely requires full sunlight. > A DISCUSS does block progress of a document, but it's > often NOT a "challenge". It is exactly and completely a challenge. By formal definition, a Discuss is a challenge. > It's often simply a request to, well, > discuss something briefly. It is not a 'request". It is a demand. One with teeth. >> This is a classic error in logic: The current mechanism often works >> adequately, so let's ignore the times it doesn't and let's ignore its> inefficiencies an inequities. > Did I ever say anything about ignoring anything? Yes. You are using the /possibility/ of some sturm und drang as an excuse for the /guarantee/ that wg participants are filtered out of direct involvement in dealing with a Discuss. > In fact, I said that when in the chair's judgment the discussion Barry, you keep ignoring the core point I keep making: The chair does not do that kind of prior restraint for any other part of wg process. Why is it reasonable for the chair to exert parental control over wg content for this part? >> My core point is that the /design/ of the current process is inherently >> flawed: it violates the IETF's model for handling objections that pervades> every other aspect of IETF work. > There's no question that the DISCUSS process is flawed. Really? I haven't seen anything in your postings that suggests that's your view. In any event, you've phrased that as a very broad point about Discusses and the one I've been pressing is quite narrow. >>> In this case, in fact, Murray did bring the discussion to the WG, without >>> your needing to force it.> >> This places an undue burden on chairs and/or authors. > > It's an "undue burden" on the chairs to manage their working groups? > I can't agree. Would it be reasonable to require all participants to be required to first get permission from the chairs or authors before bringing an issue to the list? Why is it then reasonable to impose that gatekeeping for this particular situation with ADs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Tue Jan 24 08:30:15 2012 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 7E1D221F865B for ; Tue, 24 Jan 2012 08:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GHPBbbei3rU for ; Tue, 24 Jan 2012 08:30:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E04BD21F8655 for ; Tue, 24 Jan 2012 08:30:14 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jan 2012 08:30:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 24 Jan 2012 08:30:14 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 24 Jan 2012 08:30:13 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt Thread-Index: AczaqPsJeg+HN3/DR/Ck1l87MEfc3wADErNg Message-ID: References: <20120124132935.87921.qmail@joyce.lan> <3076312.vJcWbVWg0z@scott-latitude-e6320> In-Reply-To: <3076312.vJcWbVWg0z@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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:30:15 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Tuesday, January 24, 2012 7:00 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt >=20 > On Tuesday, January 24, 2012 01:29:35 PM John Levine wrote: > > >- move all the broken signature reporting into the signature itself > > >by making them extension DKIM-Signature tags, rather than putting > > >them in the key records in the DNS; the revised design doesn't > > >require DNS queries for failed signatures that don't otherwise need > > >them > > > > Let's say I put this line in the header of a bazillion messages in a > > spam run: > > > > DKIM-Signature: v=3D1; d=3Dblackops.org; s=3Dbogus; b=3Dfoo; bh=3Dbar; = h=3Dbaz; > > r=3Dmurray; > > > > I've just indirectly mailbombed you. Oops. The domain has to publish > > something about its willingness to get reports, not unlike the way > > that ADSP publishes a record about what to do if there's no signature > > that matches the From: domains. Perhaps something like this: >=20 > I agree with it going in a DNS record, not in the signature for exactly > the reasons you state. The bottom part of Section 8.4 talks about not sending these automatically,= which is kind of in line with what we tell people about FBLs. Should this= just be normative? It's the same as the DNS idea except the indication is= explicit rather than something published, and we're not putting yet anothe= r record in the DNS. -MSK From internet-drafts@ietf.org Tue Jan 24 09:44:23 2012 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 2036A21F8584; Tue, 24 Jan 2012 09:44:23 -0800 (PST) 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 JQ15nVYjZkoa; Tue, 24 Jan 2012 09:44:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA021F856F; Tue, 24 Jan 2012 09:44:07 -0800 (PST) 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.64p1 Message-ID: <20120124174407.22910.76562.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2012 09:44:07 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 24 Jan 2012 17:44:23 -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 M. Kucherawy Filename : draft-ietf-marf-redaction-07.txt Pages : 8 Date : 2012-01-24 Email messages often contain information that 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-07.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-07.txt From msk@cloudmark.com Tue Jan 24 09:51:02 2012 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 31A5811E807A for ; Tue, 24 Jan 2012 09:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWJ8Z4eF4-uG for ; Tue, 24 Jan 2012 09:51:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1511E8079 for ; Tue, 24 Jan 2012 09:51:01 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jan 2012 09:51:01 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 24 Jan 2012 09:51:01 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 24 Jan 2012 09:50:59 -0800 Thread-Topic: I-D Action: draft-ietf-marf-redaction-07.txt Thread-Index: Aczav9dKa5HSmK+3QSedKJtmBoOLgAAAHAcQ Message-ID: References: <20120124174407.22910.76562.idtracker@ietfa.amsl.com> In-Reply-To: <20120124174407.22910.76562.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-redaction-07.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, 24 Jan 2012 17:51:02 -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: Tuesday, January 24, 2012 9:44 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-redaction-07.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 : Redaction of Potentially Sensitive Data from Mail Abus= e Reports > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-redaction-07.txt > Pages : 8 > Date : 2012-01-24 >=20 > Email messages often contain information that 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. The DISCUSS was cleared this morning. This version includes the changes ba= sed on Alessandro's suggestions, per recent consensus support. We hope thi= s is the final version. We'll ping Pete to approve this one on Friday if t= here hasn't been any squawking. -MSK From johnl@iecc.com Tue Jan 24 11:21:24 2012 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 0BACC11E80A1 for ; Tue, 24 Jan 2012 11:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.081 X-Spam-Level: X-Spam-Status: No, score=-109.081 tagged_above=-999 required=5 tests=[AWL=2.118, 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 KibVVUpC-UUf for ; Tue, 24 Jan 2012 11:21:23 -0800 (PST) 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 D801611E809D for ; Tue, 24 Jan 2012 11:21:22 -0800 (PST) Received: (qmail 30194 invoked from network); 24 Jan 2012 19:21:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 19:21:20 -0000 Date: 24 Jan 2012 19:20:58 -0000 Message-ID: <20120124192058.99679.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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:21:24 -0000 >The bottom part of Section 8.4 talks about not sending these automatically, which >is kind of in line with what we tell people about FBLs. Should this just be >normative? It's the same as the DNS idea except the indication is explicit rather >than something published, and we're not putting yet another record in the DNS. The next question has to be: if you have an external source telling whose signatures to report, why wouldn't that source also tell you where to send the reports and how many to send? If it's supposed to be automatic, then I think it has to be reasonably resistant to abuse by hostiles, which in this case requires a hard-to-fake indication of whether you want reports. If it's manual, what's the point of a standard? R's, John From steve@wordtothewise.com Tue Jan 24 11:32:17 2012 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 423D421F84F7 for ; Tue, 24 Jan 2012 11:32:17 -0800 (PST) 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 wTTCiDABZ2OQ for ; Tue, 24 Jan 2012 11:32:16 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92121F84F6 for ; Tue, 24 Jan 2012 11:32:16 -0800 (PST) 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 BB2E12DECF for ; Tue, 24 Jan 2012 11:32:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Tue, 24 Jan 2012 11:32:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99BA73F5-A02C-4CF6-A786-4B35DCCCA05D@wordtothewise.com> References: <20120124132935.87921.qmail@joyce.lan> <3076312.vJcWbVWg0z@scott-latitude-e6320> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:32:17 -0000 On Jan 24, 2012, at 8:30 AM, Murray S. Kucherawy wrote: >>>=20 >>> Let's say I put this line in the header of a bazillion messages in a >>> spam run: >>>=20 >>> DKIM-Signature: v=3D1; d=3Dblackops.org; s=3Dbogus; b=3Dfoo; bh=3Dbar;= h=3Dbaz; >>> r=3Dmurray; >>>=20 >>> I've just indirectly mailbombed you. Oops. The domain has to = publish >>> something about its willingness to get reports, not unlike the way >>> that ADSP publishes a record about what to do if there's no = signature >>> that matches the From: domains. Perhaps something like this: >>=20 >> I agree with it going in a DNS record, not in the signature for = exactly >> the reasons you state. >=20 > The bottom part of Section 8.4 talks about not sending these = automatically, which is kind of in line with what we tell people about = FBLs. Should this just be normative? It's the same as the DNS idea = except the indication is explicit rather than something published, and = we're not putting yet another record in the DNS. Over in draft-ietf-marf-as we are telling people it's OK to send = unsolicited reports automatically due to authentication failures. We = should be consistent about that, in one direction or the other. Cheers, Steve From sklist@kitterman.com Tue Jan 24 11:45:35 2012 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 1A4E211E8072 for ; Tue, 24 Jan 2012 11:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 Vp0udTg-W6Kt for ; Tue, 24 Jan 2012 11:45:34 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A44B11E8079 for ; Tue, 24 Jan 2012 11:45:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D89D320E40DA; Tue, 24 Jan 2012 14:45:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327434333; bh=LQi8bDhsN/IYtxfKlDGVsOYd1hj539JC7aiy/d3kHj8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Av7upJtGYtvkS4NLdfOUR6EQ8LqvNs8ZPe6YUDcKqDl6yAzb5XUqwbz6KIjMH5WYm ejZdjtcbx5CCWX1KjlV7DE5TC3l7UbMUmnnffSSsFTXEL+kS9p6jaKcIQtWqbYw76R mtphWd7K+j9AKfk0BcBYZLX6eTGhFeCoQG5KDYNw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BD45C20E406C; Tue, 24 Jan 2012 14:45:33 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 14:45:29 -0500 Message-ID: <3639441.lPrUbtX0Lb@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <99BA73F5-A02C-4CF6-A786-4B35DCCCA05D@wordtothewise.com> References: <20120124132935.87921.qmail@joyce.lan> <99BA73F5-A02C-4CF6-A786-4B35DCCCA05D@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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:45:35 -0000 On Tuesday, January 24, 2012 11:32:10 AM Steve Atkins wrote: > On Jan 24, 2012, at 8:30 AM, Murray S. Kucherawy wrote: > >>> Let's say I put this line in the header of a bazillion messages in a > >>> spam run: > >>> > >>> DKIM-Signature: v=1; d=blackops.org; s=bogus; b=foo; bh=bar; h=baz; > >>> r=murray; > >>> > >>> I've just indirectly mailbombed you. Oops. The domain has to > >>> publish > >>> something about its willingness to get reports, not unlike the way > >>> that ADSP publishes a record about what to do if there's no > >>> signature > >> > >>> that matches the From: domains. Perhaps something like this: > >> I agree with it going in a DNS record, not in the signature for > >> exactly > >> the reasons you state. > > > > The bottom part of Section 8.4 talks about not sending these > > automatically, which is kind of in line with what we tell people about > > FBLs. Should this just be normative? It's the same as the DNS idea > > except the indication is explicit rather than something published, and > > we're not putting yet another record in the DNS. > Over in draft-ietf-marf-as we are telling people it's OK to send unsolicited > reports automatically due to authentication failures. We should be > consistent about that, in one direction or the other. In draft-ietf-marf-spf-reporting as well. I think that the specification needs to be reasonable for automatic reporting even if there will often be out of band discussion about it. Scott K From msk@cloudmark.com Tue Jan 24 11:47:34 2012 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 868E911E8079 for ; Tue, 24 Jan 2012 11:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xblaLLFuWa3Y for ; Tue, 24 Jan 2012 11:47:33 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BA29211E8072 for ; Tue, 24 Jan 2012 11:47:33 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jan 2012 11:47:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 24 Jan 2012 11:47:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 24 Jan 2012 11:47:31 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt Thread-Index: Acza0L6SnyZZr+tQSOCpdB6DL+2T/wAACiZg Message-ID: References: <20120124132935.87921.qmail@joyce.lan> <99BA73F5-A02C-4CF6-A786-4B35DCCCA05D@wordtothewise.com> <3639441.lPrUbtX0Lb@scott-latitude-e6320> In-Reply-To: <3639441.lPrUbtX0Lb@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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:47:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, January 24, 2012 11:45 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt >=20 > In draft-ietf-marf-spf-reporting as well. >=20 > I think that the specification needs to be reasonable for automatic > reporting even if there will often be out of band discussion about it. OK, I'll work on something like the DNS verification thing John suggested a= nd get a diff or new version out shortly. -MSK From johnl@iecc.com Tue Jan 24 13:29:14 2012 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 0D99821F8669 for ; Tue, 24 Jan 2012 13:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.124 X-Spam-Level: X-Spam-Status: No, score=-109.124 tagged_above=-999 required=5 tests=[AWL=2.075, 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 4iQjOFe1oMar for ; Tue, 24 Jan 2012 13:29:13 -0800 (PST) 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 579D021F854C for ; Tue, 24 Jan 2012 13:29:13 -0800 (PST) Received: (qmail 10048 invoked from network); 24 Jan 2012 21:29:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Jan 2012 21:29:11 -0000 Date: 24 Jan 2012 21:28:49 -0000 Message-ID: <20120124212849.4290.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4628741.jAfMZy1Lx3@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] I-D Action: draft-ietf-marf-spf-reporting-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, 24 Jan 2012 21:29:14 -0000 Nits: in Sec 3, the description of r= still refers to rf=. In 6.3, how come it says that a bounce address MUST pass SPF but a HELO only SHOULD pass? (I'm not necessarily arguing, I'm asking.) Other than that, looks fine. R's, John From msk@cloudmark.com Tue Jan 24 13:35:01 2012 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 E88E621F8675 for ; Tue, 24 Jan 2012 13:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fu4oFGCn8an for ; Tue, 24 Jan 2012 13:34:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7B21F85D1 for ; Tue, 24 Jan 2012 13:34:58 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jan 2012 13:34:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 24 Jan 2012 13:34:58 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 24 Jan 2012 13:34:56 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt Thread-Index: AczazVyzfWXo0ry6RJiCyjppbHblrQAEpVwQ Message-ID: References: <20120124192058.99679.qmail@joyce.lan> In-Reply-To: <20120124192058.99679.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] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:35:01 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwgMjAxMiAxMToy MSBBTQ0KPiBUbzogbWFyZkBpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0KPiBT dWJqZWN0OiBSZTogW21hcmZdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFyZi1ka2ltLXJlcG9y dGluZy0wNC50eHQNCj4gDQo+ID5UaGUgYm90dG9tIHBhcnQgb2YgU2VjdGlvbiA4LjQgdGFsa3Mg YWJvdXQgbm90IHNlbmRpbmcgdGhlc2UNCj4gPmF1dG9tYXRpY2FsbHksIHdoaWNoIGlzIGtpbmQg b2YgaW4gbGluZSB3aXRoIHdoYXQgd2UgdGVsbCBwZW9wbGUgYWJvdXQNCj4gPkZCTHMuICBTaG91 bGQgdGhpcyBqdXN0IGJlIG5vcm1hdGl2ZT8gIEl0J3MgdGhlIHNhbWUgYXMgdGhlIEROUyBpZGVh DQo+ID5leGNlcHQgdGhlIGluZGljYXRpb24gaXMgZXhwbGljaXQgcmF0aGVyIHRoYW4gc29tZXRo aW5nIHB1Ymxpc2hlZCwgYW5kDQo+IHdlJ3JlIG5vdCBwdXR0aW5nIHlldCBhbm90aGVyIHJlY29y ZCBpbiB0aGUgRE5TLg0KPiANCj4gVGhlIG5leHQgcXVlc3Rpb24gaGFzIHRvIGJlOiBpZiB5b3Ug aGF2ZSBhbiBleHRlcm5hbCBzb3VyY2UgdGVsbGluZw0KPiB3aG9zZSBzaWduYXR1cmVzIHRvIHJl cG9ydCwgd2h5IHdvdWxkbid0IHRoYXQgc291cmNlIGFsc28gdGVsbCB5b3UNCj4gd2hlcmUgdG8g c2VuZCB0aGUgcmVwb3J0cyBhbmQgaG93IG1hbnkgdG8gc2VuZD8NCg0KV2FpdCwgaXNuJ3QgdGhh dCB3aGF0IEkgaGFkIGluIHRoZSBsYXN0IHZlcnNpb24sIHdoZXJlIHRoZSByZXBvcnRpbmcgYWRk cmVzcyB3YXMgaW4gdGhlIGtleSByZWNvcmQgaW4gdGhlIEROUz8NCg== From sklist@kitterman.com Tue Jan 24 14:02:04 2012 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 EA80211E8086 for ; Tue, 24 Jan 2012 14:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 o9kO4lRrLR3D for ; Tue, 24 Jan 2012 14:02:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1A61011E8079 for ; Tue, 24 Jan 2012 14:02:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2CD0120E40DA; Tue, 24 Jan 2012 17:02:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327442522; bh=viiFh6wgRAKwdeXu2oniHCMOHWPTzJNiO5SFGbKtPz4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=H0IusaW/ihuYm52GMdku09nTcYo2GOmZZHaFmofUKi3FeGxMH7rVU81KWMooPOAL/ Bscu6fgeFn38eHaE6koCP8l0t4sK41BHfihMAf81O3ZONW5+jZCENCCoCJePS0vgJM 78m2hyLT+b5iq4Y6yrhm+hbCSokXA+XRoRvCh3YM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EF7EA20E406C; Tue, 24 Jan 2012 17:02:01 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 24 Jan 2012 17:02:01 -0500 Message-ID: <1980939.JGD91LrNHg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120124212849.4290.qmail@joyce.lan> References: <20120124212849.4290.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] I-D Action: draft-ietf-marf-spf-reporting-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, 24 Jan 2012 22:02:04 -0000 On Tuesday, January 24, 2012 09:28:49 PM John Levine wrote: > Nits: in Sec 3, the description of r= still refers to rf=. Thanks. Fixed locally. > In 6.3, how come it says that a bounce address MUST pass SPF but a > HELO only SHOULD pass? (I'm not necessarily arguing, I'm asking.) > > Other than that, looks fine. Sending the report from an address the passes SPF, modulo bugs and DNS errors, solves the potential looping problem. If you're using NULL Mail From and the only identity you have for an SPF check is EHLO/HELO then there's still no loop problem, although you might generate an extra report if there's a rejection due to EHLO/HELO not passing SPF. Scott K From vesely@tana.it Wed Jan 25 05:48:11 2012 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 4560921F8600 for ; Wed, 25 Jan 2012 05:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[AWL=0.088, 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 X6ECHfH-C+pm for ; Wed, 25 Jan 2012 05:48:10 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD7621F85F1 for ; Wed, 25 Jan 2012 05:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327499289; bh=CSOkShq/9aEafvWykoIcHXWPDBI21vAgkpDLSliIQb8=; l=1076; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=c5VZWIx3IbjTlV4M/hFd4lZEAvjqaHMKQiGIhR/HwWPGApZ4203cnvQ/CMWfHj6E1 uLMsxROkgdbNoBsfG6HuyUrG9cwHaHD1NrZgPZ8Nw8BsfSAOWrZV54C+xkf3Je6Ld2 8SVxTiwnjFjK6HLyY0tOrdIRSPff8rghEVYIQ02E= 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, 25 Jan 2012 14:48:09 +0100 id 00000000005DC033.000000004F200819.00006583 Message-ID: <4F200818.90000@tana.it> Date: Wed, 25 Jan 2012 14:48:08 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120124192058.99679.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:48:11 -0000 On 24/Jan/12 22:34, Murray S. Kucherawy wrote: >> From: John Levine >> >> The next question has to be: if you have an external source telling >> whose signatures to report, why wouldn't that source also tell you >> where to send the reports and how many to send? > > Wait, isn't that what I had in the last version, where the > reporting address was in the key record in the DNS? Not exactly, John suggests a separate record like: _report._domainkey.blackops.org TXT "r=sendreportshere" Scott notes this solution allows to notify missing or misspelled selectors. So, as long as the ADMD don't change both records simultaneously, this way provides for more stable reporting than otherwise. In addition: * "_report" is not a valid selector, so there's no conflict, and * for a range of [report data] X [key data] sizes, this solution may allow to use UDP rather than TCP. For the consistency problem, and also in order to avoid redefining report modalities at every turn, I make an appeal to treat them all together, in reporting-discovery. From dotis@mail-abuse.org Wed Jan 25 08:54:43 2012 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 95F4B21F861F for ; Wed, 25 Jan 2012 08:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 4CFqLM0s3q8x for ; Wed, 25 Jan 2012 08:54:42 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id E57D021F861E for ; Wed, 25 Jan 2012 08:54:42 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 895D517404A6; Wed, 25 Jan 2012 16:54:42 +0000 (UTC) Message-ID: <4F2033D2.8040604@mail-abuse.org> Date: Wed, 25 Jan 2012 08:54:42 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120124012602.61337.qmail@joyce.lan> <4F1E0DC9.3030909@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 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, 25 Jan 2012 16:54:43 -0000 On 1/23/12 7:22 PM, Scott Kitterman wrote: > Douglas Otis wrote: > > On 1/23/12 5:26 PM, John Levine wrote: > >>>> You say to use a null bounce address and a HELO with a > >>>> domain that produces an SPF Pass. I say use whatever bounce > >>>> address you want, but be sure that it produces an SPF Pass. > >>>> I don't see any practical advantage to requiring a null > >>>> bounce address. If it's not null, and the r= address doesn't > >>>> work, the reporter might get the report bounced back, but if > >>>> I were a reporter I'd prefer to know if my reports were going > >>>> into the void so I could stop sending them. > >>> The advantage of null mail from is no bounce loops. Right, and > >>> the disadvantage is no feedback if it's bouncing. > >>> > >>> How would you feel about SHOULD use null mail from (with > >>> EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From, > >>> if not null, MUST pass SPF? > >> Make it MAY use null bounce address and we have a deal. And > >> whether or not it's null, it MUST pass SPF. > > Dear John, > > > > It would be a bad practice to require a protocol that defeats > > DNS/API caching by incorporating local-part macros that are of no > > value. Macros able to target a domain with a significant number of > > recipient generated transactions per message where the victim may > > not be evident within any referenced record or message. Is MUST > > not use local-part macros an ingredient of this mustard? > > No. This is no different than any other use of SPF. Dear Scott, Perhaps, but to what end? Until SPF is safe for the rest of the Internet, its use must not be mandated. After all, SPF mechanisms and macros permit more than 100 reflected DNS transactions per message times the number of parameters checked. This is suggesting a check against the Mail From and EHLO parameter that lacks any other form of cache-able authentication. The use of local-part macros with SPF means this validation process must NEVER be assumed cache-able. Until SPF copes with the current Internet environment, its use should not be mandated. What happens when the client and server do not share the same version of Internet Protocol and one of their Internet providers compensates by translating between the two? This might lead to nonsensical SPF records containing "exists:icann.org" or ending with "+all". Regards, Doug Otis From sklist@kitterman.com Wed Jan 25 09:13:22 2012 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 B553D21F85EE for ; Wed, 25 Jan 2012 09:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 7tMlp0Py+Fmq for ; Wed, 25 Jan 2012 09:13:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B328821F85E0 for ; Wed, 25 Jan 2012 09:13:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A8D8D20E40DA; Wed, 25 Jan 2012 12:13:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327511600; bh=HiehK/1Xx2OKy1BP54cHSbJVrX5Vi1gFhyxCmmB94hA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Qn2Va5EMov69YUByjVlRjLXsT+0Vj7zczYSdwsBA5q+EEpLnWr5ZAyXzAfNkOQmRl Q11KhO7QMQFMiFXzr7rtMpT1p1212Baj7zr4/XSeyf1gKPyPuc7OoBdtfYjpaAK9FQ dbKykFmk6xS2/WvUWy20x7Sdj/tBTEv+29I/4TzQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8A6CF20E4081; Wed, 25 Jan 2012 12:13:20 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 12:13:15 -0500 Message-ID: <1600074.ppbnrpJDya@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F2033D2.8040604@mail-abuse.org> References: <20120124012602.61337.qmail@joyce.lan> <4F2033D2.8040604@mail-abuse.org> 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-spf-reporting-02 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, 25 Jan 2012 17:13:22 -0000 On Wednesday, January 25, 2012 08:54:42 AM Douglas Otis wrote: > On 1/23/12 7:22 PM, Scott Kitterman wrote: > > Douglas Otis wrote: > > > On 1/23/12 5:26 PM, John Levine wrote: > > >>>> You say to use a null bounce address and a HELO with a > > >>>> domain that produces an SPF Pass. I say use whatever bounce > > >>>> address you want, but be sure that it produces an SPF Pass. > > >>>> I don't see any practical advantage to requiring a null > > >>>> bounce address. If it's not null, and the r= address doesn't > > >>>> work, the reporter might get the report bounced back, but if > > >>>> I were a reporter I'd prefer to know if my reports were going > > >>>> into the void so I could stop sending them. > > >>> > > >>> The advantage of null mail from is no bounce loops. Right, and > > >>> the disadvantage is no feedback if it's bouncing. > > >>> > > >>> How would you feel about SHOULD use null mail from (with > > >>> EHLO/HELO SPF pass), but MUST avoid mail loops and Mail From, > > >>> if not null, MUST pass SPF? > > >> > > >> Make it MAY use null bounce address and we have a deal. And > > >> whether or not it's null, it MUST pass SPF. > > > > > > Dear John, > > > > > > It would be a bad practice to require a protocol that defeats > > > DNS/API caching by incorporating local-part macros that are of no > > > value. Macros able to target a domain with a significant number of > > > recipient generated transactions per message where the victim may > > > not be evident within any referenced record or message. Is MUST > > > not use local-part macros an ingredient of this mustard? > > > > No. This is no different than any other use of SPF. > > Dear Scott, > > Perhaps, but to what end? > > Until SPF is safe for the rest of the Internet, its use must not be > mandated. Safe or not, it's not mandated. This spec is completely optional and is only applicable to domains doing SPF already. > After all, SPF mechanisms and macros permit more than 100 reflected DNS > transactions per message times the number of parameters checked. This > is suggesting a check against the Mail From and EHLO parameter that > lacks any other form of cache-able authentication. The use of > local-part macros with SPF means this validation process must NEVER be > assumed cache-able. This use of SPF is no different than any other, so it's no better or worse here. I don't think your theories about how SPF will make the Internet melt are on topic in the MARF working group. > Until SPF copes with the current Internet environment, its use should > not be mandated. Safe or not, it's not mandated. This spec is completely optional and is only applicable to domains doing SPF already. > What happens when the client and server do not share the same version of > Internet Protocol and one of their Internet providers compensates by > translating between the two? This use of SPF is no different than any other, so it's no better or worse here. I don't think your theories about how SPF will make the Internet melt are on topic in the MARF working group. > This might lead to nonsensical SPF records containing "exists:icann.org" > or ending with "+all". No specification can ensure people don't do odd things. Scott K From dotis@mail-abuse.org Wed Jan 25 09:47:13 2012 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 5773E21F84A1 for ; Wed, 25 Jan 2012 09:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 xUzv4lz73Gby for ; Wed, 25 Jan 2012 09:47:12 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95021F849D for ; Wed, 25 Jan 2012 09:47:12 -0800 (PST) Received: from US-DOUGO-MAC.local (unknown [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 7136D17404B4 for ; Wed, 25 Jan 2012 17:47:12 +0000 (UTC) Message-ID: <4F204020.3070609@mail-abuse.org> Date: Wed, 25 Jan 2012 09:47:12 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120124012602.61337.qmail@joyce.lan> <4F2033D2.8040604@mail-abuse.org> <1600074.ppbnrpJDya@scott-latitude-e6320> In-Reply-To: <1600074.ppbnrpJDya@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-spf-reporting-02 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, 25 Jan 2012 17:47:13 -0000 On 1/25/12 9:13 AM, Scott Kitterman wrote: > On Wednesday, January 25, 2012 08:54:42 AM Douglas Otis wrote: > > What happens when the client and server do not share the same > > version of Internet Protocol and one of their Internet providers > > compensates by translating between the two? > This use of SPF is no different than any other, so it's no better or > worse here. I don't think your theories about how SPF will make the > Internet melt are on topic in the MARF working group. Dear Scott, A requirement for an SPF PASS seems illogical for assessing SPF failure feedback. Disparities involving use of different IP protocols seems poorly considered in this case, does it not? The SPF macro concern is also unlikely to impact the email providers facilitating a targeted attack. What prevents use of DKIM as the only required vetting for feedback? > > This might lead to nonsensical SPF records containing > > "exists:icann.org" or ending with "+all". > No specification can ensure people don't do odd things. A specification should not require a protocol that expects an inappropriate processing of macros, nor should it inhibit the communications that it intends to support. Regards, Doug Otis From sklist@kitterman.com Wed Jan 25 09:54:55 2012 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 2DAE121F8585 for ; Wed, 25 Jan 2012 09:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 zCKeDbGW2Sp7 for ; Wed, 25 Jan 2012 09:54:54 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4421F8596 for ; Wed, 25 Jan 2012 09:54:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4D0B120E40DA; Wed, 25 Jan 2012 12:54:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327514093; bh=mONtHKgqgG8Yp776uSy4+yMGuyFC2LTbZycGenQ9/kk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=kK7rV6d2eZkQFHtaAFrCinUXjN+duq/oRhAE4iXZhCDLxJNLZdJ7JhSN7VkXc2hLu Aiy40ydf9WK0jWnIa1htzgkI9zkwLSPK54My5xdrA7+GgsGn2ujQQCMqx7cDhU0c2T RCQLXI2+bBkgxTFuiwxSfKSAmHyWlgmRrTp/HU8g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2D6E420E4081; Wed, 25 Jan 2012 12:54:53 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 12:54:52 -0500 Message-ID: <3186075.TP2dm1ouzh@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F204020.3070609@mail-abuse.org> References: <20120124012602.61337.qmail@joyce.lan> <1600074.ppbnrpJDya@scott-latitude-e6320> <4F204020.3070609@mail-abuse.org> 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-spf-reporting-02 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, 25 Jan 2012 17:54:55 -0000 On Wednesday, January 25, 2012 09:47:12 AM Douglas Otis wrote: > On 1/25/12 9:13 AM, Scott Kitterman wrote: > > On Wednesday, January 25, 2012 08:54:42 AM Douglas Otis wrote: > > > What happens when the client and server do not share the same > > > version of Internet Protocol and one of their Internet providers > > > compensates by translating between the two? > > > > This use of SPF is no different than any other, so it's no better or > > worse here. I don't think your theories about how SPF will make the > > Internet melt are on topic in the MARF working group. > > Dear Scott, > > A requirement for an SPF PASS seems illogical for assessing SPF failure > feedback. Disparities involving use of different IP protocols seems > poorly considered in this case, does it not? Logical or not, the spec doesn't actually do that, so you can relax. > The SPF macro concern is also unlikely to impact the email providers > facilitating a targeted attack. To this extent that is a problem (and we'll have to agree to disagree on this), this is no different than any other application of SPF, so it's not relevant to the discussion. > What prevents use of DKIM as the only required vetting for feedback? The issue in question is about the envelope and looping reports. I think DKIM is orthogonal to the point. Even if it's not, requiring implementation of an entirely separate technology (DKIM) to prevent loops is overkill and there's no evidence of any need for it to support interoperation. > > > This might lead to nonsensical SPF records containing > > > "exists:icann.org" or ending with "+all". > > > > No specification can ensure people don't do odd things. > > A specification should not require a protocol that expects an > inappropriate processing of macros, nor should it inhibit the > communications that it intends to support. I think we're OK on those grounds here. Scott K From msk@cloudmark.com Wed Jan 25 09:58:39 2012 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 7E5E821F8573 for ; Wed, 25 Jan 2012 09:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 9zifTqljwg8T for ; Wed, 25 Jan 2012 09:58:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 199D721F8570 for ; Wed, 25 Jan 2012 09:58:39 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 09:58:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 09:58:38 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 09:58:37 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-spf-reporting-02 Thread-Index: AczbhKYs++dTzZPxTxm89hnGefldhgABb+cw Message-ID: References: <20120124012602.61337.qmail@joyce.lan> <4F2033D2.8040604@mail-abuse.org> <1600074.ppbnrpJDya@scott-latitude-e6320> In-Reply-To: <1600074.ppbnrpJDya@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-spf-reporting-02 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, 25 Jan 2012 17:58:39 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 25, 2012 9:13 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting-02 >=20 > This use of SPF is no different than any other, so it's no better or > worse here. I don't think your theories about how SPF will make the > Internet melt are on topic in the MARF working group. I concur. Design concerns with SPF itself are not within the MARF scope. -MSK, as co-chair From internet-drafts@ietf.org Wed Jan 25 10:11:47 2012 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 F3FC821F85E4; Wed, 25 Jan 2012 10:11:46 -0800 (PST) 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=[AWL=0.000, 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 P3733dub8HsX; Wed, 25 Jan 2012 10:11:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7284221F85CC; Wed, 25 Jan 2012 10:11:36 -0800 (PST) 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.64p1 Message-ID: <20120125181136.3647.70318.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 10:11:36 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-05.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, 25 Jan 2012 18:11: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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-05.txt Pages : 21 Date : 2012-01-25 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-05.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-dkim-reporting-05.txt From msk@cloudmark.com Wed Jan 25 10:12:52 2012 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 55E7521F85C4 for ; Wed, 25 Jan 2012 10:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 aZUCOgnProy7 for ; Wed, 25 Jan 2012 10:12:51 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4E21F85B7 for ; Wed, 25 Jan 2012 10:12:51 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 10:12:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 10:12:51 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 10:12:50 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-05.txt Thread-Index: AczbjNP2Fk5+K78qSGq3Dm5AjqIDbAAAARHA Message-ID: References: <20120125181136.3647.70318.idtracker@ietfa.amsl.com> In-Reply-To: <20120125181136.3647.70318.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-05.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, 25 Jan 2012 18:12:52 -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: Wednesday, January 25, 2012 10:12 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-dkim-reporting-05.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 : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-05.txt > Pages : 21 > Date : 2012-01-25 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Incorporates feedback since -04. Yeas/neas or other feedback, please. -MSK From msk@cloudmark.com Wed Jan 25 10:36:46 2012 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 6224321F85E1 for ; Wed, 25 Jan 2012 10:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 wiZeYlxuGIcJ for ; Wed, 25 Jan 2012 10:36:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 02AC321F85D5 for ; Wed, 25 Jan 2012 10:36:45 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 10:36:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 10:36:45 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 10:36:44 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-05.txt Thread-Index: AczbjNP2Fk5+K78qSGq3Dm5AjqIDbAAAARHAAADWLsA= Message-ID: References: <20120125181136.3647.70318.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] I-D Action: draft-ietf-marf-dkim-reporting-05.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, 25 Jan 2012 18:36:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy > Sent: Wednesday, January 25, 2012 10:13 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-05.txt >=20 > Incorporates feedback since -04. Also, I'll work to have this implemented before or during WGLC so that we h= ave those results to include as it moves forward. Thanks for the feedback. -MSK From msk@cloudmark.com Wed Jan 25 10:53:43 2012 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 C962321F85B5 for ; Wed, 25 Jan 2012 10:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 XQdxlpzfipSJ for ; Wed, 25 Jan 2012 10:53:43 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E8BFA21F856F for ; Wed, 25 Jan 2012 10:53:42 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 10:53:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 10:53:42 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 10:53:41 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt Thread-Index: Acza48+uY64Asw/+TCSQaAGSkGiPGgArUYJw Message-ID: References: <20120124212849.4290.qmail@joyce.lan> <1980939.JGD91LrNHg@scott-latitude-e6320> In-Reply-To: <1980939.JGD91LrNHg@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 18:53:43 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, January 24, 2012 2:02 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >=20 > On Tuesday, January 24, 2012 09:28:49 PM John Levine wrote: > > Nits: in Sec 3, the description of r=3D still refers to rf=3D. >=20 > Thanks. Fixed locally. >=20 > > In 6.3, how come it says that a bounce address MUST pass SPF but a > > HELO only SHOULD pass? (I'm not necessarily arguing, I'm asking.) > > > > Other than that, looks fine. >=20 > Sending the report from an address the passes SPF, modulo bugs and DNS > errors, solves the potential looping problem. If you're using NULL Mail > From and the only identity you have for an SPF check is EHLO/HELO then > there's still no loop problem, although you might generate an extra > report if there's a rejection due to EHLO/HELO not passing SPF. The text in -03 says: "Per Section 2 of [DSN], the NULL envelope sender address of the report MAY= be chosen to ensure that no delivery status reports will be issued in resp= onse to the report itself." That's not consistent with Section 2 of [DSN], which says SHOULD and MUST. = We should either drop the reference, or be consistent with it. If we drop= it, we need to be prepared to explain why we're contradicting [DSN], which= is a draft standard. Also: 1) 6.3 has a missing "<" before an xref, so the XML is revealed in the prod= uced document. 2) I've changed "r=3D" to "ra=3D" so that all of the reporting tags are dis= tinguishable as "r[a-z]". Seem reasonable for yours as well? -MSK From msk@cloudmark.com Wed Jan 25 11:17:49 2012 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 1446C21F8593 for ; Wed, 25 Jan 2012 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 DRWzNpgyuZkF for ; Wed, 25 Jan 2012 11:17:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 78B0E21F858B for ; Wed, 25 Jan 2012 11:17:48 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 11:17:47 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 11:17:47 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 25 Jan 2012 11:17:46 -0800 Thread-Topic: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicited Reports Thread-Index: AczamsSWdQUr36LgQteAapnrqQDRRgA+zPvA Message-ID: References: <20120124130502.2BBCEF5808F@smtp.patriot.net> In-Reply-To: <20120124130502.2BBCEF5808F@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-ietf-marf-as Section 5 Solicited and Unsolicited Reports 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, 25 Jan 2012 19:17:49 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Tuesday, January 24, 2012 5:20 AM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-as Section 5 Solicited and Unsolicite= d Reports >=20 > I was thinking of text like >=20 > Other uses for ARF involve reports sent between parties that > don't know each other, with the recipient address typically > being abuse@domain (see [RFC2142]), looked up via WHOIS, or > using other heuristics. The reports may be manual, or automated > due to hitting spam traps, scored high by spam filters, or > anything else that the sender of the report considers to merit > an abuse report. The abuse addresses in the whois records of > the source IP and its FCrDNS are likely reasonable candidates > for receiving fedback about the message, although automated > parsing may be difficult. Ah, that's much more palatable than what I was envisioning. Thanks. -MSK From sklist@kitterman.com Wed Jan 25 11:56:14 2012 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 0823F21F8599 for ; Wed, 25 Jan 2012 11:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 sinNwaEdIQwR for ; Wed, 25 Jan 2012 11:56:13 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40BF021F855E for ; Wed, 25 Jan 2012 11:56:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BD49E20E40DA; Wed, 25 Jan 2012 14:56:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327521372; bh=os9C7xxvuULnzYm2JkZC/MvgDFsX+jCZ5jVpJbjlMg0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=G03Jy4L7T3/Ou0bz2QAtmN2Kz5eXxLxqb2ph9XIoFab6MN6ckJf6ISNIdl/bbsEGh du1ML8rruB9Qb0avCAYf/wbstGFdwVtvuWndvMrKL+bUASnR+ESFtSl4RAqWboWLIG wo0SOs4U1KKLIbyMxQQEs+GFtKiHA1/R+5S4Y6S8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A296720E4081; Wed, 25 Jan 2012 14:56:12 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 14:56:12 -0500 Message-ID: <1378257.GpPSoy1TIW@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124212849.4290.qmail@joyce.lan> <1980939.JGD91LrNHg@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 19:56:14 -0000 On Wednesday, January 25, 2012 10:53:41 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Tuesday, January 24, 2012 2:02 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt > > > > On Tuesday, January 24, 2012 09:28:49 PM John Levine wrote: > > > Nits: in Sec 3, the description of r= still refers to rf=. > > > > Thanks. Fixed locally. > > > > > In 6.3, how come it says that a bounce address MUST pass SPF but a > > > HELO only SHOULD pass? (I'm not necessarily arguing, I'm asking.) > > > > > > Other than that, looks fine. > > > > Sending the report from an address the passes SPF, modulo bugs and DNS > > errors, solves the potential looping problem. If you're using NULL Mail > > From and the only identity you have for an SPF check is EHLO/HELO then > > there's still no loop problem, although you might generate an extra > > report if there's a rejection due to EHLO/HELO not passing SPF. > > The text in -03 says: > > "Per Section 2 of [DSN], the NULL envelope sender address of the report MAY > be chosen to ensure that no delivery status reports will be issued in > response to the report itself." > > That's not consistent with Section 2 of [DSN], which says SHOULD and MUST. > We should either drop the reference, or be consistent with it. If we drop > it, we need to be prepared to explain why we're contradicting [DSN], which > is a draft standard. This isn't actually a DSN (is it)? Perhaps "Similar to Section 2 of [DSN} ..." instead of "Per Section 2 of [DSN] ..."? > Also: > > 1) 6.3 has a missing "<" before an xref, so the XML is revealed in the > produced document. Fixed locally. Thanks. > 2) I've changed "r=" to "ra=" so that all of the reporting tags are > distinguishable as "r[a-z]". Seem reasonable for yours as well? Sure. Done locally. I notice in your draft you use two styles for the ABNF specification: rep-ra-tag = %x72.61 spf-rp-tag = %x72 %x69 The SPF draft uses the latter format. Is one of these preferred? I suspect it would be better to pick one form and stick with it over using two (I'm not an ABNF expert at all, so please advise). Scott K From msk@cloudmark.com Wed Jan 25 11:59:48 2012 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 6A19F21F85B5 for ; Wed, 25 Jan 2012 11:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 f-JDBzNqkRsr for ; Wed, 25 Jan 2012 11:59:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EE81B21F859E for ; Wed, 25 Jan 2012 11:59:47 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 11:59:47 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 11:59:47 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 11:59:46 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt Thread-Index: Aczbm2XEUXutuIB9SZiBjZgXMiHMxgAABGhA Message-ID: References: <20120124212849.4290.qmail@joyce.lan> <1980939.JGD91LrNHg@scott-latitude-e6320> <1378257.GpPSoy1TIW@scott-latitude-e6320> In-Reply-To: <1378257.GpPSoy1TIW@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 19:59:48 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 25, 2012 11:56 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >=20 > This isn't actually a DSN (is it)? Perhaps "Similar to Section 2 of > [DSN} ..." instead of "Per Section 2 of [DSN] ..."? It's not a DSN proper, right, but we still want to avoid the same situation= s that DSN has to avoid. > > 2) I've changed "r=3D" to "ra=3D" so that all of the reporting tags are > > distinguishable as "r[a-z]". Seem reasonable for yours as well? >=20 > Sure. Done locally. I notice in your draft you use two styles for the A= BNF > specification: >=20 > rep-ra-tag =3D %x72.61 > spf-rp-tag =3D %x72 %x69 >=20 > The SPF draft uses the latter format. Is one of these preferred? I > suspect it would be better to pick one form and stick with it over > using two (I'm not an ABNF expert at all, so please advise). I'll switch it to the first. I tried to get them all but I must've missed = some. -MSK From sklist@kitterman.com Wed Jan 25 12:14:08 2012 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 11C3021F84F5 for ; Wed, 25 Jan 2012 12:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 4qp5yRhIrVV9 for ; Wed, 25 Jan 2012 12:14:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5A72821F84EF for ; Wed, 25 Jan 2012 12:14:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E370320E40DA; Wed, 25 Jan 2012 15:14:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327522446; bh=hQgk+Ei/DNbAKdyUEGccmflvkBASR80MQlR7zVmUVUY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=gKh/B130jkfP5qsKoJPXxwMfQIyEbhbLIZV49r3Bu+3s6d75knTnljAP6P6kU2B0B B8mfIEuyhCicebJAZfv6q7vWX8zci5pXSQX50qH27gqbx/wN4B0LJWPrVOEEEiXMDa SWOmISCFXL8jC3snGZ641LlboUqhX6422sIoEWPU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C3B1D20E4081; Wed, 25 Jan 2012 15:14:06 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 15:14:06 -0500 Message-ID: <1381115.JgxOmO110E@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124212849.4290.qmail@joyce.lan> <1378257.GpPSoy1TIW@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 20:14:08 -0000 On Wednesday, January 25, 2012 11:59:46 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, January 25, 2012 11:56 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt > > > > This isn't actually a DSN (is it)? Perhaps "Similar to Section 2 of > > [DSN} ..." instead of "Per Section 2 of [DSN] ..."? > > It's not a DSN proper, right, but we still want to avoid the same situations > that DSN has to avoid. OK. I changed it to "Similar to ..." > > > 2) I've changed "r=" to "ra=" so that all of the reporting tags are > > > distinguishable as "r[a-z]". Seem reasonable for yours as well? > > > > Sure. Done locally. I notice in your draft you use two styles for the > > ABNF specification: > > > > rep-ra-tag = %x72.61 > > spf-rp-tag = %x72 %x69 > > > > The SPF draft uses the latter format. Is one of these preferred? I > > suspect it would be better to pick one form and stick with it over > > using two (I'm not an ABNF expert at all, so please advise). > > I'll switch it to the first. I tried to get them all but I must've missed > some. OK. I switched the SPF draft to the first one as well. Scott K From msk@cloudmark.com Wed Jan 25 12:19:07 2012 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 7413C11E80BC for ; Wed, 25 Jan 2012 12:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 kCJSJmttIZAE for ; Wed, 25 Jan 2012 12:19:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0633C11E80BE for ; Wed, 25 Jan 2012 12:19:05 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 12:19:04 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 12:19:04 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 12:19:02 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt Thread-Index: AczbneckvzZOKhBVQ2q7pRqPnngpYgAAFlZQ Message-ID: References: <20120124212849.4290.qmail@joyce.lan> <1378257.GpPSoy1TIW@scott-latitude-e6320> <1381115.JgxOmO110E@scott-latitude-e6320> In-Reply-To: <1381115.JgxOmO110E@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 20:19:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 25, 2012 12:14 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >=20 > > It's not a DSN proper, right, but we still want to avoid the same > > situations that DSN has to avoid. >=20 > OK. I changed it to "Similar to ..." It seems to me that we should say the same thing here. Here's what my working copy has: 6.2. Envelope Sender Selection In the case of transmitted reports in the form of a new message (versus rejections during an [SMTP] session), it is necessary to construct the message so as to avoid amplification attacks, deliberate or otherwise. The envelope sender address of the report needs to be chosen so that these reports will not generate mail loops. Per Section 2 of [DSN], the envelope sender address of the report SHOULD be chosen to ensure that no delivery status reports will be issued in response to the report itself, and MUST be chosen so that the report will not cause a mail loop. Therefore, if an [SMTP] transaction is used to send a report, the MAIL FROM command MUST either use the NULL return address, i.e., "MAIL FROM:<>", or one that will pass [SPF] MAIL FROM checks on receipt. The HELO/EHLO command SHOULD also be selected so that it wil pass [SPF] HELO checks. Does that fit with what you and John were saying? From sklist@kitterman.com Wed Jan 25 12:41:41 2012 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 9675C21F8542 for ; Wed, 25 Jan 2012 12:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 gxWjckHzlJQ7 for ; Wed, 25 Jan 2012 12:41:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BC75421F853D for ; Wed, 25 Jan 2012 12:41:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 22FC120E40DA; Wed, 25 Jan 2012 15:41:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327524100; bh=gcNvGJ0J1YpzoUw6I4UglCR5GZ6AFMOfplE38ZXrj6I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=J3yuUTyQv9cNaiP6LcBNr403+YSjcvRsRqaoVqYFrJfIdQ6G0pRckZE3QgDkcm+Kq tG6l6Lz/vsX6VAI4WTkdsK/Amj3dQzCLiNKWdOWJX5oQIgp1aetVpm6WEOedvMZfsv XHr6detqk26ozNma2s57aV51PNeuidBooCKBZt0g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 07C9620E4081; Wed, 25 Jan 2012 15:41:39 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 15:41:39 -0500 Message-ID: <2123233.4NIzhkgVZA@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124212849.4290.qmail@joyce.lan> <1381115.JgxOmO110E@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 20:41:41 -0000 On Wednesday, January 25, 2012 12:19:02 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, January 25, 2012 12:14 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt > > > > > It's not a DSN proper, right, but we still want to avoid the same > > > situations that DSN has to avoid. > > > > OK. I changed it to "Similar to ..." > > It seems to me that we should say the same thing here. > > Here's what my working copy has: > > 6.2. Envelope Sender Selection > > In the case of transmitted reports in the form of a new message > (versus rejections during an [SMTP] session), it is necessary to > construct the message so as to avoid amplification attacks, > deliberate or otherwise. The envelope sender address of the report > needs to be chosen so that these reports will not generate mail > loops. > > Per Section 2 of [DSN], the envelope sender address of the report > SHOULD be chosen to ensure that no delivery status reports will be > issued in response to the report itself, and MUST be chosen so that > the report will not cause a mail loop. > > Therefore, if an [SMTP] transaction is used to send a report, the > MAIL FROM command MUST either use the NULL return address, i.e., > "MAIL FROM:<>", or one that will pass [SPF] MAIL FROM checks on > receipt. The HELO/EHLO command SHOULD also be selected so that it > wil pass [SPF] HELO checks. > > Does that fit with what you and John were saying? Speaking for myself, I think so. It still has the Per section 2 of [DSN] problem. How about this (a hybrid of what you have here and what I've got locally): 6.2. Envelope Sender Selection In the case of transmitted reports in the form of a new message (versus rejections during an [SMTP] session), it is necessary to construct the message so as to avoid amplification attacks, deliberate or otherwise. The envelope sender address of the report MUST be chosen so that these reports will not generate mail loops. Similar to Section 2 of [DSN], the envelope sender address of the report SHOULD be chosen to ensure that no feed back reports will be issued in response to the report itself. When an [SMTP] transaction is used to send a report, the MAIL FROM command MUST either use the NULL return address, i.e., "MAIL FROM:<>", or one that will pass [SPF] MAIL FROM checks on receipt. The HELO/EHLO command SHOULD also be selected so that it will pass [SPF] HELO checks. Scott K From derek.diget+marf@wmich.edu Wed Jan 25 14:13:02 2012 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 D105D11E807A for ; Wed, 25 Jan 2012 14:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=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 AFaSHggw4e28 for ; Wed, 25 Jan 2012 14:13:02 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0311E80A6 for ; Wed, 25 Jan 2012 14:13:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LYD00LZDKDKXM60@mta01.service.private> for marf@ietf.org; Wed, 25 Jan 2012 17:12:58 -0500 (EST) X-WMU-Spam: Gauge=X, Probability=10% on Wed Jan 25 17:12:58 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.25.220018 - Wed Jan 25 17:12:57 2012 Date: Wed, 25 Jan 2012 17:12:56 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: marf@ietf.org In-reply-to: <4628741.jAfMZy1Lx3@scott-latitude-e6320> Message-id: References: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> <4628741.jAfMZy1Lx3@scott-latitude-e6320> Subject: [marf] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 22:13:03 -0000 On Jan 24, 2012 at 10:36 -0500, Scott Kitterman wrote: =>* Updated the r= definition to only use localparts and append the SPF domain. How will this work for sites that publish "null" SPF records ()? By publishing a "null" SPF record the domain part is not suppose to be used for email. But if the site wanted to get reports for attempts to use that domain, how would they? Sending to @ won't work. Similar issue with "HELO" SPF records (). For example with the following DNS/SPF records: (I hope I don't have any errors below. :) example.com TXT "v=spf1 ip4:192.168.1.25 ip4:192.168.1.81 -all r=postmaster" MX 10 mail.example.com mail.example.com A 192.168.1.25 TXT "v=spf1 -a -all r=postmaster" www.example.com A 192.168.1.80 TXT "v=spf1 -all r=postmaster" websrv1.example.com A 192.168.1.81 TXT "v=spf1 -a -all r=postmaster" Example 1: A message is sent from mail.example.com's IP address. (connection source IP is from 192.168.1.25) HELO mail.example.com --> SPF HELO check = Pass MAIL FROM: --> SPF MAIL FROM check = Pass No report generated. Example 2: A message sent from their web server. (www.example.com IP is a virtual interface on the "websrv1" box.) (connection source IP is from 192.168.1.81) HELO websrv1.example.com --> SPF HELO check = Pass MAIL FROM: --> SPF MAIL FROM check = Pass No report generated. Example 3: A message sent from a system not authorized (connection source IP is from 172.16.1.100) HELO mail.example.com --> SPF HELO check = Fail A report should be created (if I understand the concept of this draft) with r=postmaster for the mail.example.com SPF record being sent to . But mail.example.com is not used as a domain for mail delivery. No MX record, but in this case the A record is listening on port 25 is not configured to accept mail for messages addressed to @mail.example.com. Example 4: A message sent from a system not authorized (connection source IP is from 172.16.1.100) HELO dsl-100.1.16.172.big-isp.example.net --> no SPF published = Pass MAIL FROM: --> SPF MAIL FROM check = Fail As with example 3, sending a report to won't work. No MX record and the A record is not even listening on port 25. Does the last two example makes sense or am I missing something? == *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From sklist@kitterman.com Wed Jan 25 14:17:10 2012 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 24C6111E80A6 for ; Wed, 25 Jan 2012 14:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 1zKRSDD9kbwE for ; Wed, 25 Jan 2012 14:17:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6634111E807A for ; Wed, 25 Jan 2012 14:17:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D7B5020E40DA; Wed, 25 Jan 2012 17:17:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327529828; bh=v8gUe14RpSt2YZfYQFLTrIutw1ocwzDgTpVe98nvHk4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Z5dclpGibYpQ/UJtbq3z7AG52XbEopewQIwniVIg4TosrrhTMM+nHKrv3NBNu69x3 FFaE5f0y86/AaI6AoMyUhUuxPylZYygcn6bu3J/q2j4pAQyn344J7AwPbORx8clLMF lUFAsn4pFSSIHBTUhGKTFjRTue2Pok1nkHSGoffc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B8CF520E4081; Wed, 25 Jan 2012 17:17:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 17:17:08 -0500 Message-ID: <1376842.rDsXOy1W6A@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> <4628741.jAfMZy1Lx3@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] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 22:17:10 -0000 On Wednesday, January 25, 2012 05:12:56 PM Derek Diget wrote: > On Jan 24, 2012 at 10:36 -0500, Scott Kitterman wrote: > =>* Updated the r= definition to only use localparts and append the SPF > domain. > > How will this work for sites that publish "null" SPF records > ()? > > By publishing a "null" SPF record the domain part is not suppose to be > used for email. But if the site wanted to get reports for attempts to > use that domain, how would they? Sending to > @ won't work. You are confusing sending and receiving. Nothing says such domains don't receive mail. Scott K From msk@cloudmark.com Wed Jan 25 14:44:34 2012 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 6FE6611E80B9 for ; Wed, 25 Jan 2012 14:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtIOmHpg5Czm for ; Wed, 25 Jan 2012 14:44:33 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DE57A11E807A for ; Wed, 25 Jan 2012 14:44:33 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 14:44:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 14:44:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 14:44:32 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt Thread-Index: AczbocA2ikGrtdbyR0+J2tXVTckqwQAERpbQ Message-ID: References: <20120124212849.4290.qmail@joyce.lan> <1381115.JgxOmO110E@scott-latitude-e6320> <2123233.4NIzhkgVZA@scott-latitude-e6320> In-Reply-To: <2123233.4NIzhkgVZA@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] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 22:44:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 25, 2012 12:42 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >=20 > Speaking for myself, I think so. It still has the Per section 2 of > [DSN] problem. How about this (a hybrid of what you have here and what I= 've got > locally): >[...] Works for me. -MSK From sklist@kitterman.com Wed Jan 25 15:32:52 2012 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 319A421F8525 for ; Wed, 25 Jan 2012 15:32:52 -0800 (PST) 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 QrGnCZnYbPpv for ; Wed, 25 Jan 2012 15:32:46 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id EC16B21F8522 for ; Wed, 25 Jan 2012 15:32:45 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 194F8D04088; Wed, 25 Jan 2012 17:32:45 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327534365; bh=b6H3sDbiKFhoIkIFNb4/FgpUNQW9Tej1Esks2lS8aTs=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=Li2lI3XmIIMYJFEcDMKt7N4gVyA8p4dZnfXNFxdkMPUtNBuGj8PwAzqsqYeh1e1Bz Bf49tK6Fb5rTrli/1lbf5MhCof//vurygfFi7O6R8htTKZuG1nKh4AwDlFUgeSv2Xr pp4cCuxMjEMt5+EewXZllWjjuJOYPPlMd6gTwluE= Received: from 238.sub-97-252-226.myvzw.com (238.sub-97-252-226.myvzw.com [97.252.226.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1D878D0401E; Wed, 25 Jan 2012 17:32:43 -0600 (CST) References: <20120124212849.4290.qmail@joyce.lan> <1381115.JgxOmO110E@scott-latitude-e6320> <2123233.4NIzhkgVZA@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 25 Jan 2012 18:32:53 -0500 To: "marf@ietf.org" Message-ID: <4ce8ca5e-1deb-4a2f-aa3f-d31f7e1c243b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 23:32:52 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Scott Kitterman >> Sent: Wednesday, January 25, 2012 12:42 PM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >> >> Speaking for myself, I think so. It still has the Per section 2 of >> [DSN] problem. How about this (a hybrid of what you have here and >what I've got >> locally): >>[...] > >Works for me. Great. It occurs to me that maybe the [DSN] reference could be informative now. Once I'm in front of my computer again I'll look at it and check if that's the only place it comes up. Scott K From msk@cloudmark.com Wed Jan 25 15:34:44 2012 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 4C5E921F8525 for ; Wed, 25 Jan 2012 15:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX0V639hOmjM for ; Wed, 25 Jan 2012 15:34:43 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E1ACE21F8526 for ; Wed, 25 Jan 2012 15:34:43 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 15:34:43 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 15:34:43 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 15:34:41 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt Thread-Index: AczbuapHPuxm0X2SRUS8YNNI1XlPBwAADL4w Message-ID: References: <20120124212849.4290.qmail@joyce.lan> <1381115.JgxOmO110E@scott-latitude-e6320> <2123233.4NIzhkgVZA@scott-latitude-e6320> <4ce8ca5e-1deb-4a2f-aa3f-d31f7e1c243b@email.android.com> In-Reply-To: <4ce8ca5e-1deb-4a2f-aa3f-d31f7e1c243b@email.android.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-spf-reporting-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, 25 Jan 2012 23:34:44 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, January 25, 2012 3:33 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt >=20 > It occurs to me that maybe the [DSN] reference could be informative > now. Once I'm in front of my computer again I'll look at it and check > if that's the only place it comes up. It is so in dkim-reporting already. From derek.diget+marf@wmich.edu Wed Jan 25 15:54:51 2012 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 5D34D21F852A for ; Wed, 25 Jan 2012 15:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 u8Ob4xQoazin for ; Wed, 25 Jan 2012 15:54:50 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id A06CC21F8525 for ; Wed, 25 Jan 2012 15:54:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LYD000P7P385N40@mta01.service.private> for marf@ietf.org; Wed, 25 Jan 2012 18:54:45 -0500 (EST) X-WMU-Spam: Gauge=X, Probability=10% on Wed Jan 25 18:54:45 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.25.234514 - Wed Jan 25 18:54:44 2012 Date: Wed, 25 Jan 2012 18:54:44 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: marf@ietf.org In-reply-to: <1376842.rDsXOy1W6A@scott-latitude-e6320> Message-id: References: <20120124153217.13513.81965.idtracker@ietfa.amsl.com> <4628741.jAfMZy1Lx3@scott-latitude-e6320> <1376842.rDsXOy1W6A@scott-latitude-e6320> Subject: Re: [marf] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 25 Jan 2012 23:54:51 -0000 On Jan 25, 2012 at 17:17 -0500, Scott Kitterman wrote: =>On Wednesday, January 25, 2012 05:12:56 PM Derek Diget wrote: =>> On Jan 24, 2012 at 10:36 -0500, Scott Kitterman wrote: =>> =>* Updated the r= definition to only use localparts and append the SPF =>> domain. =>> =>> How will this work for sites that publish "null" SPF records =>> ()? =>> =>> By publishing a "null" SPF record the domain part is not suppose to be =>> used for email. But if the site wanted to get reports for attempts to =>> use that domain, how would they? Sending to =>> @ won't work. => =>You are confusing sending and receiving. Nothing says such domains don't =>receive mail. Ok, I might have misspoken when I wrote "the domain part is not suppose to be used for email." The FAQ says "Publishing "v=spf1 -all" says that a domain sends no mail." Ok, got the "sending" part. So, no legitimate mail is sent using that domain. How does the domain owner receive reports of others trying to use the domain to send mail? If the domain owner has said via the SPF record that the domain doesn't send mail, I would be highly surprised if the domain owner has configured anything to accept mail at that domain. They are publishing the SPF record so that if somebody else wanted to send mail using that domain, it would receive a SPF fail versus getting the SPF none result if they didn't have the record. Again if a domain owner publishes a SPF record of www.example.com "v=spf1 -all -r=postmaster" How do they get reports of sending (forgery) attempts using MAIL FROM: sent to them? Do they have to put a MX record on www.example.com and configure their mail server to accept mail for that domain? (I sure hope not.) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From johnl@iecc.com Wed Jan 25 16:07:14 2012 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 6E0DF21F84B9 for ; Wed, 25 Jan 2012 16:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.241 X-Spam-Level: X-Spam-Status: No, score=-109.241 tagged_above=-999 required=5 tests=[AWL=1.958, 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 8D5Gia2rRBns for ; Wed, 25 Jan 2012 16:07:14 -0800 (PST) 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 D359D21F84B8 for ; Wed, 25 Jan 2012 16:07:13 -0800 (PST) Received: (qmail 5276 invoked from network); 26 Jan 2012 00:07:13 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Jan 2012 00:07:13 -0000 Date: 26 Jan 2012 00:06:51 -0000 Message-ID: <20120126000651.60565.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] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 26 Jan 2012 00:07:14 -0000 >How does the domain owner receive reports of others trying to use the >domain to send mail? If the domain owner has said via the SPF record >that the domain doesn't send mail, I would be highly surprised if the >domain owner has configured anything to accept mail at that domain. If he wants to get the reports, he'd better. R's, John From msk@cloudmark.com Wed Jan 25 16:08:38 2012 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 1F58D21F85CC for ; Wed, 25 Jan 2012 16:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAWEZfGfW64h for ; Wed, 25 Jan 2012 16:08:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D821F855A for ; Wed, 25 Jan 2012 16:08:37 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 16:08:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 16:08:37 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 16:08:35 -0800 Thread-Topic: [marf] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-03.txt} Thread-Index: Aczbvnm9IH4BfgVMTr6o5VyrQ2BNOwAACBwg Message-ID: References: <20120126000651.60565.qmail@joyce.lan> In-Reply-To: <20120126000651.60565.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 26 Jan 2012 00:08:38 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn Levine > Sent: Wednesday, January 25, 2012 4:07 PM > To: marf@ietf.org > Subject: Re: [marf] r=3D using localpart - WAS: {Re: I-D Action: draft-ie= tf-marf-spf-reporting-03.txt} >=20 > >How does the domain owner receive reports of others trying to use the > >domain to send mail? If the domain owner has said via the SPF record > >that the domain doesn't send mail, I would be highly surprised if the > >domain owner has configured anything to accept mail at that domain. >=20 > If he wants to get the reports, he'd better. Do we need to call out this (somewhat obvious) situation in the draft? From sklist@kitterman.com Wed Jan 25 16:26:48 2012 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 BC3BB11E80A1 for ; Wed, 25 Jan 2012 16:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 VOchr0LIeO2D for ; Wed, 25 Jan 2012 16:26:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C42211E8097 for ; Wed, 25 Jan 2012 16:26:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5BAD320E40DA; Wed, 25 Jan 2012 19:26:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327537607; bh=yb/W1u+F7ZYlKPH9jJtbYVLSaYBEoJFoNRTph4O+DCw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ETmXuYthHkqhFXfYA+my92HvwWpDD7jomrRTukR8wgDz11fLXbzg5OjlUZkT4D8dn 3cj6EKsPFEcEeIbnHHuw6Wvag8DlMmEsMKRjhKg9SmlRI4+SGDbJuVcutV1YMaZxO3 xMuMTLQMbZ2+VY9qXOyGYVqMUtxwjM+jsgsK6m0k= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3D40520E4081; Wed, 25 Jan 2012 19:26:47 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 19:26:46 -0500 Message-ID: <5012163.72uYFOBuHy@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124212849.4290.qmail@joyce.lan> <4ce8ca5e-1deb-4a2f-aa3f-d31f7e1c243b@email.android.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] I-D Action: draft-ietf-marf-spf-reporting-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, 26 Jan 2012 00:26:48 -0000 On Wednesday, January 25, 2012 03:34:41 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, January 25, 2012 3:33 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-03.txt > > > > It occurs to me that maybe the [DSN] reference could be informative > > now. Once I'm in front of my computer again I'll look at it and check > > if that's the only place it comes up. > > It is so in dkim-reporting already. It turns out it is in spf-reporting already as well. I've updated my local copy with the new language. Scott K From sklist@kitterman.com Wed Jan 25 16:28:33 2012 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 E28AF11E80B4 for ; Wed, 25 Jan 2012 16:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 CN2hVkPeLlKy for ; Wed, 25 Jan 2012 16:28:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6C32211E8097 for ; Wed, 25 Jan 2012 16:28:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 04CA320E40DA; Wed, 25 Jan 2012 19:28:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327537713; bh=ywuRDP4kQx9g6viZy5GVU6Ni5neW2psNAgvR5kWm7f0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=aOixJmgAgSHVFtvpXf2aHyD6208BakhMClUYWdlX9oxUvUjKsnMmL7CzimYKvJUIf 5F+TlYLegWiN63ruVAzoQ6kAsFYeS1yk7aN1qqX4d2vgnRvF//JCNtlZ7hUUr3v2W7 QXKNiueNi/P8AldqgOebpMohrfRNDf6hdpqVNgto= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DAD0B20E4081; Wed, 25 Jan 2012 19:28:32 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 19:28:32 -0500 Message-ID: <2952671.6CruZRtEId@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120126000651.60565.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] r= using localpart - WAS: {Re: I-D Action: draft-ietf-marf-spf-reporting-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, 26 Jan 2012 00:28:34 -0000 On Wednesday, January 25, 2012 04:08:35 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > John Levine Sent: Wednesday, January 25, 2012 4:07 PM > > To: marf@ietf.org > > Subject: Re: [marf] r= using localpart - WAS: {Re: I-D Action: > > draft-ietf-marf-spf-reporting-03.txt}> > > >How does the domain owner receive reports of others trying to use the > > >domain to send mail? If the domain owner has said via the SPF record > > >that the domain doesn't send mail, I would be highly surprised if the > > >domain owner has configured anything to accept mail at that domain. > > > > If he wants to get the reports, he'd better. > > Do we need to call out this (somewhat obvious) situation in the draft? I hope we don't need to say that if you ask for reports you aren't going to get them unless you configure your system to accept them. Scott K From internet-drafts@ietf.org Wed Jan 25 18:03:01 2012 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 07CEF5E8008; Wed, 25 Jan 2012 18:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 VMog7GUgdglJ; Wed, 25 Jan 2012 18:02:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E432C21F84BF; Wed, 25 Jan 2012 18:02:36 -0800 (PST) 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.64p1 Message-ID: <20120126020236.25522.70860.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 18:02:36 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 02:03:01 -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-04.txt Pages : 15 Date : 2012-01-25 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-04.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-04.txt From sklist@kitterman.com Wed Jan 25 18:05:13 2012 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 E9C955E8001 for ; Wed, 25 Jan 2012 18:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 o49YXoImPfcG for ; Wed, 25 Jan 2012 18:05:12 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B72C21F84D4 for ; Wed, 25 Jan 2012 18:05:12 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0D86220E40DA; Wed, 25 Jan 2012 21:05:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327543512; bh=IuzaIrj9uLGeaYc3iTeJTnFj1ePEwAqzMhbwy5ptor0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=awWA6mY+FuDRghAGMskZiAmxJFCjRMqkndWVg7fEc+Mf5Lc3Cdw98I8YrfnETyV7x dBUbZJ03nar1dd7KJM1QyMv8QAXSUrhiaKvNYa8k5MD3LkFNihy9NepXlq8TpKZZa3 A3nqB5q925pfJFVW/PM+0MRWxj8WY3NDjQQxon7A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D36BA20E4081; Wed, 25 Jan 2012 21:05:11 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 25 Jan 2012 21:05:11 -0500 Message-ID: <1590558.CFgYyEczsY@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120126020236.25522.70860.idtracker@ietfa.amsl.com> References: <20120126020236.25522.70860.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] I-D Action: draft-ietf-marf-spf-reporting-04.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 02:05:14 -0000 On Wednesday, January 25, 2012 06:02:36 PM 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-04.txt > Pages : 15 > Date : 2012-01-25 > > 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. Another day, another draft ... New in this version: * Updated Envelope Sender Selection text from WG mail list. * Switch ABNF ASCII designation styles to match DKIM draft. * Change r= tag to ra= to match the DKIM draft. * Delete obsolete reference to previously removed rf= modifier in r= definition. Scott K From internet-drafts@ietf.org Wed Jan 25 21:18:29 2012 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 D961F11E80CD; Wed, 25 Jan 2012 21:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 h-an7dwB4PQT; Wed, 25 Jan 2012 21:18:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7E321F8483; Wed, 25 Jan 2012 21:18:12 -0800 (PST) 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.64p1 Message-ID: <20120126051812.5342.92984.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 21:18:12 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-06.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, 26 Jan 2012 05:18: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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-06.txt Pages : 22 Date : 2012-01-25 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-06.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-dkim-reporting-06.txt From msk@cloudmark.com Wed Jan 25 21:22:38 2012 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 F192421F8522 for ; Wed, 25 Jan 2012 21:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMDYUy33n6zV for ; Wed, 25 Jan 2012 21:22:36 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CA34321F84B2 for ; Wed, 25 Jan 2012 21:22:27 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 21:22:27 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 21:22:27 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 21:22:26 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-06.txt Thread-Index: Aczb6fd3L16e6gunQR2PsXbeh1IuzAAAFcZw Message-ID: References: <20120126051812.5342.92984.idtracker@ietfa.amsl.com> In-Reply-To: <20120126051812.5342.92984.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-06.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, 26 Jan 2012 05:22:38 -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: Wednesday, January 25, 2012 9:18 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-dkim-reporting-06.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 : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-06.txt > Pages : 22 > Date : 2012-01-25 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Reflecting similar changes to the SPF draft: - update ABNF to simpler string syntax - improved envelope sender specification - add normative SPF reference -MSK From msk@cloudmark.com Wed Jan 25 22:06:43 2012 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 131C621F8600 for ; Wed, 25 Jan 2012 22:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZeOLTgdBbQN for ; Wed, 25 Jan 2012 22:06:42 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B60521F85FF for ; Wed, 25 Jan 2012 22:06:41 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 22:06:41 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 22:06:41 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 22:06:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-02.txt Thread-Index: AczGJsrGU0tyjk+ZRAyj+ccVZYOiDQVxNqeQ Message-ID: References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> In-Reply-To: <4EFC5F35.8020805@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] I-D Action: draft-ietf-marf-as-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: Thu, 26 Jan 2012 06:06:43 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, December 29, 2011 4:38 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt >=20 > Sections 6 and 7 are dedicated to solicited feedback. However, there > is a number of points that should be valid also for unsolicited > reports. If the order is not important, the common points could be put > in a common section. Specifically, for the sending part, Section 6, > here's the points I think should be common and why: > [...] It doesn't seem to me the document is improved any by common factoring poin= ts out of those two sections into one that's common for both. Your comment does point out, however, that Section 8 should include a set o= f numbered "rules" as Sections 6 and 7 are; there's no reason for them to b= e inconsistent. So I'll do that. > 1. End-users report to mailbox providers, they shouldn't go > searching whois databases and similar stuff. This point is > partially repeated already in Section 8, where it says that > sending criteria "might include direct complaint submissions > from MUAs". Using ARF for MUA-to-MP is not discussed. I think "direct complaint submissions" in this context means that an unsoli= cited report is triggered by MUA action, not that the MUA complains directl= y to something found in a WHOIS database. I'll adjust the wording. > 2. Reports can be used to instruct filters. Section 3.1 of RFC6449 makes a vague allusion to this idea. I don't think = this AS needs to re-state it, unless that's known to be a popular use of fe= edback reports. > 4. "Feedback-Type: abuse" is fine for unsolicited reports too. Copied. > 5. Ditto for other optional fields. Copied. > By contrast, points (3) and (6) cover solicited-specific stuff. >=20 > For the receiving part, Section 7, the points are: >=20 > 2. ARF over SMTP is fine for unsolicited feedback too. It doesn't strike me as reasonable to talk about receiving syntax and proto= col requirements for the case where the feedback is unsolicited. We'd basi= cally be forcing processing requirements on a non-participant. > 5. Optional fields may vary in unsolicited feedback too. Same deal; if they're not participating, that advice falls on deaf ears. F= or the unsolicited case, we really can only speak to the sender. > * Neither the RFC nor the draft mention degrading the offending IP's > profile at the firewall. Does it need to? As I said above, Section 3.1 of RFC6449 talks about filte= ring resulting from complaints but doesn't say what kind of filtering. > * The RFC says replying to feedback is useless. For unsolicited > feedback, especially the first times it's being sent, some sort of > acknowledge may be meaningful. I think that's a reasonable suggestion. I'll add something for -04. > * Both senders and receivers should keep a database of contacts and > annotate it regularly. The draft only mentions such operations for > the solicited case, referring to Section 4.4 of the RFC --point (3). I think that's a MAY at best, but I'll see if I can work that in to the pre= vious point as well. > For Section 8, unsolicited complaints, the second paragraph needs to > clarify that "Senders" means "mailbox providers who are forwarding > their users' complaints". We are not stopping end-users from reporting > to whoever they like, e.g. SpamCop, are we? I'll change it to "report generators". > This WG already agreed that ARF messages are automated and the human- > readable part is boilerplate. Conversely, technical data for an abuse > team has to be sent in non-ARF messages unless it can fit into the > provided ARF fields. This concept needs to be stated, though. > The beginning of the third paragraph of Section 8 can be changed so as > to read like so: >=20 > Recipients of unsolicited ARF reports SHOULD, in general, handle them > the same way as any other abuse reports. However, they can take > advantage of the ARF format to automate processing. Lacking [etc.] OK. > The converse can be put in the beginning of the last paragraph of > Section 8, e.g. like so: >=20 > Published abuse-mailbox addresses SHOULD NOT reject non-ARF messages, > because producing ARF messages may occasionally be unavailable or not- > applicable. Nevertheless some large messaging service providers > specifically request that [etc.] OK. > Finally, I propose to add the following paragraphs to the Security > Considerations section: There's a common practice in IETF documents to avoid putting normative stuf= f in Security Considerations, which is supposed to be strictly informative.= Not all documents follow this practice, but I prefer it. That said: > Mailbox Providers SHOULD perform any possible checks to ascertain > that the messages reported by their users, that they are about to > report in turn, really originated at the domain they intend to forward > it to. This includes checking that the reporting user did not > inadvertently or maliciously alter the reported message. Mailbox > Providers MAY digitally sign received messages on delivery in order to > perform this check. That seems reasonable. > Mailbox Providers SHOULD manually inspect the messages reported by > their users if their spam score is noticeably low --which might > indicate that the user hit the spam-button by mistake. Do users have spam scores? I don't know that that's a known implementation= . We'd need to flesh this out quite a bit more for it to fly. > Mailbox Providers should evaluate the trustworthiness of the target > abuse team, possibly using external reputation providers. It is not > worth to send any information to domains that exist for the sole > purpose of spamming. Mailbox Providers MAY redact the reported > message, according to its policy and to the reputation of the > destination. Redacting techniques are discussed in [REDACT]. I think this is best added to the section on unsolicited reports, actually. > The obvious correction for an acknowledged policy contravention is to > remove the email address of the original recipient from whatever > storage it was retrieved from for sending the reported message, > including mailing lists. An abuse team may need to investigate > whether email addresses are stored legitimately on their customer's > systems, or if any malware is running there. I think this is already covered in general in RFC6449, to which the applica= bility statement draft refers. Thanks, I'll go through the replies to this and prepare a new version. -MSK From msk@cloudmark.com Wed Jan 25 22:08:54 2012 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 16F7621F861E for ; Wed, 25 Jan 2012 22:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8hDsruEuf0i for ; Wed, 25 Jan 2012 22:08:53 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AE3FF21F85B9 for ; Wed, 25 Jan 2012 22:08:53 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 22:08:53 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 22:08:53 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 22:08:52 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-02.txt Thread-Index: AczK5Nf2Sh0qaPLNRKGxkrY8OMJsSARC/EtA Message-ID: References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> <4EFC5F35.8020805@tana.it> <6.2.5.6.2.20120103113844.0b840708@resistor.net> <4F04540B.8070200@tana.it> In-Reply-To: <4F04540B.8070200@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] I-D Action: draft-ietf-marf-as-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: Thu, 26 Jan 2012 06:08:54 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, January 04, 2012 5:29 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt >=20 > Moving the paragraphs from those numbered lists would alter their > numeration. > Personally, I don't like them to be numbered, since the numbers bear > no special meaning. The subcompact feature worsens their appearance by > suggesting some sort of indivisibility. I tend to associate that style > with some (mis)conceptions about ASes, and IMHO is unnecessary. I think the numbered bullets help insofar as it makes them easier to refere= nce; e.g. "Section X, bullet Y of RFC Z" versus "in Section X of RFC Z, the= Yth bullet down". It's a minor point, however. -MSK From internet-drafts@ietf.org Wed Jan 25 22:15:01 2012 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 6054F11E80E8; Wed, 25 Jan 2012 22:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 IiVwMMHL3lF0; Wed, 25 Jan 2012 22:15:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0111E80B7; Wed, 25 Jan 2012 22:15:00 -0800 (PST) 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.64p1 Message-ID: <20120126061500.20272.40574.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2012 22:15:00 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-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: Thu, 26 Jan 2012 06:15:01 -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 : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-04.txt Pages : 9 Date : 2012-01-25 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-04.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-as-04.txt From msk@cloudmark.com Wed Jan 25 22:17:00 2012 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 DF2D35E8002 for ; Wed, 25 Jan 2012 22:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVzKWpTPXOOq for ; Wed, 25 Jan 2012 22:16:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C5B475E8001 for ; Wed, 25 Jan 2012 22:16:59 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 22:16:59 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 22:16:59 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 25 Jan 2012 22:16:58 -0800 Thread-Topic: I-D Action: draft-ietf-marf-as-04.txt Thread-Index: Aczb8d34ewBKZOIRRvGx4yAPq8VgLAAACOiQ Message-ID: References: <20120126061500.20272.40574.idtracker@ietfa.amsl.com> In-Reply-To: <20120126061500.20272.40574.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-as-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: Thu, 26 Jan 2012 06:17:01 -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: Wednesday, January 25, 2012 10:15 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-as-04.txt >=20 >=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 : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-04.txt > Pages : 9 > Date : 2012-01-25 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. I'm caught up on the feedback for this, I think. Please review the latest = version and provide commentary. The diffs are viewable through the datatra= cker's "History" tab. -MSK From msk@cloudmark.com Wed Jan 25 22:24:41 2012 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 2898521F8617 for ; Wed, 25 Jan 2012 22:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 iPV-blAs3iG6 for ; Wed, 25 Jan 2012 22:24:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CECB321F8616 for ; Wed, 25 Jan 2012 22:24:37 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 22:24:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 25 Jan 2012 22:24:37 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 25 Jan 2012 22:24:36 -0800 Thread-Topic: Where we go from here Thread-Index: AczZkwaa8t8LLue5RXSNvE2Y0lXUGwCX3b6g 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: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7D9D1EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Where we go from here 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, 26 Jan 2012 06:24:41 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7D9D1EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, if we'd known that threatening to shut the working group down soon wo= uld've sparked all this interest and activity, we could've done it sooner! This is good stuff. All three remaining documents have recently taken big = steps toward being ready for advancement. We have requested a one-hour meeting for the IETF meeting in Paris at the e= nd of March. Ideally, we would meet there to discuss the progress of these= three documents through the formal parts of evaluation and processing, and= then spin down shortly thereafter, a job well done. That means IETF Last = Call will need to start by early March at the latest, so Working Group Last= Calls need to start by mid-February at the latest. With the recent moment= um, I think we can hit those marks. Everyone, please take a run through all three drafts (draft-ietf-marf-as, d= raft-ietf-marf-dkim-reporting, draft-ietf-marf-spf-reporting) top-to-bottom= and report any feedback, including "I looked at this, I agree with it, let= 's move forward" or suchlike. Once all three of them look to be on solid g= round, we can start the various Last Call processes. Thanks, -MSK, as co-chair From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Sunday, January 22, 2012 9:51 PM To: Message Abuse Report Format working group Subject: [marf] Where we go from here With the imminent approval of the redaction draft, we are left with four cu= rrent documents. As we appear to be low on remaining steam, we need to dec= ide what to do with them. Barry and I are thinking that the working group = will meet in Paris at the end of March to tie up loose ends, and come in fo= r a landing shortly thereafter. What's below is my own current opinion on our documents, having observed th= e working group's current interest levels, consulting with Barry and Pete, = and knowing about other related IETF activity. 1) draft-ietf-marf-as ("Creation and Use of Email Feedback Reports: An Appl= icability Statement for the Abuse Reporting Format (ARF)") I believe this document is useful and possibly even important to get out th= ere. It's also the one closest to earning the labels "well-developed" and = "has consensus". We have some feedback on the current version that the wor= king group needs to process, and I hope we can do that in the coming few we= eks. I will also solicit a few more reviewers from outside MARF but within= the realm of abuse reporting and applicability statements. After that, I = think a Working Group Last Call would be in order, and then we can send it = to the IESG. 2) draft-ietf-marf-dkim-reporting ("Extensions to DKIM for Failure Reportin= g") Although the protocol specified here has been implemented in open source fo= r several years, there has been significant feedback within MARF on some po= ssible better ways to do it. I don't think the working group has the energ= y to invest in re-hashing it from the ground up and producing something wor= thy of the standards track that would then expect some widespread deploymen= t. Instead, I propose that this one be "parked", and eventually returned t= o "Individual" status and progressed outside of the working group, or perha= ps through APPSAWG if there's interest there, perhaps seeking Experimental = status. 3) draft-ietf-marf-spf-reporting ("SPF Authentication Failure Reporting usi= ng the Abuse Report Format") The feedback on the DKIM reporting draft makes me wonder if this one needs = to be revisited with a similar bent. Regardless, there will likely be more= energy for processing this one in the proposed "spfbis" working group rath= er than in MARF, so I suggest it be "parked", and if and when spfbis charte= rs (or re-charters) to take this on, it can pick up the work item. 4) draft-ietf-marf-reporting-discovery ("A DNS TXT Record for Advertising a= nd Discovering Willingness to Provide or Receive ARF Reports") This draft doesn't have a current champion. It also describes a protocol t= hat is not in any known open use, nor have we heard from anyone who plans t= o implement it. It's based on a proprietary protocol whose owner was seeki= ng to move it into open use, but currently doesn't have personnel to dedica= te to its advancement. I know there is a small amount of interest in MARF = to see this progress, but it also needs some significant interest from indu= stry, and we've seen no evidence of that at all. Accordingly, it is now a = "parked" working group document. It will expire later this month. I don't= believe we should continue to work on it. Feedback welcome. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7D9D1EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, if we’d known that threatening to shut the workin= g group down soon would’ve sparked all this interest and activity, we= could’ve done it sooner!

<= span style=3D'color:#1F497D'> 

This is good stuff.  All three remain= ing documents have recently taken big steps toward being ready for advancem= ent.


We have requested a one-hour meeting for the IETF meeting in Paris at= the end of March.  Ideally, we would meet there to discuss the progre= ss of these three documents through the formal parts of evaluation and proc= essing, and then spin down shortly thereafter, a job well done.  That = means IETF Last Call will need to start by early March at the latest, so Wo= rking Group Last Calls need to start by mid-February at the latest.  W= ith the recent momentum, I think we can hit those marks.<= /p>

 

Everyone, please = take a run through all three drafts (draft-ietf-marf-as, draft-ietf-marf-dk= im-reporting, draft-ietf-marf-spf-reporting) top-to-bottom and report any f= eedback, including “I looked at this, I agree with it, let’s mo= ve forward” or suchlike.  Once all three of them look to be on s= olid ground, we can start the various Last Call processes.


Thanks,

-MSK, as c= o-chair

 

= From:= marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Sunday, January 22, 2012 9:51 PM
<= b>To: Message Abuse Report Format working group
Subject: [mar= f] Where we go from here

 

With the imminent approval of= the redaction draft, we are left with four current documents.  As we = appear to be low on remaining steam, we need to decide what to do with them= .  Barry and I are thinking that the working group will meet in Paris = at the end of March to tie up loose ends, and come in for a landing shortly= thereafter.

    &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;       

What’s below is my own current opinion on our documents, havin= g observed the working group’s current interest levels, consulting wi= th Barry and Pete, and knowing about other related IETF activity.

 

1) draf= t-ietf-marf-as (“Creation and Use of Email Feedback Reports: An Appli= cability Statement for the Abuse Reporting Format (ARF)”)<= /p>


I believe this document is useful and possibly = even important to get out there.  It’s also the one closest to e= arning the labels “well-developed” and “has consensusR= 21;.  We have some feedback on the current version that the working gr= oup needs to process, and I hope we can do that in the coming few weeks.&nb= sp; I will also solicit a few more reviewers from outside MARF but within t= he realm of abuse reporting and applicability statements.  After that,= I think a Working Group Last Call would be in order, and then we can send = it to the IESG.

 

2) draft-ietf-marf-dkim-reporting (“Extensions to D= KIM for Failure Reporting”)

&= nbsp;

Although the protocol specified here ha= s been implemented in open source for several years, there has been signifi= cant feedback within MARF on some possible better ways to do it.  I do= n’t think the working group has the energy to invest in re-hashing it= from the ground up and producing something worthy of the standards track t= hat would then expect some widespread deployment.  Instead, I propose = that this one be “parked”, and eventually returned to “In= dividual” status and progressed outside of the working group, or perh= aps through APPSAWG if there’s interest there, perhaps seeking Experi= mental status.

 

3) draft-ietf-marf-spf-reporting (“SPF Authenticatio= n Failure Reporting using the Abuse Report Format”)

 

The feedback on= the DKIM reporting draft makes me wonder if this one needs to be revisited= with a similar bent.  Regardless, there will likely be more energy fo= r processing this one in the proposed “spfbis” working group ra= ther than in MARF, so I suggest it be “parked”, and if and when= spfbis charters (or re-charters) to take this on, it can pick up the work = item.

 

4) draft-ietf-marf-reporting-discovery (“A DNS TXT Record for= Advertising and Discovering Willingness to Provide or Receive ARF Reports&= #8221;)

 

This draft doesn’t have a current champion.  It also d= escribes a protocol that is not in any known open use, nor have we heard fr= om anyone who plans to implement it.  It’s based on a proprietar= y protocol whose owner was seeking to move it into open use, but currently = doesn’t have personnel to dedicate to its advancement.  I know t= here is a small amount of interest in MARF to see this progress, but it als= o needs some significant interest from industry, and we’ve seen no ev= idence of that at all.  Accordingly, it is now a “parked” = working group document.  It will expire later this month.  I don&= #8217;t believe we should continue to work on it.

 

Feedback welcome.<= /o:p>

 

-MS= K

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7D9D1EXCHC2corpclo_-- From shmuel+gen@patriot.net Thu Jan 26 07:20:09 2012 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 80BEA21F8629 for ; Thu, 26 Jan 2012 07:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 l-xXlflCxoP9 for ; Thu, 26 Jan 2012 07:20:08 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 820C321F8620 for ; Thu, 26 Jan 2012 07:20:08 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.120]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 0A270F58096 for ; Thu, 26 Jan 2012 10:05:55 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 26 Jan 2012 10:20:14 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120126150556.0A270F58096@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.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, 26 Jan 2012 15:20:09 -0000 In , on 01/25/2012 at 10:06 PM, "Murray S. Kucherawy" said: >> 1. End-users report to mailbox providers, they shouldn't go >> searching whois databases and similar stuff. This point is >> partially repeated already in Section 8, where it says that >> sending criteria "might include direct complaint submissions >> from MUAs". Using ARF for MUA-to-MP is not discussed. >I think "direct complaint submissions" in this context means that an >unsolicited report is triggered by MUA action, not that the MUA >complains directly to something found in a WHOIS database. I'll >adjust the wording. I thought that the wording was clear[1], since the provider would hardly be forwarding reports not sent to it. However, I don't agree that the end users shouldn't send reports to addresses located in whois, only that it needs to be done carefully. [1] Which doesn't preclude rewording it if that helps other readers. -- 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 barryleiba.mailing.lists@gmail.com Thu Jan 26 21:37:06 2012 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 DFE9111E808D for ; Thu, 26 Jan 2012 21:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sj9v4WKPzk4w for ; Thu, 26 Jan 2012 21:37:06 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21AF211E808C for ; Thu, 26 Jan 2012 21:37:05 -0800 (PST) Received: by ghbg16 with SMTP id g16so699151ghb.31 for ; Thu, 26 Jan 2012 21:37:05 -0800 (PST) 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:cc:content-type; bh=eiw7r6M/PVKiI5CvI7rYUBF6MQfqLJoDyvo/wZTwavg=; b=DFR+OyIH8VMOMmx0HFJIxM/AwM15vOTleBJyH6xnTM2kM1jdhxywWQS8oKWMaVSGQ1 5pWzfhUVHRc9u9Syjbnr4K2mXZ/FVOqJg2tYoZCQUXrNEC/Dpa9ddW4xk857Rq9EzX+S zonpPC9UwU8pykjoeEpOvr2qUqGBUgeE2b0RI= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr7780524yhh.23.1327642625648; Thu, 26 Jan 2012 21:37:05 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Thu, 26 Jan 2012 21:37:05 -0800 (PST) In-Reply-To: References: <20120124174407.22910.76562.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 00:37:05 -0500 X-Google-Sender-Auth: SSnLclbDFQfVYGR3HFi_39NPKsU Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf300e562517260e04b77be3a8 Cc: "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 05:37:07 -0000 --20cf300e562517260e04b77be3a8 Content-Type: text/plain; charset=ISO-8859-1 > The DISCUSS was cleared this morning. This version includes the changes > based on Alessandro's suggestions, per recent consensus support. We hope > this is the final version. We'll ping Pete to approve this one on Friday if there > hasn't been any squawking. In case Murray's note wasn't clear on this: We do want some folks to give -07 a final review and make sure that the changes since WG approval are still acceptable. We think the document is now a better one than what we sent to the IESG before. Let's get some confirmation on that, please. Pete is considering, based on IESG feedback, whether or not to issue a second IETF Last Call on the document, similarly to re-confirm consensus after the changes. It's an interesting discussion as to how much may change *after* a document is approved by the community, and before it goes to the RFC Editor. We don't know yet what Pete will do, but even a new Last Call will likely only delay the document by two weeks. Barry --20cf300e562517260e04b77be3a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The DISCUSS was cleared this morning. =A0This version includes the cha= nges
> based on Alessandro's suggestions, per recent consensus su= pport. =A0We hope
> this is the final version. =A0We'll ping Pete= to approve this one on Friday if there
> hasn't been any squawking.

In case Murray's note wasn&#= 39;t clear on this:
We do want some folks to give -07 a final review and= make sure that the changes since WG approval are still acceptable. =A0We t= hink the document is now a better one than what we sent to the IESG before.= =A0Let's get some confirmation on that, please.

Pete is considering, based on IESG feedback, whether or not to issue a = second IETF Last Call on the document, similarly to re-confirm consensus af= ter the changes. =A0It's an interesting discussion as to how much may c= hange *after* a document is approved by the community, and before it goes t= o the RFC Editor. =A0We don't know yet what Pete will do, but even a ne= w Last Call will likely only delay the document by two weeks.

Barry --20cf300e562517260e04b77be3a8-- From msk@cloudmark.com Thu Jan 26 22:37:55 2012 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 2ECF821F853C for ; Thu, 26 Jan 2012 22:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 a6bj2Vquld0T for ; Thu, 26 Jan 2012 22:37:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AA21F853B for ; Thu, 26 Jan 2012 22:37:54 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 22:37:53 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 26 Jan 2012 22:37:53 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 26 Jan 2012 22:37:53 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-redaction-07.txt Thread-Index: AczctbUBUB+KmrYZRH6lUyjpLNYlqQACGYzg Message-ID: References: <20120124174407.22910.76562.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: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DA0DEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 06:37:55 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA0DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a point of clarification, this will actually be a third IETF Last Call= , after its state change from Informational to Proposed Standard. Whew. := ) From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Thursday, January 26, 2012 9:37 PM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.txt > The DISCUSS was cleared this morning. This version includes the changes > based on Alessandro's suggestions, per recent consensus support. We hope > this is the final version. We'll ping Pete to approve this one on Friday= if there > hasn't been any squawking. In case Murray's note wasn't clear on this: We do want some folks to give -07 a final review and make sure that the cha= nges since WG approval are still acceptable. We think the document is now = a better one than what we sent to the IESG before. Let's get some confirma= tion on that, please. Pete is considering, based on IESG feedback, whether or not to issue a seco= nd IETF Last Call on the document, similarly to re-confirm consensus after = the changes. It's an interesting discussion as to how much may change *aft= er* a document is approved by the community, and before it goes to the RFC = Editor. We don't know yet what Pete will do, but even a new Last Call will= likely only delay the document by two weeks. Barry --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA0DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a po= int of clarification, this will actually be a third IETF Last Call, after i= ts state change from Informational to Proposed Standard.  Whew.  = J

&nbs= p;

From: barryleiba= .mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com] On = Behalf Of Barry Leiba
Sent: Thursday, January 26, 2012 9:37 P= M
To: Murray S. Kucherawy
Cc: marf@ietf.org
Subje= ct: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.txt<= /span>

 

> The DISCUSS was cleared this morning.  This version inc= ludes the changes
> based on Alessandro's suggestions, per recent con= sensus support.  We hope
> this is the final version.  We'l= l ping Pete to approve this one on Friday if there
> hasn't been any = squawking.

In case Murray's note wasn't clear on this:
We do want= some folks to give -07 a final review and make sure that the changes since= WG approval are still acceptable.  We think the document is now a bet= ter one than what we sent to the IESG before.  Let's get some confirma= tion on that, please.

Pete is considering, based on IESG feedback, w= hether or not to issue a second IETF Last Call on the document, similarly t= o re-confirm consensus after the changes.  It's an interesting discuss= ion as to how much may change *after* a document is approved by the communi= ty, and before it goes to the RFC Editor.  We don't know yet what Pete= will do, but even a new Last Call will likely only delay the document by t= wo weeks.

Barry

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA0DEXCHC2corpclo_-- From shmuel+gen@patriot.net Fri Jan 27 06:35:07 2012 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 EDD0621F85A8 for ; Fri, 27 Jan 2012 06:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 SEopsga0uNrB for ; Fri, 27 Jan 2012 06:35:07 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62121F859E for ; Fri, 27 Jan 2012 06:35:06 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.116]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id E2320F580A3 for ; Fri, 27 Jan 2012 09:20:51 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 27 Jan 2012 09:01:13 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120127142052.E2320F580A3@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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: Fri, 27 Jan 2012 14:35:08 -0000 In , on 01/27/2012 at 12:37 AM, Barry Leiba said: >We do want some folks to give -07 a final review and make sure that >the changes since WG approval are still acceptable. It looks good as long as it keeps the IESG happy. -- 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 barryleiba.mailing.lists@gmail.com Fri Jan 27 08:53:24 2012 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 17E7321F8638 for ; Fri, 27 Jan 2012 08:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=0.049, 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 N6SlCPv3p6U7 for ; Fri, 27 Jan 2012 08:53:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDEB721F863B for ; Fri, 27 Jan 2012 08:53:22 -0800 (PST) Received: by yenm3 with SMTP id m3so975498yen.31 for ; Fri, 27 Jan 2012 08:53:22 -0800 (PST) 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=t+BrnszQ/NFgh4g2KNnBaQiA/Gfs+x75qapJSRByL3M=; b=KCOKnGpMFCJdtdp1wczVbewqKvGCMESVzT2Bvd/1drbepRmTe49BvwJYvzzcGKkhbR ho6ez2jMhedL458RPSmSWLqj+rSlTHPMljqove2wkLvGpqNHIZDSeQuRm++BrfNbKczp WzomDbrLkGpoWLiz6N4Sp3wsC0j43jK+kA/88= MIME-Version: 1.0 Received: by 10.236.133.210 with SMTP id q58mr12056242yhi.6.1327683202468; Fri, 27 Jan 2012 08:53:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Fri, 27 Jan 2012 08:53:22 -0800 (PST) In-Reply-To: <20120127142052.E2320F580A3@smtp.patriot.net> References: <20120127142052.E2320F580A3@smtp.patriot.net> Date: Fri, 27 Jan 2012 11:53:22 -0500 X-Google-Sender-Auth: AsO6dzs82ipUAaf-qkU7iJaprg0 Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 16:53:24 -0000 On Fri, Jan 27, 2012 at 9:01 AM, Shmuel Metz wrote: >>We do want some folks to give -07 a final review and make sure that >>the changes since WG approval are still acceptable. > > It looks good as long as it keeps the IESG happy. I'm glad to see the first half of that sentence. Note that "keeping the IESG happy" is not what we're asking here. The main point is whether the WG thinks this document is (1) good, and (2) better than previous versions. If anyone thinks this version has made the document *worse*, we want to know that, regardless of whether the IESG is happy. Barry, in a very chairy mood today From sm@resistor.net Fri Jan 27 08:58:56 2012 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 6367421F8638 for ; Fri, 27 Jan 2012 08:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWhcYmtPow93 for ; Fri, 27 Jan 2012 08:58:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CEE21F8645 for ; Fri, 27 Jan 2012 08:58:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0RGwjdn006006; Fri, 27 Jan 2012 08:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327683530; i=@resistor.net; bh=BYvrgFz8BfL9GWQW90m4A+2f2WdyhqiUXxUfaxz5p/o=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=giQa3kbGyNVYqbrwHIUHb92VcwmI+Awa4yE0QOBbD/bpPn3c8OLp9p4+Op/rUZ1pR rOEoMSAce+E4jbdCXDidbRlNDomX1cf5wa8D22NZeBzW31bPVT95zphI4Z84guGzTF Uems3YAM7eqsVvZ1V19Ox6ykXkCyvZ1zPXHlTNnA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327683530; i=@resistor.net; bh=BYvrgFz8BfL9GWQW90m4A+2f2WdyhqiUXxUfaxz5p/o=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=j4OLkLbu6UjF7ROg2ipF+sb5lBRim5//bScomjRc9f1YjicJaBElqJ4ZupylBq2JZ KYyc02S7LoFIh7iXPMh0pNpx8/PNd7jsH6xT4obWSUg8c4WsL104I3fhDx6b2Agsg7 BA2PmL7/fa32OVl0+3YfubRe6G8oApCRzE3PREJ0= Message-Id: <6.2.5.6.2.20120127085658.09cb6828@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Jan 2012 08:58:14 -0800 To: Barry Leiba From: SM In-Reply-To: References: <20120127142052.E2320F580A3@smtp.patriot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 16:58:56 -0000 Hi Barry, At 08:53 27-01-2012, Barry Leiba wrote: >If anyone thinks this version has made the document *worse*, we want >to know that, regardless of whether the IESG is happy. The RFC 2119 boilerplate and reference is missing. Regards, -sm From barryleiba.mailing.lists@gmail.com Fri Jan 27 09:16:20 2012 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 6552F21F866E for ; Fri, 27 Jan 2012 09:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=0.048, 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 qN-0b-TCcUKq for ; Fri, 27 Jan 2012 09:16:20 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCCC321F8671 for ; Fri, 27 Jan 2012 09:16:19 -0800 (PST) Received: by yenm3 with SMTP id m3so990962yen.31 for ; Fri, 27 Jan 2012 09:16:19 -0800 (PST) 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=E3Ng8dsNfcaJltZ6XKHH6vkCXEptHoaf8uO0jY1r7ts=; b=t5HQPKAlaAQ3GonKV9sMp5s8SELKXKNikC7P/8OuFZ2vlARBfcukFjHLo4/6u1NGMi kZayZhtIxZrdhqEzM8xtT2/JTij1qEDW4IEBwO9kYEJoxtyEbQg2MCCXfn/eBNlGyUdZ mKeGgrh6qXKPa3IGgzKz04P8ZZ/YoTnw9Fx3w= MIME-Version: 1.0 Received: by 10.236.133.210 with SMTP id q58mr12221066yhi.6.1327684579496; Fri, 27 Jan 2012 09:16:19 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Fri, 27 Jan 2012 09:16:19 -0800 (PST) In-Reply-To: <6.2.5.6.2.20120127085658.09cb6828@resistor.net> References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@resistor.net> Date: Fri, 27 Jan 2012 12:16:19 -0500 X-Google-Sender-Auth: jwLSGG8yNR1AvW-FHskDv0ixoIo Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 17:16:20 -0000 > The RFC 2119 boilerplate and reference is missing. True: there's one SHOULD and one MAY in the document now. Barry From msk@cloudmark.com Fri Jan 27 09:42:36 2012 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 75A5E21F8518 for ; Fri, 27 Jan 2012 09:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 J+JB7Bx3mLtf for ; Fri, 27 Jan 2012 09:42:36 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD821F8526 for ; Fri, 27 Jan 2012 09:42:36 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 09:42:35 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 27 Jan 2012 09:42:35 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 27 Jan 2012 09:42:34 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-redaction-07.txt Thread-Index: AczdF2URpi2MWeEGQweBIofhbRq/xQAA5lcQ Message-ID: References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@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] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 17:42:36 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of B= arry Leiba > Sent: Friday, January 27, 2012 9:16 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.txt >=20 > > The RFC 2119 boilerplate and reference is missing. >=20 > True: there's one SHOULD and one MAY in the document now. &#%$! Fixed for -08. From msk@cloudmark.com Fri Jan 27 09:53:49 2012 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 31DA221F8664 for ; Fri, 27 Jan 2012 09:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 bt8m41ZMpZ+S for ; Fri, 27 Jan 2012 09:53:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBF21F8663 for ; Fri, 27 Jan 2012 09:53:48 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 09:53:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 27 Jan 2012 09:53:42 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 27 Jan 2012 09:53:41 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-redaction-07.txt Thread-Index: AczdFPbqBKbLIGjUTxWQefK3znutCwAB5Ljg Message-ID: References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@resistor.net> In-Reply-To: <6.2.5.6.2.20120127085658.09cb6828@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] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 17:53:49 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Friday, January 27, 2012 8:58 AM > To: Barry Leiba > Cc: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.txt >=20 > Hi Barry, > At 08:53 27-01-2012, Barry Leiba wrote: > >If anyone thinks this version has made the document *worse*, we want to > >know that, regardless of whether the IESG is happy. >=20 > The RFC 2119 boilerplate and reference is missing. For the record: Apart from that, you're happy with the changes since the DI= SCUSS? From sklist@kitterman.com Fri Jan 27 10:10:11 2012 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 634C521F85EA for ; Fri, 27 Jan 2012 10:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 rgdFk3B5geoB for ; Fri, 27 Jan 2012 10:10:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E073B21F85E0 for ; Fri, 27 Jan 2012 10:10:06 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 59BBB20E40EA; Fri, 27 Jan 2012 13:10:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327687804; bh=OvcP6VpzwbX05Kjq7zMqbF1soL+iddGALkZOMlgxRhE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Xc9kR6G5bWLcUIS/QywFmQGTDTHvU/hsEXxH4tlT1eWsXmJKzvUpZxbMjXHkZCFJi N1t4JsXfbh/eyQkGmYEOUQ+NFFpLOXUcw3eEO99wnS/u0qJUir71BaqdwXRdSneCp4 N9l1+O/IV4fSHLmCFGmsNYEMP5zVW7gWAonUQOEg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 38DB120E40DA; Fri, 27 Jan 2012 13:10:04 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 27 Jan 2012 13:10:03 -0500 Message-ID: <3919084.vv6A874rlI@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120124174407.22910.76562.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] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 18:10:11 -0000 On Tuesday, January 24, 2012 09:50:59 AM Murray S. Kucherawy wrote: ... > The DISCUSS was cleared this morning. This version includes the changes > based on Alessandro's suggestions, per recent consensus support. We hope > this is the final version. We'll ping Pete to approve this one on Friday > if there hasn't been any squawking. ... Modulo the RFC 2119 boilerplate issue, I think it's good. Scott K From dhc@dcrocker.net Fri Jan 27 10:27:16 2012 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 01C9421F84C4 for ; Fri, 27 Jan 2012 10:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 iugr4hK1CkLa for ; Fri, 27 Jan 2012 10:27:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7477121F84BD for ; Fri, 27 Jan 2012 10:27:15 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RIR92M012452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 10:27:15 -0800 Message-ID: <4F22EC78.1050704@dcrocker.net> Date: Fri, 27 Jan 2012 10:27:04 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 27 Jan 2012 10:27:15 -0800 (PST) Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 27 Jan 2012 18:27:16 -0000 On 1/27/2012 9:53 AM, Murray S. Kucherawy wrote: > For the record: Apart from that, you're happy with the changes since the DISCUSS? +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Fri Jan 27 10:40:27 2012 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 CC08521F861B for ; Fri, 27 Jan 2012 10:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.977 X-Spam-Level: X-Spam-Status: No, score=-107.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 Np0BWujU3QsQ for ; Fri, 27 Jan 2012 10:40:27 -0800 (PST) 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 C9C4A21F8618 for ; Fri, 27 Jan 2012 10:40:26 -0800 (PST) Received: (qmail 51965 invoked from network); 27 Jan 2012 18:40:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Jan 2012 18:40:25 -0000 Date: 27 Jan 2012 18:40:03 -0000 Message-ID: <20120127184003.73998.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [marf] draft-ietf-marf-redaction-07 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, 27 Jan 2012 18:40:27 -0000 This fixes a few nits and it sure looks done to me. Please ship it before someone else finds another nit to pick. R's, John From steve@wordtothewise.com Fri Jan 27 10:48:24 2012 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 E01D321F8637 for ; Fri, 27 Jan 2012 10:48:24 -0800 (PST) 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 kQgXD59n4iZN for ; Fri, 27 Jan 2012 10:48:24 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7121F861F for ; Fri, 27 Jan 2012 10:48:24 -0800 (PST) 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 EAE7D2DED3 for ; Fri, 27 Jan 2012 10:48:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <20120124174407.22910.76562.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 10:48:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <33A1C58E-F84F-4300-AB2B-6DD73BF7EBE9@wordtothewise.com> References: <20120124174407.22910.76562.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 18:48:25 -0000 On Jan 24, 2012, at 9:44 AM, Internet-Drafts@ietf.org wrote: >=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 : Redaction of Potentially Sensitive Data from = Mail Abuse Reports > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-redaction-07.txt > Pages : 8 > Date : 2012-01-24 Looks OK to me, modulo the trivial issues others have already mentioned. Cheers, Steve From vesely@tana.it Fri Jan 27 11:17:32 2012 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 346CB21F852A for ; Fri, 27 Jan 2012 11:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_40=-0.185, 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 IrZO6G6LnD1B for ; Fri, 27 Jan 2012 11:17:31 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4B21F8512 for ; Fri, 27 Jan 2012 11:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327691846; bh=uwrRmknSzqaUCehAUfUK9LyadnhrkPxD+pT7s1gBu48=; l=3650; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=O/bB+TcDim6xYBenvQG9SZyZBpKWxFfiCUY1+jzvTL8/WKMGRbr38UQdw7AtZHLio 9a7FXZ36JJJ4q233jmj3Vy3uFRLqZ5Q1E/R/5dmu9mkJkBr79wLetMcfVVLNEEZnI/ 2xyep5FHjiz0nL77N4sdiUCL5dH8ukSnohofEXgw= 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, 27 Jan 2012 20:17:26 +0100 id 00000000005DC045.000000004F22F846.00005B84 Message-ID: <4F22F846.1070709@tana.it> Date: Fri, 27 Jan 2012 20:17:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120126061500.20272.40574.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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: Fri, 27 Jan 2012 19:17:32 -0000 Hi Murray, version -04 looks nearly good for WGLC. Thank you so much! On 26/Jan/12 07:16, Murray S. Kucherawy wrote: > > I'm caught up on the feedback for this, I think. Please review the > latest version and provide commentary. Some points, nits, and ideas: *Updates 5965* It doesn't seem to actually update the format. If the use of ARF is meant to be updated, we probably need a section where that update is identified. *Section 5* The second part of the second paragraph ("Abuse addresses in WHOIS records [...]") covers a where-to-send question similar to the one answered by bullet 5 in Section 8. Would it be an improvement to have them near to one another? BTW, this method is also "not universally true", as the retrieved abuse mailbox can belong to a network provider who may or may not forward reports to the relevant mailbox provider or ESP. *Section 6* The text "Section 3.4 of that document" gets a wrong link in bullet 1 of http://tools.ietf.org/html/draft-ietf-marf-as-04#section-6 Repeating the same reference makes for a less appealing prose, but is easier to markup and search. *Section 7* In bullet 4, "That system" refers to the automated system considered in the previous bullet. It is unclear, now that that text has changed. Hints for rewording: bullets 4 and 5 apply to automated systems, so they might be further indented. Bullet 7 could also refer to Section 4.4 of [RFC6449], as it covers redaction. However, RFC 6449 treats that the same irrespectively of the redaction algorithm used. Should we say how to recognize and take advantage of /conforming/ redaction? *Section 8* Bullets 1 and 2 sound quite obscure, or maybe it's just me. As a minor improvement, maybe s/generating/reporting/? Bullet 3: s/service provider/mailbox provider/. Bullet 5: sounds good, but see previous comment for Section 5. Perhaps before bullet 9: do we want to mention that a network provider MAY use ARF data for automated forwarding of Feedback Messages to the originating customer, as described in the last paragraph of Section 4.4 of [RFC6449]? Bullet 11: kudos for that, great! Do we want to refer to Section 3.5 of [RFC6449] from there too? In particular, feedback providers who save the unsolicited reports they send (as they should) can provide a web page for the report at hand. That page would display all parts of the report --thereby solving the issue of bullet 10-- and also provide any FBL-related link that is mentioned in Section 3.5.1 of [RFC6449]. Would this be good? If we like it, we could summarize such approach by adding an example of unsolicited feedback in an appendix of this I-D. The human readable part of the exemplified message might contain text such as: This is an unsolicited feedback report for an email message received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT) and generated according to [this memo]. If you are unable to correctly visualize any of its parts, you may want to access https://postmaster.feedback-provider.example/fbl?key=1a2b3c4d5e (certified by http://unusual-CAcert.example/certs/root.crt). Our web page above also contains links to general information on our Complaint Feedback Loop program and how to get enrolled, so as to receive feedback reports like this regularly or to stop them altogether. Alternatively, you may reply to this message to confirm the email address that was used to send this report. Please tell us what action you took in order to avoid that the abusive behavior we are complaining about will continue. Just a thought. From sm@resistor.net Fri Jan 27 11:26:07 2012 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 3E0EA21F85EA for ; Fri, 27 Jan 2012 11:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDuZcg0I35Dt for ; Fri, 27 Jan 2012 11:26:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F9021F85D4 for ; Fri, 27 Jan 2012 11:26:02 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0RJPu7O010048 for ; Fri, 27 Jan 2012 11:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327692361; i=@resistor.net; bh=EQEH4oibevB9MfIqd3tvQwnfMu872wBFL09HKMF7uKk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=i5vfaxAhrrPk9AntC4FGqW6zV87rSH/k9/8wfxtI3E8WX1xEP2b3eCzDHZYj0mG2A yHlp3jkIluiKWyV/ne0QEB2X/e4O+xUxrunHeLVLyhSPo0+XD1+b5qRi9loZlA+E9o ++4T94hRArEfPjzwLKdsAMAgYXNKB3h2F7T6rvq8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327692361; i=@resistor.net; bh=EQEH4oibevB9MfIqd3tvQwnfMu872wBFL09HKMF7uKk=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sa1xbV6B6auJUGCOx/Sa0+YVvqi6kawRK2kQ7IGqv6uhBfleYdLEvPrDD4uCwQuxY NM0IRdtS/X4A0nO5VvnozrjHWNDUNRWNomxeTnLED2SkXfDfDKkTHtKjUkopm+NBSO BwRqlbCujXFOkpR88aHUiiHGoUXoWywVOvYip8/c= Message-Id: <6.2.5.6.2.20120127112401.089715c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Jan 2012 11:24:42 -0800 To: Message Abuse Report Format working group From: SM In-Reply-To: References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 19:26:07 -0000 Hi Murray, At 09:53 27-01-2012, Murray S. Kucherawy wrote: >For the record: Apart from that, you're happy with the changes since >the DISCUSS? Yes, send it off. Regards, -sm From barryleiba.mailing.lists@gmail.com Fri Jan 27 13:13:37 2012 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 9F5EC21F8697 for ; Fri, 27 Jan 2012 13:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 TMGqZh6ye4qn for ; Fri, 27 Jan 2012 13:13:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0821F8685 for ; Fri, 27 Jan 2012 13:13:36 -0800 (PST) Received: by ggnq4 with SMTP id q4so1229791ggn.31 for ; Fri, 27 Jan 2012 13:13:36 -0800 (PST) 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:cc:content-type; bh=nHGU0w14f12hAJGvzhmf88Q2gZLPh4s2gQv36wPTvTI=; b=VA2lUxVcMo5JBtM8SdR7B9kXR828cPIWti2wBoo4KkY9zmsUwjwR9odFJN9D74Jl7N xSfOosSchJapPUAVxMD4zxFlJ3DAKhC1sVs/OB+BSofoLIjy89Sq2oTr8r6j8+Dhm3Mv uH5uGc/xVjM0xUTMn4sshza711jffpsc+XdAE= MIME-Version: 1.0 Received: by 10.101.148.28 with SMTP id a28mr3149352ano.18.1327698816690; Fri, 27 Jan 2012 13:13:36 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Fri, 27 Jan 2012 13:13:36 -0800 (PST) In-Reply-To: <6.2.5.6.2.20120127112401.089715c0@resistor.net> References: <20120127142052.E2320F580A3@smtp.patriot.net> <6.2.5.6.2.20120127085658.09cb6828@resistor.net> <6.2.5.6.2.20120127112401.089715c0@resistor.net> Date: Fri, 27 Jan 2012 16:13:36 -0500 X-Google-Sender-Auth: ENqbSzv8qEhx3AKIGl18YyNXtNE Message-ID: From: Barry Leiba To: Murray Kucherawy Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 27 Jan 2012 21:13:37 -0000 OK... Murray, please post -08 and we'll tell Pete it's ready for his move. Barry From internet-drafts@ietf.org Fri Jan 27 13:23:35 2012 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 F16B821F862B; Fri, 27 Jan 2012 13:23:34 -0800 (PST) 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 TOMhVVD1zFId; Fri, 27 Jan 2012 13:23:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD7B21F85D4; Fri, 27 Jan 2012 13:23:34 -0800 (PST) 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.64p1 Message-ID: <20120127212334.22075.82753.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 13:23:34 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-redaction-08.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, 27 Jan 2012 21:23:35 -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 M. Kucherawy Filename : draft-ietf-marf-redaction-08.txt Pages : 8 Date : 2012-01-27 Email messages often contain information that 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-08.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-08.txt From barryleiba.mailing.lists@gmail.com Fri Jan 27 13:25:25 2012 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 DEB7B21F865C for ; Fri, 27 Jan 2012 13:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, 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 JOlUWY1UKyHy for ; Fri, 27 Jan 2012 13:25:25 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6282821F865A for ; Fri, 27 Jan 2012 13:25:25 -0800 (PST) Received: by ghbg16 with SMTP id g16so1123120ghb.31 for ; Fri, 27 Jan 2012 13:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=gZ3R7M9Al0lrignkEJ/duXgzSgrOkNSmCLSSiuvdO28=; b=dcnvdEzluePZfZYQ+BwtW/JzpPHLhMl0b5yMbZxXSFhsXmJ8NVWA7yW1qji7oXOOc0 vFjSF0JxpaIIZMR4yShPzTxV3vaxibzXOrxoE9Ht48Wurvr1f7Z3Bh9BMV6N0RTyEmJY 8Ah/fy7y4dyD4U/Lj0Ufx1aF7OAnVqr7x0jSA= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr13305683yhh.57.1327699524997; Fri, 27 Jan 2012 13:25:24 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Fri, 27 Jan 2012 13:25:24 -0800 (PST) Date: Fri, 27 Jan 2012 16:25:24 -0500 X-Google-Sender-Auth: bQn-vpb5BaKZYUOleUaK996rHfc Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: [marf] marf-redaction ready to go with version -08 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, 27 Jan 2012 21:25:26 -0000 Pete, the MARF working group is satisfied with the -08 version, and thinks it's ready for your final handling. Please let us know whether you decide to send it to the RFC Editor now, or re-do IETF Last Call first. Barry, shepherd/chair From msk@cloudmark.com Fri Jan 27 14:01:19 2012 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 F052B21F863B for ; Fri, 27 Jan 2012 14:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 mO1NaahcVaBM for ; Fri, 27 Jan 2012 14:01:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD0721F862B for ; Fri, 27 Jan 2012 14:01:18 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 27 Jan 2012 14:01:18 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 27 Jan 2012 14:01:17 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 27 Jan 2012 14:01:16 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-04.txt Thread-Index: AczdKFNzyvWVTDdiRNKn8K/HIuJSrwAD8osg Message-ID: References: <20120126061500.20272.40574.idtracker@ietfa.amsl.com> <4F22F846.1070709@tana.it> In-Reply-To: <4F22F846.1070709@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] I-D Action: draft-ietf-marf-as-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: Fri, 27 Jan 2012 22:01:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, January 27, 2012 11:17 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-04.txt >=20 > On 26/Jan/12 07:16, Murray S. Kucherawy wrote: > > I'm caught up on the feedback for this, I think. Please review the > > latest version and provide commentary. >=20 > Some points, nits, and ideas: >=20 > *Updates 5965* >=20 > It doesn't seem to actually update the format. If the use of ARF is > meant to be updated, we probably need a section where that update is > identified. It's my understanding that "RFCx updates RFCy" means "if you are implementi= ng RFCy, you really also need to read RFCx". For an applicability statemen= t, therefore, this is typical. > *Section 5* >=20 > The second part of the second paragraph ("Abuse addresses in WHOIS > records [...]") covers a where-to-send question similar to the one > answered by bullet 5 in Section 8. Would it be an improvement to have > them near to one another? That doesn't seem to be beneficial enough to warrant rearranging the whole = thing. > BTW, this method is also "not universally > true", as the retrieved abuse mailbox can belong to a network provider > who may or may not forward reports to the relevant mailbox provider or > ESP. True, will add that nit-text. > *Section 6* >=20 > The text "Section 3.4 of that document" gets a wrong link in bullet 1 > of http://tools.ietf.org/html/draft-ietf-marf-as-04#section-6 >=20 > Repeating the same reference makes for a less appealing prose, but is > easier to markup and search. That's unfortunate, so OK. > *Section 7* >=20 > In bullet 4, "That system" refers to the automated system considered in > the previous bullet. It is unclear, now that that text has changed. > Hints for rewording: bullets 4 and 5 apply to automated systems, so > they might be further indented. I just changed "That system" to "An automatic report processing system". > Bullet 7 could also refer to Section 4.4 of [RFC6449], as it covers > redaction. However, RFC 6449 treats that the same irrespectively of > the redaction algorithm used. Should we say how to recognize and take > advantage of /conforming/ redaction? Added the reference and a sentence reiterating the point of standard redact= ion, which is to enable correlation and prioritization by the recipient. > *Section 8* >=20 > Bullets 1 and 2 sound quite obscure, or maybe it's just me. As a minor > improvement, maybe s/generating/reporting/? Done. > Bullet 3: s/service provider/mailbox provider/. Done. > Perhaps before bullet 9: do we want to mention that a network provider > MAY use ARF data for automated forwarding of Feedback Messages to the > originating customer, as described in the last paragraph of Section > 4.4 of [RFC6449]? Added. > Bullet 11: kudos for that, great! Do we want to refer to Section 3.5 > of [RFC6449] from there too? Added. > In particular, feedback providers who save the unsolicited reports they > send (as they should) can provide a web page for the report at hand. > That page would display all parts of the report --thereby solving the > issue of bullet 10-- and also provide any FBL-related link that is > mentioned in Section 3.5.1 of [RFC6449]. Would this be good? Possibly, but without an implementation it's hard to say that we can justif= y including it in an applicability statement. Have you actually tried this= ? > If we like it, we could summarize such approach by adding an example > of unsolicited feedback in an appendix of this I-D. The human readable > part of the exemplified message might contain text such as: >=20 > This is an unsolicited feedback report for an email message > received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT) > and generated according to [this memo]. If you are unable to > correctly visualize any of its parts, you may want to access > https://postmaster.feedback-provider.example/fbl?key=3D1a2b3c4d5e > (certified by http://unusual-CAcert.example/certs/root.crt). >=20 > Our web page above also contains links to general information on > our Complaint Feedback Loop program and how to get enrolled, so as > to receive feedback reports like this regularly or to stop them > altogether. >=20 > Alternatively, you may reply to this message to confirm the email > address that was used to send this report. Please tell us what > action you took in order to avoid that the abusive behavior we are > complaining about will continue. Simpler would be to suggest that sending unsolicited feedback SHOULD popula= te the text/plain part of the report with ample explanatory text about what= this message is and where to get more information, since there's no guaran= tee the recipient will understand the other two MIME parts. But I believe = bullet 10 already covers that. -MSK From shmuel+gen@patriot.net Fri Jan 27 16:47:02 2012 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 1CD6B21F860F for ; Fri, 27 Jan 2012 16:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 H+wAJlXKpVzy for ; Fri, 27 Jan 2012 16:47:01 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF7721F8611 for ; Fri, 27 Jan 2012 16:47:01 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.131]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 69F52F5809A for ; Fri, 27 Jan 2012 19:32:46 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 27 Jan 2012 12:20:42 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120128003246.69F52F5809A@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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: Sat, 28 Jan 2012 00:47:02 -0000 In , on 01/27/2012 at 11:53 AM, Barry Leiba said: >The main point is whether the WG thinks this document is (1) good, Yes. >and (2) better than previous versions. No, but just as good. -- 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 vesely@tana.it Sat Jan 28 04:10:04 2012 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 A18A521F8546 for ; Sat, 28 Jan 2012 04:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.608 X-Spam-Level: X-Spam-Status: No, score=-4.608 tagged_above=-999 required=5 tests=[AWL=0.111, 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 DegqBgeFRm4H for ; Sat, 28 Jan 2012 04:09:43 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18821F8543 for ; Sat, 28 Jan 2012 04:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327752581; bh=TWb/nF0u3s/osn8lQ7r7ly1OBcueqiDs5dvMhOEZIuE=; l=1522; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kVsjv+V1C38WmnAwLuFAU/2LSQuR/hl828POR+78bEihqi8skRPjUGUL9keEsuvQd +yaBYm83jwm0mETu88eqjItGcjW6hMJz3GVtRKbcQTW6ZG2xC6vIh7o2T06ZyahYnT hnpsnoC6vf6Ucj+eg4ZPN55gGCUeYGDbdABV9ztI= 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, 28 Jan 2012 13:09:41 +0100 id 00000000005DC03F.000000004F23E585.00003DBE Message-ID: <4F23E584.8060107@tana.it> Date: Sat, 28 Jan 2012 13:09:40 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120126000651.60565.qmail@joyce.lan> <2952671.6CruZRtEId@scott-latitude-e6320> In-Reply-To: <2952671.6CruZRtEId@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] r= using localpart 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, 28 Jan 2012 12:10:37 -0000 On 26/Jan/12 01:28, Scott Kitterman wrote: > On Wednesday, January 25, 2012 04:08:35 PM Murray S. Kucherawy wrote: >> >>>> How does the domain owner receive reports of others trying to use the >>>> domain to send mail? If the domain owner has said via the SPF record >>>> that the domain doesn't send mail, I would be highly surprised if the >>>> domain owner has configured anything to accept mail at that domain. >>> >>> If he wants to get the reports, he'd better. >> >> Do we need to call out this (somewhat obvious) situation in the draft? > > I hope we don't need to say that if you ask for reports you aren't going to > get them unless you configure your system to accept them. Derek's concern seems legitimate to me. Although John's note may seem obvious, let me recall that SPF is rather weak at checking helo names because of a very similar reason. We are demanding too much diligence from domain admins, for a task they can achieve more easily by tracing an included exists mechanism. On the other hand, dkim-reporting has an rd= tag that makes such flexibility possible. What is the use case where rd= is different than d=? Why cannot we have the following for spf-reporting? www.example.com TXT "v=spf1 redirect=nomail._spf.example.com" nomail._spf.example.com TXT "v=spf1 -all rd=example.org" _report._spf.example.org TXT "ra=spf-failures" (The fixed prefix "_report._spf" and the missing v= are not very SPFish, but may look simpler and consistent with dkim-reporting.) From sklist@kitterman.com Sat Jan 28 07:14:58 2012 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 3AD8221F855F for ; Sat, 28 Jan 2012 07:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 4D9l5CJ1Pa+B for ; Sat, 28 Jan 2012 07:14:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 557BC21F8547 for ; Sat, 28 Jan 2012 07:14:57 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7FCF920E40DA; Sat, 28 Jan 2012 10:14:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327763696; bh=GGntEry9ZZQSWYcNDmIjYyJuaeAp3nArl8ZOGtLEy/M=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=dBJIsILFj0/aTcyUj5BYP0sEjEP5+zoTNsKYrXb/VM1gbnrv5sVpDjP+jS7yVHKkH nehlL/aYbp2CY5iaCgeazWXAac/75AZpZSxYIz4gdK35aii7/lPeStEGGC6aardSSB buAc5Y0BgooJ9l8g1CYBhR/6OTuj85NF/UipG1nY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6065920E40B7; Sat, 28 Jan 2012 10:14:56 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sat, 28 Jan 2012 10:14:55 -0500 Message-ID: <1635766.6HWI7H8t9h@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting 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, 28 Jan 2012 15:14:58 -0000 In draft-ietf-marf-spf-reporting we changed the address construction rules to use a localpart from the new mechanism published in DNS and the SPF domain in order to limit the abilty of random third parties to point this kinds of reports at unrelated receivers who may not be prepared for them (and retired a security consideration in the process). We did not (I now notice, thanks to Alessandro Vesely's not on the subject in the SPF draft, make a similar change in the DKIM draft. I think we should. My proposal is to drop 3.1. Extension DKIM Signature Tag and change the address construction in the ra= tag to use the signing domain (d=) in the signature. In this manner the reports will only go back where they came from (in a general sense). Scott K From sklist@kitterman.com Sat Jan 28 07:21:41 2012 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 5F9E221F85D4 for ; Sat, 28 Jan 2012 07:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 PF-63uEuVh3d for ; Sat, 28 Jan 2012 07:21:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 44EE321F85A2 for ; Sat, 28 Jan 2012 07:21:27 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D2CBE20E40DA; Sat, 28 Jan 2012 10:21:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327764086; bh=dKJ4W+hqm+pjLchdcQSx4/6DZtfLSEPhA5CyVt02jCw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DyTFyd9AIjaiHWPj1rDFDZf0Kqv9f9xnWQYtu5v/Xqonw5AzqJLFhoDerbAeumt0n UFdnI05Gg9CzK9ia+VXCHAPFaz1P5hUATP2dCzOTfZ4h8guD9oHou/fEpI6WuSmuVj B0Yj6LPzXr13k7LyTweGOvsLvlmV29M6nAA4R0TI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B77F520E40B7; Sat, 28 Jan 2012 10:21:26 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sat, 28 Jan 2012 10:21:26 -0500 Message-ID: <2042177.jTN0kpQ30j@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F23E584.8060107@tana.it> References: <2952671.6CruZRtEId@scott-latitude-e6320> <4F23E584.8060107@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] r= using localpart 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, 28 Jan 2012 15:21:41 -0000 On Saturday, January 28, 2012 01:09:40 PM Alessandro Vesely wrote: > On 26/Jan/12 01:28, Scott Kitterman wrote: > > On Wednesday, January 25, 2012 04:08:35 PM Murray S. Kucherawy wrote: > >>>> How does the domain owner receive reports of others trying to use > >>>> the > >>>> domain to send mail? If the domain owner has said via the SPF > >>>> record > >>>> that the domain doesn't send mail, I would be highly surprised if > >>>> the > >>>> domain owner has configured anything to accept mail at that > >>>> domain. > >>> > >>> If he wants to get the reports, he'd better. > >> > >> Do we need to call out this (somewhat obvious) situation in the draft? > > > > I hope we don't need to say that if you ask for reports you aren't going > > to get them unless you configure your system to accept them. > > Derek's concern seems legitimate to me. Although John's note may seem > obvious, let me recall that SPF is rather weak at checking helo names > because of a very similar reason. We are demanding too much diligence > from domain admins, for a task they can achieve more easily by tracing > an included exists mechanism. Why is SPF 'weak' at checking HELO names? I think I misunderstand something about the premise of your statement. What diligence are we asking for that is too much? > On the other hand, dkim-reporting has an rd= tag that makes such > flexibility possible. What is the use case where rd= is different > than d=? Why cannot we have the following for spf-reporting? I missed that we still had that in the DKIM draft and I've sent a note regarding changing that as well. I think it's better to keep the reports being sent back to the relevant domain (SPF domain as defined in check_host() or d= domain for DKIM) and let them make arrangements to relay them elsewhere if needed than to allow these messages to be sent to arbitrary domains that may not be expecting them. Here's the security consideration we retired when we changed it to work the way it is now: "6.2. Reports From Unrelated Domains SPF records can be used by other domains via include mechanisms and redirect modifiers. If reporting addresses included in these records are specified with a full addr-spec then reports for other, potentially unrelated, domains may be reported to this address. In theory, malicious senders might use this as a path for generating large numbers of feedback reports. To mitigate this issue, specify reporting addresses with a local-part so that reports will be directed to the original domain from which the message causing the feedback report was sent." I think this was a good change and the DKIM draft should be changed similarly. Scott K From presnick@qualcomm.com Sat Jan 28 14:39:49 2012 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 D704B21F852B for ; Sat, 28 Jan 2012 14:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8FyufqErvJ6e for ; Sat, 28 Jan 2012 14:39:49 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36421F84B6 for ; Sat, 28 Jan 2012 14:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327790389; x=1359326389; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F247932.50009@qualcomm.com>|Date:=20Sat, =2028=20Jan=202012=2016:39:46=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Barry=20Leiba=20|CC:=20Message=20Abuse=20Report=20Format=20wor king=20group=20|Subject:=20Re:=20[marf]=20 marf-redaction=20ready=20to=20go=20with=20version=20-08 |References:=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=JirPX9tsLUuWGflxrVoUOq+5lBYcRfC+GgCBb2VoYDg=; b=PQCh46idoe0e6relI0c0CzMwmsa/sL0bqk24XsKyKq9B8QG6qO92bjzg LywdUT1dD0f+yBVjew/j3X1yaH1zdLlcE8lhfNgR/v5BRkAslh/NyzIzZ JXeVAlsx80F3hYUixx2wwC2/17z46YWbsx0/Toq2suhqgFUvZZH2nprCC Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6603"; a="156409745" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 28 Jan 2012 14:39:49 -0800 X-IronPort-AV: E=Sophos;i="4.71,585,1320652800"; d="scan'208";a="119020632" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2012 14:39:48 -0800 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 28 Jan 2012 14:39:48 -0800 Message-ID: <4F247932.50009@qualcomm.com> Date: Sat, 28 Jan 2012 16:39:46 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Message Abuse Report Format working group Subject: Re: [marf] marf-redaction ready to go with version -08 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, 28 Jan 2012 22:39:50 -0000 On 1/27/12 3:25 PM, Barry Leiba wrote: > Pete, the MARF working group is satisfied with the -08 version, and > thinks it's ready for your final handling. Please let us know whether > you decide to send it to the RFC Editor now, or re-do IETF Last Call > first. > After some consideration, I've decided that the prudent thing to do is issue another IETF Last Call: There has been pretty substantial change to the document since the previous Last Call, and I think the IETF should get an official last look. All of the IESG comments have been appropriately addressed, so unless there is some objection during this Last Call, I will approve the document as soon as it completes. Thanks for your patience. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From vesely@tana.it Sun Jan 29 05:31:42 2012 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 0976821F850C for ; Sun, 29 Jan 2012 05:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=0.109, 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 tOD2MixH91Lo for ; Sun, 29 Jan 2012 05:31:41 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1509321F8505 for ; Sun, 29 Jan 2012 05:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327843899; bh=vGxkrRW2HwTBujbRBJXdSCsx+az31dQUyYlVfgWU2gU=; l=839; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=g+JVGlaWyRsztl69QuMsNw/Xpq4Xp+V4oCCGYmlkPCSv1J0Q1hA7lMlbAUKNBfTzG TO7vCkC7odmmCSIpGdGL3/a+MIfdb1rnHHPBkEuTIvCbAbhpze5ydZ/O0e1ovptFmr 2oWPCVVymS4TGWDzAVv3zvDcZ1dbcpz2HwteNQnQ= 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, 29 Jan 2012 14:31:39 +0100 id 00000000005DC039.000000004F254A3B.0000090F Message-ID: <4F254A3A.1000605@tana.it> Date: Sun, 29 Jan 2012 14:31:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <1635766.6HWI7H8t9h@scott-latitude-e6320> In-Reply-To: <1635766.6HWI7H8t9h@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting 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, 29 Jan 2012 13:31:42 -0000 On 28/Jan/12 16:14, Scott Kitterman wrote: > My proposal is to drop 3.1. Extension DKIM Signature Tag and change the > address construction in the ra= tag to use the signing domain (d=) in the > signature. In this manner the reports will only go back where they came from > (in a general sense). Murray introduced 3.1 after John pointed out an attack path in http://www.ietf.org/mail-archive/web/marf/current/msg01775.html I guess this feature is needed in order to account for message streams , but I'm looking forward to Murray's word on this. The general statement seems to be that is a valid address for reporting _something as long as there is a RR that says _report._something.example.com. TXT "[...]whatever-local[...]" Correct? From vesely@tana.it Sun Jan 29 05:56:23 2012 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 4355821F8548 for ; Sun, 29 Jan 2012 05:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.106, 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 B9zlZvxxa0Kw for ; Sun, 29 Jan 2012 05:56:22 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF0721F852E for ; Sun, 29 Jan 2012 05:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327845381; bh=EGX8AWUgtwW/cM7mFJCydJYOkpBwlVAEr/FVB1XwP4k=; l=1540; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OiLpNkjsFC54/HiMcSdZFPDpR/8+2AfbAVyH+lYIOVBfAk+2b3l2FnUxuCaVXV3HC LOFOMZTQCWRDDZFPNlQk3nw8pE9Hk/WkPRpgGMvB9b0/w47qJP3ursShfVFBKXnV9t tyvquCyfV5FwMVC0Z/4jaK5EI0KCskOMf8H/cqs4= 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, 29 Jan 2012 14:56:21 +0100 id 00000000005DC039.000000004F255005.00000EF5 Message-ID: <4F255005.9010702@tana.it> Date: Sun, 29 Jan 2012 14:56:21 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <2952671.6CruZRtEId@scott-latitude-e6320> <4F23E584.8060107@tana.it> <2042177.jTN0kpQ30j@scott-latitude-e6320> In-Reply-To: <2042177.jTN0kpQ30j@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] r= using localpart 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, 29 Jan 2012 13:56:23 -0000 On 28/Jan/12 16:21, Scott Kitterman wrote: > On Saturday, January 28, 2012 01:09:40 PM Alessandro Vesely wrote: >>>>>> How does the domain owner receive reports of others >>>>>> trying to use the domain to send mail? If the domain >>>>>> owner has said via the SPF record that the domain doesn't >>>>>> send mail, I would be highly surprised if the domain >>>>>> owner has configured anything to accept mail at that >>>>>> domain. >>>>> >>>>> If he wants to get the reports, he'd better. >>>> >>>> Do we need to call out this (somewhat obvious) situation in the draft? >>> >>> I hope we don't need to say that if you ask for reports you aren't going >>> to get them unless you configure your system to accept them. >> >> Derek's concern seems legitimate to me. Although John's note may seem >> obvious, let me recall that SPF is rather weak at checking helo names >> because of a very similar reason. We are demanding too much diligence >> from domain admins, for a task they can achieve more easily by tracing >> an included exists mechanism. > > Why is SPF 'weak' at checking HELO names? I think I misunderstand something > about the premise of your statement. I just notice that admins don't bother publishing a record for each and every host that mails out, although they publish one for the domain. > What diligence are we asking for that is too much? They should additionally publish an MX, for the sole purpose of collecting failure reports. We could as well ask to deliver them via pony express. From sklist@kitterman.com Sun Jan 29 09:47:57 2012 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 97E9B21F857F for ; Sun, 29 Jan 2012 09:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 woWpL58h9fKL for ; Sun, 29 Jan 2012 09:47:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD11A21F8541 for ; Sun, 29 Jan 2012 09:47:56 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D8B0820E40F5; Sun, 29 Jan 2012 12:47:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327859275; bh=SiZdQEl/jQ4EbcpgQUUtogwHWAhRqDLUo4F84n2rBww=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SUkg4kodA2wbV3TRXUfXWKgHDk2VYGWqjKQq5DPHqMH90CLM3ghK3rQW60kU17N26 szmwqJ0d7vuox466ArCOUGBMe9Wd5Onra3j90ApJ/CEtDSL2MDT54dXbncPqTCLOs8 cVnZucsg3V7A6N4SWg5T5xd1K6D157chJjvFS0xU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B845820E4084; Sun, 29 Jan 2012 12:47:55 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 12:47:54 -0500 Message-ID: <8099303.a66Fh2J7xx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F255005.9010702@tana.it> References: <2042177.jTN0kpQ30j@scott-latitude-e6320> <4F255005.9010702@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] r= using localpart 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, 29 Jan 2012 17:47:57 -0000 On Sunday, January 29, 2012 02:56:21 PM Alessandro Vesely wrote: > On 28/Jan/12 16:21, Scott Kitterman wrote: > > On Saturday, January 28, 2012 01:09:40 PM Alessandro Vesely wrote: > >>>>>> How does the domain owner receive reports of others > >>>>>> trying to use the domain to send mail? If the domain > >>>>>> owner has said via the SPF record that the domain doesn't > >>>>>> send mail, I would be highly surprised if the domain > >>>>>> owner has configured anything to accept mail at that > >>>>>> domain. > >>>>> > >>>>> If he wants to get the reports, he'd better. > >>>> > >>>> Do we need to call out this (somewhat obvious) situation in the > >>>> draft? > >>> > >>> I hope we don't need to say that if you ask for reports you aren't > >>> going to get them unless you configure your system to accept them. > >> > >> Derek's concern seems legitimate to me. Although John's note may seem > >> obvious, let me recall that SPF is rather weak at checking helo names > >> because of a very similar reason. We are demanding too much diligence > >> from domain admins, for a task they can achieve more easily by tracing > >> an included exists mechanism. > > > > Why is SPF 'weak' at checking HELO names? I think I misunderstand > > something about the premise of your statement. > > I just notice that admins don't bother publishing a record for each > and every host that mails out, although they publish one for the domain. I agree it's less deployed, but I wouldn't call that weak. > > What diligence are we asking for that is too much? > > They should additionally publish an MX, for the sole purpose of > collecting failure reports. We could as well ask to deliver them via > pony express. An A record is sufficient. Scott K From msk@cloudmark.com Sun Jan 29 19:04:30 2012 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 B39FD21F847D for ; Sun, 29 Jan 2012 19:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YRKp7KmwO6G for ; Sun, 29 Jan 2012 19:04:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 46ACE21F8474 for ; Sun, 29 Jan 2012 19:04:30 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 19:04:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 29 Jan 2012 19:04:29 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 19:04:31 -0800 Thread-Topic: [marf] r= using localpart Thread-Index: Aczdtd13oIE+P1rnRT2JsrApKx4qowBRYTxg Message-ID: References: <20120126000651.60565.qmail@joyce.lan> <2952671.6CruZRtEId@scott-latitude-e6320> <4F23E584.8060107@tana.it> In-Reply-To: <4F23E584.8060107@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] r= using localpart 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, 30 Jan 2012 03:04:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, January 28, 2012 4:10 AM > To: marf@ietf.org > Subject: Re: [marf] r=3D using localpart >=20 > On the other hand, dkim-reporting has an rd=3D tag that makes such > flexibility possible. What is the use case where rd=3D is different than > d=3D? If some intermediary is doing your DKIM work for you, you might want that i= ntermediary to receive failure reports as well. But, then again, you could= just as easily alias the failure address from your domain to them; this in= troduces a hop through your own mail servers, but it actually closes a secu= rity issue in that domain X can't fake a signature from domain Y on mail to= domain Z and request reports go back to X, thus revealing whether or not Z= is doing DKIM verification (if it participates in the reporting). So maybe the "rd" for DKIM should just become "r=3D" which, if present and = containing any value (as with "t=3Dy"), then do the rest of the protocol us= ing only the signing domain as the possible destination of reports. -MSK From msk@cloudmark.com Sun Jan 29 19:07:18 2012 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 4BC0321F8458 for ; Sun, 29 Jan 2012 19:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0q+lNgwo0oG for ; Sun, 29 Jan 2012 19:07:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D321F8449 for ; Sun, 29 Jan 2012 19:07:16 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 19:07:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 29 Jan 2012 19:07:14 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 19:07:16 -0800 Thread-Topic: [marf] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting Thread-Index: Aczdz5rokKkpB7VURtuDUZ3RBFdDvgBLE16g Message-ID: References: <1635766.6HWI7H8t9h@scott-latitude-e6320> In-Reply-To: <1635766.6HWI7H8t9h@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] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting 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, 30 Jan 2012 03:07:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Saturday, January 28, 2012 7:15 AM > To: marf@ietf.org > Subject: [marf] rd=3D Reporting Domain Tag In draft-ietf-marf-dkim-report= ing >=20 > My proposal is to drop 3.1. Extension DKIM Signature Tag and change > the address construction in the ra=3D tag to use the signing domain (d=3D= ) > in the signature. In this manner the reports will only go back where > they came from (in a general sense). The point of the extension tag is to add an active signal that the extra DN= S work is supposed to be done to determine the reporting address. Absent t= hat, any Verifier participating in reporting will query the DNS of the sign= ing domain for a reporting address, even for signatures that don't claim to= request reporting. I suppose it's not a huge difference though (i.e., if you want to make the = attack, just include the "rd=3D" tag too). -MSK From msk@cloudmark.com Sun Jan 29 19:14:37 2012 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 70C3921F8498 for ; Sun, 29 Jan 2012 19:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBjBz7wcKMSZ for ; Sun, 29 Jan 2012 19:14:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 09E1421F8474 for ; Sun, 29 Jan 2012 19:14:36 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 19:14:36 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 29 Jan 2012 19:14:36 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 19:14:38 -0800 Thread-Topic: [marf] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting Thread-Index: AczeilhEzlMR6FhATmaJOn7aWC7HpgAcK/vg Message-ID: References: <1635766.6HWI7H8t9h@scott-latitude-e6320> <4F254A3A.1000605@tana.it> In-Reply-To: <4F254A3A.1000605@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] rd= Reporting Domain Tag In draft-ietf-marf-dkim-reporting 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, 30 Jan 2012 03:14:37 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Sunday, January 29, 2012 5:32 AM > To: marf@ietf.org > Subject: Re: [marf] rd=3D Reporting Domain Tag In draft-ietf-marf-dkim-re= porting >=20 > On 28/Jan/12 16:14, Scott Kitterman wrote: > > My proposal is to drop 3.1. Extension DKIM Signature Tag and change > > the address construction in the ra=3D tag to use the signing domain (d= =3D) > > in the signature. In this manner the reports will only go back where > > they came from (in a general sense). >=20 > Murray introduced 3.1 after John pointed out an attack path in > http://www.ietf.org/mail-archive/web/marf/current/msg01775.html >=20 > I guess this feature is needed in order to account for message streams > , but I'm looking > forward to Murray's word on this. >=20 > The general statement seems to be that is > a valid address for reporting _something as long as there is a RR that > says >=20 > _report._something.example.com. TXT "[...]whatever-local[...]" >=20 > Correct? Yes, though I think I agree that being able to include an alternate domain = name in the algorithm creates more exposure than it fixes, so rather than "= rd=3Ddomain", we should just have "r=3Dy" in the DKIM reporting document. I'll do this in -07 unless there's a better idea. -MSK From msk@cloudmark.com Sun Jan 29 20:18:33 2012 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 09F1C21F84F3 for ; Sun, 29 Jan 2012 20:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 w+GwDwnMYGtc for ; Sun, 29 Jan 2012 20:18:32 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3623C21F8484 for ; Sun, 29 Jan 2012 20:18:31 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 20:18:31 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 29 Jan 2012 20:18:31 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 20:18:33 -0800 Thread-Topic: Additional dkim-reporting report type requests Thread-Index: AczfBjp4J40/j/ROSqKy+d/IcvRrrg== 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_F5833273385BB34F99288B3648C4F06F19C9A7DA55EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:18:33 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA55EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it's prudent for us to add two more report types for both ADSP and = DKIM: "p", meaning the DKIM or ADSP test failed for local policy reasons, a= nd "o", meaning there was a problem with DKIM or ADSP that was something ot= her than the report types already listed. DKIM in particular can be presented a perfectly valid DKIM signature that v= erifies, but the verifier could decide it doesn't want to accept the signat= ure anyway for policy reasons, including (real use cases here) Subject: was= n't signed, or "l=3D" didn't cover enough of the message percentage-wise. = The existing report requests don't cover those. I don't know if there's an SPF equivalent for "p", but I suspect adding the= "o" case would be a good idea. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA55EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it’= ;s prudent for us to add two more report types for both ADSP and DKIM: R= 20;p”, meaning the DKIM or ADSP test failed for local policy reasons,= and “o”, meaning there was a problem with DKIM or ADSP that wa= s something other than the report types already listed.

 

DKIM in particula= r can be presented a perfectly valid DKIM signature that verifies, but the = verifier could decide it doesn’t want to accept the signature anyway = for policy reasons, including (real use cases here) Subject: wasn’t s= igned, or “l=3D” didn’t cover enough of the message perce= ntage-wise.  The existing report requests don’t cover those.

 

I= don’t know if there’s an SPF equivalent for “p”, b= ut I suspect adding the “o” case would be a good idea.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA55EXCHC2corpclo_-- From sklist@kitterman.com Sun Jan 29 20:23:29 2012 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 121AE21F849C for ; Sun, 29 Jan 2012 20:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 rsM0u6PXj9Gc for ; Sun, 29 Jan 2012 20:23:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5839921F8493 for ; Sun, 29 Jan 2012 20:23:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A8EE20E40F5; Sun, 29 Jan 2012 23:23:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327897407; bh=21z99rWLr0V4R7/tX3BoKn+YEHr8Pu9luPKiA84vXxo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SGJnb7d6ebUFRoflyFdFD2A9YcmDDwk34+QWUXAf9KugW7FSuYKiRJu1GQ77O/M2j QSd+AWWWwXJZYuvp7tjfzM8dZSFh/SBiKHjcETmWgoMTL8Je6yTUulEnFVZeyIRU7a Q8X8oegStmllJfwQlCuaAhCul1Rh44DyaTu+XnAw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6A3AE20E4084; Sun, 29 Jan 2012 23:23:27 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 23:23:26 -0500 Message-ID: <2416959.fKLS07zzhM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:23:29 -0000 On Sunday, January 29, 2012 08:18:33 PM Murray S. Kucherawy wrote: > I think it's prudent for us to add two more report types for both ADSP and > DKIM: "p", meaning the DKIM or ADSP test failed for local policy reasons, > and "o", meaning there was a problem with DKIM or ADSP that was something > other than the report types already listed. > > DKIM in particular can be presented a perfectly valid DKIM signature that > verifies, but the verifier could decide it doesn't want to accept the > signature anyway for policy reasons, including (real use cases here) > Subject: wasn't signed, or "l=" didn't cover enough of the message > percentage-wise. The existing report requests don't cover those. > > I don't know if there's an SPF equivalent for "p", but I suspect adding the > "o" case would be a good idea. "p" is embedded in SPF already. If the SPF result is fail and you are rejecting due to SPF, it's by definition a policy issue. I would suggest that "o" isn't needed for SPF since we've already covered the spectrum of reasons for an SPF related rejection and so if one is rejecting a mail due to some other reason, it's not an SPF auth failure that's causing the rejection, it's another type of policy of some kind (e.g. passes SPF, but it's a known spammer domain, so reject the mail isn't an SPF issue). Scott K From sklist@kitterman.com Sun Jan 29 20:27:32 2012 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 BA6E421F84CD for ; Sun, 29 Jan 2012 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 vjOyZz+z0G8S for ; Sun, 29 Jan 2012 20:27:32 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41F21F84B5 for ; Sun, 29 Jan 2012 20:27:32 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9939120E40F5; Sun, 29 Jan 2012 23:27:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327897651; bh=cwshl5QG67ZCP1JP0+6mSz/ba1VTSEW74UlN/+lj9S4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TmVfzGcbXw+hdqISmDTELgxoZdxpyRbl97m2kTG3slM35iFNY0zFaKOp+Uwy+XCqL rZwGsOZaYf0BORmi1kgAnzSjh0PEzv9AccveFQZVU5STyfLMrbiXPxkDjEBDVRov0b MAJkzw+atII1Um/yMQ0Nt75pRRUD7+BkoUF0TE14= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7AF1220E4084; Sun, 29 Jan 2012 23:27:31 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 23:27:30 -0500 Message-ID: <5489781.FqGBdEXlYF@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <4F23E584.8060107@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] r= using localpart 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, 30 Jan 2012 04:27:32 -0000 On Sunday, January 29, 2012 07:04:31 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Alessandro Vesely Sent: Saturday, January 28, 2012 4:10 AM > > To: marf@ietf.org > > Subject: Re: [marf] r= using localpart > > > > On the other hand, dkim-reporting has an rd= tag that makes such > > flexibility possible. What is the use case where rd= is different than > > d=? > > If some intermediary is doing your DKIM work for you, you might want that > intermediary to receive failure reports as well. But, then again, you > could just as easily alias the failure address from your domain to them; > this introduces a hop through your own mail servers, but it actually closes > a security issue in that domain X can't fake a signature from domain Y on > mail to domain Z and request reports go back to X, thus revealing whether > or not Z is doing DKIM verification (if it participates in the reporting). > > So maybe the "rd" for DKIM should just become "r=" which, if present and > containing any value (as with "t=y"), then do the rest of the protocol > using only the signing domain as the possible destination of reports. I think the key is that the information about where reports need to go needs to be found in DNS, not in the message, so if one takes the signing domain and looks up the record there, it will give you the localpart to go with that domain. The r= flag you propose would (AIUI) be the trigger to do the DNS lookup to see if there's a DNS record asking for reports. Is along the lines of what you intend? Scott K From msk@cloudmark.com Sun Jan 29 20:42:18 2012 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 6F83D21F8497 for ; Sun, 29 Jan 2012 20:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIzCUdx6aOmZ for ; Sun, 29 Jan 2012 20:42:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3B821F8474 for ; Sun, 29 Jan 2012 20:42:18 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 20:42:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 29 Jan 2012 20:42:17 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 20:42:18 -0800 Thread-Topic: [marf] r= using localpart Thread-Index: AczfB33we9CgDaYMSnOyX1Z1S5iEKQAAfc2Q Message-ID: References: <4F23E584.8060107@tana.it> <5489781.FqGBdEXlYF@scott-latitude-e6320> In-Reply-To: <5489781.FqGBdEXlYF@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] r= using localpart 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, 30 Jan 2012 04:42:18 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Sunday, January 29, 2012 8:28 PM > To: marf@ietf.org > Subject: Re: [marf] r=3D using localpart >=20 > I think the key is that the information about where reports need to go > needs to be found in DNS, not in the message, so if one takes the > signing domain and looks up the record there, it will give you the > localpart to go with that domain. The r=3D flag you propose would (AIUI) > be the trigger to do the DNS lookup to see if there's a DNS record > asking for reports. >=20 > Is along the lines of what you intend? Specifically in the signer's DNS, but yes, that's right. From msk@cloudmark.com Sun Jan 29 20:44:33 2012 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 B33DC21F854E for ; Sun, 29 Jan 2012 20:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOSQFDePXR8B for ; Sun, 29 Jan 2012 20:44:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4AA21F8497 for ; Sun, 29 Jan 2012 20:44:26 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 20:44:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 29 Jan 2012 20:44:25 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 20:44:26 -0800 Thread-Topic: [marf] Additional dkim-reporting report type requests Thread-Index: AczfBuyuYGmoZivuRbun3TYlHjYT2AAAqZig Message-ID: References: <2416959.fKLS07zzhM@scott-latitude-e6320> In-Reply-To: <2416959.fKLS07zzhM@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:44:33 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Sunday, January 29, 2012 8:23 PM > To: marf@ietf.org > Subject: Re: [marf] Additional dkim-reporting report type requests >=20 > "p" is embedded in SPF already. If the SPF result is fail and you are > rejecting due to SPF, it's by definition a policy issue. We're using "policy" differently. An SPF example might be that SPF evaluat= ion passes, but the Verifier demands that SPF only be given credit when the= policy includes "-all", and anything else can't truly be trusted. That wo= uld be a case where local policy overrides what SPF says, and you actually = treat a "pass" as something other than a "pass". That's probably a contriv= ed example but you get the idea. -MSK From sklist@kitterman.com Sun Jan 29 20:49:24 2012 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 0338C21F84C3 for ; Sun, 29 Jan 2012 20:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 su6fsY5GBaJw for ; Sun, 29 Jan 2012 20:49:23 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8D21F84BF for ; Sun, 29 Jan 2012 20:49:23 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E464A20E40F5; Sun, 29 Jan 2012 23:49:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327898962; bh=8l5XDOoATLg/cX7Pq0eC/Wu5W9W0Fjrn7ZXhl5+X3RE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SRJMGCdI9OHMmBqXdzpreQE+e2H2s/0VHh5qKmvt5egM8D6RRep4fsV/QYkDRRRST GBXMdtK/pQkvvxGmz02XoZ2fZ2wry/E7ihtIJNrgSH2GUHod/LyjdMFRfao4PGAYNB vbO6haWtQC1++sG4wDjdOZbu65nn9UnR+xd91FFs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C4E6C20E4084; Sun, 29 Jan 2012 23:49:22 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 23:49:22 -0500 Message-ID: <2137486.OJZ7VaLnLe@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <2416959.fKLS07zzhM@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:49:24 -0000 On Sunday, January 29, 2012 08:44:26 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Sunday, January 29, 2012 8:23 PM > > To: marf@ietf.org > > Subject: Re: [marf] Additional dkim-reporting report type requests > > > > "p" is embedded in SPF already. If the SPF result is fail and you are > > rejecting due to SPF, it's by definition a policy issue. > > We're using "policy" differently. An SPF example might be that SPF > evaluation passes, but the Verifier demands that SPF only be given credit > when the policy includes "-all", and anything else can't truly be trusted. > That would be a case where local policy overrides what SPF says, and you > actually treat a "pass" as something other than a "pass". That's probably > a contrived example but you get the idea. OK. I would say that's not an SPF result at all. Scott K From msk@cloudmark.com Sun Jan 29 20:53:22 2012 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 7A16421F8555 for ; Sun, 29 Jan 2012 20:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftGky5u98zCa for ; Sun, 29 Jan 2012 20:53:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5E21F8554 for ; Sun, 29 Jan 2012 20:53:22 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 20:53:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 29 Jan 2012 20:53:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 20:53:22 -0800 Thread-Topic: [marf] Additional dkim-reporting report type requests Thread-Index: AczfCouGQH5JmUHdTD2UXJ4O/CGtsAAACckw Message-ID: References: <2416959.fKLS07zzhM@scott-latitude-e6320> <2137486.OJZ7VaLnLe@scott-latitude-e6320> In-Reply-To: <2137486.OJZ7VaLnLe@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:53:22 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Sunday, January 29, 2012 8:49 PM > To: marf@ietf.org > Subject: Re: [marf] Additional dkim-reporting report type requests >=20 > OK. I would say that's not an SPF result at all. Right; I would say it's a Verifier policy override of an SPF result, and po= ssible something a sender might want to know about. But that's because I c= ome from the DKIM side of things. The difference is probably in the specs themselves: DKIM has always talked = about the fact that a Verifier could render a signature failed for any reas= on it wants (e.g., last paragraph of Section 6.1.1 of RFC6376) even if all = the bits line up to produce a valid signature, and I'm guessing SPF has alw= ays put policy stuff like that out of scope. -MSK From sklist@kitterman.com Sun Jan 29 20:58:10 2012 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 3FDD221F8543 for ; Sun, 29 Jan 2012 20:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 nd6E9lU0TIgL for ; Sun, 29 Jan 2012 20:58:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEEE21F84EC for ; Sun, 29 Jan 2012 20:58:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1375720E40F5; Sun, 29 Jan 2012 23:58:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327899489; bh=ut9gL1Ow2LSLGP9XWSiSqDkQCOjGevUVQR+5gLlHimY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TtSdun1hDjsivZqfv/R/JMY//URjW0FYozlra5bYHJrYZSoYd+HJjor8uehp7Wmjd ez21Thrv5JVNbBQLi0Pa/nmL6qnSqRV8bOKoZmTHgns3ekgbRuKP00vNUu0eY84ygq hmvDhQUj0OeQEVUsOoqyIeqZygn6+XWrX9QPGr9E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E959D20E4084; Sun, 29 Jan 2012 23:58:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 23:58:08 -0500 Message-ID: <1846905.VTUMUpE8Lf@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <2137486.OJZ7VaLnLe@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 04:58:10 -0000 On Sunday, January 29, 2012 08:53:22 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Sunday, January 29, 2012 8:49 PM > > To: marf@ietf.org > > Subject: Re: [marf] Additional dkim-reporting report type requests > > > > OK. I would say that's not an SPF result at all. > > Right; I would say it's a Verifier policy override of an SPF result, and > possible something a sender might want to know about. But that's because I > come from the DKIM side of things. > > The difference is probably in the specs themselves: DKIM has always talked > about the fact that a Verifier could render a signature failed for any > reason it wants (e.g., last paragraph of Section 6.1.1 of RFC6376) even if > all the bits line up to produce a valid signature, and I'm guessing SPF has > always put policy stuff like that out of scope. Right, DKIM has no policy component at all, so any policy reasons are inherently of some other class of things, but without policy there's no action, so it makes sense to bring it in. In SPF, sender policy is embedded in the record and one can infer receiver policy based on results. If one is doing non-SPF things then it should be reported in some other way. I agree such reports would be of interest, I just don't seem them as SPF reports. I think it'd be inappropriate to use the SPF type for an Authentication Results header in such cases too. Scott K From sklist@kitterman.com Sun Jan 29 20:59:49 2012 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 4934421F8557 for ; Sun, 29 Jan 2012 20:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 zVj3iArmyi59 for ; Sun, 29 Jan 2012 20:59:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D237F21F8555 for ; Sun, 29 Jan 2012 20:59:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6A29420E40F5; Sun, 29 Jan 2012 23:59:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327899588; bh=BF/fnDoTC/O9/RIFtyg/b/0bmAYvdfKSLBGQmFV79gg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=OBpBqszi0p5HTj1/mSLepI+QJJaysbDdG86UEFZbnZoGgqLh78ROnsoMeRi3vKwgk 5cbHVm6Uhwbp1dj3+CVE7EF9b44LIb5aHNGM/sFj7kr5agZHgMxB6sjqs1dBAsuSEq SDxx7GdHCj2TiwRNBuTDj/cVZmaEAPiyLvKWWL1Y= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5BF0820E4084; Sun, 29 Jan 2012 23:59:48 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 29 Jan 2012 23:59:47 -0500 Message-ID: <5677385.iYbtzkYjDx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <5489781.FqGBdEXlYF@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] r= using localpart 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, 30 Jan 2012 04:59:49 -0000 On Sunday, January 29, 2012 08:42:18 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Sunday, January 29, 2012 8:28 PM > > To: marf@ietf.org > > Subject: Re: [marf] r= using localpart > > > > I think the key is that the information about where reports need to go > > needs to be found in DNS, not in the message, so if one takes the > > signing domain and looks up the record there, it will give you the > > localpart to go with that domain. The r= flag you propose would (AIUI) > > be the trigger to do the DNS lookup to see if there's a DNS record > > asking for reports. > > > > Is along the lines of what you intend? > > Specifically in the signer's DNS, but yes, that's right. Sounds good. Thanks, Scott K From msk@cloudmark.com Sun Jan 29 21:11:34 2012 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 89C9A21F855D for ; Sun, 29 Jan 2012 21:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEzND76SSFbm for ; Sun, 29 Jan 2012 21:11:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 19C2121F8559 for ; Sun, 29 Jan 2012 21:11:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 21:11:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 29 Jan 2012 21:11:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 29 Jan 2012 21:11:34 -0800 Thread-Topic: [marf] Additional dkim-reporting report type requests Thread-Index: AczfC8UGbSY37o1hSnuYQPtIKNcxUAAAZ9nA Message-ID: References: <2137486.OJZ7VaLnLe@scott-latitude-e6320> <1846905.VTUMUpE8Lf@scott-latitude-e6320> In-Reply-To: <1846905.VTUMUpE8Lf@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 05:11:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Sunday, January 29, 2012 8:58 PM > To: marf@ietf.org > Subject: Re: [marf] Additional dkim-reporting report type requests >=20 > I agree such reports would be of interest, I just don't seem them as > SPF reports. I think it'd be inappropriate to use the SPF type for an > Authentication Results header in such cases too. RFC5451 did bring in "policy" as a possible result for SPF and Sender-ID th= ough. Possible fodder for discussion on that other mailing list. From scott@kitterman.com Sun Jan 29 21:14:41 2012 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 CF7E421F855B for ; Sun, 29 Jan 2012 21:14:41 -0800 (PST) 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 KzM+ae62qRBn for ; Sun, 29 Jan 2012 21:14:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 25E1D21F84F2 for ; Sun, 29 Jan 2012 21:14:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B181320E40F5; Mon, 30 Jan 2012 00:14:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1327900480; bh=jeOkPtCjPWbsMwDlmRhw7tIutb1lpx9B2eQ7xU7j+uI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PYxgcKDoo+MnYI3Cr+amkARSKJTzYHZs0RxL+LHhC53Oh5a9I4K3zkyeVaiGvKepa WwuUN2uN1pyw+FR9jEJKgf0m0P6T0CiatF1OB5OlVTpi1pD71pH6QowD5+Ih8NTkN/ IYbZvSi/17yAUQHcuHPk34G4CbitsJ2M37uIUG0s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A433920E4084; Mon, 30 Jan 2012 00:14:40 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 30 Jan 2012 00:14:40 -0500 Message-ID: <1365948.RgOcvGgv7y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <1846905.VTUMUpE8Lf@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] Additional dkim-reporting report type requests 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, 30 Jan 2012 05:14:41 -0000 On Sunday, January 29, 2012 09:11:34 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Sunday, January 29, 2012 8:58 PM > > To: marf@ietf.org > > Subject: Re: [marf] Additional dkim-reporting report type requests > > > > I agree such reports would be of interest, I just don't seem them as > > SPF reports. I think it'd be inappropriate to use the SPF type for an > > Authentication Results header in such cases too. > > RFC5451 did bring in "policy" as a possible result for SPF and Sender-ID > though. Possible fodder for discussion on that other mailing list. I think that's a bug in 5451. Scott K From vesely@tana.it Mon Jan 30 01:07:15 2012 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 2D97221F847E for ; Mon, 30 Jan 2012 01:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.615 X-Spam-Level: X-Spam-Status: No, score=-4.615 tagged_above=-999 required=5 tests=[AWL=0.104, 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 il7b54xjI5ni for ; Mon, 30 Jan 2012 01:07:14 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFFF21F8418 for ; Mon, 30 Jan 2012 01:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327914432; bh=09w0ZoHL5Ik7dIbZO0Ron2wckmOCScOqaWED1O0VJpg=; l=1189; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hNUO5KoyQ+WsXveaGx4aFyVr0jAgO+vwt3hMkmLHa8laSogDHkYIWq1M5cD2XU1RQ GVQMIMBaA7RHslnh7AJdtXZoZuw6tEo4tWQEhNuGijHhXUgDYscgHZ3oc6oIST/WqL yxye/56Jo5+mImhJUGWJVFmgqvD24FubX9rdwux8= 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, 30 Jan 2012 10:07:12 +0100 id 00000000005DC039.000000004F265DC0.00001063 Message-ID: <4F265DBF.8050302@tana.it> Date: Mon, 30 Jan 2012 10:07:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <5489781.FqGBdEXlYF@scott-latitude-e6320> <5677385.iYbtzkYjDx@scott-latitude-e6320> In-Reply-To: <5677385.iYbtzkYjDx@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] r= using localpart 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, 30 Jan 2012 09:07:15 -0000 On 30/Jan/12 05:59, Scott Kitterman wrote: > On Sunday, January 29, 2012 08:42:18 PM Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Scott Kitterman >> >>> I think the key is that the information about where reports need to go >>> needs to be found in DNS, not in the message, so if one takes the >>> signing domain and looks up the record there, it will give you the >>> localpart to go with that domain. The r= flag you propose would (AIUI) >>> be the trigger to do the DNS lookup to see if there's a DNS record >>> asking for reports. >>> >>> Is along the lines of what you intend? >> >> Specifically in the signer's DNS, but yes, that's right. > > Sounds good. Thanks, +1: doing so is more consistent with the generic idea that "domain claims some responsibility", and with the indication given in marf-as. However, flag-triggered lookups leave report requests to the signer's mercies. If this message had a forged ietf.org's signature, there is no way they can say they'd like to know about it. Perhaps, it's fair to say the verifier MAY lookup the _report RR anyway --which it would tend to do if it remembers r= from signatures it saw earlier. From iesg-secretary@ietf.org Mon Jan 30 06:54:17 2012 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 AAFDB21F8633; Mon, 30 Jan 2012 06:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 7NXiwPAEyhvf; Mon, 30 Jan 2012 06:54:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048F621F8570; Mon, 30 Jan 2012 06:54:17 -0800 (PST) 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.64p1 Message-ID: <20120130145417.21566.49118.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 06:54:17 -0800 Cc: marf@ietf.org Subject: [marf] Additional Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 30 Jan 2012 14:54:17 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' as a Proposed Standard During Last Call and IESG Evaluation, a significant change was made to the document to address the comments of reviewers, removing a recommended transformation mechanism and instead detailing how to select any of the acceptable transformation mechanisms. This additional last call is to solicit any comments on this change. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information that 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. From msk@cloudmark.com Mon Jan 30 09:25:46 2012 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 DF3EE21F8596 for ; Mon, 30 Jan 2012 09:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNpLqZqWC8fi for ; Mon, 30 Jan 2012 09:25:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7A21F8576 for ; Mon, 30 Jan 2012 09:25:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jan 2012 09:25:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 30 Jan 2012 09:25:45 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 30 Jan 2012 09:25:44 -0800 Thread-Topic: [marf] r= using localpart Thread-Index: AczfLpEmEU0acBLCR/iT/AEO3AcwDwARZSMg Message-ID: References: <5489781.FqGBdEXlYF@scott-latitude-e6320> <5677385.iYbtzkYjDx@scott-latitude-e6320> <4F265DBF.8050302@tana.it> In-Reply-To: <4F265DBF.8050302@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] r= using localpart 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, 30 Jan 2012 17:25:47 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, January 30, 2012 1:07 AM > To: marf@ietf.org > Subject: Re: [marf] r=3D using localpart >=20 > However, flag-triggered lookups leave report requests to the signer's > mercies. If this message had a forged ietf.org's signature, there is > no way they can say they'd like to know about it. Perhaps, it's fair > to say the verifier MAY lookup the _report RR anyway --which it would > tend to do if it remembers r=3D from signatures it saw earlier. Don't the ADSP reporting extensions cover this case? From msk@cloudmark.com Mon Jan 30 10:16:45 2012 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 2C48121F863B for ; Mon, 30 Jan 2012 10:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 WdxHZjHMAoNS for ; Mon, 30 Jan 2012 10:16:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 52FC021F8633 for ; Mon, 30 Jan 2012 10:16:44 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jan 2012 10:16:43 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 30 Jan 2012 10:16:44 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 30 Jan 2012 10:16:42 -0800 Thread-Topic: MARF in the media Thread-Index: Aczfe1Fw1jCRI1S/Qv6u085pshj05A== 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_F5833273385BB34F99288B3648C4F06F19C9A7DA68EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] MARF in the media 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, 30 Jan 2012 18:16:45 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA68EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.channelregister.co.uk/2012/01/30/dmarc_email_authentication_push= / DMARC is a proposal that builds on top of SPF, DKIM, and ARF and its extens= ions (the authfailure-report in particular) to crack down on spoofed-domain= phishing emails. It'll be coming to the IETF at some point in the future. If you do a search on http://news.google.com for "DMARC" you'll find severa= l other stories as well. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA68EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ht= tp://www.channelregister.co.uk/2012/01/30/dmarc_email_authentication_push/<= /a>

 

DMARC is a proposal that builds on top of SPF, DKIM, and ARF and its = extensions (the authfailure-report in particular) to crack down on spoofed-= domain phishing emails.  It’ll be coming to the IETF at some poi= nt in the future.

 

<= p class=3DMsoNormal>If you do a search on http://news.google.com for “DMARC” you’ll find seve= ral other stories as well.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA68EXCHC2corpclo_-- From dhc@dcrocker.net Mon Jan 30 10:29:23 2012 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 2C58D21F8693 for ; Mon, 30 Jan 2012 10:29:23 -0800 (PST) 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 Js5duQudCm0W for ; Mon, 30 Jan 2012 10:29:22 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 97B9D21F8652 for ; Mon, 30 Jan 2012 10:29:22 -0800 (PST) Received: from [22.177.53.150] (mdf0536d0.tmodns.net [208.54.5.223]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0UITBKU014208 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Jan 2012 10:29:21 -0800 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Dave Crocker Date: Mon, 30 Jan 2012 10:29:08 -0800 To: "Murray S. Kucherawy" , "marf@ietf.org" Message-ID: <064f7025-0e4d-4fe1-9573-a7800ad6aed9@email.android.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 30 Jan 2012 10:29:21 -0800 (PST) Subject: Re: [marf] MARF in the media 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, 30 Jan 2012 18:29:23 -0000 That is among the most carefully worded industry reporting I've seen. "Murray S. Kucherawy" wrote: >http://www.channelregister.co.uk/2012/01/30/dmarc_email_authentication_push/ > >DMARC is a proposal that builds on top of SPF, DKIM, and ARF and its >extensions (the authfailure-report in particular) to crack down on >spoofed-domain phishing emails. It'll be coming to the IETF at some >point in the future. > >If you do a search on http://news.google.com for "DMARC" you'll find >several other stories as well. > >-MSK >_______________________________________________ >marf mailing list >marf@ietf.org >https://www.ietf.org/mailman/listinfo/marf /d -- Dave Crocker bbiw.net via mobile From vesely@tana.it Mon Jan 30 11:04:26 2012 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 C982511E8093 for ; Mon, 30 Jan 2012 11:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.62 X-Spam-Level: X-Spam-Status: No, score=-4.62 tagged_above=-999 required=5 tests=[AWL=0.099, 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 r1n7g6zB9wOc for ; Mon, 30 Jan 2012 11:04:26 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5911E8081 for ; Mon, 30 Jan 2012 11:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327950264; bh=DwFh04plcoUBh3p5BWX8A44hb0QyBOS2v4dwO4dERYo=; l=562; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EveZWpJSP4pRsZE30aol63t3N7/JLoEU8x7q7/9NPC60jzKux2LyCBkqOGQTgDRn0 UJwIZmhcivEmKOJ2/A2VJn3ViuSB8/C6UxKG7iS0dudrlyPfgkD44HQV0WDwb2vLCY NSRZw4zJDcEmMS+DZwM1W5na91BJM/5oDDG/mC/g= 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, 30 Jan 2012 20:04:24 +0100 id 00000000005DC046.000000004F26E9B8.00007467 Message-ID: <4F26E9B8.7060706@tana.it> Date: Mon, 30 Jan 2012 20:04:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <5489781.FqGBdEXlYF@scott-latitude-e6320> <5677385.iYbtzkYjDx@scott-latitude-e6320> <4F265DBF.8050302@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] r= using localpart 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, 30 Jan 2012 19:04:26 -0000 On 30/Jan/12 18:25, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> However, flag-triggered lookups leave report requests to the signer's >> mercies. If this message had a forged ietf.org's signature, there is >> no way they can say they'd like to know about it. Perhaps, it's fair >> to say the verifier MAY lookup the _report RR anyway --which it would >> tend to do if it remembers r= from signatures it saw earlier. > > Don't the ADSP reporting extensions cover this case? Yes, but only for the author's domain. From msk@cloudmark.com Mon Jan 30 11:12:07 2012 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 7665021F8603 for ; Mon, 30 Jan 2012 11:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPcajndD6MEP for ; Mon, 30 Jan 2012 11:12:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7EB21F85FF for ; Mon, 30 Jan 2012 11:12:07 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jan 2012 11:12:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 30 Jan 2012 11:12:06 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 30 Jan 2012 11:12:06 -0800 Thread-Topic: [marf] r= using localpart Thread-Index: Aczfgf5iJsVkI1XjRiii533pBFArgAAAORUA Message-ID: References: <5489781.FqGBdEXlYF@scott-latitude-e6320> <5677385.iYbtzkYjDx@scott-latitude-e6320> <4F265DBF.8050302@tana.it> <4F26E9B8.7060706@tana.it> In-Reply-To: <4F26E9B8.7060706@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] r= using localpart 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, 30 Jan 2012 19:12:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, January 30, 2012 11:04 AM > To: marf@ietf.org > Subject: Re: [marf] r=3D using localpart >=20 > >> However, flag-triggered lookups leave report requests to the signer's > >> mercies. If this message had a forged ietf.org's signature, there is > >> no way they can say they'd like to know about it. Perhaps, it's fair > >> to say the verifier MAY lookup the _report RR anyway --which it would > >> tend to do if it remembers r=3D from signatures it saw earlier. > > > > Don't the ADSP reporting extensions cover this case? >=20 > Yes, but only for the author's domain. I don't think I object to identifying the use case, adding that MAY, and th= en pointing out that it causes additional DNS load. Others? From msk@cloudmark.com Mon Jan 30 11:13:31 2012 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 A918411E8093 for ; Mon, 30 Jan 2012 11:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 9dl5fk86dxij for ; Mon, 30 Jan 2012 11:13:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34111E8081 for ; Mon, 30 Jan 2012 11:13:31 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jan 2012 11:13:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 30 Jan 2012 11:13:30 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 30 Jan 2012 11:13:29 -0800 Thread-Topic: draft-ietf-marf-as -- any other review comments? Thread-Index: Aczfgz/TwKGN+m/qQJOPd12WxyN4+Q== 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_F5833273385BB34F99288B3648C4F06F19C9A7DA6DEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] draft-ietf-marf-as -- any other review comments? 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, 30 Jan 2012 19:13:31 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA6DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there any other outstanding review comments on the applicability statem= ent? Do people think it's ready for a working group Last Call? We're still fiddling with the -reporting documents, so we can WGLC those a = bit later. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA6DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are there any ot= her outstanding review comments on the applicability statement?  Do pe= ople think it’s ready for a working group Last Call?

 

We’re st= ill fiddling with the –reporting documents, so we can WGLC those a bi= t later.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DA6DEXCHC2corpclo_-- From internet-drafts@ietf.org Mon Jan 30 11:36:50 2012 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 0F4CF1F0C4A; Mon, 30 Jan 2012 11:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 EowmtVRGmnoZ; Mon, 30 Jan 2012 11:36:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB88F1F0C42; Mon, 30 Jan 2012 11:36:49 -0800 (PST) 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.64p1 Message-ID: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 11:36:49 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 30 Jan 2012 19:36:50 -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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-07.txt Pages : 23 Date : 2012-01-30 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-07.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-dkim-reporting-07.txt From msk@cloudmark.com Mon Jan 30 11:39:16 2012 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 65B6E21F8716 for ; Mon, 30 Jan 2012 11:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5BLfeDtxId8 for ; Mon, 30 Jan 2012 11:39:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4521F8715 for ; Mon, 30 Jan 2012 11:39:15 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 30 Jan 2012 11:39:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 30 Jan 2012 11:39:15 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 30 Jan 2012 11:39:14 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-07.txt Thread-Index: AczfhopvTzTzu+N0T52M2UFT1IeGawAABH8g Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> In-Reply-To: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 30 Jan 2012 19:39: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, January 30, 2012 11:37 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-dkim-reporting-07.txt >=20 >=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 : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-07.txt > Pages : 23 > Date : 2012-01-30 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. - addresses Alessandro's last point about fraudulent signature detection - fix up the examples, and split the first one since DKIM reporting is now = split into two parts - change "rd=3Ddomain" to "r=3Dy" in the signature - add "policy" and "other" report types From shmuel+gen@patriot.net Mon Jan 30 17:14:27 2012 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 C345C21F858E for ; Mon, 30 Jan 2012 17:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 HemaH87ahnvF for ; Mon, 30 Jan 2012 17:14:27 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12421F8540 for ; Mon, 30 Jan 2012 17:14:26 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.115]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 1ABD6F58089 for ; Mon, 30 Jan 2012 20:00:06 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 30 Jan 2012 20:15:48 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120131010007.1ABD6F58089@smtp.patriot.net> Subject: Re: [marf] draft-ietf-marf-as -- any other review comments? 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, 31 Jan 2012 01:14:27 -0000 In , on 01/30/2012 at 11:13 AM, "Murray S. Kucherawy" said: >Do people think it's ready for a working group Last Call? Yes. -- 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 vesely@tana.it Tue Jan 31 07:32:39 2012 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 CCD5511E80A5 for ; Tue, 31 Jan 2012 07:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=0.097, 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 m8UgeNasht0k for ; Tue, 31 Jan 2012 07:32:39 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 28BAF11E80A4 for ; Tue, 31 Jan 2012 07:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328023957; bh=ff3wUkTVcdXmaEGlQZ4Yw1ty6xhevWgPICnw7Ks0jxk=; l=688; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YkRux8X3SH5kQAj4UqbxfvjdNhWzgixMQ3iZmS2pq69L0ZCIq7bPAHRz0XmnJ4838 lMggGg4zXkQ/Z5ZTcTKDwakZsbSdLzDwhAx/khv40tIeHwE7wBqIb49Mm1uANBONpR 82DBJQoLUgEWt7V4Bsef0njNTS4iAt+7dMuD6rzU= 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, 31 Jan 2012 16:32:37 +0100 id 00000000005DC048.000000004F280995.000012E1 Message-ID: <4F280993.2060207@tana.it> Date: Tue, 31 Jan 2012 16:32:35 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120126061500.20272.40574.idtracker@ietfa.amsl.com> <4F22F846.1070709@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-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, 31 Jan 2012 15:32:39 -0000 On 27/Jan/12 23:01, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> *Updates 5965* >> >> It doesn't seem to actually update the format. If the use of ARF is >> meant to be updated, we probably need a section where that update is >> identified. > > It's my understanding that "RFCx updates RFCy" means "if you are > implementing RFCy, you really also need to read RFCx". Agreed, that's more or less what Section 12 of RFC 2223 says. > For an applicability statement, therefore, this is typical. That's the point I don't get. If anything, I'd say marf-as updates RFC 6449. RFC 5965 implementations might well do without this I-D, IMHO. From internet-drafts@ietf.org Tue Jan 31 09:29:19 2012 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 A1C3611E80A5; Tue, 31 Jan 2012 09:29:19 -0800 (PST) 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 Rbx3P+++XyOA; Tue, 31 Jan 2012 09:29:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07311E8080; Tue, 31 Jan 2012 09:29:19 -0800 (PST) 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.64p1 Message-ID: <20120131172919.18764.97241.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 09:29:19 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-05.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, 31 Jan 2012 17:29:19 -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 : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-05.txt Pages : 9 Date : 2012-01-31 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-05.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-as-05.txt From msk@cloudmark.com Tue Jan 31 09:34:19 2012 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 3E46121F8547 for ; Tue, 31 Jan 2012 09:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYREwWhvCi88 for ; Tue, 31 Jan 2012 09:34:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0221F8543 for ; Tue, 31 Jan 2012 09:34:18 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 09:34:18 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 31 Jan 2012 09:34:18 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 31 Jan 2012 09:34:17 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-05.txt Thread-Index: AczgPd9ObfcFYhcUSuSDBdGAohn1bQAAJlKQ Message-ID: References: <20120131172919.18764.97241.idtracker@ietfa.amsl.com> In-Reply-To: <20120131172919.18764.97241.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-as-05.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, 31 Jan 2012 17:34:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Tuesday, January 31, 2012 9:29 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-as-05.txt >=20 >=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 : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-05.txt > Pages : 9 > Date : 2012-01-31 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. Incorporates the last of the recent feedback. Barry is shepherding this document, so I'll leave it to him to run the Work= ing Group Last Call. -MSK From vesely@tana.it Tue Jan 31 11:08:40 2012 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 144B711E8089 for ; Tue, 31 Jan 2012 11:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, 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 SXbRm9agFDD4 for ; Tue, 31 Jan 2012 11:08:39 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A63A511E8072 for ; Tue, 31 Jan 2012 11:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328036915; bh=+f+MMRspc386R/6Uj110Co/RVjd2mjmOmTbKyz4gnTg=; l=4837; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gToKzLjTh4Q9C6lyeqcadmCYTpU2DACiCoZhg9SyxhvNh2yIBJUfqMrfeeukrOrgc PS+jaD5x7uDpiIhwaDP+129SVrcfKtfXihbNJ15d2fnNEk8WGkSz5cZDuFA79MKE+0 I+0ySL+2/h9cbObNo3ujXIvSNbNYNtlMLGybGd3M= 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, 31 Jan 2012 20:08:35 +0100 id 00000000005DC039.000000004F283C33.000047E2 Message-ID: <4F283C32.7070206@tana.it> Date: Tue, 31 Jan 2012 20:08:34 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 31 Jan 2012 19:08:40 -0000 On 30/Jan/12 20:39, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of internet-drafts@ietf.org > >> Filename : draft-ietf-marf-dkim-reporting-07.txt > > - addresses Alessandro's last point about fraudulent signature detection > > - fix up the examples, and split the first one since DKIM reporting is now split into two parts > > - change "rd=domain" to "r=y" in the signature > > - add "policy" and "other" report types Does this I-D update RFCs 5617 and 6376? I'm just trying to learn... 1. *Introduction* How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too? 2. *Definitions* I'd add a short section to define /report generator/, e.g. A report generator is an entity that generates and sends reports. For the scope of this memo, the term refers to Verifiers, as defined in Section 2.2 of [DKIM], designed to also generate authentication failure reports according to this specification. 3.2. *DKIM Reporting TXT Record* s/The Verifier (if it supports this extension)/A report generator/ if you inserted that definition. (For capitalization, I found eight occurrences of "Verifier" and just four of "verifier".) In the definition of rp=, maybe s/The value is an integer value/The value is a decimal integer/. If you do, the same applies to Section 4. In the definition of rr=, you need to add "d", "p", and "o" to rep-rr-type. Same applies to Section 4. In the definition of rs=, it may be worth noting that the reply code should not be part of the string. BTW, why isn't the rs= string actionable even in the absence of ra=? 3.3. *DKIM Reporting Algorithm* Typo: "on a message fails". If you added the above definition, you may replace this text: The following algorithm, or one semantically equivalent to it, MUST be applied when an implementation is equipped to generate reports in compliance with this specification and its evaluation of the DKIM- Signature header field (see [DKIM]) on a message fails for some reason. with something like Report generators MUST apply the following algorithm, or one semantically equivalent to it, on each DKIM-Signature header field whose verification fails for some reason. The last paragraph of this section is rather convoluted. In order to simplify it, I would modify the first step of the algorithm to read like so: 1. If the DKIM-Signature field did not contain a valid "r=" tag and if there are no different out-of-band arrangements, terminate. I don't attempt to actually simplify that paragraph, but note that it might refer to Section 8.5 (Automatic Generation) for out-of-band arrangements. Murray, the "previous implementations" that the subsequent paragraphs refer to are a rather obscure entity. They seem to be internal notes that somehow happened to make their way into the published spec. 4. *Optional Reporting Address for DKIM-ADSP* See notes above for rp= and rr=. 5. *Requested Reports* s/this these/these/ 5.2. *Requested Reports for DKIM ADSP Failures* s/[ADSP]-related reason/[ADSP]-related failure reason/ 6.2. *Envelope Sender Selection* In our case, mail loops may occur among _report addresses. For example, bad signature => dkim-report with bad SPF => spf-report with bad DKIM-Signature => dkim-report with bad SPF... Perhaps, the I-D could say that, for ARF messages of any kind, the r= tag of a DKIM-Signature MUST be ignored and automatic report generation MUST NOT take place. Out-of-band arrangements can still provide for manual ways to report failures of the reporting mechanism itself. Typo: s/wil pass/will pass/ 8.1. *Inherited Considerations* [I-D.MARF-AUTHFAILURE-REPORT] is missing here. 8.5. *Automatic Generation* The last paragraph, about out-of-band arrangements, seems to defy this I-D's very purpose of automating reporting. Considering what marf-as is going to say on unsolicited reports, I'd s/create/persist sending/. The resulting wording implies an upper limit for reports generated automatically that are destined to a given domain. That, in turn, implies maintaining a domain-indexed database of what's going on with the email. In this case we may count the overall number of reports sent with no out-of-band arrangement. 8.6. *Reporting Multiple Incidents* This section seems disconcerting, especially the middle paragraph. Since the rp= tag is specified with utter sharpness, implementations of the logarithmic approach seem to be out of the way. Perhaps, we can recommend a switch-to-manual upper limit instead, counting the number of reports sent per day (or per hour), using the same database as above. To suspend report generation for some time after an RCPT rejection of the reporting address might also provide for a safe approach. From msk@cloudmark.com Tue Jan 31 12:00:48 2012 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 5690911E815E for ; Tue, 31 Jan 2012 12:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ojisxbsYhbv for ; Tue, 31 Jan 2012 12:00:47 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B821411E817E for ; Tue, 31 Jan 2012 12:00:42 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 12:00:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 31 Jan 2012 12:00:41 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 31 Jan 2012 12:00:41 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt Thread-Index: AczgS8AdG6iGIZObR02TxwFzoXwYzgAAChoA Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> In-Reply-To: <4F283C32.7070206@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] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 31 Jan 2012 20:00:48 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, January 31, 2012 11:09 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt >=20 > Does this I-D update RFCs 5617 and 6376? I'm just trying to learn... No. Someone implementing those isn't encouraged to be familiar with this w= ork. It's purely an optional extension. > 1. *Introduction* >=20 > How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too? Seems reasonable; same for the spf-reporting draft. Scott? > 2. *Definitions* >=20 > I'd add a short section to define /report generator/, e.g. >=20 > A report generator is an entity that generates and sends reports. > For the scope of this memo, the term refers to Verifiers, as > defined in Section 2.2 of [DKIM], designed to also generate > authentication failure reports according to this specification. Seems reasonable; same for the spf-reporting draft. Scott? > 3.2. *DKIM Reporting TXT Record* >=20 > s/The Verifier (if it supports this extension)/A report generator/ if > you inserted that definition. (For capitalization, I found eight > occurrences of "Verifier" and just four of "verifier".) OK, and capitalized the four lowercase instances. > In the definition of rp=3D, maybe s/The value is an integer value/The > value is a decimal integer/. If you do, the same applies to Section 4. I just dropped the second "value". Saying "the value is an integer" is fin= e. > In the definition of rr=3D, you need to add "d", "p", and "o" to rep-rr- > type. Same applies to Section 4. Fixed. > In the definition of rs=3D, it may be worth noting that the reply code > should not be part of the string. It says "included", which to me makes it clear that it goes in the reply, n= ot that it is the reply. > BTW, why isn't the rs=3D string actionable even in the absence of ra=3D? Good point; fixed. > 3.3. *DKIM Reporting Algorithm* >=20 > Typo: "on a message fails". If you added the above definition, you may > replace this text: >=20 > The following algorithm, or one semantically equivalent to it, MUST > be applied when an implementation is equipped to generate reports in > compliance with this specification and its evaluation of the DKIM- > Signature header field (see [DKIM]) on a message fails for some > reason. >=20 > with something like >=20 > Report generators MUST apply the following algorithm, or one > semantically equivalent to it, on each DKIM-Signature header field > whose verification fails for some reason. Done. > The last paragraph of this section is rather convoluted. In order to > simplify it, I would modify the first step of the algorithm to read > like so: >=20 > 1. If the DKIM-Signature field did not contain a valid "r=3D" tag > and if there are no different out-of-band arrangements, > terminate. >=20 > I don't attempt to actually simplify that paragraph, but note that it > might refer to Section 8.5 (Automatic Generation) for out-of-band > arrangements. I think that falls under "semantically equivalent", so I'd prefer not to ch= ange it. > Murray, the "previous implementations" that the subsequent paragraphs > refer to are a rather obscure entity. They seem to be internal notes > that somehow happened to make their way into the published spec. They're there deliberately to explain the choices made with this algorithm,= especially when the people reading it might be familiar with pre-RFC imple= mentations of DKIM reporting. > 4. *Optional Reporting Address for DKIM-ADSP* >=20 > See notes above for rp=3D and rr=3D. Fixed. > 5. *Requested Reports* >=20 > s/this these/these/ It's one list, so "this" is correct. > 5.2. *Requested Reports for DKIM ADSP Failures* >=20 > s/[ADSP]-related reason/[ADSP]-related failure reason/ I think that's redundant, but harmless, so sure. > 6.2. *Envelope Sender Selection* >=20 > In our case, mail loops may occur among _report addresses. For > example, bad signature =3D> dkim-report with bad SPF =3D> spf-report with > bad DKIM-Signature =3D> dkim-report with bad SPF... >=20 > Perhaps, the I-D could say that, for ARF messages of any kind, the r=3D > tag of a DKIM-Signature MUST be ignored and automatic report generation > MUST NOT take place. Out-of-band arrangements can still provide for > manual ways to report failures of the reporting mechanism itself. I think the existing text in this section already covers that case, especia= lly the first SHOULD. I also think a general admonishment of this type is = not appropriate in this subsection because it has nothing at all to do with= the envelope sender. So I'll add it in its own subsection. > Typo: s/wil pass/will pass/ Fixed. > 8.1. *Inherited Considerations* >=20 > [I-D.MARF-AUTHFAILURE-REPORT] is missing here. Fixed. > 8.5. *Automatic Generation* >=20 > The last paragraph, about out-of-band arrangements, seems to defy this > I-D's very purpose of automating reporting. Considering what marf-as > is going to say on unsolicited reports, I'd s/create/persist sending/. > The resulting wording implies an upper limit for reports generated > automatically that are destined to a given domain. That, in turn, > implies maintaining a domain-indexed database of what's going on with > the email. In this case we may count the overall number of reports > sent with no out-of-band arrangement. What this section is trying to say is that people should not implement syst= ems that do this kind of reporting work by default. It can create a ton of= traffic due to simple infrastructure problems at the signer/sender, for ex= ample. The obvious mitigation, rate limiting the generation of reports, is= n't an ideal solution for various reasons. I don't think this harms what -as is saying about unsolicited reports. Thi= s document discusses a specific kind of feedback and thus this is not a sta= tement about ARF in general. > 8.6. *Reporting Multiple Incidents* >=20 > This section seems disconcerting, especially the middle paragraph. > Since the rp=3D tag is specified with utter sharpness, implementations of > the logarithmic approach seem to be out of the way. Perhaps, we can > recommend a switch-to-manual upper limit instead, counting the number > of reports sent per day (or per hour), using the same database as > above. >=20 > To suspend report generation for some time after an RCPT rejection of > the reporting address might also provide for a safe approach. Since it's Security Considerations, none of this is normative. It's just a= suggestion for handling large volumes of reports. Your two are equally vi= able, so it would be fine to add them as well, especially since the latter = one talks about a way to do rate limiting at the report receiver rather tha= n relying on the report generator to do it all. So I'll add this: Other rate limiting provisions might be conside= red, including detection of a temporary failure response from the report destination and thus halting report generation to that destination for some period, or simply imposing or negotiat= ing a hard limit on the number of reports to be sen= t to a particular receiver in a given time frame. -MSK From barryleiba.mailing.lists@gmail.com Tue Jan 31 13:18:34 2012 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 0FEAA21F84BD; Tue, 31 Jan 2012 13:18:34 -0800 (PST) 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.034, 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 YE4-sqyPgQ8l; Tue, 31 Jan 2012 13:18:33 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3F21F84AF; Tue, 31 Jan 2012 13:18:33 -0800 (PST) Received: by yenm3 with SMTP id m3so313733yen.31 for ; Tue, 31 Jan 2012 13:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=hc/QuKFNuYYCWDms/nDGSnwwwWsHXNqO6L/YbgQlALI=; b=j6OTmoF5pRLVTG9mb6J/unC+Zdlb1TBUoDvLGDQ5SLvGA5FmIrhrlSFS38vW2Zw7ij 0lOr6mmXIgdyW9qWRmoS80MBuixnDGHjmnMs8bACE3AL7B1RFBlE7zoeag8QXa9Ev7P9 deCY9iF2RVocfT63l/QCjYHar5SqNb7ToGloE= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr37009987yhh.57.1328044712774; Tue, 31 Jan 2012 13:18:32 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Tue, 31 Jan 2012 13:18:32 -0800 (PST) Date: Tue, 31 Jan 2012 16:18:32 -0500 X-Google-Sender-Auth: XHxskVSIsDNnBnz1RhFsoJ4OxfY Message-ID: From: Barry Leiba To: internet-drafts@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org, i-d-announce@ietf.org Subject: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 21:18:34 -0000 Here begins a last call for the MARF working group on the subject document, detailed below. Please make any comments you have on this version no later than 10 Feb 2012. That's a week and a half, which should be enough for this active and vocal group, wot? Please do not wait until the last minute, and especially do not wait until the document goes to the IESG. You will be beaten with a rubber truncheon. > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Messaging Abuse Reporting Format Working > Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Creation and Use of Email Feed= back Reports: An Applicability > Statement for the Abuse Reporting Format (ARF) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J.D. Falk > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0M. Kucherawy > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-marf-as-05.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 9 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-31 > > =A0 RFC 5965 defines an extensible, machine-readable format intended for > =A0 mail operators to report feedback about received email to other > =A0 parties. =A0This document describes common methods for utilizing this > =A0 format for abuse reporting. =A0Mailbox Providers of any size, mail > =A0 sending entities, and end users can use these methods as a basis to > =A0 create procedures that best suit them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-marf-as-05.txt From barryleiba.mailing.lists@gmail.com Tue Jan 31 13:23:34 2012 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 ADA6711E8097 for ; Tue, 31 Jan 2012 13:23:34 -0800 (PST) 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.033, 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 h+anoiKfPPMy for ; Tue, 31 Jan 2012 13:23:34 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3211E8095 for ; Tue, 31 Jan 2012 13:23:33 -0800 (PST) Received: by ghbg16 with SMTP id g16so326019ghb.31 for ; Tue, 31 Jan 2012 13:23:33 -0800 (PST) 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=SSxQYeIZqWfUPb2RCfnkR2ImGlDaKrW9CNjutNR9dl4=; b=F5+RbsaVHEgiqh8RCNbrZMD3pjxxZ10pQtaags1wxmxequ3frvFyzlTdPEcvpNCwQ2 KxxfzDnA06P9momRy2kutG+TZ7LHPhuoh2n40fsDEhbSMJYsDwJAS4PEFUa4516sdbEU wbWzonC7MjegWLtQBjPNAHlazqvZb46ciXue4= MIME-Version: 1.0 Received: by 10.101.145.5 with SMTP id x5mr9907913ann.30.1328045013451; Tue, 31 Jan 2012 13:23:33 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Tue, 31 Jan 2012 13:23:33 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Jan 2012 16:23:33 -0500 X-Google-Sender-Auth: Bc4wwbbIGQu4u9QdrW0BmLJsxgs Message-ID: From: Barry Leiba To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 21:23:34 -0000 I am re-posting this without the extra recipients; please reply to THIS message, and NOT to that other one. We can discuss later who, exactly, should get the truncheon treatment here....... --- Here begins a last call for the MARF working group on the subject document, detailed below. Please make any comments you have on this version no later than 10 Feb 2012. That's a week and a half, which should be enough for this active and vocal group, wot? Please do not wait until the last minute, and especially do not wait until the document goes to the IESG. You will be beaten with a rubber truncheon. > 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 : Creation and Use of Email Feedback Reports: An Applicability > Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-05.txt > Pages : 9 > Date : 2012-01-31 > > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-marf-as-05.txt From msk@cloudmark.com Tue Jan 31 13:23:50 2012 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 A485111E8095 for ; Tue, 31 Jan 2012 13:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Puzc2fDFeSVd for ; Tue, 31 Jan 2012 13:23:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B47D921F86D7 for ; Tue, 31 Jan 2012 13:23:49 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 13:23:49 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 31 Jan 2012 13:23:49 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 31 Jan 2012 13:23:48 -0800 Thread-Topic: WGLC pending on the reporting documents Thread-Index: AczgXp74RJAXTysMSRKOaIlFvc7A4A== 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_F5833273385BB34F99288B3648C4F06F19C9A7DAC8EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] WGLC pending on the reporting documents 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, 31 Jan 2012 21:23:50 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DAC8EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to initiate a Working Group Last Call on the SPF and DKIM reportin= g documents sometime next week. Please review the current versions (I will= post an update tonight including Alessandro's latest feedback) and post co= mments before then. I'd like the mechanisms and overall document structure= to be stable before WGLC, but we can nit about wording during WGLC if nece= ssary. As Barry said, we definitely do not want changes suggested after IE= TF LC, so please get them in early. Ideally for all three documents we'd like to see the "I've read this, I agr= ee with it, ship it" kind of thing; "+1" type stuff is better than nothing,= but silence sounds a lot like apathy to reviewers outside the working grou= p, and we don't want that. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DAC8EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like t= o initiate a Working Group Last Call on the SPF and DKIM reporting document= s sometime next week.  Please review the current versions (I will post= an update tonight including Alessandro’s latest feedback) and post c= omments before then.  I’d like the mechanisms and overall docume= nt structure to be stable before WGLC, but we can nit about wording during = WGLC if necessary.  As Barry said, we definitely do not want changes s= uggested after IETF LC, so please get them in early.

 

Ideally for all thre= e documents we’d like to see the “I’ve read this, I agree= with it, ship it” kind of thing; “+1” type stuff is bett= er than nothing, but silence sounds a lot like apathy to reviewers outside = the working group, and we don’t want that.

 

Thanks,

<= p class=3DMsoNormal>-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DAC8EXCHC2corpclo_-- From johnl@iecc.com Tue Jan 31 16:37:21 2012 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 49CFF11E8095 for ; Tue, 31 Jan 2012 16:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.359 X-Spam-Level: X-Spam-Status: No, score=-108.359 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_20=-0.74, 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 ZCMcJFglJVIG for ; Tue, 31 Jan 2012 16:37:20 -0800 (PST) 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 ADB8911E8087 for ; Tue, 31 Jan 2012 16:37:20 -0800 (PST) Received: (qmail 40120 invoked from network); 1 Feb 2012 00:37:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Feb 2012 00:37:19 -0000 Date: 1 Feb 2012 00:36:57 -0000 Message-ID: <20120201003657.27719.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4F22EC78.1050704@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-07.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, 01 Feb 2012 00:37:21 -0000 >> For the record: Apart from that, you're happy with the changes since the DISCUSS? Yes, getting rid of the extra advice was the right fix. Ship it. R's, John From dhc@dcrocker.net Tue Jan 31 19:28:26 2012 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 6B6E121F8522; Tue, 31 Jan 2012 19:28:26 -0800 (PST) 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 UvT4WGE7BBhL; Tue, 31 Jan 2012 19:28:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C1FDD21F851D; Tue, 31 Jan 2012 19:28:25 -0800 (PST) Received: from [10.0.0.73] (wsip-68-101-40-225.dc.dc.cox.net [68.101.40.225]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q113SC4W028179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 19:28:20 -0800 Message-ID: <4F28B149.6020408@dcrocker.net> Date: Tue, 31 Jan 2012 22:28:09 -0500 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 31 Jan 2012 19:28:21 -0800 (PST) Cc: i-d-announce@ietf.org, internet-drafts@ietf.org, marf@ietf.org Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 01 Feb 2012 03:28:26 -0000 On 1/31/2012 4:18 PM, Barry Leiba wrote: > Here begins a last call for the MARF working group on the subject > document, detailed below. Please make any comments you have on this > version no later than 10 Feb 2012. That's a week and a half, which > should be enough for this active and vocal group, wot? Please do not > wait until the last minute, and especially do not wait until the > document goes to the IESG. You will be beaten with a rubber > truncheon. rubber? wimp. +1 for approving the spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Tue Jan 31 21:07:30 2012 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 0347F21F8491; Tue, 31 Jan 2012 21:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 kIoyb88HxGgQ; Tue, 31 Jan 2012 21:07:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8942B21F8483; Tue, 31 Jan 2012 21:07:29 -0800 (PST) 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.64p1 Message-ID: <20120201050729.17249.52858.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 21:07:29 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08.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, 01 Feb 2012 05:07: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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-08.txt Pages : 24 Date : 2012-01-31 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-08.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-dkim-reporting-08.txt From msk@cloudmark.com Tue Jan 31 21:09:14 2012 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 7376721F848B for ; Tue, 31 Jan 2012 21:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deNlLNbpLDvy for ; Tue, 31 Jan 2012 21:09:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E69B021F8489 for ; Tue, 31 Jan 2012 21:09:13 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 21:09:12 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 31 Jan 2012 21:09:12 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 31 Jan 2012 21:09:15 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-08.txt Thread-Index: Aczgn21QKIg5GGOnTzqQjxKzqD4lWgAACJlg Message-ID: References: <20120201050729.17249.52858.idtracker@ietfa.amsl.com> In-Reply-To: <20120201050729.17249.52858.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08.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, 01 Feb 2012 05:09:14 -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: Tuesday, January 31, 2012 9:07 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-dkim-reporting-08.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 : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-08.txt > Pages : 24 > Date : 2012-01-31 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Incorporates Alessandro's document/language suggestions. No protocol chang= es. -MSK From sklist@kitterman.com Tue Jan 31 21:13:45 2012 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 991C911E8095 for ; Tue, 31 Jan 2012 21:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRFpkY7jarQc for ; Tue, 31 Jan 2012 21:13:44 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0111E80B3 for ; Tue, 31 Jan 2012 21:13:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 83BFA20E40F5; Wed, 1 Feb 2012 00:13:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328073223; bh=irk1cx63czFzkNbdRUGC8xwhGzstuizD2kE1A/yNOXY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=P2zG32WIml+Zuh28SJGreeUL3O5MSid8JUBJYjXf0wY6Mr4rYsPG1Aqxi9OaOHWRa 9MSkwMaYslticG2LQzYAFs66GceKFQ4Gp+7m8VW7RJrRt5tQuML8dUwO/2ysFM0HIp lI0u7frNwh2VNzKZCiNK1jcZthcVgbjjx0GrhEW0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6497D20E405D; Wed, 1 Feb 2012 00:13:43 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 01 Feb 2012 00:13:42 -0500 Message-ID: <2138569.ncAi74kg8P@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 01 Feb 2012 05:13:45 -0000 On Tuesday, January 31, 2012 12:00:41 PM Murray S. Kucherawy wrote: ... > Seems reasonable; same for the spf-reporting draft. Scott? ... It's really late and I'm very tired. Just tell me which ones you did in your new draft and I'll follow your lead. I'm sure it will be fine. On the off chance it's not, I'll let you know. Scott K From msk@cloudmark.com Tue Jan 31 21:21:25 2012 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 A1AEE21F845E for ; Tue, 31 Jan 2012 21:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 UHsJC+GSb7+B for ; Tue, 31 Jan 2012 21:21:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C81F521F845A for ; Tue, 31 Jan 2012 21:21:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 21:21:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 31 Jan 2012 21:21:23 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 31 Jan 2012 21:21:26 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt Thread-Index: AczgoEesN+IFDghaTkqxr/OMUvYcCgAAMuYw Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <2138569.ncAi74kg8P@scott-latitude-e6320> In-Reply-To: <2138569.ncAi74kg8P@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] I-D Action: draft-ietf-marf-dkim-reporting-07.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, 01 Feb 2012 05:21:25 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, January 31, 2012 9:14 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt >=20 > On Tuesday, January 31, 2012 12:00:41 PM Murray S. Kucherawy wrote: > ... > > Seems reasonable; same for the spf-reporting draft. Scott? > ... >=20 > It's really late and I'm very tired. Just tell me which ones you did > in your new draft and I'll follow your lead. I'm sure it will be fine. > On the off chance it's not, I'll let you know. So do it tomorrow. :-) The easiest thing to do is probably to pull it up in the datatracker, click= the History tab, and request a diff from the -07 version. The datatracker link is http://datatracker.ietf.org/doc/draft-ietf-marf-dki= m-reporting/. -MSK