From prvs=887ab8cb2=fmartin@linkedin.com Mon Jul 1 15:11:42 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D0911E82A4 for ; Mon, 1 Jul 2013 15:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 PU5UW12WcOBJ for ; Mon, 1 Jul 2013 15:11:38 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5711E829B for ; Mon, 1 Jul 2013 15:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372716698; x=1404252698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jZ9QOyTRzWljtsPInUrYSrPk62onzjdP1Jcsr54AUig=; b=BKsthO5hucnfADb1q3m12E7eP/AzI68OA/YiCowk/4WLsYrdeHXeR1zI 8u0M/58CawGsEukCpT24aOMNxxXsom5YEhR5v8hWVOuE5uH/lfPn8KBy6 bst1mJ/3mlkg7AHkZy8MbfIXGtNpKvaTsgC/STMr6raW4N8OE9ghQ8Xox Q=; X-IronPort-AV: E=Sophos;i="4.87,976,1363158000"; d="scan'208";a="54396573" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 1 Jul 2013 15:11:19 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 15:11:19 -0700 From: Franck Martin To: John Levine Thread-Topic: [dmarc-ietf] DMARC BoF at IETF 87, Berlin Thread-Index: AQHOdCfI9b5jenK0uUGXlrIwu64RYJlL68eAgAAqogCAAAVjgIACw5YAgAADJACAAC8KAIAAB2uAgAAH+YCAAAYRAIAAAQsAgAAjaoCAAZFxAA== Date: Mon, 1 Jul 2013 22:11:19 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53395A88@ESV4-MBX01.linkedin.biz> References: <20130630221443.71098.qmail@joyce.lan> In-Reply-To: <20130630221443.71098.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <2DED75D38A128A4AACDF504410540FE4@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 22:11:42 -0000 On Jun 30, 2013, at 3:14 PM, John Levine wrote: >> And there have recently been some detail, independent reviews that >> are prompted a document revision that will be issued within days. >=20 > While I don't doubt that the next version will be better, I think that > the dmarc.org group needs to make up its mind and either get a > reasonably chartered IETF WG that says no gratuitous changes to the > bits, contribute all of the drafts to the WG, and take its chances. or > else contribute none of them and just send them in via the independent > stream. >=20 > I understand why you might want to tell the IETF that it can only > change the minor documents, not the major one, but I don't see why the > IETF would be interested. >=20 This is my take on the process so far. The spec has been handed over to IETF already. IETF can do what it likes wi= th it. So I don't think the DMARC.org group worries (much) about what can b= e changed or not. The question is: is there sufficiently enough work to be done in the curren= t spec (besides editorial) that warrants an IETF WG to work on the spec? So far the answer to that question is no. The reason: even has a non IETF W= G, the DMARC.org group has been listening to all comments and the deploymen= t experience has shown the mechanism is robust across multiple segments. So the logic conclusion: the spec needs to be AD sponsored to be on the sta= ndard track. But I realize this will not stop conspiracy theories. If I'm mistaken, please review the spec and answer the question with specif= ics. From johnl@taugh.com Mon Jul 1 15:59:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367E21F9FF6 for ; Mon, 1 Jul 2013 15:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGdnuqtVV0pd for ; Mon, 1 Jul 2013 15:59:20 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D2ECF21F90EF for ; Mon, 1 Jul 2013 15:58:57 -0700 (PDT) Received: (qmail 47090 invoked from network); 1 Jul 2013 22:58:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b7f1.51d209ab.k1307; bh=j3WqiAcjwJWagm5rLSFWJhmEcdW1EIBMyFxEovA/2jo=; b=UBxCHL61Rr+UqbI9u2D7I1dLGeXl0tBxwBxEfWANMf3SKTUcwiuLlnEgTbBPJsSq6YRn2l7eRNvukKQR3Zxw6DZ71c0UoS1VQjdmdagUuBzMeaQBMZIUyT4Z00OiO72JPNXe3AMdyu5kilrk2Gni7WqXix3P7xRdCXJ3zDLYSobzU4MrdUfHvqRjdoGD2M0OAVapO2bH3CRgbmwId49QgYVxjlv0upuxLHDzZ6nK3pIC+AmgM/nqa0ZBCgIp/dJi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b7f1.51d209ab.k1307; bh=j3WqiAcjwJWagm5rLSFWJhmEcdW1EIBMyFxEovA/2jo=; b=DlCpyM9x5Seo4asCopiO5mnKg85fWHhZYyuBOscBQU4ymWE5cBCVY8tRnhNZb8gZx/Se+1C51rdP8eSWV8vopOKT2QDmQHTbmAkdYv0Yqv7GIIuZ/fUAzrkkhbAloBa8Inam56eZzLK483WaMr7xN94pnuOb26CByvakERo9mLgnm4IeUbLnDyIXrQpZg7bzFw8ScANLh2n8wHrofjDh24Ws7lS87xyW+d4uPKZ2EUDkWqTSOu9cTSeNJSO+g0rf Received: (ofmipd 127.0.0.1); 1 Jul 2013 22:58:29 -0000 Date: 1 Jul 2013 18:58:51 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" , "DMARC IETF list" In-Reply-To: <77426B543150464AA3F30DF1A91365DE53395A88@ESV4-MBX01.linkedin.biz> References: <20130630221443.71098.qmail@joyce.lan> <77426B543150464AA3F30DF1A91365DE53395A88@ESV4-MBX01.linkedin.biz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 22:59:21 -0000 >> I understand why you might want to tell the IETF that it can only >> change the minor documents, not the major one, but I don't see why the >> IETF would be interested. > > This is my take on the process so far. > > The spec has been handed over to IETF already. IETF can do what it likes > with it. So I don't think the DMARC.org group worries (much) about what > can be changed or not. The draft-kucherawy-dmarc-base-00 document has a license that, as I read it, is not compatible with a standards track document. It wouldn't be hard to fix, but it needs fixing. > The question is: is there sufficiently enough work to be done in the > current spec (besides editorial) that warrants an IETF WG to work on the > spec? That's not the question I see. It's whether this is an IETF effort or a dmarc.org effort. Maybe the base document will be all done by the time the WG is spun up, maybe not, but that should be the WG's decision. I think everyone agrees that the BCP is a long way from being publishable, so there's certainly work there. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dcrocker@gmail.com Mon Jul 1 16:12:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91C511E82F1 for ; Mon, 1 Jul 2013 16:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwVdidRbrO8o for ; Mon, 1 Jul 2013 16:12:14 -0700 (PDT) Received: from mail-gh0-x22b.google.com (mail-gh0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B536F11E82D8 for ; Mon, 1 Jul 2013 16:12:14 -0700 (PDT) Received: by mail-gh0-f171.google.com with SMTP id f15so2246819ghb.30 for ; Mon, 01 Jul 2013 16:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V4QXY5avqve3vx29D1jL0KBt6syjO4KRbPpa+YMgdn4=; b=AgXTIJHXpFB1/Vi/yQ5f359kOlykd0tCzbBjx3oqlZbeV74k+Dc1IvNny7EARsbvyj hvF9F7PzHG4alHIubACW5ADnuUg976Ip8EElKK3ErkzwyNCTchOwOAbsz/NbpWZ5yTcy ogb6oH7u8Ynj2ih6JHaL6rhlTQKhI152lZxj7QAAUULgi7Rs40mIB/dlwptbN0/d8UK7 ySWJnQJYZWjXCAlf8o1DAwOpcdnhuP7frlX7p/sg/GLRsWJQtv6Ek8uX0Lo8vFvNiA4T SrErZKUZp3mPG/cnvqU8CRcEUFLZDaChafzu7mQxzxJC4mGLN4U32HP30gYEZE34Ef/L ZrJw== X-Received: by 10.236.174.199 with SMTP id x47mr13403448yhl.257.1372720334251; Mon, 01 Jul 2013 16:12:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id b48sm9711652yhc.8.2013.07.01.16.12.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 16:12:13 -0700 (PDT) Message-ID: <51D20CC0.6020605@gmail.com> Date: Mon, 01 Jul 2013 16:12:00 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130630221443.71098.qmail@joyce.lan> In-Reply-To: <20130630221443.71098.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 23:12:15 -0000 On 6/30/2013 3:14 PM, John Levine wrote: >> And there have recently been some detail, independent reviews that >> are prompted a document revision that will be issued within days. > > While I don't doubt that the next version will be better, I think that > the dmarc.org group needs to make up its mind and either get a > reasonably chartered IETF WG that says no gratuitous changes to the > bits, contribute all of the drafts to the WG, and take its chances. or > else contribute none of them and just send them in via the independent > stream. John, Your premise is that something problematic and possibly wrong is being done. It isn't. The base specification is being submitted through the 'individual submission' path within the IETF stream. We have a sponsoring AD and we are following his guidance for this. An initial version of the draft was posted as an I-D. The sponsoring AD has pressed for a number of reviews to be done. An initial set were done and came back calling for some significant editorial changes, but no technical changes, essentially to make the document better to read. Let me repeat: better writing; no technical changes. That seemed like an obviously good suggestion, so we are responding to it. Rather than impose the original I-D on further reviewers, we decided to fold in their guidance now, with initial update, so that further reviewers can benefit from the improvements. A working group is for technical work. We've solicited suggestions for incremental technical work at least twice in two forums and there has been no constituency developed for any near-term work. If you know of work to be done and can develop community support for it, please, please, please document it. At that point, it will be worth considering working group chartering for technical effort on the base dmarc spec. Absent that, it isn't. As for the 'status' of the document, we are targeting a standards track RFC through the IETF stream. The copyright choices for that are quite constrained. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Mon Jul 1 18:33:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3A11E834F for ; Mon, 1 Jul 2013 18:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.975, 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 XueNEflyGjwO for ; Mon, 1 Jul 2013 18:33:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E13911E834D for ; Mon, 1 Jul 2013 18:33:27 -0700 (PDT) Received: (qmail 77864 invoked from network); 2 Jul 2013 01:33:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Jul 2013 01:33:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d22de5.xn--hew.k1307; i=johnl@user.iecc.com; bh=y7SOioHe9zAoSFFG68bokaICeJl+b6FrbPn1TwYq/c0=; b=ptkipAyTPdkw5QLbBo3RNbnRpqWZ2lo3Dcl3QZ7aaDFPPBJaPTHQKggYYpw3gXhZVrhIDg0Dvq5aumUDnN3U/cg0oNorVifEmJrQsleQPI+ajHK0grBckm+XJiDt9Zd4N2MRPuRZAKw4b63LWqa0aaapoyO91mG5oqYJIj8CBmFkE/iLI7MKDKRFLKVtycys4BfukcCPsQU+nqKzS11NOBp6+I1WRsJlhF0MXoVm2vuEkcq2oyC6eMGDfVUb75GI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d22de5.xn--hew.k1307; olt=johnl@user.iecc.com; bh=y7SOioHe9zAoSFFG68bokaICeJl+b6FrbPn1TwYq/c0=; b=Z/IzE04d4wUfGmLCw/JQarRnzB6DBvIgSJ3Gnhm07CT2lHpKZjdl96StkJJ0BMtUrjWjzLf5kOelr2didTFATbpBtuA+ycGlywWn6mKFY8zFlur8+Kjd5Rxhs39RrCSCDPfpIYzhbmJkGwDQEwGAqPsULLR0NZ6xccib/+pmGq0msPJX/cWntMzI8hkaGnweQodk1El/Ol4wRmycCd/bmI2dmVDofs2Ynx9cHpsSrN9EFzoBZXQ5lmMs3hbjBiQo Date: 2 Jul 2013 01:33:02 -0000 Message-ID: <20130702013302.14968.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51D20CC0.6020605@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 01:33:32 -0000 >A working group is for technical work. We've solicited suggestions for >incremental technical work at least twice in two forums and there has >been no constituency developed for any near-term work. If you know of >work to be done and can develop community support for it, please, >please, please document it. If reviewing the spec is off the table, I don't see any work other than cleaning up the BCP. Since the dmarc.org group seems to have a working process to write drafts adequate to publish using member employees and consultants, I see no reason for the IETF to invest volunteer cycles on it. R's, John From dcrocker@gmail.com Mon Jul 1 19:22:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D211E8381 for ; Mon, 1 Jul 2013 19:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go7nKeBGNqOz for ; Mon, 1 Jul 2013 19:22:27 -0700 (PDT) Received: from mail-ye0-x233.google.com (mail-ye0-x233.google.com [IPv6:2607:f8b0:4002:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4011E837F for ; Mon, 1 Jul 2013 19:22:26 -0700 (PDT) Received: by mail-ye0-f179.google.com with SMTP id r3so1409740yen.24 for ; Mon, 01 Jul 2013 19:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ozRv6Yhs682x1b318DHgTFG7AmmbsD4MEHsgHWM29XU=; b=S/UTWyqgeD1x92OM0863kys9V93zhiCElGSjt89g+wv3SpFFTUrjKsLHKdFt9T04Ta tiWTXgrJ4Egwmt95c8xGRUI+dsM0Jp+cUTO0Usi6ts4FHjP0WSKvkqLUFX7OW2nltkG2 iN9aR4fhpe6LXXQg2EG3pEOZ70PiRzM+sWOvDZOV/MlOxZaCOEGB7HN+X+OMboVib7tC LCjW0Fv+MjGBCzIECIVpQDSjiXRQX18LB20kHyVJCSDYXnxjxZ/afhfuuXSCsQphIW1m 34bRPVhx52VOsEsgDILo3fhpJ5Ej/A9Or8kyqEuLaDsWVNMLkS9GJnY+5DnrNEQNN1z+ lbUQ== X-Received: by 10.236.88.170 with SMTP id a30mr13473673yhf.85.1372731746537; Mon, 01 Jul 2013 19:22:26 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id d68sm37405824yhk.7.2013.07.01.19.22.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 19:22:25 -0700 (PDT) Message-ID: <51D23955.8030902@gmail.com> Date: Mon, 01 Jul 2013 19:22:13 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130702013302.14968.qmail@joyce.lan> In-Reply-To: <20130702013302.14968.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:22:28 -0000 On 7/1/2013 6:33 PM, John Levine wrote: >> A working group is for technical work. We've solicited suggestions for >> incremental technical work at least twice in two forums and there has >> been no constituency developed for any near-term work. If you know of >> work to be done and can develop community support for it, please, >> please, please document it. > > If reviewing the spec is off the table, That's not what I said. > I don't see any work other > than cleaning up the BCP. If you mean the "Using" draft, it needs considerably more than cleaning up. > Since the dmarc.org group seems to have a working process to write > drafts adequate to publish using member employees and consultants, I > see no reason for the IETF to invest volunteer cycles on it. Sorry you are not a fan of the individual submission path for the IETF stream. Oh, wait: RFC 6713 RFC 6143 RFC 5518 These appear to be RFCs you authored that were through the IETF's individual submission path and RFC 5518 (VBR) appears to be Proposed Standard. So now I'm confused about what your objection is. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Mon Jul 1 19:28:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D811E8384 for ; Mon, 1 Jul 2013 19:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9zUGcDyNWVV for ; Mon, 1 Jul 2013 19:28:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE911E837F for ; Mon, 1 Jul 2013 19:27:59 -0700 (PDT) Received: (qmail 88234 invoked from network); 2 Jul 2013 02:27:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=158a9.51d23aae.k1307; bh=TuP/kHs0u20jaHcDlBsRT5RN2ZnxqBOgivooDzyEm3A=; b=k/XMaPZ0HBDT3/EI47Yk9h3c7QimFEP/X00VlsZhgaDrIz8Xe5evVc7YqN3kZ0MESjEoRayEjG8N8FejM6mKty7c48Mh77qiwgb5b3zEiqV77VspcwZm57V8bKY/kKLIYdr4wVQKpjMKCB4omcZ+/zydycaeU3gs14N7TcW48H0rEkQOPKhpHXfzJiW1acpSPUJpYH59IuHM3k/YxHJ568kE9kThrhzYNDenQLVlwiIEBeO6q1DNyuqI6JdNPRSR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=158a9.51d23aae.k1307; bh=TuP/kHs0u20jaHcDlBsRT5RN2ZnxqBOgivooDzyEm3A=; b=qxVfU8e9HOPUmDdDxXd+HbEyMxP2sireTeQRNPIKYWrmn9CiBjlk1808oPeQ4GyY+qYRL2u8rNBsz4dqV2e28B7s2+1Qw/ReieQ1uXTWd5jSMqZdzQHBEwdiULvS7M2GtoEIf8uMUQKNbUIagKQjp3j/bXJ75+/pyzZ2rYBfs7PXQKh8WgpncrnwUoLBQMmTb80hYW1gYZBjfYB9AwJVFj3ExpaYMlNLOq8ddpwfOqzxVarFIoovb0bC0n27llm9 Received: (ofmipd 127.0.0.1); 2 Jul 2013 02:27:36 -0000 Date: 1 Jul 2013 22:27:58 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <51D23955.8030902@gmail.com> References: <20130702013302.14968.qmail@joyce.lan> <51D23955.8030902@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:28:00 -0000 >> Since the dmarc.org group seems to have a working process to write >> drafts adequate to publish using member employees and consultants, I >> see no reason for the IETF to invest volunteer cycles on it. > > Sorry you are not a fan of the individual submission path for the IETF > stream. You have it backwards. I think the individual path is just dandy for competent documents written elsewhere. My point is that since dmarc.org can do this stuff, why should the IETF spend volunteer time on a WG? R's, John From sklist@kitterman.com Mon Jul 1 19:41:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820821F9E60 for ; Mon, 1 Jul 2013 19:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XooDJNFpY9n for ; Mon, 1 Jul 2013 19:41:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED8621F9E52 for ; Mon, 1 Jul 2013 19:41:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2FB5620E40EA; Mon, 1 Jul 2013 22:41:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372732861; bh=5TcvD9vZOSMiepabVngoFZcfgNM4mVwRMLSefgCx27Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I/t2Nat73OUT/g/tiU4PWXpxkO92tNhz+zgfXDU8JB8NrIkJjatdDXKuAzFf3PeVv 6omq0pj5+MTC7Rr2FYBwsJwNxFPrrcnPngs4wTAxX65qPKS+5xb12OJ7hft+8SNi+n GGzYzh8/iN6Nu/GQxXU+6iorgEDecss11QL0uGA0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1439B20E407C; Mon, 1 Jul 2013 22:41:00 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Jul 2013 22:40:59 -0400 Message-ID: <6935780.Ol8a9WOpun@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <51D20CC0.6020605@gmail.com> References: <20130630221443.71098.qmail@joyce.lan> <51D20CC0.6020605@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:41:08 -0000 On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote: > An initial version of the draft was posted as an I-D. The sponsoring AD > has pressed for a number of reviews to be done. An initial set were > done and came back calling for some significant editorial changes, but > no technical changes, essentially to make the document better to read. > > Let me repeat: better writing; no technical changes. I disagree. I've been saying repeatedly that I think that the policy overrides are a layering violation that should be removed. They are bad design. I'll add to that that having watched senders try to interpret XML reports they receive from different providers and understand the subtleties between them that while the mechanics of the XML schema are there, the semantics are not clear enough to provide for interoperable implementations. Even among implementers who have worked together in dmarc.org to develop the schema, there are inconsistencies. I don't think there is anything in the two issues about that would force existing implementers to make changes, but I think that they are not purely editorial either. Scott K From dcrocker@gmail.com Mon Jul 1 19:47:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1111E838D for ; Mon, 1 Jul 2013 19:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwbtPg7y7Afk for ; Mon, 1 Jul 2013 19:47:09 -0700 (PDT) Received: from mail-ye0-x233.google.com (mail-ye0-x233.google.com [IPv6:2607:f8b0:4002:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3992F11E8304 for ; Mon, 1 Jul 2013 19:47:09 -0700 (PDT) Received: by mail-ye0-f179.google.com with SMTP id r3so1438848yen.10 for ; Mon, 01 Jul 2013 19:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MISypBI1ao0TNvXoecLeyN/LcAmdKGIAolSZbviZ4AU=; b=UngzMH6ii6JNVl2GeSsPji77EsFH1SSCnwBeDlqDvcjrdOC+HtN4EGB5G0kwwRJRub V18WxOUxNAB8K6DvrBonVebd2W5qTRQTkhMpuSju69IQPgoYrRsVcr9f+via/3xSVIB/ LAMeXhXba9wagPOpaI8RmMkzgsmuoPmttBtABK8DJgKOzT47XssCoOHFvmymJGHsPL4t xbciyWbtvRGpdYUC3KlxZjPcD9xAIrMt8XLVhCyrNjAiIndfYutf9tea+gkWgcDiYHH5 z5H4RplC0dheZfi2OJ6f5kX5q3MIBVFy6yhs0WB/bihmO4Rbaq2Ujw2WgFYw3QCgAFl+ OzCQ== X-Received: by 10.236.193.169 with SMTP id k29mr14013063yhn.146.1372733227746; Mon, 01 Jul 2013 19:47:07 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id m63sm28593429yhb.10.2013.07.01.19.47.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 19:47:07 -0700 (PDT) Message-ID: <51D23F1E.4090302@gmail.com> Date: Mon, 01 Jul 2013 19:46:54 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <20130630221443.71098.qmail@joyce.lan> <51D20CC0.6020605@gmail.com> <6935780.Ol8a9WOpun@scott-latitude-e6320> In-Reply-To: <6935780.Ol8a9WOpun@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:47:10 -0000 On 7/1/2013 7:40 PM, Scott Kitterman wrote: > On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote: >> Let me repeat: better writing; no technical changes. > > I disagree. I've been saying repeatedly that I think that the policy > overrides are a layering violation that should be removed. They are bad > design. Yes you have. And where is the community constituency that supports that view? > I'll add to that that having watched senders try to interpret XML reports they > receive from different providers and understand the subtleties between them > that while the mechanics of the XML schema are there, the semantics are not > clear enough to provide for interoperable implementations. Even among > implementers who have worked together in dmarc.org to develop the schema, > there are inconsistencies. Not sure what you are suggesting, as technical work, for the reporting mechanism. I also missed the demonstration of community interest in those changes, ideally on this list. > I don't think there is anything in the two issues about that would force > existing implementers to make changes, but I think that they are not purely > editorial either. Sorry for my confusion, but I don't know how to classify the changes that you seem to be calling for. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Mon Jul 1 19:49:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0279811E838E for ; Mon, 1 Jul 2013 19:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvOFwAUN26zc for ; Mon, 1 Jul 2013 19:49:39 -0700 (PDT) Received: from mail-ye0-x233.google.com (mail-ye0-x233.google.com [IPv6:2607:f8b0:4002:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8656321F9546 for ; Mon, 1 Jul 2013 19:49:13 -0700 (PDT) Received: by mail-ye0-f179.google.com with SMTP id r3so1416258yen.24 for ; Mon, 01 Jul 2013 19:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8dfpLFGNFEmbIg649A9GTAms6W0YDtUH7dxssfqw1ec=; b=j5U8BxnP8bu1fQGeUieIgp2sXhVzHccieKlw5XdEb7GT9a/pRru33Qq4Lmx9qiHee5 BFOKVUqQO7HX6RKcsk945DD4n62g3y7KC10QcFBgfWJcD6p6aZqwSI/PT0k4EH+8YPgi 9zqm7LOcJNBCP6bJkwiy1W6u5WlJb9ZlvoGMg0dI1pk6Jmr2a+8bFF57o7ab7nk0Pi5R SiSxocvLATdZXcTSwrS/muNwKJV6H9m3keFNLvdkzdG0bErQ2+PY6Pw5ZY3mkgDc//a4 Y0tr+uDmbd72PePULTpMF7DHewNRlpPuK2rHDyDl/D+jsUB94b2cLHzrrt0sUYar+YAX zPww== X-Received: by 10.236.154.37 with SMTP id g25mr13966604yhk.216.1372733353119; Mon, 01 Jul 2013 19:49:13 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id m63sm28599979yhb.10.2013.07.01.19.49.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 19:49:12 -0700 (PDT) Message-ID: <51D23F9C.2040707@gmail.com> Date: Mon, 01 Jul 2013 19:49:00 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John R Levine References: <20130702013302.14968.qmail@joyce.lan> <51D23955.8030902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:49:41 -0000 On 7/1/2013 7:27 PM, John R Levine wrote: > I think the individual path is just dandy for > competent documents written elsewhere. Like Domain Assurance Council did for VBR? > My point is that since dmarc.org can do this stuff, why should the IETF > spend volunteer time on a WG? Why was volunteer time reasonable for VBR but not now for DMARC? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Mon Jul 1 20:30:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5740111E83AC for ; Mon, 1 Jul 2013 20:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTWBh4MvV0Dz for ; Mon, 1 Jul 2013 20:30:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4610011E83A1 for ; Mon, 1 Jul 2013 20:30:46 -0700 (PDT) Received: (qmail 99975 invoked from network); 2 Jul 2013 03:30:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=18685.51d24963.k1307; bh=0W7ieboF+m30x7ZRxW82M5Fep5cNpgwJNkeIXLPmtPQ=; b=gfX5tZ6Ic5dIYm/Vdp5quVtafsUHwMiIVhoqPC/dGY2C4sQPbcw8XFnYPyksGiDFbBBdTkTqRYFrP+h9FiggFAKTj/1MJS7uK2sz7sI9lHql4D72bFx9+IdWdN0rgQTqwhuK7we4so0qnA4Gb9yyiihyRrdkvTMHAyuOuI3Z9eGPab7ZfItWQz/cU+O1QnYuKhCXGL1wBQMIOqw8HR5xuy+nDbTgTH3hMdnKIZoYLuSFaMr9vexmifA3NqVSbzmh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=18685.51d24963.k1307; bh=0W7ieboF+m30x7ZRxW82M5Fep5cNpgwJNkeIXLPmtPQ=; b=g5vJjOc1svlL9jCPNSZGkpKZogcfGAC96xe08ckxT/8UmwFMn6i/auSuQADm7XBYJHG5/xb1QuTSXaPDB5tb4azsAFm0BxxtJLqVxymu4kBfa1IxELWyuASzHyOZDeDgYIZbtz9WlGYVptdHJwnIPys6TxlAuz2fimqjcz7Xo37sq8Ung5UC1BZbWKvIiapWAAesoXAyUd1fa0++Zm4V6kxLkE44s0hRE+yOT/QwS8FQWlSWOlseaEvNCqvuv0xv Received: (ofmipd 127.0.0.1); 2 Jul 2013 03:30:21 -0000 Date: 1 Jul 2013 23:30:43 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <51D23F9C.2040707@gmail.com> References: <20130702013302.14968.qmail@joyce.lan> <51D23955.8030902@gmail.com> <51D23F9C.2040707@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 03:30:56 -0000 We do seem to be suffering from a failure to communicate, don't we? According to the subject lines of the messages we've been exchanging, we're talking about a BoF for DMARC. I hope we agree that the reason to have a BoF is to see if a topic merits a working group. According to what you've said, the DMARC technical draft is good enough that you'll send it in as an independent submission, no WG involved. Franck says that if people have comments on it, they can send them to the dmarc.org list and that group will listen, which matches my experience. The only other document I'm aware of is the BCP draft. That draft is a mess, but the dmarc.org group who wrote the technical draft seems entirely able to fix it into something reasonable and send it in as another independent submission, leaving nothing for a WG to do. Perhaps my reference to volunteer time was confusing. I realize that an independent submission takes some time from the AD*, IESG*, and whoever looks at it in last call, but a WG is a lot more with chairs, members, document editors, and whoever. It's the latter group who don't need to spend time on DMARC. Unless I'm missing something important here, it seems so obvious that DMARC doesn't need a WG that perhaps we should can the BoF and give the slot back, since I gather there's a lot of other groups who could use it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. * - who are stuck either way From sklist@kitterman.com Mon Jul 1 20:41:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6F21F8D10 for ; Mon, 1 Jul 2013 20:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRTVaSH2Br1w for ; Mon, 1 Jul 2013 20:41:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6566D21F8C20 for ; Mon, 1 Jul 2013 20:41:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A88D20E40EA; Mon, 1 Jul 2013 23:41:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372736485; bh=70dDjgSMktT4VdYeojv+Ynvs/x1YA+W6p5nfjMmWXus=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JaZQ4HtK7sSjR1OysOo16fHhfDro7SC3dOmssoePbDu07rWdSuVc5dIU70pDd2NDL YMeQ/owuimNekQmmiCfsdiq+6CnEqyICWYaFWP7SVHwxVljDg0d5x34LwsPfwzLd7/ iMAAUUc8miY0cKT6NwCBbgSTIN0h9DhsMj8lPTgs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 722D420E407C; Mon, 1 Jul 2013 23:41:24 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Jul 2013 23:41:24 -0400 Message-ID: <2386009.gcBsi9JlR4@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <51D23F1E.4090302@gmail.com> References: <20130630221443.71098.qmail@joyce.lan> <6935780.Ol8a9WOpun@scott-latitude-e6320> <51D23F1E.4090302@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 03:41:31 -0000 On Monday, July 01, 2013 07:46:54 PM Dave Crocker wrote: > On 7/1/2013 7:40 PM, Scott Kitterman wrote: > > On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote: > >> Let me repeat: better writing; no technical changes. > > > > I disagree. I've been saying repeatedly that I think that the policy > > overrides are a layering violation that should be removed. They are bad > > design. > > Yes you have. > > And where is the community constituency that supports that view? How many experts on the policy mechanism DMARC wants to mess with are involved in the discussion? So far, DMARC is pretty much a self-licking ice cream cone. To claim the lack of broad community support for a particular change is a reason not to seek broad community review seems like a bit of a catch 22. > > I'll add to that that having watched senders try to interpret XML reports > > they receive from different providers and understand the subtleties > > between them that while the mechanics of the XML schema are there, the > > semantics are not clear enough to provide for interoperable > > implementations. Even among implementers who have worked together in > > dmarc.org to develop the schema, there are inconsistencies. > > Not sure what you are suggesting, as technical work, for the reporting > mechanism. I also missed the demonstration of community interest in > those changes, ideally on this list. Since this is the first time I've mentioned this particular point, it's not surprising there isn't much feedback on it. You don't ask for anything here that wouldn't require time travel. > > I don't think there is anything in the two issues about that would force > > existing implementers to make changes, but I think that they are not > > purely > > editorial either. > > Sorry for my confusion, but I don't know how to classify the changes > that you seem to be calling for. I'm' sorry too. Scott K From sklist@kitterman.com Mon Jul 1 20:45:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C4B11E83A4 for ; Mon, 1 Jul 2013 20:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMnxnJ68kCtD for ; Mon, 1 Jul 2013 20:45:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F2F9111E83A3 for ; Mon, 1 Jul 2013 20:45:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6E34020E40EA; Mon, 1 Jul 2013 23:45:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372736735; bh=+HOi9L0c4EhSbyyEHWVXNDH34h5TO6dm56t3EplAQvE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A0WXr332V4lLNx5eJreAiVvmZPf4njTY8aq1bxB1Zv7rTxTaWp+fBYd6XeffSV7TX grW4eePQ31EkXI1r28rqu3RL9XLF01eKEh+qDYNe3NhZIS4xYTpCirOBaMFLsU1CYd KtCXqvunuuTe3AR/Jp/MnYpnd2ohzCezXzRf3M5M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5306220E407C; Mon, 1 Jul 2013 23:45:34 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Jul 2013 23:45:34 -0400 Message-ID: <1792534.Wz7mkIuNVK@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <77426B543150464AA3F30DF1A91365DE53395A88@ESV4-MBX01.linkedin.biz> References: <20130630221443.71098.qmail@joyce.lan> <77426B543150464AA3F30DF1A91365DE53395A88@ESV4-MBX01.linkedin.biz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 03:45:40 -0000 On Monday, July 01, 2013 10:11:19 PM Franck Martin wrote: > On Jun 30, 2013, at 3:14 PM, John Levine wrote: > >> And there have recently been some detail, independent reviews that > >> are prompted a document revision that will be issued within days. > > > > While I don't doubt that the next version will be better, I think that > > the dmarc.org group needs to make up its mind and either get a > > reasonably chartered IETF WG that says no gratuitous changes to the > > bits, contribute all of the drafts to the WG, and take its chances. or > > else contribute none of them and just send them in via the independent > > stream. > > > > I understand why you might want to tell the IETF that it can only > > change the minor documents, not the major one, but I don't see why the > > IETF would be interested. > > This is my take on the process so far. > > The spec has been handed over to IETF already. IETF can do what it likes > with it. So I don't think the DMARC.org group worries (much) about what can > be changed or not. > > The question is: is there sufficiently enough work to be done in the current > spec (besides editorial) that warrants an IETF WG to work on the spec? > > So far the answer to that question is no. The reason: even has a non IETF > WG, the DMARC.org group has been listening to all comments and the > deployment experience has shown the mechanism is robust across multiple > segments. > > So the logic conclusion: the spec needs to be AD sponsored to be on the > standard track. > > But I realize this will not stop conspiracy theories. > > If I'm mistaken, please review the spec and answer the question with > specifics. Personally, I'm getting tired of investing time in it. It seems like the only response to comments amounts to "La La La La, I can't hear you". Of course I've no idea what you DMARC folks are doing in private, but that's part of the problem. There's no transparency and it seems so far not a lot of openness to outside input. Scott K From dcrocker@gmail.com Mon Jul 1 21:16:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FCF21F9C55 for ; Mon, 1 Jul 2013 21:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M3GDVBMCgMM for ; Mon, 1 Jul 2013 21:16:13 -0700 (PDT) Received: from mail-gh0-x236.google.com (mail-gh0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id E948D21F9C51 for ; Mon, 1 Jul 2013 21:16:12 -0700 (PDT) Received: by mail-gh0-f182.google.com with SMTP id z15so2321940ghb.41 for ; Mon, 01 Jul 2013 21:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iaEwrQj5ViAGfeALTkOYfvi1tgfQiq+Jwtg9sjMT4LY=; b=IgfIqibBhFQd5JNZ66xr8LWnbAiJVTHUWWueDzey3UicibRyy0m4ZJiOWKIojFKjD+ wpiAxAcPJQv4bFd2P0gLs/qmrrMLcJBWkm65AzUxzoLL8GmKp00cvqCmdc0iIlkoPnxR K8v93ZC4hwTb2c8KCQoGuXiynXiaoea/VU3lryr0ffoVktur3BQ7gPmp2xNySBodZv+p 1gdJjlygDqzUHVL6IEvGgI2P3Le9VzD72ulk6DkgFknrrs5agHV6DCiut0R0eGUx66y/ tGHVrAIKsTtd/proFUZOWGY9sFKE/jFZE7awjVHg1kYbOFauReNUX9Y357MwnuNZB81E 9/pA== X-Received: by 10.236.170.201 with SMTP id p49mr351335yhl.201.1372738570240; Mon, 01 Jul 2013 21:16:10 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id s29sm38003707yhf.6.2013.07.01.21.16.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 21:16:09 -0700 (PDT) Message-ID: <51D253FD.1080203@gmail.com> Date: Mon, 01 Jul 2013 21:15:57 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <20130630221443.71098.qmail@joyce.lan> <6935780.Ol8a9WOpun@scott-latitude-e6320> <51D23F1E.4090302@gmail.com> <2386009.gcBsi9JlR4@scott-latitude-e6320> In-Reply-To: <2386009.gcBsi9JlR4@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 04:16:13 -0000 On 7/1/2013 8:41 PM, Scott Kitterman wrote: > On Monday, July 01, 2013 07:46:54 PM Dave Crocker wrote: >> On 7/1/2013 7:40 PM, Scott Kitterman wrote: >>> On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote: >>>> Let me repeat: better writing; no technical changes. >>> >>> I disagree. I've been saying repeatedly that I think that the policy >>> overrides are a layering violation that should be removed. They are bad >>> design. >> >> Yes you have. >> >> And where is the community constituency that supports that view? > > How many experts on the policy mechanism DMARC wants to mess with are involved > in the discussion? So far, DMARC is pretty much a self-licking ice cream > cone. To claim the lack of broad community support for a particular change is > a reason not to seek broad community review seems like a bit of a catch 22. Scott, This list has been available for some time, to discuss the dmarc spec, the Using draft, the draft charter and the planned BOF. Note that your opening text here was "I've been saying repeatedly". My query about community support for your concerns was based on that reference. In any event, you are indicating that you have concerns over the specifications. That's fine, of course, but there needs to be some community resonance with that concern, to justify opening up the spec and pursuing it. That's merely standard IETF process. Again: if you want folks on this list to press for something to be done, please recruit folks on this list to support its being done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sklist@kitterman.com Mon Jul 1 21:21:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3A21F9EC1 for ; Mon, 1 Jul 2013 21:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08QJTm+l--hV for ; Mon, 1 Jul 2013 21:20:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EEC3221F9ECF for ; Mon, 1 Jul 2013 21:20:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4A15520E40EA; Tue, 2 Jul 2013 00:20:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372738858; bh=VJXuCF10evo2DH7ACOPIZ8QLpRbEUkq3F3YguWHjjis=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eHB+GhGm3KTpC2/KZKfxnqsAWeOEuK+/pHPP3JrIYLlBkwSS1p5ifOfctdWYt+90K smvwmnimiwKLVUYYVJa7EbUpHmCU6xdvShWh5DLVxDUDOzKbHrRGt2aGdy2aDpBp3c Uvs+LPa2be9tvR+w9nGyyayeQr6iaLayn2KeV9n4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2E02C20E407C; Tue, 2 Jul 2013 00:20:57 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 02 Jul 2013 00:20:57 -0400 Message-ID: <16743503.BShYmKGdG4@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <51D253FD.1080203@gmail.com> References: <20130630221443.71098.qmail@joyce.lan> <2386009.gcBsi9JlR4@scott-latitude-e6320> <51D253FD.1080203@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 04:21:04 -0000 On Monday, July 01, 2013 09:15:57 PM Dave Crocker wrote: > On 7/1/2013 8:41 PM, Scott Kitterman wrote: > > On Monday, July 01, 2013 07:46:54 PM Dave Crocker wrote: > >> On 7/1/2013 7:40 PM, Scott Kitterman wrote: > >>> On Monday, July 01, 2013 04:12:00 PM Dave Crocker wrote: > >>>> Let me repeat: better writing; no technical changes. > >>> > >>> I disagree. I've been saying repeatedly that I think that the policy > >>> overrides are a layering violation that should be removed. They are bad > >>> design. > >> > >> Yes you have. > >> > >> And where is the community constituency that supports that view? > > > > How many experts on the policy mechanism DMARC wants to mess with are > > involved in the discussion? So far, DMARC is pretty much a self-licking > > ice cream cone. To claim the lack of broad community support for a > > particular change is a reason not to seek broad community review seems > > like a bit of a catch 22. > Scott, > > This list has been available for some time, to discuss the dmarc spec, > the Using draft, the draft charter and the planned BOF. > > Note that your opening text here was "I've been saying repeatedly". My > query about community support for your concerns was based on that > reference. > > In any event, you are indicating that you have concerns over the > specifications. That's fine, of course, but there needs to be some > community resonance with that concern, to justify opening up the spec > and pursuing it. That's merely standard IETF process. > > Again: if you want folks on this list to press for something to be > done, please recruit folks on this list to support its being done. It's a bit difficult to have a conversation about things that are being decided in private, particularly when those in the private club dismiss external input. I guess I've misunderstood the IETF. I had this crazy notion it was about getting the proper technical solution, not collecting votes for a position. Scott K From dcrocker@gmail.com Mon Jul 1 21:27:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730C21F9F77 for ; Mon, 1 Jul 2013 21:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeF9vIL6dX1c for ; Mon, 1 Jul 2013 21:27:10 -0700 (PDT) Received: from mail-ye0-x22c.google.com (mail-ye0-x22c.google.com [IPv6:2607:f8b0:4002:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF621F9F75 for ; Mon, 1 Jul 2013 21:27:09 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id l14so1446850yen.3 for ; Mon, 01 Jul 2013 21:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BAad/Q91SLY9g4r7i55dOOg9Vom4LiqVWUJr40khvso=; b=XBuT5Wtu136dzdDO0eKKV1SV8+ZBcTOaYQsMwleVLYqWkB3sUhkj8mb2e/ic/ezuz4 BZMk71llsf8m350YiYdoosdL/uh16a2e0gbfIV2qshHp9T3xfosAvm+UIGDRs4NATvmG zGWzA4NS9IsH9mTK6HeHl+QQKPIqKuamJEP1fC8Oa45ncHl3XvcTXwDVS7XLn9R6R6Kp AsmkT8jnLegpTNKbRRBWEcDf3UgMQe+y45gm/BWkZdpM2ovMPPUk+f5VZP96a51pkA6J 9jKmDdJE89A0itr7qbIR743RBgYHdsrzx2K3cBn19LxOShNW8NPPAObWpeeGHy1xT0Lv twNg== X-Received: by 10.236.27.234 with SMTP id e70mr13887061yha.15.1372739229602; Mon, 01 Jul 2013 21:27:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id i27sm12658278yhj.24.2013.07.01.21.27.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 21:27:08 -0700 (PDT) Message-ID: <51D25690.1080503@gmail.com> Date: Mon, 01 Jul 2013 21:26:56 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John R Levine References: <20130702013302.14968.qmail@joyce.lan> <51D23955.8030902@gmail.com> <51D23F9C.2040707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 04:27:11 -0000 On 7/1/2013 8:30 PM, John R Levine wrote: > We do seem to be suffering from a failure to communicate, don't we? Evidently there is, since it now appears that your concerns are actually with the draft charter. The charter proposes some stuff. Perhaps you can comment in terms of what is missing or inappropriate about it? So far, the gist of your concern seems to be that since a private group has already been doing some productive work on a topic, there's no need (never any need?) to have the IETF work on the topic? But perhaps I've misunderstood that. The fact that a group did some stuff does not automatically make it inappropriate to consider further work to be done on the topic in the IETF. Ultimately, dmarc.org would like to disband. Getting the spec published through an established IETF vetting process and getting a usage BCP developed are not all that unusual. (The draft charter cites more than that.) At the least, the BCP is real work. Your classing it as a real mess suggests that you agree. I assume you didn't object to DKIM following a broadly similar path. Since it was in a different place in development and deployment, it happened to be more amenable to protocol development in an IETF working group. But there were also the other docs produced. Their development didn't depend on first having an IETF working group develop the base specification, unless there's some unwritten rule I've missed. > According to what you've said, the DMARC technical draft is good enough > that you'll send it in as an independent submission, no WG involved. And since I keep hassling the dmarc folk about this finicky point, I'll stay consistent and note: Individual submission on the IETF stream, not Independent stream. > Franck says that if people have comments on it, they can send them to > the dmarc.org list and that group will listen, which matches my experience. My own recommendation is to post comments on this list, not the dmarc.org list, so that they are within the IETF sphere. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Mon Jul 1 21:28:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889E611E83A3 for ; Mon, 1 Jul 2013 21:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G+L5f2hvbce for ; Mon, 1 Jul 2013 21:28:40 -0700 (PDT) Received: from mail-ye0-x22d.google.com (mail-ye0-x22d.google.com [IPv6:2607:f8b0:4002:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5ED21F9F75 for ; Mon, 1 Jul 2013 21:28:39 -0700 (PDT) Received: by mail-ye0-f173.google.com with SMTP id m7so1441385yen.18 for ; Mon, 01 Jul 2013 21:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=m3RzmNB924+F8ZboV5bdld/E7mehtdhTorPmWAPbK6A=; b=dqCVb+isejB4Pk6X1Hn15S8JSTiO1U4Jjuolv6F0YCWXapUdLW/nRTxOo0v/VbZYV6 Vp3rk9Lh4p7FLswgLJpsIN+9/MMHtVm7KobG1e0lubiZCn4KjLQ25C7L0NFPvggS20/c imkDKvrpNjhOqyI+fFXuZmux9YAue6PLsNS4y9FiCMAcOYC3bxu6B9A8H1Yjx4+1bgbU TDIONbiLkoOr7iui8DudfgevKMrJVj3M0+LeW7Ysixba7vYpAWNpdwR/Ev+aOYvUCXbc +j8N75ZALK8zWvN8B/jwmV2kVa38yMrF5kbZ8t5jrj7pS4nBugylYuAAx4H1hZBdwIJD YhFg== X-Received: by 10.236.30.65 with SMTP id j41mr13845109yha.147.1372739318504; Mon, 01 Jul 2013 21:28:38 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id a28sm38065806yha.0.2013.07.01.21.28.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 21:28:37 -0700 (PDT) Message-ID: <51D256E9.2010104@gmail.com> Date: Mon, 01 Jul 2013 21:28:25 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <20130630221443.71098.qmail@joyce.lan> <2386009.gcBsi9JlR4@scott-latitude-e6320> <51D253FD.1080203@gmail.com> <16743503.BShYmKGdG4@scott-latitude-e6320> In-Reply-To: <16743503.BShYmKGdG4@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 04:28:40 -0000 On 7/1/2013 9:20 PM, Scott Kitterman wrote: > It's a bit difficult to have a conversation about things that are being decided > in private, particularly when those in the private club dismiss external > input. I guess I've misunderstood the IETF. I had this crazy notion it was > about getting the proper technical solution, not collecting votes for a > position. The concerns you have are not being decided in private. Raise them on this list. Discuss them on this list. Recruit support for them on this list. I'm quite certain that IETF management will pay attention to the support you develop for work to be done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Mon Jul 1 21:56:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51D11E83C6 for ; Mon, 1 Jul 2013 21:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OMen7flv6Xx for ; Mon, 1 Jul 2013 21:56:11 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id CA04011E83B8 for ; Mon, 1 Jul 2013 21:56:04 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so3761582wib.2 for ; Mon, 01 Jul 2013 21:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=avp7XPg5Alb6oFV84GEg7gN/+Lf0Zj8ZDEpo8q/n8KY=; b=gFyxyQfk19b7ZFOC/gM5Mi4Of4Yhk8+0Yvj1hKN9NE5JQY5y4k/wLXLI9HKrx7+ybR GSvYMtwUCdXeiBk+tasmS1Ac6TIyzj/H7LUMckK/I8nurYcuURHUk97L2PP5PnBSs2f9 0su+AOz9UAnuUFz4ZvLIbzsU9yXFkHBPR0oisGjMtItp8fm7e25pRfL/EZIq3AN14RXp aZtD5wrkPOZVNOgPWk9MJGAEPjwom1E72iMFN9PL5JAJaJW3OnUCRNl1uotJ7/sCCsR5 9UiYrFa4YmRDEqrpAOG0+THuTjzy7r8vRdEDdkmAllSDYr/ze1TiJ7SHWIFZGY0GtmM8 8i6g== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr14093230wic.52.1372740963957; Mon, 01 Jul 2013 21:56:03 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 1 Jul 2013 21:56:03 -0700 (PDT) In-Reply-To: <16743503.BShYmKGdG4@scott-latitude-e6320> References: <20130630221443.71098.qmail@joyce.lan> <2386009.gcBsi9JlR4@scott-latitude-e6320> <51D253FD.1080203@gmail.com> <16743503.BShYmKGdG4@scott-latitude-e6320> Date: Mon, 1 Jul 2013 21:56:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c269ac86816a04e080290c Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 04:56:13 -0000 --001a11c269ac86816a04e080290c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 1, 2013 at 9:20 PM, Scott Kitterman wrote: > It's a bit difficult to have a conversation about things that are being > decided > in private, particularly when those in the private club dismiss external > input. I guess I've misunderstood the IETF. I had this crazy notion it > was > about getting the proper technical solution, not collecting votes for a > position. > > There are a lot of assumptions being made here. Let me put some of them to rest: I'm currently volunteering as the lead editor on this document. That the concerns expressed on this list by yourself, Eliot, SM, and anyone else have not immediately resulted in a new draft being issued addressing them is not automatically evidence of cabal-like behavior or intent by the community that created the work. I/we simply haven't had the time to go through the motions required to crank out a new version, especially given the nature and volume of some of the feedback requiring a lot of editing work on the XML source. I apologize unreservedly that this has ruffled feathers, but as John points out, I'm a volunteer like the rest of you with other obligations, and in the past few weeks this has simply not been at the top of my priority list. And even if a revision appears that doesn't address your pet rock, it's entirely (perhaps even likely) that it got missed in error, not because it was rejected. (See above about priorities.) As an admitted "insider" here, please invest whatever trust you have in my integrity that not one iota of feedback has been discarded out of hand by anyone. We are not so stupid as to think we'd get away with it, nor do we think the IETF is so stupid as to try, nor do we think anyone would find the IETF rubber stamping something like this onto the standards track to be anything close to palatable to the community. A number of dialogs have taken place to get us here, which involve compromise and negotiation. I believe there's far more cooperation going on here than people are allowing for in these arguments. I'm pleased to hear John's experience of the DMARC people to date is that we do listen to feedback. I believe we've gone to great lengths to be accessible, and I would also say, for example, that the community which created the pre-IETF drafts of DKIM was far less open yet suffered far less objection when it approached a BoF. I'm sorry that your experience has not been like John's, but that's not the result of secrecy or anything sinister. What I think would be more productive here is discussion of what's in the proposed charter. I'm thinking about what's in RFC5434 because it's clear to me, at least, that there are enough people who are interested in working on this to justify at least having the BoF. As Barry points out, the outcome of that BoF will (hopefully) be a clear indication as to whether a working group is appropriate. I think it is, but I also think the conversation about what the charter should be like is one we need to have. That's brought us here. John stated that if dmarc.org can do the editing and development it's done so far, then dmarc.org can finish it independent of a working group. That's certainly true, but by that reckoning a number of things now on the standards track also shouldn't have bothered to come into the IETF. A large number, in fact. I suggest, then, that DMARC is as legitimate a candidate to bring in half-baked or even three-quarters-baked as all the other things in the past that have fit that description. -MSK --001a11c269ac86816a04e080290c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 1, 2013 at 9:20 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
It's a bit difficult = to have a conversation about things that are being decided
in private, particularly when those in the private club dismiss external input. =A0I guess I've misunderstood the IETF. =A0I had this crazy noti= on it was
about getting the proper technical solution, not collecting votes for a
position.


There are a lot of assumptions being m= ade here.=A0 Let me put some of them to rest:

I'm currently volu= nteering as the lead editor on this document.=A0 That the concerns expresse= d on this list by yourself, Eliot, SM, and anyone else have not immediately= resulted in a new draft being issued addressing them is not automatically = evidence of cabal-like behavior or intent by the community that created the= work.=A0 I/we simply haven't had the time to go through the motions re= quired to crank out a new version, especially given the nature and volume o= f some of the feedback requiring a lot of editing work on the XML source.= =A0 I apologize unreservedly that this has ruffled feathers, but as John po= ints out, I'm a volunteer like the rest of you with other obligations, = and in the past few weeks this has simply not been at the top of my priorit= y list.

And even if a revision appears that doesn't address your pet rock,= =20 it's entirely (perhaps even likely) that it got missed in error, not be= cause it was rejected.=A0 (See above about priorities.)

A= s an admitted "insider" here, please invest whatever trust you ha= ve in my integrity that not one iota of feedback has been discarded out of = hand by anyone.=A0 We are not so stupid as to think we'd get away with = it, nor do we think the IETF is so stupid as to try, nor do we think anyone= would find the IETF rubber stamping something like this onto the standards= track to be anything close to palatable to the community.=A0 A number of d= ialogs have taken place to get us here, which involve compromise and negoti= ation.=A0 I believe there's far more cooperation going on here than peo= ple are allowing for in these arguments.

I'm pleased to hear John's experience of the DMARC people to da= te is that we do listen to feedback.=A0 I believe we've gone to great l= engths to be accessible, and I would also say, for example, that the commun= ity which created the pre-IETF drafts of DKIM was far less open yet suffere= d far less objection when it approached a BoF.=A0 I'm sorry that your e= xperience has not been like John's, but that's not the result of se= crecy or anything sinister.

What I think would be more productive here is discussion of what&= #39;s in the proposed charter.=A0 I'm thinking about what's in RFC5= 434 because it's clear to me, at least, that there are enough people wh= o are interested in working on this to justify at least having the BoF.=A0 = As Barry points out, the outcome of that BoF will (hopefully) be a clear in= dication as to whether a working group is appropriate.=A0 I think it is, bu= t I also think the conversation about what the charter should be like is on= e we need to have.=A0 That's brought us here.

John stated that if dmarc.org can do the editing and development it's done s= o far, then dmarc.org can finish it indepe= ndent of a working group.=A0 That's certainly true, but by that reckoni= ng a number of things now on the standards track also shouldn't have bo= thered to come into the IETF.=A0 A large number, in fact.=A0 I suggest, the= n, that DMARC is as legitimate a candidate to bring in half-baked or even t= hree-quarters-baked as all the other things in the past that have fit that = description.

-MSK
--001a11c269ac86816a04e080290c-- From sklist@kitterman.com Mon Jul 1 22:24:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A789D11E83A8 for ; Mon, 1 Jul 2013 22:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMEZJyXyCXst for ; Mon, 1 Jul 2013 22:24:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 305B921F9C25 for ; Mon, 1 Jul 2013 22:24:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8893820E40EA; Tue, 2 Jul 2013 01:24:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372742685; bh=7x1IfS5d4gYdkgzT/GtfUZCPG8s7TfRE1E96iGGEwWM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TV0zgjF9HxQd1hSm3VBgVpuhWc+yerv8OgJA+CeoOyCvFub4JNnYM9/lZTPYKArDz P8z3894Wbz4wOIh3c74LyzJMKkZsTv6cQyU7k7Qq1n3lorYOuD48E8CF7iDMUDMktm ISiasNZ0kWwRxp5Ja2vq64CbugXYEdhj5IWjqlxs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6CEDA20E407C; Tue, 2 Jul 2013 01:24:44 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 02 Jul 2013 01:24:44 -0400 Message-ID: <3702901.qqViAzZfBM@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: References: <20130630221443.71098.qmail@joyce.lan> <16743503.BShYmKGdG4@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: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 05:24:50 -0000 On Monday, July 01, 2013 09:56:03 PM Murray S. Kucherawy wrote: ... > What I think would be more productive here is discussion of what's in the > proposed charter. I'm thinking about what's in RFC5434 because it's clear > to me, at least, that there are enough people who are interested in working > on this to justify at least having the BoF. As Barry points out, the > outcome of that BoF will (hopefully) be a clear indication as to whether a > working group is appropriate. I think it is, but I also think the > conversation about what the charter should be like is one we need to have. > That's brought us here. ... So far, in this thread the base spec has been ruled out and then possibly in for the BoF. http://www.ietf.org/mail-archive/web/dmarc/current/msg00309.html I think it's very difficult to have a conversation about what work needs to be done at this point because we don't know what the base spec looks like. I think the last published version has some design issues that need to be addressed and it not nearly clear enough to support development of independent, interoperable implementations (including particularly the data exchange). I understand there's work in progress to improve that, but until we know what it looks like, how can we possibly have an opinion on if it's adequate or not? To me, the entire question of a WG or not and if so, what it's scope should be turns on the question of if there's already a well developed specification that doesn't need further work. So far, I haven't seen one. I'm not arguing for conspiracies, just that for those of us on the outside of the group, we don't know what we don't know. Scott K From johnl@iecc.com Mon Jul 1 22:28:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835E11E83EA for ; Mon, 1 Jul 2013 22:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.387 X-Spam-Level: X-Spam-Status: No, score=-110.387 tagged_above=-999 required=5 tests=[AWL=0.812, 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 xTLBw0+zL6n9 for ; Mon, 1 Jul 2013 22:28:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D414211E83A8 for ; Mon, 1 Jul 2013 22:28:09 -0700 (PDT) Received: (qmail 22038 invoked from network); 2 Jul 2013 05:28:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Jul 2013 05:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d264e9.xn--9vv.k1307; i=johnl@user.iecc.com; bh=upEiUi1ydQqOtUR6KepL6O7zY4cHYYBOm1/o+ypHxkw=; b=Gy7m41jDy6dIV4Agiu1DZipPElqtd5utmaEk6MHYlpQG3fzT+s6D3c6egm4w9zkBpxgFKVKPDRnxU4oGPzBLtPW87YAJ9Crc+/RRfYIPSRTGjRQegY6ity9iNFhqCDmtTD25DMPe21/donDjni+rS0kwEiYUquyIg5Tbl2HjDTJFyQ6T6mn07A5EFi5d9Ie9q0sjjgxEe2XzFI4KVsSlD7F3OKhFJ7FdswUfonPx8YsRuj1O743zVwJ48Yi9xnt2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d264e9.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=upEiUi1ydQqOtUR6KepL6O7zY4cHYYBOm1/o+ypHxkw=; b=GXNTIYPzJTuHy2HhR0/apHMKcIodzUi5gj6t8viH2UiM1WIfGyeyD7p4LCm11m4VsXwdBK+e3E04F5S7eKLSt4r/3C1o/AGtZ7paeshit7KejZBQsaiztVU1IgAZzRPCleaCDCm+UKntL/RVk3D6FA06PSwH6hGdrFmxF+51/5l66rRbqEzRA8QE7e8B8BarOV9gqXh3ldfN9pj9bopmDRQ14Hmt6Mfd+F8QApwlBM/4U+jxbGVg/aUOUGUN7Nng Date: 2 Jul 2013 05:27:46 -0000 Message-ID: <20130702052746.15876.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 05:28:14 -0000 >What I think would be more productive here is discussion of what's in the >proposed charter. Replace the second and third paragraphs with: The working group will adopt draft-kucherawy-dmarc-base as an input document and any other drafts the the group deems relevant and useful, with the goal of publishing a standards track DMARC specification and posssibly other documents. In view of the large base of running DMARC code, the group will avoid changes that would cause incompatible changes to bits on the wire. Delete the 13th paragraph. Delete discussions of mailing lists which are a hopeless black hole. Adjust the schedule to taste. Alternatively, per my previous colloquy with Dave, delete text starting with "Email abuse often ..." and ending with "... guide to WGLC." R's, John PS: For people who have lost track, the draft charter is here: http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC From superuser@gmail.com Mon Jul 1 22:52:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2411E83F2 for ; Mon, 1 Jul 2013 22:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCOUkScwFC+3 for ; Mon, 1 Jul 2013 22:52:42 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0711E83EF for ; Mon, 1 Jul 2013 22:52:42 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so4789766wiw.0 for ; Mon, 01 Jul 2013 22:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d0drx9fi+Gn41d1LF5s4C9Ii2430LWH4sX2WctkNF0k=; b=KyewmwioLDc/9nHLBEAu+nfC7A7+htLCcoaDsymn8JIJAgSVrgpe/MscYoLidSTqwE 63Jb57O4SGeX0zrTivs39YnkHuIuH/A/pUqUbMV3rBUONJenpCGl1sexeZKNM81ngrlB MZd+16X5cAT0wUu6tMZ/em+4PV8J1oAYr84PDuaH0no6wzfVLfdYklroxOZc92MHB8w0 g4HpyilcOib35oBi01njmmt5OFggdCZnmjJDxXab8X359auQQjxDR8ysIBHsgm8RBgvb txLU8eg1M5c80F001I7g1jJTwlEhn4UUt8+pvlOYa46Og6Oz/BICRWIVhYVk9Mu+ipra G0kw== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr14216600wib.52.1372744361439; Mon, 01 Jul 2013 22:52:41 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 1 Jul 2013 22:52:41 -0700 (PDT) In-Reply-To: <3702901.qqViAzZfBM@scott-latitude-e6320> References: <20130630221443.71098.qmail@joyce.lan> <16743503.BShYmKGdG4@scott-latitude-e6320> <3702901.qqViAzZfBM@scott-latitude-e6320> Date: Mon, 1 Jul 2013 22:52:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d044517f707f7c704e080f41a Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 05:52:43 -0000 --f46d044517f707f7c704e080f41a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 1, 2013 at 10:24 PM, Scott Kitterman wrote: > I understand there's work in progress to improve that, but until we know > what > it looks like, how can we possibly have an opinion on if it's adequate or > not? > There's no requirement of which I'm aware that says the documents on the table at a BoF have to be anything close to complete. They merely have to be a starting point for the conversation. It could be that they need a ton of work, and it could be that they don't. It seems to me your concern is that there won't be any conversation at all; meanwhile it's obvious to me just from a few reviews plus your feedback that there will be at least some if not a lot of changes to the prose in many places. Personally, I think this can be done very reasonably without disturbing the installed base much if at all. -MSK --f46d044517f707f7c704e080f41a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 1, 2013 at 10:24 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
I understand there's work in progress to= improve that, but until we know what
it looks like, how can we possibly have an opinion on if it's adequate = or not?

There's no requirement of w= hich I'm aware that says the documents on the table at a BoF have to be= anything close to complete.=A0 They merely have to be a starting point for= the conversation.=A0 It could be that they need a ton of work, and it coul= d be that they don't.

It seems to me your concern is that there won't be any conversation= at all; meanwhile it's obvious to me just from a few reviews plus your= feedback that there will be at least some if not a lot of changes to the p= rose in many places.

Personally, I think this can be done very reasonably without= disturbing the installed base much if at all.

-MSK
--f46d044517f707f7c704e080f41a-- From sklist@kitterman.com Mon Jul 1 23:03:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79B11E82A5 for ; Mon, 1 Jul 2013 23:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Tlpk79aP57 for ; Mon, 1 Jul 2013 23:03:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E95E111E8299 for ; Mon, 1 Jul 2013 23:03:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 50EE220E40EA; Tue, 2 Jul 2013 02:03:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372745018; bh=gHRrOQ6vOz8HOg/cJtYqdR6CW295mKzXXDfvaVlbf2g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AYVAm4TIuFeHi88kLZhS+sAoc2FZIGlfdZbmnwwW13cAw4dmYYpkfJFzctm0Ofpbw NsYydb4WR6cT0SRgFKUKIQuZVoQfNqPsNdtM7Cpyv05oeCdd7yXVQoS8LMbD1ZCwOc zK1f0gtH/EVmiVvfaEt/vZUflPMIXIfGhqHBtAKE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 33D0920E407C; Tue, 2 Jul 2013 02:03:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 02 Jul 2013 02:03:37 -0400 Message-ID: <6186322.YWEmVzIH41@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: References: <20130630221443.71098.qmail@joyce.lan> <3702901.qqViAzZfBM@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: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 06:03:44 -0000 On Monday, July 01, 2013 10:52:41 PM Murray S. Kucherawy wrote: > On Mon, Jul 1, 2013 at 10:24 PM, Scott Kitterman wrote: > > I understand there's work in progress to improve that, but until we know > > what > > it looks like, how can we possibly have an opinion on if it's adequate or > > not? > > There's no requirement of which I'm aware that says the documents on the > table at a BoF have to be anything close to complete. They merely have to > be a starting point for the conversation. It could be that they need a ton > of work, and it could be that they don't. > > It seems to me your concern is that there won't be any conversation at all; > meanwhile it's obvious to me just from a few reviews plus your feedback > that there will be at least some if not a lot of changes to the prose in > many places. > > Personally, I think this can be done very reasonably without disturbing the > installed base much if at all. I agree that it seems the needed changes are unlikely to affect the installed base. My concern is that the plan appears to be an AD sponsored base specification with maybe a working group to address the BCP and potentially other things. To have a good understanding of if that's a reasonable plan, you need a base spec that's pretty ready to go. If the draft charter is adjusted to take your document as an input to the WG and have the base spec as an output to the WG, then I entirely agree about the level of maturity required in the documents. I'm confident that whatever you produce would be quite suitable as the input to a WG effort. Scott K From dcrocker@gmail.com Tue Jul 2 07:31:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885BF21F9EB5 for ; Tue, 2 Jul 2013 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PPHaKcztCjy for ; Tue, 2 Jul 2013 07:31:17 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAAB21F9EC1 for ; Tue, 2 Jul 2013 07:31:10 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so2772075vcb.41 for ; Tue, 02 Jul 2013 07:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iphNzsB4mTCd8ixe7Msk3i1CE8ecgKIWHdIR6OrQ4UU=; b=NyT4Dgj8jw1uHFDj1sG9oUiME4Ssw3Muh6ZIS54/2eWj3zJjvLFTTVxGBYJsGzWZUt lgXb95LAdx/nQzujeTF4k39AEmJnAuUeM/9i77OY64h0OwRuSBf2icoCA9N1vREKQxgd tI4T+OFbRZ2UotU8mgLxd2kw0ef1j5wZkqpeZY/Sv51ljcxgSkJAg7Wb0RHtwzp1z5Un Egw6/7tPMyHBh0JNQdHOzV/JANOVLfnScQXAgwSpE4wgFpqfWYZat1gDC3pMS+kAJbLa mkZy6qvvMZtazz4Csv/iAilS+uASQ1GwJlBeTVRfAk66Y7fnV8p+d2I2JXTHbHSW9Goe 8fZw== X-Received: by 10.220.251.3 with SMTP id mq3mr11623067vcb.20.1372775469653; Tue, 02 Jul 2013 07:31:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id t5sm6506197vde.8.2013.07.02.07.31.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 07:31:08 -0700 (PDT) Message-ID: <51D2E41E.5000609@gmail.com> Date: Tue, 02 Jul 2013 07:30:54 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <20130630221443.71098.qmail@joyce.lan> <16743503.BShYmKGdG4@scott-latitude-e6320> <3702901.qqViAzZfBM@scott-latitude-e6320> In-Reply-To: <3702901.qqViAzZfBM@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:31:18 -0000 On 7/1/2013 10:24 PM, Scott Kitterman wrote: > I think it's very difficult to have a conversation about what work needs to be > done at this point because we don't know what the base spec looks like. Yes you do. The changes being done are non-technical. The technical details have been visible and stable for a long time. You've also participated in other IETF group discussions during document development. So the idea that a document is undergoing changes and yet is still being talked about is something you are familiar with. > I > think the last published version has some design issues that need to be > addressed and it not nearly clear enough to support development of > independent, interoperable implementations (including particularly the data > exchange). The clarity issue might well be a matter of writing quality, and that's what the current round of revisions is attempting to address. "Design issues" sounds more technically substantive. As has been said, no design changes are being made to the document in the current round. Once again: If you have technical concerns -- including design concerns -- please raise them here; pursue them here; resolve them here through group consensus. > I'm not arguing for conspiracies, just that for those of us on the outside of > the group, we don't know what we don't know. You don't know what editorial changes are in the midst of being made. That's typically true for working group documents, too, since most leave such things to the editor. However you /do/ know all the technical details, because they have been public and stable for quite awhile. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Tue Jul 2 07:46:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED0721F9F9A for ; Tue, 2 Jul 2013 07:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fbXXojfNo62 for ; Tue, 2 Jul 2013 07:46:59 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id E814121F9F97 for ; Tue, 2 Jul 2013 07:46:58 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so4823283veb.40 for ; Tue, 02 Jul 2013 07:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rQdmkaQi4Ntgcch2BSMQbRV7xkcYfIj/buNYACkGaXQ=; b=r/cuj/VEMHkh3JUAf2NR+FQpfn44cptmyTVOWex+Q9jHY6Go68TeaXEFiCb0F5W71o uoIOGwCoMafJxPihxfQn3euI3gYuhifSU/8x4/svtdOGoHngya3asnxbSlIGAIPKtOp8 QI6DmJijMf2yzobfzcTb4b+Ea+JoU47X5aWsex/maDJ8J4i8EIQ15Fjr3bomvnsyBLj1 jFnXwqWG/mvasPmbmKGwX2TSD0uqP8LqmeqGulUL2YEnm2zquI3wOC3GUNJYBiR+bA8y QXids0Ux5P+ZzKTQ45RHB0uxdTIojcL00MEwfcdxGQi7TJ1WmosjFRKhtOQPG3cISpE+ FuOA== X-Received: by 10.58.50.7 with SMTP id y7mr11346273ven.24.1372776418416; Tue, 02 Jul 2013 07:46:58 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id at19sm17531111vdc.10.2013.07.02.07.46.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 07:46:57 -0700 (PDT) Message-ID: <51D2E7D3.1000703@gmail.com> Date: Tue, 02 Jul 2013 07:46:43 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130702052746.15876.qmail@joyce.lan> In-Reply-To: <20130702052746.15876.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:46:59 -0000 On 7/1/2013 10:27 PM, John Levine wrote: >> What I think would be more productive here is discussion of what's in the >> proposed charter. > > Replace the second and third paragraphs with: > > The working group will adopt draft-kucherawy-dmarc-base as an input What is the work to be done on the base document? Please provide substance rather than form. The substance describes the work or the nature of the work with a sense of what is useful about the deliverable. The charter of work for a working group is supposed to give a sense of the work. While some charters do indeed seem to say "we'll take on the document and then figure out what we want to do with it" that is rarely a constructive model for getting anything useful published anytime soon. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Tue Jul 2 08:11:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA721F9DCF for ; Tue, 2 Jul 2013 08:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.651 X-Spam-Level: X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, NO_RELAYS=-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 xnmBV19zhv8U for ; Tue, 2 Jul 2013 08:11:48 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1511721F9D7E for ; Tue, 2 Jul 2013 08:11:43 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so4926532veb.39 for ; Tue, 02 Jul 2013 08:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zLzsf6rh8DfrGT24D/BbqJDUXlSNOm9dfZAxTaGCiPg=; b=vWDvDHYwSQ3Yg5deEjLhT+fPeV2IjnXlOnod2om+UJ5I4vKYd1zXLrL26lOyVdskHf J3odPRgUz4dLCniUVO5Efzh+EALVe7Nd+Tyw3UIQDXxtNdAkG3iflXOSKXx2Rew5kMaY NqJ3JJX1I8mPne07+MBiQMPAtDyAG0luUAVL2/LsuYH+Ktl992A2HIU2y+cPKaoceHyN Ho5gzp5QSqdtpPB5hhJnesg1rwqGJMDIVfBaWcT5ft3iZLq6b/n+WclYi0CzkF/kAkis 5yUrGMVzVG38ZtKnA3WkmnUQOSVfBP+MXF1llbjo0g5v8cUvoV942+Cc6WCk1VxW/biU MZ0w== MIME-Version: 1.0 X-Received: by 10.58.34.69 with SMTP id x5mr11514579vei.11.1372777896315; Tue, 02 Jul 2013 08:11:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Tue, 2 Jul 2013 08:11:36 -0700 (PDT) In-Reply-To: <6186322.YWEmVzIH41@scott-latitude-e6320> References: <20130630221443.71098.qmail@joyce.lan> <3702901.qqViAzZfBM@scott-latitude-e6320> <6186322.YWEmVzIH41@scott-latitude-e6320> Date: Tue, 2 Jul 2013 11:11:36 -0400 X-Google-Sender-Auth: MEGigKPOR7AMjjhVO0mTHylSJqk Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC BoF at IETF 87, Berlin X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:11:49 -0000 Scott, I'm clumping bits from a few of your messages in this thread into one reply; I think it'll make it easier. >> An initial version of the draft was posted as an I-D. The sponsoring AD >> has pressed for a number of reviews to be done. An initial set were >> done and came back calling for some significant editorial changes, but >> no technical changes, essentially to make the document better to read. >> >> Let me repeat: better writing; no technical changes. > > I disagree. I've been saying repeatedly that I think that the policy > overrides are a layering violation that should be removed. They are bad > design. Repeatedly? I've just re-read every message you've posted to this mailing list, and I see none in which you've said this, none in which you've done a review of the dmarc base spec document, and several in which you've said that you're using dmarc and are supportive of it. I'm sure you think there are things that should be changed. The best way to suggest that is to do a review of the document, to post it here, and to be specific about what you want to see changed. > I'll add to that that having watched senders try to interpret XML reports they > receive from different providers and understand the subtleties between them > that while the mechanics of the XML schema are there, the semantics are not > clear enough to provide for interoperable implementations. Even among > implementers who have worked together in dmarc.org to develop the schema, > there are inconsistencies. > > I don't think there is anything in the two issues about that would force > existing implementers to make changes, but I think that they are not purely > editorial either. Excellent; put an expansion of that into a review, making sure that it's clear about what the problem is and what, specifically, you want to change. > Personally, I'm getting tired of investing time in it. It seems like the only > response to comments amounts to "La La La La, I can't hear you". This and statements like it don't seem to be fair: I see no evidence that anyone is unwilling to listen to comments (from you or anyone else). Responses might disagree with you, and people might think that changes you want made should not happen... but that's technical disagreement, not refusal to listen. In any case, I haven't see any real opportunity to discuss what issues you might have with the dmarc protocol, because I haven't seen you lay those issues out clearly so they can be discussed. Please do that. Really: please do that. Please don't get tired; get specific. > I agree that it seems the needed changes are unlikely to affect the installed > base. My concern is that the plan appears to be an AD sponsored base > specification with maybe a working group to address the BCP and potentially > other things. Whether the base spec is AD-sponsored or handled by a working group isn't going to affect the quality or depth of review that I'm going to insist on. The dmarc spec will not become an IETF Standards Track document without a good deal of thorough review, discussion and changes where that's necessary, and significant support for putting it on the Standards Track. The path of AD sponsorship is happening because there was difficulty in converging on a charter that included the base spec (see the discussion on the apps-discuss list about that). Such a working group is still not out of the question, but the level of technical work that appears to be needed for the base spec is very low -- that's what makes it reasonable to AD-sponsor it if the community gets behind it with review and discussion. In this post: http://www.ietf.org/mail-archive/web/dmarc/current/msg00184.html ...you say this: > I'm not certain what the best answer is, but I think that at least getting the > spec to say you can publish p=none and not affect existing behavior is very > important. Unfortunately, there's no venue to discuss updating the base spec. *This* is the venue to discuss updating the base spec. Clearly, those who have deployments of dmarc don't want to see changes that will affect their deployments. That said, there's no restriction on what aspects of dmarc can be discussed on this list. You want to propose changes, do as I said above: post a review of the document and be specific about what you want to see changed and why. And then participate in the discussion that ensues. Scattered comments in other threads that give very brief mention to issues you have are hard to follow, hard to get into real discussion of, and hard for editors to track. Barry, Applications AD From johnl@iecc.com Tue Jul 2 08:32:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3341B21F9F1A for ; Tue, 2 Jul 2013 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.696, 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 7Y6x53K7X8gm for ; Tue, 2 Jul 2013 08:32:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7E21F9E2D for ; Tue, 2 Jul 2013 08:32:01 -0700 (PDT) Received: (qmail 10369 invoked from network); 2 Jul 2013 15:32:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Jul 2013 15:32:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d2f270.xn--btvx9d.k1307; i=johnl@user.iecc.com; bh=tS7kZx+jPIvOfXqsaKFRwJx/+yS4EAz3f+28ElYLAAA=; b=HhkghM7SWtzt8a9rQz+ljKkDE7iSrqF/8uy2bDkm8R7jKdS7b+9u/2ggq92DO2HSe0mx+vahN6fNuzjfOd7SBfQlb3rz+l4j6QTamTFriDQwjsCwkuf1tEe2MAdmcXNG1gHdxgwn4Fgdjuti7s0QNDoOlvTidPr/GTNrUoBUKTgkdh/8nDY0POwBVsEaqzVLhoeaBYJA6Wjs+N6hO/D+btHUumAgAXn8c+XLqArYvCCABKhT/l6x9tJphPKuMnSR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d2f270.xn--btvx9d.k1307; olt=johnl@user.iecc.com; bh=tS7kZx+jPIvOfXqsaKFRwJx/+yS4EAz3f+28ElYLAAA=; b=OIUZ24yXJhwI08zdUOaRP1Ivooxm7Jz1k2cY77zZ3oGS4yuU4t4g1T5761alJnZtxfb07KnRfdpuF2UWNKEdcv1CAgW9X4bN7nz3FtxUxrZfHvIwSDf4GbuZKHFTWn5m7BxcajxP0SCDkhU+iDThOS/KAeK2q2B1mreiChnRKXHa4aBfOtLiSKoZWFwhn461eKcnlvNC2+ZF11QagwsMZXoK4vSO6KDJz6I3ztPBDOTgY7MdqPYbotf3SsUlPzmB Date: 2 Jul 2013 15:31:38 -0000 Message-ID: <20130702153138.21069.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51D2E7D3.1000703@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:32:06 -0000 >>> What I think would be more productive here is discussion of what's in the >>> proposed charter. >> >> Replace the second and third paragraphs with: >> >> The working group will adopt draft-kucherawy-dmarc-base as an input > >What is the work to be done on the base document? I don't know, because nobody other than perhaps Murray knows what it says. Maybe the WG will look at it and say it's done, maybe they will find problems like the ones Scott alluded to. Telling us "the base document is all done, don't you worry your pretty little heads about it" is just insulting. Also, see the next message for more concrete comments on the current charter. R's, John From johnl@iecc.com Tue Jul 2 09:16:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D0B21F9F25 for ; Tue, 2 Jul 2013 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_16=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 23vm+44DZcib for ; Tue, 2 Jul 2013 09:15:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6229621F9F47 for ; Tue, 2 Jul 2013 09:15:57 -0700 (PDT) Received: (qmail 17646 invoked from network); 2 Jul 2013 16:15:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Jul 2013 16:15:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51d2fcbb.xn--9vv.k1307; i=johnl@user.iecc.com; bh=Zk0k+jhk0WY46WozZF+MCebG+n/nrMyndNXVZAnee54=; b=s++zMDsig6vmYjC/vLJIdUo3k+EMWqBtC9QIeCTWh5jreQcSaUeLbC8a/BJRWlLMNsFoUqfLXbvVC8tfdBwE5sD1U2FIa/zHUzqgAaplzNohFZVsAmv9uqY8E/S//K2+O4GbTbeRXRT2qmKWkl9mZ4nJxMm8sKN3Otv9+TDDSDQYYwy7/2xgK+u1XvTJ0ArgyDb3xETp557o53LXGD56/WR7V5ghkv+rYmwvYs6XMAP+gudrojmS42TmjXaJbep2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51d2fcbb.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=Zk0k+jhk0WY46WozZF+MCebG+n/nrMyndNXVZAnee54=; b=FZUhLtIfo7MwfTzGFlAi1JFIXSkpWaal+hflsERzXAZvj1tLZRlCF8d/rianSKh3j8/lCGnv2iGSRzVbBb2WQ5x/bUWx6I/YEohzxsQzZeO34GMdSu2Lwq3hA8MC91TW8QJ/QWRkwfYBunTJZmcw9R8NMr+l0BEjyHB34+BQpnesGjJJ1NjmFyjHnGEADD2PRl9a0xZ9w1CUbTiqBA3CvhO+TnFC+x2Q1Hynr0L3FXMM2OP7DXJWWFd82qbU9rA9 Date: 2 Jul 2013 16:15:33 -0000 Message-ID: <20130702161533.21196.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: [dmarc-ietf] Notes from DMARC session at IETF 95 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:16:03 -0000 To save time, here are the notes from the final DMARC session, based on the current charter: Mailing lists: One person demanded that all list software change to preserve SPF and DKIM signatures. Another person said to whitelist based on A-R or List-ID headers until someone explained to him offline that bad guys can forge them, and can sign forged headers. A third person noted that after three years, LinkedIn is still almost the only domain anyone has seen sending p=reject mail to lists, and large ISPs all do their own proprietary list whitelisting, so problems with the clueless bouncing people off lists didn't happen. Conclusion: nothing to report. Transitive trust: Senders just love transitive trust, receivers see no benefit. The extension in draft-baer-dkim-transitive has been implemented by 14 senders but no receivers whose position (if you want us to deliver your mail, make it easy for us) has been unchanged since 1987. Conclusion: maybe publish it, but why bother. Robust report mechanisms: After a year of ever more complex proposals using https, https with client certificates, STARTTLS with client certificates, DANE, PGP, SIP/TLS and COAP, the group gave up and decided that DKIM signed email was as good as it gets. Oh, and you can skip sending aggregate reports for mail volume below a locally determined threshold. Conclusion: nothing beyond existing language in operations guide. Display name attacks: Several people suggested complex MUA changes to highlight or grey out various parts of messages, none implemented. A few people implemented draft-hammer-dmarc-display which extends DMARC to strings in the display name that resemble domain names, but found a large number of false alarms due to new domains like .web and was trivially avoided using UTF-8 homographs (what IDNA prohibits from domain names, see RFC 5892). Conclusion: publish as experimental, because the part about MUAs and homographs is interesting. Determining registered domain name: The group looked at draft-sullivan-domain-origin-assert and draft-levine-orgboundary, neither of which got any traction due to deep disagreements in the DNS community about what boundaries mean. The group gave up and kept using the Mozilla public suffix list which, for all its faults, actually exists. Conclusion: nothing beyond existing language in operations guide. Operations guide: draft-ietf-dmarc-ops-12 finally in last call, There haven't been any substantive changes since October 2013. The appeal demanding that DMARC use a new RRTYPE was rejected. R's, John From dcrocker@gmail.com Tue Jul 2 09:19:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC0121F896D for ; Tue, 2 Jul 2013 09:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVpwaOJt00DA for ; Tue, 2 Jul 2013 09:19:23 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1421F940D for ; Tue, 2 Jul 2013 09:19:20 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so2941612vcb.16 for ; Tue, 02 Jul 2013 09:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pZqsF1LAz9/Js7whPv01QHJMbnJdyn5Y1H8UsHfOqhI=; b=MPM1exMgO7SMmCSUHe3zLjOquVT6M0at4s7lAS31WagMyjEjOR5ZNAqv8Pa5Q0uAyb ZM7yIeNSyP/Wfa/bLf91otnP32a0E39EJQYjCCfUkYalvRQkiY1qSSCY/yfKcjDxa1hT 0RInlpsbhEhkhG4ZpHj0KYZ2mfOrWePEf6+0aheQYvDVwsaxUBtyoAjdPWeMXfFYZ/mn NUO1j9Q45MwGfOmER5ZYCltD9qTkK0hNK/i9GTk7zX134xvyTuqxByWJKwomx0MdCbFq 9Egugt9VjF6lGKsIeHa9NDfGqL1icB+HEynF1j8937lulLYM83LDyjedT/0x5MBFSB/Q 8pxQ== X-Received: by 10.220.59.69 with SMTP id k5mr11588330vch.34.1372781960123; Tue, 02 Jul 2013 09:19:20 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id p17sm17989976vdg.11.2013.07.02.09.19.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 09:19:19 -0700 (PDT) Message-ID: <51D2FD79.1060704@gmail.com> Date: Tue, 02 Jul 2013 09:19:05 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130702153138.21069.qmail@joyce.lan> In-Reply-To: <20130702153138.21069.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:19:24 -0000 On 7/2/2013 8:31 AM, John Levine wrote: >> What is the work to be done on the base document? > > I don't know, because nobody other than perhaps Murray knows what it > says. John, That's not true and you know it's not true. And the fact that it's not true has been explained repeatedly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From prvs=888df1167=fmartin@linkedin.com Tue Jul 2 11:22:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F386121F9A64 for ; Tue, 2 Jul 2013 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 xQ000rphxbVm for ; Tue, 2 Jul 2013 11:22:35 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id E239121F9A33 for ; Tue, 2 Jul 2013 11:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372789354; x=1404325354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D2k3v6InIEHwL2dWf07lc3pkb/FUH1vssHeTVH22v7c=; b=BAGkp8v+q3jsigzso+WY2raTue/NKS/zDn5vtLyGAbdRIlLGu+/XJYCI c6kwtx+Xpgvq/zf0aOajmM9dh6UqJaaL22swov1qQnFs5bLjDJSbQ+1eo XDDXkU8QyE4eKbyneg8rPESUTuzOgmF0pRwXuaToaYa+bIhJIg1ed/6PX A=; X-IronPort-AV: E=Sophos;i="4.87,982,1363158000"; d="scan'208";a="54517139" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Jul 2013 11:22:15 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 11:22:15 -0700 From: Franck Martin To: John Levine Thread-Topic: [dmarc-ietf] Notes from DMARC session at IETF 95 Thread-Index: AQHOdz+HpZ244Kv+m0mUHNriJ+SwOJlSKRAA Date: Tue, 2 Jul 2013 18:22:14 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE533DCBD1@ESV4-MBX01.linkedin.biz> References: <20130702161533.21196.qmail@joyce.lan> In-Reply-To: <20130702161533.21196.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dmarc-ietf] Notes from DMARC session at IETF 95 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:22:39 -0000 The world according to John "Crazy Franck" On Jul 2, 2013, at 9:15 AM, John Levine wrote: > To save time, here are the notes from the final DMARC session, > based on the current charter: >=20 From prvs=888df1167=fmartin@linkedin.com Tue Jul 2 11:44:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0321F9B57 for ; Tue, 2 Jul 2013 11:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=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 g0o4UBu0FF0o for ; Tue, 2 Jul 2013 11:44:40 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8316D21F99A4 for ; Tue, 2 Jul 2013 11:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372790680; x=1404326680; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=C4Pna/sOvaajmpMt0EJkHHxGrTvZPLNd6oKvXANjFvs=; b=Dux6pMu1yfXQLLZXDp4U9KU+Pv/X83unVShaErsY5u1CxhpeBZyIEzmz EUoGGPytXYlGrzDMiDopc2999gZWWxf5wPRXnCaW6ZHHEz94PVChNeSp+ dcycDqFUDkx0QgIwkv4nzh8iqmgGx19YYlA8BdhJIg1LKe+Ej8CH9/7KL U=; X-IronPort-AV: E=Sophos;i="4.87,982,1363158000"; d="scan'208";a="54519583" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Jul 2013 11:44:27 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 11:44:27 -0700 From: Franck Martin To: "dmarc@ietf.org" Thread-Topic: DMARC policy overrides Thread-Index: AQHOd1Qt4G/x1dE5/0mSwEkA7nXYtQ== Date: Tue, 2 Jul 2013 18:44:26 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:44:44 -0000 "DMARC-compliant Mail Receivers SHOULD disregard any mail directive discovered as part of an authentication mechanism (e.g., ADSP, SPF) where a DMARC policy is also discovered that specifies a policy other than "none". {R7} To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=3Dnone" SHOULD NOT modify existing mail disposition processing. Note that some Mail Receivers may reject email based upon SPF policy mechanisms before email enters DMARC-specific processing. Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting. {R10}" As a sender I want certainty in the processing. The DMARC mechanism is of b= etter strength than SPF alone, because it does SPF AND DKIM. However not ev= eryone does DMARC on the receiving side, so there is still a need to publis= h a -all SPF policy for the receivers that are not yet on DMARC. If a sende= r does DMARC with p!=3Dnone this is because it has a (serious) spoofing pro= blem. With such SPF policy I don't want it to overrides DMARC, as DMARC is of mor= e superior nature (this is my judgement otherwise I would not care about DM= ARC). But to encourage adoption, and make transition smooth, when p=3Dnone, the e= mail flow must not be affected by DMARC. DMARC is transparent to the email = in that case, providing reports to allow you to put your mail in order. The problem arises because SPF can be evaluated at the end of the RCPT TO p= hase, well before DKIM and therefore DMARC is evaluated. In practices, few = enforces SPF policy and uses it later as a scoring mechanism like spamassas= sin do. This is why in the text above there is a SHOULD, this brings constancy in t= he processing, but depending on the receiver infrastructure, then it certai= nly can deviate from ignoring SPF, but this is not the recommended practice= . Furthermore, for the aggregate reports to be accurate, they need to see all= the emails, regardless of SPF policy. Once you implement DMARC as a receiv= er, you should move your SPF policy decision to the end of DATA, so you can= make an accurate aggregate report. This will provide certainty on what wil= l happen when the sender moves away from p=3Dnone policy. A receiver can do what it wants, but the SHOULD above is common sense when = you decide to do DMARC as a receiver.=20 I think the text, could be more focused, and speak only of overriding only = policies that use the same underlying authentication mechanisms, and this i= s only SPF, DKIM and ADSP. TLS to other scheme would not be affected.= From johnl@iecc.com Tue Jul 2 11:51:42 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2564F21F9B9A for ; Tue, 2 Jul 2013 11:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.571 X-Spam-Level: X-Spam-Status: No, score=-110.571 tagged_above=-999 required=5 tests=[AWL=0.628, 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 OvwqOXgOBMiF for ; Tue, 2 Jul 2013 11:51:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE7921F9B97 for ; Tue, 2 Jul 2013 11:51:36 -0700 (PDT) Received: (qmail 46324 invoked from network); 2 Jul 2013 18:51:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Jul 2013 18:51:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d32137.xn--hew.k1307; i=johnl@user.iecc.com; bh=mT5pqYwOTj7DJuUuiJCzBoTPSulTS1GSFkgcaTtPDdY=; b=DNZV1nrtqCeeR/AXzWqntbDQE33EGMsMHdoJOF1ndXZgZJIlEXFGIkmQFcXBkcykICL+0I3bP/hyUmiVwejO2OqHa4cAjorOPQu83IqLHbQGx2TqsKIHbAWW5IcFvocCfk8FJLrJr0LEqdyIF2orY8lQ25daYKSL/6ihejpKP5AhZhIfaLH/uVOPc4wFfMrCJpgJeFGG3eWdOHol+Kf5YCC8KB0s2hpDvXjylRNkYRsIKNE1bNTW0WQvXOZ3IgLi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d32137.xn--hew.k1307; olt=johnl@user.iecc.com; bh=mT5pqYwOTj7DJuUuiJCzBoTPSulTS1GSFkgcaTtPDdY=; b=PRZQKEZY5TMLmXruMoyUzB6I34wVpUzBNtHGH40nuXKq2aH8TJY0zA+egIXy3aSArb53s54QS+RA/ip+r7tIEQ+DFS6PfPTBD+EJ1/IEhsmITgWPZodjwcYkqowMOiBQrD5untCRwTzEAnVTqSvtzoPJUyWmIjwkB+rveg/huB51YicMT2+Gpfagj3ykS7PjziFAHg4W5gJpBp7cxc6RmY9/k/jsQ2Z8IMbvwBy8USMB/p/Ok7j4bRk1DwqOeT5+ Date: 2 Jul 2013 18:51:13 -0000 Message-ID: <20130702185113.21926.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <20130702153138.21069.qmail@joyce.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:51:42 -0000 >>> Replace the second and third paragraphs with: >>> >>> The working group will adopt draft-kucherawy-dmarc-base as an input >> >>What is the work to be done on the base document? One final thought and then I'll stop: If you think that there is some chance of making progress on the first four charter items, it seems likely that the results of that progress would go into the base document. I suppose an alternative would be to send the base document through separately, then after it's published charter dmarcbis that would start with the RFC as an input, a highly compressed version of what spfbis is doing, but that seems like a lot of extra work for no benefit. R's, John From sklist@kitterman.com Tue Jul 2 11:58:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F058421F9BBB for ; Tue, 2 Jul 2013 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=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 9xAq36xktT5q for ; Tue, 2 Jul 2013 11:58:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46ABA21F9B9A for ; Tue, 2 Jul 2013 11:58:15 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A69DBD0408B; Tue, 2 Jul 2013 14:58:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372791493; bh=E9e8OJUEWvuRfTFu05llZ8U2WJbok8cKExtok5TOU0Q=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Jeh4i3qt6GCt5XiAxpf3O94kq70/zVTwsfpzTjoXvbZ1e8D2UXL4pZ3doTP0vKD1N FJLHtYffgXh1yLuDZ16umwMcc2/YrF8SsONJs5/RZXpHbB/hHwL3WXcyp9/78SNt0o EYj62d40v+oZ14OAJB0YdUpnurvcRgUoqVnFKpaA= Received: from [IPV6:2600:1003:b113:8b19:99c2:69b6:77b0:d672] (unknown [IPv6:2600:1003:b113:8b19:99c2:69b6:77b0:d672]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0B552D04040; Tue, 2 Jul 2013 14:58:12 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 02 Jul 2013 14:58:09 -0400 To: "dmarc@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:58:16 -0000 Except you can't tell if DMARC applies to a message until DATA, so the only way to implement this is to change all SPF checks to after DATA whether they are related to DMARC or not. I think imposing such architectural change on unrelated message processing is inappropriate. I think some discussion of this absent the 2119 words is fine. Scott K Franck Martin wrote: >"DMARC-compliant Mail Receivers SHOULD disregard any mail directive > discovered as part of an authentication mechanism (e.g., ADSP, SPF) > where a DMARC policy is also discovered that specifies a policy other > than "none". {R7} To enable Domain Owners to receive DMARC feedback > without impacting existing mail processing, discovered policies of > "p=none" SHOULD NOT modify existing mail disposition processing. > Note that some Mail Receivers may reject email based upon SPF policy > mechanisms before email enters DMARC-specific processing. > > Mail Receivers SHOULD also implement reporting instructions of DMARC > in place of any extensions to SPF or DKIM that might enable such > reporting. {R10}" > >As a sender I want certainty in the processing. The DMARC mechanism is >of better strength than SPF alone, because it does SPF AND DKIM. >However not everyone does DMARC on the receiving side, so there is >still a need to publish a -all SPF policy for the receivers that are >not yet on DMARC. If a sender does DMARC with p!=none this is because >it has a (serious) spoofing problem. > >With such SPF policy I don't want it to overrides DMARC, as DMARC is of >more superior nature (this is my judgement otherwise I would not care >about DMARC). > >But to encourage adoption, and make transition smooth, when p=none, the >email flow must not be affected by DMARC. DMARC is transparent to the >email in that case, providing reports to allow you to put your mail in >order. > >The problem arises because SPF can be evaluated at the end of the RCPT >TO phase, well before DKIM and therefore DMARC is evaluated. In >practices, few enforces SPF policy and uses it later as a scoring >mechanism like spamassassin do. > >This is why in the text above there is a SHOULD, this brings constancy >in the processing, but depending on the receiver infrastructure, then >it certainly can deviate from ignoring SPF, but this is not the >recommended practice. > >Furthermore, for the aggregate reports to be accurate, they need to see >all the emails, regardless of SPF policy. Once you implement DMARC as a >receiver, you should move your SPF policy decision to the end of DATA, >so you can make an accurate aggregate report. This will provide >certainty on what will happen when the sender moves away from p=none >policy. > >A receiver can do what it wants, but the SHOULD above is common sense >when you decide to do DMARC as a receiver. > >I think the text, could be more focused, and speak only of overriding >only policies that use the same underlying authentication mechanisms, >and this is only SPF, DKIM and ADSP. TLS to other scheme would not be >affected. >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From prvs=888df1167=fmartin@linkedin.com Tue Jul 2 12:12:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39B821F9BB4 for ; Tue, 2 Jul 2013 12:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=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 etDB7m9sWKcr for ; Tue, 2 Jul 2013 12:12:39 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id D494311E80D3 for ; Tue, 2 Jul 2013 12:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372792346; x=1404328346; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fU3GfFJEcK5E83vqC9jDdHYPHog4L6S6wVWyEVTuxhU=; b=AhFIUZX1sOCQgEaYinyEls2UlWPq0x8MxHd1DV8OKXR/BofRquBPMVYu hAoG9qTvq8zOWbypK+ZZVRBaq4DYRUXwbrkTQ9UeSc/zSFY1IApPbHQdo saLXNGXUCbo2F5R2ADQcEKZogDWWpMgUrPTPbjIV/OBSjSTxoJEx/+OSd I=; X-IronPort-AV: E=Sophos;i="4.87,982,1363158000"; d="scan'208";a="54522522" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Jul 2013 12:11:51 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 12:11:51 -0700 From: Franck Martin To: Scott Kitterman Thread-Topic: [dmarc-ietf] DMARC policy overrides Thread-Index: AQHOd1Qt4G/x1dE5/0mSwEkA7nXYtZlSMt+AgAAD44A= Date: Tue, 2 Jul 2013 19:11:50 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE533DDDF6@ESV4-MBX01.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D1236F921B6184DA49CD75A9752A934@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:12:43 -0000 This is what I just said, if you want to implement DMARC as a receiver this= is what you have to do, for all the reasons I have explained. You are free= to not implement DMARC as a receiver if your infrastructure cannot do it, = but you are not free to implement it in a way that brings inconsistency acr= oss implementers which create inconsistent aggregate reports and therefore = email discarding because the receiver does not send to the sender a complet= e view. On Jul 2, 2013, at 11:58 AM, Scott Kitterman wrote: > Except you can't tell if DMARC applies to a message until DATA, so the on= ly way to implement this is to change all SPF checks to after DATA whether = they are related to DMARC or not. I think imposing such architectural chan= ge on unrelated message processing is inappropriate. I think some discussio= n of this absent the 2119 words is fine. >=20 > Scott K >=20 > Franck Martin wrote: >=20 >> "DMARC-compliant Mail Receivers SHOULD disregard any mail directive >> discovered as part of an authentication mechanism (e.g., ADSP, SPF) >> where a DMARC policy is also discovered that specifies a policy other >> than "none". {R7} To enable Domain Owners to receive DMARC feedback >> without impacting existing mail processing, discovered policies of >> "p=3Dnone" SHOULD NOT modify existing mail disposition processing. >> Note that some Mail Receivers may reject email based upon SPF policy >> mechanisms before email enters DMARC-specific processing. >>=20 >> Mail Receivers SHOULD also implement reporting instructions of DMARC >> in place of any extensions to SPF or DKIM that might enable such >> reporting. {R10}" >>=20 >> As a sender I want certainty in the processing. The DMARC mechanism is >> of better strength than SPF alone, because it does SPF AND DKIM. >> However not everyone does DMARC on the receiving side, so there is >> still a need to publish a -all SPF policy for the receivers that are >> not yet on DMARC. If a sender does DMARC with p!=3Dnone this is because >> it has a (serious) spoofing problem. >>=20 >> With such SPF policy I don't want it to overrides DMARC, as DMARC is of >> more superior nature (this is my judgement otherwise I would not care >> about DMARC). >>=20 >> But to encourage adoption, and make transition smooth, when p=3Dnone, th= e >> email flow must not be affected by DMARC. DMARC is transparent to the >> email in that case, providing reports to allow you to put your mail in >> order. >>=20 >> The problem arises because SPF can be evaluated at the end of the RCPT >> TO phase, well before DKIM and therefore DMARC is evaluated. In >> practices, few enforces SPF policy and uses it later as a scoring >> mechanism like spamassassin do. >>=20 >> This is why in the text above there is a SHOULD, this brings constancy >> in the processing, but depending on the receiver infrastructure, then >> it certainly can deviate from ignoring SPF, but this is not the >> recommended practice. >>=20 >> Furthermore, for the aggregate reports to be accurate, they need to see >> all the emails, regardless of SPF policy. Once you implement DMARC as a >> receiver, you should move your SPF policy decision to the end of DATA, >> so you can make an accurate aggregate report. This will provide >> certainty on what will happen when the sender moves away from p=3Dnone >> policy. >>=20 >> A receiver can do what it wants, but the SHOULD above is common sense >> when you decide to do DMARC as a receiver.=20 >>=20 >> I think the text, could be more focused, and speak only of overriding >> only policies that use the same underlying authentication mechanisms, >> and this is only SPF, DKIM and ADSP. TLS to other scheme would not be >> affected. From dcrocker@gmail.com Tue Jul 2 12:13:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8037711E80F2 for ; Tue, 2 Jul 2013 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFuZHmkrEurx for ; Tue, 2 Jul 2013 12:13:16 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2F11E80F8 for ; Tue, 2 Jul 2013 12:13:10 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so12894328iea.4 for ; Tue, 02 Jul 2013 12:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fqZggyowlT61igEuLkmoWFbWo1p/UkI+K5a0vJA+egY=; b=yj6GMRwEGUWCy2IW8vnsxEhSNXNFaTlb85xYjo8BYzDPC4HplH8wICUyY+2IuaQNSc ldtzuAuVyif+PpNDrCPHvZMk+gm5h5ukdzSv6MDHiiumErCUohymKp9xIQhLr7vEsVKO hyDjZF0tWSls4gUnd3UEh3SSFs/WFsXJgvm5j4/5R2vrVymA9kFYhgplMgYHBnsZBri8 aoeyKuRTF+GgIHblAYFdANP+WRtjNqoXvFZJQOZwT5xgnvm8e2xU9PuZC9uQi3IRY6oI s5H3PgAoqyBPQig/1yWc4pJej9lUHqqC+S3UaKkoz0ga5bs+jJIVaUNfH+0JnYgIEin9 KDpQ== X-Received: by 10.50.112.5 with SMTP id im5mr22718785igb.23.1372792388726; Tue, 02 Jul 2013 12:13:08 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id ff19sm19820074igb.0.2013.07.02.12.13.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 12:13:07 -0700 (PDT) Message-ID: <51D32635.5090206@gmail.com> Date: Tue, 02 Jul 2013 12:12:53 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130702185113.21926.qmail@joyce.lan> In-Reply-To: <20130702185113.21926.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:13:17 -0000 On 7/2/2013 11:51 AM, John Levine wrote: >>>> Replace the second and third paragraphs with: >>>> >>>> The working group will adopt draft-kucherawy-dmarc-base as an input >>> >>> What is the work to be done on the base document? > > One final thought and then I'll stop: If you think that there is some > chance of making progress on the first four charter items, it seems > likely that the results of that progress would go into the base > document. > > I suppose an alternative would be to send the base document through > separately, then after it's published charter dmarcbis that would > start with the RFC as an input, a highly compressed version of what > spfbis is doing, but that seems like a lot of extra work for no > benefit. Your presumption is that it's necessary to make changes to the base document for these enhancements. Mine is that it isn't. So we don't need to wait. We can proceed with the listed tasks now. If we find that we really do need to wait... we can. Your approach imposes potentially unnecessary delay. Mine doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Tue Jul 2 12:35:46 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE221F9A16 for ; Tue, 2 Jul 2013 12:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ1uiLOlbVue for ; Tue, 2 Jul 2013 12:35:45 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 759F921F9971 for ; Tue, 2 Jul 2013 12:35:43 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so12954075iec.22 for ; Tue, 02 Jul 2013 12:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=axvIeTL+t2ELt364PXtsyVFhuWBNt8KOLqVv4LFs5nY=; b=pJaKG+X4+qpfs1LmpBBJsPY8K154drsirG506KgPgOo1Uqpe8v4bCaAHVJiK4+dSNd aTKi+SQnWV4VIpcPQ+ch6z1tiIXjMFJY+9/wbwnO2jMoT5f1rvxZck3ZBI0pN4UjlPm8 juiSfR/lU6dk8gxstw+2CiIGJHL4R83qXjpSpi+o4+cMYYDk5DyQC4fvvRjZW53MgfL3 NQGqvdbpk88wBbpACD1AG7JNab8TAtH2qFUV4H4Pa7ueXkdFMqWbS/41VmNwCC4HH80e yBztY2HH42il4JkpiP/+8iSpstO8ME4FtaIpI1YJGY8UPCuiSmgTNXx8IE4QXuposPvb hcKw== X-Received: by 10.50.56.20 with SMTP id w20mr22231466igp.40.1372793742051; Tue, 02 Jul 2013 12:35:42 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id fu2sm19901091igb.3.2013.07.02.12.35.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 12:35:41 -0700 (PDT) Message-ID: <51D32B7F.40007@gmail.com> Date: Tue, 02 Jul 2013 12:35:27 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:35:46 -0000 My own view is that we should not call this anything as formal as 'policy overrides'. What it is is simply leaving the DMARC spec. Let me repeat: If someone does something differently than the DMARC says they need to do, they are no longer performing DMARC. Anyone can do that whenever they want. The results will be outside the spec, too. DMARC dictates some behaviors. Participants choose to... participate. They can choose not to. If they choose to participate only partially, they risk unknown results including non-interoperability. That's their choice. d/ From superuser@gmail.com Tue Jul 2 13:42:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F53D21F9B87 for ; Tue, 2 Jul 2013 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHRRpD0W2IXa for ; Tue, 2 Jul 2013 13:42:50 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A921F9B35 for ; Tue, 2 Jul 2013 13:42:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so4587434wib.2 for ; Tue, 02 Jul 2013 13:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yQcCUexuGaXycLOuugos0+fXZ+waku4YyjnPZkO2aaU=; b=Ujn5K0dZA/F/YegUorGtiayHeSCDOBEsWhX1IqAvo4wBldCiFJ2BRHhNsvASKmqHOH NOBd7m+WGe0Z6yWVZuknvrgO0ydztBcF1IJzDSy+EW/nztB2GLBafZL6p0ckogJPYvpB v6Fis0VhKbHBGhrc/pdsHr3gAgm1nY3he5/0dhss6raIq1EBhRa/T1tvey+9SOp2PT6G wAX665ZIy6iB9g/UTVPZG34ZZ1Il7bZOGohbXs3U2JUu8R/bujVz0Bo7mH0GbJ5uEEgs ylbmHzfTnKwDYFiMLxYCyeAN1Y+Kr4UO7mH//hC53eNmJMu3dmiPZ+2kkA1vYkevU+1/ BMDg== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr2274244wic.19.1372797769023; Tue, 02 Jul 2013 13:42:49 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 2 Jul 2013 13:42:48 -0700 (PDT) In-Reply-To: <51D32B7F.40007@gmail.com> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D32B7F.40007@gmail.com> Date: Tue, 2 Jul 2013 13:42:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c3436a5f06b204e08d6312 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:42:50 -0000 --001a11c3436a5f06b204e08d6312 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 12:35 PM, Dave Crocker wrote: > My own view is that we should not call this anything as formal as 'policy > overrides'. > > What it is is simply leaving the DMARC spec. Let me repeat: If someone > does something differently than the DMARC says they need to do, they are no > longer performing DMARC. > > Anyone can do that whenever they want. The results will be outside the > spec, too. > > DMARC dictates some behaviors. Participants choose to... participate. > They can choose not to. > > If they choose to participate only partially, they risk unknown results > including non-interoperability. That's their choice. It seems to me that prose which spells this out, including the costs of the "override" (namely processing through to the end of DATA), is potentially a fine compromise. I also think it's necessary to consider some current realities. In an architecture such as the one I use, filters operate serially on the data. The SPF module runs ahead of DKIM, which in turn runs ahead of DMARC. If the SPF module decides to act on a "-all" and reject the message, DMARC and DKIM simply can't happen. DMARC, by saying SHOULD over SPF, is attempting to require that the SPF module change what it's doing. That means, at least in my local example, that DMARC is not a pure overlay atop SPF and DKIM. -MSK --001a11c3436a5f06b204e08d6312 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 2, 2013 at 12:35 PM, Dave Crocker <dcrocker@= gmail.com> wrote:
My own view is that we should not call this = anything as formal as 'policy overrides'.

What it is is simply leaving the DMARC spec. =A0Let me repeat: =A0If someon= e does something differently than the DMARC says they need to do, they are = no longer performing DMARC.

Anyone can do that whenever they want. =A0The results will be outside the s= pec, too.

DMARC dictates some behaviors. =A0Participants choose to... participate. Th= ey can choose not to.

If they choose to participate only partially, they risk unknown results inc= luding non-interoperability. =A0That's their choice.

= It seems to me that prose which spells this out, including the costs of the= "override" (namely processing through to the end of DATA), is po= tentially a fine compromise.

I also think it's necessary to consider some current rea= lities.=A0 In an architecture such as the one I use, filters operate serial= ly on the data.=A0 The SPF module runs ahead of DKIM, which in turn runs ah= ead of DMARC.=A0 If the SPF module decides to act on a "-all" and= reject the message, DMARC and DKIM simply can't happen.=A0 DMARC, by s= aying SHOULD over SPF, is attempting to require that the SPF module change = what it's doing.=A0 That means, at least in my local example, that DMAR= C is not a pure overlay atop SPF and DKIM.

-MSK

--001a11c3436a5f06b204e08d6312-- From dcrocker@gmail.com Tue Jul 2 13:59:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF321F8B21 for ; Tue, 2 Jul 2013 13:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ierl1gcRXB for ; Tue, 2 Jul 2013 13:59:30 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A322021F8B33 for ; Tue, 2 Jul 2013 13:59:30 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so6030972obc.38 for ; Tue, 02 Jul 2013 13:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CWmc26cGMqQoh+CKXAtWJHU/apoQYOX2W0Fk3fPAUxg=; b=vGRYIUe9/AgsliJogLnihxzEZvZggXOdxzC76+CMnQue+FOQsIDwFK5MSxnkCNPY+4 iEzclkHGGwtVK4nKaD1r8DInk2ZEplqTi0pas9VSsOfKxk3gYdPw5X5emEvDXmK1MeOn IKygQvCTayDhYG+M1O5xlvk6S20hBtLeWMQVfJI/hGSgH6HuUZROxHtyvNnr+YYbP5zj itlrDIzdX1p49E0mlSOAxMl1ywgtKoL6Nzu0smeCzF937GcUB8Z4hrjVGEuBC1gYb1/v wQ6JKJ4HdSiokeR/tfRIV87FE5L7Q8vbDzhYxbM0+jFxwgY1uD1yRQ2s9xaxU/NiZaIf fZ6w== X-Received: by 10.182.233.137 with SMTP id tw9mr14105878obc.2.1372798770214; Tue, 02 Jul 2013 13:59:30 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id x10sm6714157obw.13.2013.07.02.13.59.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 13:59:29 -0700 (PDT) Message-ID: <51D33F23.8050502@gmail.com> Date: Tue, 02 Jul 2013 13:59:15 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D32B7F.40007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:59:31 -0000 On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote: > It seems to me that prose which spells this out, including the costs of > the "override" (namely processing through to the end of DATA), is > potentially a fine compromise. Since the horse is possible still having some spasms, whether alive or not, I'll beat it some more: My comments are about language, not technical details. My concern is that the language many folk are using can lead to misunderstanding what is inside or outside the spec. > I also think it's necessary to consider some current realities. In an > architecture such as the one I use, filters operate serially on the > data. The SPF module runs ahead of DKIM, which in turn runs ahead of > DMARC. If the SPF module decides to act on a "-all" and reject the > message, DMARC and DKIM simply can't happen. DMARC, by saying SHOULD > over SPF, is attempting to require that the SPF module change what it's > doing. That means, at least in my local example, that DMARC is not a > pure overlay atop SPF and DKIM. Right. It's not. As for DMARC 'replacing' some SPF portions, yeah, it's doing that. If someone thinks the text is not sufficiently clear about what is specified to do or why, we know how to fix that. As for /whether/ to do it, again, one can choose to live within DMARC or... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From R.E.Sonneveld@sonnection.nl Tue Jul 2 14:30:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FE721F9AA2 for ; Tue, 2 Jul 2013 14:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lxWiAvY-gJH for ; Tue, 2 Jul 2013 14:29:58 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D727321F9AA0 for ; Tue, 2 Jul 2013 14:29:57 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3blJWP2vpGz1L8cB; Tue, 2 Jul 2013 23:29:53 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3blJWP1PVlz1L8b9; Tue, 2 Jul 2013 23:29:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id D6DEA1230A0; Tue, 2 Jul 2013 23:29:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Od693CDfYgQa; Tue, 2 Jul 2013 23:29:50 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id EDD58123042; Tue, 2 Jul 2013 23:29:49 +0200 (CEST) Message-ID: <51D3464D.2060502@sonnection.nl> Date: Tue, 02 Jul 2013 23:29:49 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130702052746.15876.qmail@joyce.lan> In-Reply-To: <20130702052746.15876.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1372800593; bh=nwQx3zyA/AObbGgMCmfwVYlgg2jCWGkAPK9NrZz4t4Q=; h=Message-ID:Date:From:To:Subject:From; b=fSlnXRL5KkdGOy7fyheV+02Umxy9UBTbTl6P96iLtMAlU7ojspmQSOa0bJ7YyO2T4 F0Af1qN/DexMvb5f2TY4VBznZqPUYP1K30b1zve+i1aqhUBOJo4Mh/ar/cd007GQFu GctvqrOPocgEk5iJl4R1DtX6YfGuPRoCknOdTK60= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3blJWP2vpGz1L8cB Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:30:02 -0000 On 07/02/2013 07:27 AM, John Levine wrote: >> What I think would be more productive here is discussion of what's in the >> proposed charter. > Replace the second and third paragraphs with: > > The working group will adopt draft-kucherawy-dmarc-base as an input > document and any other drafts the the group deems relevant and useful, > with the goal of publishing a standards track DMARC specification and > posssibly other documents. +1 > In view of the large base of running DMARC > code, the group will avoid changes that would cause incompatible > changes to bits on the wire. -1 Granted, the installed base is large, but let's not ignore the other 40 percent of the Internet. IETF standards are standards for the _entire_ Internet community, not just ten or twenty of the largest companies in a specific area. The WG should not be bound by 'bits on the wire' in their review and possible comments on the standard. Otherwise the IETF is to a large extent degraded to the 'rubber stamp business' Scott mentioned. Don't get me wrong: the outcome of the discussions may well be that nothing will change on the wire and that'd be fine. But including this in the Charter as a precondition for the work to be done is wrong in my opinion. > Delete the 13th paragraph. Not sure which one is that? Just to make sure we're on the same page: we're talking about http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC, isn't it? > Delete discussions of mailing lists which are > a hopeless black hole. Adjust the schedule to taste. > > > Alternatively, per my previous colloquy with Dave, delete text > starting with "Email abuse often ..." and ending with "... guide to > WGLC." +1 /rolf From sklist@kitterman.com Tue Jul 2 14:54:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DD821F901A for ; Tue, 2 Jul 2013 14:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNh4dPIJ0OCs for ; Tue, 2 Jul 2013 14:54:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F28BD11E8104 for ; Tue, 2 Jul 2013 14:53:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1552F20E40FC; Tue, 2 Jul 2013 17:53:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372802028; bh=X8flGyKOa84zeVumgMNDnTPx0KGn22m8wY+Dvpi4//w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qZWGQtdozrA/5FJYy3GkZVNALjr2/apHCKT4hKlbv4zXa6hNgtIYD5cO2JRXqOhca HjqHIgmck+JFAr2rCGIuYqGmZCE3jJVQ6kRsowbPSYD1Wbqw4+cSoKB+ElJ1+e40uI wKpAo3RFgRtjptmyqMLwPEfQOAeVhP3hYUPCIG80= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E9A0820E40D5; Tue, 2 Jul 2013 17:53:47 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Tue, 02 Jul 2013 17:53:45 -0400 Message-ID: <1458562.mnNGVq3FHH@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <51D33F23.8050502@gmail.com> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D33F23.8050502@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:54:24 -0000 On Tuesday, July 02, 2013 01:59:15 PM Dave Crocker wrote: > On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote: > > It seems to me that prose which spells this out, including the costs of > > the "override" (namely processing through to the end of DATA), is > > potentially a fine compromise. > > Since the horse is possible still having some spasms, whether alive or > not, I'll beat it some more: My comments are about language, not > technical details. My concern is that the language many folk are using > can lead to misunderstanding what is inside or outside the spec. > > > I also think it's necessary to consider some current realities. In an > > architecture such as the one I use, filters operate serially on the > > data. The SPF module runs ahead of DKIM, which in turn runs ahead of > > DMARC. If the SPF module decides to act on a "-all" and reject the > > message, DMARC and DKIM simply can't happen. DMARC, by saying SHOULD > > over SPF, is attempting to require that the SPF module change what it's > > doing. That means, at least in my local example, that DMARC is not a > > pure overlay atop SPF and DKIM. > > Right. It's not. > > As for DMARC 'replacing' some SPF portions, yeah, it's doing that. > > If someone thinks the text is not sufficiently clear about what is > specified to do or why, we know how to fix that. As for /whether/ to do > it, again, one can choose to live within DMARC or... Ah, so DMARC is what it's defined as, so by definition any suggestion that it should be changed is incorrect. Got it. Glad we cleared that up. Scott K From prvs=888df1167=fmartin@linkedin.com Tue Jul 2 15:22:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC211E8107 for ; Tue, 2 Jul 2013 15:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 J73KP28trm+w for ; Tue, 2 Jul 2013 15:22:15 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91D11E8105 for ; Tue, 2 Jul 2013 15:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1372803735; x=1404339735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qUtFrk9CFyfqpGmM+ExFNr+UcVOgw1A2lwpTLfgH848=; b=kX/sbDQ5slC4Zgurx7BiihWqzMQTrUBXZHZuoAn/9c2+rrnWDk+a2186 Y5MN3iFlf+9wPk0KZogxD1A+oYX+hjiWMlG4cr6Ta9Ijo89yyNye8Nmwt n3Rm0qWQdE5KeaHOLxJquBG3iVv1K7yoeRRDbhFBcbPxB/ZE4NKMRHCCx M=; X-IronPort-AV: E=Sophos;i="4.87,983,1363158000"; d="scan'208";a="52920424" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Jul 2013 15:21:57 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Jul 2013 15:21:57 -0700 From: Franck Martin To: Scott Kitterman Thread-Topic: [dmarc-ietf] DMARC policy overrides Thread-Index: AQHOd1Qt4G/x1dE5/0mSwEkA7nXYtZlSPUuAgAAS0gCAAASYgIAADzqAgAAH8IA= Date: Tue, 2 Jul 2013 22:21:56 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53A1279D@ESV4-MBX02.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D33F23.8050502@gmail.com> <1458562.mnNGVq3FHH@scott-latitude-e6320> In-Reply-To: <1458562.mnNGVq3FHH@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A136E076878E7409A9F7361823D4270@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 22:22:19 -0000 On Jul 2, 2013, at 2:53 PM, Scott Kitterman wrote: > On Tuesday, July 02, 2013 01:59:15 PM Dave Crocker wrote: >> On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote: >>> It seems to me that prose which spells this out, including the costs of >>> the "override" (namely processing through to the end of DATA), is >>> potentially a fine compromise. >>=20 >> Since the horse is possible still having some spasms, whether alive or >> not, I'll beat it some more: My comments are about language, not >> technical details. My concern is that the language many folk are using >> can lead to misunderstanding what is inside or outside the spec. >>=20 >>> I also think it's necessary to consider some current realities. In an >>> architecture such as the one I use, filters operate serially on the >>> data. The SPF module runs ahead of DKIM, which in turn runs ahead of >>> DMARC. If the SPF module decides to act on a "-all" and reject the >>> message, DMARC and DKIM simply can't happen. DMARC, by saying SHOULD >>> over SPF, is attempting to require that the SPF module change what it's >>> doing. That means, at least in my local example, that DMARC is not a >>> pure overlay atop SPF and DKIM. >>=20 >> Right. It's not. >>=20 >> As for DMARC 'replacing' some SPF portions, yeah, it's doing that. >>=20 >> If someone thinks the text is not sufficiently clear about what is >> specified to do or why, we know how to fix that. As for /whether/ to do >> it, again, one can choose to live within DMARC or... >=20 > Ah, so DMARC is what it's defined as, so by definition any suggestion tha= t it=20 > should be changed is incorrect. Got it. Glad we cleared that up. >=20 Scott, There are more than 20 people that developed this spec, we reached consensu= s on this is the best path and we deployed it and we have not seen it shoul= d be done otherwise. Any suggestion that it should be changed is not incorr= ect, it needs more support than the 20 people or so behind it...=20 As Barry said, review the current spec, build support and the spec will be = changed. It seems I'm flogging a dead horse here. From matt@tnpi.net Tue Jul 2 15:39:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C1521F8421 for ; Tue, 2 Jul 2013 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eUcy27osjCD for ; Tue, 2 Jul 2013 15:39:09 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA721F99E3 for ; Tue, 2 Jul 2013 15:39:09 -0700 (PDT) Received: (qmail 82625 invoked by uid 1026); 2 Jul 2013 22:39:08 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Tue, 02 Jul 2013 18:39:08 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.7 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; s=mar2013; bh=tc3dRqnWtJGfyaW/NxaSIYi6U3FdxoMXOceffeBFl/Q=; b=l93Y5brSkwFuEsYGNZ0h5ikEXyPLV5c0kP51zbS5ohZuyCFoErVe7UcGVcjgs8AcljIQMmIEyMu2RxWMZDBBGgNeKgl9KHdavoZ50Z3kgw15ueO+3hMg18Y/5E8+7ZJpjDvSlgHuEN4MAYls+PixXbJpC09BTNrJuuF9OyithYY3862Ocmb1Aw3hXMN1cLj09X9+WQcoBC63xiar8BNPxjGRtg8wCZwUKy//IXI1Wi4jyYz4rKoy1tQCBjUGLRg9ZR1yQdEHix1/cSzp4wTrdyvzk2C9j/9fMf3H5fXW0eV1vm9BzhG0iQ9H1pclkQixOyXm4pqZklj/Bf5A0adEOw== X-HELO: [10.0.1.32] Content-Type: multipart/alternative; boundary="Apple-Mail=_0351DA70-7FCD-400E-ABD9-262909D6EDCE" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: Date: Tue, 2 Jul 2013 15:39:06 -0700 Message-Id: References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D32B7F.40007@gmail.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 22:39:14 -0000 --Apple-Mail=_0351DA70-7FCD-400E-ABD9-262909D6EDCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 2, 2013, at 1:42 PM, "Murray S. Kucherawy" = wrote: > I also think it's necessary to consider some current realities. In an = architecture such as the one I use, filters operate serially on the = data. The SPF module runs ahead of DKIM, which in turn runs ahead of = DMARC. That is how I deploy as well. > If the SPF module decides to act on a "-all" and reject the message, = DMARC and DKIM simply can't happen. SPF just returns a policy result. Whether or not your SPF module decides = to reject the message based on that is a function of your module. It is = only your *implementation* that needs to be modified, not SPF. I use qpsmtpd "out front" and I hacked in a universal 'reject' method = that plugins call when they want to reject a message. Each plugin gets = to specify a reject type. Most plugins (like SPF & DKIM) have a reject = method of deferred, letting all the plugins have a go at the message = first. Later plugins can override earlier ones (DMARC can override SPF = and/or DKIM, AUTH can override everything, etc).=20 > DMARC, by saying SHOULD over SPF, is attempting to require that the = SPF module change what it's doing. That means, at least in my local = example, that DMARC is not a pure overlay atop SPF and DKIM. I run SPF and DKIM with a deferred rejection and then run the DMARC = plugin. If no DMARC policy is published, then the DMARC plugin exits = and any deferred rejections get applied later. If a DMARC policy is = discovered, then any SPF and DKIM rejections should be nulled.=20 Again, these are implementation issues, not SPF or DKIM issues. Matt= --Apple-Mail=_0351DA70-7FCD-400E-ABD9-262909D6EDCE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Jul 2, 2013, = at 1:42 PM, "Murray S. Kucherawy" <superuser@gmail.com> = wrote:

I also think it's necessary to = consider some current realities.  In an architecture such as the = one I use, filters operate serially on the data.  The SPF = module runs ahead of DKIM, which in turn runs ahead of DMARC. =

That is how I deploy as = well.

If the SPF module decides = to act on a "-all" and reject the message, DMARC and DKIM simply can't = happen.

SPF just returns a policy = result. Whether or not your SPF module decides to reject the message = based on that is a function of your module.  It is only your = *implementation* that needs to be modified, not = SPF.

I use qpsmtpd "out front" and I hacked in = a universal 'reject' method that plugins call when they want to reject a = message. Each plugin gets to specify a reject type. Most plugins (like = SPF & DKIM) have a reject method of deferred, letting = all the plugins have a go at the message first. Later plugins can = override earlier ones (DMARC can override SPF and/or DKIM, AUTH can = override everything, etc). 

DMARC,= by saying SHOULD over SPF, is attempting to require that the SPF = module change what it's doing.  That means, at least in = my local example, that DMARC is not a pure overlay atop SPF and = DKIM.

I run SPF and DKIM with a = deferred rejection and then run the DMARC plugin.  If no DMARC = policy is published, then the DMARC plugin exits and any deferred = rejections get applied later.  If a DMARC policy is discovered, = then any SPF and DKIM rejections should be = nulled. 

Again, these are implementation = issues, not SPF or DKIM = issues.

Matt
= --Apple-Mail=_0351DA70-7FCD-400E-ABD9-262909D6EDCE-- From sklist@kitterman.com Tue Jul 2 15:47:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2A511E8105 for ; Tue, 2 Jul 2013 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ghpZQIvZoFLv for ; Tue, 2 Jul 2013 15:47:12 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6693511E8100 for ; Tue, 2 Jul 2013 15:47:12 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BE12CD0408B; Tue, 2 Jul 2013 18:47:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372805231; bh=8pTD1RrYrW+wxoe4VJBbqvLK4+VwFFtt4lEkyS/znR8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=KHG/dJTQX7k5x7yhEmmMrhfs4yGOdcmKw7siQeJJf9ePIRC/7quVOY93e7Sieqc5E 1bvh7Xj6JrxBfw0jf2IUw1zqD+1JCxZqU/OpTb/sIiA37Yz3l/qTgdOsjhIiev01P/ 3IeAPJv98DDklofWdVV5iKkN2Lq7wd45XGS0ORJk= Received: from [IPV6:2600:1003:b113:8b19:56df:75d7:c1c7:679d] (unknown [IPv6:2600:1003:b113:8b19:56df:75d7:c1c7:679d]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1FD20D04040; Tue, 2 Jul 2013 18:47:10 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <77426B543150464AA3F30DF1A91365DE53A1279D@ESV4-MBX02.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D33F23.8050502@gmail.com> <1458562.mnNGVq3FHH@scott-latitude-e6320> <77426B543150464AA3F30DF1A91365DE53A1279D@ESV4-MBX02.linkedin.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 02 Jul 2013 18:46:57 -0400 To: "dmarc@ietf.org" Message-ID: <675b2b90-64f8-4c7d-899c-3d3080c961a2@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 22:47:13 -0000 Franck Martin wrote: > >On Jul 2, 2013, at 2:53 PM, Scott Kitterman > wrote: > >> On Tuesday, July 02, 2013 01:59:15 PM Dave Crocker wrote: >>> On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote: >>>> It seems to me that prose which spells this out, including the >costs of >>>> the "override" (namely processing through to the end of DATA), is >>>> potentially a fine compromise. >>> >>> Since the horse is possible still having some spasms, whether alive >or >>> not, I'll beat it some more: My comments are about language, not >>> technical details. My concern is that the language many folk are >using >>> can lead to misunderstanding what is inside or outside the spec. >>> >>>> I also think it's necessary to consider some current realities. In >an >>>> architecture such as the one I use, filters operate serially on the >>>> data. The SPF module runs ahead of DKIM, which in turn runs ahead >of >>>> DMARC. If the SPF module decides to act on a "-all" and reject the >>>> message, DMARC and DKIM simply can't happen. DMARC, by saying >SHOULD >>>> over SPF, is attempting to require that the SPF module change what >it's >>>> doing. That means, at least in my local example, that DMARC is not >a >>>> pure overlay atop SPF and DKIM. >>> >>> Right. It's not. >>> >>> As for DMARC 'replacing' some SPF portions, yeah, it's doing that. >>> >>> If someone thinks the text is not sufficiently clear about what is >>> specified to do or why, we know how to fix that. As for /whether/ >to do >>> it, again, one can choose to live within DMARC or... >> >> Ah, so DMARC is what it's defined as, so by definition any suggestion >that it >> should be changed is incorrect. Got it. Glad we cleared that up. >> > >Scott, > >There are more than 20 people that developed this spec, we reached >consensus on this is the best path and we deployed it and we have not >seen it should be done otherwise. Any suggestion that it should be >changed is not incorrect, it needs more support than the 20 people or >so behind it... > >As Barry said, review the current spec, build support and the spec will >be changed. > >It seems I'm flogging a dead horse here. This isn't an IETF working group with an established consensus that I'm seeking to overturn. Please stop pretending it is. That group wasn't representative of senders, so I question the relevance to the IETF of your private consensus. Scott K From dcrocker@gmail.com Tue Jul 2 19:55:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050DC11E8143 for ; Tue, 2 Jul 2013 19:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dL6WQzLo7ts for ; Tue, 2 Jul 2013 19:55:57 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 702B111E8135 for ; Tue, 2 Jul 2013 19:55:57 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id dn14so6548176obc.30 for ; Tue, 02 Jul 2013 19:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=q1Z162kj7xHG00CphJ43MEZBcWWpxcUsmS0Xi4q63V8=; b=bC/Oj+Fiyb0Nwnrg9ot38kY9qu9MXP5erjCrdWQWxme39WjKz5qB9bEtiMgH5jTR0S DeesXX3N654EZMRE8oQTY1QlhqWveQbvdjX8r0m39fXiVxt5X9dIPI9zAJ6HleZ/9iAC y7D/nwvowOCYo4Vg5f1xZXf5XaanqUKVKysSKA5o1p2p1qBkSxC32aHbnURAYx41FwLN WFNqSyvT+AKKhLfVz+pskQDV0xCZbTAt3HB58P9/Hzuv1pMvRfOr8zsaV2hX6yNlT3Lu 25WAneZ6yAerIog8SUUorapo7cVkVQrXvdiIP6nF+uKPRgBtlrymPMDYJnWZ+qtnfCyx hbSA== X-Received: by 10.182.111.199 with SMTP id ik7mr6252031obb.44.1372820157016; Tue, 02 Jul 2013 19:55:57 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id i9sm3890590oem.7.2013.07.02.19.55.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 19:55:56 -0700 (PDT) Message-ID: <51D392AD.5010808@gmail.com> Date: Tue, 02 Jul 2013 19:55:41 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> In-Reply-To: <51D3464D.2060502@sonnection.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 02:55:59 -0000 On 7/2/2013 2:29 PM, Rolf E. Sonneveld wrote: > On 07/02/2013 07:27 AM, John Levine wrote: >>> What I think would be more productive here is discussion of what's in >>> the >>> proposed charter. >> Replace the second and third paragraphs with: >> >> The working group will adopt draft-kucherawy-dmarc-base as an input >> document and any other drafts the the group deems relevant and useful, >> with the goal of publishing a standards track DMARC specification and >> posssibly other documents. > > +1 What technical work do you want done? Why? Who else do you believe wants it? >> In view of the large base of running DMARC >> code, the group will avoid changes that would cause incompatible >> changes to bits on the wire. > > -1 > > Granted, the installed base is large, but let's not ignore the other 40 > percent of the Internet. Presumably you have some empirical data that supports claims that that other 40% wants technical changes to the specification? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Tue Jul 2 19:58:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335BF11E8143 for ; Tue, 2 Jul 2013 19:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP19PUEs8OTV for ; Tue, 2 Jul 2013 19:58:57 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4711E8135 for ; Tue, 2 Jul 2013 19:58:57 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so6408965obb.5 for ; Tue, 02 Jul 2013 19:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+eg691m6y6ywqXgSS1/Dx6PkYDizooMyCu0V/LOPaIU=; b=toImaM9CLKMbhdX7a7AVs/tRW7ZhAbfejSEB48f+AbLnZYRoi8PaAKHYF+F/Jh+Ymd qXLG8C17g4ury8nKQ6yL0TjlR/KIsAGtJclgEu/nTBjyBThpZD1j83YsMU5LjMGhRV0U SbSOgl50qDFXe+cxSoudHSX0B/Dpkr3eUbaohFtickJToCEvsbjTuA19K/1oXZwFKsuE hTzw+m0E+oTRpTjyEmjjFKRo7jsEM/xZlZ9ssWmgvKKfC5MxwqNghN81CtA7n4765iSg qJxI0TOhkZ0hDqBXzIVjMRlPDOknpTqiXUWSNNkaJkVknWdC5YFeepLQdmh8ICXWH0/s RyHw== X-Received: by 10.182.72.137 with SMTP id d9mr14820009obv.99.1372820337231; Tue, 02 Jul 2013 19:58:57 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id tv3sm8767740obb.8.2013.07.02.19.58.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 19:58:56 -0700 (PDT) Message-ID: <51D39361.2010201@gmail.com> Date: Tue, 02 Jul 2013 19:58:41 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <51D33F23.8050502@gmail.com> <1458562.mnNGVq3FHH@scott-latitude-e6320> In-Reply-To: <1458562.mnNGVq3FHH@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 02:58:58 -0000 On 7/2/2013 2:53 PM, Scott Kitterman wrote: >> >If someone thinks the text is not sufficiently clear about what is >> >specified to do or why, we know how to fix that. As for/whether/ to do >> >it, again, one can choose to live within DMARC or... > Ah, so DMARC is what it's defined as, so by definition any suggestion that it > should be changed is incorrect. 1. Your logic is flawed to the point of silliness and the conclusion you invented is simple and completely wrong. 2. You have yet to indicate what technical work needs to be done on the specification and, for extra points, indicate who else wants that work done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From matt@tnpi.net Tue Jul 2 21:50:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EA921F99CF for ; Tue, 2 Jul 2013 21:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Tw8iqyW9zuat for ; Tue, 2 Jul 2013 21:50:11 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD9021F99BF for ; Tue, 2 Jul 2013 21:50:11 -0700 (PDT) Received: (qmail 87558 invoked by uid 1026); 3 Jul 2013 04:50:10 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Wed, 03 Jul 2013 00:50:10 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.7 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:content-transfer-encoding:message-id:references:to; s=mar2013; bh=NC64YZiGkGx7EaGyuJxi0pqR0UtgdVl0V+Z808JCyFI=; b=QLG31NG+0uL7A2xZrgiBduCbLyHm2QipRN1WxBC/+u6zaDe9/B+kL6R8z69ObJ7Y+WOE/2Ecs1Vz4Q1Jhmf+m81SBRxwyH0vqyFtBn1Cs1bPbA9jwADflSWAGx1ayGyxYCyiM+bmS4r1yBXGipGaLd382irdeDX3RNsBKA6UnswNfn9IZ7LHkcDWgRswuFh0kxXt86bJRlO33FYJM7wHEpGQbvStn+XxKMRC62uocgwuH9DlZpooOwV8+iCuiywmQ1qWPz9iQTZGHn4aDUSoWIWxWyZj2i6Ei6T6nQR4tyH6gdOIZ7RePANE6TGqHbpkOCjohHGcsJ8zKQCVcyVSUw== X-HELO: [10.0.1.32] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: <51D3464D.2060502@sonnection.nl> Date: Tue, 2 Jul 2013 21:50:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:50:28 -0000 On Jul 2, 2013, at 2:29 PM, "Rolf E. Sonneveld" = wrote: >> In view of the large base of running DMARC >> code, the group will avoid changes that would cause incompatible >> changes to bits on the wire. >=20 > -1 >=20 > Granted, the installed base is large, but let's not ignore the other = 40 percent of the Internet. IETF standards are standards for the = _entire_ Internet community, not just ten or twenty of the largest = companies in a specific area. The WG should not be bound by 'bits on the = wire' in their review and possible comments on the standard. Otherwise = the IETF is to a large extent degraded to the 'rubber stamp business' = Scott mentioned. >=20 > Don't get me wrong: the outcome of the discussions may well be that = nothing will change on the wire and that'd be fine. But including this = in the Charter as a precondition for the work to be done is wrong in my = opinion. +1 to Rolf's -1.=20 I'm happy to see DMARC moving towards becoming a standard. Validation of = incoming messages is a great feature. Reporting is more timely and = structured than bounce messages. But for the vast majority of mail = senders, DMARC is close to useless because of the forwarder / mailing = list issue.=20 "DMARC policies are not appropriate for domains with users who = send mail through mailing lists" --John R Levine "SMTP refusal to an unmapped-but-reliable forwarder is likely to = cause list unsubscription." --Roland Turner The mailing list issue is intractable and also a huge implementation = barrier that is barely documented. For legit domain owners (ie, not = abusers) that wish to use DMARC to curtail phishing from their domains, = they will need to choose between losing legit mail (DMARC + mailing = lists) or not losing legit mail (no DMARC).=20 Most of the broader internet community does not have the resources to = "map the exit IP addresses of well-behaved forwarders and ignore DMARC = results for messages that come from those addresses." As such, many = domain owners will deploy DMARC, lose valid mail, and then reject the = technology. While it may be kinda sorta true that DMARC "protects 60% of global = consumer mailboxes," it seems to be marketing puffery. While 60% of = global mailboxes may have some form of DMARC validation, the number of = legit domains that do and potentially *can* deploy DMARC records is = absurdly low.=20 Other minor Issues such as report loops (DMARC reporters reporting each = others DMARC reports to each other ad infinitum) are minor and have = simple (but not yet documented) workarounds but could also be addressed = technically, rather than requiring workaround documentation. Matt From sklist@kitterman.com Tue Jul 2 22:08:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DAE21F9B9D for ; Tue, 2 Jul 2013 22:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYpYxELVDqDF for ; Tue, 2 Jul 2013 22:08:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC321F9B9B for ; Tue, 2 Jul 2013 22:08:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BCC0D20E40C2; Wed, 3 Jul 2013 01:08:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372828125; bh=WebKCx9GTjCrZqowhu6SxB2sGjAShWKr5nGoy08a6o8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DMOue0N3bodv5WVU3d1yNx46c0n9hBwTIuN78Pjd8NrUeMw2r1+tP5D0He5m33oLQ ZSOZq09tU+wEyG4gW4yi4To4BMA9GF/d2pe5tM9mCQOfJgLYd080JCDMtFwugBzqtr WkNYfLROBF4UrqsUipGKFPph1YP+y/cDR3t+eSz0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A22DB20E40A6; Wed, 3 Jul 2013 01:08:45 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 03 Jul 2013 01:08:43 -0400 Message-ID: <2144478.q9Cq7UVjAO@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; ) In-Reply-To: <51D39361.2010201@gmail.com> References: <77426B543150464AA3F30DF1A91365DE533DD678@ESV4-MBX01.linkedin.biz> <1458562.mnNGVq3FHH@scott-latitude-e6320> <51D39361.2010201@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] DMARC policy overrides X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:08:51 -0000 On Tuesday, July 02, 2013 07:58:41 PM Dave Crocker wrote: > On 7/2/2013 2:53 PM, Scott Kitterman wrote: > >> >If someone thinks the text is not sufficiently clear about what is > >> >specified to do or why, we know how to fix that. As for/whether/ to do > >> >it, again, one can choose to live within DMARC or... > > > > Ah, so DMARC is what it's defined as, so by definition any suggestion that > > it should be changed is incorrect. > > 1. Your logic is flawed to the point of silliness and the conclusion you > invented is simple and completely wrong. > > 2. You have yet to indicate what technical work needs to be done on the > specification and, for extra points, indicate who else wants that work done. I have, you're not listening, so I'm done. Scott K From superuser@gmail.com Fri Jul 5 01:08:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0E111E825B for ; Fri, 5 Jul 2013 01:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fozF2Jw+ulj7 for ; Fri, 5 Jul 2013 01:08:11 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A870D11E8255 for ; Fri, 5 Jul 2013 01:08:10 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so1704049wgh.13 for ; Fri, 05 Jul 2013 01:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7qZiwzFjAf/QsWJHB+/SpegxWRX7S7xeGT05l1XW9Zs=; b=E7zkpKwY03VADrsgtFjiUID0KpAg5qCyf5TnJWeKPuN1VdRYarZen4Q5hzpaDIBZlW r+suBk/ea2WzIufRLQAA5kRfex0wugcSbZ3yn0y6yXYR+bIBz5adAuiTzM3RcvKllMnj 7zOmTMzTnzaFvj6qYDezL/0g44e95Zruue0yBLWavYo+mZLJQaVLpdQ3i6eRMigAeQ0K NiEMbJFxpc6dA8lEiBz2ezIAudvcBPYbB/NfmInUESc4gPX4MUDWGqaiV9bObaZ1vpkP Wm6Kq7E4oNkWbXuXHKALbz01RrGBwbKuGrtHyNAzNX8eD9taDSw1G/kWeTS3wb0UnYov d+Sw== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr23040637wib.19.1373011689634; Fri, 05 Jul 2013 01:08:09 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 5 Jul 2013 01:08:09 -0700 (PDT) In-Reply-To: <519B47DC.20008@cisco.com> References: <519B47DC.20008@cisco.com> Date: Fri, 5 Jul 2013 01:08:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Eliot Lear Content-Type: multipart/alternative; boundary=e89a8f3ba25508831c04e0bf3290 Cc: "dmarc@ietf.org" , draft-kucherawy-dmarc-base.all@tools.ietf.org, Barry Leiba Subject: Re: [dmarc-ietf] Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 08:08:12 -0000 --e89a8f3ba25508831c04e0bf3290 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 21, 2013 at 3:09 AM, Eliot Lear wrote: > I've been asked to take a look at the DMARC spec. Let me start by saying > that I know that you guys have running code. I beg your indulgence and ask > you to read through. While this review may come across as a bit negative, > and while I have concerns about several components (potential downgrade > attack etc). > [...] > Hi Eliot, At long last, thanks for taking a look at this so early on. We've finally taken a run at processing this and other feedback and a new version should be out before the embargo prior to IETF 87 kicks in. I wanted to reply to a few points as we do so to make sure we understand what you're saying and can make sure the next version takes care of as much of this as practical. First, much of the requirements summary stuff in what's now Sections 2 and 3 have been crushed down or eliminated. Most of that is left over from when the document was pre-IETF and needed a lot more introduction to non-technical audiences. We agree it doesn't need to be there in this context. > > Please also intersperse the examples. Otherwise the reader has to jump > all over the document. > > Added a note-to-self to revisit this issue. The original approach was to add them at the end in recipe or cookbook fashion. We'll add some in the middle and see if your idea improves things for the reader. > The Security Considerations section needs a serious edit cut. > Can you be more specific? > Section 4: > > The glossary needs to be moved forward!!! > It has, by virtue of the cleanup in Sections 2 and 3. > > Organizational Domain: Question: what would happen if two sites develop > two separate lists of public suffixes that don't match? In particular, > could a parent domain assert authority for messages sent from a child > domain? What are the implications if a TLD is not listed? Does anyone > know the breakdown of the Egyptian domains in Arabic? > The public suffix list is far from an optimal solution to this requirement. There are some proposals on the table for doing this through the DNS rather than the public suffix list, though that to some is only marginally more palatable. The DMARC people don't have any particular marriage to public suffix, but it's the only option presently available. This is discussed in one of the appendices. We could make it more clear that this is a known weak point and say we intend to replace it with whatever comes along as soon as that thing is available. > > Section 5: > > A Mail Receiver MUST consider an arriving message to pass the DMARC > test if and only if one or more of the underlying message > authentication mechanisms pass with proper identifier alignment. > > > Please define what the test actually IS!! > The test is the second half of that sentence, starting "one or more..." What's missing? > Later on: > > A Domain Owner that does not advertise an SPF policy or sign with > DKIM is making an implicit statement that the use cases those > protocols satisfy are not to be considered when determining whether > or not the message under evaluation is valid. For example, not > publishing an SPF policy is an implicit message from Domain Owners to > Mail Receivers that successful path authorization is not to be taken > as sufficient evidence that the Domain Owner authorized the message. > > > Either I'm confused or this example is backwards. How can you do > successful path authorization in the first place without SPF? > Put another way: DMARC passes if either SPF or DKIM pass. If your setup for some reason can lead to SPF false positives (invalid "pass" results), then if you're concerned about DMARC false positives, you would decline to publish SPF. > Section 8.4: > > That last comment in (2) seems to indicate that there should be a way to > collapse the ABNF, but I leave it to Dave who is Mr. ABNF as to whether > that is the right thing to do (I guess the tradeoff would be a mandatory > order). > I think it's just another way of indicating the order doesn't matter. > Section 12.2.1: EMail > > Please justify your normative language in the following cases: > > In the case of a "mailto" URI, the Mail Receiver SHOULD communicate > reports using the method described in [STARTTLS]. > > > As a matter of security, RFC-2119 gives license to you to use MUST here. > Why not do it? > There may be some operators that can't support STARTTLS yet for some reason. Do we need to preclude their participation? > > The aggregate data MUST be present using the media type "application/ > gzip", and the filenames SHOULD be constructed using the following > ABNF: > > > On what basis according to RFC-2119 MUST aggregate data be compressed? > The reports are substantially large in practice, at least among the deployed base. Compression is appropriate, and selecting one as the required base form for doing so is also appropriate. If two operators want to use application/zip, they could do so, but they would not interoperate with the base. > > Separately, why is the filename at all important, requiring a SHOULD? > The timestamps found in the filename are important to the receivers for sorting and collating. > > Section 13: > > o Is able to send and/or receive reports at least daily; > > o Is able to send and/or receive reports using "mailto" URIs; > > > Receive? Eh? How can one receive a report at least daily? Using a URI? > Won't blow up if it gets a 500Mb report over email once a day. Can accept email. (Just because you can send, doesn't mean you can receive.) > > Section 15 Security Considerations: > > 15.1, 15.2, and elsewhere don't follow the best current practices > specified in RFC-3552, and those that have evolved since. State the threat > and state the remediation (if any). I would split 15.4 to two points: > there is the potential for a downgrade attack as SPF is only as strong as > its weakest link in the path, and that a poor deployment of SPF can lead to > garbage getting through. > > I don't really see 15.9 as a security consideration, but more of a > deployment consideration. > Thanks, we'll take another full pass over this section with RFC3552's advice in mind. We hope to have a revision up in a week or so. -MSK --e89a8f3ba25508831c04e0bf3290 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 21, 2013 at 3:09 AM, Eliot Lear <lear@cisco.com<= /a>> wrote:
=20 =20 =20
I've been asked to take a look at the DMARC spec.=A0 Let me start b= y saying that I know that you guys have running code.=A0 I beg your indulgence and ask you to read through.=A0 While this review may come across as a bit negative, and while I have concerns about several components (potential downgrade attack etc).
[...]

Hi Eliot,

At lon= g last, thanks for taking a look at this so early on.=A0 We've finally = taken a run at processing this and other feedback and a new version should = be out before the embargo prior to IETF 87 kicks in.=A0 I wanted to reply t= o a few points as we do so to make sure we understand what you're sayin= g and can make sure the next version takes care of as much of this as pract= ical.

First, much of the requirements summary stuff in what's = now Sections 2 and 3 have been crushed down or eliminated.=A0 Most of that = is left over from when the document was pre-IETF and needed a lot more intr= oduction to non-technical audiences.=A0 We agree it doesn't need to be = there in this context.
=A0

Please also intersperse the examples.=A0 Otherwise the reader has to jump all over the document.


Added a note-to-self to revi= sit this issue.=A0 The original approach was to add them at the end in reci= pe or cookbook fashion.=A0 We'll add some in the middle and see if your= idea improves things for the reader.
=A0
The Security Considerations section needs a serious edit cut.
=

Can you be more specific?
=A0
=
Section 4:

The glossary needs to be moved forward!!!
It has, by virtue of the cleanup in Sections 2 and 3.
=A0

Organizational Domain: Question: what would happen if two sites develop two separate lists of public suffixes that don't match?=A0 = In particular, could a parent domain assert authority for messages sent from a child domain?=A0 What are the implications if a TLD is not listed?=A0 Does anyone know the breakdown of the Egyptian domains in Arabic?

The public suffix lis= t is far from an optimal solution to this requirement.=A0 There are some pr= oposals on the table for doing this through the DNS rather than the public = suffix list, though that to some is only marginally more palatable.=A0 The = DMARC people don't have any particular marriage to public suffix, but i= t's the only option presently available.=A0 This is discussed in one of= the appendices.=A0 We could make it more clear that this is a known weak p= oint and say we intend to replace it with whatever comes along as soon as t= hat thing is available.
=A0

Section 5:

=A0=A0 A Mail Receiver MUST consider an arriv= ing message to pass the DMARC
=A0=A0 test if and only if one or more of the underlying message
=A0=A0 authentication mechanisms pass with proper identifier alignment.

Please define what the test actually IS!!
The test is the second half of that sentence, starting "o= ne or more..."=A0 What's missing?


Later on:

=A0=A0 A Domain Owner that does not advertise= an SPF policy or sign with
=A0=A0 DKIM is making an implicit statement that the use cases those<= br> =A0=A0 protocols satisfy are not to be considered when determining whether
=A0=A0 or not the message under evaluation is valid.=A0 For example, = not
=A0=A0 publishing an SPF policy is an implicit message from Domain Owners to
=A0=A0 Mail Receivers that successful path authorization is not to be taken
=A0=A0 as sufficient evidence that the Domain Owner authorized the message.

Either I'm confused or this example is backwards.=A0 How can you do successful path authorization in the first place without SPF?
=

Put another way: DMARC passes if either SP= F or DKIM pass.=A0 If your setup for some reason can lead to SPF false posi= tives (invalid "pass" results), then if you're concerned abou= t DMARC false positives, you would decline to publish SPF.
=A0


Section 8.4:

That last comment in (2) seems to indicate that there should be a way to collapse the ABNF, but I leave it to Dave who is Mr. ABNF as to whether that is the right thing to do (I guess the tradeoff would be a mandatory order).

I thin= k it's just another way of indicating the order doesn't matter.
=


Section 12.2.1: EMail

Please justify your normative language in the following cases:
=A0=A0 In the case of a "mailto" UR= I, the Mail Receiver SHOULD communicate
=A0=A0 reports using the method described in [STARTTLS].

As a matter of security, RFC-2119 gives license to you to use MUST here.=A0 Why not do it?

There= may be some operators that can't support STARTTLS yet for some reason.= =A0 Do we need to preclude their participation?
=A0

=A0=A0 The aggregate data MUST be present usi= ng the media type "application/
=A0=A0 gzip", and the filenames SHOULD be constructed using the following
=A0=A0 ABNF:

On what basis according to RFC-2119=A0 MUST aggregate data be compressed?

The reports are subst= antially large in practice, at least among the deployed base.=A0 Compressio= n is appropriate, and selecting one as the required base form for doing so = is also appropriate.=A0=A0 If two operators want to use application/zip, th= ey could do so, but they would not interoperate with the base.
=A0

Separately, why is the filename at all important, requiring a SHOULD?

The timestamps found = in the filename are important to the receivers for sorting and collating.=A0

=A0

Section 13:

=A0=A0 o=A0 Is able to send and/or receive re= ports at least daily;

=A0=A0 o=A0 Is able to send and/or receive reports using "mailto= " URIs;

Receive?=A0 Eh?=A0 How can one receive a report at least daily?=A0 Usin= g a URI?

Won't blow up if it = gets a 500Mb report over email once a day.

Can accept email.=A0 (Jus= t because you can send, doesn't mean you can receive.)
=A0

Section 15 Security Considerations:

15.1, 15.2, and elsewhere don't follow the best current practices specified in RFC-3552, and those that have evolved since.=A0 State the threat and state the remediation (if any).=A0 I would split 15.4 to two points: there is the potential for a downgrade attack as SPF is only as strong as its weakest link in the path, and that a poor deployment of SPF can lead to garbage getting through.

I don't really see 15.9 as a security consideration, but more of a deployment consideration.

Tha= nks, we'll take another full pass over this section with RFC3552's = advice in mind.

We hope to have a revision up in a week or so.

-MSK
--e89a8f3ba25508831c04e0bf3290-- From superuser@gmail.com Fri Jul 5 01:34:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A651011E826E for ; Fri, 5 Jul 2013 01:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1dsfR5ppTrD for ; Fri, 5 Jul 2013 01:34:08 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4887711E8264 for ; Fri, 5 Jul 2013 01:34:06 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so6969567wib.4 for ; Fri, 05 Jul 2013 01:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nq73IcUWBdO3Ku8KUz0Vy9z6L9v7auItzmYNfCu92AQ=; b=WqgGr7rDtRhMoqYggwJgAdDWw3KqtLK9+o1aZ6o2zFDNBEt0IhyYT/tLpV5uN3FcS/ 09f6b8zHLilLqSviUkb4YD8rbI6Smz1M6Zzfg7t4nehADLpfuJ6Cz5CA7Q3jxORx+a6d PtR/Lotazc2xb7KHCfy5726JELBimCaKCBuYam0jz67pSP2+7pBBJS3P5SJnD2JGrCwY N46SuK2oed68Hr3ng2onm2SFj3dIr8M1YsObce0mD08+8IG6N5R/RouhP2mGG/u3m8h9 gSaIruXFGbX5U3Zrnk9S0JJsPL+UVJLdgJAFfsFWKiJET2kRLjA22BREXDoB92SKEFmO 7Mow== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr5468518wjc.63.1373013246035; Fri, 05 Jul 2013 01:34:06 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 5 Jul 2013 01:34:05 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> Date: Fri, 5 Jul 2013 01:34:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=089e01493384cd4f4a04e0bf8e38 Cc: "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] Fwd: Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 08:34:09 -0000 --089e01493384cd4f4a04e0bf8e38 Content-Type: text/plain; charset=ISO-8859-1 Hi SM, As I said with Eliot's review, thanks for looking at this so early on. I'm going to chop a chunk of what you said out about the heavy requirements and "marketing" since much of it will be slashed in the next version. As for what's left: On Thu, May 23, 2013 at 2:55 AM, SM wrote: > > The terminology section mentions terms such as "cousin domains", "domain > owner", etc. Although such terms may be popular I don't think that it is a > good idea to use them in a protocol document as they can be ambiguous. > Can you make other suggestions? I think the first one is not ambiguous in general, but we're very clear on defining and using the second. > > In Section 5: > > > "A Mail Receiver MUST consider an arriving message to pass the DMARC > test if and only if one or more of the underlying message > authentication mechanisms pass with proper identifier alignment." > > The above conveys the idea. It does not provide adequate information for > the implementer. > The details are further down in the document. Section 5 is setting the stage for what comes later. It's more overview than substance. > > "A Mail Receiver implementing the DMARC mechanism MUST make a best- > effort to adhere to the Domain Owner's published DMARC policy when a > message fails the DMARC test." > > The above uses a "MUST" to tell people that they ought to make a > best-effort. In my opinion that is incorrect usage of RFC 2119 key words. > I agree, this would likely be caught during more formal reviews as well. I think "MUST make" can just be "makes". > > "Mail Receivers MAY deviate from a Domain Owner's published policy > during message processing and SHOULD make available the fact and > reason of the deviation to the Domain Owner via feedback reporting." > > I read the above as "if you do not do what I say you have to provide me > with a justification". Let me rewrite the text: > > "Mail Receivers deviating from a Domain Owner's published policy > during message processing and MUST make available the fact and > reason of the deviation to the Domain Owner via feedback reporting." > > If that text is not acceptable to mail receivers the RFC 2119 SHOULD will > have the same effect. > SHOULD is appropriate. There can be local policy reasons for not revealing such details via feedback. > > In Section 7: > > "When this is done, the DNS domain name thus recorded MUST be encoded as > an > A-label, as described in Section 2.3 of [IDNA]." > > The above is under "policy enforcement considerations". It should be in a > section discussing the DNS aspects of the specification. > Why? The context is the construction of an RFC5451 header field, not something about DNS. > > Section 8.2 is about "Verifying External Destinations". If I am not > mistaken, IETF specifications are not about imposing a specific method. > Section 8.2 sounds like a tutorial for the implementer instead of a > definition of what the "DMARC policy string" means. > > I disagree; a specification is indeed about describing a specific method. Tutorials for implementers appear throughout various documents we produce, one of which you are working on in another working group right now. :-) > "A report receiver MUST publish such a record in its DNS if it wishes > to receive reports for other domains." > > The RFC 2119 usage is inappropriate here. I would put it after the > high-level view (see Eliot's message) of how DMARC works. > It's fine to drop this to "publishes". I believe "MUST publish" is also technically correct, but Pete has described it as "unnecessary shouting" in the past. > > In Section 8.3: > > "The report SHOULD include the following data: > > o Enough information for the report consumer to re-calculate DMARC > disposition based on the published policy, message dispositon, and > SPF, DKIM, and identifier alignment results. {R12}" > > "enough information" is an ambiguous description of what the report should > include. > That SHOULD looks more like requirements language, and I agree the bullet list is non-specific. The details are in the section containing the XML syntax. We'll adjust. > > In Section 11.2: > > "Heuristics applied in the absence of use by a Domain Owner of either > SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be > the case that the Domain Owner wishes a Message Receiver not to > consider the results of that underlying authentication protocol at > all." > > The reference would have to be normative. > Is that true? I would think making normative something one SHOULD NOT use seems contradictory. > > In Section 11.3: > > 'If email is subject to the DMARC policy of "quarantine", the Mail > Receiver SHOULD quarantine the message. If the email is not subject > to the "quarantine" policy (e.g., due to the "pct" tag), the Mail > Receiver SHOULD apply local spam classification as normal.' > > The usage of RFC 2119 key words in the above is incorrect. > Why? > > In Section 12.2.1: > > 'In the case of a "mailto" URI, the Mail Receiver SHOULD communicate > reports using the method described in [STARTTLS].' > > Has the usual STARTTLS issues been taken into consideration for the RFC > 2119 recommendation? > Such as what? > > "The aggregate data MUST be an XML file subjected to GZIP compression. > > The aggregate data MUST be present using the media type "application/ > gzip", and the filenames SHOULD be constructed using the following > ABNF:" > > In Section 12.2.2 it mentioned that: > > 'Where an "http" or "https" method is requested in a Domain Owner's > URI list, the Mail Receiver MAY encode the data using the > "application/gzip" media type ([GZIP]) or MAY send the Appendix C > data uncompressed or unencoded.' > > The data exchange format depends on the URI scheme being used. In my > opinion that makes the implementation more complex. > I don't agree, but I think the more important point is that the two sections disagree on whether compression is required. > > 'For the GZIP file itself, the extension MUST be "gz"; for the XML > report, the extension MUST be "xml".' > > I would ask why such a RFC 2119 requirement is in the draft. > For interoperability, of course. What's the issue here? > > "Email streams carrying DMARC feedback data MUST conform to the DMARC > mechanism, thereby resulting in an aligned "pass" (see Section 4.3)." > > As far as I am aware the IETF does not do conformance. > It doesn't do conformance levels, as far as I'm aware. But you either conform to the standard or you do not. Are you keying on the word "conform" or is there more going on here? > > 'The RFC5322.Subject field for individual report submissions SHOULD > conform to the following ABNF:' > > The Subject field is specified as structured text in the above. > Is that bad? > > In Section 12.2.2: > > "The header portion of the POST or PUT request SHOULD contain a > Subject field as described in Section 12.2.1." > > This sounds like sending RFC 5322 formatted messages over HTTP. > Is that bad? > In Section 15.8: > > "Many systems are able to scan the SMTP reply text to determine the > nature of the rejection, thus providing a machine-detectable reason > for rejection allows automated sorting of rejection causes so they > can be properly addressed." > > I don't think that it is a good idea to discuss about that as part of a > protocol specification. > Why? > > I suggest giving careful consideration to privacy. The draft discusses > about that in Section 15.10.1. The draft would require a detailed review > to understand what information is being exchanged and how that can affect > users. > What issue should we cover that 15.10.1 does not already? > > In Section 15.12: > > "The DMARC mechanism and its underlying technologies (SPF, DKIM) > depend on the security of the DNS. To reduce the risk of subversion > of the DMARC mechanism due to DNS-based exploits, serious consideration > should be given to the deployment of DNSSEC in parallel to the > deployment > of DMARC." > > I would ask whether anyone who has deployed this mechanism is actually > using DNSSEC. If not the above is not saying anything to ensure secure use > of the protocol. > I don't think it's pragmatic to demand use of DNSSEC because of the obvious chicken-and-egg problem. However, for a system that is so heavily reliant on the DNS being stable and secure, it seems wrong not to mention this. > > "S/MIME, or Secure Multipurpose Internet Mail Extensions, is a > standard for encryption and signing of MIME data in a message. This > was suggested and considered as a third security protocol for > authenticating the source of a message." > > I could not understand the relationship between S/MIME and what this > specification attempts to do. > S/MIME can authenticate part of a message and associate it with a user or role. DKIM and SPF can do the same. The relationship seems obvious to me. The question will be asked "Why didn't you also include support for FOOBAR?" and it seemed appropriate to make it clear that we did, even if the result is that the idea was discarded. > > "It has been suggested in several message authentication efforts that > the Sender header field be checked for an identifier of interest, as > the standards indicate this as the proper way to indicate a re- > mailing of content such as through a mailing list. Most recently, it > was a protocol-level option for DomainKeys, but on evolution to DKIM, > this property was removed." > > That discussion would be better in a DKIM-related document instead of > adding it to this draft. > I don't agree, because "Use the Sender field!" came up during both the private and public portions of the evolution of this work. As with S/MIME, it seems appropriate to document history rather than repeat it. > > 'DMARC has been characterized as a "super-ADSP" of sorts.' > > It is not a good idea to include criticism of other protocols in a draft > that specifies a protocol unless it is relevant to the protocol being > specified. > Just about every BoF that tries to tackle a problem for which prior attempts have failed includes an analysis of why those prior attempts failed. I don't think this is any different, and I think it provides a fair treatment of the issues with ADSP that have been showstoppers for a lot of people. > I suggest dropping the idea of using the "public suffix list" as previous > attempts to use it have not been successful in the IETF. > The revised version makes it clear that we don't like public suffix any better than the rest of the IETF does, and will be happy to adopt a replacement solution as soon as there is one. -MSK --089e01493384cd4f4a04e0bf8e38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi SM,

As I said with Eliot's review, thanks fo= r looking at this so early on.=A0 I'm going to chop a chunk of what you= said out about the heavy requirements and "marketing" since much= of it will be slashed in the next version.=A0 As for what's left:

On Thu, May 23, 2= 013 at 2:55 AM, SM <sm@resistor.net> wrote:

The terminology section mentions terms such as "cousin domains", = "domain owner", etc. =A0Although such terms may be popular I don&= #39;t think that it is a good idea to use them in a protocol document as th= ey can be ambiguous.

Can you make other suggestions?=A0 I think= the first one is not ambiguous in general, but we're very clear on def= ining and using the second.
=A0

In Section 5:


=A0 "A Mail Receiver MUST consider an arriving message to pass the DMA= RC
=A0 =A0test if and only if one or more of the underlying message
=A0 =A0authentication mechanisms pass with proper identifier alignment.&quo= t;

The above conveys the idea. =A0It does not provide adequate information for= the implementer.

The details are furth= er down in the document.=A0 Section 5 is setting the stage for what comes l= ater.=A0 It's more overview than substance.
=A0

=A0 "A Mail Receiver implementing the DMARC mechanism MUST make a best= -
=A0 =A0effort to adhere to the Domain Owner's published DMARC policy wh= en a
=A0 =A0message fails the DMARC test."

The above uses a "MUST" to tell people that they ought to make a = best-effort. =A0In my opinion that is incorrect usage of RFC 2119 key words= .

I agree, this would likely be caught = during more formal reviews as well.=A0 I think "MUST make" can ju= st be "makes".
=A0

=A0 "Mail Receivers MAY deviate from a Domain Owner's published po= licy
=A0 =A0during message processing and SHOULD make available the fact and
=A0 =A0reason of the deviation to the Domain Owner via feedback reporting.&= quot;

I read the above as "if you do not do what I say you have to provide m= e with a justification". =A0Let me rewrite the text:

=A0 "Mail Receivers deviating from a Domain Owner's published poli= cy
=A0 =A0during message processing and MUST make available the fact and
=A0 =A0reason of the deviation to the Domain Owner via feedback reporting.&= quot;

If that text is not acceptable to mail receivers the RFC 2119 SHOULD will h= ave the same effect.

SHOULD is appropri= ate.=A0 There can be local policy reasons for not revealing such details vi= a feedback.
=A0

In Section 7:

=A0 "When this is done, the DNS domain name thus recorded MUST be enco= ded as an
=A0 =A0A-label, as described in Section 2.3 of [IDNA]."

The above is under "policy enforcement considerations". =A0It sho= uld be in a section discussing the DNS aspects of the specification.

Why?=A0 The context is the construction of an= RFC5451 header field, not something about DNS.
=A0

Section 8.2 is about "Verifying External Destinations". =A0If I a= m not mistaken, IETF specifications are not about imposing a specific metho= d. =A0Section 8.2 sounds like a tutorial for the implementer instead of a d= efinition of what the "DMARC policy string" means.


I disagree; a specification is indeed = about describing a specific method.=A0 Tutorials for implementers appear th= roughout various documents we produce, one of which you are working on in a= nother working group right now.=A0 :-)

=A0
=A0 "A report receiver MUST publish such a record in its DNS if it wis= hes
=A0 =A0to receive reports for other domains."

The RFC 2119 usage is inappropriate here. =A0I would put it after the high-= level view (see Eliot's message) of how DMARC works.

It's fine to drop this to "publishes".=A0 I= believe "MUST publish" is also technically correct, but Pete has= described it as "unnecessary shouting" in the past.
=A0

In Section 8.3:

=A0 "The report SHOULD include the following data:

=A0 =A0o =A0Enough information for the report consumer to re-calculate DMAR= C
=A0 =A0 =A0 disposition based on the published policy, message dispositon, = and
=A0 =A0 =A0 SPF, DKIM, and identifier alignment results. {R12}"

"enough information" is an ambiguous description of what the repo= rt should include.

That SHOULD looks mo= re like requirements language, and I agree the bullet list is non-specific.= =A0 The details are in the section containing the XML syntax.=A0 We'll = adjust.
=A0

In Section 11.2:

=A0 "Heuristics applied in the absence of use by a Domain Owner of eit= her
=A0 =A0SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may b= e
=A0 =A0the case that the Domain Owner wishes a Message Receiver not to
=A0 =A0consider the results of that underlying authentication protocol at =A0 =A0all."

The reference would have to be normative.

Is that true?=A0 I would think making normative something one SHOULD NOT= use seems contradictory.
=A0

In Section 11.3:

=A0 'If email is subject to the DMARC policy of "quarantine",= the Mail
=A0 =A0Receiver SHOULD quarantine the message. =A0If the email is not subje= ct
=A0 =A0to the "quarantine" policy (e.g., due to the "pct&quo= t; tag), the Mail
=A0 =A0Receiver SHOULD apply local spam classification as normal.'

The usage of RFC 2119 key words in the above is incorrect.
=

Why?
=A0

In Section 12.2.1:

=A0'In the case of a "mailto" URI, the Mail Receiver SHOULD c= ommunicate
=A0 =A0reports using the method described in [STARTTLS].'

Has the usual STARTTLS issues been taken into consideration for the RFC 211= 9 recommendation?

Such as what?
=A0<= br>

=A0 "The aggregate data MUST be an XML file subjected to GZIP compress= ion.

=A0 =A0The aggregate data MUST be present using the media type "applic= ation/
=A0 =A0gzip", and the filenames SHOULD be constructed using the follow= ing
=A0 =A0ABNF:"

In Section 12.2.2 it mentioned that:

=A0 'Where an "http" or "https" method is requested= in a Domain Owner's
=A0 =A0URI list, the Mail Receiver MAY encode the data using the
=A0 =A0"application/gzip" media type ([GZIP]) or MAY send the App= endix C
=A0 =A0data uncompressed or unencoded.'

The data exchange format depends on the URI scheme being used. =A0In my opi= nion that makes the implementation more complex.

<= /div>
I don't agree, but I think the more important point is that t= he two sections disagree on whether compression is required.
=A0

=A0 'For the GZIP file itself, the extension MUST be "gz"; fo= r the XML
=A0 =A0report, the extension MUST be "xml".'

I would ask why such a RFC 2119 requirement is in the draft.

For interoperability, of course.=A0 What's the is= sue here?
=A0

=A0 "Email streams carrying DMARC feedback data MUST conform to the DM= ARC
=A0 =A0mechanism, thereby resulting in an aligned "pass" (see Sec= tion 4.3)."

As far as I am aware the IETF does not do conformance.

It doesn't do conformance levels, as far as I'm awa= re.=A0 But you either conform to the standard or you do not.=A0 Are you key= ing on the word "conform" or is there more going on here?
=A0

=A0 'The RFC5322.Subject field for individual report submissions SHOULD=
=A0 =A0conform to the following ABNF:'

The Subject field is specified as structured text in the above.

Is that bad?
=A0

In Section 12.2.2:

=A0 "The header portion of the POST or PUT request SHOULD contain a =A0 =A0Subject field as described in Section 12.2.1."

This sounds like sending RFC 5322 formatted messages over HTTP.

Is that bad?


In Section 15.8:

=A0 "Many systems are able to scan the SMTP reply text to determine th= e
=A0 =A0nature of the rejection, thus providing a machine-detectable reason<= br> =A0 =A0for rejection allows automated sorting of rejection causes so they =A0 =A0can be properly addressed."

I don't think that it is a good idea to discuss about that as part of a= protocol specification.

Why?
=A0

I suggest giving careful consideration to privacy. =A0The draft discusses a= bout that in Section 15.10.1. =A0The draft would require a detailed review = to understand what information is being exchanged and how that can affect u= sers.

What issue should we cover that 15.10.1 do= es not already?
=A0

In Section 15.12:

=A0 "The DMARC mechanism and its underlying technologies (SPF, DKIM) =A0 =A0depend on the security of the DNS. =A0To reduce the risk of subversi= on
=A0 =A0of the DMARC mechanism due to DNS-based exploits, serious considerat= ion
=A0 =A0should be given to the deployment of DNSSEC in parallel to the deplo= yment
=A0 =A0of DMARC."

I would ask whether anyone who has deployed this mechanism is actually usin= g DNSSEC. =A0If not the above is not saying anything to ensure secure use o= f the protocol.

I don't think it= 9;s pragmatic to demand use of DNSSEC because of the obvious chicken-and-eg= g problem.=A0 However, for a system that is so heavily reliant on the DNS b= eing stable and secure, it seems wrong not to mention this.
=A0

=A0 "S/MIME, or Secure Multipurpose Internet Mail Extensions, is a
=A0 =A0standard for encryption and signing of MIME data in a message. =A0Th= is
=A0 =A0was suggested and considered as a third security protocol for
=A0 =A0authenticating the source of a message."

I could not understand the relationship between S/MIME and what this specif= ication attempts to do.

S/MIME can auth= enticate part of a message and associate it with a user or role.=A0 DKIM an= d SPF can do the same.=A0 The relationship seems obvious to me.=A0 The ques= tion will be asked "Why didn't you also include support for FOOBAR= ?" and it seemed appropriate to make it clear that we did, even if the= result is that the idea was discarded.
=A0

=A0 "It has been suggested in several message authentication efforts t= hat
=A0 =A0the Sender header field be checked for an identifier of interest, as=
=A0 =A0the standards indicate this as the proper way to indicate a re-
=A0 =A0mailing of content such as through a mailing list. =A0Most recently,= it
=A0 =A0was a protocol-level option for DomainKeys, but on evolution to DKIM= ,
=A0 =A0this property was removed."

That discussion would be better in a DKIM-related document instead of addin= g it to this draft.

I don't agree, = because "Use the Sender field!" came up during both the private a= nd public portions of the evolution of this work.=A0 As with S/MIME, it see= ms appropriate to document history rather than repeat it.
=A0

=A0 'DMARC has been characterized as a "super-ADSP" of sorts.= '

It is not a good idea to include criticism of other protocols in a draft th= at specifies a protocol unless it is relevant to the protocol being specifi= ed.

Just about every BoF that tries to = tackle a problem for which prior attempts have failed includes an analysis = of why those prior attempts failed.=A0 I don't think this is any differ= ent, and I think it provides a fair treatment of the issues with ADSP that = have been showstoppers for a lot of people.


I suggest dropping the idea of using the "public suffix list" as = previous attempts to use it have not been successful in the IETF.

The revised version makes it clear that we don&#= 39;t like public suffix any better than the rest of the IETF does, and will= be happy to adopt a replacement solution as soon as there is one.

-MSK
--089e01493384cd4f4a04e0bf8e38-- From lear@cisco.com Fri Jul 5 02:09:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE721F8B35 for ; Fri, 5 Jul 2013 02:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.44 X-Spam-Level: X-Spam-Status: No, score=-110.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LatV4Xut3U6b for ; Fri, 5 Jul 2013 02:09:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5412521F8B07 for ; Fri, 5 Jul 2013 02:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28401; q=dns/txt; s=iport; t=1373015361; x=1374224961; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NDMBbpG4wAZHvuSJMsi465ooAgChy2cxf3EmZfJ+yUY=; b=eOYNmTYkGxynQ8cTvNeV14YbbUsrmvhUNzQLEMhs56CGCK7nDhE1bxt8 tXDsdStOPH4xK9+q1twAYJnfa3Xad7JJZiqau+o83q4qEMG8Ea4Ye4OiT Vd5N6fyt0rcgcrQomjM81szmOIl74l6wm1FKJ08xP3LNujLPyhcRewIqF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAK+L1lGQ/khM/2dsb2JhbABagwmEA4Vdt0t/FnSCIwEBAQMBI08GARALGAkWAQcDAgIJAwIBAgErCREGDQEHAQEXh24Gp2KRD44pEIEyB4JRgRwDk3eDUpFFgxM6gSwFBBc X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208,217";a="156210898" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2013 09:09:14 +0000 Received: from mctiny.local ([10.61.207.23]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6599BkB007503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 09:09:12 GMT Message-ID: <51D68D37.9040904@cisco.com> Date: Fri, 05 Jul 2013 11:09:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <519B47DC.20008@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------060207020600000603000507" X-Mailman-Approved-At: Fri, 05 Jul 2013 08:38:32 -0700 Cc: "dmarc@ietf.org" , draft-kucherawy-dmarc-base.all@tools.ietf.org, Barry Leiba Subject: Re: [dmarc-ietf] Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 09:09:27 -0000 This is a multi-part message in MIME format. --------------060207020600000603000507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Murray, Thanks for your response. Please see below. On 7/5/13 10:08 AM, Murray S. Kucherawy wrote: > First, much of the requirements summary stuff in what's now Sections 2 > and 3 have been crushed down or eliminated. Most of that is left over > from when the document was pre-IETF and needed a lot more introduction > to non-technical audiences. We agree it doesn't need to be there in > this context. Good! > > > > Please also intersperse the examples. Otherwise the reader has to > jump all over the document. > > > Added a note-to-self to revisit this issue. The original approach was > to add them at the end in recipe or cookbook fashion. We'll add some > in the middle and see if your idea improves things for the reader. Thanks. You're covering a lot of ground. I think for simple RFCs it's okay to cram in an example or two. This is, at least for me, just beyond that. > > > The Security Considerations section needs a serious edit cut. > > > Can you be more specific? You've dealt with it below. > > > Section 4: > > The glossary needs to be moved forward!!! > > > It has, by virtue of the cleanup in Sections 2 and 3. Good! > > > > Organizational Domain: Question: what would happen if two sites > develop two separate lists of public suffixes that don't match? > In particular, could a parent domain assert authority for messages > sent from a child domain? What are the implications if a TLD is > not listed? Does anyone know the breakdown of the Egyptian > domains in Arabic? > > > The public suffix list is far from an optimal solution to this > requirement. There are some proposals on the table for doing this > through the DNS rather than the public suffix list, though that to > some is only marginally more palatable. The DMARC people don't have > any particular marriage to public suffix, but it's the only option > presently available. This is discussed in one of the appendices. We > could make it more clear that this is a known weak point and say we > intend to replace it with whatever comes along as soon as that thing > is available. I think we may need to iterate on this, but not in the middle of this document. My current thinking is that this is actually a contractual problem, at least in part. No parent should assert for a child for which there is no administrative control. On the other hand, there is no way within DNS for this relationship to be asserted on a technical basis. It's enough of an annoyance, however, that it really needs repair. > > > > Section 5: > >> A Mail Receiver MUST consider an arriving message to pass the >> DMARC >> test if and only if one or more of the underlying message >> authentication mechanisms pass with proper identifier alignment. > > Please define what the test actually IS!! > > > The test is the second half of that sentence, starting "one or > more..." What's missing? I suggest that you be a bit more clear about what proper identifier alignment is, and perhaps what pass means. I seem to recall a header for this ;-) Referencing the terms there would probably be sufficient. > > > Later on: > >> A Domain Owner that does not advertise an SPF policy or sign with >> DKIM is making an implicit statement that the use cases those >> protocols satisfy are not to be considered when determining >> whether >> or not the message under evaluation is valid. For example, not >> publishing an SPF policy is an implicit message from Domain >> Owners to >> Mail Receivers that successful path authorization is not to be >> taken >> as sufficient evidence that the Domain Owner authorized the >> message. > > Either I'm confused or this example is backwards. How can you do > successful path authorization in the first place without SPF? > > > Put another way: DMARC passes if either SPF or DKIM pass. If your > setup for some reason can lead to SPF false positives (invalid "pass" > results), then if you're concerned about DMARC false positives, you > would decline to publish SPF. I think there is a simpler way to say all of this. We can easily enumerate the cases and stick them into a table. Fill in the blanks. Condition DMARC Action DKIM and SPF pass pass DKIM and SPF fail fail DKIM passes and SPF fails DKIM fails and SPF passes SPF passes DKIM not present pass DKIM passes, SPF not present pass neither DKIM nor SPF present > > > > Section 8.4: > > That last comment in (2) seems to indicate that there should be a > way to collapse the ABNF, but I leave it to Dave who is Mr. ABNF > as to whether that is the right thing to do (I guess the tradeoff > would be a mandatory order). > > > I think it's just another way of indicating the order doesn't matter. Ok. > > > Section 12.2.1: EMail > > Please justify your normative language in the following cases: >> In the case of a "mailto" URI, the Mail Receiver SHOULD >> communicate >> reports using the method described in [STARTTLS]. > > As a matter of security, RFC-2119 gives license to you to use MUST > here. Why not do it? > > > There may be some operators that can't support STARTTLS yet for some > reason. Do we need to preclude their participation? No, but you may want to indicate why it's a SHOULD and not a MUST, and encourage use of STARTTLS. > > > >> The aggregate data MUST be present using the media type >> "application/ >> gzip", and the filenames SHOULD be constructed using the following >> ABNF: > > On what basis according to RFC-2119 MUST aggregate data be > compressed? > > > The reports are substantially large in practice, at least among the > deployed base. Compression is appropriate, and selecting one as the > required base form for doing so is also appropriate. If two > operators want to use application/zip, they could do so, but they > would not interoperate with the base. I think you just made a good argument for SHOULD. Again, please review the criteria for a MUST. They're pretty stringent. > > > > Separately, why is the filename at all important, requiring a SHOULD? > > > The timestamps found in the filename are important to the receivers > for sorting and collating. Ok, but isn't that just a receiver implementation problem? I think it's fine to give advice like this, but I don't see it requiring normative language. > > > > > > Section 13: > >> o Is able to send and/or receive reports at least daily; >> >> o Is able to send and/or receive reports using "mailto" URIs; > > Receive? Eh? How can one receive a report at least daily? Using > a URI? > > > Won't blow up if it gets a 500Mb report over email once a day. This in itself requires a security consideration and remediation. Suppose I start sending vast numbers of bogus reports to you. What's the remediation? > > Can accept email. (Just because you can send, doesn't mean you can > receive.) > > > > Section 15 Security Considerations: > > 15.1, 15.2, and elsewhere don't follow the best current practices > specified in RFC-3552, and those that have evolved since. State > the threat and state the remediation (if any). I would split 15.4 > to two points: there is the potential for a downgrade attack as > SPF is only as strong as its weakest link in the path, and that a > poor deployment of SPF can lead to garbage getting through. > > I don't really see 15.9 as a security consideration, but more of a > deployment consideration. > > > Thanks, we'll take another full pass over this section with RFC3552's > advice in mind. > > We hope to have a revision up in a week or so. Thanks! Eliot --------------060207020600000603000507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Murray,

Thanks for your response.  Please see below.

On 7/5/13 10:08 AM, Murray S. Kucherawy wrote:
First, much of the requirements summary stuff in what's now Sections 2 and 3 have been crushed down or eliminated.  Most of that is left over from when the document was pre-IETF and needed a lot more introduction to non-technical audiences.  We agree it doesn't need to be there in this context.

Good!
 

Please also intersperse the examples.  Otherwise the reader has to jump all over the document.


Added a note-to-self to revisit this issue.  The original approach was to add them at the end in recipe or cookbook fashion.  We'll add some in the middle and see if your idea improves things for the reader.

Thanks.  You're covering a lot of ground.  I think for simple RFCs it's okay to cram in an example or two.  This is, at least for me, just beyond that.

 
The Security Considerations section needs a serious edit cut.

Can you be more specific?

You've dealt with it below.

 
Section 4:

The glossary needs to be moved forward!!!

It has, by virtue of the cleanup in Sections 2 and 3.

Good!

 

Organizational Domain: Question: what would happen if two sites develop two separate lists of public suffixes that don't match?  In particular, could a parent domain assert authority for messages sent from a child domain?  What are the implications if a TLD is not listed?  Does anyone know the breakdown of the Egyptian domains in Arabic?

The public suffix list is far from an optimal solution to this requirement.  There are some proposals on the table for doing this through the DNS rather than the public suffix list, though that to some is only marginally more palatable.  The DMARC people don't have any particular marriage to public suffix, but it's the only option presently available.  This is discussed in one of the appendices.  We could make it more clear that this is a known weak point and say we intend to replace it with whatever comes along as soon as that thing is available.

I think we may need to iterate on this, but not in the middle of this document.  My current thinking is that this is actually a contractual problem, at least in part.  No parent should assert for a child for which there is no administrative control.  On the other hand, there is no way within DNS for this relationship to be asserted on a technical basis.  It's enough of an annoyance, however, that it really needs repair.

 

Section 5:

   A Mail Receiver MUST consider an arriving message to pass the DMARC
   test if and only if one or more of the underlying message
   authentication mechanisms pass with proper identifier alignment.

Please define what the test actually IS!!

The test is the second half of that sentence, starting "one or more..."  What's missing?

I suggest that you be a bit more clear about what proper identifier alignment is, and perhaps what pass means.  I seem to recall a header for this ;-)  Referencing the terms there would probably be sufficient.



Later on:

   A Domain Owner that does not advertise an SPF policy or sign with
   DKIM is making an implicit statement that the use cases those
   protocols satisfy are not to be considered when determining whether
   or not the message under evaluation is valid.  For example, not
   publishing an SPF policy is an implicit message from Domain Owners to
   Mail Receivers that successful path authorization is not to be taken
   as sufficient evidence that the Domain Owner authorized the message.

Either I'm confused or this example is backwards.  How can you do successful path authorization in the first place without SPF?

Put another way: DMARC passes if either SPF or DKIM pass.  If your setup for some reason can lead to SPF false positives (invalid "pass" results), then if you're concerned about DMARC false positives, you would decline to publish SPF.

I think there is a simpler way to say all of this.  We can easily enumerate the cases and stick them into a table.  Fill in the blanks.

Condition
 DMARC Action
DKIM and SPF pass
 pass
DKIM and SPF fail
 fail
DKIM passes and SPF fails
DKIM fails and SPF passes
SPF passes DKIM not present
 pass
DKIM passes, SPF not present
 pass
neither DKIM nor SPF present


 


Section 8.4:

That last comment in (2) seems to indicate that there should be a way to collapse the ABNF, but I leave it to Dave who is Mr. ABNF as to whether that is the right thing to do (I guess the tradeoff would be a mandatory order).

I think it's just another way of indicating the order doesn't matter.

Ok.


Section 12.2.1: EMail

Please justify your normative language in the following cases:
   In the case of a "mailto" URI, the Mail Receiver SHOULD communicate
   reports using the method described in [STARTTLS].

As a matter of security, RFC-2119 gives license to you to use MUST here.  Why not do it?

There may be some operators that can't support STARTTLS yet for some reason.  Do we need to preclude their participation?

No, but you may want to indicate why it's a SHOULD and not a MUST, and encourage use of STARTTLS.
 

   The aggregate data MUST be present using the media type "application/
   gzip", and the filenames SHOULD be constructed using the following
   ABNF:

On what basis according to RFC-2119  MUST aggregate data be compressed?

The reports are substantially large in practice, at least among the deployed base.  Compression is appropriate, and selecting one as the required base form for doing so is also appropriate.   If two operators want to use application/zip, they could do so, but they would not interoperate with the base.

I think you just made a good argument for SHOULD.  Again, please review the criteria for a MUST.  They're pretty stringent.

 

Separately, why is the filename at all important, requiring a SHOULD?

The timestamps found in the filename are important to the receivers for sorting and collating.

Ok, but isn't that just a receiver implementation problem?  I think it's fine to give advice like this, but I don't see it requiring normative language.
 

 

Section 13:

   o  Is able to send and/or receive reports at least daily;

   o  Is able to send and/or receive reports using "mailto" URIs;

Receive?  Eh?  How can one receive a report at least daily?  Using a URI?

Won't blow up if it gets a 500Mb report over email once a day.

This in itself requires a security consideration and remediation.  Suppose I start sending vast numbers of bogus reports to you.  What's the remediation?


Can accept email.  (Just because you can send, doesn't mean you can receive.)
 

Section 15 Security Considerations:

15.1, 15.2, and elsewhere don't follow the best current practices specified in RFC-3552, and those that have evolved since.  State the threat and state the remediation (if any).  I would split 15.4 to two points: there is the potential for a downgrade attack as SPF is only as strong as its weakest link in the path, and that a poor deployment of SPF can lead to garbage getting through.

I don't really see 15.9 as a security consideration, but more of a deployment consideration.

Thanks, we'll take another full pass over this section with RFC3552's advice in mind.

We hope to have a revision up in a week or so.

Thanks!

Eliot
--------------060207020600000603000507-- From johnl@iecc.com Fri Jul 5 11:52:48 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4221F9FD5 for ; Fri, 5 Jul 2013 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.78 X-Spam-Level: X-Spam-Status: No, score=-110.78 tagged_above=-999 required=5 tests=[AWL=0.419, 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 8J5QotvyI5jc for ; Fri, 5 Jul 2013 11:52:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3B12721F9FD1 for ; Fri, 5 Jul 2013 11:52:43 -0700 (PDT) Received: (qmail 69449 invoked from network); 5 Jul 2013 18:52:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Jul 2013 18:52:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d715fa.xn--btvx9d.k1307; i=johnl@user.iecc.com; bh=qWGEYjTkpPMGboKo0iByXlc8gWlzxkzs4GNRJXYx3tA=; b=CO021VP7We4v1IBHDRDxgV2sQYFGRVwFyUp2VOans4qN059xWM9B/9iaKbOYAHn4N2f9H+sQXznBQ1g4gzAfLW8MK60unyExE74z716bFSo6yX2MaTmOvkOHvSSD6KbdgWcYN18ysRgYkd1v3uOYv0h+W5V5dg8UFaHtyMZCoczLGRukfffL5CYG6Q40nTwcUQD2oO2HWWKZfyC2FRdLEsldD8nHrSfSu3ywtsHH3sNDcvnGLEJZeoUtnaNWLrhQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d715fa.xn--btvx9d.k1307; olt=johnl@user.iecc.com; bh=qWGEYjTkpPMGboKo0iByXlc8gWlzxkzs4GNRJXYx3tA=; b=XcvH1BIPmFUgP41HjLO2CHi+aYI2ErlKBwgGYyp6RoU0dTYL5iaHvvHCzpCW3xixSV/ADf+gfLELL3IMclaL32zTaAk3UEozaDOEIvjBaxmI8xBxI+PsdPfMRLtzCxKeOASYABVtvj79xpecW9Wvzy12Uic3yTZgBBmhTLnLIjdgJ7QsYfjrPDdTlLq2MUe0ASkDuvoel9BNlwT9NrUfJP5A7Jq79O+H4rHnI/hcnLMkiEpSJlTiZvPKE9OsCkBw Date: 5 Jul 2013 18:52:20 -0000 Message-ID: <20130705185220.28629.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: superuser@gmail.com, lear@cisco.com Subject: Re: [dmarc-ietf] Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 18:52:48 -0000 >> I've been asked to take a look at the DMARC spec. Your original note with the comments never made it to the DMARC list (I checked the archives.) Could someone send it along so we don't have to reverse engineer it from the meta-comments? Tnx. From superuser@gmail.com Fri Jul 5 12:10:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42A521F9EB2 for ; Fri, 5 Jul 2013 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m46XCVEmKykW for ; Fri, 5 Jul 2013 12:10:32 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1621F9EAF for ; Fri, 5 Jul 2013 12:10:31 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so8512536wid.5 for ; Fri, 05 Jul 2013 12:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cwp0oi1gmZzUlKZr0UPw41fcKPzCVY4DfLWwLquP468=; b=NNlV7A8LYK/+PgDypkFrx9051f/4OxS+tLlrJyjSlkyHWqO9MW01J5QGtor04vCGrR revN9EVF+qmylHVrsbWZqXYYwVT37HaSRVVrmZOFwyqoxCqcX5vle2eyGPGzJ8jddflR Y9rdctbGk16/mURtyDjJztYHlWNbZX7eDVhb2YCENKLKNRm8rVBJTlsDKX8Fv1nWvCqp eCOIekCUrWcoK0vw3xLK5pktlOOWFLqMw6S1yxJTvZUNKLrj5iU/5p+gKlt06Z9px1JS RN1C8uYINWiwv1GUPP3evS0D3UWoPWEbrpImPGfN+eVzY3AU2s40FI3aL/XaVXtdET8a G2Kw== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr6872860wjc.63.1373051431246; Fri, 05 Jul 2013 12:10:31 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 5 Jul 2013 12:10:31 -0700 (PDT) In-Reply-To: <20130705185220.28629.qmail@joyce.lan> References: <20130705185220.28629.qmail@joyce.lan> Date: Fri, 5 Jul 2013 12:10:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01493384d15ef304e0c87257 Cc: "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:10:32 -0000 --089e01493384d15ef304e0c87257 Content-Type: text/plain; charset=ISO-8859-1 Wasn't it this? http://www.ietf.org/mail-archive/web/dmarc/current/msg00292.html I don't have anything from him prior to that. On Fri, Jul 5, 2013 at 11:52 AM, John Levine wrote: > >> I've been asked to take a look at the DMARC spec. > > Your original note with the comments never made it to the DMARC list > (I checked the archives.) Could someone send it along so we don't > have to reverse engineer it from the meta-comments? > > Tnx. > --089e01493384d15ef304e0c87257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't have anythin= g from him prior to that.


On Fri,= Jul 5, 2013 at 11:52 AM, John Levine <johnl@taugh.com> wrote:=
>> =A0I've been asked to take a look at the DMA= RC spec.

Your original note with the comments never made it to the DMARC list<= br> (I checked the archives.) =A0Could someone send it along so we don't have to reverse engineer it from the meta-comments?

Tnx.

--089e01493384d15ef304e0c87257-- From sm@resistor.net Fri Jul 5 12:25:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507CB21F9E6A for ; Fri, 5 Jul 2013 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 I4xpMuxArgc3 for ; Fri, 5 Jul 2013 12:25:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4919921F9E60 for ; Fri, 5 Jul 2013 12:25:12 -0700 (PDT) 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 r65JOw1d026366; Fri, 5 Jul 2013 12:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373052304; bh=QtSFSyyplE7MsERjWxGgTFoTBb229RfZZdoOZA9xDhw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AhyQW16x/QXxY8Hm8ze4cRDFviAyWwN1Qkqxl37+oA6IjOPmE6OkxXzyOsD5BABI7 6Pb0g/pTbirsosQrfl6uNeJmTKkfoY65g8KxqJ+/r40XTn6bECbr8BMqON/zCvG/Li dahW49PyKstg8WWhxcxRtHQ/EqPYrbz/KFX9RZwM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373052304; i=@resistor.net; bh=QtSFSyyplE7MsERjWxGgTFoTBb229RfZZdoOZA9xDhw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UgTMjoJeD7KksgGw2+nbbEUusRC7cB/RqiibJsoLh0XB8J6381oEy/xmNjNpAhQZS Qf7igIrSlHL0O0D0g7Lt94TcWSy/Di50c/3L+XkW6puqf8VFScR39Tf1kWHKcunsYn x0Pp/9GORV38WESZSnk0wLCU4iQrnLd0zI4Q0n6E= Message-Id: <6.2.5.6.2.20130705091238.0be05400@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Jul 2013 11:05:58 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org, Eliot Lear Subject: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:25:17 -0000 Hi Murray, At 01:34 05-07-2013, Murray S. Kucherawy wrote: >As I said with Eliot's review, thanks for looking at this so early >on. I'm going to chop a chunk of what you said out about the heavy >requirements and "marketing" since much of it will be slashed in the >next version. As for what's left: Ok. I would have to read draft-kucherawy-dmarc-base-00 to remember the context of my previous comments. I'll respond quickly instead. >On Thu, May 23, 2013 at 2:55 AM, SM wrote: >Can you make other suggestions? I think the first one is not >ambiguous in general, but we're very clear on defining and using the second. I'll have to go and read before suggesting anything. Let's put this one on hold and get back to it later. > The details are further down in the document. Section 5 is > setting the stage for what comes later. It's more overview than substance. I suggest not putting requirements in a section which provides an overview. Barry and Pete commented about yelling in a WG. I suggest taking those comments into consideration. As a meta-comment about setting the stage I suggest writing the proposal as a mechanism. You could then drop text, reorganize it, etc. to come up with a leaner version which specifies the mechanism and avoids the usual headaches. >I agree, this would likely be caught during more formal reviews as >well. I think "MUST make" can just be "makes". Yes (see above). > > > "Mail Receivers MAY deviate from a Domain Owner's published policy > during message processing and SHOULD make available the fact and > reason of the deviation to the Domain Owner via feedback reporting." > >I read the above as "if you do not do what I say you have to provide >me with a justification". Let me rewrite the text: > > "Mail Receivers deviating from a Domain Owner's published policy > during message processing and MUST make available the fact and > reason of the deviation to the Domain Owner via feedback reporting." > >If that text is not acceptable to mail receivers the RFC 2119 SHOULD >will have the same effect. > > >SHOULD is appropriate. There can be local policy reasons for not >revealing such details via feedback. What I meant is that the proposal is telling mail receivers what to do. The matter is entirely a local policy issue. draft-kucherawy-dmarc-base-00 is intended as a Standards Track document. The draft is doing policy stuff and trying to set conformance. There has been previous similar efforts. I would describe them as controversial and subject to interpretation. I would scope the work to keep the implementation and policy parts separate so that you have a tightly-written specification. > > >In Section 7: > > "When this is done, the DNS domain name thus recorded MUST be encoded as an > A-label, as described in Section 2.3 of [IDNA]." > >The above is under "policy enforcement considerations". It should >be in a section discussing the DNS aspects of the specification. > > >Why? The context is the construction of an RFC5451 header field, >not something about DNS. I guess that we are reading "policy enforcement considerations" differently. The context is as what you wrote above. What I was suggesting is to separate policy from how the DMARC code is supposed to work. You could take the RFC 5451 approach to simplify the draft. >Section 8.2 is about "Verifying External Destinations". If I am not >mistaken, IETF specifications are not about imposing a specific >method. Section 8.2 sounds like a tutorial for the implementer >instead of a definition of what the "DMARC policy string" means. > > >I disagree; a specification is indeed about describing a specific >method. Tutorials for implementers appear throughout various >documents we produce, one of which you are working on in another >working group right now. :-) I disclaim any knowledge of any other working group. :-) I have been reading some specifications (not mail-related) and some reviews recently. I don't think that the Internet Engineering Tooth Fairy will agree with the following; sometimes a proposal specifies a method and gets into details which turns the proposal into a guide about a specific implementation. A Standards Track document is about interoperability and not about specifying how the implementor should do things. > > "A report receiver MUST publish such a record in its DNS if it wishes > to receive reports for other domains." > >The RFC 2119 usage is inappropriate here. I would put it after the >high-level view (see Eliot's message) of how DMARC works. > > >It's fine to drop this to "publishes". I believe "MUST publish" is >also technically correct, but Pete has described it as "unnecessary >shouting" in the past. Yes. > > >In Section 8.3: > > "The report SHOULD include the following data: > > o Enough information for the report consumer to re-calculate DMARC > disposition based on the published policy, message dispositon, and > SPF, DKIM, and identifier alignment results. {R12}" > >"enough information" is an ambiguous description of what the report >should include. > > >That SHOULD looks more like requirements language, and I agree the >bullet list is non-specific. The details are in the section >containing the XML syntax. We'll adjust. As a quick reaction this is fixable. > In Section 11.2: > > "Heuristics applied in the absence of use by a Domain Owner of either > SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be > the case that the Domain Owner wishes a Message Receiver not to > consider the results of that underlying authentication protocol at > all." > >The reference would have to be normative. > > >Is that true? I would think making normative something one SHOULD >NOT use seems contradictory. I missed the "e.g.". You could leave it as it as informative. I would remove the example, or that entire paragraph, and focus on the technologies you are using to design DMARC. > In Section 11.3: > > 'If email is subject to the DMARC policy of "quarantine", the Mail > Receiver SHOULD quarantine the message. If the email is not subject > to the "quarantine" policy (e.g., due to the "pct" tag), the Mail > Receiver SHOULD apply local spam classification as normal.' > >The usage of RFC 2119 key words in the above is incorrect. > > >Why? If I recall correctly, I wrote that as I thought that the above dictates local policy. You could restate this in terms of information the publisher is trying to convey. I would remove the "SHOULD apply local spam classification" as the draft is then trying to solve the spam problem. > In Section 12.2.1: > > 'In the case of a "mailto" URI, the Mail Receiver SHOULD communicate > reports using the method described in [STARTTLS].' > >Has the usual STARTTLS issues been taken into consideration for the >RFC 2119 recommendation? > > >Such as what? The trust path is usually broken for STARTTLS. It's like using self-signed certificates. There is also an ambiguity, if I recall correctly, in the specification. > "The aggregate data MUST be an XML file subjected to GZIP compression. > > The aggregate data MUST be present using the media type "application/ > gzip", and the filenames SHOULD be constructed using the following > ABNF:" > >In Section 12.2.2 it mentioned that: > > 'Where an "http" or "https" method is requested in a Domain Owner's > URI list, the Mail Receiver MAY encode the data using the > "application/gzip" media type ([GZIP]) or MAY send the Appendix C > data uncompressed or unencoded.' > >The data exchange format depends on the URI scheme being used. In >my opinion that makes the implementation more complex. > > >I don't agree, but I think the more important point is that the two >sections disagree on whether compression is required. Ok. > 'For the GZIP file itself, the extension MUST be "gz"; for the XML > report, the extension MUST be "xml".' > >I would ask why such a RFC 2119 requirement is in the draft. > > >For interoperability, of course. What's the issue here? That sounds using MIME sniffing. It's easier to defer to the relevant specification instead of setting a requirement here. > "Email streams carrying DMARC feedback data MUST conform to the DMARC > mechanism, thereby resulting in an aligned "pass" (see Section 4.3)." > >As far as I am aware the IETF does not do conformance. > > >It doesn't do conformance levels, as far as I'm aware. But you >either conform to the standard or you do not. Are you keying on the >word "conform" or is there more going on here? Yes, I was keying on the word "conform". The "standard" tells you what you need to know to achieve interoperability. My reading of the above is that you want an aligned "pass" and you worked your way back to get there. > 'The RFC5322.Subject field for individual report submissions SHOULD > conform to the following ABNF:' > >The Subject field is specified as structured text in the above. > > >Is that bad? The specification is re-purposing ancient technology. :-) The short answer is that it is not good. I was not keen about previous proposals taking such an approach. It works if you do it on a controlled environment. You might see problems as you scale it. >In Section 12.2.2: > > "The header portion of the POST or PUT request SHOULD contain a > Subject field as described in Section 12.2.1." > >This sounds like sending RFC 5322 formatted messages over HTTP. > > >Is that bad? I don't have enough information as I write this to say that it is bad. The proposal reminds me of another specification and that's not a good sign. :-) >In Section 15.8: > > "Many systems are able to scan the SMTP reply text to determine the > nature of the rejection, thus providing a machine-detectable reason > for rejection allows automated sorting of rejection causes so they > can be properly addressed." > >I don't think that it is a good idea to discuss about that as part >of a protocol specification. > >Why? The draft getting into heuristics. This takes you away from protocol specification to things people do because "it works for them". The straight answer is that I don't really know as it is a matter of whether the heuristics not working is really an edge case or something to seriously consider. >I suggest giving careful consideration to privacy. The draft >discusses about that in Section 15.10.1. The draft would require a >detailed review to understand what information is being exchanged >and how that can affect users. > >What issue should we cover that 15.10.1 does not already? I flagged this as "things to look out for". It's easier if you have people who will review the privacy considerations during the initial work. Given all the privacy discussions that are going on I suggest looking into it carefully. I don't have any idea of whether everything is covered adequately as I prefer not to put too much time into a review at this stage. >In Section 15.12: > > "The DMARC mechanism and its underlying technologies (SPF, DKIM) > depend on the security of the DNS. To reduce the risk of subversion > of the DMARC mechanism due to DNS-based exploits, serious consideration > should be given to the deployment of DNSSEC in parallel to the deployment > of DMARC." > >I would ask whether anyone who has deployed this mechanism is >actually using DNSSEC. If not the above is not saying anything to >ensure secure use of the protocol. > >I don't think it's pragmatic to demand use of DNSSEC because of the >obvious chicken-and-egg problem. However, for a system that is so >heavily reliant on the DNS being stable and secure, it seems wrong >not to mention this. The chicken-and-egg problem has been solved. You could have DNSSEC under Security Considerations. > "S/MIME, or Secure Multipurpose Internet Mail Extensions, is a > standard for encryption and signing of MIME data in a message. This > was suggested and considered as a third security protocol for > authenticating the source of a message." > >I could not understand the relationship between S/MIME and what this >specification attempts to do. > > >S/MIME can authenticate part of a message and associate it with a >user or role. DKIM and SPF can do the same. The relationship seems >obvious to me. The question will be asked "Why didn't you also >include support for FOOBAR?" and it seemed appropriate to make it >clear that we did, even if the result is that the idea was discarded. I see. > "It has been suggested in several message authentication efforts that > the Sender header field be checked for an identifier of interest, as > the standards indicate this as the proper way to indicate a re- > mailing of content such as through a mailing list. Most recently, it > was a protocol-level option for DomainKeys, but on evolution to DKIM, > this property was removed." > >That discussion would be better in a DKIM-related document instead >of adding it to this draft. > > >I don't agree, because "Use the Sender field!" came up during both >the private and public portions of the evolution of this work. As >with S/MIME, it seems appropriate to document history rather than repeat it. Ok. > 'DMARC has been characterized as a "super-ADSP" of sorts.' > >It is not a good idea to include criticism of other protocols in a >draft that specifies a protocol unless it is relevant to the >protocol being specified. > >Just about every BoF that tries to tackle a problem for which prior >attempts have failed includes an analysis of why those prior >attempts failed. I don't think this is any different, and I think >it provides a fair treatment of the issues with ADSP that have been >showstoppers for a lot of people. It happens. :-) You could leave it for now and drop the text before publication. >I suggest dropping the idea of using the "public suffix list" as >previous attempts to use it have not been successful in the IETF. > >The revised version makes it clear that we don't like public suffix >any better than the rest of the IETF does, and will be happy to >adopt a replacement solution as soon as there is one. I would flag the "public suffix list" on a Last Call so that nobody says that they were not aware that it is being standardized. Regards, -sm From johnl@taugh.com Fri Jul 5 12:25:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1679521F9E6A for ; Fri, 5 Jul 2013 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0WaSmPzGtBK for ; Fri, 5 Jul 2013 12:25:17 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 208BA21F9EF8 for ; Fri, 5 Jul 2013 12:25:16 -0700 (PDT) Received: (qmail 77191 invoked from network); 5 Jul 2013 19:25:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12d86.51d71d9b.k1307; bh=6lLfbTalh3xs4gyLXaGWvY15zfIUmQqGKFfdFy14wfU=; b=OfER23LPMwx7Yz5EpTDZZy32zUd2hQDWSIijVHP3yHxS9+7c9F1Vj6rfOgaSta8gLWw7/AxqzD10e3RHh3wu+tnhihDciUUA1+oigO7qXDGNvWc2qBLOKZndTZAw9Val74r5+obKWaiwPj05be5LKZucWvH/H52xEJYh29L5u8vVAevYcjz3Xh5y2v8Ms4sfn7K8gC75E50aAX93oE4+MlQYu520+FqLfMA3psp7RlRu7tKCRiQcYfOsNdMA84rU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12d86.51d71d9b.k1307; bh=6lLfbTalh3xs4gyLXaGWvY15zfIUmQqGKFfdFy14wfU=; b=L43hw/G9x1t/eQ6SCXWcapgkFKupGVWUEc0tnOAH6wX7iAswBbXouTK5J/FPejKTwxz2YFOHnqMTR0wyFh5Sh/cNkPGU/dLA/gdNXUvBBvwnCoxsoEjBZ1IhJjKt8MPfsEsR3Ygt1GydwjEE0cMuhksl2LuJxv6r1v7SqlptZLAKxTyA9bp3zzOYE11c2ae3gRdpRbGZAovsitnQETuMSz0rh8RjaA3YHn1FjFcQS3iokjXOg+1+VEdD6ObLDa8R Received: (ofmipd 127.0.0.1); 5 Jul 2013 19:24:53 -0000 Date: 5 Jul 2013 15:25:15 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130705185220.28629.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Eliot's review of the DMARC spec X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:25:18 -0000 > Wasn't it this? > http://www.ietf.org/mail-archive/web/dmarc/current/msg00292.html > > I don't have anything from him prior to that. Oh OK, I didn't realize it was from six weeks ago, so it aged out of the news spool where I keep list mail. R's, John From prvs=892313021=fmartin@linkedin.com Sat Jul 6 01:14:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C010D21F99CD for ; Sat, 6 Jul 2013 01:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 0t6Skv-goCxJ for ; Sat, 6 Jul 2013 01:14:25 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id C251221F8825 for ; Sat, 6 Jul 2013 01:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1373098465; x=1404634465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8zPHK7bGnr9W+lv8nQGKClol/LyjswsXEcsLjV/1F4Q=; b=Bs1EplYhtI+TjSfz63gFPKnv1Lr35O3IYLgZi9hxNZ20eRklIzmYbX27 MXWeeWgqPQEbF/OS77NUJ9TbmDI59jNHfxKu2MTg82aU3GNpBA0xDM26r OtXHYRdc2mnyopxeoroiYxUcUkZKi1qem5B25SYZGe9b+Xzu4dBeDlzqu w=; X-IronPort-AV: E=Sophos;i="4.87,1008,1363158000"; d="scan'208";a="54864665" Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Sat, 6 Jul 2013 01:14:09 -0700 From: Franck Martin To: SM Thread-Topic: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) Thread-Index: AQHOebVpplPe5sX1+kqIOKlzOpGV35lXw5CA Date: Sat, 6 Jul 2013 08:14:08 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linkedin.biz> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <6.2.5.6.2.20130705091238.0be05400@resistor.net> In-Reply-To: <6.2.5.6.2.20130705091238.0be05400@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <8AB2391EFE6B4740AE386A06290D2BC3@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 08:14:31 -0000 On Jul 5, 2013, at 11:05 AM, SM wrote: > Hi Murray, > At 01:34 05-07-2013, Murray S. Kucherawy wrote: >=20 >> In Section 15.8: >>=20 >> "Many systems are able to scan the SMTP reply text to determine the >> nature of the rejection, thus providing a machine-detectable reason >> for rejection allows automated sorting of rejection causes so they >> can be properly addressed." >>=20 >> I don't think that it is a good idea to discuss about that as part of a = protocol specification. >>=20 >> Why? >=20 > The draft getting into heuristics. This takes you away from protocol spe= cification to things people do because "it works for them". The straight a= nswer is that I don't really know as it is a matter of whether the heuristi= cs not working is really an edge case or something to seriously consider. >=20 There is not much standardization of response codes from MTAs. There are ex= tended response codes, but then you cannot deduct from them, if the problem= is due to DMARC or other security policies. If I'm not mistaken, take the = case of Facebook, refusing an email because you are not a friend of the rec= ipient... Or the same error code could indicate SPF or DKIM or other protoc= ol failure... Having the word DMARC in the text of the error message gives = a lot of information for debugging a specific email. Consider also the erro= r could be generated after a forwarder is trying to send an email... Withou= t a proper hint of what is the reason of the reject it is very hard to know= what really happened for a specific email. From dcrocker@gmail.com Sat Jul 6 10:51:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464A721F9C85 for ; Sat, 6 Jul 2013 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lANONuFR69je for ; Sat, 6 Jul 2013 10:51:01 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D159221F9B94 for ; Sat, 6 Jul 2013 10:50:56 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so4626926oah.7 for ; Sat, 06 Jul 2013 10:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Me+L9JqGG1Yhgos2QRzk84GNcq6HzZNc2smsB3JjPps=; b=kWcC1hJhhBnL6goEgyweVx2ryCvBEzFJwzPFE2frktuTMDiot+57F/7QfVePXDNrFe iOq9nEDBZGyC/FSXq+epOEHrDY5HJmUlan64l0b+35VqlV+JVYaXHqgilaPLhhB5+65y fCvxBwCR0OhQIXlgzgVEGVgcCKhzkBCgrxjbMeUK1uFTuL2Op/zLryhxddUKRXfgy80D ga51Sdwnutz+oaY9RT+we7olOqdifIEeCz39AnC+ix29D7LsEYqmNiD+Z5KfWORgqF/u L1zlQgv/jENqqgu3E34MbDfDgDE6Uxr4UPDlNDi++TUWu01x579njcTMQSJpCPW+In64 Ib5A== X-Received: by 10.182.81.233 with SMTP id d9mr15917079oby.43.1373133056440; Sat, 06 Jul 2013 10:50:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id df11sm23967564oec.0.2013.07.06.10.50.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 10:50:55 -0700 (PDT) Message-ID: <51D858EB.3030202@gmail.com> Date: Sat, 06 Jul 2013 10:50:35 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , "dmarc@ietf.org" , Eliot Lear Subject: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:51:02 -0000 On 7/5/2013 1:34 AM, Murray S. Kucherawy wrote: > On Thu, May 23, 2013 at 2:55 AM, SM > wrote: > The terminology section mentions terms such as "cousin domains", > "domain owner", etc. Although such terms may be popular I don't > think that it is a good idea to use them in a protocol document as > they can be ambiguous. > > > Can you make other suggestions? I think the first one is not ambiguous > in general, but we're very clear on defining and using the second. I'm astonished to discover that google does not readily produce major listings of a definition of cousin domain. (Interestingly, the dmarc base draft showed up pretty high in the search...) Anyhow, I think that means a) we have to create our own definition, and b) it's worth being fairly careful about the text of the definition, since there's a chance it will become popular... First listing I found strikes me as logical but wholly inadequate, in terms of interesting attacks: http://www.informit.com/articles/article.aspx?p=1190114 "we defined a cousin domain name as one that contains the candidate domain name in its entirety, with additional words either prefixed or appended to the candidate domain name." A squib from the book gets the idea, but isn't quite sufficient as a 'definition': Phishing and Countermeasures: Understanding the Increasing Problem of ...; edited by Markus Jakobsson, Steven Myers "phisher regisers a domain name similar to the targeted domain, such as 'commerceflaw.com' instead of 'commerceflow.com'." A variant of this one shows up in a dhs.gov document: http://www.cyber.st.dhs.gov/docs/phishing-dhs-report.pdf "domain name controlled by a phisher that isdeceptively similar to a legitimate domain name, such as www.commerceflowsecurity.cominstead of www.commerceflow.com." So in looking these over, I find myself liking the phrase "deceptively similar". Hence I'll propose: A cousin domain is a registered domain name that is deceptively similar to a target domain name. The target domain is familiar to many end-users, and therefore imparts a degree of trust. The deceptive similarity can trick the user by embedding the essential parts of the target name, in a new string, or it can use some variant of the target name, such as replacing 'i' with '1'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Sat Jul 6 11:05:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52221F9CC4 for ; Sat, 6 Jul 2013 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hllbWPFmUIyf for ; Sat, 6 Jul 2013 11:05:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00D21F9AF0 for ; Sat, 6 Jul 2013 11:05:12 -0700 (PDT) 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 r66I51lb013870; Sat, 6 Jul 2013 11:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373133908; bh=Ouvz9RTM8nPVEQmVIcNBKpbuAKpewzuqZ4NmRe4a5H0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gC+nit0430bx5fZfoaNhMJ9TWnDCzoPdiTj1aiP5IjpnpHQHQzoCdVDUao1DH03a0 vWyUz/NPSD3Afgqza0imxlFT0Pt4Lr+qsFodQLFxGJJQXLeOIoxjTrib8GRyVqyS3l iiMnhu/+fWAbGfhzgyGjWTIW/grx3jNQrQDsKLHE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373133908; i=@resistor.net; bh=Ouvz9RTM8nPVEQmVIcNBKpbuAKpewzuqZ4NmRe4a5H0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZxyejxzT9uUmmf0oXYBY7/FjAbWG1NApoNNLBn9zQ1pqmW/8LjD07ofS1OEGYka+L 1uIamMhRhh0h8gL5u3MP7XH49/bSDhhhCQ8Y387sfFU/NYDNbikYDTZrLkvzCCSNAF GJJhkbZf/Kz7HKA0TOaSN4xEbA8kAlTbYRX3Jme4= Message-Id: <6.2.5.6.2.20130706105143.0d56b5f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 06 Jul 2013 11:01:40 -0700 To: Franck Martin From: SM In-Reply-To: <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linked in.biz> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <6.2.5.6.2.20130705091238.0be05400@resistor.net> <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linkedin.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:05:19 -0000 Hi Frank, At 01:14 06-07-2013, Franck Martin wrote: >There is not much standardization of response codes from MTAs. There >are extended response codes, but then you cannot deduct from them, >if the problem is due to DMARC or other security policies. If I'm >not mistaken, take the case of Facebook, refusing an email because >you are not a friend of the recipient... Or the same error code >could indicate SPF or DKIM or other protocol failure... Having the >word DMARC in the text of the error message gives a lot of >information for debugging a specific email. Consider also the error >could be generated after a forwarder is trying to send an email... >Without a proper hint of what is the reason of the reject it is very >hard to know what really happened for a specific email. That is usually know as a local policy decision. If I recall correctly the question of the sender knowing the reason for a mail delivery failure was discussed in another working group. I understand the use case mentioned above. I would look at the draft in terms of a standard for the Internet, if that is the intended purpose, instead of a document about how to know why a message is considered as spam. Regards, -sm From matt@tnpi.net Sat Jul 6 11:19:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8D21F9CD1 for ; Sat, 6 Jul 2013 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5biSEjO5La1 for ; Sat, 6 Jul 2013 11:19:04 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id A767821F9CD0 for ; Sat, 6 Jul 2013 11:19:04 -0700 (PDT) Received: (qmail 67997 invoked by uid 1026); 6 Jul 2013 18:18:58 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Sat, 06 Jul 2013 14:18:58 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; s=mar2013; bh=9PN8GLhmGHEMG6qiYgyvf+4DH3LPN2Oq/nJTfNx5omc=; b=Pxi5r+nhUWHbzkkRuGDCKHogQHD95JDaqb7SmEQpXWMF1Sn2/gP/9wcMw3+Cd2LgR7Jx5KRvOAtqIE0TI5oSV7AKdlr68zsWht65Fj5VuowHr9+94TXBwhv5EcFMDImgvOUNX800ggYxBqmav4IaFxH6xIiNKOsqEScaw3kcgQ5UblAEUugnmzBPD1gSPwoqX8nvZmGt25G9Nnfm3+zPpQHGyt0+REbCN1FYsb0BJjocCjdI+FQTmYnLiv6sfTZJIgmD4ekwTFxCMUGFmVAczB5cPd7dPdSYgjKzlLo4Nx6Owria8m/tjJv+HAhRDYV+ovHeHqoLoKpaUGjU7RGByQ== X-HELO: [10.0.1.32] Content-Type: multipart/alternative; boundary="Apple-Mail=_740BB305-9476-43D9-9B9B-4877EB05694B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: <51D858EB.3030202@gmail.com> Date: Sat, 6 Jul 2013 11:18:57 -0700 Message-Id: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.1508) Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:19:08 -0000 --Apple-Mail=_740BB305-9476-43D9-9B9B-4877EB05694B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 6, 2013, at 10:50 AM, Dave Crocker wrote: > On 7/5/2013 1:34 AM, Murray S. Kucherawy wrote: >> On Thu, May 23, 2013 at 2:55 AM, SM > > wrote: >> The terminology section mentions terms such as "cousin domains", >> "domain owner", etc. Although such terms may be popular I don't >> think that it is a good idea to use them in a protocol document as >> they can be ambiguous. >>=20 >> Can you make other suggestions? I think the first one is not = ambiguous >> in general, but we're very clear on defining and using the second. >=20 > IAnyhow, I think that means a) we have to create our own definition, = and b) it's worth being fairly careful about the text of the definition, = since there's a chance it will become popular... +1 > So in looking these over, I find myself liking the phrase "deceptively = similar". +1 > Hence I'll propose: >=20 > A cousin domain is a registered domain name that is deceptively = similar to a target domain name. The target domain is usually familiar = to many end-users, and therefore imparts a degree of trust. The = deceptive similarity can trick the user by embedding the essential parts = of the target name, in a new string, or it can use some variant of the = target name, such as replacing 'i' with '1'. I inserted the word 'usually'.=20 In addition to providing basic examples, perhaps include the well = defined and recognized terms: typosquatting, and IDN homographs? https://en.wikipedia.org/wiki/Typosquatting https://en.wikipedia.org/wiki/IDN_homograph_attack Matt= --Apple-Mail=_740BB305-9476-43D9-9B9B-4877EB05694B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii dcrocker@gmail.com> = wrote:
On 7/5/2013 1:34 AM, Murray S. Kucherawy = wrote:
On Thu, May 23, 2013 at 2:55 AM, SM = <sm@resistor.net
<mailto:sm@resistor.net>> = wrote:
   The terminology section mentions terms such = as "cousin domains",
   "domain owner", etc. =  Although such terms may be popular I don't
=    think that it is a good idea to use them in a protocol = document as
   they can be ambiguous.

Can you = make other suggestions?  I think the first one is not = ambiguous
in general, but we're very clear on defining and using the = second.

IAnyhow, I think that means a) we have to = create our own definition, and b) it's worth being fairly careful about = the text of the definition, since there's a chance it will become = popular...

+1

So in looking these over, I find myself liking the phrase = "deceptively similar". =

+1

Hence I'll propose:

    A = cousin domain is a registered domain name that is deceptively similar to = a target domain name.  The target domain is = usually familiar to many end-users, and therefore imparts a = degree of trust.  The deceptive similarity can trick the user by = embedding the essential parts of the target name, in a new string, or it = can use some variant of the target name, such as replacing 'i' with = '1'.

I inserted the word = 'usually'. 

In addition to providing basic = examples, perhaps include the well defined and recognized terms: = typosquatting, and IDN homographs?


Matt= --Apple-Mail=_740BB305-9476-43D9-9B9B-4877EB05694B-- From dcrocker@gmail.com Sat Jul 6 11:42:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A7B21F9B8E for ; Sat, 6 Jul 2013 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY3burpkSP0x for ; Sat, 6 Jul 2013 11:42:10 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94821F9A23 for ; Sat, 6 Jul 2013 11:42:10 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so4677027oag.2 for ; Sat, 06 Jul 2013 11:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f+B6YWstci99wC2kmTlR1bbebcuzM3LNDPMeCE3jZYA=; b=vvzsrmBTnEXWX5yOF13WZjGDFrmcNCMar9iesEynemy4ctd18eqMBrxwQmKG0Rfs8C g2ws5qFYZxV744kJm6R9Jw4VcZ17Cu0Dpvewvj4/ZlQUPS9TRfM5EgpzjDYUwLvZDsas T2e94uyvJOzoDLTpzitKZdkK39CFeIVql0BcEOhZTSldS6xdfW3LGG05GfFMeLnCmhIE kBjAEKYIYO1ztS46sMrYoWJmMzEIuK4XepxLwKu9vCqNzaaHMSTWtFerP4hz7kq5UTAx uDxI7PuY8P96WKjRWGp+svYUxk+qIl9hesMHdb+d7EeN3FHJo5OBIx7JT3AZgpqRVCHD 57TA== X-Received: by 10.60.96.9 with SMTP id do9mr15757292oeb.49.1373136129761; Sat, 06 Jul 2013 11:42:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id b7sm23767344oby.5.2013.07.06.11.42.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 11:42:08 -0700 (PDT) Message-ID: <51D864EC.1040105@gmail.com> Date: Sat, 06 Jul 2013 11:41:48 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Matt Simerson References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:42:11 -0000 Thanks for the quick feedback. some additional thoughts... On 7/6/2013 11:18 AM, Matt Simerson wrote: >> A cousin domain is a registered domain name that is deceptively >> similar to a target domain name. The target domain is *usually >> *familiar to many end-users, and therefore imparts a degree of trust. >> The deceptive similarity can trick the user by embedding the >> essential parts of the target name, in a new string, or it can use >> some variant of the target name, such as replacing 'i' with '1'. > > I inserted the word 'usually'. That's a kind of careful phrasing that makes sense for precise specification, but I think is actually distracting for the usage here. That is, I think that extra qualifiers in definitions are, ummmm... usually distracting... It's not that it's wrong; it's that I doubt it's as helpful as we'd like. > In addition to providing basic examples, perhaps include the well > defined and recognized terms: typosquatting, and IDN homographs? > > https://en.wikipedia.org/wiki/Typosquatting > https://en.wikipedia.org/wiki/IDN_homograph_attack yeah, and probably cite the dhs.gov text, to show some history to the key phrase. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From zwicky@yahoo-inc.com Sat Jul 6 11:53:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE421F9BCA for ; Sat, 6 Jul 2013 11:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.599 X-Spam-Level: X-Spam-Status: No, score=-18.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf0nLQpzP7YP for ; Sat, 6 Jul 2013 11:53:04 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id CFDA021F9A94 for ; Sat, 6 Jul 2013 11:53:04 -0700 (PDT) Received: from GQ1-EX10-CAHT02.y.corp.yahoo.com (gq1-ex10-caht02.corp.gq1.yahoo.com [10.73.118.81]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r66IqNxT047543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 6 Jul 2013 11:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1373136746; bh=sS+09N2pGL93q2e6tn09NKj3DhwaAK4OoysIQ1L4neQ=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=P/ihzdOr9Xy+RjltIizOmpYeI/iBwh/D8pyeEu44Hk80Qhpx2caPRpk2P7qb7eTEg XRjt5SY3isxTAnkI4KrfAxleyU9NJraw0iZCCrMirt3sgg0gbaXNugPEuf4z4wQKoq sUtHhmiDkRJxAZ8p2hbpAUX4I4oFOAmaGhumF4V0= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT02.y.corp.yahoo.com ([fe80::35be:ca2f:4da2:1e90%12]) with mapi id 14.03.0123.003; Sat, 6 Jul 2013 11:52:22 -0700 From: Elizabeth Zwicky To: Dave Crocker , Matt Simerson Thread-Topic: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) Thread-Index: AQHOenimX9DauVXNMESPUplVCINllZlX/vKA Date: Sat, 6 Jul 2013 18:52:22 +0000 Message-ID: In-Reply-To: <51D864EC.1040105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [216.145.54.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <920AFD6BEC101647A3E857BA6F09D92D@yforest.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 136743001 Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:53:08 -0000 I would say that the target domain is familiar to the users under attack. Elizabeth On 7/6/13 11:41 AM, "Dave Crocker" wrote: >Thanks for the quick feedback. > >some additional thoughts... > > >On 7/6/2013 11:18 AM, Matt Simerson wrote: >>> A cousin domain is a registered domain name that is deceptively >>> similar to a target domain name. The target domain is *usually >>> *familiar to many end-users, and therefore imparts a degree of trust. >>> The deceptive similarity can trick the user by embedding the >>> essential parts of the target name, in a new string, or it can use >>> some variant of the target name, such as replacing 'i' with '1'. >> >> I inserted the word 'usually'. > >That's a kind of careful phrasing that makes sense for precise >specification, but I think is actually distracting for the usage here. > >That is, I think that extra qualifiers in definitions are, ummmm... >usually distracting... > >It's not that it's wrong; it's that I doubt it's as helpful as we'd like. > > >> In addition to providing basic examples, perhaps include the well >> defined and recognized terms: typosquatting, and IDN homographs? >> >> https://en.wikipedia.org/wiki/Typosquatting >> https://en.wikipedia.org/wiki/IDN_homograph_attack > >yeah, and probably cite the dhs.gov text, to show some history to the >key phrase. > >d/ > > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From matt@tnpi.net Sat Jul 6 12:01:48 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9618921F9CC1 for ; Sat, 6 Jul 2013 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bw4bKReeNZnX for ; Sat, 6 Jul 2013 12:01:33 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id E25AA21F9CDD for ; Sat, 6 Jul 2013 12:01:32 -0700 (PDT) Received: (qmail 88099 invoked by uid 1026); 6 Jul 2013 19:01:32 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Sat, 06 Jul 2013 15:01:32 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=/IBWCLoxWG+wXb8SnOw/RT7jjTa0xyY/F//hHf2hOIQ=; b=yA1DWdmP8/w2HPaqWdR92glQG4aQQgzOct7op1AqtGj0SUFjTGADZeeHY205t+PCqJkdjORwIPNjOpeC/RMrhy0q1eCRHaHpxiyN4cyrecKUD4sj5yaVsAYfl0rymSvRzSckwU/6pHAtJxa5S9vwIb3KFTf/h/Sv8LIXSDY4Mw91YcZbu+szF+iXoi1DlCg3JEa2BDNbshqaX1i8DlUqVYThLqkc5bJlbQdah3rhPAkpYU3U64yobQmKHplfXi/GdqAxdaT1I1ONIkpdviSrpdbDgI1+Gh88A15mY7A8AKAW/UkYUbW5V1VC1D0sIvt+UNa2ne7INcK5B9VnCpI7NQ== X-HELO: [10.0.1.32] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: <51D864EC.1040105@gmail.com> Date: Sat, 6 Jul 2013 12:01:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> <51D864EC.1040105@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.1508) Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:01:48 -0000 On Jul 6, 2013, at 11:41 AM, Dave Crocker wrote: > On 7/6/2013 11:18 AM, Matt Simerson wrote: >>> A cousin domain is a registered domain name that is deceptively >>> similar to a target domain name. The deceptive similarity = can trick the user by embedding the >>> essential parts of the target name, in a new string, or it can use >>> some variant of the target name, such as replacing 'i' with '1'. >>=20 >> I inserted the word 'usually'. >=20 > That's a kind of careful phrasing that makes sense for precise = specification, but I think is actually distracting for the usage here. >=20 > That is, I think that extra qualifiers in definitions are, ummmm... = usually distracting... >=20 > It's not that it's wrong; it's that I doubt it's as helpful as we'd = like. Why not remove the domain familiarity part entirely? The essence of a = cousin domain is not in the victims familiarity with the target domain = name (which is less common than technophiles would hope) but in the = victims familiarity with the organizational name in the domain. Matt= From prvs=892313021=fmartin@linkedin.com Sat Jul 6 12:15:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F0C21F9B94 for ; Sat, 6 Jul 2013 12:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Vy3TmH7GPdFM for ; Sat, 6 Jul 2013 12:15:33 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7394521F9C4E for ; Sat, 6 Jul 2013 12:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1373138131; x=1404674131; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vjlJDNLFsHw718OrNrA+kJiYBLi2UFymqHpVc77tTR0=; b=pNM7+FQ/Q7RmzrIWVkUa1KLoM6iOWqWrDGvZLrjLmrYDAIV5uazpTCkZ iCoUkCDMmj4neHBFKBXnnKHJ2arI+ylGq97GUsLSBz69IxGoNLx/oEKQv /gn6LX+cyb9tGQes6cI8YeZPq5Sj0lj6/phoEloGjm8lkYc7pVsmjiJdl E=; X-IronPort-AV: E=Sophos;i="4.87,1010,1363158000"; d="scan'208";a="54887137" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sat, 6 Jul 2013 12:15:14 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sat, 6 Jul 2013 12:15:14 -0700 From: Franck Martin To: SM Thread-Topic: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) Thread-Index: AQHOenNZRnhBwLurRkCph9DVdvyg+JlYesqA Date: Sat, 6 Jul 2013 19:15:14 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53A7FE84@ESV4-MBX02.linkedin.biz> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <6.2.5.6.2.20130705091238.0be05400@resistor.net> <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linkedin.biz> <6.2.5.6.2.20130706105143.0d56b5f8@resistor.net> In-Reply-To: <6.2.5.6.2.20130706105143.0d56b5f8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <6F0F947CB6144A4D8AC650428EF5142F@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:15:37 -0000 On Jul 6, 2013, at 11:01 AM, SM wrote: > Hi Frank, > At 01:14 06-07-2013, Franck Martin wrote: >> There is not much standardization of response codes from MTAs. There are= extended response codes, but then you cannot deduct from them, if the prob= lem is due to DMARC or other security policies. If I'm not mistaken, take t= he case of Facebook, refusing an email because you are not a friend of the = recipient... Or the same error code could indicate SPF or DKIM or other pro= tocol failure... Having the word DMARC in the text of the error message giv= es a lot of information for debugging a specific email. Consider also the e= rror could be generated after a forwarder is trying to send an email... Wit= hout a proper hint of what is the reason of the reject it is very hard to k= now what really happened for a specific email. >=20 > That is usually know as a local policy decision. If I recall correctly t= he question of the sender knowing the reason for a mail delivery failure wa= s discussed in another working group. >=20 > I understand the use case mentioned above. I would look at the draft in = terms of a standard for the Internet, if that is the intended purpose, inst= ead of a document about how to know why a message is considered as spam. >=20 Sure, but if you don't provide guidance in this document for implementors, = where will you give it? From prvs=892313021=fmartin@linkedin.com Sat Jul 6 12:20:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8021F9A6A for ; Sat, 6 Jul 2013 12:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 LNqtVAfiHhh4 for ; Sat, 6 Jul 2013 12:20:28 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 11D2121F9A30 for ; Sat, 6 Jul 2013 12:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1373138428; x=1404674428; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/U/KDuswIbXXOivFI6sBk7lCjKofhd/T1c5Tfxzm8kU=; b=NOv/yLa+Xs9XBN8E2pxqG8DAqk2CTjg2l1ldZpguk3uM2YSkYQ00u4ae /a+/zvKV5MoVgllPfLcIQ022RiRx4zLoUt7BfgMLh1XZ6MRlev0RzBcqU uuJeeqQ+TmkUCsTd6EYO2MtpVFbFcTRQdBJPqnfsnAvzJE11QEhk77S1Z k=; X-IronPort-AV: E=Sophos;i="4.87,1010,1363158000"; d="scan'208";a="53241931" Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Sat, 6 Jul 2013 12:20:10 -0700 From: Franck Martin To: Matt Simerson Thread-Topic: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) Thread-Index: AQHOens/xA0+0/WmvEmOAIUmr9YDwplYfBwA Date: Sat, 6 Jul 2013 19:20:10 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53A80000@ESV4-MBX02.linkedin.biz> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> <51D864EC.1040105@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <97CBB744243F11479DEB154F2CFD52D0@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dave Crocker , SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:20:35 -0000 On Jul 6, 2013, at 12:01 PM, Matt Simerson wrote: >=20 > On Jul 6, 2013, at 11:41 AM, Dave Crocker wrote: >=20 >> On 7/6/2013 11:18 AM, Matt Simerson wrote: >>>> A cousin domain is a registered domain name that is deceptively >>>> similar to a target domain name. The deceptive similarity can = trick the user by embedding the >>>> essential parts of the target name, in a new string, or it can use >>>> some variant of the target name, such as replacing 'i' with '1'. >>>=20 >>> I inserted the word 'usually'. >>=20 >> That's a kind of careful phrasing that makes sense for precise specifica= tion, but I think is actually distracting for the usage here. >>=20 >> That is, I think that extra qualifiers in definitions are, ummmm... usua= lly distracting... >>=20 >> It's not that it's wrong; it's that I doubt it's as helpful as we'd like= . >=20 > Why not remove the domain familiarity part entirely? The essence of a cou= sin domain is not in the victims familiarity with the target domain name (w= hich is less common than technophiles would hope) but in the victims famili= arity with the organizational name in the domain. >=20 I think we should completely remove the notion of cousin domains or at leas= t include it as part of a subset of grief, which is any email that claims t= o be from a brand regardless of the domain present in the From: It seems to me, the miscreants do not care anymore what domain they put the= re... At least that's my experience. From dcrocker@gmail.com Sat Jul 6 12:20:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55721F9A30 for ; Sat, 6 Jul 2013 12:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ltRTStzaauU for ; Sat, 6 Jul 2013 12:20:35 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 386C821F9A31 for ; Sat, 6 Jul 2013 12:20:31 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so4817297oag.27 for ; Sat, 06 Jul 2013 12:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1gz0YovbKt0pzK1HnBuTJgT/iwTbyWBPjF3VUnFuetA=; b=t+Fuo9qOElD87fYDDx4bPElL/NjQw5zuNKKWUWO2kjJpnT5Xxdbu6Lr/52p86ovJ5z aaBSE/Zd+xkG9tu7EbmkJOpD+Zs4qj7V7xEmGlcNyc+jDyHGOPYpjSOmngX+NmZu0uOp o3c6z7ssewk0D9WShL3cPn+Bu+6sDdEIuwdSCmL2PnRu7dV53UDW9SyjYyOlblGC3/QA 52k0QP4mwJ0wRErpkMvUmugCD/nNo1uH9szfVXCqFLoX9rDEm01mWp3nXekfxAFEPULL v8Nq0bAuklqCxcSbZoRbOjZcxw+gH/SAhCMffptd8lRTsq58eFQWEf/pNSRmFDIKgdw/ yHTQ== X-Received: by 10.182.129.101 with SMTP id nv5mr15763892obb.56.1373138429806; Sat, 06 Jul 2013 12:20:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id r4sm24300892oem.3.2013.07.06.12.20.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 12:20:29 -0700 (PDT) Message-ID: <51D86DE8.8060103@gmail.com> Date: Sat, 06 Jul 2013 12:20:08 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Matt Simerson References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> <51D864EC.1040105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:20:36 -0000 On 7/6/2013 12:01 PM, Matt Simerson wrote: > Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the victims familiarity with the target domain name (which is less common than technophiles would hope) but in the victims familiarity with the organizational name in the domain. well, /that's/ an interesting point. comments? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sat Jul 6 19:41:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961D21F9DBF for ; Sat, 6 Jul 2013 19:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.832 X-Spam-Level: X-Spam-Status: No, score=-100.832 tagged_above=-999 required=5 tests=[AWL=-9.633, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, URIBL_BLACK=20, 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 Z-Cas+JiOFHr for ; Sat, 6 Jul 2013 19:41:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8021F9CE9 for ; Sat, 6 Jul 2013 19:41:05 -0700 (PDT) Received: (qmail 50447 invoked from network); 7 Jul 2013 02:41:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Jul 2013 02:41:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d8d53f.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=wRGev7hF0TA1L/Mz/JFevqbz/FMLWiRkLIGjasCai/s=; b=3FFdfLtywW4Du+6m9rtJZvOC/ARVDE4afyX0qLIw6kNfkc6fmPskUePOTOwOVUUNAO9ubVYeYeOYixzBiCdpR0AMjHpjCpr3KgudWw1aoUaPd/j/dXrihXCE9PRtxg455VubU/SZptsJzj+Jd82HRs/6Fw08WIInTWrI3YissHkQr6fkM0XuqWuv+2GEDX6XSXqSAv4sQjdD9SZUMBfu7dqbT5obtkw9qKaIY7t/CtEI8+nn9xkipUggtFXt97Sh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d8d53f.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=wRGev7hF0TA1L/Mz/JFevqbz/FMLWiRkLIGjasCai/s=; b=VBeHMz3mZ7SUWkpGZGYvMI1hV20my30x07g9vmHBPe1XXtSvWCFLXxlPIgaB9bIMYSxopEbbnWCO0J8meWSdUErNgYNSFV3jDjyOvPggUE802A+akWoW5DRfjTdag0mBbcMl5syJkPnUIs6vCQsgxt/e6402BfUw0JznVcDcoNw48JvUSCwzLQRPKXas2sMy3Lw/Hj6oWugv5gzR7HII9ue+QIaTFzhZ1RwKZc2Er8m1p/SLaR+mqq8/axlBs/5R Date: 7 Jul 2013 02:40:41 -0000 Message-ID: <20130707024041.55347.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51D86DE8.8060103@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:41:09 -0000 >> Why not remove the domain familiarity part entirely? The essence of a cousin domain is not in the >victims familiarity with the target domain name (which is less common than technophiles would hope) >but in the victims familiarity with the organizational name in the domain. > > >well, /that's/ an interesting point. > >comments? Sounds right to me. paypaI.com is a phish because it resembles Paypal. From superuser@gmail.com Sat Jul 6 23:04:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9885F21F9E3D for ; Sat, 6 Jul 2013 23:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbMdtWVpkbsC for ; Sat, 6 Jul 2013 23:04:14 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id CD75121F9E32 for ; Sat, 6 Jul 2013 23:04:13 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3091745wiw.1 for ; Sat, 06 Jul 2013 23:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e4/C9oExh1tdVCZmXt225sLgCNlPD4pIyeS4xVCWvlA=; b=dVOkops+w11XNqLPPxjDrc4DIn8xtZT8HNEeCjIE+UEXsatyyyqigJPgUr35QRg3rw m/Z+ou2G1FuTzPVxlBOaZPlhDZu18bVBp3OEwahECvgjwovUf67fFzVshZ61rytqPu4x jKw9pR3/X0DqL2iQx3dv3pe8M6i3P5TMDmXCSOfb7tLtfWq8/4dPuiRzuxXCA7BN03W/ JZ9vOV5pU1K1DQOMmgNPoVKl5GRP1OBDHUm7accxTrnoCy0Xhycfj+KePHXWbebsoH0V SlCbhbXdATkCLvCZNmEbok4maWxa79mOEI/vmG0whh2AeIwQeppjFulZ9vAfvkFQoCsp ydpA== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr8993333wic.60.1373177053010; Sat, 06 Jul 2013 23:04:13 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sat, 6 Jul 2013 23:04:12 -0700 (PDT) In-Reply-To: <51D858EB.3030202@gmail.com> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> Date: Sat, 6 Jul 2013 23:04:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c26a5e75623404e0e5b2b6 Cc: SM , "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 06:04:14 -0000 --001a11c26a5e75623404e0e5b2b6 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 6, 2013 at 10:50 AM, Dave Crocker wrote: > So in looking these over, I find myself liking the phrase "deceptively > similar". Hence I'll propose: > > A cousin domain is a registered domain name that is deceptively > similar to a target domain name. The target domain is familiar to many > end-users, and therefore imparts a degree of trust. The deceptive > similarity can trick the user by embedding the essential parts of the > target name, in a new string, or it can use some variant of the target > name, such as replacing 'i' with '1'. > > Seems a reasonable starting point. Might also include a reference to "homograph (literally, one appearance) attack". -MSK --001a11c26a5e75623404e0e5b2b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 10:50 AM, Dave Crocker <dcrocker@= gmail.com> wrote:
So in looking these over, I find myself liki= ng the phrase "deceptively similar". =A0Hence I'll propose:
=A0 =A0 =A0A cousin domain is a registered domain name that is deceptively = similar to a target domain name. =A0The target domain is familiar to many e= nd-users, and therefore imparts a degree of trust. =A0The deceptive similar= ity can trick the user by embedding the essential parts of the target name,= in a new string, or it can use some variant of the target name, such as re= placing 'i' with '1'.


Seems a reasonable start= ing point.=A0 Might also include a reference to "homograph (literally,= one appearance) attack".

-MSK
--001a11c26a5e75623404e0e5b2b6-- From sm@resistor.net Sat Jul 6 23:34:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9755A21F91B7 for ; Sat, 6 Jul 2013 23:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 FTIbkYl0XvTd for ; Sat, 6 Jul 2013 23:34:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6A21F8700 for ; Sat, 6 Jul 2013 23:34:36 -0700 (PDT) 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 r676YO5x001335; Sat, 6 Jul 2013 23:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373178869; bh=XSu6xT2AB8s/BIeY1ZYf/mCHDIbtzpmyTe4EqV1xF9I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RiMbp4etmXG+GWLaMjtRXTWWgvkm39KvN4xmFAIuCRctM2Kkd35LGSpYawDF7j/Gu p9Mq8gH510Pa8Pm0S/jM3/I1clqQDGz1AUrliTPX1WeugfotxDU6xEMAJLIB/7/k2h uHXh2vI+IPD2tfO1ED7XdC7z35YCild4fBdbbQCA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373178869; i=@resistor.net; bh=XSu6xT2AB8s/BIeY1ZYf/mCHDIbtzpmyTe4EqV1xF9I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MHXKWyr1CZ0B/HdbHgooIbfbKixZBQqCJmGIegCwAe/PyMxS59DRZFrorlVbqYRIr 6cO2f4ZBaZFYA99Zy3eI6tUVXFBlOQLRtBiIm4jiHiKMNkTAxA/qxfubesReu2HUeW hZyWoo9/XRS7YBK6uyS9cscb4/EG0kXatlsZ5hkc= Message-Id: <6.2.5.6.2.20130706230555.06a4e890@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 06 Jul 2013 23:16:25 -0700 To: Franck Martin From: SM In-Reply-To: <77426B543150464AA3F30DF1A91365DE53A7FE84@ESV4-MBX02.linked in.biz> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <6.2.5.6.2.20130705091238.0be05400@resistor.net> <77426B543150464AA3F30DF1A91365DE53A77D0C@ESV4-MBX02.linkedin.biz> <6.2.5.6.2.20130706105143.0d56b5f8@resistor.net> <77426B543150464AA3F30DF1A91365DE53A7FE84@ESV4-MBX02.linkedin.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 06:34:38 -0000 Hi Franck, At 12:15 06-07-2013, Franck Martin wrote: >Sure, but if you don't provide guidance in this document for >implementors, where will you give it? If the purpose of the document is to provide guidance for implementers about why a message is considered as spam I would put that guidance in the document. Regards, -sm From superuser@gmail.com Sun Jul 7 00:20:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CCB21F9E52 for ; Sun, 7 Jul 2013 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHk7afOKPGV3 for ; Sun, 7 Jul 2013 00:20:39 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 440C121F9E50 for ; Sun, 7 Jul 2013 00:20:39 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so8144273wgg.0 for ; Sun, 07 Jul 2013 00:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=83JeaCqbmg1unOTFqjIrbkHVnqeXRyYpkKCjtjA5i84=; b=e3qD8MvIXVXPxdNPFo2VqU8DgvoOxaT12Eu5S7+++gAgKwXIr3oQlagWcbXCyRnfxn ZW116c9e4Vac9pdnz6fKUsU0x3x8J2zyvPj7BWUC1RqQ10hhJuJA7u7hljADKDGStZcU AIHSDKIMBNCcJ2TOPGNrFnJwkDhPU3Ympz/xLaDlw+S6DbNCwQJy18yWUfvJroN1l5l8 2q23/NYvx5jdENPFYl0sdJe4Pj9MacKhBRHRXX3fg8TQjBRpAQpQMdYsZb1zct3Z6SOl UY23OIqA+LWecFR17gv/r0RqVjzAql8lkLoB7+1a+9vPDVx7Rs2RCeyVuf1R3y7RzlB9 JJeA== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr9082056wic.60.1373181638358; Sun, 07 Jul 2013 00:20:38 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 7 Jul 2013 00:20:37 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130705091238.0be05400@resistor.net> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <6.2.5.6.2.20130705091238.0be05400@resistor.net> Date: Sun, 7 Jul 2013 00:20:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=001a11c26a5ec43d1e04e0e6c32c Cc: "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:20:41 -0000 --001a11c26a5ec43d1e04e0e6c32c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 5, 2013 at 11:05 AM, SM wrote: > The details are further down in the document. Section 5 is setting the > stage for what comes later. It's more overview than substance. > > I suggest not putting requirements in a section which provides an > overview. Barry and Pete commented about yelling in a WG. I suggest > taking those comments into consideration. As a meta-comment about > setting the stage I suggest writing the proposal as a mechanism. You could > then drop text, reorganize it, etc. to come up with a leaner version which > specifies the mechanism and avoids the usual headaches. > I think requirements, or perhaps they're better stated as "goals", explain part of how we got here. They're useful for providing background. > > >> "Mail Receivers MAY deviate from a Domain Owner's published policy >> during message processing and SHOULD make available the fact and >> reason of the deviation to the Domain Owner via feedback reporting." >> >> I read the above as "if you do not do what I say you have to provide me >> with a justification". Let me rewrite the text: >> >> "Mail Receivers deviating from a Domain Owner's published policy >> during message processing and MUST make available the fact and >> reason of the deviation to the Domain Owner via feedback reporting." >> >> If that text is not acceptable to mail receivers the RFC 2119 SHOULD will >> have the same effect. >> >> SHOULD is appropriate. There can be local policy reasons for not >> revealing such details via feedback. >> > > What I meant is that the proposal is telling mail receivers what to do. > The matter is entirely a local policy issue. > draft-kucherawy-dmarc-base-00 is intended as a Standards Track document. > The draft is doing policy stuff and trying to set conformance. There has > been previous similar efforts. I would describe them as controversial and > subject to interpretation. I would scope the work to keep the > implementation and policy parts separate so that you have a tightly-written > specification. > I think your change of "MAY deviate" to "deviating" is fine, but changing MUST to SHOULD won't work. MUST is not appropriate because the protocol doesn't completely break if you don't take the action described here, and there are certain to be operators that won't do what's specified because of a need to keep internal mechanisms private. That fits SHOULD nicely. Any standards track document "sets conformance" by spelling out those parts that are mandatory to implement. I don't understand the objection there. > >> In Section 7: >> >> "When this is done, the DNS domain name thus recorded MUST be encoded >> as an >> A-label, as described in Section 2.3 of [IDNA]." >> >> The above is under "policy enforcement considerations". It should be in >> a section discussing the DNS aspects of the specification. >> >> Why? The context is the construction of an RFC5451 header field, not >> something about DNS. >> > > I guess that we are reading "policy enforcement considerations" > differently. The context is as what you wrote above. What I was > suggesting is to separate policy from how the DMARC code is supposed to > work. You could take the RFC 5451 approach to simplify the draft. > > Every operational environment is different. Some will be able to take the RFC5451 approach and some will not. Shouldn't we provide operational advice for both cases? > > Section 8.2 is about "Verifying External Destinations". If I am not >> mistaken, IETF specifications are not about imposing a specific method. >> Section 8.2 sounds like a tutorial for the implementer instead of a >> definition of what the "DMARC policy string" means. >> >> >> I disagree; a specification is indeed about describing a specific method. >> Tutorials for implementers appear throughout various documents we produce, >> one of which you are working on in another working group right now. :-) >> > > I disclaim any knowledge of any other working group. :-) > > I have been reading some specifications (not mail-related) and some > reviews recently. I don't think that the Internet Engineering Tooth Fairy > will agree with the following; sometimes a proposal specifies a method and > gets into details which turns the proposal into a guide about a specific > implementation. A Standards Track document is about interoperability and > not about specifying how the implementor should do things. > This sort of protocol isn't completely deterministic. At various junctures, there are places where operational decisions get made. It strikes me that guidance when making those decisions is a good thing, and its absence would be a bad thing. We are asked to provide it more often than not. I think it all comes down to whether separating that sort of material out into a separate document is a useful thing to do. If doing so would mean an implementer needs to hop back and forth between two documents just to get the thing running, I'd say we've done the implementer a disservice. I'm going to leave the rest for now and see what you think of the next version. I think a lot of this has been addressed, though I'm sure there will be other things to discuss. -MSK --001a11c26a5ec43d1e04e0e6c32c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 5, 2013 at 11:05 AM, SM <= sm@resistor.net>= ; wrote:
=A0The details are further down in the document. =A0Section 5 is setting th= e stage for what comes later. =A0It's more overview than substance.

I suggest not putting requirements in a section which provides an overview.= =A0Barry and Pete commented about yelling in a WG. =A0I suggest taking tho= se comments into consideration. =A0 =A0As a meta-comment about setting the = stage I suggest writing the proposal as a mechanism. =A0You could then drop= text, reorganize it, etc. to come up with a leaner version which specifies= the mechanism and avoids the usual headaches.

I think requirements, or perhaps they'= re better stated as "goals", explain part of how we got here.=A0 = They're useful for providing background.
=A0


=A0 "Mail Receivers MAY deviate from a Domain Owner's published po= licy
=A0 =A0during message processing and SHOULD make available the fact and
=A0 =A0reason of the deviation to the Domain Owner via feedback reporting.&= quot;

I read the above as "if you do not do what I say you have to provide m= e with a justification". =A0Let me rewrite the text:

=A0 "Mail Receivers deviating from a Domain Owner's published poli= cy
=A0 =A0during message processing and MUST make available the fact and
=A0 =A0reason of the deviation to the Domain Owner via feedback reporting.&= quot;

If that text is not acceptable to mail receivers the RFC 2119 SHOULD will h= ave the same effect.

SHOULD is appropriate. =A0There can be local policy reasons for not reveali= ng such details via feedback.

What I meant is that the proposal is telling mail receivers what to do. =A0= The matter is entirely a local policy issue. =A0draft-kucherawy-dmarc-base-= 00 is intended as a Standards Track document. =A0The draft is doing policy = stuff and trying to set conformance. =A0There has been previous similar eff= orts. =A0I would describe them as controversial and subject to interpretati= on. =A0I would scope the work to keep the implementation and policy parts s= eparate so that you have a tightly-written specification.

I think your change of "MAY deviate&q= uot; to "deviating" is fine, but changing MUST to SHOULD won'= t work.=A0 MUST is not appropriate because the protocol doesn't complet= ely break if you don't take the action described here, and there are ce= rtain to be operators that won't do what's specified because of a n= eed to keep internal mechanisms private.=A0 That fits SHOULD nicely.

Any standards track document "sets conformance" by= spelling out those parts that are mandatory to implement.=A0 I don't u= nderstand the objection there.



In Section 7:

=A0 "When this is done, the DNS domain name thus recorded MUST be enco= ded as an
=A0 =A0A-label, as described in Section 2.3 of [IDNA]."

The above is under "policy enforcement considerations". =A0It sho= uld be in a section discussing the DNS aspects of the specification.

Why? =A0The context is the construction of an RFC5451 header field, not som= ething about DNS.

I guess that we are reading "policy enforcement considerations" d= ifferently. =A0The context is as what you wrote above. =A0What I was sugges= ting is to separate policy from how the DMARC code is supposed to work. =A0= You could take the RFC 5451 approach to simplify the draft.


Every operational environment is diffe= rent.=A0 Some will be able to take the RFC5451 approach and some will not.= =A0 Shouldn't we provide operational advice for both cases?
=A0
=

Section 8.2 is about "Verifying External Destinations". =A0If I a= m not mistaken, IETF specifications are not about imposing a specific metho= d. =A0Section 8.2 sounds like a tutorial for the implementer instead of a d= efinition of what the "DMARC policy string" means.


I disagree; a specification is indeed about describing a specific method. = =A0Tutorials for implementers appear throughout various documents we produc= e, one of which you are working on in another working group right now. =A0:= -)

I disclaim any knowledge of any other working group. :-)

I have been reading some specifications (not mail-related) and some reviews= recently. =A0I don't think that the Internet Engineering Tooth Fairy w= ill agree with the following; sometimes a proposal specifies a method and g= ets into details which turns the proposal into a guide about a specific imp= lementation. =A0A Standards Track document is about interoperability and no= t about specifying how the implementor should do things.

This sort of protocol isn't completely dete= rministic.=A0 At various junctures, there are places where operational deci= sions get made.=A0 It strikes me that guidance when making those decisions = is a good thing, and its absence would be a bad thing.=A0 We are asked to p= rovide it more often than not.

I think it all comes down to whether separating that sort of mate= rial out into a separate document is a useful thing to do.=A0 If doing so w= ould mean an implementer needs to hop back and forth between two documents = just to get the thing running, I'd say we've done the implementer a= disservice.

I'm going to leave= the rest for now and see what you think of the next version.=A0 I think a = lot of this has been addressed, though I'm sure there will be other thi= ngs to discuss.

-MSK
--001a11c26a5ec43d1e04e0e6c32c-- From superuser@gmail.com Sun Jul 7 00:26:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E021F9E4D for ; Sun, 7 Jul 2013 00:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0BYuB+l6cZo for ; Sun, 7 Jul 2013 00:25:55 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDAB21F8C66 for ; Sun, 7 Jul 2013 00:25:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3108760wiw.7 for ; Sun, 07 Jul 2013 00:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cYeZTSIEjYvRNeGEOdAISgCEJDENbwnN3AyvPT1+9CU=; b=Y98gNoCWyRTRzj1O07uwXa44yZF3E4U7E0rkGJ4FQLKtuS9TBZ19gWU0yMWclSwvP8 RgWRkxZN6tUjkkHfATxDiPQd1NGSoBwQkZw+lEw0t4NTPutqfQx1BVtuJt2pb6ddKeXq rz/v+++bRE8H+tmaRgw4mcz2Df5PNtPHMxng43l8bTgRfivvNJrxQczxvwbVRZ1nKGmx lYBNIAyLmO6/UoUdET5GB+4yj/idSUv/6WlEVkGXVauV69G5sg3VjLKniJO8VVZyzb1B pH2ofuhFLiI1A4HOqrAhojD4Jq+rM/hCG6Q5wicPfz91HYO3yRUIZMIrgNBN3YnlzWhJ L+Cg== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr9195427wic.19.1373181954272; Sun, 07 Jul 2013 00:25:54 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 7 Jul 2013 00:25:54 -0700 (PDT) In-Reply-To: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> Date: Sun, 7 Jul 2013 00:25:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c3436a98b40d04e0e6d613 Cc: SM , "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:26:00 -0000 --001a11c3436a98b40d04e0e6d613 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 6, 2013 at 11:04 PM, Murray S. Kucherawy wrote: > On Sat, Jul 6, 2013 at 10:50 AM, Dave Crocker wrote: > >> So in looking these over, I find myself liking the phrase "deceptively >> similar". Hence I'll propose: >> >> A cousin domain is a registered domain name that is deceptively >> similar to a target domain name. The target domain is familiar to many >> end-users, and therefore imparts a degree of trust. The deceptive >> similarity can trick the user by embedding the essential parts of the >> target name, in a new string, or it can use some variant of the target >> name, such as replacing 'i' with '1'. >> >> > Seems a reasonable starting point. Might also include a reference to > "homograph (literally, one appearance) attack". > > How's this, if you'll pardon the XML? A registered domain name that is deceptively similar to a target name, which can be a domain name or the name of a known entity. The target name is familiar to many end-users, and therefore imparts a degree of trust. The deceptive similarity can trick the user by embedding the essential parts of the target name in a new string (e.g., "companysecurity.example" to attack "company.example"), or it can use some variant of the target name, such as replacing 'i' with '1'. This latter form is sometimes known as a "homograph attack". --001a11c3436a98b40d04e0e6d613 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 11:04 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Sat, Jul 6, 2013 at 10:50 AM, Dave Crocker &= lt;dcrocker@gmail.c= om> wrote:
So in looking these over,= I find myself liking the phrase "deceptively similar". =A0Hence = I'll propose:

=A0 =A0 =A0A cousin domain is a registered domain name that is deceptively = similar to a target domain name. =A0The target domain is familiar to many e= nd-users, and therefore imparts a degree of trust. =A0The deceptive similar= ity can trick the user by embedding the essential parts of the target name,= in a new string, or it can use some variant of the target name, such as re= placing 'i' with '1'.


Seems a reasonable= starting point.=A0 Might also include a reference to "homograph (lite= rally, one appearance) attack".


= How's this, if you'll pardon the XML?

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <t hangText=3D"Cousin Domain:&= quot;> A registered domain name that=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is de= ceptively similar to a target name, which can be a=A0=A0
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 domain name or th= e name of a known entity.=A0 The target
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 name is familiar to many end-users,= and therefore
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 impar= ts a degree of trust.=A0 The deceptive similarity can=A0
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 trick the user by= embedding the essential parts of the=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 target name in a new string (= e.g.,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "= ;companysecurity.example" to attack "company.example"),=A0= =A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 or it can use some variant of the target name, such as=A0=A0=A0
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 replacin= g 'i' with '1'.=A0 This latter form is sometimes=A0=A0=A0 <= br> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 known= as a "homograph attack".=A0 </t>=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


--001a11c3436a98b40d04e0e6d613-- From matt@tnpi.net Sun Jul 7 19:25:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6C21F9C0A for ; Sun, 7 Jul 2013 19:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X5ivGtf7UA7S for ; Sun, 7 Jul 2013 19:25:17 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3CC21F9BF9 for ; Sun, 7 Jul 2013 19:25:16 -0700 (PDT) Received: (qmail 72956 invoked by uid 1026); 8 Jul 2013 02:25:15 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Sun, 07 Jul 2013 22:25:15 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=37AKylXWj2C0NW8NhXbEFC+ELs2hofJ49br4JGiADKE=; b=yDXQfimpE9WgNiVhS1zJWIFuw3YIvlUF6M5NYBzzHqB//eUasXrkIaP0IQM9xLBW+OGU0P6BT4Mj8jA/vk7tU3PWJlR73ec/Gw4YOviPvZKMIep8rmKAe4Iwu8yy6HqfYgWwVqMoIlk/I1OqVXDXKxlS34Z8Bc12WZjjUNehs3EWNpz86lHjQus23M6KxEUDOX1x7J9QjgNHPoaYBlnwY26BclX1puDzMZHku767gKKi018ewrIijcfDdLSXKv/wlWterXAthIesZRC+bSNTwNurf4ix0xldFaOpIr3Y0veHYK1TIEXnmaJMU1t9E2iO6LHZUAHqesUJu2Zw2fKSfA== X-HELO: [10.0.1.32] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: Date: Sun, 7 Jul 2013 19:25:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: Dave Crocker , SM , "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 02:25:22 -0000 On Jul 7, 2013, at 12:25 AM, "Murray S. Kucherawy" = wrote: > How's this, if you'll pardon the XML? >=20 > A registered = domain name that =20 > is deceptively similar to a target name, which = can be a =20 > domain name or the name of a known entity. = The entity target > name is familiar to many end-users, and = therefore=20 > imparts a degree of trust. The deceptive = similarity can =20 > trick the user by embedding the essential = parts of the =20 > target entity name in a new string (e.g.,=20 > "companysecurity.example" to attack = "company.example"), =20 > or it can use some variant of the target = entity name, such as =20 > replacing 'i' with '1'. This latter form is = sometimes =20 > known as a "homograph attack". = =20 I simplified the description by removing the 'target' abstraction. There = are legitimate purposes for cousin domains, such as helping poor = spellers and heading off typosquatting.=20 I don't think the distinction of end-users is helpful. It implies that = some class of users are not susceptible to cousin domain attacks. = There's ample evidence that is not the case.=20 Matt From matt@tnpi.net Sun Jul 7 19:27:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E385921F9F04 for ; Sun, 7 Jul 2013 19:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IdbKsxx3stRp for ; Sun, 7 Jul 2013 19:27:24 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id D79B521F9D3E for ; Sun, 7 Jul 2013 19:27:23 -0700 (PDT) Received: (qmail 73458 invoked by uid 1026); 8 Jul 2013 02:27:23 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Sun, 07 Jul 2013 22:27:23 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=mar2013; bh=zU6/BtH7XONnZP2I6U0PSeZXxUPkkoT7QEHEArUh5WE=; b=GyyDZigF/RBeZolKDkOUFGotZ+tjZWydjP6SKWERyJX8vFIzmZOB2iMIXkAgU5kNxvOxDlJUOLzyUvvUwKPXBeQ1O/9PTCeQbtiTUleF3qqyiOiL4a4SCcVo6OAuDbs0XhCVfhbLfdyof5S0ANOq6ka2IcDWdb4PSP3BO5lIlJzg2UjU+6102/7VGhEAdx5a1nrSrDH6J+BAMuqCa8MF4qDorcOu19y+Ya22hzuIVfPv5UrkBQgV1cyhl41Zk+GhHxREAFfSndMFAjf5qf8QbN/uV/FkBVAcAG8ZPSSq2nSDlSC2vmmcFOhAKSlFqdZUStWSZ8kKEO33WnzrX9Q84A== X-HELO: [10.0.1.32] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: Date: Sun, 7 Jul 2013 19:27:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11ACB6D3-2A24-4813-AEF8-5DF52208FB3C@tnpi.net> References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: Dave Crocker , SM , "dmarc@ietf.org" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 02:27:28 -0000 Oh humbug, the formatting was stripped out. A registered domain name that =20 is deceptively similar the name of a known = entity. The entity name is familiar to users and therefore=20 imparts a degree of trust. The deceptive = similarity can =20 trick the user by embedding the essential parts = of the =20 entity name in a new string (e.g.,=20 "companysecurity.example" to attack = "company.example"), =20 or it can use some variant of the entity name, = such as=20 replacing 'i' with '1'. This latter form is = sometimes =20 known as a "homograph attack". =20 On Jul 7, 2013, at 7:25 PM, Matt Simerson wrote: > On Jul 7, 2013, at 12:25 AM, "Murray S. Kucherawy" = wrote: >=20 >> How's this, if you'll pardon the XML? >>=20 >> =20 >=20 > I simplified the description by removing the 'target' abstraction. = There are legitimate purposes for cousin domains, such as helping poor = spellers and heading off typosquatting.=20 >=20 > I don't think the distinction of end-users is helpful. It implies that = some class of users are not susceptible to cousin domain attacks. = There's ample evidence that is not the case.=20 >=20 > Matt >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From dcrocker@gmail.com Sun Jul 7 23:22:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8A511E8199 for ; Sun, 7 Jul 2013 23:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U9PlMBq+Yba for ; Sun, 7 Jul 2013 23:22:04 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF3611E8193 for ; Sun, 7 Jul 2013 23:22:03 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so5795663oag.23 for ; Sun, 07 Jul 2013 23:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zX1WZXLk3jsa++BRh6zp+yuEtaSe4F02lfucgMK90Xs=; b=eLOfI6j+czdjZUrIQUeLGFd3bXeBpNO74/Q7MjG/cMvmatjKPVWOI8+NJeDhY+iNj+ q6nCdGj9itk23V16PBj6fgPqEV9ewWu48CFUJa+e25W1f5j+iiA07o8tzD/5Wpeu9LKq 2n2Ja9mvTVr6yTP1dk0ZbSQgVSwhhdpGzYHnpzseg2oG1uX9jJop/Gwq6rAAilDypEfP vigPo9Vn/9kO18iuVj4X37yMRvgqb0TgE3YAx7akEsqQ+/M5/EW1N75eLyd0xfEiTEVr SNBcR6jhT3ctf7mGxKgr0T65RZAGZKJDQMxZUAuCYq2UX2cQxZyvsH/J26JAw+edhfil tL3Q== X-Received: by 10.60.138.137 with SMTP id qq9mr19173415oeb.8.1373264522502; Sun, 07 Jul 2013 23:22:02 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id el16sm31922731oeb.2.2013.07.07.23.22.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 23:22:01 -0700 (PDT) Message-ID: <51DA5A75.4020307@gmail.com> Date: Sun, 07 Jul 2013 23:21:41 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Matt Simerson References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> <11ACB6D3-2A24-4813-AEF8-5DF52208FB3C@tnpi.net> In-Reply-To: <11ACB6D3-2A24-4813-AEF8-5DF52208FB3C@tnpi.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 06:22:05 -0000 On 7/7/2013 7:27 PM, Matt Simerson wrote: > A registered domain name that > is deceptively similar the name of a known entity. The entity > name is familiar to users and therefore > imparts a degree of trust. The deceptive similarity can > trick the user by embedding the essential parts of the > entity name in a new string (e.g., > "companysecurity.example" to attack "company.example"), > or it can use some variant of the entity name, such as > replacing 'i' with '1'. This latter form is sometimes > known as a "homograph attack". > > On Jul 7, 2013, at 7:25 PM, Matt Simerson wrote: >> On Jul 7, 2013, at 12:25 AM, "Murray S. Kucherawy" wrote: >>> How's this, if you'll pardon the XML? >> I simplified the description by removing the 'target' abstraction. There are legitimate purposes for cousin domains, such as helping poor spellers and heading off typosquatting. >> >> I don't think the distinction of end-users is helpful. It implies that some class of users are not susceptible to cousin domain attacks. There's ample evidence that is not the case. I think the distinction between domain names and other kinds of names can be useful to make explicitly. The use of 'target' is needed for referential disambiguation between the attacker's domain name and the one that is the basis for the attack. However I do think "end-" isn't as helpful as I had intended; so 'users' should suffice. Hence a few more tweaks: A registered domain name that is deceptively similar to a target domain name or other name of a known entity. The target name is familiar to many users, and therefore imparts a degree of trust. The deceptive similarity can trick the user by embedding the essential parts of the target name in a new string (such as, "companysecurity.example" to attack "company.example"), or it can use some variant of the target name, such as replacing 'i' with '1', which is known as a "homograph attack". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From MHammer@ag.com Mon Jul 8 05:54:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119A221F85B3 for ; Mon, 8 Jul 2013 05:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq5NL61CdcHU for ; Mon, 8 Jul 2013 05:54:45 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2521F85B2 for ; Mon, 8 Jul 2013 05:54:44 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 08:54:43 -0400 From: "MH Michael Hammer (5304)" To: Elizabeth Zwicky , Dave Crocker , Matt Simerson Thread-Topic: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) Thread-Index: AQHOeniLl550DQeef0eSVgi0uIx72plYQgIAgAJ9JPA= Date: Mon, 8 Jul 2013 12:54:42 +0000 Message-ID: References: <51D864EC.1040105@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SM , "dmarc@ietf.org" , "Murray S. Kucherawy" , Eliot Lear Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:54:49 -0000 I don't think it is just that the target domain is familiar to the users un= der attack. It is the "brand identity". That is, the users under attack may= be familiar with the brand but not necessarily familiar with the exact dom= ain that the brand/organization uses. Mike > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Elizabeth Zwicky > Sent: Saturday, July 06, 2013 2:52 PM > To: Dave Crocker; Matt Simerson > Cc: SM; dmarc@ietf.org; Murray S. Kucherawy; Eliot Lear > Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's > review of the DMARC spec) >=20 >=20 > I would say that the target domain is familiar to the users under attack. >=20 > Elizabeth >=20 > On 7/6/13 11:41 AM, "Dave Crocker" wrote: >=20 > >Thanks for the quick feedback. > > > >some additional thoughts... > > > > > >On 7/6/2013 11:18 AM, Matt Simerson wrote: > >>> A cousin domain is a registered domain name that is deceptively > >>> similar to a target domain name. The target domain is *usually > >>> *familiar to many end-users, and therefore imparts a degree of trust. > >>> The deceptive similarity can trick the user by embedding the > >>> essential parts of the target name, in a new string, or it can use > >>> some variant of the target name, such as replacing 'i' with '1'. > >> > >> I inserted the word 'usually'. > > > >That's a kind of careful phrasing that makes sense for precise > >specification, but I think is actually distracting for the usage here. > > > >That is, I think that extra qualifiers in definitions are, ummmm... > >usually distracting... > > > >It's not that it's wrong; it's that I doubt it's as helpful as we'd like= . > > > > > >> In addition to providing basic examples, perhaps include the well > >> defined and recognized terms: typosquatting, and IDN homographs? > >> > >> https://en.wikipedia.org/wiki/Typosquatting > >> https://en.wikipedia.org/wiki/IDN_homograph_attack > > > >yeah, and probably cite the dhs.gov text, to show some history to the > >key phrase. > > > >d/ > > > > > >-- > >Dave Crocker > >Brandenburg InternetWorking > >bbiw.net > >_______________________________________________ > >dmarc mailing list > >dmarc@ietf.org > >https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From steven.m.jones@gmail.com Mon Jul 8 14:04:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7648621F9E34 for ; Mon, 8 Jul 2013 14:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8Sctze84Yh for ; Mon, 8 Jul 2013 14:04:54 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ABE1F21F9E2D for ; Mon, 8 Jul 2013 14:04:52 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so10937449iec.19 for ; Mon, 08 Jul 2013 14:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LZmWGGbE9jFkbqIeYEDDMsio8MhNBq3comjxRCipxRs=; b=F4kkYa69O5u4vEhoEkDZvTDwSyZm5w+2nd60zvDgvEFECznxJlWwHwAOzLE/w/+LdK OCwXVQQOcWHf7psAzkbx7whf6gPNT4CJSNbbr7+HyUqZma64PB5Q5GrmWTAj6MXp6TPv 2Dgv6HTyJ0E7ATYtkEosCwTqEduZrv7CNoNrCPYIJYQ8NqauiFaV0MV/N/XiXmuC0JlJ AQ6e6CTYv8LTNAHRwehwaCVTZOy82gS+Bd/fSVG7Ua3fqf5VH7tDE2eYIwaJ/xWXU2C7 pohC69W76vAjzZ8LTDOhGjsVFI4dz8KJfgcBRbMIqjCCH0MnLPUznUyUqe6RyYXmgFkk J/OQ== MIME-Version: 1.0 X-Received: by 10.50.13.72 with SMTP id f8mr4394316igc.53.1373317492089; Mon, 08 Jul 2013 14:04:52 -0700 (PDT) Received: by 10.50.127.200 with HTTP; Mon, 8 Jul 2013 14:04:51 -0700 (PDT) In-Reply-To: References: <51D864EC.1040105@gmail.com> Date: Mon, 8 Jul 2013 14:04:51 -0700 Message-ID: From: Steve Jones To: "MH Michael Hammer (5304)" Content-Type: multipart/alternative; boundary=089e013c65de47abe004e10665fb Cc: Dave Crocker , Matt Simerson , Eliot Lear , "dmarc@ietf.org" , "Murray S. Kucherawy" , SM , Elizabeth Zwicky Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:04:55 -0000 --089e013c65de47abe004e10665fb Content-Type: text/plain; charset=ISO-8859-1 Do we have other definitions to cover deceptive names not similar to an existing domain? If phishers are using CraftsmanOnline.com, and Sears using other domains, is that a cousin domain or do we need a different term? If it is considered a cousin domain because it plays on a known entity name or brand identity... A domain name that is deceptively similar to a registered domain name or other name associated with a known entity. The target name may be familiar to many users, thereby imparting a degree of trust. The deceptive similarity can trick the user by embedding the essential parts of the target name in a new string (such as, "companysecurity.example" to attack "company.example"); it can use some variant of the target name, such as replacing 'i' with '1', which is known as a "homograph attack;" or it may invent a plausible domain name based on the common name of a known entity or brand, such as "BrandAOnline.example," where the entity actually uses other domain names such as "xyzcorp.example." On Mon, Jul 8, 2013 at 5:54 AM, MH Michael Hammer (5304) wrote: > I don't think it is just that the target domain is familiar to the users > under attack. It is the "brand identity". That is, the users under attack > may be familiar with the brand but not necessarily familiar with the exact > domain that the brand/organization uses. > > Mike > > > -----Original Message----- > > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > > Of Elizabeth Zwicky > > Sent: Saturday, July 06, 2013 2:52 PM > > To: Dave Crocker; Matt Simerson > > Cc: SM; dmarc@ietf.org; Murray S. Kucherawy; Eliot Lear > > Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's > > review of the DMARC spec) > > > > > > I would say that the target domain is familiar to the users under attack. > > > > Elizabeth > > > > On 7/6/13 11:41 AM, "Dave Crocker" wrote: > > > > >Thanks for the quick feedback. > > > > > >some additional thoughts... > > > > > > > > >On 7/6/2013 11:18 AM, Matt Simerson wrote: > > >>> A cousin domain is a registered domain name that is deceptively > > >>> similar to a target domain name. The target domain is *usually > > >>> *familiar to many end-users, and therefore imparts a degree of trust. > > >>> The deceptive similarity can trick the user by embedding the > > >>> essential parts of the target name, in a new string, or it can use > > >>> some variant of the target name, such as replacing 'i' with '1'. > > >> > > >> I inserted the word 'usually'. > > > > > >That's a kind of careful phrasing that makes sense for precise > > >specification, but I think is actually distracting for the usage here. > > > > > >That is, I think that extra qualifiers in definitions are, ummmm... > > >usually distracting... > > > > > >It's not that it's wrong; it's that I doubt it's as helpful as we'd > like. > > > > > > > > >> In addition to providing basic examples, perhaps include the well > > >> defined and recognized terms: typosquatting, and IDN homographs? > > >> > > >> https://en.wikipedia.org/wiki/Typosquatting > > >> https://en.wikipedia.org/wiki/IDN_homograph_attack > > > > > >yeah, and probably cite the dhs.gov text, to show some history to the > > >key phrase. > > > > > >d/ > > > > > > > > >-- > > >Dave Crocker > > >Brandenburg InternetWorking > > >bbiw.net > > >_______________________________________________ > > >dmarc mailing list > > >dmarc@ietf.org > > >https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e013c65de47abe004e10665fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do we have other definitions to cover deceptive names= not similar to an existing domain? If phishers are using CraftsmanOnline.c= om, and Sears using other domains, is that a cousin domain or do we need a = different term?

If it is considered a cousin domain because it plays on a kn= own entity name or brand identity...

<t hangText=3D"Cousin Domain:"> A domain name that= is
=A0 =A0 =A0deceptively similar to a registered domain name or other name=A0=A0=A0=A0 associated with a known entity. =A0The target name may be fam= iliar to
=A0=A0=A0=A0 many users, thereby imparting a degree of trust. T= he deceptive similarity can
=A0 =A0 =A0trick the user by embedding the essential parts of the target na= me
=A0 =A0 =A0in a new string (such as, "companysecurity.example" to= attack
=A0 =A0=A0 "company.example"); it can use some variant of the tar= get name,
=A0 =A0 =A0such as replacing 'i' with '1', which is known a= s a "homograph
=A0 =A0 =A0attack;" or it may invent a plausible domain name based on = the
=A0=A0=A0=A0 common name of a known entity or brand, such= as "BrandAOnline.example,"
=A0=A0=A0=A0 where the entity actu= ally uses other domain names such as
=A0=A0=A0=A0 "xyzcorp.example."
</t>


On Mon, Jul 8, 2= 013 at 5:54 AM, MH Michael Hammer (5304) <MHammer@ag.com> wrote= :
I don't think it is just that the target= domain is familiar to the users under attack. It is the "brand identi= ty". That is, the users under attack may be familiar with the brand bu= t not necessarily familiar with the exact domain that the brand/organizatio= n uses.

Mike

> -----Original Message-----
> From: dmarc-bounces@ietf.org= [mailto:dmarc-bounces@ietf.o= rg] On Behalf
> Of Elizabeth Zwicky
> Sent: Saturday, July 06, 2013 2:52 PM
> To: Dave Crocker; Matt Simerson
> Cc: SM; dmarc@ietf.org; Murray S= . Kucherawy; Eliot Lear
> Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot= 's
> review of the DMARC spec)
>
>
> I would say that the target domain is familiar to the users under atta= ck.
>
> =A0 =A0 =A0 Elizabeth
>
> On 7/6/13 11:41 AM, "Dave Crocker" <dcrocker@gmail.com> wrote:
>
> >Thanks for the quick feedback.
> >
> >some additional thoughts...
> >
> >
> >On 7/6/2013 11:18 AM, Matt Simerson wrote:
> >>> =A0 =A0 A cousin domain is a registered domain name that = is deceptively
> >>> similar to a target domain name. =A0The target domain is = *usually
> >>> *familiar to many end-users, and therefore imparts a degr= ee of trust.
> >>> =A0The deceptive similarity can trick the user by embeddi= ng the
> >>> essential parts of the target name, in a new string, or i= t can use
> >>> some variant of the target name, such as replacing 'i= ' with '1'.
> >>
> >> I inserted the word 'usually'.
> >
> >That's a kind of careful phrasing that makes sense for precise=
> >specification, but I think is actually distracting for the usage h= ere.
> >
> >That is, I think that extra qualifiers in definitions are, ummmm..= .
> >usually distracting...
> >
> >It's not that it's wrong; it's that I doubt it's a= s helpful as we'd like.
> >
> >
> >> In addition to providing basic examples, perhaps include the = well
> >> defined and recognized terms: typosquatting, and IDN homograp= hs?
> >>
> >> https://en.wikipedia.org/wiki/Typosquatting
> >> https://en.wikipedia.org/wiki/IDN_homograph_attack<= br> > >
> >yeah, and probably cite the dhs.gov text, to show some history to the
> >key phrase.
> >
> >d/
> >
> >
> >--
> >Dave Crocker
> >Brandenburg InternetWorking
> >bbiw.net
> >_______________________________________________
> >dmarc mailing list
> >dmarc@ietf.org
> >https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e013c65de47abe004e10665fb-- From barryleiba.mailing.lists@gmail.com Mon Jul 8 14:12:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7221F9DFB for ; Mon, 8 Jul 2013 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 HUs7WtVDnMv7 for ; Mon, 8 Jul 2013 14:12:27 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD421F9DB0 for ; Mon, 8 Jul 2013 14:12:27 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so4029855vea.15 for ; Mon, 08 Jul 2013 14:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IPuUTFQLVnbXlx5Su1QosJpRW6RNToJcxa+4HSRLh18=; b=hy509eJujr7KtGzj/wbmaTS8ftFE1/dmgRZvpDeBeHB326zSedBdef74JjWvjzkUat rc3kJ8svKpHI59hIJ5eqrmOgbiXkppSmZqO5bvsm3dRkI69MkXjrOW0Z4Zkogt3/6uPJ oqytLp5bvWi0fJhvAkxfoOCYCLqXy6m3+RXNq4o38J9QlOGCIl4sN5nG97sPBImEHOmS Qs7qXawE2NdV61BmND14FvT12l2qh0R3tiGhXogujuR2rxEsKAQ6+kXbyQrZlTzK5x34 wk4nj92ia+g22j+sHxeGTELFXocj4nu1q/VvyCY6gUKXBNFx3PjbK8ZompD2+CbtvPKM uK1g== MIME-Version: 1.0 X-Received: by 10.220.44.195 with SMTP id b3mr14855634vcf.62.1373317946835; Mon, 08 Jul 2013 14:12:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Mon, 8 Jul 2013 14:12:26 -0700 (PDT) In-Reply-To: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> Date: Mon, 8 Jul 2013 17:12:26 -0400 X-Google-Sender-Auth: ftk0o2qX0sUK7A8VqYoFVWRjajM Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:12:28 -0000 > How's this, if you'll pardon the XML? > > A registered domain name that > is deceptively similar to a target name, which can be a > domain name or the name of a known entity. The target > name is familiar to many end-users, and therefore > imparts a degree of trust. The deceptive similarity can > trick the user by embedding the essential parts of the > target name in a new string (e.g., > "companysecurity.example" to attack "company.example"), > or it can use some variant of the target name, such as > replacing 'i' with '1'. This latter form is sometimes > known as a "homograph attack". If it's not too late to change the term "cousin domain" for this, I suggest finding another term. "Cousin" implies a legitimate relation, which this isn't. I would consider, say, "ibm.com" and "lotus.com" to be cousin domains. I might consider "microsoft.com", "hotmail.com", and "skype.com" to be cousin domains. Things that try to look like they're related, but *aren't*, are what we're talking about here, and I don't think of those as cousins. Barry From sklist@kitterman.com Mon Jul 8 14:16:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05D21F9E2B for ; Mon, 8 Jul 2013 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLrnnYUTYPRK for ; Mon, 8 Jul 2013 14:16:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1B21F941D for ; Mon, 8 Jul 2013 14:16:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B22FB20E40C7; Mon, 8 Jul 2013 17:16:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373318171; bh=acUtea0e795MrVU5rgkBc3LfM4QxWrRO9TEXApAmIEo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q4rgfs/H8zj9sv8oBvaWU3wyfZv6jS1REXNY7PHY10iSrDHtdVgjw7lJq3DRNZIkf CWF+yjJvTqWv4s+ButQmXyVsxNLWy9myePEW4/0LKaqZzUePs6m0mXw3O/Y9jeaVxS QXSA/1k7uiI2OYuP1XFgCN735PvLM6D3BAYBuzGk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 92F7920E4099; Mon, 8 Jul 2013 17:16:11 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 08 Jul 2013 17:16:10 -0400 Message-ID: <4065872.gHmrjURumF@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-26-generic; KDE/4.10.4; i686; ; ) In-Reply-To: References: <519B47DC.20008@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:16:24 -0000 On Monday, July 08, 2013 05:12:26 PM Barry Leiba wrote: > > How's this, if you'll pardon the XML? > > > > A registered domain name that > > > > is deceptively similar to a target name, which can be a > > domain name or the name of a known entity. The target > > name is familiar to many end-users, and therefore > > imparts a degree of trust. The deceptive similarity can > > trick the user by embedding the essential parts of the > > target name in a new string (e.g., > > "companysecurity.example" to attack "company.example"), > > or it can use some variant of the target name, such as > > replacing 'i' with '1'. This latter form is sometimes > > known as a "homograph attack". > > If it's not too late to change the term "cousin domain" for this, I > suggest finding another term. "Cousin" implies a legitimate relation, > which this isn't. I would consider, say, "ibm.com" and "lotus.com" to > be cousin domains. I might consider "microsoft.com", "hotmail.com", > and "skype.com" to be cousin domains. Things that try to look like > they're related, but *aren't*, are what we're talking about here, and > I don't think of those as cousins. Doppelganger domains. Scott K From steven.m.jones@gmail.com Mon Jul 8 14:17:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7E621F9E34 for ; Mon, 8 Jul 2013 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvcbMN+552c4 for ; Mon, 8 Jul 2013 14:17:27 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACDE21F941D for ; Mon, 8 Jul 2013 14:17:27 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so11365248ieb.10 for ; Mon, 08 Jul 2013 14:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RMizM031CIl5rVZuAszz7sv+EwDdNbEBjSujbfXivlU=; b=r/M7MWC7ARwu3aeXGLss9w5Uvdka459pqqY2QbGsWNz74ylwiCFEOYJkIe1ERWqsE5 N8MiZdH5fVd9ieBVmE6Kp80kSl08un5hU+EttS2SIvBbLz+Xjp57m0G9yu35/ltHaVQE v5DE0D5D1au3QWP5wEmta4dVUB2E37VWTRIqmoLHNKcttJ0VxSICA9EaTAfJZ6zWDjb5 vVPlaIBj66F1TF4n49lVFYH16e7Nk9Xdg+wa5hdRQUONs7KlPRw1vE43Pojps/IK2gZg nOoY2nXMPdYRIwIB2lOr4z+PZjEKdbT5f7U/T0wew04p0UPGCizZQD8uO12UHZ/aNi09 Cv3g== MIME-Version: 1.0 X-Received: by 10.50.3.103 with SMTP id b7mr32546157igb.54.1373318246004; Mon, 08 Jul 2013 14:17:26 -0700 (PDT) Received: by 10.50.127.200 with HTTP; Mon, 8 Jul 2013 14:17:25 -0700 (PDT) In-Reply-To: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> Date: Mon, 8 Jul 2013 14:17:25 -0700 Message-ID: From: Steve Jones To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013c61e038288604e1069208 Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:17:28 -0000 --089e013c61e038288604e1069208 Content-Type: text/plain; charset=ISO-8859-1 Interesting point - is there a small monograph on the taxonomy of deceptive domain names kicking around out there? Could we split one off and forward reference? On Mon, Jul 8, 2013 at 2:12 PM, Barry Leiba wrote: > > How's this, if you'll pardon the XML? > > > > A registered domain name that > > is deceptively similar to a target name, which can be a > > domain name or the name of a known entity. The target > > name is familiar to many end-users, and therefore > > imparts a degree of trust. The deceptive similarity can > > trick the user by embedding the essential parts of the > > target name in a new string (e.g., > > "companysecurity.example" to attack "company.example"), > > or it can use some variant of the target name, such as > > replacing 'i' with '1'. This latter form is sometimes > > known as a "homograph attack". > > If it's not too late to change the term "cousin domain" for this, I > suggest finding another term. "Cousin" implies a legitimate relation, > which this isn't. I would consider, say, "ibm.com" and "lotus.com" to > be cousin domains. I might consider "microsoft.com", "hotmail.com", > and "skype.com" to be cousin domains. Things that try to look like > they're related, but *aren't*, are what we're talking about here, and > I don't think of those as cousins. > > Barry > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e013c61e038288604e1069208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Interesting point - is there a small monograph on the taxo= nomy of deceptive domain names kicking around out there? Could we split one= off and forward reference?


On Mon, Jul 8, 2013 at 2:12 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
> How's this, if you'll pardon the XML?
>
> =A0<t hangText=3D"Cousin Domain:"> A registered domain= name that
> =A0 =A0 =A0is deceptively similar to a target name, which can be a
> =A0 =A0 =A0domain name or the name of a known entity. =A0The target > =A0 =A0 =A0name is familiar to many end-users, and therefore
> =A0 =A0 =A0imparts a degree of trust. =A0The deceptive similarity can<= br> > =A0 =A0 =A0trick the user by embedding the essential parts of the
> =A0 =A0 =A0target name in a new string (e.g.,
> =A0 =A0 =A0"companysecurity.example" to attack "company= .example"),
> =A0 =A0 =A0or it can use some variant of the target name, such as
> =A0 =A0 =A0replacing 'i' with '1'. =A0This latter form= is sometimes
> =A0 =A0 =A0known as a "homograph attack". =A0</t>

If it's not too late to change the term "cousin domain"= for this, I
suggest finding another term. =A0"Cousin" implies a legitimate re= lation,
which this isn't. =A0I would consider, say, "ibm.com" and "lotus.com" to
be cousin domains. =A0I might consider "microsoft.com", "hotmail.com",
and "skype.com"= ; to be cousin domains. =A0Things that try to look like
they're related, but *aren't*, are what we're talking about her= e, and
I don't think of those as cousins.

Barry
_____________________= __________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e013c61e038288604e1069208-- From matt@tnpi.net Tue Jul 9 16:35:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9374D21F943C for ; Tue, 9 Jul 2013 16:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjdUnE2AR1QT for ; Tue, 9 Jul 2013 16:35:55 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAFD11E80C5 for ; Tue, 9 Jul 2013 16:35:55 -0700 (PDT) Received: (qmail 28729 invoked by uid 1026); 9 Jul 2013 23:35:51 -0000 Received: from c-76-121-98-64.hsd1.wa.comcast.net (HELO [10.0.1.32]) (76.121.98.64) by mail.theartfarm.com (qpsmtpd/0.93) with (AES128-SHA encrypted) ESMTPSA; Tue, 09 Jul 2013 19:35:51 -0400 Authentication-Results: mail.theartfarm.com; auth=pass (plain) smtp.auth=matt@theartfarm.com; iprev=pass X-Virus-Checked: by ClamAV 0.97.8 on mail.theartfarm.com X-Virus-Found: No DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tnpi.net; h=content-type:mime-version:subject:from:in-reply-to:date:cc:message-id:references:to; s=mar2013; bh=gGZTTXKcp+XmegJjLDjHtT82Aw8FWAilLQZb/idCR8Y=; b=nRd1ZTGweMCjDhYCFzD9zBY8K35HHH9+3r+dp9fTO+0CLWAN2W3qJi01n0RNyJZe5EMrPwQoULORKErWw65iXnJfZAMse6xFJXf79Bdxt/OFwKYJNtpTGUUjN82fD9kSnf+5lsl5hxDhNo58KefK8dzNIaQTCUeRbdxxVLJvKHMSJA/5n7nHU76EmueIoGHnWQ31m64ZO4UfldNRIbi+Ywc57q1REdyl81lNEGfHbz2f2diL7X3q0H9dylsv6H00sF0tsBZTDDh8h7H4Gr1x2TlUN37n6YVp9ZXcUR8lk2HBiIB7yR2Lkk66vMW5jfTAK6kTMVky0nckfgfM4Cpi0A== X-HELO: [10.0.1.32] Content-Type: multipart/alternative; boundary="Apple-Mail=_D0B9C6A5-52F0-4991-AF77-A14368B5FBFE" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Matt Simerson In-Reply-To: Date: Tue, 9 Jul 2013 16:35:52 -0700 Message-Id: References: <519B47DC.20008@cisco.com> <6.2.5.6.2.20130523002139.0da7ac58@resistor.net> <51D858EB.3030202@gmail.com> To: Steve Jones X-Mailer: Apple Mail (2.1508) Cc: "dmarc@ietf.org" , Barry Leiba , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] cousin domain definition (was Re: Fwd: Eliot's review of the DMARC spec) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 23:35:59 -0000 --Apple-Mail=_D0B9C6A5-52F0-4991-AF77-A14368B5FBFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 8, 2013, at 2:17 PM, Steve Jones = wrote: > On Mon, Jul 8, 2013 at 2:12 PM, Barry Leiba = wrote: > > > > >=20 > If it's not too late to change the term "cousin domain" for this, I > suggest finding another term. "Cousin" implies a legitimate relation, New Oxford American Dictionary, cousin: =95 a person belonging to the same extended family. =95 a thing related or analogous to another: the new motorbikes = are not proving as popular as their four-wheeled cousins. Having mulled this over, including time wearing my genealogist's hat, I = heartily disagree that the term cousin implies any sense of legitimacy. = In my experience, it is uncommon for people to distinguish between = natural, step, adopted, foster, illegitimate, maternal, paternal, or = even to describe the degree of a cousin. Until further inquiry or = precision is requested, cousins are usually just cousins.=20 > which this isn't. I would consider, say, "ibm.com" and "lotus.com" to > be cousin domains. I might consider "microsoft.com", "hotmail.com", > and "skype.com" to be cousin domains. I think most anyone would accept that those are related domains. The = term "cousin domain" is already established and already conveys a sense = of illegitimacy. Adding a new term to the mix with a slightly different = meaning isn't going to help anyone, even if it is semantically more = correct.=20 > Things that try to look like they're related, but *aren't*, are what = we're talking about here, and > I don't think of those as cousins. But a cousin domain *is* related to the target domain, typically by = appearance. It's just that as you pointed out earlier, the relationship = is not legitimate.=20 Matt= --Apple-Mail=_D0B9C6A5-52F0-4991-AF77-A14368B5FBFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 8, 2013, at 2:17 PM, = Steve Jones <steven.m.jones@gmail.com> = wrote:

On Mon, Jul 8, 2013 at 2:12 PM, = Barry Leiba <barryleiba@computer.org>&nb= sp;wrote:
>
>  <t hangText=3D"Cousin Domain:"> = <snip> </t>

If it's not too late to change the = term "cousin domain" for this, I
suggest finding another term. =  "Cousin" implies a legitimate = relation,

New Oxford American = Dictionary, cousin:
=95 a person belonging to = the same extended family.
=95 a thing related or = analogous to another: the new motorbikes are = not proving as popular as their four-wheeled = cousins.

Having mulled this over, = including time wearing my genealogist's hat, I heartily disagree that = the term cousin implies any sense of legitimacy. In my experience, it is = uncommon for people to distinguish between natural, step, adopted, = foster, illegitimate, maternal, paternal, or even to describe the degree = of a cousin. Until further inquiry or precision is requested, cousins = are usually just cousins. 

which = this isn't.  I would consider, say, "ibm.com" and "lotus.com" to
be cousin = domains.  I might consider "microsoft.com", "hotmail.com",
and = "skype.com" to be cousin domains.

I = think most anyone would accept that those are related domains. = The term "cousin domain" is already established and already conveys a = sense of illegitimacy.  Adding a new term to the mix with a = slightly different meaning isn't going to help anyone, even if it is = semantically more correct. 

Things= that try to look like they're related, but *aren't*, are what = we're talking about here, and
I don't think of those as = cousins.

But a cousin domain *is* related to = the target domain, typically by appearance. It's just that as you = pointed out earlier, the relationship is not = legitimate. 

Matt
= --Apple-Mail=_D0B9C6A5-52F0-4991-AF77-A14368B5FBFE-- From housley@vigilsec.com Wed Jul 10 13:53:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5E921F9E52 for ; Wed, 10 Jul 2013 13:53:25 -0700 (PDT) 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 GVOTWrevSSdX for ; Wed, 10 Jul 2013 13:53:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4A76E21F9EAE for ; Wed, 10 Jul 2013 13:53:19 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 89F09F2407E for ; Wed, 10 Jul 2013 16:53:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id tAk3Eo7d554Y for ; Wed, 10 Jul 2013 16:53:14 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 670F99A4005 for ; Wed, 10 Jul 2013 16:53:38 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 2013 16:53:13 -0400 Message-Id: To: dmarc@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [dmarc-ietf] Draft DMARC BOF Agenda X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:53:25 -0000 We have discussed the BOF agenda, and this structure still seems to be = the right one. DMARC BOF Agenda Summary of DMARC -- Goal: Common foundation of DMARC -- Note: DMARC specification is being AD sponsored Summary of Open Issues -- Goal: What is left for a working group to do? Charter review -- Goal: Discuss the draft charter Hums -- Facilitator: Barry Leiba -- Goal: Is there adequate support for a DMARC WG? At this time, I am also calling for volunteers to take minutes and to = jabber scribe. Rus= From housley@vigilsec.com Fri Jul 12 12:54:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DCE21F9F4D for ; Fri, 12 Jul 2013 12:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 D79ficasEfff for ; Fri, 12 Jul 2013 12:53:57 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 50E7021F9F49 for ; Fri, 12 Jul 2013 12:53:57 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CBA49F240B6 for ; Fri, 12 Jul 2013 15:54:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2oxBS1jPTqUQ for ; Fri, 12 Jul 2013 15:53:43 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F643F2408B for ; Fri, 12 Jul 2013 15:54:26 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jul 2013 15:53:54 -0400 Message-Id: <300040D1-57F7-47AB-8B8F-14E68733B2B6@vigilsec.com> To: dmarc@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 19:54:03 -0000 Dear DMARC Mail List Participants: I have already posted a Draft Agenda for the DMARC BOF. That includes a = discussion of the draft working group charter. The closer we can get to = consensus on this mail list before the BOF, the more likely that we can = get a working group shortly after Berlin. To this end, I want to start = a discussion of the charter. Trent Adams has agree to lead the discussion of the charter during the = BOF, so I am passing him the pen for the draft charter. Russ From jtrentadams@gmail.com Fri Jul 12 13:55:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9321F9F3D for ; Fri, 12 Jul 2013 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VWso1ad+KHx for ; Fri, 12 Jul 2013 13:55:15 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44B21F9F42 for ; Fri, 12 Jul 2013 13:55:13 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so21338143iec.19 for ; Fri, 12 Jul 2013 13:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Lsi7qkj6ZrsG/ei9xKYQOjmHvT4Fu76fXte8Fbi3JdI=; b=uaw5CTsOEaOel6ofv+O74xPd/QP56KU8On8UGkTFWSRUvNTUkqGIqc3qsgICqqlsDN 9fqGqI/zSev8YWkgkJQVsfl14U7W95jk9b7EZcyodSch0+suGnhjemOu1jQSqkXhb6vN 9S6BhcvFZx//y5ML8tuz5aNIikrpFRFvsnJLIkXu/PSAUYMSEGsiWBXu6qKLUYRH+dJB xJ2jsXeBw72syCszKvWc0XbeNsNapfLBsJ6zhEzvRKBklawBdD/r3NpvyusbqhhCw2/d CZ6xoCvTfe70rmhYNJdmvZ52o93i34HpOzmURnkHG1YvzzMcflYw1U9NXGhTwe10G2Dg 6ilQ== X-Received: by 10.50.85.114 with SMTP id g18mr1511653igz.14.1373662511928; Fri, 12 Jul 2013 13:55:11 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id ht10sm1616536igb.2.2013.07.12.13.55.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 13:55:11 -0700 (PDT) Message-ID: <51E06D2E.9060709@gmail.com> Date: Fri, 12 Jul 2013 14:55:10 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmarc@ietf.org References: <300040D1-57F7-47AB-8B8F-14E68733B2B6@vigilsec.com> In-Reply-To: <300040D1-57F7-47AB-8B8F-14E68733B2B6@vigilsec.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:55:16 -0000 As a reminder, here's a link to the most recent version of the proposed charter: http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC Any and all comments welcome, the more specific you can be the better. Thanks, Trent On 7/12/13 1:53 PM, Russ Housley wrote: > Dear DMARC Mail List Participants: > > I have already posted a Draft Agenda for the DMARC BOF. That includes a discussion of the draft working group charter. The closer we can get to consensus on this mail list before the BOF, the more likely that we can get a working group shortly after Berlin. To this end, I want to start a discussion of the charter. > > Trent Adams has agree to lead the discussion of the charter during the BOF, so I am passing him the pen for the draft charter. > > Russ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From jtrentadams@gmail.com Fri Jul 12 14:09:34 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3495421F9F34 for ; Fri, 12 Jul 2013 14:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJdh+npKMkHS for ; Fri, 12 Jul 2013 14:09:33 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7718D21F9ECA for ; Fri, 12 Jul 2013 14:09:30 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so21885123iej.15 for ; Fri, 12 Jul 2013 14:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=oJe+tnMyWUt3AGlIiedU+GLsp5YhD12zFH0J5KIH5FM=; b=Ec6nLb4VW5mBf5+hktBxJAyYErj1NdBACeMPTF8gDVGF1bCL5HxfpLUEol3Iy536uA XmliygAtW9p7IgtcGe8AG6zipoc4tx2anKNn9MFegeA66xGbeEAzXUIthlSP+G3CnBG0 YdGLfMWsm2/7tZvQuc4VtuhRv0q+fG/LxUyFdE7aus9jnQTw5O/l/puBsr5zKCK5RcLp YLFgRFN3BE+Xxb63RJyQOSTlte6BplbQahRML1U2furONBHs1foeK1uzLyyqMkQMEpkF ky44pGoVyrvSfu7mi2UV+KXWAkmXNVWu+p7pQKmTqTI2oJkvNPptRQ5NTes0GIzSzntx VPmA== X-Received: by 10.43.143.4 with SMTP id jk4mr13256983icc.81.1373663369875; Fri, 12 Jul 2013 14:09:29 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id nr4sm1668181igb.0.2013.07.12.14.09.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 14:09:29 -0700 (PDT) Message-ID: <51E07088.7010401@gmail.com> Date: Fri, 12 Jul 2013 15:09:28 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Draft DMARC BOF Agenda X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:09:34 -0000 I'd offer a friendly amendment to the agenda for consideration: On 7/10/13 2:53 PM, Russ Housley wrote: > We have discussed the BOF agenda, and this structure still seems to be the right one. > > DMARC BOF Agenda > > Summary of DMARC > -- Goal: Common foundation of DMARC > -- Note: DMARC specification is being AD sponsored > > Summary of Open Issues > -- Goal: What is left for a working group to do? It seems that there are likely to be a couple different interpretations of the "Open Issues" topic. So far, it seems that most of the questions needing answers revolve around interpretations of policy on either side. Since we already have a start at identifying some issues, I believe it'd be worth the time to discuss them. As a reminder, here's a link to the draft that's been offered as input to the proposed work group: http://www.ietf.org/id/draft-crocker-dmarc-bcp-02.txt In that light, I propose breaking the topic into "Possible Technical Issues" and "Deployment & Usage Issues". HTH, Trent > > Charter review > -- Goal: Discuss the draft charter > > Hums > -- Facilitator: Barry Leiba > -- Goal: Is there adequate support for a DMARC WG? > > At this time, I am also calling for volunteers to take minutes and to jabber scribe. > > Rus > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From housley@vigilsec.com Fri Jul 12 14:37:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1895D21F9FE9 for ; Fri, 12 Jul 2013 14:37:33 -0700 (PDT) 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.037, 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 SVQuwQd3BLBX for ; Fri, 12 Jul 2013 14:37:17 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BAFA021F9FE5 for ; Fri, 12 Jul 2013 14:37:17 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 4286EF240B4; Fri, 12 Jul 2013 17:37:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id eiwK4fmz0eLH; Fri, 12 Jul 2013 17:37:04 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 6D334F2408B; Fri, 12 Jul 2013 17:37:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51E07088.7010401@gmail.com> Date: Fri, 12 Jul 2013 17:37:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC271C2-153F-4B71-BFA2-44DBC9C19DA0@vigilsec.com> References: <51E07088.7010401@gmail.com> To: "J. Trent Adams" X-Mailer: Apple Mail (2.1085) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Draft DMARC BOF Agenda X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:37:33 -0000 This is fine with me. Russ On Jul 12, 2013, at 5:09 PM, J. Trent Adams wrote: >=20 > I'd offer a friendly amendment to the agenda for consideration: >=20 > On 7/10/13 2:53 PM, Russ Housley wrote: >> We have discussed the BOF agenda, and this structure still seems to = be the right one. >>=20 >> DMARC BOF Agenda >>=20 >> Summary of DMARC >> -- Goal: Common foundation of DMARC >> -- Note: DMARC specification is being AD sponsored >>=20 >> Summary of Open Issues >> -- Goal: What is left for a working group to do? >=20 > It seems that there are likely to be a couple different = interpretations > of the "Open Issues" topic. So far, it seems that most of the = questions > needing answers revolve around interpretations of policy on either = side. > Since we already have a start at identifying some issues, I believe = it'd > be worth the time to discuss them. >=20 > As a reminder, here's a link to the draft that's been offered as input > to the proposed work group: >=20 > http://www.ietf.org/id/draft-crocker-dmarc-bcp-02.txt >=20 > In that light, I propose breaking the topic into "Possible Technical > Issues" and "Deployment & Usage Issues". >=20 > HTH, > Trent >=20 >>=20 >> Charter review >> -- Goal: Discuss the draft charter >>=20 >> Hums >> -- Facilitator: Barry Leiba >> -- Goal: Is there adequate support for a DMARC WG? >>=20 >> At this time, I am also calling for volunteers to take minutes and to = jabber scribe. >>=20 >> Rus >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > --=20 > J. Trent Adams >=20 > Profile: http://www.mediaslate.org/jtrentadams/ > LinkedIN: http://www.linkedin.com/in/jtrentadams > Twitter: http://twitter.com/jtrentadams >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From housley@vigilsec.com Fri Jul 12 15:50:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61C021E80BA for ; Fri, 12 Jul 2013 15:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 ZePxE5EcYDVl for ; Fri, 12 Jul 2013 15:50:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8C21F9FE5 for ; Fri, 12 Jul 2013 15:50:19 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A22E3F240B4 for ; Fri, 12 Jul 2013 18:50:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id XfcXyesZzP+Y for ; Fri, 12 Jul 2013 18:50:09 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A7E7FF2408B for ; Fri, 12 Jul 2013 18:50:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Fri, 12 Jul 2013 18:50:15 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4DE81AC1-C55E-4E3B-B6F7-EA6D2956433A@vigilsec.com> References: To: dmarc@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [dmarc-ietf] Draft DMARC BOF Agenda X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 22:50:28 -0000 Here is the updated BOF agenda. Russ = = = = = = = = DMARC BOF Agenda Summary of DMARC -- Presentation: Murray Kucherawy -- Goal: Common foundation of DMARC -- Note: DMARC specification is being AD sponsored Summary of Open Issues -- Goal: What is left for a working group to do? Possible Technical Issues -- Presentation: Trent Adams Deployment & Usage Issues -- Presentation: Dave Crocker Charter review -- Presentation: Trent Adams -- Goal: Discuss the draft charter Hums -- Facilitator: Barry Leiba -- accepted -- Goal: Is there adequate support for a DMARC WG? Many thanks to John Levine for volunteering to take minutes. From johnl@iecc.com Fri Jul 12 18:36:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCFD21F9DA1 for ; Fri, 12 Jul 2013 18:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.719 X-Spam-Level: X-Spam-Status: No, score=-110.719 tagged_above=-999 required=5 tests=[AWL=0.480, 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 a8F6zQoZRxGT for ; Fri, 12 Jul 2013 18:36:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFCE21F9958 for ; Fri, 12 Jul 2013 18:36:33 -0700 (PDT) Received: (qmail 11204 invoked from network); 13 Jul 2013 01:36:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jul 2013 01:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e0af20.xn--30v786c.k1307; i=johnl@user.iecc.com; bh=KJXtYRuYmK2Vh3tdxgB6oHayLzzug5fBoWwMEBXAar4=; b=FXSuuUA6kGMI9noKOpO4OZAxC8RKEvdZ764Czb8p765hoETzhQAv2LKSiiTBNaFbAUEVlfZhuk9Uc1dHPG3JdCuM6+1MzYd719F1mULYLqOwav236roeX0Ut4PeclHAd6+PFV/zxxeF7Qs8zKzwvjg+U91n1KBX+W5NPC7/5UhTJ0nx1MHkXXZLuES4pOVG2Je4zrxj/e8A/LQZK3LFrRigg+IwKctBHwI9nXG1qSqDVT9o/e6vmrTgProymTdvA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e0af20.xn--30v786c.k1307; olt=johnl@user.iecc.com; bh=KJXtYRuYmK2Vh3tdxgB6oHayLzzug5fBoWwMEBXAar4=; b=EcV/7mTsz+TitzOoPWrrBtViEz1YlpbpsE80owGvBUtvJio5ijJioFLPy3a7uIdjCkK86sP+8otG5gcCKi7Y4fojhtM/4aK6Yk9kdhkzYRn4Ak23/E5a2ov9V4jTaNq9j7HIdxIxwZJgoKH9oqiWU57XNIx/Bb56jvwLw8hHAVlGtp2u/gF8zT6xx+LB02Z8mGEIeGSJ5p/Gr5CJX6laRFcPWfFYKatFfWoJGxPU0GPVGKUBUPSGu7XPFfZGLKG6 Date: 13 Jul 2013 01:36:09 -0000 Message-ID: <20130713013609.14351.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51E06D2E.9060709@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: jtrentadams@gmail.com Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 01:36:38 -0000 Um, didn't we just have this argument last week? Here's a pointer to my proposed charter improvements: http://www.ietf.org/mail-archive/web/dmarc/current/msg00335.html Executive summary: if there's going to be a DMARC group, it gets to work on all the DMARC documents. R's, John From sm@resistor.net Fri Jul 12 19:23:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFCE11E8162 for ; Fri, 12 Jul 2013 19:23:06 -0700 (PDT) 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 utegR8+Rg89j for ; Fri, 12 Jul 2013 19:23:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1F11E815E for ; Fri, 12 Jul 2013 19:23:06 -0700 (PDT) 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 r6D2MsCW004034; Fri, 12 Jul 2013 19:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373682179; bh=ZSCrp0+YfYP80u4NVqBTRUWENwZheq2Rvf7C4eoGl9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3V7rT5oIpLkHZBf4cPBIXFa+JhHmfBiw0VSmVmqPTdBeQ8rcEMBHovIBT3ub0asTc gVbpf/PEjxDExn4ikIfKRS9XQ5LNJxGBKOYVcVqdEPVS0y2AHMhsLf+6uYzcKEyMqj 8f3/og3jpTrtZWF1D1NWVMOKZxKbkn9KUNcrDqQA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373682179; i=@resistor.net; bh=ZSCrp0+YfYP80u4NVqBTRUWENwZheq2Rvf7C4eoGl9U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zB1j9QLIPo+XgPgU1HdaNr9dKCI+v2rsB7bR2tY/LmE0WJHybCz5CimtaHQ60c6L1 iRK8iczgwRpGqbW/DEul2VsUxuRpJULPKEvYuk3nJ86k4OU8m/1DmxznAisKnL2m0P lJGyJ2fhNtzA8fRdHlcVjxkb2dURhTbbMLm+cYDY= Message-Id: <6.2.5.6.2.20130712185039.0c822648@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 12 Jul 2013 19:21:36 -0700 To: "J. Trent Adams" From: SM In-Reply-To: <51E06D2E.9060709@gmail.com> References: <300040D1-57F7-47AB-8B8F-14E68733B2B6@vigilsec.com> <51E06D2E.9060709@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 02:23:07 -0000 Hi Trent, At 13:55 12-07-2013, J. Trent Adams wrote: >http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC "The existing base specification is being submitted via the Independent Submission Editor for publication." "For reference, draft-kucherawy-dmarc-base is the current location of the base specification, which will be submitted to the Independent Submission Editor." Based on the messages which have been posted to this mailing list I think that the submission path mentioned above is incorrect. "The working group will review the specification, including its limitations, particularly focusing on those listed below." Is it being suggested that the future working group reviews or does not review the base specification? "Also in scope are possible extensions enabling accommodation of previously unanticipated use cases." I gather that the group has carefully considered the implications. "The initial charter for this working group does not include revising the base specification, but rather producing incremental extensions to it." The answer to the question about working group review of the base specification affects the above. "At the time of chartering, DMARC has already achieved an estimated coverage of 60% of the Internet's mailboxes." The above text looks like something from the marketing department. Regards, -sm From dcrocker@gmail.com Fri Jul 12 19:45:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE86A21E8063 for ; Fri, 12 Jul 2013 19:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cugU2rJJSsK for ; Fri, 12 Jul 2013 19:45:11 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 986E511E817A for ; Fri, 12 Jul 2013 19:45:07 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so12015546obb.8 for ; Fri, 12 Jul 2013 19:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kqw4LUbcm7lEJ0UoaYdFXHJHjtWUDLuP0HUgrpVOeXI=; b=pgqXqKPjAoJnx132o80EXomcTiwYGfluo6fUvdjxsJ714zu0DVjvvb8DwdqH/sm8M9 WOF7jOfVLQ0RZWXvO/CJZ9y1OXli0nnrIpdG65tnpyAEpfgLYx1foaVQ+5k1+25rIcTX xNjDf02HhL7C7jxYyaTYDy8noRS4oIHxm8RglgRXHLm+CgpN2/iE6UEzsDYv2pZUif+Q iUgB2d08RoAu4Cj6+wAnJ6ra7KJHtDKHiBxxexRMKHmh0SROVgsxYMFkEWQ0o9ekPq8x nDvmE/pKW0LbT18L74A9TA0hnZKizMBhzs1v/NqQ9FPJ4lf1ZaMi5Y9ZbZnG3oDEBIPT ZApg== X-Received: by 10.182.27.74 with SMTP id r10mr37672658obg.63.1373683495223; Fri, 12 Jul 2013 19:44:55 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id hm1sm57839894obb.9.2013.07.12.19.44.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 19:44:54 -0700 (PDT) Message-ID: <51E0BF08.6020608@gmail.com> Date: Fri, 12 Jul 2013 19:44:24 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130713013609.14351.qmail@joyce.lan> In-Reply-To: <20130713013609.14351.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jtrentadams@gmail.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 02:45:13 -0000 On 7/12/2013 6:36 PM, John Levine wrote: > Um, didn't we just have this argument last week? ... > Executive summary: if there's going to be a DMARC group, it gets to > work on all the DMARC documents. Why? More specifically: For each such document, what is the... uhhhh... you know... "work"? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Fri Jul 12 21:43:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1761711E80A2 for ; Fri, 12 Jul 2013 21:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oyZgflydDCY for ; Fri, 12 Jul 2013 21:43:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F41CB21F9E3C for ; Fri, 12 Jul 2013 21:43:21 -0700 (PDT) Received: (qmail 44774 invoked from network); 13 Jul 2013 04:43:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=aee5.51e0dae9.k1307; bh=f1vBZBcUpRSH8qhTXmCn6ReGSZomxtZjmsiCQtKrLjo=; b=bybcfjeHId7puaORUM305TCeesWGOuzOUAPPr5qlEcTy8ybQYIaeAutqIPJdabz8R7BIfbTfLNRn8ie9eBHH4s4i+bdIhKLxpTRv52zePiuHQeXrAqsOJSdZe+36me3OiuFKAu2xL98TSTLm8BE/8gGnQ+70YbuNXyaqIOS1FamNws0CYwS4jkGSIJ7atYPe9K2PW8YhtBHTMVqakyK0M3h4YfCMaEgrbsdQftt6GdhDzKFCeXjMLlRY4X5tR5sX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=aee5.51e0dae9.k1307; bh=f1vBZBcUpRSH8qhTXmCn6ReGSZomxtZjmsiCQtKrLjo=; b=m+HbUzW9FEhLngobd8fRtmL4Kw+8r7iMLYlvn4J+JeW5cdAVN4iwQgW1bYUMtomS52WBfgzcgJGkRIKseGjzDmHp3ityQ5RcCYCi3cRb6FxkyC5bdS/T2v9DIfyULILNo9kqXqGmwKhHZYEZ5EjN98Wxs/puvWnuOX6q0acIgijDkFDJ4UJvqHCmMlvt7vjcPEG2xSabbCL9jEohUHteFfu10B07dB4sZzQ3fu60dFiEir6R+/pdVxmGhDawpFIa Received: (ofmipd 127.0.0.1); 13 Jul 2013 04:42:59 -0000 Date: 13 Jul 2013 00:43:21 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <51E0BF08.6020608@gmail.com> References: <20130713013609.14351.qmail@joyce.lan> <51E0BF08.6020608@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 04:43:23 -0000 >> Um, didn't we just have this argument last week? > ... >> Executive summary: if there's going to be a DMARC group, it gets to >> work on all the DMARC documents. > > Why? > > More specifically: > > For each such document, what is the... uhhhh... you know... "work"? Sigh. Keeping in mind that we DO NOT KNOW what the draft that will apparently be submitted says (since the most recent public one is from April), here's a few things in that draft that could use work: * Fix the requirements in sec 3.1 * Fix the terminology in sec 4. * Figure out whether the public suffix kludge in sec 4 and A.6.1 needs further definition to interoperate adequately * Decide whether to remove section 12.2.2 since I don't think anyone has ever implemented and it's rather badly specified. Every http POST I've ever seen has had an application/x-www-form-urlencoded or multipart/form-data body. While there's nothing in the http spec that forbids other random multiparts, I wouldn't want to write it into a standards track document unless I was confident that web servers would do something reasonable. Note that an http PUT means to replace whatever is at the URL with the body of the message, which is not what you want. POST makes more sense, but for a POST to work reliably you'd be much better off with the gzip file inside a multipart/form-data. The Subject field it describes is also pretty dodgy since I don't know anyone who uses them with http, and would in any event be redundant with the filename in the form-data. The section is also somwhat underspecified on the response side, since it gives no hint as to what http return codes might be returned and how a receiver should interpret them, e.g., if it gets a 302 should it really go re-post it somewhere else? If it gets a 4xx should it keep sending subsequent reports? * Has 12.2.4 been implemented? The bracketed text suggests not. It says that if you can't deliver a report, you sould send a DSN to the same address you couldn't deliver the report to, which seems like an exercise in futility. * Section 13 seems to say that if I act as a mail receiver, I have to send daily reports, unless that "and/or" means something else. Say I have a small mail system where I use a postfix plugin to do DMARC processing on inbound mail, but I don't have a database to store all the results so I can't send aggregate reports. It appears to be telling me in that case not to bother doing the inbound processing. That seems counterproductive. That's what I got in a 15 minute read through. If I read it carefully, I'd probably find more, as would other people. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From sklist@kitterman.com Fri Jul 12 22:29:42 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3467E21E80CD for ; Fri, 12 Jul 2013 22:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIQUciXXtRmo for ; Fri, 12 Jul 2013 22:29:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id C25151F0D41 for ; Fri, 12 Jul 2013 22:29:41 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 190A8D04067; Sat, 13 Jul 2013 01:29:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373693381; bh=UpZIpUxaVHup0Dbcq/YUoMJCkwoGwqkPx/VtQuzVgBI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=YwHKxpDWTO1pqUII1TeLH1VT969yMupG2Hb4Qyi97PYcUiifrYQ5minsOVF1ov7Zj thOJE33AFm+8cMNmR0xaMmEl8sDzo8VPxW5WAdZt6t8pNuTEqlXj7o7acYZsEkc7Fy DkGrjkMcgEf0AX+ok1SXvXxxbIQU7s5F3cMay0RY= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A8092D0403F; Sat, 13 Jul 2013 01:29:40 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <20130713013609.14351.qmail@joyce.lan> References: <20130713013609.14351.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 13 Jul 2013 01:29:37 -0400 To: dmarc@ietf.org Message-ID: <786e4f3c-3f4f-46da-8302-4deee0fcf9e8@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 05:29:42 -0000 John Levine wrote: >Um, didn't we just have this argument last week? > >Here's a pointer to my proposed charter improvements: > >http://www.ietf.org/mail-archive/web/dmarc/current/msg00335.html > >Executive summary: if there's going to be a DMARC group, it gets to >work on all the DMARC documents. +1. Scott K From housley@vigilsec.com Sat Jul 13 13:23:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6121F9C7D for ; Sat, 13 Jul 2013 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 VHuewpIRxdTE for ; Sat, 13 Jul 2013 13:23:47 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3FADC21F9CAC for ; Sat, 13 Jul 2013 13:23:47 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6F46EF240BB; Sat, 13 Jul 2013 16:23:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id mgcmZBBj1M4W; Sat, 13 Jul 2013 16:23:43 -0400 (EDT) Received: from [192.168.2.108] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 03781F240BA; Sat, 13 Jul 2013 16:23:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20130713013609.14351.qmail@joyce.lan> Date: Sat, 13 Jul 2013 16:23:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130713013609.14351.qmail@joyce.lan> To: John Levine , Scott Kitterman X-Mailer: Apple Mail (2.1085) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:23:52 -0000 John and Scott: It is clear that there are people on this list that hold this view. = However, that is not the draft charter that Barry has asked us to = produce. Without an indication from Barry that he is not going to AD = sponsor the DMARC specification, the charter should not include that as = part of the work. Barry has said that we wants review for the DMARC specification. = However, if the path forward for the DMARC spec does not change, that = review will not be the responsibility of the proposed working group. Russ On Jul 12, 2013, at 9:36 PM, John Levine wrote: > Um, didn't we just have this argument last week? >=20 > Here's a pointer to my proposed charter improvements: >=20 > http://www.ietf.org/mail-archive/web/dmarc/current/msg00335.html >=20 > Executive summary: if there's going to be a DMARC group, it gets to > work on all the DMARC documents. >=20 > R's, > John From housley@vigilsec.com Sat Jul 13 13:35:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995BE21F86B1 for ; Sat, 13 Jul 2013 13:35:58 -0700 (PDT) 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 h6d2ZX91EJAk for ; Sat, 13 Jul 2013 13:35:53 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2721F9DA0 for ; Sat, 13 Jul 2013 13:35:53 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 560A5F240BB; Sat, 13 Jul 2013 16:36:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id zQmtUMFJL5XR; Sat, 13 Jul 2013 16:35:50 -0400 (EDT) Received: from [192.168.2.108] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1840BF240BA; Sat, 13 Jul 2013 16:36:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <51E06D2E.9060709@gmail.com> Date: Sat, 13 Jul 2013 16:35:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <300040D1-57F7-47AB-8B8F-14E68733B2B6@vigilsec.com> <51E06D2E.9060709@gmail.com> To: "J. Trent Adams" X-Mailer: Apple Mail (2.1085) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:35:58 -0000 At 13:55 12-07-2013, J. Trent Adams wrote: > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC Trent: I believe that the proposed WG name is dmarc, not dmarcext. The existing specification is not being submitted to the "Independent = Submission Editor for publication." If this was to happen, it would = become an Informational RFC. Instead, Barry is AD sponsoring the = document on the standards track. This has an impact on the text in two = places. I suggest that "initial charter" be replaced with "charter". This will = read better a few months from now. I find this wording abrasive: "... include developers and operators of = DMARC-based mechanisms outside the core set of working group = participants in its consensus discussion." I suggest: "... include = developers and operators of DMARC-based mechanisms to the greatest = extent possible." Russ From sm@resistor.net Sat Jul 13 14:39:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64E21F9E80 for ; Sat, 13 Jul 2013 14:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 lP3vAvP4A8VW for ; Sat, 13 Jul 2013 14:39:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB5921F9E4E for ; Sat, 13 Jul 2013 14:39:42 -0700 (PDT) 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 r6DLdbtY016971; Sat, 13 Jul 2013 14:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373751582; bh=TRtaKVeNZSKltoC09YY9IQjhw6x6rXVz/abANgDlBOg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wz0XXXaKdVOM1YX05fKjZqXjmWRpgaqrxzoMGHCtdxJTtV/dNtOd0kzQQh0nWTEb0 68CM88wX6qEFJx6i4DUpoe5b265zS/PQo47O1WvllYh44xYsusXsqgoijh8w08xe+c RIgnDMYcDdodzsDCsnlXUyDZ5zmP+bmIYBpHCdTA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373751582; i=@resistor.net; bh=TRtaKVeNZSKltoC09YY9IQjhw6x6rXVz/abANgDlBOg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=J5T5MXGPZM4xZbjzsnQ2ynqH7Wde4Kp3In9OSAaxPGExfaLq+ONRjo4FcgbQI1UJG KnrAWIFWbnBOcU4k+EjDvBd9FEgV59Di1FO4rI+ktxwiwnrRZAXRbZMGN/J84Luik3 92oQ/S4P+SAflV0AGuUB3c8QdgXymZtVEr9mj+FQ= Message-Id: <6.2.5.6.2.20130713141237.0d1ff1c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 13 Jul 2013 14:32:47 -0700 To: dmarc@ietf.org From: SM In-Reply-To: <20130702052746.15876.qmail@joyce.lan> References: <20130702052746.15876.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John Levine Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 21:39:44 -0000 At 22:27 01-07-2013, John Levine wrote: >Delete the 13th paragraph. Delete discussions of mailing lists which are >a hopeless black hole. Adjust the schedule to taste. I don't have a strong opinion about whether the future working group should or should not work on a draft about mailing lists. A small number of people who have participated in IETF discussions about mailing lists are aware that it is a hopeless case. Who knows, maybe this group will succeed where everyone else failed. Regards, -sm From sklist@kitterman.com Sun Jul 14 21:38:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BD521F9AE6 for ; Sun, 14 Jul 2013 21:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 T1QPVqN5Nrll for ; Sun, 14 Jul 2013 21:38:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95821F9A2A for ; Sun, 14 Jul 2013 21:38:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D35DE20E40D6; Mon, 15 Jul 2013 00:38:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373863112; bh=RrKAdYG4fb9hSUFwbeA5I4nJBGmI2GkeSw2bbZEJ0u4=; h=From:To:Subject:Date:From; b=m9P2hMMSgzkzL5uh2oQYl9pEHgVaOZLibIGxsZ21BTw5zqnPkKFUqreYcCiUU0WUH OIHS9gRxAYHLV9TOr0stSfnvC7shsHhxmOVITHH598ufwqNvo3M4mse1FQoOu2r0Vr KMPCetEEXvvLPQnOBszSnhM2sg24HkdoosDWlFss= Received: from scott-latitude-e6320.localnet (unknown [97.89.236.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A03A220E40B0; Mon, 15 Jul 2013 00:38:32 -0400 (EDT) From: Scott Kitterman To: "" Date: Mon, 15 Jul 2013 00:38:24 -0400 Message-ID: <2482982.50XS0uITtr@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 04:38:52 -0000 In the introduction, there is a discussion about the RFC5322.From field being the primary identifier in the DMARC mechanism and how DMARC is leveraging SPF and DKIM, but nothing about how DMARC is connecting 5322.From to either the d= signing domain for DKIM or the 5321.MailFrom for SPF. For a reader that knows anything about either of those, it will be confusing, since neither of the technologies that DMARC is leveraging have anything to say about 5322.From. I don't think 2.4. Experiment Team belongs in an IETF draft. Section 3. Requirements should be stricken and to the extent these requirements are still relevant to the intended draft/RFC they should be captured in the WG charter. The requirements are inconsistent, in some cases conflicting, and not all satisfied by the current design. Any reference to requirements should be to ones that are still operative. Section 4: Terminology: If domain owner is analogous to the existing email-arch term ADMD, just use that instead of inventing another term for the same thing. Similarly, I don't find Mail Receiver in 5598 either. It would be better to use existing, consistent terminology. The concept of organizational domain is critical to applying identifier alignment correctly, but it's impossible to do so based on the information in the spec. I'm not sure what the solution is, but this seems like a substantial mess in the making. Section 4.3 implies that SPF HELO checks are only done if 5321.MailFrom is null. This is not correct. In Section 4.3.1, I know what's meant by DKIM relaxed mode due to the example, but the normative text is not at all clear. I would not consider "news.example.com" and "example.com" to be "equal". Relaxed is equal and strict is identical doesn't parse. Section 5: > A Mail Receiver implementing the DMARC mechanism MUST make a best- > effort to adhere to the Domain Owner's published DMARC policy when a > message fails the DMARC test. We're about a decade into working on email authentication technology (SPF started in 2003, it has older antecedents). For almost all of that time we've been working with a construct that senders don't get to dictate receive policy. I think a 2119 MUST is wrong here. I think it's up to the draft and the DMARC community to explain why receivers would want to do this, but MUST is the wrong way to go about this. It's certainly a novel approach that warrants consideration and not just swallowing whole, unexamined. Section 6.1. Apparently people get confused about when bytes are supposed to have 1,000 bits and when they are supposed to have 1,024 bits plus mail sometimes gets sent 7 bit and sometimes 8 bit, so something that starts out on disk as a 50MB file can be substantially larger at the receiving MTA. I would suggest some additional precision about what it meant by file size would be appropriate to ensure a common understanding and avoid interoperatility problems. Section 6.2 - In the section about policy, the definition for none: > none: {R5} The Domain Owner requests no specific action be taken > regarding delivery of messages. should have ... due to DMARC ... added to it to appropriately scope the request. In the report format section: Having two types that not all senders/receivers will implement seems suboptimal. I've previously expressed my reservations about Section 7, policy enforcement considerations. I've been asked for inputs offlist, so I anticipate changes in the next revision, but even when there is some discussion outside the secret design group writing these drafts, it is very difficult to consider it actual participation. I think that will be a problem until this is the list where actual work on DMARC happens. Secton 11.2 describes SPF checks being done after DKIM verification. This is, in my experience, and odd order to describe them in and it's equally odd to describe both DKIM and SPF verification being done after a DMARC record is retrieved. In reality, the order doesn't matter. You need an SPF result, a DKIM result, and a DMARC record to determine the DMARC result. The current language implies sequence requirements that don't exist. I think mentioning best guess SPF is out of place too. That's no where defined in any IEFT document, so there's no way to describe the thing you're telling people not to do. I think general advice is enough. At the end of 12.2: > ... The Mail Receiver MAY cache that > data and try again later, or MAY discard data that could not be sent. I don't thing the 2119 words are needed here. I don't think there's a third option here, so you're telling the receiver they can do whatever they want. You don't need 2119 language to tell them that. Section 15.4 describes SPF as a "backup" to DKIM. That's not consistent with the rest of the draft. Similar to 15.4, there are also senders that aren't very careful about what the put DKIM signatures on, so there's a similar, but missing security consideration for DKIM. Section 15.8 needs a complete rewrite. Start with SMTP rejections don't cause backscatter and go from there. A.6.1. Public Suffix Lists mentions one publicly maintained list and license states that license terms can be found at the relevant URL. They aren't there. The XML schema definition is confusing to me to read (I'm not an XML expert by any means, so it may just be me). It does not seem to consistently match up with what I see being used in the wild. I see forwarded used quite often for mailing lists and I don't recall ever having seen mailing list as a policy override reason. I think there's substantial work to be done here once we look at the spec versus what's going out on the wire. Appdendix D should be updated to refer to this list. I kept waiting for a justification for why TLS was recommended, but I got to the end and didn't find it. I'm on vacation this week and work's been busy up to being on vacation, so I've only had limited time to review this. Consider these comments after a light read. I'm sure if I had more time, the review could have been longer. Scott K From jtrentadams@gmail.com Mon Jul 15 08:12:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9221F9F43 for ; Mon, 15 Jul 2013 08:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCOuA66CfrZS for ; Mon, 15 Jul 2013 08:12:23 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16C21F9E1F for ; Mon, 15 Jul 2013 08:12:21 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so15901476oag.16 for ; Mon, 15 Jul 2013 08:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=XGgxNp+AAbOGhvOPVGjJi+Uyo9pZqgJaKzYAniQ1Fpk=; b=G8Lxi5st2blE8mfOoTolPoHiiuM+TDDTSRbyQGUhW5ykvcUO1fzo0v77s13y98xW8M Dsatks7u6WyKjUc+EgFThfs1i4VxZgMhypIlqAwY3GrMUCJ1946Lq4QgtClKYAEaThYK ZLMgP7wt49hYmTrgECuATi2KI/a9NgKpiqOe3hZtALc/GT7CguoKlMUBe7b/Kbckfk8R KPgzvojlZ0hNYj2vVi43srs4uoKO2pWNRFMWOnRLmhXEY4APzGKb7LM93kkzun2btwO9 8kSg8fquAre/awCXqifTH0kwKvvza7h70YBNiyptXnhC4ptRiSpSAC9XDZAC/xKXOHDl cq5Q== X-Received: by 10.182.120.196 with SMTP id le4mr43880307obb.57.1373901139644; Mon, 15 Jul 2013 08:12:19 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id df11sm69938973oec.0.2013.07.15.08.12.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 08:12:18 -0700 (PDT) Message-ID: <51E41152.7040901@gmail.com> Date: Mon, 15 Jul 2013 09:12:18 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130713013609.14351.qmail@joyce.lan> <51E0BF08.6020608@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:12:24 -0000 John - Many thanks for the pointer to the previous conversation. Apologies for asking again when the answers were already staring up at me from my inbox. Digging in now. Thanks again, Trent On 7/12/13 10:43 PM, John R Levine wrote: >>> Um, didn't we just have this argument last week? >> ... >>> Executive summary: if there's going to be a DMARC group, it gets to >>> work on all the DMARC documents. >> >> Why? >> >> More specifically: >> >> For each such document, what is the... uhhhh... you know... "work"? > > Sigh. Keeping in mind that we DO NOT KNOW what the draft that will > apparently be submitted says (since the most recent public one is from > April), here's a few things in that draft that could use work: > > * Fix the requirements in sec 3.1 > > * Fix the terminology in sec 4. > > * Figure out whether the public suffix kludge in sec 4 and A.6.1 needs > further definition to interoperate adequately > > * Decide whether to remove section 12.2.2 since I don't think anyone > has ever implemented and it's rather badly specified. Every http POST > I've ever seen has had an application/x-www-form-urlencoded or > multipart/form-data body. While there's nothing in the http spec that > forbids other random multiparts, I wouldn't want to write it into a > standards track document unless I was confident that web servers would > do something reasonable. Note that an http PUT means to replace > whatever is at the URL with the body of the message, which is not what > you want. POST makes more sense, but for a POST to work reliably you'd > be much better off with the gzip file inside a multipart/form-data. > The Subject field it describes is also pretty dodgy since I don't know > anyone who uses them with http, and would in any event be redundant > with the filename in the form-data. The section is also somwhat > underspecified on the response side, since it gives no hint as to what > http return codes might be returned and how a receiver should > interpret them, e.g., if it gets a 302 should it really go re-post it > somewhere else? If it gets a 4xx should it keep sending subsequent > reports? > > * Has 12.2.4 been implemented? The bracketed text suggests not. It > says that if you can't deliver a report, you sould send a DSN to the > same address you couldn't deliver the report to, which seems like an > exercise in futility. > > * Section 13 seems to say that if I act as a mail receiver, I have to > send daily reports, unless that "and/or" means something else. Say I > have a > small mail system where I use a postfix plugin to do DMARC processing > on inbound mail, but I don't have a database to store all the results > so I can't send aggregate reports. It appears to be telling me in that > case not to bother doing the inbound processing. That seems > counterproductive. > > That's what I got in a 15 minute read through. If I read it carefully, > I'd probably find more, as would other people. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From franck@peachymango.org Mon Jul 15 12:16:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E62111E81A7 for ; Mon, 15 Jul 2013 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv8TuTw57B4r for ; Mon, 15 Jul 2013 12:15:58 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4F11E8177 for ; Mon, 15 Jul 2013 12:15:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 291BC390134; Mon, 15 Jul 2013 14:15:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cVqMoamTkmg; Mon, 15 Jul 2013 14:15:57 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 08FE2390150; Mon, 15 Jul 2013 14:15:57 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E7F54390134; Mon, 15 Jul 2013 14:15:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NqLeT-Zs1xjv; Mon, 15 Jul 2013 14:15:56 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 0B7A9390153; Mon, 15 Jul 2013 14:15:55 -0500 (CDT) Date: Mon, 15 Jul 2013 14:15:54 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <126220632.35923.1373915754252.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20130713013609.14351.qmail@joyce.lan> <51E0BF08.6020608@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Charter Discussion at the DMARC BOF Thread-Index: oeCnX11Yk90yvi7YaqbViNfiUyuTKA== Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:16:04 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Dave Crocker" > Cc: dmarc@ietf.org > Sent: Friday, July 12, 2013 9:43:21 PM > Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF > > > * Decide whether to remove section 12.2.2 since I don't think anyone has > ever implemented and it's rather badly specified. Every http POST I've > ever seen has had an application/x-www-form-urlencoded or > multipart/form-data body. While there's nothing in the http spec that > forbids other random multiparts, I wouldn't want to write it into a > standards track document unless I was confident that web servers would do > something reasonable. Note that an http PUT means to replace whatever is > at the URL with the body of the message, which is not what you want. > POST makes more sense, but for a POST to work reliably you'd be much > better off with the gzip file inside a multipart/form-data. The Subject > field it describes is also pretty dodgy since I don't know anyone who uses > them with http, and would in any event be redundant with the filename in > the form-data. The section is also somwhat underspecified on the response > side, since it gives no hint as to what http return codes might be > returned and how a receiver should interpret them, e.g., if it gets a 302 > should it really go re-post it somewhere else? If it gets a 4xx should it > keep sending subsequent reports? I believe that netease has implemented it. > > * Has 12.2.4 been implemented? The bracketed text suggests not. It says > that if you can't deliver a report, you sould send a DSN to the same > address you couldn't deliver the report to, which seems like an exercise > in futility. > There are many reasons why an email will not be delivered, one of these reasons is that the receiver will not accept an aggregate report that it is too big. Notifying that an aggregate report could not be delivered can make sense here and is not an exercise in futility, which brings back that the way to get the report delivered is via http (instead of fragmenting the report into smaller ones and emailing them). From franck@peachymango.org Mon Jul 15 12:29:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF7211E81FD for ; Mon, 15 Jul 2013 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGZ4XKUwRWTj for ; Mon, 15 Jul 2013 12:29:01 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1348311E81E0 for ; Mon, 15 Jul 2013 12:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 87DF22940E7 for ; Mon, 15 Jul 2013 14:28:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8of25xW43hh1 for ; Mon, 15 Jul 2013 14:28:59 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 68FF7294118 for ; Mon, 15 Jul 2013 14:28:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5091F2940CE for ; Mon, 15 Jul 2013 14:28:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jTlAiZAFy5cZ for ; Mon, 15 Jul 2013 14:28:59 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id AB2F3294061 for ; Mon, 15 Jul 2013 14:28:58 -0500 (CDT) Date: Mon, 15 Jul 2013 14:28:57 -0500 (CDT) From: Franck Martin To: dmarc@ietf.org Message-ID: <79439469.36619.1373916537696.JavaMail.zimbra@peachymango.org> In-Reply-To: <444729198.36585.1373916509147.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_36618_612165978.1373916537695" X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: IETF DKIM signature of this list is in testing mode Thread-Index: LLHih3w0f+NTIwP11laoByKgbuN8gg== Subject: [dmarc-ietf] IETF DKIM signature of this list is in testing mode X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:29:11 -0000 ------=_Part_36618_612165978.1373916537695 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ietf1._domainkey.ietf.org. 1133 IN TXT "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDNzNnjKTd5cczd2CDzHflCZuv1tMWYwd7zE+deoJ6s/fXR7/n9ZIBnDS5egt7HAHjNjZrmjcoRlfSsNxRJvUQFyYvaU1BT1s8R+mkPgSOqZ4t9HqAVjiczn2B9+dbjdNN+S/zvSyMMuSCSJDKKAXhBpDeQTpeY7/UdP9s6ws0yjQIDAQAB" t=y should be removed. ------=_Part_36618_612165978.1373916537695 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
ietf1._domainkey.ietf.org. 1133    IN    TXT    "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDNzNnjKTd5cczd2CDzHflCZuv1tMWYwd7zE+deoJ6s/fXR7/n9ZIBnDS5egt7HAHjNjZrmjcoRlfSsNxRJvUQFyYvaU1BT1s8R+mkPgSOqZ4t9HqAVjiczn2B9+dbjdNN+S/zvSyMMuSCSJDKKAXhBpDeQTpeY7/UdP9s6ws0yjQIDAQAB"

t=y should be removed.
------=_Part_36618_612165978.1373916537695-- From johnl@taugh.com Mon Jul 15 13:08:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCAE11E8211 for ; Mon, 15 Jul 2013 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 042UPG6F9wLU for ; Mon, 15 Jul 2013 13:08:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6B11E81A2 for ; Mon, 15 Jul 2013 13:08:38 -0700 (PDT) Received: (qmail 28990 invoked from network); 15 Jul 2013 20:08:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=713d.51e456c4.k1307; bh=YeZOTh20c4xr6dInEj8NX3ixyL8FH8TOZeuTsA7oXys=; b=24na8w2mj7NRJgpmaikD2FRQq+UfFJEKQcz69kRDDbXCwSUfbQA/JdW0c2Hj/cxU8xwvRUw03arqtZHAOM5vaB8WBFYWX3awIRIKm3KKZ31MkdCZYwm3U+RaUColp4IoBR6MJ70w/Unz08Fu5OT2kCTHfwS7vsqSAqEmHtlDmJULIaS0UEhwXFtGeCDZeM5RmkJZDe2IaulfIKJ/FbWXVdiTHlNer9lysq/ajvzsMHtse4oeUrXOGnrRDm2Qe+pR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=713d.51e456c4.k1307; bh=YeZOTh20c4xr6dInEj8NX3ixyL8FH8TOZeuTsA7oXys=; b=Bf/RYoDe+nIQCUFuUMBfbgeyFyTdzKNcwXaWhN+HGtfBejSYMcT9Uq3xjOWxVJ6i7lDzEeUemJ4G0hNb88DeacWXV7isa6jcTWXq0niKyUHGMmoMXDOGwNk1HS8SWiEd0Jcjrf0D2UxYXWt3ig0IhA13KJKhejymTSqm+4qM8X9DDGdp5EuXzlKc52ct9tSoiVTJl+pDsQqETjSVnnqGcqAsH4X0kXhcnpvar1xyMv6APiMaGxDsjGyvOXFWd4mE Received: (ofmipd 127.0.0.1); 15 Jul 2013 20:08:14 -0000 Date: 15 Jul 2013 16:08:36 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <126220632.35923.1373915754252.JavaMail.zimbra@peachymango.org> References: <20130713013609.14351.qmail@joyce.lan> <51E0BF08.6020608@gmail.com> <126220632.35923.1373915754252.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:08:39 -0000 >> * Has 12.2.4 been implemented? The bracketed text suggests not. It says >> that if you can't deliver a report, you sould send a DSN to the same >> address you couldn't deliver the report to, which seems like an exercise >> in futility. > There are many reasons why an email will not be delivered, one of these > reasons is that the receiver will not accept an aggregate report that it > is too big. Notifying that an aggregate report could not be delivered > can make sense here and is not an exercise in futility, which brings > back that the way to get the report delivered is via http (instead of > fragmenting the report into smaller ones and emailing them). Well, there's an interesting question. Has anyone implemented the size limits on reports? Has anyone seen one of thees bounce reports for oversize messages in the wild? By the way, I entirely agree that sending reports by http is a reasonable idea. But not the way it's described in the current draft, which doesn't even the difference between PUT and POST, or the way that servers expect the arguments to POST to be sent. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From superuser@gmail.com Mon Jul 15 13:50:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6F11E8252 for ; Mon, 15 Jul 2013 13:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2po-AO1RTtUL for ; Mon, 15 Jul 2013 13:50:23 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C934C11E8254 for ; Mon, 15 Jul 2013 13:50:22 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so10398010wes.21 for ; Mon, 15 Jul 2013 13:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+C/59HVGBOmpj9CkJeqOH2eQDsL0gGzWa9jh+gsrSjE=; b=F5L+uXC8yy6AWPVhpnOHouXqMNnJj+mL1XpbeiD50bxG0xqxb7S/qm4t/YhVHnFmSr Dj8c9/FpCu0rmoqi/etqrC0pwTkFPBKB4bSQU2yQAR5FVyweJpwFhDL7TtdCo6mCeRmo OorLsZLPYUcCCxzwich0h6wgOAnUOKjSwDP9VdwTtk8ROFHkWu2KUkOuc9lDHwMaAHjH 30osWiXIVLPHyiB1SsjNN/7++TqQW8/gsAhZC4V8fPk+dAYcnXJbKKr3cwkA4WdmX3RG iU3GU4g5OBri4taGpANCcH+4mobWt5bKqAzCJ8az64iuywTFtThoE7e8p0kLPYBXi35E Gx+w== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr10210151wic.19.1373921421877; Mon, 15 Jul 2013 13:50:21 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 15 Jul 2013 13:50:21 -0700 (PDT) In-Reply-To: <79439469.36619.1373916537696.JavaMail.zimbra@peachymango.org> References: <444729198.36585.1373916509147.JavaMail.zimbra@peachymango.org> <79439469.36619.1373916537696.JavaMail.zimbra@peachymango.org> Date: Mon, 15 Jul 2013 13:50:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a11c3436a4cea0704e1930273 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] IETF DKIM signature of this list is in testing mode X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:50:23 -0000 --001a11c3436a4cea0704e1930273 Content-Type: text/plain; charset=ISO-8859-1 You can make reports like this to ietf-action@ietf.org, and a trouble ticket will be opened. On Mon, Jul 15, 2013 at 12:28 PM, Franck Martin wrote: > ietf1._domainkey.ietf.org. 1133 IN TXT "k=rsa\; t=y\; > p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDNzNnjKTd5cczd2CDzHflCZuv1tMWYwd7zE+deoJ6s/fXR7/n9ZIBnDS5egt7HAHjNjZrmjcoRlfSsNxRJvUQFyYvaU1BT1s8R+mkPgSOqZ4t9HqAVjiczn2B9+dbjdNN+S/zvSyMMuSCSJDKKAXhBpDeQTpeY7/UdP9s6ws0yjQIDAQAB" > > t=y should be removed. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c3436a4cea0704e1930273 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You can make reports like this to ietf-action@ietf.org, and a trouble ticket will be open= ed.


= On Mon, Jul 15, 2013 at 12:28 PM, Franck Martin <franck@peachymango.o= rg> wrote:
ietf1._domainkey.ietf.org. 1133=A0=A0 =A0IN=A0=A0 =A0TX= T=A0=A0 =A0"k=3Drsa\; t=3Dy\; p=3DMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB= gQDNzNnjKTd5cczd2CDzHflCZuv1tMWYwd7zE+deoJ6s/fXR7/n9ZIBnDS5egt7HAHjNjZrmjco= RlfSsNxRJvUQFyYvaU1BT1s8R+mkPgSOqZ4t9HqAVjiczn2B9+dbjdNN+S/zvSyMMuSCSJDKKAX= hBpDeQTpeY7/UdP9s6ws0yjQIDAQAB"

t=3Dy should be removed.

_____= __________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc


--001a11c3436a4cea0704e1930273-- From superuser@gmail.com Mon Jul 15 15:14:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52511E8219 for ; Mon, 15 Jul 2013 15:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTR7ZN+BKPqX for ; Mon, 15 Jul 2013 15:14:03 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id AB8F711E81ED for ; Mon, 15 Jul 2013 15:14:01 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so10761627wes.10 for ; Mon, 15 Jul 2013 15:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8f+19t4FcAzJVTHcrF6navvsicBzsWBMaWnQTb9ZsoY=; b=rUtCs5q7SMnOBIV893RGxMZw/leqVoKJavln8/ElcWFSeIfaWLVWAe/7qLG7je4emI lZzFS9eU/+tTO/HAyn4q80ACQ2fft36dSSk3/zOuTiEmGK1BlwqiZQcT4S9bC2BnXr/Z EGCr69+QsXWO1eW8ywJ+KSihBWzLJxXxH9kxPd/17a/mTRZMx2cH7XLrqCAkHPT+LRB+ 7OMRaRECLfDGf5HDxh1aSQl0nEZ6j+OOgD810RM/b35o4QCtlgmXoNIHp2Do0IXz30e2 gB0RSqPYdxHdqwjgyxTKuvy9ButqbGqtbg21iZ8eYlrbCKOwBcJLV3ngwXwhX78s/7rI WfyA== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr10282477wic.60.1373926440212; Mon, 15 Jul 2013 15:14:00 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 15 Jul 2013 15:14:00 -0700 (PDT) In-Reply-To: <20130715221131.5654.36943.idtracker@ietfa.amsl.com> References: <20130715221131.5654.36943.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:14:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c26a5e6a9fa404e1942d23 Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-base-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:14:05 -0000 --001a11c26a5e6a9fa404e1942d23 Content-Type: text/plain; charset=ISO-8859-1 FYI, this handles some of the feedback received to date. It may or may not handle things that John Levine and Scott Kitterman submitted in the last couple of days, but I wanted to make sure we got as much as we could done before the embargo settled in. ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 3:11 PM Subject: New Version Notification for draft-kucherawy-dmarc-base-01.txt To: "Murray S. Kucherawy" , Elizabeth Zwicky < zwicky@yahoo-inc.com> A new version of I-D, draft-kucherawy-dmarc-base-01.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Filename: draft-kucherawy-dmarc-base Revision: 01 Title: Domain-based Message Authentication, Reporting and Conformance (DMARC) Creation date: 2013-07-15 Group: Individual Submission Number of pages: 77 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-base-01.txt Status: http://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base Htmlized: http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-base-01 Abstract: This memo presents a proposal for a scalable mechanism by which a mail sending organization can express, using the Domain Name System, domain-level policies and preferences for message validation, disposition, and reporting, and a mail receiving organization can use those policies and preferences to improve mail handling. The email ecosystem currently lacks a cohesive mechanism through which email senders and receivers can make use of multiple authentication protocols to establish reliable domain identifiers, communicate policies about those identifiers, and report about mail using those identifiers. This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology The enclosed proposal is not intended to introduce mechanisms that provide elevated delivery privilege of authenticated email. The proposal presents a mechanism for policy distribution that enables a continuum of increasingly strict handling of messages that fail multiple authentication checks, from no action, through altered delivery, up to message rejection. The IETF Secretariat --001a11c26a5e6a9fa404e1942d23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI, this handles some of the feedback received to date.= =A0 It may or may not handle things that John Levine and Scott Kitterman su= bmitted in the last couple of days, but I wanted to make sure we got as muc= h as we could done before the embargo settled in.

---------- Forwarded message ----------=
From: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 3:11 PM
Subject: New Version Notification for= draft-kucherawy-dmarc-base-01.txt
To: "Murray S. Kucherawy" &= lt;superuser@gmail.com>, Eliz= abeth Zwicky <zwicky@yahoo-inc.c= om>



A new version of I-D, draft-kucherawy-dmarc-base-01.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-kucherawy-dmarc-base
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Domain-based Message Authentication, Reporting a= nd Conformance (DMARC)
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 77
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/i= nternet-drafts/draft-kucherawy-dmarc-base-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-kucherawy-dmarc-base
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-kuche= rawy-dmarc-base-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdif= f?url2=3Ddraft-kucherawy-dmarc-base-01

Abstract:
=A0 =A0This memo presents a proposal for a scalable mechanism by which a =A0 =A0mail sending organization can express, using the Domain Name System,=
=A0 =A0domain-level policies and preferences for message validation,
=A0 =A0disposition, and reporting, and a mail receiving organization can us= e
=A0 =A0those policies and preferences to improve mail handling.

=A0 =A0The email ecosystem currently lacks a cohesive mechanism through
=A0 =A0which email senders and receivers can make use of multiple
=A0 =A0authentication protocols to establish reliable domain identifiers, =A0 =A0communicate policies about those identifiers, and report about mail<= br> =A0 =A0using those identifiers. =A0This lack of cohesion has several effect= s:
=A0 =A0receivers have difficulty providing feedback to senders about
=A0 =A0authentication, senders therefore have difficulty evaluating their =A0 =A0authentication deployments, and as a result neither is able to make<= br> =A0 =A0effective use of existing authentication technology

=A0 =A0The enclosed proposal is not intended to introduce mechanisms that =A0 =A0provide elevated delivery privilege of authenticated email. =A0The =A0 =A0proposal presents a mechanism for policy distribution that enables a=
=A0 =A0continuum of increasingly strict handling of messages that fail
=A0 =A0multiple authentication checks, from no action, through altered
=A0 =A0delivery, up to message rejection.




The IETF Secretariat


--001a11c26a5e6a9fa404e1942d23-- From jtrentadams@gmail.com Tue Jul 16 08:39:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9B111E80F0 for ; Tue, 16 Jul 2013 08:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G4b43FN2mYI for ; Tue, 16 Jul 2013 08:39:24 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E019F11E80D5 for ; Tue, 16 Jul 2013 08:39:23 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so1915166ieb.2 for ; Tue, 16 Jul 2013 08:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Gdxg/6wQUGj8Vvi1SflpEW71EZMYbiE05u13vQVqjZQ=; b=gRYrC6Cvp8QEQjvTehTYDK4vMe4CtKdr9pRsdftPOSyQKKBUJiEyqOwQ3DXMONrAU3 aSkGkeeO4cF7YnOmVoOXHKoQuV/uWlM9/GUuDFdIK4apVZY7JrxI8jk4K7wU3xYtANR7 GWH/457Rcl18qyKqTDudBi7BwNNre8WKsEpW3ewJu5yzxByLNXJuFfBh78K0TXfXjmfL ULJyaVD3X2IrOXPJABwZh9uc1tDfCj/cipIQ4AoDvhD6mgmzfIvtjW10Al4B36ztXgGV IkvseHQkc6PuL0x3TdAp+IJu9Q1/qJSI8JfzefQvj54mHQPLvEd7RnTIAEXlF05wYMLZ OkZQ== X-Received: by 10.42.109.15 with SMTP id j15mr1302961icp.116.1373989161978; Tue, 16 Jul 2013 08:39:21 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id y9sm25114028iga.9.2013.07.16.08.39.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 08:39:21 -0700 (PDT) Message-ID: <51E56928.4020207@gmail.com> Date: Tue, 16 Jul 2013 09:39:20 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> In-Reply-To: <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:39:28 -0000 Thanks, everyone, for their input on this thread (and to John for the pointer how to get back to land when I blundered into the wrong stream). Editing the proposed charter is a lot easier with this feedback. >From what I can tell, the most important question needing to be answered is whether or not revising the base DMARC specification is within scope of the proposed work group. Following Russ's guidance, it seems that we should start from the assumption that it's not in scope for now given the fact that it's being sponsored by an AD as an Individual Submission. Regardless of whether that's the right path, or not, let's explore it as an option and see how the rest of the items identified in the proposed charter play out. Then we can leverage the outcome of the conversation to potentially revisit the fate of the base specification itself. Given that guidance, here're the most obvious (and noncontroversial?) items needing to be done to shore up the proposed charter: * Correct the text regarding the current path of the specification. * Tone down the "marketing puffery". * Clarify how to address "backward compatibility" with the installed base. I've already updated the description of the current path of the base specification from "Independent Submission" to "Individual Submission", so that's one down. I'll pull out my red pen on the other two topics and see if I can make them more reasonable. Skipping ahead. . . here're the items that have previously been proposed as worth exploring in the setting of an IETF work group: ----- * a mechanism for determining the organizational domain name based on an arbitrary fully-qualified hostname ----- If I'm not mistaken, the Apps Area WG has already expressed an interest in this work. In that case, I believe that this WG would only need to track that effort and ensure that its work addresses the use cases required to support DMARC. QUESTION: Given that it's an important topic, and there's no guarantee that the other effort will result in an applicable solution, would it still be reasonable to include a mention of this as worth exploration? If so, it'd probably make sense to reference the other work as a starting point to clarify we're not planning to spin up a competing solution. ----- * a mechanism for detecting abuse involving the portion of the RFC5322.From field ----- This is an interesting item in that there have been some proposals from contributors to the base DMARC specification to address this. The proposals, as you can see, didn't make it through to a consensus and it was suggested that they be brought to the broader community for consideration. It's highly likely that through the WG process we're able to identify a means by which this issue can be addressed. QUESTION: Does it make sense for this proposed WG to explore how the base specification can be extended to apply the same level of "identifier alignment" to the as is helping defend the ? ----- * a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list ----- I recognize that there's definitely a counter-pressure against including this topic as it seems to be a potentially quixotic quest. That being said, even if we don't find the perfect solution, it does seem reasonable to believe there is a way to provide something more than nothing that does help in some meaningful way. I'm not presupposing a solution, just that there have been a few possible options discussed at the edges which are likely to be worth more rigorous exploration. QUESTION: Is there value in a WG such as this exploring possible solutions to this issue and developing guidance that would potentially help improve the utility of the base DMARC specification? ----- * support for the notion of transitive trust (i.e., "host X trusted the sender of this message, and I trust X, so you should too") ----- I see this as similar to the above, but potentially more broadly applicable. One tweak I'd offer would be to replace ", so you should too" with something like ", so you could choose to as well". QUESTION: Is there value in a WG such as this exploring possible solutions to this issue and developing guidance that would potentially help improve the utility of the base DMARC specification? ----- * more robust transport of reports ----- After over a year of deployment, and the rise in support services handling reports, many folks have suggested that it would be worth exploring how to offer additional optional means of transport for reports. The base DMARC specification provides for this, but it is an area that was left to be extended by a group such as this. QUESTION: Is this an area of exploration that is of enough interest to include in the charter for this proposed work group? Beyond those, the topics in the proposed "Using DMARC" document have already proven useful in clarifying some options that aren't typically included in a base specification. For example, here a few items that may benefit from being specifically called out in the charter as worth exploring: * Identifier alignment configuration options * Implementation decisions regarding "pct" * Determining effective RUA sending frequency * Leveraging policy caching * Various options for integrating within an existing flow * Defining a useful, common set of RUA reporting options * When and how to use local policy override options QUESTION: Do any items on this list seem to be worth specifically adding to the proposed charter as examples of the type of work that would be useful? Finally, this list of potential work items was developed a while ago, and it's likely additional possible areas of exploration have surfaced since then. Are there any other substantive items that would be worth adding to the list? Keeping in mind, of course, that our first cut will be to assume that the base specification isn't in scope for now. Once the dust settles a bit around these items, I'll take another whack at the charter text to at least get it stable for now. Then we can bubble up the bigger question and see if we can tackle that given the input I've seen recently on other threads. Thanks again, Trent On 7/2/13 10:50 PM, Matt Simerson wrote: > On Jul 2, 2013, at 2:29 PM, "Rolf E. Sonneveld" wrote: > >>> In view of the large base of running DMARC >>> code, the group will avoid changes that would cause incompatible >>> changes to bits on the wire. >> -1 >> >> Granted, the installed base is large, but let's not ignore the other 40 percent of the Internet. IETF standards are standards for the _entire_ Internet community, not just ten or twenty of the largest companies in a specific area. The WG should not be bound by 'bits on the wire' in their review and possible comments on the standard. Otherwise the IETF is to a large extent degraded to the 'rubber stamp business' Scott mentioned. >> >> Don't get me wrong: the outcome of the discussions may well be that nothing will change on the wire and that'd be fine. But including this in the Charter as a precondition for the work to be done is wrong in my opinion. > +1 to Rolf's -1. > > I'm happy to see DMARC moving towards becoming a standard. Validation of incoming messages is a great feature. Reporting is more timely and structured than bounce messages. But for the vast majority of mail senders, DMARC is close to useless because of the forwarder / mailing list issue. > > "DMARC policies are not appropriate for domains with users who send mail through mailing lists" --John R Levine > > "SMTP refusal to an unmapped-but-reliable forwarder is likely to cause list unsubscription." --Roland Turner > > The mailing list issue is intractable and also a huge implementation barrier that is barely documented. For legit domain owners (ie, not abusers) that wish to use DMARC to curtail phishing from their domains, they will need to choose between losing legit mail (DMARC + mailing lists) or not losing legit mail (no DMARC). > > Most of the broader internet community does not have the resources to "map the exit IP addresses of well-behaved forwarders and ignore DMARC results for messages that come from those addresses." As such, many domain owners will deploy DMARC, lose valid mail, and then reject the technology. > > While it may be kinda sorta true that DMARC "protects 60% of global consumer mailboxes," it seems to be marketing puffery. While 60% of global mailboxes may have some form of DMARC validation, the number of legit domains that do and potentially *can* deploy DMARC records is absurdly low. > > Other minor Issues such as report loops (DMARC reporters reporting each others DMARC reports to each other ad infinitum) are minor and have simple (but not yet documented) workarounds but could also be addressed technically, rather than requiring workaround documentation. > > Matt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From dcrocker@gmail.com Tue Jul 16 08:50:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09221E8050 for ; Tue, 16 Jul 2013 08:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFVYEop6Lvfg for ; Tue, 16 Jul 2013 08:50:46 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5661E21F9A1C for ; Tue, 16 Jul 2013 08:50:42 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so1036263oag.5 for ; Tue, 16 Jul 2013 08:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C7IBEWlPp5fP+SodivcF7Ziu8yd9wDzK3IXqa9YkmAI=; b=VEFbYK6x9VwiNTEHkFVQiBiUQLnRRoW68BIyBmpjGajsPSYHMcAKJ94/Php5TNCI2q cJZznR6zxk+5XK5g2N2yDblRGGPyEF0D+ZecreN9u/3l/qAcAAa3awGi05NlM6Hb66Yu Ng12qW2/vsiHjiR7cyYS3CEvWgrNXEYWEXuQXfp7HsbJ9YB28K9d3ueZFKh1+FgoEclI 9av/pJadagyeBjS/ODGeuyyL+jy4wF1Mk+tRuHonAd17Zb40DWd0MBr5le/BGXKx/DXa Bsc/y4/MyWft6MS553AizvLCLMzS36rklma/sWKA+ITxTxkufxzrucatUd8warnN/EHj Sifw== X-Received: by 10.182.134.229 with SMTP id pn5mr345204obb.9.1373989841823; Tue, 16 Jul 2013 08:50:41 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id rs4sm1533920obc.10.2013.07.16.08.50.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 08:50:40 -0700 (PDT) Message-ID: <51E56BAD.3060602@gmail.com> Date: Tue, 16 Jul 2013 08:50:05 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "J. Trent Adams" References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> In-Reply-To: <51E56928.4020207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:50:47 -0000 On 7/16/2013 8:39 AM, J. Trent Adams wrote: > * Tone down the "marketing puffery". While I think the existing text isn't all that puffed-up, something along the lines of what it says is still helpful to include. The key point is that the existing specification has a sufficiently large installed base to warrant considerable care in making changes that would disrupt it. > * Clarify how to address "backward compatibility" with the installed base. Perhaps: In order to protect the installed base, any changes to operational practice or bits over the wire need to be incremental and optional. That is, they need to be added as extensions to existing practice, rather than make changes to it. This permits unmodified software and operations to continue to interoperate with those that are upgraded. > * a mechanism for determining the organizational domain name based on an > arbitrary fully-qualified hostname > ----- > > If I'm not mistaken, the Apps Area WG has already expressed an interest > in this work. In that case, I believe that this WG would only need to > track that effort and ensure that its work addresses the use cases > required to support DMARC. > > QUESTION: Given that it's an important topic, and there's no guarantee > that the other effort will result in an applicable solution, would it > still be reasonable to include a mention of this as worth exploration? Not in a charter, unless the wg is going to explore it, which it won't. > If so, it'd probably make sense to reference the other work as a > starting point to clarify we're not planning to spin up a competing > solution. In formal IETF terms, other work isn't real yet. So the reference would be to something not yet having any substance. > ----- > * a mechanism for mitigating the effect of failures of DMARC policy when > a message transits a mailing list > ----- > > I recognize that there's definitely a counter-pressure against including > this topic as it seems to be a potentially quixotic quest. That being > said, even if we don't find the perfect solution, it does seem > reasonable to believe there is a way to provide something more than > nothing that does help in some meaningful way. I'm not presupposing a > solution, just that there have been a few possible options discussed at > the edges which are likely to be worth more rigorous exploration. > > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? If the wg handles this carefully and pragmatically, there might be some benefit in at least documenting the topic, in terms of concerns and choices. I believe there isn't an IETF published paper in this realm, in spite of the issue appearing regularly. It might also chart out one or two pragmatic paths for change that are worth exploring. As such, this would be a non-normative discussion paper, rather than a specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From MHammer@ag.com Tue Jul 16 09:22:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0321E8086 for ; Tue, 16 Jul 2013 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnk5VOvSFK+5 for ; Tue, 16 Jul 2013 09:22:12 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8521F9BAB for ; Tue, 16 Jul 2013 09:22:11 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 12:22:10 -0400 From: "MH Michael Hammer (5304)" To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Charter improvements Thread-Index: AQHOgjqje5HXAqhl50KbbIvPVtUdmJlneh9w Date: Tue, 16 Jul 2013 16:22:09 +0000 Message-ID: References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> In-Reply-To: <51E56928.4020207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:22:21 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Trent Adams > Sent: Tuesday, July 16, 2013 11:39 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Charter improvements >=20 >=20 > Thanks, everyone, for their input on this thread (and to John for the poi= nter > how to get back to land when I blundered into the wrong stream). > Editing the proposed charter is a lot easier with this feedback. >=20 > From what I can tell, the most important question needing to be answered = is > whether or not revising the base DMARC specification is within scope of t= he > proposed work group. Following Russ's guidance, it seems that we should > start from the assumption that it's not in scope for now given the fact t= hat it's > being sponsored by an AD as an Individual Submission. >=20 +1 > Regardless of whether that's the right path, or not, let's explore it as = an > option and see how the rest of the items identified in the proposed chart= er > play out. Then we can leverage the outcome of the conversation to > potentially revisit the fate of the base specification itself. >=20 > Given that guidance, here're the most obvious (and noncontroversial?) ite= ms > needing to be done to shore up the proposed charter: >=20 > * Correct the text regarding the current path of the specification. > * Tone down the "marketing puffery". > * Clarify how to address "backward compatibility" with the installed base= . >=20 These items make sense to me. +1 > I've already updated the description of the current path of the base > specification from "Independent Submission" to "Individual Submission", s= o > that's one down. I'll pull out my red pen on the other two topics and see= if I > can make them more reasonable. >=20 > Skipping ahead. . . here're the items that have previously been proposed = as > worth exploring in the setting of an IETF work group: >=20 > ----- > * a mechanism for determining the organizational domain name based on an > arbitrary fully-qualified hostname > ----- >=20 > If I'm not mistaken, the Apps Area WG has already expressed an interest i= n > this work. In that case, I believe that this WG would only need to track = that > effort and ensure that its work addresses the use cases required to suppo= rt > DMARC. >=20 > QUESTION: Given that it's an important topic, and there's no guarantee th= at > the other effort will result in an applicable solution, would it still be > reasonable to include a mention of this as worth exploration? > If so, it'd probably make sense to reference the other work as a starting= point > to clarify we're not planning to spin up a competing solution. >=20 I personally think this is beyond the scope of the proposed working group e= ven though the issue impacts DMARC. I suppose a mention might make sense bu= t only in the sense of recognizing reality. > ----- > * a mechanism for detecting abuse involving the portion of > the RFC5322.From field > ----- >=20 > This is an interesting item in that there have been some proposals from > contributors to the base DMARC specification to address this. The proposa= ls, > as you can see, didn't make it through to a consensus and it was suggeste= d > that they be brought to the broader community for consideration. It's hig= hly > likely that through the WG process we're able to identify a means by whic= h > this issue can be addressed. >=20 > QUESTION: Does it make sense for this proposed WG to explore how the > base specification can be extended to apply the same level of "identifier > alignment" to the as is helping defend the ? >=20 I think this is beyond the scope of the working group and probably stands o= n its own as a candidate for a separate working group. This is a much more = intractable problem in that the display-name is free form. > ----- > * a mechanism for mitigating the effect of failures of DMARC policy when = a > message transits a mailing list > ----- >=20 > I recognize that there's definitely a counter-pressure against including = this > topic as it seems to be a potentially quixotic quest. That being said, ev= en if > we don't find the perfect solution, it does seem reasonable to believe th= ere > is a way to provide something more than nothing that does help in some > meaningful way. I'm not presupposing a solution, just that there have bee= n a > few possible options discussed at the edges which are likely to be worth > more rigorous exploration. >=20 > QUESTION: Is there value in a WG such as this exploring possible solution= s to > this issue and developing guidance that would potentially help improve th= e > utility of the base DMARC specification? >=20 I don't mind this topic being included but I'm not optimistic that a reason= able solution can be found other than "Dr., it hurts when I do that. Dr: Th= en don't do that!". > ----- > * support for the notion of transitive trust (i.e., "host X trusted the s= ender of > this message, and I trust X, so you should too") > ----- >=20 Definitely have an issue with this approach. It would significantly and neg= atively impact DMARC and almost introduce opportunities for abuse. > I see this as similar to the above, but potentially more broadly applicab= le. > One tweak I'd offer would be to replace ", so you should too" with > something like ", so you could choose to as well". >=20 > QUESTION: Is there value in a WG such as this exploring possible solution= s to > this issue and developing guidance that would potentially help improve th= e > utility of the base DMARC specification? >=20 > ----- > * more robust transport of reports > ----- >=20 > After over a year of deployment, and the rise in support services handlin= g > reports, many folks have suggested that it would be worth exploring how t= o > offer additional optional means of transport for reports. The base DMARC > specification provides for this, but it is an area that was left to be ex= tended > by a group such as this. Definitely worth exploring. >=20 > QUESTION: Is this an area of exploration that is of enough interest to in= clude > in the charter for this proposed work group? >=20 > Beyond those, the topics in the proposed "Using DMARC" document have > already proven useful in clarifying some options that aren't typically in= cluded > in a base specification. For example, here a few items that may benefit f= rom > being specifically called out in the charter as worth > exploring: >=20 > * Identifier alignment configuration options > * Implementation decisions regarding "pct" > * Determining effective RUA sending frequency > * Leveraging policy caching > * Various options for integrating within an existing flow > * Defining a useful, common set of RUA reporting options > * When and how to use local policy override options >=20 > QUESTION: Do any items on this list seem to be worth specifically adding = to > the proposed charter as examples of the type of work that would be useful= ? >=20 +1 for the Using DMARC document. > Finally, this list of potential work items was developed a while ago, and= it's > likely additional possible areas of exploration have surfaced since then.= Are > there any other substantive items that would be worth adding to the list? > Keeping in mind, of course, that our first cut will be to assume that the= base > specification isn't in scope for now. >=20 > Once the dust settles a bit around these items, I'll take another whack a= t the > charter text to at least get it stable for now. Then we can bubble up the > bigger question and see if we can tackle that given the input I've seen > recently on other threads. >=20 > Thanks again, > Trent >=20 >=20 Mike From sklist@kitterman.com Tue Jul 16 09:33:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6B311E80F5 for ; Tue, 16 Jul 2013 09:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvKfuck5f+4p for ; Tue, 16 Jul 2013 09:33:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC011E80ED for ; Tue, 16 Jul 2013 09:33:37 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 199E9D04066; Tue, 16 Jul 2013 12:33:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373992415; bh=E9QJunbeNozzU2UqjGS1CgCWRiFMFfInYFaJTuOpZuA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=irxSr9jTTMPVxuVj8jspia3C2cqNKh+eBMl5DZo6kbT0RToLlua5P5JP4+EXSDZRb f1Opnc4JQNw7QCKo15s1RIDIrqneeGVQEp44wYNf31T0IXnKD7KgLtA4JgDXoUoOih KRe4NFl/KWpqCHclz+r54SMuXD9McpbZhFOWPIFM= Received: from [IPV6:2600:1003:b105:fdb3:bf9:f71c:e0d7:5bea] (unknown [IPv6:2600:1003:b105:fdb3:bf9:f71c:e0d7:5bea]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9B25FD0405E; Tue, 16 Jul 2013 12:33:34 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <51E56928.4020207@gmail.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 16 Jul 2013 12:33:34 -0400 To: "dmarc@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:33:45 -0000 "J. Trent Adams" wrote: > >Thanks, everyone, for their input on this thread (and to John for the >pointer how to get back to land when I blundered into the wrong >stream). >Editing the proposed charter is a lot easier with this feedback. > >From what I can tell, the most important question needing to be >answered >is whether or not revising the base DMARC specification is within scope >of the proposed work group. Following Russ's guidance, it seems that we >should start from the assumption that it's not in scope for now given >the fact that it's being sponsored by an AD as an Individual >Submission. > >Regardless of whether that's the right path, or not, let's explore it >as >an option and see how the rest of the items identified in the proposed >charter play out. Then we can leverage the outcome of the conversation >to potentially revisit the fate of the base specification itself. If the base spec is out of scope, I think the entire effort should be deferred until after it's done. I don't think it makes sense to spin up a working group to work on extensions until they can leverage a stable foundation. Scott K From prvs=902145067=kandersen@linkedin.com Tue Jul 16 09:35:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA25111E80E9 for ; Tue, 16 Jul 2013 09:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 MiS6p2DcnU3Q for ; Tue, 16 Jul 2013 09:35:47 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 028C321E80A1 for ; Tue, 16 Jul 2013 09:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1373992539; x=1405528539; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kQ996a/CM9Ctu+90prRmeb9Suv0+GHidyD8kEwHvYqw=; b=fk2Ex7h10txYul71xmpIwFfPzYINVixEsgV2jOiqh4AzLhURPXiv4MYj 3zWwuGDsE18dd2dV6nA4lCmKroHHlFCt34LlaKgtTHRzPjFJHotM+lFh4 H/GccPJrLpR/rU2ohDjyvPEFSl8JZQJKWx1XO6eaJbqwB/SYqXMi9pl8/ 0=; X-IronPort-AV: E=Sophos;i="4.89,678,1367996400"; d="scan'208";a="54367923" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 16 Jul 2013 09:35:21 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 09:35:21 -0700 From: Kurt Andersen To: "MH Michael Hammer (5304)" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Charter improvements Thread-Index: AQHOduTxI2V4I5harUK2ilq5D3M9h5lSXh6AgAB7B4CAFSOwAIAAC/aA//+OZoA= Date: Tue, 16 Jul 2013 16:35:20 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B72839509739F1B@ESV4-EXC02.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D5F2C84DBD64841BCB9B45E3A1EAD2D@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:35:51 -0000 On 2013-07-16 09:22 , "MH Michael Hammer (5304)" wrote: >>----- >>* support for the notion of transitive trust (i.e., "host X trusted the >>sender of >>this message, and I trust X, so you should too") >>----- > >Definitely have an issue with this approach. It would significantly and >negatively impact DMARC and almost introduce opportunities for abuse. Did you perhaps mean to say ". . .almost *certainly* introduce opportunities for abuse"? That would be my thought on the subject as trust has rarely been transitive. --Kurt Andersen LinkedIn From john.kelley@teamaol.com Tue Jul 16 10:29:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5441521F9A2A for ; Tue, 16 Jul 2013 10:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoJLiQ+wEkHm for ; Tue, 16 Jul 2013 10:29:35 -0700 (PDT) Received: from omr-d03.mx.aol.com (omr-d03.mx.aol.com [205.188.109.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA1F21F991E for ; Tue, 16 Jul 2013 10:29:35 -0700 (PDT) Received: from AOLDTCMEI31.ad.aol.aoltw.net (aoldtcmei31.office.aol.com [10.180.121.109]) by omr-d03.mx.aol.com (Outbound Mail Relay) with ESMTP id 2F78C700B048B for ; Tue, 16 Jul 2013 13:29:34 -0400 (EDT) Received: from AOLDTCMES31.ad.aol.aoltw.net ([169.254.8.227]) by AOLDTCMEI31.ad.aol.aoltw.net ([10.180.121.108]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 13:29:34 -0400 From: "Kelley, John" To: "J. Trent Adams" Thread-Topic: [dmarc-ietf] Charter improvements Thread-Index: AQHOduT0Pyi+C7IeHkuLGYN+GiJe1JlSK9OAgAB7B4CAFSOwAIAAHs8A Date: Tue, 16 Jul 2013 17:29:32 +0000 Message-ID: <033CB4C9-979B-42B5-A0FE-8D0EB33B0E6C@teamaol.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> In-Reply-To: <51E56928.4020207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.8.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:29:39 -0000 On Jul 16, 2013, at 11:39 AM, J. Trent Adams wrote: >=20 > Thanks, everyone, for their input on this thread (and to John for the > pointer how to get back to land when I blundered into the wrong stream). > Editing the proposed charter is a lot easier with this feedback. >=20 > From what I can tell, the most important question needing to be answered > is whether or not revising the base DMARC specification is within scope > of the proposed work group. Following Russ's guidance, it seems that we > should start from the assumption that it's not in scope for now given > the fact that it's being sponsored by an AD as an Individual Submission. >=20 > Regardless of whether that's the right path, or not, let's explore it as > an option and see how the rest of the items identified in the proposed > charter play out. Then we can leverage the outcome of the conversation > to potentially revisit the fate of the base specification itself. >=20 > Given that guidance, here're the most obvious (and noncontroversial?) > items needing to be done to shore up the proposed charter: >=20 > * Correct the text regarding the current path of the specification. > * Tone down the "marketing puffery". > * Clarify how to address "backward compatibility" with the installed base= . >=20 > I've already updated the description of the current path of the base > specification from "Independent Submission" to "Individual Submission", > so that's one down. I'll pull out my red pen on the other two topics and > see if I can make them more reasonable. >=20 > Skipping ahead. . . here're the items that have previously been proposed > as worth exploring in the setting of an IETF work group: >=20 > ----- > * a mechanism for determining the organizational domain name based on an > arbitrary fully-qualified hostname > ----- >=20 > If I'm not mistaken, the Apps Area WG has already expressed an interest > in this work. In that case, I believe that this WG would only need to > track that effort and ensure that its work addresses the use cases > required to support DMARC. >=20 > QUESTION: Given that it's an important topic, and there's no guarantee > that the other effort will result in an applicable solution, would it > still be reasonable to include a mention of this as worth exploration? > If so, it'd probably make sense to reference the other work as a > starting point to clarify we're not planning to spin up a competing > solution. +1 I agree with monitor and only address if needed. A mention about the ot= her work is fine. >=20 > ----- > * a mechanism for detecting abuse involving the portion > of the RFC5322.From field > ----- >=20 > This is an interesting item in that there have been some proposals from > contributors to the base DMARC specification to address this. The > proposals, as you can see, didn't make it through to a consensus and it > was suggested that they be brought to the broader community for > consideration. It's highly likely that through the WG process we're able > to identify a means by which this issue can be addressed. >=20 > QUESTION: Does it make sense for this proposed WG to explore how the > base specification can be extended to apply the same level of > "identifier alignment" to the as is helping defend the > ? >=20 +1=20 > ----- > * a mechanism for mitigating the effect of failures of DMARC policy when > a message transits a mailing list > ----- >=20 > I recognize that there's definitely a counter-pressure against including > this topic as it seems to be a potentially quixotic quest. That being > said, even if we don't find the perfect solution, it does seem > reasonable to believe there is a way to provide something more than > nothing that does help in some meaningful way. I'm not presupposing a > solution, just that there have been a few possible options discussed at > the edges which are likely to be worth more rigorous exploration. >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? >=20 -1 Not sure what continued debate here would accomplish. =20 > ----- > * support for the notion of transitive trust (i.e., "host X trusted the > sender of this message, and I trust X, so you should too") > ----- >=20 > I see this as similar to the above, but potentially more broadly > applicable. One tweak I'd offer would be to replace ", so you should > too" with something like ", so you could choose to as well". >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? >=20 +1 I agree there is a potential value added for transitive trust. I am no= t completely sold that a DMARC group is the place to hammer it out, but its= probably worth discussing.=20 > ----- > * more robust transport of reports > ----- >=20 > After over a year of deployment, and the rise in support services > handling reports, many folks have suggested that it would be worth > exploring how to offer additional optional means of transport for > reports. The base DMARC specification provides for this, but it is an > area that was left to be extended by a group such as this. >=20 > QUESTION: Is this an area of exploration that is of enough interest to > include in the charter for this proposed work group? >=20 +1 =20 > Beyond those, the topics in the proposed "Using DMARC" document have > already proven useful in clarifying some options that aren't typically > included in a base specification. For example, here a few items that may > benefit from being specifically called out in the charter as worth > exploring: >=20 > * Identifier alignment configuration options > * Implementation decisions regarding "pct" > * Determining effective RUA sending frequency > * Leveraging policy caching > * Various options for integrating within an existing flow > * Defining a useful, common set of RUA reporting options > * When and how to use local policy override options >=20 > QUESTION: Do any items on this list seem to be worth specifically adding > to the proposed charter as examples of the type of work that would be > useful? >=20 None of those items are jumping out at me as something that MUST be part of= the WG output. > Finally, this list of potential work items was developed a while ago, > and it's likely additional possible areas of exploration have surfaced > since then. Are there any other substantive items that would be worth > adding to the list? Keeping in mind, of course, that our first cut will > be to assume that the base specification isn't in scope for now. >=20 Nothing comes to mind > Once the dust settles a bit around these items, I'll take another whack > at the charter text to at least get it stable for now. Then we can > bubble up the bigger question and see if we can tackle that given the > input I've seen recently on other threads. >=20 > Thanks again, > Trent >=20 John Kelley >=20 > On 7/2/13 10:50 PM, Matt Simerson wrote: >> On Jul 2, 2013, at 2:29 PM, "Rolf E. Sonneveld" wrote: >>=20 >>>> In view of the large base of running DMARC >>>> code, the group will avoid changes that would cause incompatible >>>> changes to bits on the wire. >>> -1 >>>=20 >>> Granted, the installed base is large, but let's not ignore the other 40= percent of the Internet. IETF standards are standards for the _entire_ Int= ernet community, not just ten or twenty of the largest companies in a speci= fic area. The WG should not be bound by 'bits on the wire' in their review = and possible comments on the standard. Otherwise the IETF is to a large ext= ent degraded to the 'rubber stamp business' Scott mentioned. >>>=20 >>> Don't get me wrong: the outcome of the discussions may well be that not= hing will change on the wire and that'd be fine. But including this in the = Charter as a precondition for the work to be done is wrong in my opinion. >> +1 to Rolf's -1.=20 >>=20 >> I'm happy to see DMARC moving towards becoming a standard. Validation of= incoming messages is a great feature. Reporting is more timely and structu= red than bounce messages. But for the vast majority of mail senders, DMARC = is close to useless because of the forwarder / mailing list issue.=20 >>=20 >> "DMARC policies are not appropriate for domains with users who send mai= l through mailing lists" --John R Levine >>=20 >> "SMTP refusal to an unmapped-but-reliable forwarder is likely to cause = list unsubscription." --Roland Turner >>=20 >> The mailing list issue is intractable and also a huge implementation bar= rier that is barely documented. For legit domain owners (ie, not abusers) t= hat wish to use DMARC to curtail phishing from their domains, they will nee= d to choose between losing legit mail (DMARC + mailing lists) or not losing= legit mail (no DMARC).=20 >>=20 >> Most of the broader internet community does not have the resources to "m= ap the exit IP addresses of well-behaved forwarders and ignore DMARC result= s for messages that come from those addresses." As such, many domain owner= s will deploy DMARC, lose valid mail, and then reject the technology. >>=20 >> While it may be kinda sorta true that DMARC "protects 60% of global cons= umer mailboxes," it seems to be marketing puffery. While 60% of global mai= lboxes may have some form of DMARC validation, the number of legit domains = that do and potentially *can* deploy DMARC records is absurdly low.=20 >>=20 >> Other minor Issues such as report loops (DMARC reporters reporting each = others DMARC reports to each other ad infinitum) are minor and have simple = (but not yet documented) workarounds but could also be addressed technicall= y, rather than requiring workaround documentation. >>=20 >> Matt >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 > --=20 > J. Trent Adams >=20 > Profile: http://www.mediaslate.org/jtrentadams/ > LinkedIN: http://www.linkedin.com/in/jtrentadams > Twitter: http://twitter.com/jtrentadams >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From dcrocker@gmail.com Tue Jul 16 13:01:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3321F9EAF for ; Tue, 16 Jul 2013 13:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdR06tEHSYtM for ; Tue, 16 Jul 2013 13:01:18 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D01C21F9D9A for ; Tue, 16 Jul 2013 13:01:18 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so1422238oag.8 for ; Tue, 16 Jul 2013 13:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mm8i1vtJTMv6Dh9/D/PxWFNh16/mtauS1Iz3p1eY48E=; b=E89lgotltYkYI/VIwV3cRjw8DJi//Lvk4alnx+QdpLUvx5O7Z5adBC9KqLF/FlEhgi VNuNAiGeI8+/gWyavcB7urX98QvpSK0btt1+mGbARag6ETuOMH3WZF0U+HCJcjWwwAEs v/TrGH3HOsfDc3VVnr61uyWj6rdfjr4d4glMg/aX4j7FIF5ZcDrLJxw9cagqH3dWKw17 KLWGF5VLCZeWoQY9PBWF01ifsUjZb+jt7aIYeSvXtdFoV59t2ruo22lOoyjXnLur67a8 aOf9QC/Fl6UpSMrNpL7WVDaBHGL0Mt5/NcozV5Fq3HupeIr/8Po0eGbfCs/NR5tcFRsj 60vQ== X-Received: by 10.60.155.169 with SMTP id vx9mr3725031oeb.93.1374004875783; Tue, 16 Jul 2013 13:01:15 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id hm1sm2537352obb.9.2013.07.16.13.01.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 13:01:15 -0700 (PDT) Message-ID: <51E5A667.50503@gmail.com> Date: Tue, 16 Jul 2013 13:00:39 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:01:19 -0000 On 7/16/2013 9:33 AM, Scott Kitterman wrote: > If the base spec is out of scope, I think the entire effort should be > deferred until after it's done. I don't think it makes sense to spin > up a working group to work on extensions until they can leverage a > stable foundation. Huh? Given: 1. There is no community support for any proposals to change the bits-over-the-wire. 2. The current bits-over-the-wire protocol is widely deployed and is used for a very large fraction of the Internet's email traffic. Then if that does not constitute the ultimate form of "stable foundation", then I can't guess what you mean. Please explain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mjones@agari.com Tue Jul 16 22:19:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4676321F9AD6 for ; Tue, 16 Jul 2013 22:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF6k1imVzg08 for ; Tue, 16 Jul 2013 22:19:49 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7421F9A05 for ; Tue, 16 Jul 2013 22:19:49 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld11so1558330pab.22 for ; Tue, 16 Jul 2013 22:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer; bh=jeEbx1KF+aTcAnFkZWraRUv7Qr6hVdWA28zIGznxG6w=; b=oeiFMxXtT6Ex36+4CNvdVsOxLWUv+P35Gmv5eWXdfBQUd96s4rl26IBK8YJR7mq6n4 bjrK9fLP6jIzLaH4TLRQ62JnKnirzPZFChGFcvd7Z9osY6xQJ1QULdPxtgziZyj6EpJz E36Wg5RMrZyTghogOPGpWNy2xNlG+dK2R0d0M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer:x-gm-message-state; bh=jeEbx1KF+aTcAnFkZWraRUv7Qr6hVdWA28zIGznxG6w=; b=iQfA77zSf5p28ci4lfeC1QBT39v17hoGATYBdCGxMfwY56ZLDkSE6I9w3ieooUyl70 8YX5QVe4cXGLAP3+IBb1DzjVFCJAyVXTD3EV2yLtmbuD5xrpOnGgme6P70DqiLZzCuwV 0jBemyekGbInVqY6LZ9TFbjEsS2mTdk/wccT1kwDYqlXWtHCHV1h1zyClp7DJ8pLB5c9 s3u667dLVSXdGT2DuHsEXxIrKeybgu6DwfIQmsHOJ5cPNUriWV534SME8XD4KLSrMyzt JFB1PMjHVq9QhR8NvoVn2GOGkdoZ47mW0crmUgRG5bsAvevtPtTXb7qTJrOkjErPcU1V McTg== X-Received: by 10.68.251.234 with SMTP id zn10mr4824887pbc.188.1374038389221; Tue, 16 Jul 2013 22:19:49 -0700 (PDT) Received: from [192.168.0.14] (c-24-4-3-179.hsd1.ca.comcast.net. [24.4.3.179]) by mx.google.com with ESMTPSA id ht5sm5551649pbb.29.2013.07.16.22.19.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 22:19:48 -0700 (PDT) From: Mike Jones Content-Type: multipart/alternative; boundary="Apple-Mail=_83F3FD39-27C9-4A47-B7B1-19BDC9E07DC4" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 16 Jul 2013 22:19:46 -0700 References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> To: "J. Trent Adams" , "dmarc@ietf.org" In-Reply-To: <51E56928.4020207@gmail.com> X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQm8NZj4ceorSPsRe068u8A5l+Jg2yL3sCLMCuP4T8FYZP5jpuaJE3uy+OynutSNz33bxyWF Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:19:51 -0000 --Apple-Mail=_83F3FD39-27C9-4A47-B7B1-19BDC9E07DC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 16, 2013, at 8:39 AM, J. Trent Adams = wrote: >=20 > Thanks, everyone, for their input on this thread (and to John for the > pointer how to get back to land when I blundered into the wrong = stream). > Editing the proposed charter is a lot easier with this feedback. >=20 > =46rom what I can tell, the most important question needing to be = answered > is whether or not revising the base DMARC specification is within = scope > of the proposed work group. Following Russ's guidance, it seems that = we > should start from the assumption that it's not in scope for now given > the fact that it's being sponsored by an AD as an Individual = Submission. >=20 > Regardless of whether that's the right path, or not, let's explore it = as > an option and see how the rest of the items identified in the proposed > charter play out. Then we can leverage the outcome of the conversation > to potentially revisit the fate of the base specification itself. >=20 > Given that guidance, here're the most obvious (and noncontroversial?) > items needing to be done to shore up the proposed charter: >=20 > * Correct the text regarding the current path of the specification. > * Tone down the "marketing puffery". > * Clarify how to address "backward compatibility" with the installed = base. >=20 > I've already updated the description of the current path of the base > specification from "Independent Submission" to "Individual = Submission", > so that's one down. I'll pull out my red pen on the other two topics = and > see if I can make them more reasonable. +1=20 >=20 > Skipping ahead. . . here're the items that have previously been = proposed > as worth exploring in the setting of an IETF work group: >=20 > ----- > * a mechanism for determining the organizational domain name based on = an > arbitrary fully-qualified hostname > ----- >=20 > If I'm not mistaken, the Apps Area WG has already expressed an = interest > in this work. In that case, I believe that this WG would only need to > track that effort and ensure that its work addresses the use cases > required to support DMARC. >=20 > QUESTION: Given that it's an important topic, and there's no guarantee > that the other effort will result in an applicable solution, would it > still be reasonable to include a mention of this as worth exploration? > If so, it'd probably make sense to reference the other work as a > starting point to clarify we're not planning to spin up a competing > solution. I think if it is expected to be addressed by another WG then only a = reference to that work is appropriate. I think even a mention of = exploring it in this DMARC WG would be overreaching. >=20 > ----- > * a mechanism for detecting abuse involving the portion > of the RFC5322.=46rom field > ----- >=20 > This is an interesting item in that there have been some proposals = from > contributors to the base DMARC specification to address this. The > proposals, as you can see, didn't make it through to a consensus and = it > was suggested that they be brought to the broader community for > consideration. It's highly likely that through the WG process we're = able > to identify a means by which this issue can be addressed. >=20 > QUESTION: Does it make sense for this proposed WG to explore how the > base specification can be extended to apply the same level of > "identifier alignment" to the as is helping defend the > ? >=20 Yes, this would be a worthwhile discussion for a DMARC WG. Maybe it is = unlikely that a means to address this is identified as an extension to = DMARC, but it's a real problem and worth the effort to discuss. > ----- > * a mechanism for mitigating the effect of failures of DMARC policy = when > a message transits a mailing list > ----- >=20 > I recognize that there's definitely a counter-pressure against = including > this topic as it seems to be a potentially quixotic quest. That being > said, even if we don't find the perfect solution, it does seem > reasonable to believe there is a way to provide something more than > nothing that does help in some meaningful way. I'm not presupposing a > solution, just that there have been a few possible options discussed = at > the edges which are likely to be worth more rigorous exploration. >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? >=20 Yes, I believe so. > ----- > * support for the notion of transitive trust (i.e., "host X trusted = the > sender of this message, and I trust X, so you should too") > ----- >=20 > I see this as similar to the above, but potentially more broadly > applicable. One tweak I'd offer would be to replace ", so you should > too" with something like ", so you could choose to as well". >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? This one is a maybe for me. I could see value in the discussion, but = think it is far less likely a WG reaches any consensus on this than on = the previous two items.=20 >=20 > ----- > * more robust transport of reports > ----- >=20 > After over a year of deployment, and the rise in support services > handling reports, many folks have suggested that it would be worth > exploring how to offer additional optional means of transport for > reports. The base DMARC specification provides for this, but it is an > area that was left to be extended by a group such as this. >=20 > QUESTION: Is this an area of exploration that is of enough interest to > include in the charter for this proposed work group? Yes.=20 >=20 > Beyond those, the topics in the proposed "Using DMARC" document have > already proven useful in clarifying some options that aren't typically > included in a base specification. For example, here a few items that = may > benefit from being specifically called out in the charter as worth > exploring: >=20 > * Identifier alignment configuration options > * Implementation decisions regarding "pct" > * Determining effective RUA sending frequency > * Leveraging policy caching > * Various options for integrating within an existing flow > * Defining a useful, common set of RUA reporting options > * When and how to use local policy override options >=20 > QUESTION: Do any items on this list seem to be worth specifically = adding > to the proposed charter as examples of the type of work that would be > useful? >=20 Yes to all of the items on the list from the "Using DMARC" document. > Finally, this list of potential work items was developed a while ago, > and it's likely additional possible areas of exploration have surfaced > since then. Are there any other substantive items that would be worth > adding to the list? Keeping in mind, of course, that our first cut = will > be to assume that the base specification isn't in scope for now. >=20 > Once the dust settles a bit around these items, I'll take another = whack > at the charter text to at least get it stable for now. Then we can > bubble up the bigger question and see if we can tackle that given the > input I've seen recently on other threads. >=20 > Thanks again, > Trent >=20 Thanks,=20 Mike Jones Agari mjones@agari.com --Apple-Mail=_83F3FD39-27C9-4A47-B7B1-19BDC9E07DC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
jtrentadams@gmail.com> = wrote:


Thanks, everyone, for their input on this thread (and = to John for the
pointer how to get back to land when I blundered into = the wrong stream).
Editing the proposed charter is a lot easier with = this feedback.

=46rom what I can tell, the most important = question needing to be answered
is whether or not revising the base = DMARC specification is within scope
of the proposed work group. = Following Russ's guidance, it seems that we
should start from the = assumption that it's not in scope for now given
the fact that it's = being sponsored by an AD as an Individual Submission.

Regardless = of whether that's the right path, or not, let's explore it as
an = option and see how the rest of the items identified in the = proposed
charter play out. Then we can leverage the outcome of the = conversation
to potentially revisit the fate of the base = specification itself.

Given that guidance, here're the most = obvious (and noncontroversial?)
items needing to be done to shore up = the proposed charter:

* Correct the text regarding the current = path of the specification.
* Tone down the "marketing puffery".
* = Clarify how to address "backward compatibility" with the installed = base.

I've already updated the description of the current path of = the base
specification from "Independent Submission" to "Individual = Submission",
so that's one down. I'll pull out my red pen on the = other two topics and
see if I can make them more = reasonable.

+1 


Skipping ahead. . . here're the items that have = previously been proposed
as worth exploring in the setting of an IETF = work group:

-----
* a mechanism for determining the = organizational domain name based on an
arbitrary fully-qualified = hostname
-----

If I'm not mistaken, the Apps Area WG has = already expressed an interest
in this work. In that case, I believe = that this WG would only need to
track that effort and ensure that its = work addresses the use cases
required to support = DMARC.

QUESTION: Given that = it's an important topic, and there's no guarantee
that the other = effort will result in an applicable solution, would it
still be = reasonable to include a mention of this as worth exploration?
If so, = it'd probably make sense to reference the other work as a
starting = point to clarify we're not planning to spin up a = competing
solution.

I think if it = is expected to be addressed by another WG then only a reference to that = work is appropriate.  I think even a mention of exploring it in = this DMARC WG would be overreaching.


-----
* a mechanism for detecting abuse involving = the <display-name> portion
of the RFC5322.=46rom = field
-----

This is an interesting item in that there have = been some proposals from
contributors to the base DMARC specification = to address this. The
proposals, as you can see, didn't make it = through to a consensus and it
was suggested that they be brought to = the broader community for
consideration. It's highly likely that = through the WG process we're able
to identify a means by which this = issue can be addressed.

QUESTION: Does it make sense for this = proposed WG to explore how the
base specification can be extended to = apply the same level of
"identifier alignment" to the = <display-name> as is helping defend = the
<address-spec>?


Yes, = this would be a worthwhile discussion for a DMARC WG.  Maybe it is = unlikely that a means to address this is identified as an extension to = DMARC, but it's a real problem and worth the effort to = discuss.


-----
* a = mechanism for mitigating the effect of failures of DMARC policy = when
a message transits a mailing list
-----

I recognize = that there's definitely a counter-pressure against including
this = topic as it seems to be a potentially quixotic quest. That = being
said, even if we don't find the perfect solution, it does = seem
reasonable to believe there is a way to provide something more = than
nothing that does help in some meaningful way. I'm not = presupposing a
solution, just that there have been a few possible = options discussed at
the edges which are likely to be worth more = rigorous exploration.

QUESTION: Is there value in a WG such as = this exploring possible
solutions to this issue and developing = guidance that would potentially
help improve the utility of the base = DMARC specification?


Yes, I = believe so.


-----
* = support for the notion of transitive trust (i.e., "host X trusted = the
sender of this message, and I trust X, so you should = too")
-----

I see this as similar to the above, but = potentially more broadly
applicable. One tweak I'd offer would be to = replace ", so you should
too" with something like ", so you could = choose to as well".

QUESTION: Is there value in a WG such as this = exploring possible
solutions to this issue and developing guidance = that would potentially
help improve the utility of the base DMARC = specification?

This one is a maybe = for me.  I could see value in the discussion, but think it is far = less likely a WG reaches any consensus on this than on the previous two = items. 



-----
* more robust transport of = reports
-----

After over a year of deployment, and the rise in = support services
handling reports, many folks have suggested that it = would be worth
exploring how to offer additional optional means of = transport for
reports. The base DMARC specification provides for = this, but it is an
area that was left to be extended by a group such = as this.

QUESTION: Is this an area of exploration that is of = enough interest to
include in the charter for this proposed work = group?

Yes. 

=

Beyond those, the topics in the = proposed "Using DMARC" document have
already proven useful in = clarifying some options that aren't typically
included in a base = specification. For example, here a few items that may
benefit from = being specifically called out in the charter as = worth
exploring:

* Identifier alignment configuration = options
* Implementation decisions regarding "pct"
* Determining = effective RUA sending frequency
* Leveraging policy caching
* = Various options for integrating within an existing flow
* Defining a = useful, common set of RUA reporting options
* When and how to use = local policy override options

QUESTION: Do any items on this list = seem to be worth specifically adding
to the proposed charter as = examples of the type of work that would = be
useful?


Yes to all of the = items on the list from the "Using DMARC" = document.


Finally, = this list of potential work items was developed a while ago,
and it's = likely additional possible areas of exploration have surfaced
since = then. Are there any other substantive items that would be = worth
adding to the list? Keeping in mind, of course, that our first = cut will
be to assume that the base specification isn't in scope for = now.

Once the dust settles a bit around these items, I'll take = another whack
at the charter text to at least get it stable for now. = Then we can
bubble up the bigger question and see if we can tackle = that given the
input I've seen recently on other = threads.

Thanks = again,
Trent



Thanks, 

Mike = Jones
Agari
mjones@agari.com Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:46:58 -0000 On Jul 16, 2013, at 8:39 AM, J. Trent Adams = wrote: >=20 > Thanks, everyone, for their input on this thread (and to John for the > pointer how to get back to land when I blundered into the wrong = stream). > Editing the proposed charter is a lot easier with this feedback. >=20 > =46rom what I can tell, the most important question needing to be = answered > is whether or not revising the base DMARC specification is within = scope > of the proposed work group. Following Russ's guidance, it seems that = we > should start from the assumption that it's not in scope for now given > the fact that it's being sponsored by an AD as an Individual = Submission. >=20 > Regardless of whether that's the right path, or not, let's explore it = as > an option and see how the rest of the items identified in the proposed > charter play out. Then we can leverage the outcome of the conversation > to potentially revisit the fate of the base specification itself. >=20 > Given that guidance, here're the most obvious (and noncontroversial?) > items needing to be done to shore up the proposed charter: >=20 > * Correct the text regarding the current path of the specification. > * Tone down the "marketing puffery". > * Clarify how to address "backward compatibility" with the installed = base. >=20 > I've already updated the description of the current path of the base > specification from "Independent Submission" to "Individual = Submission", > so that's one down. I'll pull out my red pen on the other two topics = and > see if I can make them more reasonable. >=20 > Skipping ahead. . . here're the items that have previously been = proposed > as worth exploring in the setting of an IETF work group: >=20 > ----- > * a mechanism for determining the organizational domain name based on = an > arbitrary fully-qualified hostname > ----- >=20 > If I'm not mistaken, the Apps Area WG has already expressed an = interest > in this work. In that case, I believe that this WG would only need to > track that effort and ensure that its work addresses the use cases > required to support DMARC. >=20 > QUESTION: Given that it's an important topic, and there's no guarantee > that the other effort will result in an applicable solution, would it > still be reasonable to include a mention of this as worth exploration? > If so, it'd probably make sense to reference the other work as a > starting point to clarify we're not planning to spin up a competing > solution. >=20 Isn't it the place where the BCP could answer that question, by giving = guidance on how to do it pending a standard? > ----- > * a mechanism for detecting abuse involving the portion > of the RFC5322.=46rom field > ----- >=20 > This is an interesting item in that there have been some proposals = from > contributors to the base DMARC specification to address this. The > proposals, as you can see, didn't make it through to a consensus and = it > was suggested that they be brought to the broader community for > consideration. It's highly likely that through the WG process we're = able > to identify a means by which this issue can be addressed. >=20 > QUESTION: Does it make sense for this proposed WG to explore how the > base specification can be extended to apply the same level of > "identifier alignment" to the as is helping defend the > ? >=20 why not > ----- > * a mechanism for mitigating the effect of failures of DMARC policy = when > a message transits a mailing list > ----- >=20 > I recognize that there's definitely a counter-pressure against = including > this topic as it seems to be a potentially quixotic quest. That being > said, even if we don't find the perfect solution, it does seem > reasonable to believe there is a way to provide something more than > nothing that does help in some meaningful way. I'm not presupposing a > solution, just that there have been a few possible options discussed = at > the edges which are likely to be worth more rigorous exploration. >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? >=20 This is a hot topic, and it smells a lot like qmail, but people will = want to protect any domain. It seems rather to me the question is once a = domain has p=3Dreject what the miscreants do? Where the next protection = should be put on? I'm not saying bad stuff happen through mailing lists, = I'm saying bad stuff will happen to other domains (and there is a whole = bunch coming up). It seems also to me we have the problem of defining = what is a mailing list, in a similar way what is an organizational = domain. Everyone knows when they see one, but not can define it in a = machine parseable way. > ----- > * support for the notion of transitive trust (i.e., "host X trusted = the > sender of this message, and I trust X, so you should too") > ----- >=20 > I see this as similar to the above, but potentially more broadly > applicable. One tweak I'd offer would be to replace ", so you should > too" with something like ", so you could choose to as well". >=20 > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? >=20 is there transitive trust defined in other IETF documents? > ----- > * more robust transport of reports > ----- >=20 > After over a year of deployment, and the rise in support services > handling reports, many folks have suggested that it would be worth > exploring how to offer additional optional means of transport for > reports. The base DMARC specification provides for this, but it is an > area that was left to be extended by a group such as this. >=20 > QUESTION: Is this an area of exploration that is of enough interest to > include in the charter for this proposed work group? >=20 > Beyond those, the topics in the proposed "Using DMARC" document have > already proven useful in clarifying some options that aren't typically > included in a base specification. For example, here a few items that = may > benefit from being specifically called out in the charter as worth > exploring: >=20 > * Identifier alignment configuration options > * Implementation decisions regarding "pct" > * Determining effective RUA sending frequency > * Leveraging policy caching > * Various options for integrating within an existing flow > * Defining a useful, common set of RUA reporting options > * When and how to use local policy override options A lot of it is gained thru operational experience, common sense and = level of threat. A BCP to help implementation whould answer a lot of = these questions >=20 > QUESTION: Do any items on this list seem to be worth specifically = adding > to the proposed charter as examples of the type of work that would be > useful? >=20 > Finally, this list of potential work items was developed a while ago, > and it's likely additional possible areas of exploration have surfaced > since then. Are there any other substantive items that would be worth > adding to the list? Keeping in mind, of course, that our first cut = will > be to assume that the base specification isn't in scope for now. >=20 > Once the dust settles a bit around these items, I'll take another = whack > at the charter text to at least get it stable for now. Then we can > bubble up the bigger question and see if we can tackle that given the > input I've seen recently on other threads. >=20 I have the feeling that DMARC brings the subject of domain reputation = and becoming stricter in what we receive. = draft-ietf-appsawg-malformed-mail is a step in that direction, but may = be we need to examine the problem more broadly of cousin domains and = other forms of non direct domain spoofing. What are the tools we have = today to handle them? > Thanks again, > Trent >=20 From housley@vigilsec.com Wed Jul 17 12:39:57 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C3A11E80E6 for ; Wed, 17 Jul 2013 12:39:57 -0700 (PDT) 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 5Qx8EzPsEPON for ; Wed, 17 Jul 2013 12:39:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B751711E80E9 for ; Wed, 17 Jul 2013 12:39:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 45BACF240BB for ; Wed, 17 Jul 2013 15:40:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 7q8yFvxUqJdf for ; Wed, 17 Jul 2013 15:39:34 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-212-98.washdc.fios.verizon.net [96.241.212.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 10880F2407C for ; Wed, 17 Jul 2013 15:40:13 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jul 2013 15:39:49 -0400 References: <20130717191223.2E1CA8E019@rfc-editor.org> To: dmarc@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [dmarc-ietf] Fwd: RFC 6982 on Improving Awareness of Running Code: The Implementation Status Section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:39:57 -0000 X-List-Received-Date: Wed, 17 Jul 2013 19:39:57 -0000 This seems to offer guidance that is relevant to the DMARC situation. Begin forwarded message: > From: rfc-editor@rfc-editor.org > Date: July 17, 2013 3:12:23 PM EDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > Subject: RFC 6982 on Improving Awareness of Running Code: The = Implementation Status Section > Reply-To: ietf@ietf.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6982 >=20 > Title: Improving Awareness of Running Code:=20 > The Implementation Status Section=20 > Author: Y. Sheffer, A. Farrel > Status: Experimental > Stream: IETF > Date: July 2013 > Mailbox: yaronf.ietf@gmail.com,=20 > adrian@olddog.co.uk > Pages: 9 > Characters: 19358 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-sheffer-running-code-06.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6982.txt >=20 > This document describes a simple process that allows authors of > Internet-Drafts to record the status of known implementations by > including an Implementation Status section. This will allow > reviewers and working groups to assign due consideration to documents > that have the benefit of running code, which may serve as evidence of > valuable experimentation and feedback that have made the implemented > protocols more mature. >=20 > The process in this document is offered as an experiment. Authors of > Internet-Drafts are encouraged to consider using the process for > their documents, and working groups are invited to think about > applying the process to all of their protocol specifications. The > authors of this document intend to collate experiences with this > experiment and to report them to the community. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. From superuser@gmail.com Wed Jul 17 16:09:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA4E21F99C0 for ; Wed, 17 Jul 2013 16:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ahrlaVeuMF for ; Wed, 17 Jul 2013 16:09:25 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6095721F9A99 for ; Wed, 17 Jul 2013 16:09:25 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so2322991wgg.10 for ; Wed, 17 Jul 2013 16:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gGLuLSKHbYY6x6BuFLIOR1o/Lj4LEcmNvKbBtqXmLeM=; b=weFOdv6mIufGGl1E8UdCx6ZKNllcXkrHsV0GBjLGV/RXG8+mTCJNnMlpgFkoywan+V INVyjF1BQC48cVN2YNXy4OcjpBW2dZt+TeUDsoiKVmGUh7hC3KdpPs1OrAjoevEbcbwN TmRUX/lyZJNtSToXMtanWIvN154E8+UFaDMcGubyjzztYEp+IIv55wz+xrU+WfY1AyZb ysb4ngoH7H/f4XEi3RtzTPb9i0M1s2FQjZSqR6UeqncWeZUuzXzTv9RKA5R2j5/cVDXE Sa/6C4qIbZ2eYBlAAWvxWlXZ1eg+B6e4LSGvV7QV8X7a9fgorujp8ACJVk5Z9Qi9y/ry uPAw== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr6545578wjc.63.1374102560476; Wed, 17 Jul 2013 16:09:20 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Wed, 17 Jul 2013 16:09:20 -0700 (PDT) In-Reply-To: References: <20130717191223.2E1CA8E019@rfc-editor.org> Date: Wed, 17 Jul 2013 16:09:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Russ Housley Content-Type: multipart/alternative; boundary=089e014933840095d504e1bd2ff9 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: RFC 6982 on Improving Awareness of Running Code: The Implementation Status Section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 23:09:26 -0000 --089e014933840095d504e1bd2ff9 Content-Type: text/plain; charset=ISO-8859-1 For what it's worth, I just did this for RFC5451bis and the IESG was quite appreciative of it during the evaluation phase. -MSK On Wed, Jul 17, 2013 at 12:39 PM, Russ Housley wrote: > This seems to offer guidance that is relevant to the DMARC situation. > > Begin forwarded message: > > > From: rfc-editor@rfc-editor.org > > Date: July 17, 2013 3:12:23 PM EDT > > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > > Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > > Subject: RFC 6982 on Improving Awareness of Running Code: The > Implementation Status Section > > Reply-To: ietf@ietf.org > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6982 > > > > Title: Improving Awareness of Running Code: > > The Implementation Status Section > > Author: Y. Sheffer, A. Farrel > > Status: Experimental > > Stream: IETF > > Date: July 2013 > > Mailbox: yaronf.ietf@gmail.com, > > adrian@olddog.co.uk > > Pages: 9 > > Characters: 19358 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-sheffer-running-code-06.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc6982.txt > > > > This document describes a simple process that allows authors of > > Internet-Drafts to record the status of known implementations by > > including an Implementation Status section. This will allow > > reviewers and working groups to assign due consideration to documents > > that have the benefit of running code, which may serve as evidence of > > valuable experimentation and feedback that have made the implemented > > protocols more mature. > > > > The process in this document is offered as an experiment. Authors of > > Internet-Drafts are encouraged to consider using the process for > > their documents, and working groups are invited to think about > > applying the process to all of their protocol specifications. The > > authors of this document intend to collate experiences with this > > experiment and to report them to the community. > > > > > > EXPERIMENTAL: This memo defines an Experimental Protocol for the > > Internet community. It does not specify an Internet standard of any > > kind. Discussion and suggestions for improvement are requested. > > Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see > http://www.rfc-editor.org/search/rfc_search.php > > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e014933840095d504e1bd2ff9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For what it's worth, I just did this for RFC5451b= is and the IESG was quite appreciative of it during the evaluation phase.
-MSK


On Wed, Jul 17, 2013 at 12:39 PM, Russ Housley <housley@vigilsec.com> wrote:
This seems to offer guidance that is relevant to the DMARC situation.

Begin forwarded message:

> From: rfc-editor@rfc-edit= or.org
> Date: July 17, 2013 3:12:23 PM EDT
> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org<= br> > Cc: drafts-update-ref@ia= na.org, rfc-editor@rfc-edi= tor.org
> Subject: RFC 6982 on Improving Awareness of Running Code: The Implemen= tation Status Section
> Reply-To: ietf@ietf.org
>
> A new Request for Comments is now available in online RFC libraries. >
>
> =A0 =A0 =A0 =A0RFC 6982
>
> =A0 =A0 =A0 =A0Title: =A0 =A0 =A0Improving Awareness of Running Code:<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The Implementation Status Secti= on
> =A0 =A0 =A0 =A0Author: =A0 =A0 Y. Sheffer, A. Farrel
> =A0 =A0 =A0 =A0Status: =A0 =A0 Experimental
> =A0 =A0 =A0 =A0Stream: =A0 =A0 IETF
> =A0 =A0 =A0 =A0Date: =A0 =A0 =A0 July 2013
> =A0 =A0 =A0 =A0Mailbox: =A0 =A0yaronf.ietf@gmail.com,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0adrian@olddog.co.uk
> =A0 =A0 =A0 =A0Pages: =A0 =A0 =A09
> =A0 =A0 =A0 =A0Characters: 19358
> =A0 =A0 =A0 =A0Updates/Obsoletes/SeeAlso: =A0 None
>
> =A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-sheffer-running-code-06.txt
>
> =A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6982.= txt
>
> This document describes a simple process that allows authors of
> Internet-Drafts to record the status of known implementations by
> including an Implementation Status section. =A0This will allow
> reviewers and working groups to assign due consideration to documents<= br> > that have the benefit of running code, which may serve as evidence of<= br> > valuable experimentation and feedback that have made the implemented > protocols more mature.
>
> The process in this document is offered as an experiment. =A0Authors o= f
> Internet-Drafts are encouraged to consider using the process for
> their documents, and working groups are invited to think about
> applying the process to all of their protocol specifications. =A0The > authors of this document intend to collate experiences with this
> experiment and to report them to the community.
>
>
> EXPERIMENTAL: This memo defines an Experimental Protocol for the
> Internet community. =A0It does not specify an Internet standard of any=
> kind. Discussion and suggestions for improvement are requested.
> Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
> =A0http://www.ietf.org/mailman/listinfo/ietf-announce
> =A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= /a>
>
> For searching the RFC series, see http://www.rfc-editor.org/search/= rfc_search.php
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html
>
> Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e014933840095d504e1bd2ff9-- From barryleiba.mailing.lists@gmail.com Thu Jul 18 11:25:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029CA11E81BA for ; Thu, 18 Jul 2013 11:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 ojlr29ZsEugR for ; Thu, 18 Jul 2013 11:25:02 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CC11E819E for ; Thu, 18 Jul 2013 11:25:01 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x17so2581423vbf.24 for ; Thu, 18 Jul 2013 11:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0W8aptvFQS1KaakvvF7VOu3URBrXQb5fZ19n3KE8LPU=; b=BRJSFRLhCYOx84FCKkzY2hSrg9nvkt4LINk5JZ+ZPPjF0SCfTguR7Rs0xLL2d8CJ1U JlAocGwmLUv0Wewd1o5DJQwLH2GzeIHnanxmOfy8PmMoRXqEy3FEQsPhPreK70qaT9Dx lcUA5OrG1smZlV2i7RZYMYf/FEcHszl65r7rkIcbfeP+lxKoB9cRaYRHe+Jui+99TadT Y84TWSMW+FYUh9OgecpgRcoq0iWkkHXbp+EwHo52xmFvqTPG5FzMQEbV4T4aEfAk4+EM zv3HjjLRDrwzkSaxXMTWZAhmuygMcf3UTiU5s1plnGVJgDrOtAxKUkcKaV3cyARfBVlj nWWg== MIME-Version: 1.0 X-Received: by 10.52.164.227 with SMTP id yt3mr3759338vdb.107.1374171901555; Thu, 18 Jul 2013 11:25:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Thu, 18 Jul 2013 11:25:01 -0700 (PDT) In-Reply-To: <51E5A667.50503@gmail.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E5A667.50503@gmail.com> Date: Thu, 18 Jul 2013 14:25:01 -0400 X-Google-Sender-Auth: sXJKxwRj1n6jyUSz_IeeJs0qx1c Message-ID: From: Barry Leiba To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:25:03 -0000 >> If the base spec is out of scope, I think the entire effort should be >> deferred until after it's done. I don't think it makes sense to spin >> up a working group to work on extensions until they can leverage a >> stable foundation. ... > 1. There is no community support for any proposals to change the > bits-over-the-wire. > > 2. The current bits-over-the-wire protocol is widely > deployed and is used for a very large fraction of the Internet's email > traffic. > > Then if that does not constitute the ultimate form of "stable foundation", > then I can't guess what you mean. Indeed. Let's be clear: I have agreed to AD-sponsor the DMARC base spec *if* I see significant community review and support for publishing it as Proposed Standard. I do need to see more reviews and more comments about whether it should be a Standards Track RFC, but that's a separate point. We have gotten some reviews of it so far, and those reviews have suggested some changes. None of those suggested changes -- including the ones Scott and John have made in their reviews -- are, in my view, of a nature that would invalidate the work that the BoF is meant for. I believe that, as Dave says, the DMARC spec is sufficiently stable to be a foundation for the BoF, and for the discussion we'll have there. Let's please focus on two things: 1. For the BoF, let's work on using the time productively, starting with the assumption that something fairly close to the currently published DMARC spec is where we jump off from. 2. For the DMARC spec, let's please have more of the IETF community review the document, specifically responding to the questions of (a) what technical changes are needed in it, and (b) whether it should be published as a Standards Track specification. Barry, Applications AD From dcrocker@gmail.com Thu Jul 18 19:10:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECFB21E818A for ; Thu, 18 Jul 2013 19:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jABv8qu66a7t for ; Thu, 18 Jul 2013 19:10:55 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 79CAF21E815C for ; Thu, 18 Jul 2013 19:10:53 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so5220131oag.1 for ; Thu, 18 Jul 2013 19:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V/VM5IQyP83nZk7xembOVQGcYzFfVeYL+A/x1evKpCw=; b=wY8c6wAHtxRYb/yljkURC4jH4uw6ZYqkvXkgiJSOMhTsfVheajQrdeqFZ4YC50KLEI OUXl32AjovUeOJlW5AUXFq/AxFGQTvKtj/2gjB2DDasXuUWWfHYayVEmNDUozYibU7yW WmPLSmtQN1/mgUacyju7kNwi3/z38EeIbZViKttRBiu4rh6wYOMZd+pHemWhqV7TxUps 63lUQUqgNhm9kdlfErujOEtXTkn2Xu2Mc2QHs/DOyVZtp2PC8XXf2gpac++0heR37bsG blrmXZD4dRqVhSTkiSpiBXGTm0oKjFXIqBWuTxv14FwiHP9AjL02ox8mIHt1lhVDUV2Z pm8w== X-Received: by 10.182.144.163 with SMTP id sn3mr10593771obb.1.1374199851958; Thu, 18 Jul 2013 19:10:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id o8sm18733325obx.11.2013.07.18.19.10.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 19:10:50 -0700 (PDT) Message-ID: <51E8A003.2010901@gmail.com> Date: Thu, 18 Jul 2013 19:10:11 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barry Leiba References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E5A667.50503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 02:10:56 -0000 On 7/18/2013 11:25 AM, Barry Leiba wrote: > 1. For the BoF, let's work on using the time productively, starting > with the assumption that something fairly close to the currently > published DMARC spec is where we jump off from. Let me press the distinction between 'editorial' document changes, versus changes to the bits over the wire. With that distinction in mind, I believe that the BOF can start with the assumption that there will be no changes to bits over the wire. This is always subject to change, but there's now an extended history of it's being true. So the 'fairly close' is the editorial content of the latest draft. > 2. For the DMARC spec, let's please have more of the IETF community > review the document, specifically responding to the questions of (a) > what technical changes are needed in it, and (b) whether it should be > published as a Standards Track specification. We have a review sequence lined up. We suspended it after the first two because the call for editorial changes was strong enough and for enough change to make it worth letting further reviewers benefit from what we believe will be significantly improved readability. FWIW, whatever queue of reviewers we've lined does not, should not, and of course will not, preclude anyone else from offering their own review. More is better. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From raz@raz.cx Fri Jul 19 02:25:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92F11E80F8 for ; Fri, 19 Jul 2013 02:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwiY2D6JNGdw for ; Fri, 19 Jul 2013 02:25:20 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 68ACF11E80F6 for ; Fri, 19 Jul 2013 02:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=raz.cx; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=eD7DTkN2uHZMVFCIRtsizb1h8Hci+JnsBCq3fl0JCT0=; b=IvRh7GlDOPJdo+kpSBhY634LVGqbx9uAFYVGVAjpa+/hcnbq8epCGAiyiqw3Ul17T+eW5uKrfjH6bskytor3s0pzmah+FEU8zbpbR6Pz4Fo6PlLe5DoteUc0RgpjsTjATSHR2sJUiTbWizcQyIqP225ZLXS8kLkJcMXqL3oUVXE=; X-raz.cx-addressbook: match raz@raz.cx Received: from [116.12.149.133] (port=54850 helo=[10.100.1.133]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1V06wA-0001LQ-GX; Fri, 19 Jul 2013 09:25:18 +0000 Message-ID: <51E905FD.7090602@raz.cx> Date: Fri, 19 Jul 2013 17:25:17 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "J. Trent Adams" References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> In-Reply-To: <51E56928.4020207@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:25:29 -0000 On 07/16/2013 11:39 PM, J. Trent Adams wrote: > From what I can tell, the most important question needing to be answered > is whether or not revising the base DMARC specification is within scope > of the proposed work group. Following Russ's guidance, it seems that we > should start from the assumption that it's not in scope for now given > the fact that it's being sponsored by an AD as an Individual Submission. > > Regardless of whether that's the right path, or not, let's explore it as > an option and see how the rest of the items identified in the proposed > charter play out. Then we can leverage the outcome of the conversation > to potentially revisit the fate of the base specification itself. I would suggest that this is a problematic approach because of the effective need that this creates for the charter discussion to correctly predict what the WG will come up with. The WG should work out what the WG comes up with, and should have as broad a remit as is feasible (give or take IETF process constraints) to do so. This is not to say that there should not be a recital acknowledging that the substantial installed base will necessarily limit changes - probably to nothing - but that seeking to constrain the WG's approach now, rather than during it, is likely to be harmful. I'm thinking particularly about what happened recently with respect to the SPF macro facility and the fact that the discussion on removing it turned not on whether removing the facility was appropriate, but on whether the particular words chosen during chartering meant that this was, or was not, a permissible change for the WG to make. - Roland From dcrocker@gmail.com Fri Jul 19 05:30:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E111E8118 for ; Fri, 19 Jul 2013 05:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7y8702Ut5w1 for ; Fri, 19 Jul 2013 05:30:49 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id E759111E8105 for ; Fri, 19 Jul 2013 05:30:48 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so5786153oah.24 for ; Fri, 19 Jul 2013 05:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ABnbZ8bN2JFm49r/6qClFObE9CZFWq/v5JUqNHG7bio=; b=BcHa6g5p7acj8McH9A1JzEfKJlLXyIu7pCqUDhymtiWtbTdvEmhL/pOcwW99mRPWt8 4GRSlbAS5epSgtbwP+I120Xw6QqmUtK2nPGmdS4o9xDWKIGNu8P1gBOluzpm8FWPMaq5 2FWsod8gk2xvYhbhwCMasA3RRutORCgHOw8QHWjB6PdFbgxrJ/UXHEb+1j/uZ1ICwUw6 BOWWAt9kDd07H5Mp04us4lkt2rMn4vhwBOU2/1cHCzy3Ou7iB8c2PrZ23FoUtuQa2O1c B5XuiphyQiyl4C4KWhHfHOpbzAUc5iIRnDMXRwUCxLkfYPmm2Rk1raeemaCFV68kjAkv 6kpQ== X-Received: by 10.182.215.193 with SMTP id ok1mr12037359obc.78.1374237047371; Fri, 19 Jul 2013 05:30:47 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id rs4sm20823552obc.10.2013.07.19.05.30.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 05:30:46 -0700 (PDT) Message-ID: <51E9314F.3080304@gmail.com> Date: Fri, 19 Jul 2013 05:30:07 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Roland Turner References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E905FD.7090602@raz.cx> In-Reply-To: <51E905FD.7090602@raz.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 12:30:49 -0000 On 7/19/2013 2:25 AM, Roland Turner wrote: > On 07/16/2013 11:39 PM, J. Trent Adams wrote: > I would suggest that this is a problematic approach because of the > effective need that this creates for the charter discussion to correctly > predict what the WG will come up with. Given that there have been repeated queries to the community for technical work items and given that there have been no suggestions that have gained any traction, what is the basis for believing there is any work on the base spec for a working group to do? With spfbis and similar efforts, they were started with a knowledge that refinements were needed, whereas for the dmarc base spec, we have no evidence of that need. In fact, we have counter-evidence. Working groups are expensive in time and effort. They need justification before they start, not after. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Fri Jul 19 11:23:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC1A21F9C72 for ; Fri, 19 Jul 2013 11:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BYBWHguKHlX for ; Fri, 19 Jul 2013 11:23:40 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 17E8D21F99CF for ; Fri, 19 Jul 2013 11:23:38 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so108408wiv.8 for ; Fri, 19 Jul 2013 11:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ng2sA5NYZ0fbF/J5c1SqlGfSXi8O2sPcO47FyKKVe+E=; b=dATz6xy1m2ywyyRzt07CkBjNadISHTTBChdPKmsVQAT7nscfZR5tS+Yk1U+FvBof9D NF2DPOrJX5mU54KZxXNlPlXQWTfpnH3m5oEpZBd3LJUT9IQ1ds4CnxR7i+IbIHVwX4Pm Jnt8inb11XQh/6O49zdBPUqIiuGlAwbExtVZoHF/gWlXl/0drq7L5wFOZlYFauHPKk/F PqUeEs90ERyzprMoKCfxquvF2NQWP8EhmqyZJmFVScNuIq7P2F77DJG123+JGdHjsWw6 RBJOIT0MctClAEx4t2hoLQko4ulvN2X4Q5st+X5BiHC9Iu8zQmAU/y6E0/zgwSHGtYsb VVmg== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr12347881wic.60.1374258218204; Fri, 19 Jul 2013 11:23:38 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 11:23:37 -0700 (PDT) In-Reply-To: <51E56928.4020207@gmail.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> Date: Fri, 19 Jul 2013 11:23:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Trent Adams" Content-Type: multipart/alternative; boundary=001a11c26a5eed03d104e1e16c7a Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:23:58 -0000 --001a11c26a5eed03d104e1e16c7a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 16, 2013 at 8:39 AM, J. Trent Adams wrote: > Given that guidance, here're the most obvious (and noncontroversial?) > items needing to be done to shore up the proposed charter: > > * Correct the text regarding the current path of the specification. > * Tone down the "marketing puffery". > * Clarify how to address "backward compatibility" with the installed base. > Yes, yes, and yes. > ----- > * a mechanism for determining the organizational domain name based on an > arbitrary fully-qualified hostname > ----- > > If I'm not mistaken, the Apps Area WG has already expressed an interest > in this work. In that case, I believe that this WG would only need to > track that effort and ensure that its work addresses the use cases > required to support DMARC. > That sounds right to me. My recollection is that there have been arguments made that the right place to develop a solution to this problem is APPSAWG, but not that a decision has been made that that's going to be the venue. I've no objection, but I don't recall a decision. There are two proposals available as I-Ds that we can discuss someplace: draft-levine-orgboundary and draft-sullivan-domain-policy-authority. There's time on the APPAREA agenda right now if John and Andrew (or their delegates) would like to lead a discussion about it. > > QUESTION: Given that it's an important topic, and there's no guarantee > that the other effort will result in an applicable solution, would it > still be reasonable to include a mention of this as worth exploration? > If so, it'd probably make sense to reference the other work as a > starting point to clarify we're not planning to spin up a competing > solution. > The charter should say that the topic is out of scope, as we expect it will be handled by another working group in parallel to our work. If no working group (extant or new) does pick it up, we can negotiate to recharter and deal with it ourselves. > ----- > * a mechanism for detecting abuse involving the portion > of the RFC5322.From field > ----- > > This is an interesting item in that there have been some proposals from > contributors to the base DMARC specification to address this. The > proposals, as you can see, didn't make it through to a consensus and it > was suggested that they be brought to the broader community for > consideration. It's highly likely that through the WG process we're able > to identify a means by which this issue can be addressed. > > QUESTION: Does it make sense for this proposed WG to explore how the > base specification can be extended to apply the same level of > "identifier alignment" to the as is helping defend the > ? > With the understanding that a working group can always decide not to tackle an issue it's chartered to tackle because it decides the problem is intractable, I think we should include it. The ADs can encourage the chairs to shut down a topic that it seems has no real solution sooner rather than later. > > ----- > * a mechanism for mitigating the effect of failures of DMARC policy when > a message transits a mailing list > ----- > > I recognize that there's definitely a counter-pressure against including > this topic as it seems to be a potentially quixotic quest. That being > said, even if we don't find the perfect solution, it does seem > reasonable to believe there is a way to provide something more than > nothing that does help in some meaningful way. I'm not presupposing a > solution, just that there have been a few possible options discussed at > the edges which are likely to be worth more rigorous exploration. > > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? > Same answer as above. > > ----- > * support for the notion of transitive trust (i.e., "host X trusted the > sender of this message, and I trust X, so you should too") > ----- > > I see this as similar to the above, but potentially more broadly > applicable. One tweak I'd offer would be to replace ", so you should > too" with something like ", so you could choose to as well". > > QUESTION: Is there value in a WG such as this exploring possible > solutions to this issue and developing guidance that would potentially > help improve the utility of the base DMARC specification? > Same answer as above. > > ----- > * more robust transport of reports > ----- > > After over a year of deployment, and the rise in support services > handling reports, many folks have suggested that it would be worth > exploring how to offer additional optional means of transport for > reports. The base DMARC specification provides for this, but it is an > area that was left to be extended by a group such as this. > > QUESTION: Is this an area of exploration that is of enough interest to > include in the charter for this proposed work group? > Same answer as above. > > * Identifier alignment configuration options > * Implementation decisions regarding "pct" > * Determining effective RUA sending frequency > * Leveraging policy caching > * Various options for integrating within an existing flow > * Defining a useful, common set of RUA reporting options > * When and how to use local policy override options > > QUESTION: Do any items on this list seem to be worth specifically adding > to the proposed charter as examples of the type of work that would be > useful? > Given the path for dmarc-base on the table, I suggest these be omitted and saved for some future dmarc-bis effort, except where operational advice can be developed and included in the "using" document. -MSK --001a11c26a5eed03d104e1e16c7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2013 at 8:39 AM, J. Trent Adams <jtr= entadams@gmail.com> wrote:
Given that guidance, here= 're the most obvious (and noncontroversial?)
items needing to be done to shore up the proposed charter:

* Correct the text regarding the current path of the specification.
* Tone down the "marketing puffery".
* Clarify how to address "backward compatibility" with the instal= led base.

Yes, yes, and yes.
=A0
=
-----
* a mechanism for determining the organizational domain name based on an arbitrary fully-qualified hostname
-----

If I'm not mistaken, the Apps Area WG has already expressed an interest=
in this work. In that case, I believe that this WG would only need to
track that effort and ensure that its work addresses the use cases
required to support DMARC.

<hat type= =3D"dmarc-participant">
That sounds right to me.=
</hat>

<hat type=3D"appsawg-= co-chair">
My recollection is that there have been arguments made that the right place= to develop a solution to this problem is APPSAWG, but not that a decision = has been made that that's going to be the venue.=A0 I've no objecti= on, but I don't recall a decision.

There are two proposals available as I-Ds that we= can discuss someplace: draft-levine-orgboundary and draft-sullivan-domain-= policy-authority.=A0 There's time on the APPAREA agenda right now if Jo= hn and Andrew (or their delegates) would like to lead a discussion about it= .
</hat>
=A0

QUESTION: Given that it's an important topic, and there's no guaran= tee
that the other effort will result in an applicable solution, would it
still be reasonable to include a mention of this as worth exploration?
If so, it'd probably make sense to reference the other work as a
starting point to clarify we're not planning to spin up a competing
solution.

The charter should say that t= he topic is out of scope, as we expect it will be handled by another workin= g group in parallel to our work.=A0 If no working group (extant or new) doe= s pick it up, we can negotiate to recharter and deal with it ourselves.


-----
* a mechanism for detecting abuse involving the <display-name> portio= n
of the RFC5322.From field
-----

This is an interesting item in that there have been some proposals from
contributors to the base DMARC specification to address this. The
proposals, as you can see, didn't make it through to a consensus and it=
was suggested that they be brought to the broader community for
consideration. It's highly likely that through the WG process we're= able
to identify a means by which this issue can be addressed.

QUESTION: Does it make sense for this proposed WG to explore how the
base specification can be extended to apply the same level of
"identifier alignment" to the <display-name> as is helping = defend the
<address-spec>?

With the understa= nding that a working group can always decide not to tackle an issue it'= s chartered to tackle because it decides the problem is intractable, I thin= k we should include it.=A0 The ADs can encourage the chairs to shut down a = topic that it seems has no real solution sooner rather than later.
=A0

-----
* a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list
-----

I recognize that there's definitely a counter-pressure against includin= g
this topic as it seems to be a potentially quixotic quest. That being
said, even if we don't find the perfect solution, it does seem
reasonable to believe there is a way to provide something more than
nothing that does help in some meaningful way. I'm not presupposing a solution, just that there have been a few possible options discussed at
the edges which are likely to be worth more rigorous exploration.

QUESTION: Is there value in a WG such as this exploring possible
solutions to this issue and developing guidance that would potentially
help improve the utility of the base DMARC specification?
<= div>
Same answer as above.
=A0

-----
* support for the notion of transitive trust (i.e., "host X trusted th= e
sender of this message, and I trust X, so you should too")
-----

I see this as similar to the above, but potentially more broadly
applicable. One tweak I'd offer would be to replace ", so you shou= ld
too" with something like ", so you could choose to as well".=

QUESTION: Is there value in a WG such as this exploring possible
solutions to this issue and developing guidance that would potentially
help improve the utility of the base DMARC specification?
<= div>
Same answer as above.
=A0

-----
* more robust transport of reports
-----

After over a year of deployment, and the rise in support services
handling reports, many folks have suggested that it would be worth
exploring how to offer additional optional means of transport for
reports. The base DMARC specification provides for this, but it is an
area that was left to be extended by a group such as this.

QUESTION: Is this an area of exploration that is of enough interest to
include in the charter for this proposed work group?
<= br>
Same answer as above.
=A0

* Identifier alignment configuration options
* Implementation decisions regarding "pct"
* Determining effective RUA sending frequency
* Leveraging policy caching
* Various options for integrating within an existing flow
* Defining a useful, common set of RUA reporting options
* When and how to use local policy override options

QUESTION: Do any items on this list seem to be worth specifically adding to the proposed charter as examples of the type of work that would be
useful?

Given the path for dmarc-base on the= table, I suggest these be omitted and saved for some future dmarc-bis effo= rt, except where operational advice can be developed and included in the &q= uot;using" document.

-MSK
--001a11c26a5eed03d104e1e16c7a-- From superuser@gmail.com Fri Jul 19 11:25:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3CB21E80D2 for ; Fri, 19 Jul 2013 11:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPWFtUz6XT7E for ; Fri, 19 Jul 2013 11:25:39 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id F00C921F9DBA for ; Fri, 19 Jul 2013 11:25:38 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so947270wiw.2 for ; Fri, 19 Jul 2013 11:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BQBJaNZTJIAYpu1XJF/bhnLrTqs9JAYewk8O8hGZA5Y=; b=CyGZeI0m5CZbqindGAGcW3mfQvyTFIJhr6eaZAaZO4hnALPLZ6V2n1hIyvLDEYVRRD hR3N6R1QXcH8G9akbxy0KvYQ/W8hI8OF7Y3+kL8XvUan5OdRBvBWhKAuKldJeB5TKPgm T56Y75UeRMJrk+GN8Qduz+9QnXSINo1EammAFA9bFimIQM88dk9qGscUvN/ztqfd1vTz zN3UW8RM0YkMRFewOPmtsu9hzYMM+5M9tHmMGPXOo548i79tdNf2wwWEKF2wX9lispw+ mJOwy7HAsMgQBVkKWvGp0gx13BPwA07NMLdASxMXyeWPr4WktFCZVGFUXrlkEQLFYWSf 5E9A== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr13317974wjn.23.1374258336945; Fri, 19 Jul 2013 11:25:36 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 11:25:36 -0700 (PDT) In-Reply-To: <51E56BAD.3060602@gmail.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E56BAD.3060602@gmail.com> Date: Fri, 19 Jul 2013 11:25:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7ba975e600dd5b04e1e174cd Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:25:40 -0000 --047d7ba975e600dd5b04e1e174cd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 16, 2013 at 8:50 AM, Dave Crocker wrote: > > ----- >> * a mechanism for mitigating the effect of failures of DMARC policy when >> a message transits a mailing list >> ----- >> >> I recognize that there's definitely a counter-pressure against including >> this topic as it seems to be a potentially quixotic quest. That being >> said, even if we don't find the perfect solution, it does seem >> reasonable to believe there is a way to provide something more than >> nothing that does help in some meaningful way. I'm not presupposing a >> solution, just that there have been a few possible options discussed at >> the edges which are likely to be worth more rigorous exploration. >> >> QUESTION: Is there value in a WG such as this exploring possible >> solutions to this issue and developing guidance that would potentially >> help improve the utility of the base DMARC specification? >> > > If the wg handles this carefully and pragmatically, there might be some > benefit in at least documenting the topic, in terms of concerns and > choices. I believe there isn't an IETF published paper in this realm, in > spite of the issue appearing regularly. > RFC6377 devotes quite a bit of time to the topic, at least in the context of DKIM. There's also mention of ADSP, which is particularly germane here. We may reasonably be asked what's different now since the publication of that draft that would warrant reopening the topic. -MSK --047d7ba975e600dd5b04e1e174cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2013 at 8:50 AM, Dave Crocker <dcrocker@= gmail.com> wrote:

-----
* a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list
-----

I recognize that there's definitely a counter-pressure against includin= g
this topic as it seems to be a potentially quixotic quest. That being
said, even if we don't find the perfect solution, it does seem
reasonable to believe there is a way to provide something more than
nothing that does help in some meaningful way. I'm not presupposing a solution, just that there have been a few possible options discussed at
the edges which are likely to be worth more rigorous exploration.

QUESTION: Is there value in a WG such as this exploring possible
solutions to this issue and developing guidance that would potentially
help improve the utility of the base DMARC specification?

If the wg handles this carefully and pragmatically, there might be some ben= efit in at least documenting the topic, in terms of concerns and choices. = =A0I believe there isn't an IETF published paper in this realm, in spit= e of the issue appearing regularly.

RFC6377 devotes quite a bit of time to the= topic, at least in the context of DKIM.=A0 There's also mention of ADS= P, which is particularly germane here.

We may reasonably = be asked what's different now since the publication of that draft that = would warrant reopening the topic.

-MSK
--047d7ba975e600dd5b04e1e174cd-- From dcrocker@gmail.com Fri Jul 19 11:28:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1421F9E3C for ; Fri, 19 Jul 2013 11:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N21NY76n+-S4 for ; Fri, 19 Jul 2013 11:28:44 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1021F9E39 for ; Fri, 19 Jul 2013 11:28:44 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so5869294obc.27 for ; Fri, 19 Jul 2013 11:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gtDn9mTjV95HwHHD3PCyWpg/3X8cI8rgDYWGSAO8Lno=; b=ju7aGKWFSeTMzKoF+4+pMwk/qAfvV0WKd6os6To0r2jRwkCLjYYxSe8O3aF9ecz4YL SuUB88lYrZc0nTHs9SptTfKG7+/dHOL86MndKY4MVIVoPKOvutr9W5DR5fJnjyjei/dA Z2UwS5jsEE3xnQng1oeZdWqSaoAB4GvT56G7fuNP6aGXRylq/9RQzLwHPyPPGz7EdYSK 7Xnmnu9KIvYkcfXqFa5sReDTODFBJihjHCocU6hFpBpP9I0KURxmclnn9d7NmBfpz2My kEBr6P0M1QFKwWfVoE6hIifX2634bI54KdZ/lKxMwIccjQLMV6cmwc+rvk9z5GmpSxMM 3epQ== X-Received: by 10.182.72.137 with SMTP id d9mr13059102obv.99.1374258524261; Fri, 19 Jul 2013 11:28:44 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id jz7sm22489113obb.4.2013.07.19.11.28.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 11:28:43 -0700 (PDT) Message-ID: <51E98533.6000909@gmail.com> Date: Fri, 19 Jul 2013 11:28:03 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E56BAD.3060602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:28:45 -0000 On 7/19/2013 11:25 AM, Murray S. Kucherawy wrote: > We may reasonably be asked what's different now since the publication of > that draft that would warrant reopening the topic. I think the work we've discussed for this round might actually include proposing changes to mailing lists... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Fri Jul 19 11:29:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6E11E818B for ; Fri, 19 Jul 2013 11:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jogW0EM3GTdT for ; Fri, 19 Jul 2013 11:29:54 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3C21F9E6E for ; Fri, 19 Jul 2013 11:29:53 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so115120wiv.9 for ; Fri, 19 Jul 2013 11:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0YNKl4pmsALwE204tgFKZrGPOWZnRSpAeEqQdSeXeZg=; b=0k8tCxYIz6CqyI9F4JmAb+HrQkBZ4nqJPAaPmilp9RQpe8OBebvi4iuFSLCkC4GezR DWw6F9nfFX90ewozhJBOfQ4LBnPw7FSS1LuFkdmDtKr75geG7xU7fByoBDKj1hg8aK6S ub3ATbGcC0+GXWqRehxWzvhWgA21TGbMx/G5JwybEkHCN1h4IkilHDqBXQXyk8cOFFuX xk3juCTnJsVdwRX427UFlvjdHfFIKEW+N/b2mEvrW0mJg5NC/QGGtceYSbOVeYNGN57b jEppgX4+FKT4GjHymW8SzKv/tc6R8sjNxOsTcWsBTGBX9Cmje+LgJR63H2XtaYw1Zlln 6A/Q== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr12489951wic.19.1374258592483; Fri, 19 Jul 2013 11:29:52 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 11:29:52 -0700 (PDT) In-Reply-To: <51E98533.6000909@gmail.com> References: <20130702052746.15876.qmail@joyce.lan> <51D3464D.2060502@sonnection.nl> <0A91244B-1CAE-491A-865B-E2BA64AFB366@tnpi.net> <51E56928.4020207@gmail.com> <51E56BAD.3060602@gmail.com> <51E98533.6000909@gmail.com> Date: Fri, 19 Jul 2013 11:29:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c3436a3c118e04e1e1839b Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:29:55 -0000 --001a11c3436a3c118e04e1e1839b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 11:28 AM, Dave Crocker wrote: > We may reasonably be asked what's different now since the publication of > >> that draft that would warrant reopening the topic. >> > > I think the work we've discussed for this round might actually include > proposing changes to mailing lists... > > And that's a reasonable answer. :-) -MSK --001a11c3436a3c118e04e1e1839b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 11:28 AM, Dave Crocker <dcrock= er@gmail.com> wrote:
We may reasonably be asked= what's different now since the publication of
that draft that would warrant reopening the topic.

I think the work we've discussed for this round might actually include = proposing changes to mailing lists...


And that's a reasona= ble answer.=A0 :-)

-MSK

--001a11c3436a3c118e04e1e1839b-- From prvs=905ec3126=fmartin@linkedin.com Fri Jul 19 13:42:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F511E81C0 for ; Fri, 19 Jul 2013 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 PyVdOddxnNuW for ; Fri, 19 Jul 2013 13:42:55 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 656FF11E81CC for ; Fri, 19 Jul 2013 13:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1374266575; x=1405802575; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=d9DJYy2xsonZbJWucoC8E5lLhOmdQP5NYwK01gcFdks=; b=pBgO9vUBKG1WZNQJTqAQg5I4I/1aXFmfAHODPesfqPxayEDNIS+JwmpA zN79ydDY3IZjZxJofuGl/vx918hf4gQSpspber9gurFsJN6DRTCmAXkk6 DgGhs/TIlPpZq76M/vStcUAl+nQledcSWToOmFWjBYOiKGl7Q69dx0k/o A=; X-IronPort-AV: E=Sophos;i="4.89,704,1367996400"; d="scan'208";a="54843279" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 19 Jul 2013 13:42:29 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 13:42:29 -0700 From: Franck Martin To: "dmarc@ietf.org" Thread-Topic: Charter text to add Thread-Index: AQHOhMB8d2DqohlVn0S9WZfrlW5fMA== Date: Fri, 19 Jul 2013 20:42:29 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dmarc-ietf] Charter text to add X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:42:59 -0000 http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC It seems to me the BCP should provide advice on how you can strengthen your= receiving MTA to avoid "cousin" domain abuse. I see it at the moment mainl= y based on domain reputation and invalid syntax, but there are may be other= . For instance, I have noticed that spamassassin has no rule to check domai= ns present in From: Helo, MailFrom against blacklists such as the DBL. So I propose the following bullet point to add: - mechanisms for receivers to mitigate potential methods to circumvent DMAR= C. For instance, but not limited to handling of malformed emails, domain ba= sed blacklists and domain based reputation= From Greg.Colburn@returnpath.com Mon Jul 22 10:37:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A108611E8123 for ; Mon, 22 Jul 2013 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.6 X-Spam-Level: X-Spam-Status: No, score=-8.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQprEZgR6LGh for ; Mon, 22 Jul 2013 10:36:56 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id AC39421F868C for ; Mon, 22 Jul 2013 10:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to :subject:in-reply-to:content-type:content-transfer-encoding :mime-version; s=smtpapi; bh=alDzfyG06XmXy38j14PfJWq0RuU=; b=PRL L7C7+16BO0nQy1+hu5VDzhmIsQIXfUVc7+0kxbxpgkTs0Hm//VoRt1PBcYpban4a 5nZXrymS8O5NndQYRncSPHTMNq9jb8EJgi009ds+sJei7f4o8NhpJb4c/cH4jjZ8 OLrGYfCNSov5mh/v+Xr8cSwiWVXu3e0+yAMjX0wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to :subject:in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=smtpapi; b=XSoMvE3akh2OSdPwMCXCn0U/uG4oe E/qnFtE6MRcNOk4wTUslcBCHnh26DaSCeQ4ptQ9c3qEJD0seO/6UR6ZOD2CfFkpG bbfT0DVmASDc90GvmHc+LQ0GNseeIffqLbG+J2aX9uGRDLuUig44k+3GMAmvtn8l Xd8Y/3s8t+jrcM= Received: by 10.16.240.38 with SMTP id mf17.2638.51ED6DAB3 Mon, 22 Jul 2013 12:36:43 -0500 (CDT) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by mi18 (SG) with ESMTP id 140077464c3.46ca.1a8e9b for ; Mon, 22 Jul 2013 17:36:43 +0000 (UTC) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Mon, 22 Jul 2013 11:36:43 -0600 From: Greg Colburn To: "dmarc@ietf.org" Date: Mon, 22 Jul 2013 11:36:40 -0600 Thread-Topic: [dmarc-ietf] Charter improvements Thread-Index: Ac6HAgehGm4SOASlTKGRTuaEDG8QQg== Message-ID: In-Reply-To: <51E56928.4020207@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5IouMX/BahOz68cYydVnJ+galhBSdNJedmMk4bRGM+o+Da1tK8ORcAW0FvWpEF+cB8ouk7M9g45bDnwVmT2XFgE Subject: Re: [dmarc-ietf] Charter improvements X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:37:01 -0000 Apologies for my tardiness to the conversation. Comments below. Greg Colburn On 7/16/13 9:39 AM, "J. Trent Adams" wrote: > >Thanks, everyone, for their input on this thread (and to John for the >pointer how to get back to land when I blundered into the wrong stream). >Editing the proposed charter is a lot easier with this feedback. > >From what I can tell, the most important question needing to be answered >is whether or not revising the base DMARC specification is within scope >of the proposed work group. Following Russ's guidance, it seems that we >should start from the assumption that it's not in scope for now given >the fact that it's being sponsored by an AD as an Individual Submission. > >Regardless of whether that's the right path, or not, let's explore it as >an option and see how the rest of the items identified in the proposed >charter play out. Then we can leverage the outcome of the conversation >to potentially revisit the fate of the base specification itself. > >Given that guidance, here're the most obvious (and noncontroversial?) >items needing to be done to shore up the proposed charter: > >* Correct the text regarding the current path of the specification. >* Tone down the "marketing puffery". >* Clarify how to address "backward compatibility" with the installed base. > >I've already updated the description of the current path of the base >specification from "Independent Submission" to "Individual Submission", >so that's one down. I'll pull out my red pen on the other two topics and >see if I can make them more reasonable. +1 > >Skipping ahead. . . here're the items that have previously been proposed >as worth exploring in the setting of an IETF work group: > >----- >* a mechanism for determining the organizational domain name based on an >arbitrary fully-qualified hostname >----- > >If I'm not mistaken, the Apps Area WG has already expressed an interest >in this work. In that case, I believe that this WG would only need to >track that effort and ensure that its work addresses the use cases >required to support DMARC. > >QUESTION: Given that it's an important topic, and there's no guarantee >that the other effort will result in an applicable solution, would it >still be reasonable to include a mention of this as worth exploration? >If so, it'd probably make sense to reference the other work as a >starting point to clarify we're not planning to spin up a competing >solution. While the work required for this task is out of scope, it could significantly impact DMARC. This WG should probably track the effort as closely as possible. > >----- >* a mechanism for detecting abuse involving the portion >of the RFC5322.From field >----- > >This is an interesting item in that there have been some proposals from >contributors to the base DMARC specification to address this. The >proposals, as you can see, didn't make it through to a consensus and it >was suggested that they be brought to the broader community for >consideration. It's highly likely that through the WG process we're able >to identify a means by which this issue can be addressed. > >QUESTION: Does it make sense for this proposed WG to explore how the >base specification can be extended to apply the same level of >"identifier alignment" to the as is helping defend the >? +1, we probably cannot solve it 100%, however, this WG seems like a potential place to establish a wider effort. > >----- >* a mechanism for mitigating the effect of failures of DMARC policy when >a message transits a mailing list >----- > >I recognize that there's definitely a counter-pressure against including >this topic as it seems to be a potentially quixotic quest. That being >said, even if we don't find the perfect solution, it does seem >reasonable to believe there is a way to provide something more than >nothing that does help in some meaningful way. I'm not presupposing a >solution, just that there have been a few possible options discussed at >the edges which are likely to be worth more rigorous exploration. > >QUESTION: Is there value in a WG such as this exploring possible >solutions to this issue and developing guidance that would potentially >help improve the utility of the base DMARC specification? +1, as we're heard through dmarc-discuss (and others) this is an issue important to the community. There is work to do here. > >----- >* support for the notion of transitive trust (i.e., "host X trusted the >sender of this message, and I trust X, so you should too") >----- > >I see this as similar to the above, but potentially more broadly >applicable. One tweak I'd offer would be to replace ", so you should >too" with something like ", so you could choose to as well". > >QUESTION: Is there value in a WG such as this exploring possible >solutions to this issue and developing guidance that would potentially >help improve the utility of the base DMARC specification? +1 > >----- >* more robust transport of reports >----- > >After over a year of deployment, and the rise in support services >handling reports, many folks have suggested that it would be worth >exploring how to offer additional optional means of transport for >reports. The base DMARC specification provides for this, but it is an >area that was left to be extended by a group such as this. > >QUESTION: Is this an area of exploration that is of enough interest to >include in the charter for this proposed work group? +1, as a large report parser, I'd love to +10 this one. Absolutely things to discuss here. > >Beyond those, the topics in the proposed "Using DMARC" document have >already proven useful in clarifying some options that aren't typically >included in a base specification. For example, here a few items that may >benefit from being specifically called out in the charter as worth >exploring: > >* Identifier alignment configuration options >* Implementation decisions regarding "pct" >* Determining effective RUA sending frequency >* Leveraging policy caching >* Various options for integrating within an existing flow >* Defining a useful, common set of RUA reporting options >* When and how to use local policy override options > >QUESTION: Do any items on this list seem to be worth specifically adding >to the proposed charter as examples of the type of work that would be >useful? +1. Using DMARC laid out a number of items to discuss further. > >Finally, this list of potential work items was developed a while ago, >and it's likely additional possible areas of exploration have surfaced >since then. Are there any other substantive items that would be worth >adding to the list? Keeping in mind, of course, that our first cut will >be to assume that the base specification isn't in scope for now. > >Once the dust settles a bit around these items, I'll take another whack >at the charter text to at least get it stable for now. Then we can >bubble up the bigger question and see if we can tackle that given the >input I've seen recently on other threads. > >Thanks again, >Trent > >-- >J. Trent Adams > >Profile: http://www.mediaslate.org/jtrentadams/ >LinkedIN: http://www.linkedin.com/in/jtrentadams >Twitter: http://twitter.com/jtrentadams > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From dcrocker@gmail.com Mon Jul 22 10:40:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192911E8121 for ; Mon, 22 Jul 2013 10:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN3sNx3igVRe for ; Mon, 22 Jul 2013 10:40:35 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2E11E80D2 for ; Mon, 22 Jul 2013 10:40:34 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so110182wes.1 for ; Mon, 22 Jul 2013 10:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=a0wsEesg5FqjZG8nWSigG6Y15RTogDdhLDE6+KByijE=; b=bqLK+VR1ME1YNB9fHtWqBcpb5h7lD20nzy1Gu+OE6kFQsUbq/EzmVMTIco/RwuJ7oS Fy0YlUiczNzpiWyqpVWwZ/PS/xX52LwWcNDFnG790vqSm3I4uo3V8cHxTM0iZU6ujjh+ CSStm0WpBqHuk8IqODrJjAixvG2gm9bdAsU4NrM4FdQOJSnckkkzJaTKTppPF/yjlgCD UFhOCkvlVWu1I4Xlm7dCoC8b7x+u17AWKFhIDznnnHxlHLMrYWmUTWNa5zckvy7TIQK8 ESdUvGGvUKTZ2u4BTxIXNiQLmDvV+lqQ7UcgbUqnZjsLh/SolQXGjcKgPyxBaXnxgxsM hsdg== X-Received: by 10.180.39.136 with SMTP id p8mr19399818wik.11.1374514833969; Mon, 22 Jul 2013 10:40:33 -0700 (PDT) Received: from [172.20.130.53] ([87.252.59.189]) by mx.google.com with ESMTPSA id eu1sm446839wib.8.2013.07.22.10.40.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 10:40:33 -0700 (PDT) Message-ID: <51ED6E8F.9070006@gmail.com> Date: Mon, 22 Jul 2013 18:40:31 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Franck Martin References: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter text to add X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:40:40 -0000 On 7/19/2013 9:42 PM, Franck Martin wrote: > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > It seems to me the BCP should provide advice on how you can > strengthen your receiving MTA to avoid "cousin" domain abuse. I see Please, no. Unless I've missed the extensive discussion on the topic, there's no basis for believing -- nevermind 'knowing' -- what will avoid that. There's no basis for tieing it to DMARC. > So I propose the following bullet point to add: > > - mechanisms for receivers to mitigate potential methods to > circumvent DMARC. For instance, but not limited to handling of > malformed emails, domain based blacklists and domain based > reputation Maybe it's jet lag, but I don't understand this text. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From MHammer@ag.com Mon Jul 22 10:53:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5EB11E811F for ; Mon, 22 Jul 2013 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScBJhRj+772Z for ; Mon, 22 Jul 2013 10:53:19 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 445AC11E8122 for ; Mon, 22 Jul 2013 10:53:17 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 22 Jul 2013 13:53:16 -0400 From: "MH Michael Hammer (5304)" To: Dave Crocker , Franck Martin Thread-Topic: [dmarc-ietf] Charter text to add Thread-Index: AQHOhMB8d2DqohlVn0S9WZfrlW5fMJlxPqyA//+/0ZA= Date: Mon, 22 Jul 2013 17:53:16 +0000 Message-ID: References: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> <51ED6E8F.9070006@gmail.com> In-Reply-To: <51ED6E8F.9070006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Charter text to add X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:53:25 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Dave Crocker > Sent: Monday, July 22, 2013 1:41 PM > To: Franck Martin > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Charter text to add >=20 > On 7/19/2013 9:42 PM, Franck Martin wrote: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > > > It seems to me the BCP should provide advice on how you can strengthen > > your receiving MTA to avoid "cousin" domain abuse. I see >=20 > Please, no. >=20 > Unless I've missed the extensive discussion on the topic, there's no basi= s for > believing -- nevermind 'knowing' -- what will avoid that. >=20 > There's no basis for tieing it to DMARC. >=20 +1 - While I believe that this is worthy of discussion and ultimately effor= ts to mitigate such abuse, it is clearly well beyond the scope of DMARC. Th= is should be a separate effort/document. >=20 > > So I propose the following bullet point to add: > > > > - mechanisms for receivers to mitigate potential methods to circumvent > > DMARC. For instance, but not limited to handling of malformed emails, > > domain based blacklists and domain based reputation >=20 > Maybe it's jet lag, but I don't understand this text. >=20 Yes. > d/ >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 From franck@peachymango.org Mon Jul 22 11:20:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20E11E8118 for ; Mon, 22 Jul 2013 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPluVeslTUW8 for ; Mon, 22 Jul 2013 11:20:32 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC4D11E80D2 for ; Mon, 22 Jul 2013 11:20:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AD391390056; Mon, 22 Jul 2013 13:20:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQZY-JLyXXHB; Mon, 22 Jul 2013 13:20:31 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8969F390069; Mon, 22 Jul 2013 13:20:31 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7713239002D; Mon, 22 Jul 2013 13:20:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uKDwGhrutf_r; Mon, 22 Jul 2013 13:20:31 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 12B87390056; Mon, 22 Jul 2013 13:20:30 -0500 (CDT) Date: Mon, 22 Jul 2013 13:20:29 -0500 (CDT) From: Franck Martin To: "MH Michael Hammer (5304)" Message-ID: <2031864057.32770.1374517229384.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> <51ED6E8F.9070006@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: [dmarc-ietf] Charter text to add Thread-Index: AQHOhMB8d2DqohlVn0S9WZfrlW5fMJlxPqyA//+/0ZCKLp4y+Q== Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] Charter text to add X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:20:37 -0000 The charter is about building a BCP for implementation of DMARC, but we will not provide advice or point in the right directions for closing the other doors that make DMARC irrelevant? This should not be an exhaustive anti-spamming implementation document, but if we talk about display name, then we can talk about cousin domains therefore all methods to reduce this type of exploits that are peripheral of DMARC. The BCP deserves such chapter. ----- Original Message ----- From: "MH Michael Hammer (5304)" To: "Dave Crocker" , "Franck Martin" Cc: dmarc@ietf.org Sent: Monday, July 22, 2013 10:53:16 AM Subject: Re: [dmarc-ietf] Charter text to add > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Dave Crocker > Sent: Monday, July 22, 2013 1:41 PM > To: Franck Martin > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Charter text to add > > On 7/19/2013 9:42 PM, Franck Martin wrote: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > > > It seems to me the BCP should provide advice on how you can strengthen > > your receiving MTA to avoid "cousin" domain abuse. I see > > Please, no. > > Unless I've missed the extensive discussion on the topic, there's no basis for > believing -- nevermind 'knowing' -- what will avoid that. > > There's no basis for tieing it to DMARC. > +1 - While I believe that this is worthy of discussion and ultimately efforts to mitigate such abuse, it is clearly well beyond the scope of DMARC. This should be a separate effort/document. > > > So I propose the following bullet point to add: > > > > - mechanisms for receivers to mitigate potential methods to circumvent > > DMARC. For instance, but not limited to handling of malformed emails, > > domain based blacklists and domain based reputation > > Maybe it's jet lag, but I don't understand this text. > Yes. From sweet@secondlook.com Mon Jul 22 11:36:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F721F8546 for ; Mon, 22 Jul 2013 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 DPBzajAEcImS for ; Mon, 22 Jul 2013 11:36:10 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A31BC21F999B for ; Mon, 22 Jul 2013 11:36:08 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id b10so5392993vea.16 for ; Mon, 22 Jul 2013 11:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=M5vd+VR2ryn7cX1A0f2hgfeYkS0X+9pVA87CsoIsY10=; b=CgWZL/RUvr3YEW7oFEgysJdjIU0v+PoMder6/nt0nTmrtsMzyEf6jGdIaasoy15FXd Cfs+HijkCUmMZqNi0kHj1d7TcQSQQXFAktj9i9lOCnCRALRm45CgFX30/X+l/69R17hq I7bDkLrmAFi19CVADSq2fVrN0JZ54QcMLoVI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=M5vd+VR2ryn7cX1A0f2hgfeYkS0X+9pVA87CsoIsY10=; b=aYp1fZsZWXEBhdh4/Zi7o2EfbmS+ntIwHkWLLdDWUeJqQ30cZkMZWPfdcuU4tJ48Wn LDjCzP3RUs3QZDxrFEYa3AyjdtZFIRrf2b622G+1LxgSt49qUimNy6ZFh3ixlYBY8qh2 fcibe7Ul3kEpsTodmuyxoHnfBHLWf0u8070vBGCwlHJuPqKe+u7Dhi5B825HBIaums7n U2Sbe5VL7eNS1hxZ1ULVPcSAcU/GqDAJtxej/cXisSAE1HzPr6Ovl7lKDpj9i29r/74y BPnZOUhB9KyBQijMjJ/5az2i2TXp2JWqnSy0hDw043MQekgk87hF3Pow/hs0i+rUfpro dLPQ== X-Received: by 10.58.197.5 with SMTP id iq5mr9904451vec.30.1374518165936; Mon, 22 Jul 2013 11:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.14.69 with HTTP; Mon, 22 Jul 2013 11:35:44 -0700 (PDT) X-Originating-IP: [50.0.158.65] In-Reply-To: References: <77426B543150464AA3F30DF1A91365DE53B79CB4@ESV4-MBX02.linkedin.biz> <51ED6E8F.9070006@gmail.com> From: John Sweet Date: Mon, 22 Jul 2013 11:35:44 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a11c322e604b0f104e21df3e5 X-Gm-Message-State: ALoCoQlw5eSLdXCJ+nioNEAC5ggxGU3mSzSYMQZOfAldN9Hj8HsISyv936dLoFRyFuOSrIcJO4tQ Subject: Re: [dmarc-ietf] Charter text to add X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:36:15 -0000 --001a11c322e604b0f104e21df3e5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 22, 2013 at 10:53 AM, MH Michael Hammer (5304) wrote: > > -----Original Message----- >> From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf >> Of Dave Crocker >> Sent: Monday, July 22, 2013 1:41 PM >> To: Franck Martin >> Cc: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Charter text to add >> >> On 7/19/2013 9:42 PM, Franck Martin wrote: >>> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC >>> >>> It seems to me the BCP should provide advice on how you can strengthen >>> your receiving MTA to avoid "cousin" domain abuse. >>> >> >> Please, no. >> >> Unless I've missed the extensive discussion on the topic, there's no >> basis for >> believing -- nevermind 'knowing' -- what will avoid that. >> >> There's no basis for tieing it to DMARC. >> > > +1 - While I believe that this is worthy of discussion and ultimately > efforts to mitigate such abuse, it is clearly well beyond the scope of > DMARC. This should be a separate effort/document. > IMHO, complaining that DMARC is vulnerable to cousin domain abuse is like pointing out that auto license plates can't prevent someone else from buying the same model/color car as yours, and wearing a disguise. I do appreciate that someone looking for the benefits of DMARC would also want guidance on how to address domain spoofing in general, but it feels like it could escalate to a bottomless time-suck very quickly. J --001a11c322e604b0f104e21df3e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 10:53 AM, MH Michael Hammer (5304) <MHammer@ag.com> wrote:

=A0= -----Original Message-----
=A0 From: dmarc-bounces@ietf.org = [mailto:dmarc-bounces@ietf.org] On Behalf
=A0 Of Dave Crocker
=A0 Sent: Monday, July 22, 2013 1:41 PM
=A0 To: Franck Martin
=A0 Cc: dmarc@ietf.org
=A0 Subject: Re: [dmarc-ietf] Charter text to add

=A0 On 7/19/2013 9:42 PM, Franck Martin wrote:
=A0 http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

=A0 It seems to me the BCP should provide advice on how you can strengthen
= =A0 your receiving MTA to avoid "cousin" domain abuse.

=A0 Please, no.

=A0 Unless I've missed the extensive discussion on the topic, there's n= o basis for
=A0 believing -- nevermind 'knowing' -- what will avoid that.

=A0 There's no basis for tieing it to DMARC.

+1 - While I believe that this is worthy of discussion and ultimately= efforts to mitigate such abuse, it is clearly well beyond the scope of DMA= RC. This should be a separate effort/document.

IMHO, complaining that DMARC is vulnerable to cousin domain abuse = is like pointing out that auto license plates can't prevent someone els= e from buying the same model/color car as yours, and wearing a disguise.
I do appreciate that someone looking for the benefits of DMARC would al= so want guidance on how to address domain spoofing in general, but it feels= like it could escalate to a bottomless time-suck very quickly.

J
--001a11c322e604b0f104e21df3e5-- From jtrentadams@gmail.com Tue Jul 23 15:56:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3F11E816F for ; Tue, 23 Jul 2013 15:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnuhBVq+96Va for ; Tue, 23 Jul 2013 15:56:53 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CA01B11E8169 for ; Tue, 23 Jul 2013 15:56:47 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so12794672oag.32 for ; Tue, 23 Jul 2013 15:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=FUEoRZO38GEeijVAZ0T+cVMu3rhDjhYQaWCU8i6kyEU=; b=BozPQj/Qbnbb+RhclBKnP0XLeUK8Pf8tsa5AlRAfDBbz0jbw/fKPBn+H9u+5VNnOpn wqF0jWUU7V7+YbQuHrFxXKvPVY/mD9A4sHrlBT6dJr7lwGA9DsaD8irzSphGE/3hehnB wFRyFNulCwsyntE527ZB0quIh2REnaRKXuiQLvUG5N3TFijo06jXgGmRi7PL9e6cno14 J/GLZUcbCt2CtreDLjjC8AHVbzaA95VA1YqWpoQ9NyYKC5q3jNDsGgembrw4JeaosfOJ V7AGS2/OmNrVmmPgoH17fG09lkVqDlRtJQaAT78e7Y9jpJW1lr8EQUICHLxbYJ63H3jj W/5A== X-Received: by 10.60.146.230 with SMTP id tf6mr33540992oeb.94.1374620207312; Tue, 23 Jul 2013 15:56:47 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id ya5sm36101572obc.1.2013.07.23.15.56.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:56:46 -0700 (PDT) Message-ID: <51EF0A2D.4080702@gmail.com> Date: Tue, 23 Jul 2013 16:56:45 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmarc@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:56:54 -0000 As the holder of the pen on the draft charter for the proposed DMARC WG, I have taken the input from the list and incorporated it into an update: http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC As a reminder, this includes the guidance provided by Russ and Barry that we treat the base specification as being an Individual Submission that is AD Sponsored. The scope and identified items of work follow on that assumption. Please take a look at it and reply with your comments so we can address as much of them as possible prior to the meeting. Otherwise, I look forward to the conversation in Berlin next week. Thanks, Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From tim@eudaemon.net Tue Jul 23 17:02:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046BD21F84D9 for ; Tue, 23 Jul 2013 17:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XS7ITwTsl0I for ; Tue, 23 Jul 2013 17:02:47 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF7821F847C for ; Tue, 23 Jul 2013 17:02:47 -0700 (PDT) Received: from [10.0.1.8] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id CD1A2CB46 for ; Tue, 23 Jul 2013 20:03:21 -0400 (EDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_2869DE0B-6844-4B21-88C8-EE1DF215FF00" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 23 Jul 2013 20:02:46 -0400 References: <51EF0A2D.4080702@gmail.com> To: "dmarc@ietf.org" In-Reply-To: <51EF0A2D.4080702@gmail.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:02:52 -0000 --Apple-Mail=_2869DE0B-6844-4B21-88C8-EE1DF215FF00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 23, 2013, at 6:56 PM, J. Trent Adams = wrote: >=20 > As the holder of the pen on the draft charter for the proposed DMARC = WG, > I have taken the input from the list and incorporated it into an = update: >=20 > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC Hey Trent, thanks for doing this. I support this effort, admit to not = being an expert of IETF process, and have a slew of largely editorial = nits: DMARC allows a sender to indicate that its legitimate emails are = protected by SPF and/or DKIM, matching the validated sending domains = with the sender's email address domain in the RFC5322:=46rom field (aka = "identifier alignment"), and advises a receiver what it should do if = neither of those authentication methods yields a relevant authenticated = identifier passes, or the identifiers fail to align, for a received = message. It also provides a reporting mechanism, from receivers back to = domain owners. This sentence no longer feels accurate: Such capabilities over the public Internet are unusual and their use is = still being explored not yet well-understood. This one is hard for me to parse: The working group will explore possible extensions to the base, to = address limitations of the mechanism in particular scenarios or for = added capabilities, and provide technical implementation guidance. How about: The working group will explore possible extensions to the base, to = address context-specific limitations of the mechanism, to consider added = capabilities, and to provide technical implementation guidance. Typo: The guid(e) will catalog.. OK! For actual content: The initial charter for this working group does not include revising the = base specification,.. I wish there was a way to allow changes to the base specification aside = from "bits over the wire" changes (with a heavy nod towards maintaining = interoperability), so that readability and clarity can be tackled. Thanks again for putting this together, =3D- Tim --Apple-Mail=_2869DE0B-6844-4B21-88C8-EE1DF215FF00 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii jtrentadams@gmail.com> = wrote:

As the holder of the pen on = the draft charter for the proposed DMARC WG,
I have taken the input = from the list and incorporated it into an update:

http://wiki= .tools.ietf.org/wg/appsawg/trac/wiki/DMARC

<= div>Hey Trent, thanks for doing this.  I support this effort, admit = to not being an expert of IETF process, and have a slew of largely = editorial nits:

DMARC allows a sender to = indicate that its legitimate emails are protected by SPF = and/or DKIM, matching the validated sending domains with the = sender's email address domain in = the RFC5322:=46rom field (aka "identifier alignment"), and = advises a receiver what it should do if neither of those = authentication methods yields a relevant authenticated identifier = passes, or the identifiers fail to align, for = a received message. It also provides a reporting = mechanism, from receivers back to = domain owners.

This sentence no longer = feels accurate:

Such capabilities over the = public Internet are unusual and their use is still being explored = not yet = well-understood.

This one = is hard for me to parse:

The working = group will explore possible extensions to the base, to address limitations of = the mechanism=20 in particular scenarios or for added capabilities, and provide technical = implementation guidance.

How = about:

The working group will explore = possible extensions to the base, to address context-specific limitations = of the mechanism, to consider added capabilities, and to provide = technical implementation = guidance.

Typo:

The guid(e) will = catalog..


OK! =  For actual content:

The initial = charter for this working group does not include revising the base specification,..

I wish = there was a way to allow changes to the base specification aside from = "bits over the wire" changes (with a heavy nod towards maintaining = interoperability), so that readability and clarity can be = tackled.

Thanks again for putting this = together,
=3D- Tim

= --Apple-Mail=_2869DE0B-6844-4B21-88C8-EE1DF215FF00-- From sklist@kitterman.com Tue Jul 23 18:43:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85311E81B9 for ; Tue, 23 Jul 2013 18:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eofEAjvmQB2h for ; Tue, 23 Jul 2013 18:43:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D271A11E81B8 for ; Tue, 23 Jul 2013 18:43:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3DE8E20E40F6; Tue, 23 Jul 2013 21:43:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1374630183; bh=m9xEkfCki4YArv1ebEFefoUlsHSFgv/nuJqf6I2J5yY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pesul6y8DwGROOH9Rmt27iX7P9XE5G/dG585CGOgQF3q9mhxlzINA3hwuoU4DL/jx +zwwYiYfF+2s4XAdSfLeQb4Dc4H2rclwH4t+6EreFiWCghteyQFac7yrpolAiiQxXl IAwv5cb/2hGuZ1/jqFgd9wZfS6ru8544EpgUpZTk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1D14320E40B0; Tue, 23 Jul 2013 21:43:02 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 23 Jul 2013 21:43:02 -0400 Message-ID: <2606672.N9eGFG3hY4@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <51EF0A2D.4080702@gmail.com> References: <51EF0A2D.4080702@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:43:14 -0000 On Tuesday, July 23, 2013 04:56:45 PM J. Trent Adams wrote: > As the holder of the pen on the draft charter for the proposed DMARC WG, > I have taken the input from the list and incorporated it into an update: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > As a reminder, this includes the guidance provided by Russ and Barry > that we treat the base specification as being an Individual Submission > that is AD Sponsored. The scope and identified items of work follow on > that assumption. > > Please take a look at it and reply with your comments so we can address > as much of them as possible prior to the meeting. Otherwise, I look > forward to the conversation in Berlin next week. I really don't understand why the DMARC base spec can adequately be developed by an outside group and AD sponsored, while a BCP to use that spec needs an IETF WG? If the expertise is in the group writing the base spec, they should just do the BCP too. I think at this point it's a working group to have a working group. Scott K From dcrocker@gmail.com Tue Jul 23 21:24:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0111E834E for ; Tue, 23 Jul 2013 21:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWTwbV6Zn3Kx for ; Tue, 23 Jul 2013 21:24:07 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D08E111E81CC for ; Tue, 23 Jul 2013 21:24:00 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so7640667wgh.4 for ; Tue, 23 Jul 2013 21:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=en0FwWrv05RJt+BL6lloOdYgN+/+ugkH3VNKppy7Z4M=; b=puyVJktS03v8SK3Sp4/neMVG7uWSLYD2S6M/5Yz80Y+wecxxm0cOdehbZ9EjDN/Tyd 9iygZh0ixLIKveOaGDQ1RSWsio7NDqpd2I/9OdlVEpIXsOaFQUHAli3+A6qjIbdzaC5o C9ECuotAE9vmRtgMvRfOEUqmSIen7XAsh9LfCxm0R/WTvCiJ6AqqYq/Bru7J8u6rChZT VdDKZRcp/J1/o2UH8n0mACoVuBHUj5mZ5PkcdSUWzKU+AKc4dqvf4qYMwSoxgE9CKtlH 2pGD5/WVIYuSSkqnpmBxXf3ICtyp2Wv/J9y6z58ftOaQRK/y6xSgywAWUpgiG2N+o2ws uKng== X-Received: by 10.194.1.226 with SMTP id 2mr14719994wjp.91.1374639839670; Tue, 23 Jul 2013 21:23:59 -0700 (PDT) Received: from [10.0.0.252] (host217-40-191-246.in-addr.btopenworld.com. [217.40.191.246]) by mx.google.com with ESMTPSA id s19sm2408997wik.11.2013.07.23.21.23.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 21:23:59 -0700 (PDT) Message-ID: <51EF56DA.9040807@gmail.com> Date: Wed, 24 Jul 2013 05:23:54 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "J. Trent Adams" References: <51EF0A2D.4080702@gmail.com> In-Reply-To: <51EF0A2D.4080702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 04:24:08 -0000 On 7/23/2013 11:56 PM, J. Trent Adams wrote: > > As the holder of the pen on the draft charter for the proposed DMARC WG, > I have taken the input from the list and incorporated it into an update: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC I think the paragraph that bothered some as too 'marketing' oriented has been productively transformed into a pedantic, academic style. Much more credible. Good job. By way of demonstrating that the text must be asymptoting nicely, herewith my nitpicks... well-known company (aka, "brand") -> well-known company (also called "brand") { aka is an extreme colloquialism; besides being too informal for something this official, this sort of text is purported to be a special challenge for those who do not suffer English as their native language. fwiw, eg and ie also fall into this category, I'm told. } trust-based layer -> trust-oriented layer { besides suspecting the latter is more accurate, it bugs me to see 'based' used twice in close proximity... } matching the validated sending domains -> matching the validated domains { as an example, rfc5321.mailfrom is a return address and might have had nothing to do with sending. what? you thought I was kidding about nit-picking? } field (aka "identifier alignment") -> ... Individual Submission (a.k.a. "Area Director Sponsored") for publication -> Individual Submission for publication, which is sponsored by an Area Director. and provide -> and will provide { parallel construction } practice or bits over the wire -> practice, in particular the bits over the wire, need to be added as extensions, rather -> need to be additions, rather This permits unmodified -> This will permit unmodified Oops. Not a nit-pick: a mechanism for ensuring the RFC5322.From field can be relied upon as the primary means of DMARC identifier alignment I can parse the language, but have no idea what this means, in spite of knowing the gist of what's intended. This is obscure/confusing enough, I can't even suggest a fix. failures of DMARC policy -> failures of the DMARC mechanism { in the abstract, yeah, it's probably a policy failure; but let's keep it mundane; the procedure doesn't work in this scenario. } determine the organizational domain responsible for sending mail. -> {add} An Organizational Domain is the basic domain domain name obtained through a public registry, such as example.com or example.co.uk. { The term Organizational Domain is not in common use, so it should be explained. Also the text explaining the term at dmarc.org/overview.html really isn't correct, as demonstrated by the .co.uk example. } leverage the public suffix list -> use an information "public suffix" list solution will not scale -> solution will not scale, and that the current list often is inaccurate This working group recognizes work on a solution to be out of scope, however, depending on work in other groups, it would be in scope to explore extending the base specification to accommodate that work. -> The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. The guid will -> The guide will Defining a useful, common set of RUA reporting options -> Defining a useful, common set of reporting options for the addresses to which aggregate feedback is to be sent (RUA) For reference, draft-crocker-dmarc-bcp-02 is a proposed draft of the guide for input to this working group. -> draft-crocker-dmarc-bcp-02 will serve as the starting point for the implementation and deployment guide. Jet lag sucks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Tue Jul 23 22:23:29 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3E11E81F2 for ; Tue, 23 Jul 2013 22:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibRO6xy-qrvS for ; Tue, 23 Jul 2013 22:23:28 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DD86A11E81F6 for ; Tue, 23 Jul 2013 22:23:27 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so3811811wiv.8 for ; Tue, 23 Jul 2013 22:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iB6mmbt7/C8RF8XyFMPa5TuThiQxE+BfxiSdm3tOJi8=; b=gcHbmYFwkYvkbZamj/g3b44QbpMf99Qb2mZmTOIi+25ZTYe92Aldw6jQm3Vcu6qHwD CcobMweJiZJcbSwiy4ACSVi/w9BZXUSmQKRQSPpvgQKXVkIzA0vdCYKt97n8QWLPPPkp fYanl5d3MhbowvWBF18itpSLdw50Dne2X0aKfTA6E7trpn9xsvjkD4uoktvxrygwCNsM 37gBgF6tZwpB27+8WdPs/taZUt4fGOhB0wHR7aok6HVLaHsCv1ihgRnOKAldW58HLayl zsz7QUyA1+uzS0gEnkUdgxSMljMMqLsRK14/t8qxdeWLyJKp9r8KBC/5KV9dRwStreWr 1gXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iB6mmbt7/C8RF8XyFMPa5TuThiQxE+BfxiSdm3tOJi8=; b=FJN+vwafJXT1O8NtzyhxDuZ+kWaFN3RK7DuxQ5OHzoumRg0+gzsrTvEmHCnKNOY3rZ j0dqFDmczYh7iwPkGzue4u86kuZlAJfGu+huQqUWXRyCRmv6kg5f0kQWImihMbGXMNLH A/l1VpGF17ZZHM9J8mcBZ4Y9nh2A2ZWCA6IYMJfRFzMDKqPEcFPhqAF7Rfvf/stg7BhS jKwYr/XVtM1w8mGPIn3998aor9S/zXLGy2sacxGPSLlXQ/4Yf3Hvu+mhdNpW7YkwN+aJ QCwvYv+vRjcd1f22T2A5YqhEK52xvXTXy1SMnLHJ11/zTZj2hxq4ImcJPOYAC+6oG0sb Q1cQ== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr1347946wib.19.1374643405703; Tue, 23 Jul 2013 22:23:25 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 23 Jul 2013 22:23:25 -0700 (PDT) In-Reply-To: <2606672.N9eGFG3hY4@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <2606672.N9eGFG3hY4@scott-latitude-e6320> Date: Tue, 23 Jul 2013 22:23:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f3ba255e3d11204e23b1be9 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:23:29 -0000 --e89a8f3ba255e3d11204e23b1be9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 23, 2013 at 6:43 PM, Scott Kitterman wrote: > I really don't understand why the DMARC base spec can adequately be > developed > by an outside group and AD sponsored, while a BCP to use that spec needs an > IETF WG? If the expertise is in the group writing the base spec, they > should > just do the BCP too. I think at this point it's a working group to have a > working group. > There have been presented plenty of things about the DMARC base specification that need tuning in terms of language, layout, etc., but I believe everything that's been identified so far can be resolved during the mandatory IETF-wide Last Call, or the intervening time. In particular, there has not to date (including its life as an I-D and also a long period before that) been presented anything like "this whole idea is totally broken" or "this particular part needs to go back to the drawing board". Spinning up a working group merely to tune language or clarify things is a lot of expense for minimal return. On the other hand, the "Using" document is roughly skeletal and needs a ton of work, and there have been identified several other topics related to DMARC that need resolution for DMARC to be completely successful, and there is some measure of community agreement on them. That's real work that needs doing. What the BoF will attempt to determine is if the community interested in doing the work is large enough and dedicated enough to warrant the expense of spinning up a working group. I don't understand why the group containing the expertise is to be automatically disqualified from making this request merely because it worked on the base proposal for a long time externally, both privately and publicly, before bringing it to the IETF. If the complaint is that the group's process has been too closed and exclusive to date, why would we want to discourage it from opening up to public scrutiny and input? -MSK --e89a8f3ba255e3d11204e23b1be9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2013 at 6:43 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
I really don't understand why the DMARC = base spec can adequately be developed
by an outside group and AD sponsored, while a BCP to use that spec needs an=
IETF WG? =A0If the expertise is in the group writing the base spec, they sh= ould
just do the BCP too. =A0I think at this point it's a working group to h= ave a
working group.

There have been presented ple= nty of things about the DMARC base specification that need tuning in terms = of language, layout, etc., but I believe everything that's been identif= ied so far can be resolved during the mandatory IETF-wide Last Call, or the= intervening time.=A0 In particular, there has not to date (including its l= ife as an I-D and also a long period before that) been presented anything l= ike "this whole idea is totally broken" or "this particular = part needs to go back to the drawing board".=A0 Spinning up a working = group merely to tune language or clarify things is a lot of expense for min= imal return.

On the other hand, the "Using&quo= t; document is roughly skeletal and needs a ton of work, and there have bee= n identified several other topics related to DMARC that need resolution for= DMARC to be completely successful, and there is some measure of community = agreement on them.=A0 That's real work that needs doing.=A0 What the Bo= F will attempt to determine is if the community interested in doing the wor= k is large enough and dedicated enough to warrant the expense of spinning u= p a working group.

I don't understand why the group c= ontaining the expertise is to be automatically disqualified from making thi= s request merely because it worked on the base proposal for a long time ext= ernally, both privately and publicly, before bringing it to the IETF.=A0 If= the complaint is that the group's process has been too closed and excl= usive to date, why would we want to discourage it from opening up to public= scrutiny and input?

-MSK
--e89a8f3ba255e3d11204e23b1be9-- From sklist@kitterman.com Tue Jul 23 22:28:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2CF11E81F4 for ; Tue, 23 Jul 2013 22:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOBldOY69dtm for ; Tue, 23 Jul 2013 22:28:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E16EA11E81F2 for ; Tue, 23 Jul 2013 22:28:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 371B820E40F6; Wed, 24 Jul 2013 01:28:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1374643719; bh=+oO6xgmlkaQO1sOKmGqVmHdknSKy+zKOcBM+/CCDoxQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hsJOHJrb2pCiF3xb9l+ltn7KPSGjeXT+6r7elYfGHx6Pf7aNGxX2WYq3KAWkNrLq0 bsRzIiMSYWCWLZTAA/69BLOJ2q0fzv487iv1RlySW7q9XFciv5qSFe7RoGpSfrkEfB TtsbLwuItFgtxYy2HvLWZBCyBfDtjMnELbLcrtEE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 19CE820E40B0; Wed, 24 Jul 2013 01:28:38 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 24 Jul 2013 01:28:38 -0400 Message-ID: <27496080.geGbC66fNp@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <51EF0A2D.4080702@gmail.com> <2606672.N9eGFG3hY4@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: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:28:45 -0000 On Tuesday, July 23, 2013 10:23:25 PM Murray S. Kucherawy wrote: > On Tue, Jul 23, 2013 at 6:43 PM, Scott Kitterman wrote: > > I really don't understand why the DMARC base spec can adequately be > > developed > > by an outside group and AD sponsored, while a BCP to use that spec needs > > an > > IETF WG? If the expertise is in the group writing the base spec, they > > should > > just do the BCP too. I think at this point it's a working group to have a > > working group. > > There have been presented plenty of things about the DMARC base > specification that need tuning in terms of language, layout, etc., but I > believe everything that's been identified so far can be resolved during the > mandatory IETF-wide Last Call, or the intervening time. In particular, > there has not to date (including its life as an I-D and also a long period > before that) been presented anything like "this whole idea is totally > broken" or "this particular part needs to go back to the drawing board". > Spinning up a working group merely to tune language or clarify things is a > lot of expense for minimal return. > > On the other hand, the "Using" document is roughly skeletal and needs a ton > of work, and there have been identified several other topics related to > DMARC that need resolution for DMARC to be completely successful, and there > is some measure of community agreement on them. That's real work that > needs doing. What the BoF will attempt to determine is if the community > interested in doing the work is large enough and dedicated enough to > warrant the expense of spinning up a working group. > > I don't understand why the group containing the expertise is to be > automatically disqualified from making this request merely because it > worked on the base proposal for a long time externally, both privately and > publicly, before bringing it to the IETF. If the complaint is that the > group's process has been too closed and exclusive to date, why would we > want to discourage it from opening up to public scrutiny and input? You wouldn't. Which is exactly why the working group should work through the details of the base spec too. I think the premise that says you need an IETF working group to do the using document, but not to finish the base spec is illogical. Scott K From superuser@gmail.com Tue Jul 23 22:29:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD5311E8391 for ; Tue, 23 Jul 2013 22:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjTskC+8s-Rr for ; Tue, 23 Jul 2013 22:29:06 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 118F611E81F2 for ; Tue, 23 Jul 2013 22:29:05 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so3034575wes.41 for ; Tue, 23 Jul 2013 22:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nIK3uhWO+lHaQ002lWxi7UpJr+9/X4iLDlEQSlc85OU=; b=vVo4qYoLzu3gLMqgjFVykDNJlr+3IMAQCSVUmtHoLT/w1q3/M6xsSrEbMn0vRNMpC7 4k9/zAatvvcpIGZS5pPZTrk5fu/fGBTuWYbmXtNcj6R1QP31x3s2lZHRrsmKseRmiZoq M8QFJU+dYd48+Mdl+qXq+leP8kRIgq7uet9dzrYzysuma1oBe5Fc9E6jMlgIsVJJLmQg 4W9H52byoYIwISMvntWea3HxmovBfsAU4EM0/5zmUJ7P4T5jKf78Xj4ko3yQEVW23NcQ RHw2jknQH7PMtT8cjXeAQL6zrk3TX9sWavWq6jya65mQLniechRlp+gAxAaJWNbrXt7I k0RQ== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr25492487wjc.63.1374643743990; Tue, 23 Jul 2013 22:29:03 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 23 Jul 2013 22:29:03 -0700 (PDT) In-Reply-To: <51EF0A2D.4080702@gmail.com> References: <51EF0A2D.4080702@gmail.com> Date: Tue, 23 Jul 2013 22:29:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Trent Adams" Content-Type: multipart/alternative; boundary=089e014933840daae504e23b301e Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:29:07 -0000 --089e014933840daae504e23b301e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams wrote: > As the holder of the pen on the draft charter for the proposed DMARC WG, > I have taken the input from the list and incorporated it into an update: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > As a reminder, this includes the guidance provided by Russ and Barry > that we treat the base specification as being an Individual Submission > that is AD Sponsored. The scope and identified items of work follow on > that assumption. > > Please take a look at it and reply with your comments so we can address > as much of them as possible prior to the meeting. Otherwise, I look > forward to the conversation in Berlin next week. > > Recognizing that the charter is still subject to edits especially as a result of the Berlin discussion, I think this looks fine to me as a basis for that discussion. I concur with Dave's nits, but I don't feel strongly about any of them (he's jet lagged, I'm just tired). One nit of my own: You can take the version number out of the second draft reference, since the first one doesn't name a specific version and the number could change before the working group actually charters. -MSK --089e014933840daae504e23b301e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams <jtr= entadams@gmail.com> wrote:
As the holder of the pen on the draft charte= r for the proposed DMARC WG,
I have taken the input from the list and incorporated it into an update:
http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

As a reminder, this includes the guidance provided by Russ and Barry
that we treat the base specification as being an Individual Submission
that is AD Sponsored. =A0The scope and identified items of work follow on that assumption.

Please take a look at it and reply with your comments so we can address
as much of them as possible prior to the meeting. =A0Otherwise, I look
forward to the conversation in Berlin next week.

<= br>
Recognizing that the charter is still subject to edits especi= ally as a result of the Berlin discussion, I think this looks fine to me as= a basis for that discussion.=A0 I concur with Dave's nits, but I don&#= 39;t feel strongly about any of them (he's jet lagged, I'm just tir= ed).

One nit of my own: You can take the version number out of the second dr= aft reference, since the first one doesn't name a specific version and = the number could change before the working group actually charters.

-MSK
--089e014933840daae504e23b301e-- From superuser@gmail.com Tue Jul 23 22:57:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C095E11E81F7 for ; Tue, 23 Jul 2013 22:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajo-+Appag3T for ; Tue, 23 Jul 2013 22:57:44 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3A11E81F2 for ; Tue, 23 Jul 2013 22:57:43 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so3850844wiw.13 for ; Tue, 23 Jul 2013 22:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=53s/1I9l4zx3kAGolx/JOAzR4kISm8UWUU+3a3la+5E=; b=Dd58pr9qY8teAbct5G+PgnlclwTo3pMk5bAZb4CM2+0u7Hq4h7cLd/Yeh3j4Q37Fab z/MdZXVesGGvgHGc8IbQ7RUZVshndeUB3/Crh/R+ZGrUg6/v4/TY0/p7CUwUoG38Uo85 tCS5DF9W89a/UAVQwAEi90rJK+C38xFpdrJ1L9UyLUbKDW3kLu27G3XsWU3fkK9FTNlq qRGM4W6fMo3IxhB5g9bc5aD8iZ/n5rNbWZInua7sO/yjerIhXMyKtxejdrrwWm8QyjsN L9qsyZJa7a7AzhJNQno7Cz6BwtcFagZScUVdycXAVM2rvRClqnU4UEj9h1BfRFYENYxf 405g== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr26061588wjn.23.1374645462936; Tue, 23 Jul 2013 22:57:42 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 23 Jul 2013 22:57:42 -0700 (PDT) In-Reply-To: <27496080.geGbC66fNp@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <2606672.N9eGFG3hY4@scott-latitude-e6320> <27496080.geGbC66fNp@scott-latitude-e6320> Date: Tue, 23 Jul 2013 22:57:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7ba975e682c67104e23b96a5 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:57:44 -0000 --047d7ba975e682c67104e23b96a5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 23, 2013 at 10:28 PM, Scott Kitterman wrote: > You wouldn't. Which is exactly why the working group should work through > the > details of the base spec too. I think the premise that says you need an > IETF > working group to do the using document, but not to finish the base spec is > illogical. > > You've ignored the first paragraph in my earlier message. The proposal of working on the document as an Individual Submission does not mean it is immutable. It will go through an IETF Last Call just like any other, and it will be required to accommodate any sustained feedback received. Rather, the claim is that the review comments that have been posted to date, inclusive of your July 14th review -- which was very useful, by the way, in spite of the "secret group" jab -- are not of sufficient severity to send the whole thing back to the drawing board in the context of a working group, which is an expensive prospect for everyone involved (particularly the sponsoring AD). A new working group's time and energy would be better spent working on the engineering problems and informational material the base document doesn't already deliver. On the other hand, I would object to the creation of a working group merely to satisfy the accusation that the developers have been operating in secret, especially since the base draft was made widely available for public review and comment over 18 months ago, when work that is largely editorial is all that's been identified as needing attention. -MSK --047d7ba975e682c67104e23b96a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2013 at 10:28 PM, Scott Kitterman <skl= ist@kitterman.com> wrote:
You wouldn't. =A0Whic= h is exactly why the working group should work through the
details of the base spec too. =A0I think the premise that says you need an = IETF
working group to do the using document, but not to finish the base spec is<= br> illogical.


You've ignored the f= irst paragraph in my earlier message.

The proposal of working on the= document as an Individual Submission does not mean it is immutable.=A0 It = will go through an IETF Last Call just like any other, and it will be requi= red to accommodate any sustained feedback received.

Rather, the claim is that the review comments that have been posted to = date, inclusive of your July 14th review -- which was very useful, by the w= ay, in spite of the "secret group" jab -- are not of sufficient s= everity to send the whole thing back to the drawing board in the context of= a working group, which is an expensive prospect for everyone involved (par= ticularly the sponsoring AD).=A0 A new working group's time and energy = would be better spent working on the engineering problems and informational= material the base document doesn't already deliver.

On the other hand, I would object to the creation of a worki= ng group merely to satisfy the accusation that the developers have been ope= rating in secret, especially since the base draft was made widely available= for public review and comment over 18 months ago, when work that is largel= y editorial is all that's been identified as needing attention.

-MSK
--047d7ba975e682c67104e23b96a5-- From dcrocker@gmail.com Tue Jul 23 23:57:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7511E81FF for ; Tue, 23 Jul 2013 23:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE58PRVwNTrC for ; Tue, 23 Jul 2013 23:57:34 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 919A511E8399 for ; Tue, 23 Jul 2013 23:57:32 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so1223941wev.36 for ; Tue, 23 Jul 2013 23:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wBRYNIKvUSEr8aO5xWDlIyHRMZY8GBWmXNvRJ96yurc=; b=JfElS303xsTuZeH7zvcsilbHg+5cELip+yt7rj0kOm9S5nDBWvlc+k34n0SGDwVZ9p 9hyn3gujZ1Kntih7yOX9BBaVZkNgEZIDKEgt6esDVq6AgPcRRQJ7FnqhrqhHCYgSvRnB AFcISdWDX13uvCMJLqivX1U61ryJE732ljypgUujEI+uKbyPdsyncf2GBLdkoieeRFYT FLSGnUioPYf6oPdCj9jzyGWNilrxwhaZJ1iA1UC0gFO7tWXGw8hK7bW0QIE9CymgJUq3 aUp+wfF0lYgrHePiYglB5ij/tiGjhpVwIgvsLhQTx3W+c3k4sybhRaKuHhXglSSTCxzY HtWg== X-Received: by 10.180.160.203 with SMTP id xm11mr1444158wib.58.1374649051737; Tue, 23 Jul 2013 23:57:31 -0700 (PDT) Received: from [10.0.0.252] (host217-40-191-246.in-addr.btopenworld.com. [217.40.191.246]) by mx.google.com with ESMTPSA id s19sm3020929wik.11.2013.07.23.23.57.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 23:57:31 -0700 (PDT) Message-ID: <51EF7AD6.30901@gmail.com> Date: Wed, 24 Jul 2013 07:57:26 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <51EF0A2D.4080702@gmail.com> <2606672.N9eGFG3hY4@scott-latitude-e6320> <27496080.geGbC66fNp@scott-latitude-e6320> In-Reply-To: <27496080.geGbC66fNp@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 06:57:35 -0000 On 7/24/2013 6:28 AM, Scott Kitterman wrote: > On Tuesday, July 23, 2013 10:23:25 PM Murray S. Kucherawy wrote: >> On Tue, Jul 23, 2013 at 6:43 PM, Scott Kitterman > wrote: >>> I really don't understand why the DMARC base spec can adequately >>> be developed by an outside group and AD sponsored, while a BCP to >>> use that spec needs an IETF WG? ... >> I don't understand why the group containing the expertise is to be >> automatically disqualified from making this request merely because it >> worked on the base proposal ... > You wouldn't. Which is exactly why the working group should work through the > details of the base spec too. I think the premise that says you need an IETF > working group to do the using document, but not to finish the base spec is > illogical. Scott, You persist in making a process complaint, when there is no process error. Since you feel so strongly otherwise, you have the burden of documenting it. After /many/ rounds of your invoking this claim, you have yet to document the error. And then there is the small matter of our having no technical work to do that has community support, and your continued failure to document otherwise. Let's have a working group when there is no technical work to do? Please, no. And then there is your above response to Murray that looks suspiciously like an ad hominem. Since those are not permitted in the IETF, I'm sure you didn't intend it, but it suggests that your frustration is getting in the way of making cogent arguments for your case. In fact your next sentence purports to be some sort of logical conclusion based on your apparent ad hominem. Really? In what system of logic does that work? I've no idea why you think that repeating the same complaint, after getting the same, concrete explanations, will somehow produce a different outcome. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sklist@kitterman.com Wed Jul 24 06:08:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4650C11E8216 for ; Wed, 24 Jul 2013 06:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHYL63vjKl6V for ; Wed, 24 Jul 2013 06:08:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2983211E80E0 for ; Wed, 24 Jul 2013 06:08:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CF6E820E40EF; Wed, 24 Jul 2013 09:07:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1374671278; bh=ItM6ACCc2PdEokT5oE6nS1NAO/KIL3DjlBae/QV68OY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=i/ds2Gd69nHtTrdOurnxEQXygroGskwf6T5l21gufH3BC0VFZR5zfPz5kfvexaH7q L4FJ8PZ8S/sdX7Le7CaQ7oYsPmhJr89GzARRiroPNAB1Nzx3nwJ/glw2D0vXcSBhwT 1UAgvsB+F3tpvucTY4NXZP8mbyi3W76ZzeDBW77E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B64F720E40BE; Wed, 24 Jul 2013 09:07:58 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 24 Jul 2013 09:07:57 -0400 Message-ID: <1776975.bIMgeWNKBr@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@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: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:08:35 -0000 On Tuesday, July 23, 2013 10:57:42 PM Murray S. Kucherawy wrote: > On Tue, Jul 23, 2013 at 10:28 PM, Scott Kitterman wrote: > > You wouldn't. Which is exactly why the working group should work through > > the > > details of the base spec too. I think the premise that says you need an > > IETF > > working group to do the using document, but not to finish the base spec is > > illogical. > > You've ignored the first paragraph in my earlier message. > > The proposal of working on the document as an Individual Submission does > not mean it is immutable. It will go through an IETF Last Call just like > any other, and it will be required to accommodate any sustained feedback > received. I've already said I don't think that the proposed approach is adequate and (believe it or not) I am trying to minimize how much I repeat myself. > Rather, the claim is that the review comments that have been posted to > date, inclusive of your July 14th review -- which was very useful, by the > way, in spite of the "secret group" jab -- are not of sufficient severity > to send the whole thing back to the drawing board in the context of a > working group, which is an expensive prospect for everyone involved > (particularly the sponsoring AD). A new working group's time and energy > would be better spent working on the engineering problems and informational > material the base document doesn't already deliver. To my knowledge, there have been less than a handful of reviews (I didn't go back and look, so that may be wrong) and more than one of them carried caveats that the reviews were somewhat cursory. My conclusion is that there has been little serious review and that it's premature to conclude anything from the ones that have been done other than that the document is no where near ready for publication. That said, I agree with the general premise that changes to bits on the wire are unlikely to be needed, but that doesn't mean the document doesn't need significant work. Secret group isn't a "jab". It's a fact. > On the other hand, I would object to the creation of a working group merely > to satisfy the accusation that the developers have been operating in > secret, especially since the base draft was made widely available for > public review and comment over 18 months ago, when work that is largely > editorial is all that's been identified as needing attention. I don't get this. Dmarc-dev is a private mailing list that only certain parties can participate in that has been the venue for review and discussion of changes to the spec up to now. Yes, there have been versions made available to the publc for comment, but then those comments have been adjudicated in secret. This is all fact. Public input to a private process is not an open approach. I tried to approach the charter as Trent Adams requested: > As a reminder, this includes the guidance provided by Russ and Barry > that we treat the base specification as being an Individual Submission > that is AD Sponsored. If I start with the assumption that this is the correct approach, then I don't think an IETF working group to write a BCP makes sense. I still think having the group do some serious work on improving the base spec makes sense (but you knew that), but comments weren't solicited on that point and so I was attempting to respond in the context that was requested. I think I'm just going to sit out further charter discussions because I don't think I'm likely to change anyone's mind at this point so I'm likely to just be (more of) a distraction. Scott K From dcrocker@gmail.com Wed Jul 24 07:18:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57011E8106 for ; Wed, 24 Jul 2013 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHi2M9dgr9Fi for ; Wed, 24 Jul 2013 07:18:55 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0711E80F7 for ; Wed, 24 Jul 2013 07:18:44 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so276674eak.32 for ; Wed, 24 Jul 2013 07:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sJ9GCRq26GUnFh1JTcWkrr7NEMMxMzcn66o+LjAfuZ8=; b=pOokRHcCMqgo0KdknxCBYCqtkGbBcFMrFdB/YdOpejYSzwLkKfiq87XOqPawjn6FrF NzVb4kNYnVJBN68Lmcg8wHEgKZ6ZQvoQN594UdUNJHjRy00DOXRWlFSuBAFjzOJtmoTT EqM49MsjxgAQv7Efg4xDsaBufMj/tNcYaR/E7ebpT3bU6/Wunwu2akKDc9VlUn2ZaSZb jt/UVqA5n3GonYy2fMKxMaYVf2ViRxHoIZ35CYPtwQpWxuAz4rfGpgi4pferxaRd4l2b muPaptZyp+M2ojuHr2Wl841wtMcM4fwLg9Xevt8qDDGg3byTMQiO2c5Tuaa6gM2iom+Q es4g== X-Received: by 10.14.246.197 with SMTP id q45mr38108036eer.15.1374675512805; Wed, 24 Jul 2013 07:18:32 -0700 (PDT) Received: from [192.168.174.45] ([192.173.4.185]) by mx.google.com with ESMTPSA id c3sm66504590eev.3.2013.07.24.07.18.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 07:18:31 -0700 (PDT) Message-ID: <51EFE231.5080004@gmail.com> Date: Wed, 24 Jul 2013 15:18:25 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> In-Reply-To: <1776975.bIMgeWNKBr@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, "dmarc-discuss@dmarc.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:18:56 -0000 On 7/24/2013 2:07 PM, Scott Kitterman wrote: > On Tuesday, July 23, 2013 10:57:42 PM Murray S. Kucherawy wrote: ... > I've already said I don't think that the proposed approach is > adequate and (believe it or not) I am trying to minimize how much I > repeat myself. Oh? >> Rather, the claim is that the review comments that have been posted >> to date, inclusive of your July 14th review -- which was very >> useful, by the way, in spite of the "secret group" jab -- are not >> of sufficient severity to send the whole thing back to the drawing >> board in the context of a working group, which is an expensive >> prospect for everyone involved (particularly the sponsoring AD). A >> new working group's time and energy would be better spent working >> on the engineering problems and informational material the base >> document doesn't already deliver. > > To my knowledge, there have been less than a handful of reviews (I Perhaps you did not notice the reference to /18 months/ of public access to the specifications and discussion of it? Yes, there have been few, formal IETF reviews. More are in the pipeline. And (repeating this one more time, possibly making a baker's dozen) if any of them -- or any other review -- produces a need for technical work, then that will affect how things are pursued. However -- yet one more time -- in 18 months, no one has generated community interest in modifying the bits over the wire. > didn't go back and look, so that may be wrong) and more than one of > them carried caveats that the reviews were somewhat cursory. My > conclusion is that there has been little serious review and that it's Your conclusion is wrong. But ultimately all that matters is your convincing others that there is technical work to be done and in spite of your sustained pleading, it doesn't appear (to me, at least) that you've succeeded. > premature to conclude anything from the ones that have been done > other than that the document is no where near ready for publication. Premature? 18 months? Adoption covering 60% of the world's email traffic? Are you serious? >> On the other hand, I would object to the creation of a working >> group merely to satisfy the accusation that the developers have >> been operating in secret, especially since the base draft was made >> widely available for public review and comment over 18 months ago, >> when work that is largely editorial is all that's been identified >> as needing attention. > > I don't get this. Dmarc-dev is a private mailing list that only > certain parties can participate in that has been the venue for review > and discussion of changes to the spec up to now. Oh. I see the problem. You don't understand that dmarc-discuss@dmarc.org has been public for 18 months and, of course, this IETF list has been open for months. You want the issue to be the fact that the core development group has a closed mailing list. Apparently you aren't aware that such activity is quite common. What matter is what happens /now/. IETF process is being followed. It will continue to be followed. I'm sorry you don't like it. > If I start with the assumption that this is the correct approach, > then I don't think an IETF working group to write a BCP makes sense. Why? Is it not useful work? Is there no community interest in doing it? What other process or substantive objection are you claiming justifies your position? > I still think having the group do some serious work on improving the > base spec Oh? Excellent! That means that you know of "improvements" that are needed and that have community support? Who? Where is this documented? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@gmail.com Wed Jul 24 07:28:29 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C40A11E80CC for ; Wed, 24 Jul 2013 07:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIWZTOeibAcs for ; Wed, 24 Jul 2013 07:28:29 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E0AC911E8142 for ; Wed, 24 Jul 2013 07:28:19 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so282188eak.14 for ; Wed, 24 Jul 2013 07:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sJ9GCRq26GUnFh1JTcWkrr7NEMMxMzcn66o+LjAfuZ8=; b=CLoCyVEWtnXNZWGGi6FnmWA5oX7lCTO1PcG3mH9wHVT+xrDVHCh+SkJEisHGE6Jqxq vB72S4IuGdo3E+FY8X0DVcuiCfHXarme0ReF4yv1Sb28nMElnsiXoEM0BppV/1jvfW1w o1LlCFFtpGm+xk/kSYCWn1koBGrYNFs/ZQ24/qjkIRmv3w9nw3dkVoonajm83s/J0Tmd 2d5q+9hSsEWW+Gm3t3eH5f9xgpf8FrV7V+NY/AxdRfzXxYjRg0KPls9MUkovFmWEPlMh 2jujWIjeQrUsgpFyiz9rOqXDM5Jm/JVqQXMFq+k6awS7bheYXaVJjo8Tin4oW5gEhiPd tNJw== X-Received: by 10.14.110.194 with SMTP id u42mr38091638eeg.128.1374676082338; Wed, 24 Jul 2013 07:28:02 -0700 (PDT) Received: from [192.168.174.45] ([192.173.4.185]) by mx.google.com with ESMTPSA id n42sm66501326eeh.15.2013.07.24.07.28.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 07:28:01 -0700 (PDT) Message-ID: <51EFE3CE.80108@gmail.com> Date: Wed, 24 Jul 2013 15:25:18 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Scott Kitterman References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> In-Reply-To: <1776975.bIMgeWNKBr@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:28:29 -0000 On 7/24/2013 2:07 PM, Scott Kitterman wrote: > On Tuesday, July 23, 2013 10:57:42 PM Murray S. Kucherawy wrote: ... > I've already said I don't think that the proposed approach is > adequate and (believe it or not) I am trying to minimize how much I > repeat myself. Oh? >> Rather, the claim is that the review comments that have been posted >> to date, inclusive of your July 14th review -- which was very >> useful, by the way, in spite of the "secret group" jab -- are not >> of sufficient severity to send the whole thing back to the drawing >> board in the context of a working group, which is an expensive >> prospect for everyone involved (particularly the sponsoring AD). A >> new working group's time and energy would be better spent working >> on the engineering problems and informational material the base >> document doesn't already deliver. > > To my knowledge, there have been less than a handful of reviews (I Perhaps you did not notice the reference to /18 months/ of public access to the specifications and discussion of it? Yes, there have been few, formal IETF reviews. More are in the pipeline. And (repeating this one more time, possibly making a baker's dozen) if any of them -- or any other review -- produces a need for technical work, then that will affect how things are pursued. However -- yet one more time -- in 18 months, no one has generated community interest in modifying the bits over the wire. > didn't go back and look, so that may be wrong) and more than one of > them carried caveats that the reviews were somewhat cursory. My > conclusion is that there has been little serious review and that it's Your conclusion is wrong. But ultimately all that matters is your convincing others that there is technical work to be done and in spite of your sustained pleading, it doesn't appear (to me, at least) that you've succeeded. > premature to conclude anything from the ones that have been done > other than that the document is no where near ready for publication. Premature? 18 months? Adoption covering 60% of the world's email traffic? Are you serious? >> On the other hand, I would object to the creation of a working >> group merely to satisfy the accusation that the developers have >> been operating in secret, especially since the base draft was made >> widely available for public review and comment over 18 months ago, >> when work that is largely editorial is all that's been identified >> as needing attention. > > I don't get this. Dmarc-dev is a private mailing list that only > certain parties can participate in that has been the venue for review > and discussion of changes to the spec up to now. Oh. I see the problem. You don't understand that dmarc-discuss@dmarc.org has been public for 18 months and, of course, this IETF list has been open for months. You want the issue to be the fact that the core development group has a closed mailing list. Apparently you aren't aware that such activity is quite common. What matter is what happens /now/. IETF process is being followed. It will continue to be followed. I'm sorry you don't like it. > If I start with the assumption that this is the correct approach, > then I don't think an IETF working group to write a BCP makes sense. Why? Is it not useful work? Is there no community interest in doing it? What other process or substantive objection are you claiming justifies your position? > I still think having the group do some serious work on improving the > base spec Oh? Excellent! That means that you know of "improvements" that are needed and that have community support? Who? Where is this documented? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john.kelley@teamaol.com Wed Jul 24 07:38:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C2321F9DD0 for ; Wed, 24 Jul 2013 07:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB-3K7Q5wzDm for ; Wed, 24 Jul 2013 07:38:00 -0700 (PDT) Received: from omr-d08.mx.aol.com (omr-d08.mx.aol.com [205.188.109.207]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7511E821A for ; Wed, 24 Jul 2013 07:37:47 -0700 (PDT) Received: from AOLDTCMEI34.ad.aol.aoltw.net (aoldtcmei34.office.aol.com [10.180.121.151]) by omr-d08.mx.aol.com (Outbound Mail Relay) with ESMTP id 8C50870040AB5 for ; Wed, 24 Jul 2013 10:37:05 -0400 (EDT) Received: from AOLDTCMES31.ad.aol.aoltw.net ([169.254.8.227]) by AOLDTCMEI34.ad.aol.aoltw.net ([10.180.121.151]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 10:37:05 -0400 From: "Kelley, John" To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Updated Draft Charter for Review Thread-Index: AQHOh/fvCJdo5KknlE2osdTsHpoNX5lzkIiAgACZIgA= Date: Wed, 24 Jul 2013 14:37:04 +0000 Message-ID: References: <51EF0A2D.4080702@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.8.193] Content-Type: multipart/alternative; boundary="_000_DCA8DFADA68E405E8185B9001FA72382teamaolcom_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:38:04 -0000 --_000_DCA8DFADA68E405E8185B9001FA72382teamaolcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 John Kelley On Jul 24, 2013, at 1:29 AM, Murray S. Kucherawy > wrote: On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams > wrote: As the holder of the pen on the draft charter for the proposed DMARC WG, I have taken the input from the list and incorporated it into an update: http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC As a reminder, this includes the guidance provided by Russ and Barry that we treat the base specification as being an Individual Submission that is AD Sponsored. The scope and identified items of work follow on that assumption. Please take a look at it and reply with your comments so we can address as much of them as possible prior to the meeting. Otherwise, I look forward to the conversation in Berlin next week. Recognizing that the charter is still subject to edits especially as a resu= lt of the Berlin discussion, I think this looks fine to me as a basis for t= hat discussion. I concur with Dave's nits, but I don't feel strongly about= any of them (he's jet lagged, I'm just tired). One nit of my own: You can take the version number out of the second draft = reference, since the first one doesn't name a specific version and the numb= er could change before the working group actually charters. -MSK _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --_000_DCA8DFADA68E405E8185B9001FA72382teamaolcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9EF922515229CE41B7997535DA6A243C@teamaol.com> Content-Transfer-Encoding: quoted-printable +1

John Kelley


On Jul 24, 2013, at 1:29 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams <jtr= entadams@gmail.com> wrote:
As the holder of the pen on the draft charter for the proposed DMARC WG, I have taken the input from the list and incorporated it into an update:
http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

As a reminder, this includes the guidance provided by Russ and Barry
that we treat the base specification as being an Individual Submission
that is AD Sponsored.  The scope and identified items of work follow o= n
that assumption.

Please take a look at it and reply with your comments so we can address
as much of them as possible prior to the meeting.  Otherwise, I look forward to the conversation in Berlin next week.


Recognizing that the charter is still subject to edits especially as a= result of the Berlin discussion, I think this looks fine to me as a basis = for that discussion.  I concur with Dave's nits, but I don't feel stro= ngly about any of them (he's jet lagged, I'm just tired).

One nit of my own: You can take the version number out of the second draft = reference, since the first one doesn't name a specific version and the numb= er could change before the working group actually charters.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--_000_DCA8DFADA68E405E8185B9001FA72382teamaolcom_-- From superuser@gmail.com Wed Jul 24 09:16:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BC111E80FC for ; Wed, 24 Jul 2013 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRW87r7y29AS for ; Wed, 24 Jul 2013 09:16:01 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE88311E81DB for ; Wed, 24 Jul 2013 09:16:00 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n11so644013wgh.4 for ; Wed, 24 Jul 2013 09:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GHZMhTSyc2UIMxH/7FmJ6APKsxrNI9H5K5nyBhYQKtg=; b=j0joFOhbyMuTiee20rPR5IAbD2Vs3FrLKstPwBfldUdc4WElP919ps/7Psaha7f4P3 RdXJh8cNOtKgntyv6frHvHDom80ehFWJCzxWJQY3XH01oE5qRUa1VG/lEx3rXSsFrG9V SS0QN+W+e0KrW0CwuS8fVSqrbdwsTrYI2xe4ceEuSV54GYG6ob0wIQjw+ryX8RJUWT1F yjm2wf2ckzQqJ9vUlF+oDp+j1JjK8/eKXlWDyTbBrRCqB+b2AWhqLZfbwQIBelX3hdnV CUG3xdgU++f9Dp1723nKMrEpMGm4Qh4+vk5oeUehylF73CTbeP2QSMzt3QKpXoxOiecp Lgzg== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr27559468wjc.63.1374682559993; Wed, 24 Jul 2013 09:15:59 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 24 Jul 2013 09:15:59 -0700 (PDT) In-Reply-To: <1776975.bIMgeWNKBr@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> Date: Wed, 24 Jul 2013 09:15:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e01493384aade2204e24439fb Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:16:02 -0000 --089e01493384aade2204e24439fb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 24, 2013 at 6:07 AM, Scott Kitterman wrote: > To my knowledge, there have been less than a handful of reviews (I didn't > go > back and look, so that may be wrong) and more than one of them carried > caveats > that the reviews were somewhat cursory. My conclusion is that there has > been > little serious review and that it's premature to conclude anything from the > ones that have been done other than that the document is no where near > ready > for publication. > This means I can arbitrarily delay progress or force layers of additional process on any work I like just by saying "Here's a bunch of editorial stuff I found. I didn't really read it very hard, but I bet I might find something major if I did." If we are to make process decisions based on nebulous claims of possible future feedback that may or may not contain a showstopper, our ability to be usefully productive will plunge. How long are we to wait? > On the other hand, I would object to the creation of a working group > merely > > to satisfy the accusation that the developers have been operating in > > secret, especially since the base draft was made widely available for > > public review and comment over 18 months ago, when work that is largely > > editorial is all that's been identified as needing attention. > > I don't get this. Dmarc-dev is a private mailing list that only certain > parties can participate in that has been the venue for review and > discussion > of changes to the spec up to now. Yes, there have been versions made > available to the publc for comment, but then those comments have been > adjudicated in secret. This is all fact. Public input to a private > process > is not an open approach. > Your premise is incorrect. Nothing has been done in private in the last year and a half. The dmarc-dev list has not been the primary venue for document development in that time, dmarc-discuss has, and that's been an open and public list since its inception. -MSK --089e01493384aade2204e24439fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 24, 2013 at 6:07 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
To my knowledge, there have been less than a= handful of reviews (I didn't go
back and look, so that may be wrong) and more than one of them carried cave= ats
that the reviews were somewhat cursory. =A0My conclusion is that there has = been
little serious review and that it's premature to conclude anything from= the
ones that have been done other than that the document is no where near read= y
for publication.

This means I can arbit= rarily delay progress or force layers of additional process on any work I l= ike just by saying "Here's a bunch of editorial stuff I found.=A0 = I didn't really read it very hard, but I bet I might find something maj= or if I did."=A0 If we are to make process decisions based on nebulous= claims of possible future feedback that may or may not contain a showstopp= er, our ability to be usefully productive will plunge.=A0 How long are we t= o wait?

> On the other hand, I would ob= ject to the creation of a working group merely
> to satisfy the accusation that the developers have been operating in > secret, especially since the base draft was made widely available for<= br> > public review and comment over 18 months ago, when work that is largel= y
> editorial is all that's been identified as needing attention.

I don't get this. =A0Dmarc-dev is a private mailing list that onl= y certain
parties can participate in that has been the venue for review and discussio= n
of changes to the spec up to now. =A0Yes, there have been versions made
available to the publc for comment, but then those comments have been
adjudicated in secret. =A0This is all fact. =A0Public input to a private pr= ocess
is not an open approach.

Your premise i= s incorrect.=A0 Nothing has been done in private in the last year and a hal= f.=A0 The dmarc-dev list has not been the primary venue for document develo= pment in that time, dmarc-discuss has, and that's been an open and publ= ic list since its inception.

-MSK
--089e01493384aade2204e24439fb-- From jtrentadams@gmail.com Wed Jul 24 09:19:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0429811E80D3 for ; Wed, 24 Jul 2013 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7ylSNtAp31o for ; Wed, 24 Jul 2013 09:19:32 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id CDEB811E80EA for ; Wed, 24 Jul 2013 09:19:31 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so984058obc.27 for ; Wed, 24 Jul 2013 09:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=z7QruSFvAyBl51SJIeuNBoCKq+7Y8oGgBEJ4wfXuDqk=; b=RAdKPC8bmjvOsbjKf9QMZ6QefhbIIqKBamzBmBwgRzFVKfriLMHV/rqSVS7hDOg+YJ wdstQo2f+yC868Jem8w/FXUKT5P49WNXH+X1xI8Jg9tcHHmTwO2sUKtJsxNLh9vXk2HA BJtzkLxSk4+RjIMmzKkufNbNI9KtebLVqnPwJGi72NtQu0GyWoo/FadcjXipazqz3Wrh RcIdUEPdlN/zcwyJRWJyeRQtqMG9TgVmaKOvcms++Pc8zG9En6sw0p8XNrFSnK/aGSFx tKXNd+7QxGHhEK5PR98VijeEeF+LdDvlSYBonPuqIQUP5MzTJUtv1PM8S6k6wyLVpICu Aw7g== X-Received: by 10.182.241.101 with SMTP id wh5mr32124561obc.49.1374682771382; Wed, 24 Jul 2013 09:19:31 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id z10sm50183721obl.13.2013.07.24.09.19.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:19:30 -0700 (PDT) Message-ID: <51EFFE91.8040809@gmail.com> Date: Wed, 24 Jul 2013 10:19:29 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmarc@ietf.org References: <51EF0A2D.4080702@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:19:33 -0000 Tim - On 7/23/13 6:02 PM, Tim Draegen wrote: > On Jul 23, 2013, at 6:56 PM, J. Trent Adams > wrote: >> >> As the holder of the pen on the draft charter for the proposed DMARC WG, >> I have taken the input from the list and incorporated it into an update: >> >> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > Hey Trent, thanks for doing this. I support this effort, admit to not > being an expert of IETF process, and have a slew of largely editorial > nits: > > /DMARC allows a sender to indicate that its legitimate emails are > protected by SPF and/or DKIM, matching the validated sending domains > with the sender's email address *domain* in the RFC5322:From > field (aka "identifier alignment"), and advises a receiver what it > should do if neither of those authentication methods *yields a > relevant authenticated identifier* passes, or the identifiers fail > to align, for a received message. It also provides a reporting > mechanism, from receivers back to domain owners./ > Done. > This sentence no longer feels accurate: > > /Such capabilities over the public Internet are unusual and their use > is *still being explored* not yet well-understood./ > / > / Done. > This one is hard for me to parse: > / > / > /The working group will explore possible extensions to the base, to > address limitations of the mechanism in particular scenarios or for > added capabilities, and provide technical implementation guidance./ > / > / > How about: > > /The working group will explore possible extensions to the base, to > address context-specific limitations of the mechanism, to consider > added capabilities, and to provide technical implementation guidance./ > / > / Done. > Typo: > > /The guid*(e)* will catalog../ > / > / Done. > / > / > OK! For actual content: > > /The initial charter for this working group does not include revising > the base specification,../ > / > / > I wish there was a way to allow changes to the base specification > aside from "bits over the wire" changes (with a heavy nod towards > maintaining interoperability), so that readability and clarity can be > tackled. Given Murray's response to Scott on a similar point, I think that most (all?) of the copy-edit and clarification edits can be made during the last call. But perhaps someone will offer a creative solution that folks can get behind. Thanks, Trent > > Thanks again for putting this together, > =- Tim > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From jtrentadams@gmail.com Wed Jul 24 09:31:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86FE11E812D for ; Wed, 24 Jul 2013 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlUoqdQxAnLh for ; Wed, 24 Jul 2013 09:31:02 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1D11E80FE for ; Wed, 24 Jul 2013 09:31:02 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so1497644oag.23 for ; Wed, 24 Jul 2013 09:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=NWfriB+Ab5P59IEFZM0ggqF1TuBN9vzxmd5l3sL2bcA=; b=07YWIz2V+cMS+YN4XJYlTn1QwydxEN9S73hhqco5Bj6cQqkQT/BS9eP8l+zzF7lzCK 7gBOw/RiOF6VSr65sLdXqoPm2QJsPdJOy3SjKaUxQDI3ucnx9NP/PPUf7LkClIh5YO8c 1vbxq0oL0GdwGKrUkAiNZxwnHKk2luuC59CvJOTBWzskDBLQPLdhf+epv6B46K1uDVzF a3GmqmjZOehjbWnyROv2+Pzkg63rxsAErr9qtbtJschcACfDBNBAKQhD9YyUVtkjgVF1 uAR5AVQ8HRDG8A/LyM/lM6GIiPrFH3QJ5sLBPF6yt6qqz/Y085/gdX8YbAA5nZIE+P+i VIQA== X-Received: by 10.50.1.78 with SMTP id 14mr508529igk.60.1374683462046; Wed, 24 Jul 2013 09:31:02 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id t10sm1068505igz.9.2013.07.24.09.31.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:31:01 -0700 (PDT) Message-ID: <51F00144.70401@gmail.com> Date: Wed, 24 Jul 2013 10:31:00 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Crocker References: <51EF0A2D.4080702@gmail.com> <51EF56DA.9040807@gmail.com> In-Reply-To: <51EF56DA.9040807@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:31:04 -0000 Dave - On 7/23/13 10:23 PM, Dave Crocker wrote: > On 7/23/2013 11:56 PM, J. Trent Adams wrote: >> >> As the holder of the pen on the draft charter for the proposed DMARC WG, >> I have taken the input from the list and incorporated it into an update: >> >> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > > I think the paragraph that bothered some as too 'marketing' oriented > has been productively transformed into a pedantic, academic style. > Much more credible. Good job. > Wow, I think that's the first time I've been complimented for being a pedantic academic since I turned in my thesis on galactic photometry. Usually I have to hide that part of my personality. Thanks! > > By way of demonstrating that the text must be asymptoting nicely, > herewith my nitpicks... > > > > well-known company (aka, "brand") > -> > well-known company (also called "brand") > > { aka is an extreme colloquialism; besides being too informal for > something this official, this sort of text is purported to be a > special challenge for those who do not suffer English as their native > language. fwiw, eg and ie also fall into this category, I'm told. } Done > > trust-based layer -> trust-oriented layer > > { besides suspecting the latter is more accurate, it bugs me to see > 'based' used twice in close proximity... } > Done > > > matching the validated sending domains > -> > matching the validated domains > > { as an example, rfc5321.mailfrom is a return address and might have > had nothing to do with sending. what? you thought I was kidding > about nit-picking? } > Done > > > field (aka "identifier alignment") -> ... > Done > > > Individual Submission (a.k.a. "Area Director Sponsored") for > publication > -> > Individual Submission for publication, which is sponsored by an > Area Director. > Done > > > and provide -> and will provide > > { parallel construction } > Done > > > practice or bits over the wire > -> > practice, in particular the bits over the wire, > Done > > > need to be added as extensions, rather > -> > need to be additions, rather > Done > > > This permits unmodified -> This will permit unmodified > Done > > > Oops. Not a nit-pick: > > a mechanism for ensuring the RFC5322.From field can be relied upon > as the primary means of DMARC identifier alignment > > I can parse the language, but have no idea what this means, in spite > of knowing the gist of what's intended. This is obscure/confusing > enough, I can't even suggest a fix. > Yeah, this was a tough one. There was mixed interest in what to do about RFC5322.From fields that contain multiple domains. A few folks indicated they wanted to see how to deal with that issue, while others wanted to stay clear of taking on "display-name" abuse. I have a feeling that this would be a fantastic topic to explore in the BoF. Perhaps folks will come up with a creative way to thread the needle here. > > > > failures of DMARC policy -> failures of the DMARC mechanism > > { in the abstract, yeah, it's probably a policy failure; but let's > keep it mundane; the procedure doesn't work in this scenario. } Done > > > determine the organizational domain responsible for sending mail. > -> {add} > An Organizational Domain is the basic domain domain name obtained > through a public registry, such as example.com or example.co.uk. > > { The term Organizational Domain is not in common use, so it should be > explained. Done > Also the text explaining the term at dmarc.org/overview.html really > isn't correct, as demonstrated by the .co.uk example. } > Thanks, I'll pass that along to the editor of content on the DMARC.org site. > > > leverage the public suffix list > -> > use an information "public suffix" list Done > > > > solution will not scale > -> > solution will not scale, and that the current list often is > inaccurate Done > > > > This working group recognizes work on a solution to be out of scope, > however, depending on work in other groups, it would be in scope to > explore extending the base specification to accommodate that work. > -> > The task of defining a standard mechanism for identifying > organizational domain is out of scope for this working group. > However the working group can consider extending the base DMARC > specification to accommodate such a standard, should it be developed > during the life of this working group. Done > > > > The guid will -> The guide will Done > > > > Defining a useful, common set of RUA reporting options > -> > Defining a useful, common set of reporting options for the addresses > to which aggregate feedback is to be sent (RUA) Done > > > > For reference, draft-crocker-dmarc-bcp-02 is a proposed draft of the > guide for input to this working group. > -> > draft-crocker-dmarc-bcp-02 will serve as the starting point for the > implementation and deployment guide. Done > > > > Jet lag sucks. If you're able to offer up this level of useful specificity while jet-lagged, maybe you should fly around more! Thanks again, Trent > > d/ -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From jtrentadams@gmail.com Wed Jul 24 09:32:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25111E812D for ; Wed, 24 Jul 2013 09:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 F2HzHAZ-eYAx for ; Wed, 24 Jul 2013 09:31:59 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C95F911E80D3 for ; Wed, 24 Jul 2013 09:31:59 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so1500586oag.23 for ; Wed, 24 Jul 2013 09:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=RL0TdqJEU4SYW2QTiD79BPTBmHhi1nax6zvXC7p2b2s=; b=kTrQA15PX+II1k62+y42XSI4VbnjfELqcDGnVlD9Rjsz+WO1WyaOR8gTibWYy2syFh eCQ7gDhHri8zsAldY6FxsYPfUIGcS+mqSeZvxg06RGG1ubnpwp4WvUpGRxGHaS//TF5w 9pXO8DgXoHQDXGjv8l94v0SVIqMNVuvx23EVys0r9lddD41SMz7mrK2au4MIG60X3Gwl FBAmAtiXNqm9tewBjQyEOFHWdFyRBZ29x6bwQJg1vx4AqdzsEI+0IMXmvhfiiVucQtAj 8B41Zuuf2Q54bMOKk9U1y+9dzepWfSSxbTMk7zg7h08mtX/j0SB4fkbnfziILMXdGPQx PCRw== X-Received: by 10.60.123.112 with SMTP id lz16mr37808592oeb.88.1374683519445; Wed, 24 Jul 2013 09:31:59 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id r4sm50933570oem.3.2013.07.24.09.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 09:31:59 -0700 (PDT) Message-ID: <51F0017E.2050309@gmail.com> Date: Wed, 24 Jul 2013 10:31:58 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <51EF0A2D.4080702@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:32:00 -0000 Murray - On 7/23/13 11:29 PM, Murray S. Kucherawy wrote: > On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams > wrote: > > As the holder of the pen on the draft charter for the proposed > DMARC WG, > I have taken the input from the list and incorporated it into an > update: > > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > > As a reminder, this includes the guidance provided by Russ and Barry > that we treat the base specification as being an Individual Submission > that is AD Sponsored. The scope and identified items of work > follow on > that assumption. > > Please take a look at it and reply with your comments so we can > address > as much of them as possible prior to the meeting. Otherwise, I look > forward to the conversation in Berlin next week. > > > Recognizing that the charter is still subject to edits especially as a > result of the Berlin discussion, I think this looks fine to me as a > basis for that discussion. I concur with Dave's nits, but I don't > feel strongly about any of them (he's jet lagged, I'm just tired). > > One nit of my own: You can take the version number out of the second > draft reference, since the first one doesn't name a specific version > and the number could change before the working group actually charters. Done. Thanks, Trent > > -MSK -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From mjones@agari.com Wed Jul 24 10:17:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176611E80F6 for ; Wed, 24 Jul 2013 10:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpgKQRS8oiFo for ; Wed, 24 Jul 2013 10:17:33 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56C11E80F9 for ; Wed, 24 Jul 2013 10:17:32 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so625233pdd.34 for ; Wed, 24 Jul 2013 10:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer; bh=kShglH5IobW3MEyxC/QP5EPCyx+FPmZkgRlEhBtgaew=; b=VRWhQRwTGh8ZyQqaHdsMry3e2mT2Ux5uGJHIRfVCZGEK/gPg0X1OYo2BAo//DnrNJW uFfYYD1YhQ+HnpHuAP51vYROHrdj77rgs1g5BLhW17VNwRSMuMI6JprfYTKbFHMtBgYv 9+A7akc5XqtBTbeY+scCmiAdM3DatZDwj/Dhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer:x-gm-message-state; bh=kShglH5IobW3MEyxC/QP5EPCyx+FPmZkgRlEhBtgaew=; b=atj1Qr7tnka8h7pdBpqrLaVDdOnMZVBROVpE+Zum6hWkYyFUpXVZ9C0dtAZlyG0ls+ tVENV9uDk34ddM3rkm5BwGsK3MFg/X/UR5uhSVHoTfjcDQpFkwjplgeshVEecoLAqvCX VKhil66ZjAdVx1OO3kO9E7uskXXOX8qxH1i7rIB+sg4pDPkk8mTp2CHjM/puVHc5tRUt ZtVt38fye3TNkJEllgfn8wfYsAQ+0bWyhkxtD3UCaQYWDMVqroHyHuH2dO6OkmQS9aRr ECVnw+ZG0GyQSrPfS22tHqvPfRPpOvmzPopCUscHV2YcEF9oQsTYn147BdXeAbshqh5D Bf3w== X-Received: by 10.68.189.202 with SMTP id gk10mr42845481pbc.47.1374686252322; Wed, 24 Jul 2013 10:17:32 -0700 (PDT) Received: from [192.168.0.14] (c-24-4-3-179.hsd1.ca.comcast.net. [24.4.3.179]) by mx.google.com with ESMTPSA id pq1sm48983329pbb.26.2013.07.24.10.17.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:17:31 -0700 (PDT) From: Mike Jones Content-Type: multipart/alternative; boundary="Apple-Mail=_78D8C2F6-0438-433E-9CFF-D1F2B7E544D6" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Wed, 24 Jul 2013 10:17:29 -0700 References: <51EF0A2D.4080702@gmail.com> To: "J. Trent Adams" , "dmarc@ietf.org" In-Reply-To: <51EF0A2D.4080702@gmail.com> X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnE8GosnF8wDXpNPWJOrQnN1MBhmK6FGzSRLCeti6VTcnI+alU+W/cDwnWeSGNyKt53dlJD Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:17:35 -0000 --Apple-Mail=_78D8C2F6-0438-433E-9CFF-D1F2B7E544D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Trent,=20 Having just read through the comments in this thread and the updated = draft charter, I agree with Murray and support this version as a = starting point for the Berlin discussion. Sorry I won't be able to take = part in that discussion in Berlin! Thanks, Mike Mike Jones Agari mjones@agari.com Skype: jnzmike1 703-728-3978 (cell) On Jul 23, 2013, at 3:56 PM, J. Trent Adams = wrote: >=20 > As the holder of the pen on the draft charter for the proposed DMARC = WG, > I have taken the input from the list and incorporated it into an = update: >=20 > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC >=20 > As a reminder, this includes the guidance provided by Russ and Barry > that we treat the base specification as being an Individual Submission > that is AD Sponsored. The scope and identified items of work follow = on > that assumption. >=20 > Please take a look at it and reply with your comments so we can = address > as much of them as possible prior to the meeting. Otherwise, I look > forward to the conversation in Berlin next week. >=20 > Thanks, > Trent >=20 > --=20 > J. Trent Adams >=20 > Profile: http://www.mediaslate.org/jtrentadams/ > LinkedIN: http://www.linkedin.com/in/jtrentadams > Twitter: http://twitter.com/jtrentadams >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_78D8C2F6-0438-433E-9CFF-D1F2B7E544D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Mike Jones
Agari
mjones@agari.com
Skype: = jnzmike1
703-728-3978 = (cell)

On Jul 23, 2013, at 3:56 PM, J. Trent Adams <jtrentadams@gmail.com> = wrote:


As the holder of the pen on the draft charter for the = proposed DMARC WG,
I have taken the input from the list and = incorporated it into an update:

http://wiki= .tools.ietf.org/wg/appsawg/trac/wiki/DMARC

As a reminder, = this includes the guidance provided by Russ and Barry
that we treat = the base specification as being an Individual Submission
that is AD = Sponsored.  The scope and identified items of work follow = on
that assumption.

Please take a look at it and reply with = your comments so we can address
as much of them as possible prior to = the meeting.  Otherwise, I look
forward to the conversation in = Berlin next week.

Thanks,
Trent

--
J. Trent = Adams

Profile: = http://www.mediaslate.org/jtrentadams/
LinkedIN: = http://www.linkedin.com/in/jtrentadams
Twitter: = http://twitter.com/jtrentadams

____________________________________= ___________
dmarc mailing = list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
<= /blockquote>

= --Apple-Mail=_78D8C2F6-0438-433E-9CFF-D1F2B7E544D6-- From dcrocker@gmail.com Wed Jul 24 10:28:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4911E819E for ; Wed, 24 Jul 2013 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BGSGbEvDa37 for ; Wed, 24 Jul 2013 10:28:58 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6472211E8151 for ; Wed, 24 Jul 2013 10:28:58 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so5426281wiw.4 for ; Wed, 24 Jul 2013 10:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WpPz0toTg/qBUeocIhCfe4NaBcrGm416nvUvSillXNo=; b=ykvFX7w8zYDa5sgFLeHGU0JfCg+as5X/hzlKDs7xW8DFl1DumdbIcbVeWjO8x+h1bJ brfj+dsgNkAdhCfRnvMx8/TSBoYg76rZHMNDEjwDTB2VoZlNDQL8wWFFv74afFf6yuR3 e8LlV5UIsLQplTlPkawjj0yOUiUGB8z/fq+qj5XzjQwJau2jAHd9DT1lSQx226ZK7xSx bq+40SAmwkJNWL69ah7wCPDdHiajn59o6+fyEDXKH3ZN3KuHzWAWn2sP6KrVllX12d2J oNO+yZk8u60729i2TcLX8KBeLwBQvIyfin9rA348VD9UbFugOWMwvhh8V9qRQcDcK+ms /MAw== X-Received: by 10.180.10.135 with SMTP id i7mr3419775wib.38.1374686937565; Wed, 24 Jul 2013 10:28:57 -0700 (PDT) Received: from [10.0.0.207] (host217-40-191-246.in-addr.btopenworld.com. [217.40.191.246]) by mx.google.com with ESMTPSA id s19sm6767627wik.11.2013.07.24.10.28.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:28:56 -0700 (PDT) Message-ID: <51F00ED3.6040309@gmail.com> Date: Wed, 24 Jul 2013 18:28:51 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "J. Trent Adams" References: <51EF0A2D.4080702@gmail.com> <51EF56DA.9040807@gmail.com> <51F00144.70401@gmail.com> In-Reply-To: <51F00144.70401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:28:59 -0000 On 7/24/2013 5:31 PM, J. Trent Adams wrote: >> >Oops. Not a nit-pick: >> > >> > a mechanism for ensuring the RFC5322.From field can be relied upon >> > as the primary means of DMARC identifier alignment >> > >> >I can parse the language, but have no idea what this means, in spite >> >of knowing the gist of what's intended. This is obscure/confusing >> >enough, I can't even suggest a fix. >> > > Yeah, this was a tough one. There was mixed interest in what to do > about RFC5322.From fields that contain multiple domains. A few folks > indicated they wanted to see how to deal with that issue, while others > wanted to stay clear of taking on "display-name" abuse. 1. I don't recall the details of these exchanges. Can you provide some mailing list pointers? 2. If this is about multiple From: fields, those are illegal. The message fails before it gets to dmarc. 3. If this concerns the fact that the From: field may legally contain multiple addresses, then what's wrong with the existing text: 11.1 A message bearing multiple RFC5322.From identifiers is ambiguous under DMARC. This includes messages with multiple RFC5322.From fields (which is also forbidden under [MAIL]) and a message with a single RFC5322.From field containing multiple entities. There can also be From: fields that contain no meaningful values, such as RFC5322's "group" syntax. Such messages SHOULD be rejected. If it is something else, I've no guess. > I have a feeling that this would be a fantastic topic to explore in the > BoF. Perhaps folks will come up with a creative way to thread the > needle here. mumble. >> >Jet lag sucks. > If you're able to offer up this level of useful specificity while > jet-lagged, maybe you should fly around more! Hmmm. I thought the consensus view was that I did, even when staying home. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jtrentadams@gmail.com Wed Jul 24 10:42:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2672A21F9D56 for ; Wed, 24 Jul 2013 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osrgTv5-gw26 for ; Wed, 24 Jul 2013 10:42:32 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 572DE21F9A51 for ; Wed, 24 Jul 2013 10:42:32 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so1717577oag.18 for ; Wed, 24 Jul 2013 10:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=CHY28Pf6esexcfTw1i+o/ClUxifCTRZ2NmOZzoc/FwA=; b=u7LCph/mXv4lmVhHU01PMgvQr1Y7VatePfyDoICWIy/f1RJEZquEF9AAzXj0PGS8Aq kZKQ1UxsKasxnKHiYqm8CWTMO4juENCEraFpy12gUE26JpAK1kWaLS+FSkPQbacl2Ovc 8QgiBGMQcUhDKakljymEpXBPUDAl5AcCvidsPDUvDj3rdPBUcgyq3XAIsJNtqK5ytQyv /mlag/tXVjQsfXpDAxbO1k4EkpwLZwyDcI4T3bGoiRM3pxMKp/Xm0KSswtnBW2dk2D/H 9vwAuT5tNhq2YxElO1gLnCZRafmcnDIO7OQ8vR2Kx3p7n8W+U8h34v0f1yVURSw/2Kx0 1e2w== X-Received: by 10.182.65.1 with SMTP id t1mr32242546obs.5.1374687751767; Wed, 24 Jul 2013 10:42:31 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id i9sm51377881oem.7.2013.07.24.10.42.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:42:31 -0700 (PDT) Message-ID: <51F01206.6010908@gmail.com> Date: Wed, 24 Jul 2013 11:42:30 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Crocker References: <51EF0A2D.4080702@gmail.com> <51EF56DA.9040807@gmail.com> <51F00144.70401@gmail.com> <51F00ED3.6040309@gmail.com> In-Reply-To: <51F00ED3.6040309@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:42:33 -0000 On 7/24/13 11:28 AM, Dave Crocker wrote: > On 7/24/2013 5:31 PM, J. Trent Adams wrote: >>> >Oops. Not a nit-pick: >>> > >>> > a mechanism for ensuring the RFC5322.From field can be relied >>> upon >>> > as the primary means of DMARC identifier alignment >>> > >>> >I can parse the language, but have no idea what this means, in spite >>> >of knowing the gist of what's intended. This is obscure/confusing >>> >enough, I can't even suggest a fix. >>> > >> Yeah, this was a tough one. There was mixed interest in what to do >> about RFC5322.From fields that contain multiple domains. A few folks >> indicated they wanted to see how to deal with that issue, while others >> wanted to stay clear of taking on "display-name" abuse. > > 1. I don't recall the details of these exchanges. Can you provide > some mailing list pointers? I'll dig up what I can find. > > 2. If this is about multiple From: fields, those are illegal. The > message fails before it gets to dmarc. Right, I don't thinks that was the issue. > > 3. If this concerns the fact that the From: field may legally contain > multiple addresses, then what's wrong with the existing text: > > 11.1 > > A message bearing multiple RFC5322.From identifiers is ambiguous > under DMARC. This includes messages with multiple RFC5322.From > fields (which is also forbidden under [MAIL]) and a message with a > single RFC5322.From field containing multiple entities. There can > also be From: fields that contain no meaningful values, such as > RFC5322's "group" syntax. Such messages SHOULD be rejected. > > If it is something else, I've no guess. If I recall, the trick is to try and figure out if there's a way to address common issues (even if just to call them out in the proposed "Using DMARC" guide) without getting sucked into the morass of all the display name abuse issues. In the end, of course, it's possible that there's no way to safely negotiate those weeds and we just have to avoid them entirely. - Trent > > >> I have a feeling that this would be a fantastic topic to explore in the >> BoF. Perhaps folks will come up with a creative way to thread the >> needle here. > > mumble. > > >>> >Jet lag sucks. >> If you're able to offer up this level of useful specificity while >> jet-lagged, maybe you should fly around more! > > Hmmm. I thought the consensus view was that I did, even when staying > home. > > > d/ > -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From dcrocker@gmail.com Wed Jul 24 10:47:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD111E80EA for ; Wed, 24 Jul 2013 10:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fodF-Zco6-NN for ; Wed, 24 Jul 2013 10:47:48 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id E620911E80F8 for ; Wed, 24 Jul 2013 10:47:47 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so3898588wes.38 for ; Wed, 24 Jul 2013 10:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5blaotu+YWpliFHKCN4f83a0NdTxK7MI7FeguVDi3mI=; b=qpscXh0mj4uGutStKVAts9xUdhhS2m+ygdU/3N2D116nA1G+/8q0lE5gycXDTRI2wT dYNnBX5fMrUJBxZPMVFt28iEZrqt+I/DMUb+McyO96pgzPBUmXPhKXJRz5MNSFg+dLzr G0FpmrAsEZhPu9XJ5hz7YtW76p8i10mY+KLoIQRc5t2Xf6xia5uMjuX1OUm+FQQeVEnO eBQfl55A0A8YsiewetzNPahC2Ze6ygHiZWNnCD/h4teR22dmx+im1a6jPXp3HX2VJG5q 0TeUsu8T195DaQF6zI31J0hPSDjMngbg8GlJ24mHotvSGhZL3vJd7SlbcG5v6ut2CJQ3 0Onw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5blaotu+YWpliFHKCN4f83a0NdTxK7MI7FeguVDi3mI=; b=WVdCdSLwDIfXD99tdvJNLM5UEdSmzvirE2xtredKe5j54xIgIh7MvU8ZGITDDYDU7v AhfvtlAXMkARtk3S5TxW164Yh/16f4uUlnXlxejJW/9Gs6qoRnSE9fK0LZ2xMkH+79JI O/EsFiXyr1eeOCdFS4d2NcbtjMVe20+usT4JZxb5e8MeADTFxWL3Onyst5AOG3D1Cz72 cMGyalF1vnSKA9FecHfGbD8uWjq1vScHb1X/sMv4gm8GNtgXCz1GsT4dkuQNTLkYz9jH fCgbMPtBHo4UvQVtd/ufqjIJ7P4lkMyGdOU6XhHqWEQwGlH9pQqF+ZTUnX5SJhfFffs5 7yDw== X-Received: by 10.180.81.169 with SMTP id b9mr3485367wiy.40.1374688066008; Wed, 24 Jul 2013 10:47:46 -0700 (PDT) Received: from [10.0.0.207] (host217-40-191-246.in-addr.btopenworld.com. [217.40.191.246]) by mx.google.com with ESMTPSA id b20sm6904448wiw.4.2013.07.24.10.47.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 10:47:44 -0700 (PDT) Message-ID: <51F01335.30007@gmail.com> Date: Wed, 24 Jul 2013 18:47:33 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mike Jones References: <51EF0A2D.4080702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:47:49 -0000 On 7/24/2013 6:17 PM, Mike Jones wrote: > > Having just read through the comments in this thread and the updated > draft charter, I agree with Murray and support this version as a > starting point for the Berlin discussion. Sorry I won't be able to take > part in that discussion in Berlin! surely you can remotely attend? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Greg.Colburn@returnpath.com Wed Jul 24 14:39:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE63911E80F5 for ; Wed, 24 Jul 2013 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj9PKpoZE+6v for ; Wed, 24 Jul 2013 14:39:02 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id 9BB1711E810C for ; Wed, 24 Jul 2013 14:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to :cc:subject:in-reply-to:content-type:content-transfer-encoding :mime-version; s=smtpapi; bh=yuYmzJ6ZQ0AaidfBmnOe7GVRT+8=; b=usP JAMiA+hWyX9L7xYYRe9iiCEiHN0EyjEB/jnUBhsV0TU9prsscVOm945q4RR3DWS+ jReBHvMZzJQv4biW+tEsCyKPhjr7nveb+B0ZPMCM+UEiDl/y8RKzN5B8qgBolC49 pXksMq4lzYgbJBxA4E3dT7+n9S1RLdKzKpzRllGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:cc :subject:in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=smtpapi; b=bCpwGHak+lKZc77kVVCCdQrlsiETK ocXRpAhQ6oLAXx7OaYBbg5bZ7qx0lZx6Y9C1Ff6FUo2tsp9Im3s7aEM1xd7DLvnb j+Hk1sqgOCX2evzJ0+b1WV3IDw28+vofEuFGhJ81uJC2gGGNzZ06KAq6fi/dpzHP q5yj31TwpffrOU= Received: by 10.4.35.196 with SMTP id mf82.32336.51F049756 Wed, 24 Jul 2013 21:39:01 +0000 (GMT) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by mi17 (SG) with ESMTP id 140129ef2e0.12eb.7b77a5 Wed, 24 Jul 2013 21:39:01 +0000 (UTC) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Wed, 24 Jul 2013 15:39:01 -0600 From: Greg Colburn To: "J. Trent Adams" , "Murray S. Kucherawy" Date: Wed, 24 Jul 2013 15:38:58 -0600 Thread-Topic: [dmarc-ietf] Updated Draft Charter for Review Thread-Index: Ac6ItjYAghpec02sQtuJQp0nR9wXOA== Message-ID: In-Reply-To: <51F0017E.2050309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5Ife6Ew2SsMuk3GFbE8dmIezTJSM2b7SP356ZgogwtcST7J0o8uAwI61ZvXfFz406PSd0bh7CI48Gp9O6meIbOu DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to :cc:subject:in-reply-to:content-type:content-transfer-encoding :mime-version; s=smtpapi; bh=yuYmzJ6ZQ0AaidfBmnOe7GVRT+8=; b=usP JAMiA+hWyX9L7xYYRe9iiCEiHN0EyjEB/jnUBhsV0TU9prsscVOm945q4RR3DWS+ jReBHvMZzJQv4biW+tEsCyKPhjr7nveb+B0ZPMCM+UEiDl/y8RKzN5B8qgBolC49 pXksMq4lzYgbJBxA4E3dT7+n9S1RLdKzKpzRllGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:cc :subject:in-reply-to:content-type:content-transfer-encoding :mime-version; q=dns; s=smtpapi; b=bCpwGHak+lKZc77kVVCCdQrlsiETK ocXRpAhQ6oLAXx7OaYBbg5bZ7qx0lZx6Y9C1Ff6FUo2tsp9Im3s7aEM1xd7DLvnb j+Hk1sqgOCX2evzJ0+b1WV3IDw28+vofEuFGhJ81uJC2gGGNzZ06KAq6fi/dpzHP q5yj31TwpffrOU= Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:39:06 -0000 +1 on David's comments and Trent's rework. My only nit is in the following line at the end of the first paragraph: "Such capabilities over the public Internet are unusual and their use is still being explored." "Unusual" feels awkward to me. How about: "Such reporting capabilities over the public Internet are new and their use is still being explored." Greg Colburn On 7/24/13 10:31 AM, "J. Trent Adams" wrote: > >Murray - > >On 7/23/13 11:29 PM, Murray S. Kucherawy wrote: >> On Tue, Jul 23, 2013 at 3:56 PM, J. Trent Adams > > wrote: >> >> As the holder of the pen on the draft charter for the proposed >> DMARC WG, >> I have taken the input from the list and incorporated it into an >> update: >> >> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC >> >> As a reminder, this includes the guidance provided by Russ and Barry >> that we treat the base specification as being an Individual >>Submission >> that is AD Sponsored. The scope and identified items of work >> follow on >> that assumption. >> >> Please take a look at it and reply with your comments so we can >> address >> as much of them as possible prior to the meeting. Otherwise, I look >> forward to the conversation in Berlin next week. >> >> >> Recognizing that the charter is still subject to edits especially as a >> result of the Berlin discussion, I think this looks fine to me as a >> basis for that discussion. I concur with Dave's nits, but I don't >> feel strongly about any of them (he's jet lagged, I'm just tired). >> >> One nit of my own: You can take the version number out of the second >> draft reference, since the first one doesn't name a specific version >> and the number could change before the working group actually charters. > >Done. > >Thanks, >Trent > >> >> -MSK > >--=20 >J. Trent Adams > >Profile: http://www.mediaslate.org/jtrentadams/ >LinkedIN: http://www.linkedin.com/in/jtrentadams >Twitter: http://twitter.com/jtrentadams > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From franck@peachymango.org Wed Jul 24 16:48:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667DF21F99F2 for ; Wed, 24 Jul 2013 16:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5hm3zoPdpry for ; Wed, 24 Jul 2013 16:48:00 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28E21F99C3 for ; Wed, 24 Jul 2013 16:48:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D036F3901B6; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhHDWbTcYInu; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AEC023901BC; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 976AB3901B9; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WMlSwNiMosU3; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 7CADC3901B6; Wed, 24 Jul 2013 18:47:57 -0500 (CDT) Date: Wed, 24 Jul 2013 18:47:56 -0500 (CDT) From: Franck Martin To: dmarc@ietf.org Message-ID: <1179746800.131025.1374709676105.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: [dmarc-ietf] Updated Draft Charter for Review Thread-Index: Ac6ItjYAghpec02sQtuJQp0nR9wXOMN3D3Iv Cc: "J. Trent Adams" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 23:48:06 -0000 I like the "a mechanism for ensuring the RFC5322.From field can be relied upon as the primary means of DMARC identifier alignment, potentially mitigating common types of abuse." I would add "and other type of abuse". This would fit in what I requested while limiting the scope so it does not become an endless anti-spam document as people mentioned. From dcrocker@gmail.com Thu Jul 25 05:42:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4BB21F9A5F for ; Thu, 25 Jul 2013 05:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf3dq+3nQqyT for ; Thu, 25 Jul 2013 05:42:04 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC321F94FD for ; Thu, 25 Jul 2013 05:42:04 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id h15so922794eak.28 for ; Thu, 25 Jul 2013 05:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M4oIxHXTeJPE+LFsgyrWbBh4JtE/PwbDEr+e4Q7ROv0=; b=L8aD5BF6HRSeDOKqaV1mBM53sOSKNMz/2sISYCPz7lXNESogmZdiBVDvSWKtC0Ny8e m84II+/OM3rk101PmLAQ5fNU8OqRBfpl8BxZLIHgaJusitODtPa4ERjLi2RJLxiTz0MG iwbRTXkPb+mXQps4ys2+aIRPBo4f9hf+rNKBrvSxSr7jvZfCU5G0k1BETSb3dj2nz8qT y/GT31lQQbOiJrwSXCiucbg0Zy46IqCSJCfVu0eHvVo9VRI3HwiSwAu4poi9BfU07Z1Z zvrxZwHpQqazYi/hQY2RaNYB1PSwZrmdJ4ILb40mFSq8J6IWe7KRCwp78AI+qBnUwI0p 49kA== X-Received: by 10.15.42.129 with SMTP id u1mr42472443eev.116.1374756123374; Thu, 25 Jul 2013 05:42:03 -0700 (PDT) Received: from [192.168.174.86] ([192.173.4.185]) by mx.google.com with ESMTPSA id w43sm73444950eez.6.2013.07.25.05.42.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 05:42:02 -0700 (PDT) Message-ID: <51F11D19.6040303@gmail.com> Date: Thu, 25 Jul 2013 13:42:01 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Greg Colburn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 12:42:05 -0000 On 7/24/2013 10:38 PM, Greg Colburn wrote: > +1 on David's comments and Trent's rework. My only nit is in the > following line at the end of the first paragraph: > > "Such capabilities over the public Internet are unusual and their use is > still being explored." > > > "Unusual" feels awkward to me. How about: > > "Such reporting capabilities over the public Internet are new and their > use is still being explored." That bit of wording was my own crafting and I agree it's awkward; I thought that when writing it. The problem is that I'm not sure the underlying mechanisms are "new", which moved the point to statistics rather than innovation... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Thu Jul 25 08:34:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5AD21F968B for ; Thu, 25 Jul 2013 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.963 X-Spam-Level: X-Spam-Status: No, score=-101.963 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 YN88qjGwOm4Y for ; Thu, 25 Jul 2013 08:34:51 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9A21F9675 for ; Thu, 25 Jul 2013 08:34:51 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q16so526301vbe.41 for ; Thu, 25 Jul 2013 08:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lMOw7mkQuBVjbKwa2IiVSwUtorsHo0lr9PMlK3zi81E=; b=BuxqHYpszOW/fAsihlGO7Iza1ShhRVJFEwHSHveyBPZQT6owp7o8zfUZKI40pgUo4n X5+S9UDPdSScSkiCCxq5gJ3KjAdHUHZXQj9966xdXpT3+ieBYZImbPTyqpe8LR3L8aK2 /2DUk8QskYQOhSgKiUFsZVB6r3Y7yizi7wZjoIGBp3pr3o9jSDhU/ywRjFwVQ9ZT3pFQ UL12pZVGSeLh44PKgFvqYkXhSd3HvQ7jb7UmMP78jr4BXH3ssl7lY9zpg6et2eWOEmeV WHGnQslDWy3t+Q+uexkW0hfBGPs9M40kiYzYDQ8pseMrjDG/+oFegK9v4xdQICX9u0WC dbWg== MIME-Version: 1.0 X-Received: by 10.52.165.105 with SMTP id yx9mr15115695vdb.30.1374766490065; Thu, 25 Jul 2013 08:34:50 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Thu, 25 Jul 2013 08:34:49 -0700 (PDT) In-Reply-To: <1776975.bIMgeWNKBr@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> Date: Thu, 25 Jul 2013 11:34:49 -0400 X-Google-Sender-Auth: wQcZahVr7con2Xcx8gUv7fowTxM Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:34:52 -0000 Damn; I'm away from this list for a couple of days, and y'all somehow sense it, don't you? Oy. I'm responding to a message by Scott, because there are some things I want to say to Scott and specifically in response to this. But the points below about how we should and shouldn't be arguing things are ones that apply to others as well. >> The proposal of working on the document as an Individual Submission does >> not mean it is immutable. It will go through an IETF Last Call just like >> any other, and it will be required to accommodate any sustained feedback >> received. > > I've already said I don't think that the proposed approach is adequate and > (believe it or not) I am trying to minimize how much I repeat myself. Scott, be assured that your comments are being paid attention to -- the comments on the spec, the comments on the proposed charter, and the comments about the process we're following. > To my knowledge, there have been less than a handful of reviews Yes; as I've said, I want to see more reviews, and I want to see reviewers comment specifically on the process. > That said, I agree with the general premise that changes to bits on the wire > are unlikely to be needed, Good, thanks; that's useful to know. > but that doesn't mean the document doesn't need significant work. The question I have about this is whether you think the significant work really needs a working group to do it, or whether it can be handled by the individual submission path. The document editors will address your comments, there will be other reviews, and in the end we will either end up with a standards-track document that we have rough consensus on... or with a decision to abandon it. I think that can be done as an individual submission, but I'm willing to be convinced that that's not correct. > Secret group isn't a "jab". It's a fact. Well, it's closed, but it's not secret. In any case, let's all do our best to avoid that kind of rhetoric. The DMARC proponents participating here are well aware that they can't use "We developed it over there," as a claim to consensus, and I don't think they're trying to. Hence, see above about more reviews. > If I start with the assumption that this is the correct approach, then I don't > think an IETF working group to write a BCP makes sense. I still think having > the group do some serious work on improving the base spec makes sense Thank you; this, too, is useful. And as I said above, I hear you and Pete hears you. Your comments are being paid attention to. > I think I'm just going to sit out further charter discussions because I don't > think I'm likely to change anyone's mind at this point Well, I think the important point is that if you have something new to say, please say it. If you've already made your point, we've heard it, and thanks for that. Barry, Applications AD From sklist@kitterman.com Thu Jul 25 09:31:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DE121F98AD for ; Thu, 25 Jul 2013 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e3s3xUADoL4 for ; Thu, 25 Jul 2013 09:31:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A260F21F9943 for ; Thu, 25 Jul 2013 09:31:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 48A9720E40EA; Thu, 25 Jul 2013 12:31:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1374769881; bh=g2Onspq/SQm1PcoAZuNOR1DNOouhkWOII5l2BED3Amc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GLI2zKs7XyVlnfpYiZLHNlbNPi7ANmDgze22dIvASve++ZiUXOHZDLFHvMoG42sK2 +poWZKUkJ/kfctgbfWDQFS8tbkWQtlrGrpOF4xETkDb3vgKuL43lNqQ9RD9KM8UnEC BfWO/kqYExjO2BcmblS2mcw/MCYAwLHiEPDUcJEQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2767020E40C2; Thu, 25 Jul 2013 12:31:20 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 25 Jul 2013 12:31:20 -0400 Message-ID: <8335176.JtW2QvAHFe@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <51EF0A2D.4080702@gmail.com> <1776975.bIMgeWNKBr@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: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:31:30 -0000 On Thursday, July 25, 2013 11:34:49 AM Barry Leiba wrote: > Damn; I'm away from this list for a couple of days, and y'all somehow > sense it, don't you? Oy. > > I'm responding to a message by Scott, because there are some things I > want to say to Scott and specifically in response to this. But the > points below about how we should and shouldn't be arguing things are > ones that apply to others as well. > > >> The proposal of working on the document as an Individual Submission does > >> not mean it is immutable. It will go through an IETF Last Call just like > >> any other, and it will be required to accommodate any sustained feedback > >> received. > > > > I've already said I don't think that the proposed approach is adequate and > > (believe it or not) I am trying to minimize how much I repeat myself. > > Scott, be assured that your comments are being paid attention to -- > the comments on the spec, the comments on the proposed charter, and > the comments about the process we're following. > > > To my knowledge, there have been less than a handful of reviews > > Yes; as I've said, I want to see more reviews, and I want to see > reviewers comment specifically on the process. > > > That said, I agree with the general premise that changes to bits on the > > wire are unlikely to be needed, > > Good, thanks; that's useful to know. > > > but that doesn't mean the document doesn't need significant work. > > The question I have about this is whether you think the significant > work really needs a working group to do it, or whether it can be > handled by the individual submission path. The document editors will > address your comments, there will be other reviews, and in the end we > will either end up with a standards-track document that we have rough > consensus on... or with a decision to abandon it. > > I think that can be done as an individual submission, but I'm willing > to be convinced that that's not correct. > > > Secret group isn't a "jab". It's a fact. > > Well, it's closed, but it's not secret. In any case, let's all do our > best to avoid that kind of rhetoric. The DMARC proponents > participating here are well aware that they can't use "We developed it > over there," as a claim to consensus, and I don't think they're trying > to. Hence, see above about more reviews. What I meant to say is that the discussions are secret, the existence of the group is, of course, well known. > > If I start with the assumption that this is the correct approach, then I > > don't think an IETF working group to write a BCP makes sense. I still > > think having the group do some serious work on improving the base spec > > makes sense > Thank you; this, too, is useful. And as I said above, I hear you and > Pete hears you. Your comments are being paid attention to. > > > I think I'm just going to sit out further charter discussions because I > > don't think I'm likely to change anyone's mind at this point > > Well, I think the important point is that if you have something new to > say, please say it. If you've already made your point, we've heard > it, and thanks for that. Thanks. I think I've made it. Scott K From MHammer@ag.com Thu Jul 25 09:59:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12E121F89A5 for ; Thu, 25 Jul 2013 09:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93TWIPRvnJJb for ; Thu, 25 Jul 2013 09:59:22 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8783921F8749 for ; Thu, 25 Jul 2013 09:59:22 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 12:59:21 -0400 From: "MH Michael Hammer (5304)" To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Updated Draft Charter for Review Thread-Index: AQHOh/fxmiKG9zANfUqo7/Qaam4kTZlzUWIAgAA9k4CAAAF1AIAACB8AgAB4NoCAAbtegIAAD8oA///BmHA= Date: Thu, 25 Jul 2013 16:59:21 +0000 Message-ID: References: <51EF0A2D.4080702@gmail.com> <1776975.bIMgeWNKBr@scott-latitude-e6320> <8335176.JtW2QvAHFe@scott-latitude-e6320> In-Reply-To: <8335176.JtW2QvAHFe@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.228] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:59:28 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Scott Kitterman > Sent: Thursday, July 25, 2013 12:31 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Updated Draft Charter for Review >=20 > On Thursday, July 25, 2013 11:34:49 AM Barry Leiba wrote: > > Damn; I'm away from this list for a couple of days, and y'all somehow > > sense it, don't you? Oy. > > > > I'm responding to a message by Scott, because there are some things I > > want to say to Scott and specifically in response to this. But the > > points below about how we should and shouldn't be arguing things are > > ones that apply to others as well. > > > > >> The proposal of working on the document as an Individual Submission > > >> does not mean it is immutable. It will go through an IETF Last > > >> Call just like any other, and it will be required to accommodate > > >> any sustained feedback received. > > > > > > I've already said I don't think that the proposed approach is > > > adequate and (believe it or not) I am trying to minimize how much I > repeat myself. > > > > Scott, be assured that your comments are being paid attention to -- > > the comments on the spec, the comments on the proposed charter, and > > the comments about the process we're following. > > > > > To my knowledge, there have been less than a handful of reviews > > > > Yes; as I've said, I want to see more reviews, and I want to see > > reviewers comment specifically on the process. > > > > > That said, I agree with the general premise that changes to bits on > > > the wire are unlikely to be needed, > > > > Good, thanks; that's useful to know. > > > > > but that doesn't mean the document doesn't need significant work. > > > > The question I have about this is whether you think the significant > > work really needs a working group to do it, or whether it can be > > handled by the individual submission path. The document editors will > > address your comments, there will be other reviews, and in the end we > > will either end up with a standards-track document that we have rough > > consensus on... or with a decision to abandon it. > > > > I think that can be done as an individual submission, but I'm willing > > to be convinced that that's not correct. > > > > > Secret group isn't a "jab". It's a fact. > > > > Well, it's closed, but it's not secret. In any case, let's all do our > > best to avoid that kind of rhetoric. The DMARC proponents > > participating here are well aware that they can't use "We developed it > > over there," as a claim to consensus, and I don't think they're trying > > to. Hence, see above about more reviews. >=20 > What I meant to say is that the discussions are secret, the existence of = the > group is, of course, well known. >=20 I much prefer the word private over the word secret. I'm not sure what your= point is regarding such discussions. Are you asserting that participants i= n IETF working groups never have side bar conversations? Are you willing to= assert that you have never had a side bar "private" conversation with anyo= ne about a topic or issue before an IETF working group? Unless you have evidence that this group engaged in private discussions are= secretly trying to manipulate the IETF process in nefarious ways then I do= n't see how the existence of this private group makes any difference. The g= roup has been public and forthright about concerns as well as process.=20 In order for your expressed concern to be relevant you need to provide some= evidence that the group is subverting the IETF rather than working within = the existing mechanisms/processes. The choice to pursue individual submissi= on may not be your preference but that is a legitimate approach. I haven't = seen a substantive argument from you with regard to private discussions. > > > If I start with the assumption that this is the correct approach, > > > then I don't think an IETF working group to write a BCP makes sense. > > > I still think having the group do some serious work on improving the > > > base spec makes sense > > Thank you; this, too, is useful. And as I said above, I hear you and > > Pete hears you. Your comments are being paid attention to. > > > > > I think I'm just going to sit out further charter discussions > > > because I don't think I'm likely to change anyone's mind at this > > > point > > > > Well, I think the important point is that if you have something new to > > say, please say it. If you've already made your point, we've heard > > it, and thanks for that. >=20 > Thanks. I think I've made it. >=20 > Scott K Mike From sklist@kitterman.com Thu Jul 25 11:13:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF5821F942D for ; Thu, 25 Jul 2013 11:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4obKGx9-4YL for ; Thu, 25 Jul 2013 11:13:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31B21F8B12 for ; Thu, 25 Jul 2013 11:13:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5081220E40EA; Thu, 25 Jul 2013 14:12:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1374775981; bh=VO6mKzBdpwoclAXKov2tY9d6cqZVl5x4Szp9FU0f/dQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n168HKRFFES6y+FQs3hDKPWfnwGVNa2Zg+uGoD7G173peESIlLfnqd3U6X+NTnKoV cJC7PgLDH5M+DURqWdYFvh6QrCZ1uQy65mAKPpPPFOkCw920RF49G0xuTPMnrasOps 119nGchsbzVRmQVEtJJAKc8Kj82EdTNv4qZk4lt4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3263B20E40C2; Thu, 25 Jul 2013 14:12:49 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 25 Jul 2013 14:12:48 -0400 Message-ID: <7640882.QXmcht3Tj0@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <51EF0A2D.4080702@gmail.com> <8335176.JtW2QvAHFe@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: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 18:13:12 -0000 On Thursday, July 25, 2013 04:59:21 PM MH Michael Hammer wrote: > > > > Secret group isn't a "jab". It's a fact. > > > > > > Well, it's closed, but it's not secret. In any case, let's all do our > > > best to avoid that kind of rhetoric. The DMARC proponents > > > participating here are well aware that they can't use "We developed it > > > over there," as a claim to consensus, and I don't think they're trying > > > to. Hence, see above about more reviews. > > > > > > > > What I meant to say is that the discussions are secret, the existence of > > the group is, of course, well known. > > > > > > I much prefer the word private over the word secret. I'm not sure what your > point is regarding such discussions. Are you asserting that participants in > IETF working groups never have side bar conversations? Are you willing to > assert that you have never had a side bar "private" conversation with > anyone about a topic or issue before an IETF working group? > > Unless you have evidence that this group engaged in private discussions are > secretly trying to manipulate the IETF process in nefarious ways then I > don't see how the existence of this private group makes any difference. The > group has been public and forthright about concerns as well as process. > > In order for your expressed concern to be relevant you need to provide some > evidence that the group is subverting the IETF rather than working within > the existing mechanisms/processes. The choice to pursue individual > submission may not be your preference but that is a legitimate approach. I > haven't seen a substantive argument from you with regard to private > discussions. Of course side discussions happen all the time. I don't think it's nefarious, but it's not open. The "normal" IETF process in my experience is that the primary venue for discussions and decision making are open and there are some side discussions along the way. So far, DMARC has been the opposite. From an outside perspective, drafts come out, comments go in, and then another draft comes out. In the most recent draft some of my comments against earlier drafts have been partially addressed. There wasn't any public discussion of the proposed changes, they just appear out of nowhere. I'm not claiming my comments are being ignored, I know they aren't. I would like for there to be an open venue to discuss and resolve the issues that come up when people review the drafts. I don't need to prove nefariousness and I'm not claiming there's some rule violation associated with an AD sponsored individual submission. I'm not concerned that the DMARC group is up to no good. I'm concerned that the resistance to open work on the base spec is going to produce a lower quality result. Obviously the AD can decide to do this however he wants. I'm arguing for the one that I think will work the best. Scott K From barryleiba.mailing.lists@gmail.com Thu Jul 25 11:20:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCD121F962D for ; Thu, 25 Jul 2013 11:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 qCB7MIXuQBIv for ; Thu, 25 Jul 2013 11:20:14 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8294121F8427 for ; Thu, 25 Jul 2013 11:20:13 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so666390veb.8 for ; Thu, 25 Jul 2013 11:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WJxw/iri8zkIIRheu32BaX2dLku1awpIp+/bws3YNYg=; b=ZciqTdLWYXKO5hmwltB9bsRSxZqB5eozm3zBOw5JbWyC4iEoN1hwbhDhBtsMnK3Rfz djdc3CF3GYiF9BvAHJ5hGDdk0Qz3cJ5BIy7KP07VBJHVUuXLlAsJImavDMv6PZ169b9B rzzE0FjACy+pBjPqFRw9FOU/mZg+RT5YOaFi7pEWr02nF8E9F2NKcmj517prRK2IDX02 YZG9TJfZN7ClF9EFJuimTCBclHqIDYEPZsziX84E44V5VCG8Of1P/X62uvx16EAv9LnC UxqODdeJg+rcoQAVVQ3B5vE2R/Hy3sgElZ+Doosv2MNV2yT94fcl6XB0WgtmlsC04AVY doJw== MIME-Version: 1.0 X-Received: by 10.220.98.68 with SMTP id p4mr1271017vcn.28.1374776412858; Thu, 25 Jul 2013 11:20:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Thu, 25 Jul 2013 11:20:12 -0700 (PDT) In-Reply-To: <7640882.QXmcht3Tj0@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <8335176.JtW2QvAHFe@scott-latitude-e6320> <7640882.QXmcht3Tj0@scott-latitude-e6320> Date: Thu, 25 Jul 2013 14:20:12 -0400 X-Google-Sender-Auth: XWa6kF1z-Xqeln339be6DgD1yUw Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 18:20:14 -0000 > In the most recent draft some of my comments against earlier drafts have been > partially addressed. There wasn't any public discussion of the proposed > changes, they just appear out of nowhere. > > I'm not claiming my comments are being ignored, I know they aren't. I would > like for there to be an open venue to discuss and resolve the issues that come > up when people review the drafts. And this is that venue. Let's take this message as my request that the DMARC community keep all discussion of the DMARC specification on this list (dmarc@ietf.org) while we are processing the document in the IETF. (This isn't an accusation, and there's no particular need to have a meta-discussion here. Let's just make sure the discussions of the spec happen here.) Barry, Applications AD From steven.m.jones@bankofamerica.com Thu Jul 25 14:20:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7721F91CA for ; Thu, 25 Jul 2013 14:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iCy57dDc-YD for ; Thu, 25 Jul 2013 14:20:32 -0700 (PDT) Received: from txdmzmailmx06.bankofamerica.com (txmx06.bankofamerica.com [171.161.160.13]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB821F8607 for ; Thu, 25 Jul 2013 14:20:30 -0700 (PDT) Received: from txdmzmailmx05.bankofamerica.com ([171.180.168.230]) by txdmzmailmx06.bankofamerica.com (8.14.5/8.14.5) with ESMTP id r6PLJv8K014634; Thu, 25 Jul 2013 21:20:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bankofamerica.com; s=corp1210; t=1374787213; bh=PbN95TKjgQc06BRR8zeDCJehbA2pM0XVWLDGXaVJTfE=; h=Date:From:Subject:In-reply-to:To:Message-id:MIME-version: Content-type:Content-transfer-encoding:References; b=He/4SNdHZSUX9T03z9yRw5j/ufwuQo6LsTetGxen0l/6UEulTQJYArJ2ml9e5lwun Rj5EGiMlscKdr/jGdNVPRAOuAm13XF2lCVDATVz0Tgt4zlUI8yBBrp6GWm/103ZWBv jkaTjxxqAOO07SsUPnYMvcWIsQTZXakJ/aQjBrps= Received: from memtx2mta03.bankofamerica.com (memtx2mta03.bankofamerica.com [171.186.232.156]) by txdmzmailmx05.bankofamerica.com (8.14.5/8.14.5) with ESMTP id r6PLJqfY018831; Thu, 25 Jul 2013 21:19:57 GMT Date: Thu, 25 Jul 2013 21:19:54 +0000 From: "Jones, Steven M" In-reply-to: X-Originating-IP: [171.206.135.17] To: Barry Leiba , "dmarc@ietf.org" Message-id: <7EC008BFD9B40A4183ED77EEC394AB8D0D9EAE6D@smtp_mail.bankofamerica.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [dmarc-ietf] Updated Draft Charter for Review Thread-index: AQHOiUyc4jOKfSbSmk+ylxGqoarmSpl14CYg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-25_09:2013-07-25, 2013-07-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:20:41 -0000 Barry Leiba wrote: > Damn; I'm away from this list for a couple of days, and y'all somehow > sense it, don't you? Oy. This is similar to how I have felt about all of these threads - when I can make some time to catch up on them, I often feel like the atmosphere is so charged that any comments I might make would not be productive. But thank you for returning and reminding us that all voices both deserve to be heard, are in fact being heard, and will be considered. Thanks in no small part to the recent edits, the charter seems reasonable to me. I plan to participate remotely in the BoF, and hope to participate in the proposed working group when it is instantiated. I think trying to address "display name" and mailing list transits could be another 3 year slog, but an attempt - here or elsewhere - needs to be made. These problems haven't gone away on their own, and I guess in this case past performance does guarantee future returns... ;) --Steve. ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From superuser@gmail.com Thu Jul 25 14:23:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B6421F8468 for ; Thu, 25 Jul 2013 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LAvdQK+bdSA for ; Thu, 25 Jul 2013 14:23:04 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9E21F8467 for ; Thu, 25 Jul 2013 14:23:03 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so107572wiv.8 for ; Thu, 25 Jul 2013 14:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ixoX2BjOFDkNFio2AwK+9wdgPCvqKIDzQD7qkhBIh3A=; b=XKh3WvFWRQlR05b9SrfYynF5EWzJqhV5OV/jfe8vPpY62xbQrvykPRTPEWoRBeL/Iq FpbtjJkZ14zjtRTFPV5SfW3nVdBOWFWJc7/RTbCe92GAUCJBbEEv37Tzf335Ynvs3eKy byT6T1+RKFbF8qgIOvStDUzf2BmV/Y2IrsEXzUXV3ehS1geHZ8hDDJfkEc9FhbzzbVDt m3QFXteGczu8aK3ZT4bCKca2EFKyVFJo8t5Fq+FEceGMr/HyBG/ClX9WYAfVBzBpib4s pQNKEReEwA88qNyf035Bjgq8q3yGTuvluYVmcDpf3JnZQUDEdr22vSYECQC+IQgWGl/O KPhg== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr3531397wic.19.1374787382795; Thu, 25 Jul 2013 14:23:02 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 25 Jul 2013 14:23:02 -0700 (PDT) In-Reply-To: <7640882.QXmcht3Tj0@scott-latitude-e6320> References: <51EF0A2D.4080702@gmail.com> <8335176.JtW2QvAHFe@scott-latitude-e6320> <7640882.QXmcht3Tj0@scott-latitude-e6320> Date: Thu, 25 Jul 2013 14:23:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c3436a97e6fc04e25ca111 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Updated Draft Charter for Review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:23:05 -0000 --001a11c3436a97e6fc04e25ca111 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 25, 2013 at 11:12 AM, Scott Kitterman wrote: > I don't think it's nefarious, but it's not open. The "normal" IETF > process in > my experience is that the primary venue for discussions and decision making > are open and there are some side discussions along the way. So far, DMARC > has > been the opposite. From an outside perspective, drafts come out, comments > go > in, and then another draft comes out. > As I've said before, this is not true. The private group went public via a web site and simultaneously created an open list for discussion, to which you subscribed and on which you participated in discussions about the document once it went public. That happened in January of 2012. Other than the fact that said list was not an @ietf.org list, it doesn't get much more open and relevant than that. > > In the most recent draft some of my comments against earlier drafts have > been > partially addressed. There wasn't any public discussion of the proposed > changes, they just appear out of nowhere. > As is typical in IETF processing (to which you've had plenty of exposure), changes that are obviously right often don't get large amounts of discussion before they appear in documents. I don't know why this is suddenly noteworthy. If there are bits you mentioned on-list that were missed in the update, then by all means please identify them and describe the remedy you'd like to see, preferably with OLD/NEW text as usual. > > I'm not claiming my comments are being ignored, I know they aren't. I > would > like for there to be an open venue to discuss and resolve the issues that > come > up when people review the drafts. > Such has existed for over 18 months now, and recently this additional one has appeared. > > I don't need to prove nefariousness and I'm not claiming there's some rule > violation associated with an AD sponsored individual submission. I'm not > concerned that the DMARC group is up to no good. I'm concerned that the > resistance to open work on the base spec is going to produce a lower > quality > result. Obviously the AD can decide to do this however he wants. I'm > arguing > for the one that I think will work the best. > I totally agree, but I also believe that these discussions about abnormal, closed, or private discussions are a distraction at best. -MSK --001a11c3436a97e6fc04e25ca111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 25, 2013 at 11:12 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:
I don't think it's nefarious, but it= 's not open. =A0The "normal" IETF process in
my experience is that the primary venue for discussions and decision making=
are open and there are some side discussions along the way. =A0So far, DMAR= C has
been the opposite. =A0From an outside perspective, drafts come out, comment= s go
in, and then another draft comes out.

A= s I've said before, this is not true.=A0 The private group went public = via a web site and simultaneously created an open list for discussion, to w= hich you subscribed and on which you participated in discussions about the = document once it went public.=A0 That happened in January of 2012.=A0 Other= than the fact that said list was not an @ietf.= org list, it doesn't get much more open and relevant than that.
=A0

In the most recent draft some of my comments against earlier drafts have be= en
partially addressed. =A0There wasn't any public discussion of the propo= sed
changes, they just appear out of nowhere.

As is typical in IETF processing (to which you've had plenty of expo= sure), changes that are obviously right often don't get large amounts o= f discussion before they appear in documents.=A0 I don't know why this = is suddenly noteworthy.

If there are bits you mentioned on-list that were missed in = the update, then by all means please identify them and describe the remedy = you'd like to see, preferably with OLD/NEW text as usual.
=A0

I'm not claiming my comments are being ignored, I know they aren't.= =A0I would
like for there to be an open venue to discuss and resolve the issues that c= ome
up when people review the drafts.

Such = has existed for over 18 months now, and recently this additional one has ap= peared.
=A0

I don't need to prove nefariousness and I'm not claiming there'= s some rule
violation associated with an AD sponsored individual submission. =A0I'm= not
concerned that the DMARC group is up to no good. =A0I'm concerned that = the
resistance to open work on the base spec is going to produce a lower qualit= y
result. =A0Obviously the AD can decide to do this however he wants. =A0I= 9;m arguing
for the one that I think will work the best.

I totally agree, but I also believe that these discussions about abno= rmal, closed, or private discussions are a distraction at best.

-MSK
--001a11c3436a97e6fc04e25ca111-- From Greg.Colburn@returnpath.com Thu Jul 25 19:58:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25C21F848A for ; Thu, 25 Jul 2013 19:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.504 X-Spam-Level: X-Spam-Status: No, score=-9.504 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_05=-1.11, HABEAS_ACCREDITED_SOI=-4.3, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiVdhJcTZpXi for ; Thu, 25 Jul 2013 19:58:00 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id E80D321F847C for ; Thu, 25 Jul 2013 19:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to :subject:content-type:mime-version; s=smtpapi; bh=+gkWriQp9vURc+ 0NqO8UpNdSjl8=; b=Dylr7Oqso82d2jXv3fmtpnLTvYMnqYwMglV83AAamXp1Ei Awkm7DzkaEURwW43ux1RaMQdgjrE5Egop1xxBFQqW2tDiJWMPcJMVvlZHhA3s7Kp hJYlHNK9ligislVKUgycrkszX2Vq6JTj6OLWFvIMrxxe1zHJeaa/w2vi8itXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to :subject:content-type:mime-version; q=dns; s=smtpapi; b=S4KUE1zo JJB6vwOmON+UoIWnYdVizzIRz20oPJJVBYmBN8y8MXjit+JoL5ho3lsY09MrxUuO EToWtx50CsQAIIrO/WhgPV2D0wdUJyt/CV996iJNvMkvM4Cn9gKCBV+cJMAQFoQi B/RcDkphYTgN19xiQGlvoi+IYXX0yhMdaIE= Received: by 10.8.49.96 with SMTP id mf44.26800.51F1E5B62 Fri, 26 Jul 2013 02:57:58 +0000 (GMT) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by mi23 (SG) with ESMTP id 14018e950eb.f67.582764 for ; Fri, 26 Jul 2013 02:57:58 +0000 (UTC) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Thu, 25 Jul 2013 20:57:58 -0600 From: Greg Colburn To: "dmarc@ietf.org" Date: Thu, 25 Jul 2013 20:57:44 -0600 Thread-Topic: hosted XSD does not match latest draft Thread-Index: Ac6Jq+6nJcKw59a7TBq5vIpbRxMJ1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_CE1741C835C95gregcolburnreturnpathcom_" MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5JlrIydngFmdgqkFQobRasfQcXCqPRG+SCPET+BPrNZFo8jGqKJn4RvIRIzjUTXNYvLDXbjKSF3O41btdx9Fx3y Subject: [dmarc-ietf] hosted XSD does not match latest draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 02:58:04 -0000 --_004_CE1741C835C95gregcolburnreturnpathcom_ Content-Type: multipart/alternative; boundary="_000_CE1741C835C95gregcolburnreturnpathcom_" --_000_CE1741C835C95gregcolburnreturnpathcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey folks One of the engineers on our team noticed that the hosted rua.xsd does not m= atch the latest draft from July 15. The following link should be updated w= ith the xsd from the 2013-07-15 draft. http://dmarc.org/dmarc-xml/0.1/rua.xsd I attached the diff. It's minor stuff but worthwhile to keep the online xs= d update for anyone pulling it for validation. Greg C --_000_CE1741C835C95gregcolburnreturnpathcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hey folks

One of the engineers on our team noticed that the hosted= rua.xsd does not match the latest draft from July 15.  The following = link should be updated with the xsd from the 2013-07-15 draft.<= /div>


I attached the diff.  It's minor stuff b= ut worthwhile to keep the online xsd update for anyone pulling it for valid= ation.

Greg C
--_000_CE1741C835C95gregcolburnreturnpathcom_-- --_004_CE1741C835C95gregcolburnreturnpathcom_ Content-Type: application/octet-stream; name="oldvsnew_xsd.diff" Content-Description: oldvsnew_xsd.diff Content-Disposition: attachment; filename="oldvsnew_xsd.diff"; size=2289; creation-date="Fri, 26 Jul 2013 02:57:57 GMT"; modification-date="Fri, 26 Jul 2013 02:57:57 GMT" Content-Transfer-Encoding: base64 Myw0YzMKPCAgIHRhcmdldE5hbWVzcGFjZT0iaHR0cDovL2RtYXJjLm9yZy9k bWFyYy14bWwvMC4xIgo8ICAgeG1sbnM9Imh0dHA6Ly9kbWFyYy5vcmcvZG1h cmMteG1sLzAuMSI+Ci0tLQo+ICAgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8v ZG1hcmMub3JnL2RtYXJjLXhtbC8wLjEiPgo3MCw5NmQ2OAo8IDwhLS0gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KPCBEZXNjcmlwdGlvbnMgb2YgdGhlIFBvbGljeU92 ZXJyaWRlVHlwZXM6CjwgCjwgZm9yd2FyZGVkOiAgTWVzc2FnZSB3YXMgcmVs YXllZCB2aWEgYSBrbm93biBmb3J3YXJkZXIsIG9yIGxvY2FsCjwgICAgaGV1 cmlzdGljcyBpZGVudGlmaWVkIHRoZSBtZXNzYWdlIGFzIGxpa2VseSBoYXZp bmcgYmVlbiBmb3J3YXJkZWQuCjwgICAgVGhlcmUgaXMgbm8gZXhwZWN0YXRp b24gdGhhdCBhdXRoZW50aWNhdGlvbiB3b3VsZCBwYXNzLgo8IAo8IGxvY2Fs X3BvbGljeTogIFRoZSBNYWlsIFJlY2VpdmVyJ3MgbG9jYWwgcG9saWN5IGV4 ZW1wdGVkIHRoZSBtZXNzYWdlCjwgICAgZnJvbSBiZWluZyBzdWJqZWN0ZWQg dG8gdGhlIERvbWFpbiBPd25lcidzIHJlcXVlc3RlZCBwb2xpY3kKPCAgICBh Y3Rpb24uCjwgCjwgbWFpbGluZ19saXN0OiAgTG9jYWwgaGV1cmlzdGljcyBk ZXRlcm1pbmVkIHRoYXQgdGhlIG1lc3NhZ2UgYXJyaXZlZAo8ICAgIHZpYSBh IG1haWxpbmcgbGlzdCwgYW5kIHRodXMgYXV0aGVudGljYXRpb24gb2YgdGhl IG9yaWdpbmFsCjwgICAgbWVzc2FnZSB3YXMgbm90IGV4cGVjdGVkIHRvIHN1 Y2NlZWQuCjwgCjwgb3RoZXI6ICBTb21lIHBvbGljeSBleGNlcHRpb24gbm90 IGNvdmVyZWQgYnkgdGhlIG90aGVyIGVudHJpZXMgaW4KPCAgICB0aGlzIGxp c3Qgb2NjdXJyZWQuICBBZGRpdGlvbmFsIGRldGFpbCBjYW4gYmUgZm91bmQg aW4gdGhlCjwgICAgUG9saWN5T3ZlcnJpZGVSZWFzb24ncyAiY29tbWVudCIg ZmllbGQuCjwgCjwgc2FtcGxlZF9vdXQ6ICBNZXNzYWdlIHdhcyBleGVtcHRl ZCBmcm9tIGFwcGxpY2F0aW9uIG9mIHBvbGljeSBieSB0aGUKPCAgICAicGN0 IiBzZXR0aW5nIGluIHRoZSBETUFSQyBwb2xpY3kgcmVjb3JkLgo8IAo8IHRy dXN0ZWRfZm9yd2FyZGVyOiAgTWVzc2FnZSBhdXRoZW50aWNhdGlvbiBmYWls dXJlIHdhcyBhbnRpY2lwYXRlZCBieQo8ICAgIG90aGVyIGV2aWRlbmNlIGxp bmtpbmcgdGhlIG1lc3NhZ2UgdG8gYSBsb2NhbGx5LW1haW50YWluZWQgbGlz dCBvZgo8ICAgIGtub3duIGFuZCB0cnVzdGVkIGZvcndhcmRlcnMuCjwgPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0gLS0+CjwgCjE0OWExMjIsMTIzCj4gICAgIDwhLS0g VGhlIGVudmVsb3BlIGZyb20gZG9tYWluLiAtLT4KPiAgICAgPHhzOmVsZW1l bnQgbmFtZT0iZW52ZWxvcGVfZnJvbSIgdHlwZT0ieHM6c3RyaW5nIiBtaW5P Y2N1cnM9IjEiLz4KMTcxYTE0NiwxNDcKPiAgICAgPCEtLSBUaGUgcz0gcGFy YW1ldGVyIGluIHRoZSBzaWduYXR1cmUgLS0+Cj4gICAgIDx4czplbGVtZW50 IG5hbWU9InNlbGVjdG9yIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0i MCIvPgoxNzhhMTU1LDE2Mgo+IDwhLS0gU1BGIGRvbWFpbiBzY29wZSAtLT4K PiA8eHM6c2ltcGxlVHlwZSBuYW1lPSJTUEZEb21haW5TY29wZSI+Cj4gICA8 eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIj4KPiAgICAgPHhzOmVu dW1lcmF0aW9uIHZhbHVlPSJoZWxvIi8+Cj4gICAgIDx4czplbnVtZXJhdGlv biB2YWx1ZT0ibWZyb20iLz4KPiAgIDwveHM6cmVzdHJpY3Rpb24+Cj4gPC94 czpzaW1wbGVUeXBlPgo+IAoxOTZjMTgwCjwgICAgIDwhLS0gVGhlIGVudmVs b3BlIEZyb20gZG9tYWluLiAtLT4KLS0tCj4gICAgIDwhLS0gVGhlIGNoZWNr ZWQgZG9tYWluLiAtLT4KMTk3YTE4MiwxODMKPiAgICAgPCEtLSBUaGUgc2Nv cGUgb2YgdGhlIGNoZWNrZWQgZG9tYWluLiAtLT4KPiAgICAgPHhzOmVsZW1l bnQgbmFtZT0ic2NvcGUiIHR5cGU9IlNQRkRvbWFpblNjb3BlIiBtaW5PY2N1 cnM9IjEiLz4KMjI2YzIxMiwyMTMKPCAgICAgICA8eHM6ZWxlbWVudCBuYW1l PSJyZXBvcnRfbWV0YWRhdGEiIHR5cGU9IlJlcG9ydE1ldGFkYXRhVHlwZSIv PgotLS0KPiAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJ2ZXJzaW9uIiB0eXBl PSJ4czpkZWNpbWFsIi8+Cj4gCSAgPHhzOmVsZW1lbnQgbmFtZT0icmVwb3J0 X21ldGFkYXRhIiB0eXBlPSJSZXBvcnRNZXRhZGF0YVR5cGUiLz4K --_004_CE1741C835C95gregcolburnreturnpathcom_-- From dcrocker@gmail.com Thu Jul 25 22:43:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A66621F8497 for ; Thu, 25 Jul 2013 22:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSyztqrFzKkj for ; Thu, 25 Jul 2013 22:43:30 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD9821F8495 for ; Thu, 25 Jul 2013 22:43:29 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so395202wid.4 for ; Thu, 25 Jul 2013 22:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=c4MZ5ZVUkV6zNH8W9pCPbIobLO2MfDei6buitrTQonk=; b=xVfbjE0gisL79kCIBOVtXqdxtrvr1oM91jiymloOyDCVNEi9Nnmlj8ujHxoqhnUTDC gLfi+aZ6qRrH7OTzzAw8FnAMPz5jMHV/uy7aH/BnNSqDLX0z5kxSQBf98E646yLbPKKW fHKlSVbQzw5sGOifDd670OnZFQ0J1mY7nB22NSEmBC6O+B69/IDxkoTIWcRKpLOSkOOV RoE3hrI35323te07JfLfQT4FWAtIJN7X3oKrRheZCR9a4MT6tP8IDkgX1Ka9ybODSVLk cU3xL52+GXP3geyuQNKuX9opm2QYt9iZpOHSSmmVlimdf997O5RQc88wo09+Iho5AAvE JIXg== X-Received: by 10.180.83.163 with SMTP id r3mr4463959wiy.10.1374817408765; Thu, 25 Jul 2013 22:43:28 -0700 (PDT) Received: from [10.0.0.12] (host217-40-191-246.in-addr.btopenworld.com. [217.40.191.246]) by mx.google.com with ESMTPSA id fs8sm2202683wib.0.2013.07.25.22.43.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 22:43:28 -0700 (PDT) Message-ID: <51F20C7C.208@gmail.com> Date: Fri, 26 Jul 2013 06:43:24 +0100 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Jones, Steven M" References: <51EF0A2D.4080702@gmail.com> <27496080.geGbC66fNp@scott-latitude-e6320> <1776975.bIMgeWNKBr@scott-latitude-e6320> <7EC008BFD9B40A4183ED77EEC394AB8D0D9EAE6D@smtp_mail.bankofamerica.com> In-Reply-To: <7EC008BFD9B40A4183ED77EEC394AB8D0D9EAE6D@smtp_mail.bankofamerica.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , Barry Leiba Subject: [dmarc-ietf] Display Name (was Re: Updated Draft Charter for Review) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 05:43:31 -0000 On 7/25/2013 10:19 PM,, Steven M wrote: > I think trying to address "display name" and mailing list transits could be another 3 year slog, but an attempt - here or elsewhere - needs to be made. These problems haven't gone away on their own, and I guess in this case past performance does guarantee future returns...;) It might help for us to try to find reasonable wording for the goal we think reasonable, concerning display names. I think it's easy to make a lofty, appealing goal statement, but probably much harder to make a pragmatic one that folks generally think technically and operationally and socially tractable. In fact I think it daunting enough that -- contrary to my usual practice when suggesting a group pursue wording -- I can't think of candidate text to offer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Jul 26 03:36:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D3B21F8C66 for ; Fri, 26 Jul 2013 03:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79+QIluLYz+m for ; Fri, 26 Jul 2013 03:36:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8C21F87B7 for ; Fri, 26 Jul 2013 03:36:45 -0700 (PDT) Received: from [192.168.174.125] ([192.173.4.185]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6QAae3Q010140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jul 2013 03:36:44 -0700 Message-ID: <51F25134.4090404@dcrocker.net> Date: Fri, 26 Jul 2013 11:36:36 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <016CD35E-2382-4822-8CA3-BF47D489BE96@verilan.com> In-Reply-To: <016CD35E-2382-4822-8CA3-BF47D489BE96@verilan.com> X-Forwarded-Message-Id: <016CD35E-2382-4822-8CA3-BF47D489BE96@verilan.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.66]); Fri, 26 Jul 2013 03:36:45 -0700 (PDT) X-Mailman-Approved-At: Fri, 26 Jul 2013 10:09:18 -0700 Subject: [dmarc-ietf] Fwd: IETF87 Audio Streaming Info X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:36:50 -0000 For those who will be attending the DMARC BOF remotely... d/ -------- Original Message -------- Subject: IETF87 Audio Streaming Info Date: Fri, 26 Jul 2013 12:00:30 +0200 From: Nick Kukich To: ietf@ietf.org Greetings, For those interested in monitoring sessions or participating remotely the following information may prove useful. For general remote participation including Meetecho support see: http://www.ietf.org/meeting/87/remote-participation.html -Audio Streaming- All 8 parallel tracks at the IETF 87 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 29, 2013 at 0900 CEST (UTC+2) and continue until the close of sessions on Friday, August 2nd. Because we have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per standard operating procedure will be located here: http://tools.ietf.org/agenda/87/ -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. -Webex- Webex screen sharing participation is possible for a limited number of sessions. Consult with your working-group chair or the secretariat for more information. -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.com with info including the current time and affected streaming channel. *Nick Kukich* *Senior Network Engineer* Verilan, Inc. 503.710.5115 -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Tue Jul 30 09:06:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86B21F9C26 for ; Tue, 30 Jul 2013 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+yya3zFjeTO for ; Tue, 30 Jul 2013 09:06:02 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 719E421F9CB3 for ; Tue, 30 Jul 2013 09:03:53 -0700 (PDT) Received: from mx1.yitter.info (dhcp-64fd.meeting.ietf.org [130.129.100.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4C5948A031 for ; Tue, 30 Jul 2013 16:03:52 +0000 (UTC) Date: Tue, 30 Jul 2013 12:03:55 -0400 From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20130730160355.GO52723@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dmarc-ietf] [ajs@anvilwalrusden.com: [IAB] IETF 87 DMARC BOF evaluation] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:06:07 -0000 Dear colleagues, Here's the report I sent to the IESG and IAB about the DMARC BoF. I hope this report seems correct to you. Best. A ----- Forwarded message from Andrew Sullivan ----- Date: Tue, 30 Jul 2013 11:00:54 -0400 From: Andrew Sullivan To: iesg@ietf.org, iab@iab.org Subject: [IAB] IETF 87 DMARC BOF evaluation List-Id: "Internet Architecture Board \(IAB\)" Dear colleagues, The proposal for a DMARC WG is, in effect, to assume that a large existing spec gets adopted on the standards track outside any WG, and then to make a number of small changes to that existing spec in a WG. The BoF started with quite a lot of background info about, in effect, status of the existing work. The basic spec seems to me pretty well worked out (I felt rather like I was listening to presentations at the end of a WG: small issues that needed to get nailed down). But there are little edge issues. During the proposed charter discussion, I asked a number of questions about why to set up a WG. There's a cost to the IETF in having Yet Another WG: we already have too much work. To the extent that this spec is in good shape and complete, why can't the group that developed it complete the work? If the problem is that there are these issues for which the consortium that developed the specification doesn't have the expertise to solve, then it's hard to understand why the base spec is out of scope in the proposed charter. Since I heard lots of suggestions that the DMARC originators are anxious to make the spec better, why not just put the DMARC spec on the charter of the WG and do all the work? I very strongly agree that this basic work is an excellent basis for continued work. But it doesn't sound like it's done, and it seems to me therefore that the existing running code is a 0.9 effort; the 1.0 effort needs to go through the WG to complete. In any case, I do see the potential for valuable work here, and it does seem to me that the IETF is a natural place to do it since DMARC builds on other enabling technologies created at the IETF. At the same time, I think the IESG ought to think very hard about its ability to manage the number of WGs we already have, if the point is just to fix things around the edges of the spec. We have far too much work to do already. I saw significant appetite to work on this specification in the room, though most of the people volunteering to write documents were people who came from the existing DMARC work. I am convinced, in any case, that the chartering effort is being a little too cute about the relationship to the base spec, and I believe that, if it is chartered on the basis of the existing proposed charter before the base spec is published as an RFC, there will be major procedural pain in someone's future. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From housley@vigilsec.com Tue Jul 30 23:43:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2D821F9AC1; Tue, 30 Jul 2013 23:43:13 -0700 (PDT) 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 U8gJfoebOI03; Tue, 30 Jul 2013 23:43:06 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 128CF21F9B4B; Tue, 30 Jul 2013 23:43:04 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3E6BAF2402A; Wed, 31 Jul 2013 02:43:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id kw-RGXUPwZ09; Wed, 31 Jul 2013 02:43:00 -0400 (EDT) Received: from dhcp-540a.meeting.ietf.org (dhcp-540a.meeting.ietf.org [130.129.84.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9CD03F2401B; Wed, 31 Jul 2013 02:43:18 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jul 2013 02:43:00 -0400 Message-Id: <8401A59E-C6EC-4D29-8CDB-03D873F1655E@vigilsec.com> To: dmarc@ietf.org, "Apps Discuss" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [dmarc-ietf] DMARC BOF Summary X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 06:43:13 -0000 The DMARC base specification is being sponsored by Barry as an = individual submission for Proposed Standard. That specification is not = part of the proposed charter. There was agreement that the = specification could use some improvement, but only very minor technical = corrections are needed before publication as an RFC. Several people = felt that the DMARC base specification should be part of the proposed = working group. The proposed charter call for extensions to the base specification to = add new features as well as BCP about using DMARC. The sense of the room was that a working group should be formed for = these tasks. In addition, most people felt that the formation of the = working group could happen before the DMARC base specification was = approved.= From lear@cisco.com Tue Jul 30 13:29:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A759B11E8234 for ; Tue, 30 Jul 2013 13:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.589 X-Spam-Level: X-Spam-Status: No, score=-110.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 A+OJGnYMxxeB for ; Tue, 30 Jul 2013 13:29:22 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 58D4711E811E for ; Tue, 30 Jul 2013 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1539; q=dns/txt; s=iport; t=1375216162; x=1376425762; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WsSogfnxHhcA/y2M5lpBfsV8IOf83bPud129/ACIV+I=; b=bmjvWvry8DpvgskmIAoQOG0XuUAbchRkj3eQOdzayOyTz9KKXBrjXvxw C6l9CO8UU3iNOXjywqjo5JcqUsQmXp4T4kHJgyii2rKurIzQKMolE5wLT GcmXBmYvEInBbCQFj7M62A2u3rB2YPYyEMk/6C1Y4XPxZkfi+alIICSJG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPEg+FGQ/khM/2dsb2JhbABbgwaEFbwnFnSCTlUcGgIFFgsCCwMCAQIBKyANCAEBiAyYBI8AkVKBKI0OhDSBJAOXX5FMgxY6gTU X-IronPort-AV: E=Sophos;i="4.89,781,1367971200"; d="scan'208";a="16634830" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 30 Jul 2013 20:29:16 +0000 Received: from mctiny.local ([10.61.214.108]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6UKTEt6004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jul 2013 20:29:14 GMT Message-ID: <51F8221A.9030503@cisco.com> Date: Tue, 30 Jul 2013 22:29:14 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmarc@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Jul 2013 01:12:00 -0700 Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 20:29:27 -0000 FYI > Hi everyone, > > I also participated in the DMARC BOF. I will add a few points. The > room was not mobbed, but there was, I think, clear interest in the room > for the work to proceed, and that it was important. Barry asked the > question whether or not there would be more authors in the room than > just the folk who brought the spec, and the answer there was no, > although I think there were a few more hands for implementers. And > there were plenty willing to review. The charter, while requiring more > review, is generally in the ballpark. I particularly like the idea on > doing a BCP on operational practices, in as much as it would encourage > operator participation. The structure and scope of that document, > however, may need a little work. > > I do not worry so much as Andrew does over the number of working groups, > being the chair of qresync, a group that never plans to meet and hopes > to be finished by the next meeting. Moreover, I see this as an area > where we as an organization can demonstrate that we are still doing > stuff to improve the quality of email. > > I agree with Andrew that the WG should start AFTER the core spec is > done, and the core spec is not done. But it is probably close, as > Andrew wrote. Because of the above issue regarding the fact that the > group of authors is not expanding, I think it's a good idea to keep them > focused on getting the core at least past IETF last call. This also > resolves Andrew's concerns as well. > > Eliot From jtrentadams@gmail.com Wed Jul 31 04:29:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF54F21E8128 for ; Wed, 31 Jul 2013 04:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zq5Cq2EuzY4 for ; Wed, 31 Jul 2013 04:29:04 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 604DD21E8125 for ; Wed, 31 Jul 2013 04:29:03 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd6so1095273obb.33 for ; Wed, 31 Jul 2013 04:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pxjIubTo1lQln5fOqqqozb06CRxmt7vSbjNBGDypFCs=; b=RIYQbJDNDAF6eKvwfLoj44Ii4zuXp5ecZu8QDhV8L0Wz0lmMKZSC6r8zVVsu0cx7aL c/78SZ0K8K7HQp4XFthUzOcUvOoGcIvJbxgb/U25GxmyC2qMY19MlrgZboSZZJRpYOmI HEKk33JUNp76VQEl/UxbQwT40CbncERJTOo1nYnNmTd8ITLGtbNeBbLQI+DVGBN+Zifi 6xGfHZFAAKFu4HxeZx+EbY2i9llMrzGHYj6QyzUiivsLZmfgccgk1uBzHxEXy3rLlus0 VBY+yui7PecP4ppCwZpfXtyHb1YhjG8dt3Z0UWQU675ww70Q/6I04KxK6zor7Snyh9/B HjOA== MIME-Version: 1.0 X-Received: by 10.60.132.148 with SMTP id ou20mr4267531oeb.74.1375270142818; Wed, 31 Jul 2013 04:29:02 -0700 (PDT) Received: by 10.76.160.41 with HTTP; Wed, 31 Jul 2013 04:29:02 -0700 (PDT) In-Reply-To: <20130730160355.GO52723@mx1.yitter.info> References: <20130730160355.GO52723@mx1.yitter.info> Date: Wed, 31 Jul 2013 13:29:02 +0200 Message-ID: From: Trent Adams To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b47215855405c04e2cd0846 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] [ajs@anvilwalrusden.com: [IAB] IETF 87 DMARC BOF evaluation] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:29:07 -0000 --047d7b47215855405c04e2cd0846 Content-Type: text/plain; charset=ISO-8859-1 Andrew - Thank you for your constructive and useful questions and comments during the DMARC BOF in Berlin. And thank you for taking the time to share what you sent to the IAB and IESG. To be clear, though, this evaluation is more of an opinion than a full account of the BOF. I wanted to be sure everyone on this list knows that your note doesn't represent the consensus that emerged from the participants in the BOF. That's not to take away from your viewpoint, but just to say that below I've inserted some commentary that I hope will help provide a more complete picture (especially for those copied on this who weren't privy to the conversations in the BOF). To start, it should be clear that the consensus in the room (including the remote participants in the Jabber Room) was in support of the proposed Charter and associated work group items. That's not to say support was unanimous, as there were a couple of folks who indicated they preferred to defer formation, but the support went far beyond rough consensus. Hurray! And thanks to everyone who participated in the conversation. Onward: On Tue, Jul 30, 2013 at 6:03 PM, Andrew Sullivan wrote: > Dear colleagues, > > Here's the report I sent to the IESG and IAB about the DMARC BoF. I hope > this > report seems correct to you. > > Best. > A > > ----- Forwarded message from Andrew Sullivan > ----- > > Date: Tue, 30 Jul 2013 11:00:54 -0400 > From: Andrew Sullivan > To: iesg@ietf.org, iab@iab.org > Subject: [IAB] IETF 87 DMARC BOF evaluation > List-Id: "Internet Architecture Board \(IAB\)" > > Dear colleagues, > > The proposal for a DMARC WG is, in effect, to assume that a large > existing spec gets adopted on the standards track outside any WG, and > then to make a number of small changes to that existing spec in a WG. > The BoF started with quite a lot of background info about, in effect, > status of the existing work. The basic spec seems to me pretty well > worked out (I felt rather like I was listening to presentations at the > end of a WG: small issues that needed to get nailed down). But there > are little edge issues. > Something that you may have missed (though it was one of the major topics of the Agenda) was the need to develop a "Using DMARC Guide" as presented by Dave Crocker. The presentation made clear that there are a lot of interesting areas for exploration of technical choices to be made when implementing the base DMARC specification. I won't reiterate the items identified and discussed at length (they're covered within the proposed draft as well as summarized in the presentation slides). Rather, I wanted to ensure that you understood that we've been advised by a number of long-time IETF folks that the specification itself, to be useful as a long-lived Standards Track document, should not spend time discussing technical operational configuration options. Rather, they should exist in a separate document (or documents). The "Using DMARC Guide" is the first foray into that space, and it is packed with technical discussions that warrant much work. Given what you said here, it doesn't seem like it was clear that this is a primary driver for the proposed DMARC WG. Yes, I spoke about some interesting extensions that could be added to the utility of the base specification, but they were one component of the overall work for the proposed DMARC WG, but not the entire (nor primary) focus. BTW - You know this since you were in the room, but for the people who couldn't make it, there was a fantastic discussion about internationalization that was brought up on the floor as a possible work item. In fact, there were a few "+1" comments in support (with a strong suggestion that this would be worth dealing with in the "Using DMARC Guide"). > > During the proposed charter discussion, I asked a number of questions > about why to set up a WG. There's a cost to the IETF in having Yet > Another WG: we already have too much work. To the extent that this > spec is in good shape and complete, why can't the group that developed > it complete the work? > It is great to see you share that you asked this question, but it's too bad you didn't also include the answer. In the room, we replied to this excellent question (which we've been asked a number of times during this journey) that the original authors have come to a point in our deliberations where we're seeking counsel from the broader community. Since at least 2011 we've been advised that we should be openly engaging with the broader community. At that time we weren't quite ready, though we were actively heading in that direction, we just needed to tie off some loose ends. At the very earliest opportunity, we began to steer the ship into (what we hoped would be) the welcoming waters of the IETF. At the advice of many (including public calls by an Area Director), we shut down private conversations a few months ago about the technical development of the specification and moved the discussion to the public IETF list. This move means that we are essentially taking the expert advice and can't really look back now. The path is forward and open, not back and closed. > > If the problem is that there are these issues for which the consortium > that developed the specification doesn't have the expertise to solve, > then it's hard to understand why the base spec is out of scope in the > proposed charter. > The base DMARC specification is only closed insofar as expert reviewers convince Barry Leiba, as our possible AD Sponsor, that it is ready to be moved to Standards Track (extended) last call. We've heard from a number of reviewers on the list already that what remains is largely editorial (or else items that can be disposed of during the last call phase). The reason we didn't include the base specification in the proposed DMARC WG Charter is that we have been advised that it is distinctly possible that there's not enough technical work to warrant being included. We did, however, anticipate that it may be necessary to explore work on the base specification at some time in the future. If that happens during the lifetime of the DMARC WG, the proposed Charter calls out the possibility of re-chartering in order to tackle it. > > Since I heard lots of suggestions that the DMARC originators are > anxious to make the spec better, why not just put the DMARC spec on > the charter of the WG and do all the work? I very strongly agree that > this basic work is an excellent basis for continued work. But it > doesn't sound like it's done, and it seems to me therefore that the > existing running code is a 0.9 effort; the 1.0 effort needs to go > through the WG to complete. > If you haven't done so already, this seems like a fantastic opportunity for us to ask you to provide a detailed review of the specification in response to Barry's call for expert input. I'm sure your detailed analysis would be greatly appreciated as he weighs the options and decides whether he feels comfortable sponsoring the specification. > > In any case, I do see the potential for valuable work here, and it > does seem to me that the IETF is a natural place to do it since DMARC > builds on other enabling technologies created at the IETF. Indeed. It's gratifying to see the work all come together under a single umbrella rather than as scattered work. > At the > same time, I think the IESG ought to think very hard about its ability > to manage the number of WGs we already have, if the point is just to > fix things around the edges of the spec. We have far too much work to > do already. I saw significant appetite to work on this specification > in the room, though most of the people volunteering to write documents > were people who came from the existing DMARC work. > On the one hand you say, "we have far too much work to do already" and on the other hand you say "most of the people volunteering . . . came from the existing DMARC work." Couple that with the fact that we're told that we should have brought this work in earlier (to a system that apparently has little energy for more work). >From my read, that means that the IETF gets a net increase in capacity with the influx of new, energetic contributors to accomplish real, meaningful work. Further, given that there is already wide adoption of the pre-IETF specification, it also means that the IETF didn't have to expend it's paucity of resources getting us to this point. Win! In the end, the merit will win out. Either the proposed DMARC WG Charter is accepted given the technical work, knowing that there is ready-and-willing volunteers committed to the work, or not. I trust the IETF process enough to know that other issues won't cloud the judgement. For your consideration, Trent > > I am convinced, in any case, that the chartering effort is being a > little too cute about the relationship to the base spec, and I believe > that, if it is chartered on the basis of the existing proposed charter > before the base spec is published as an RFC, there will be major > procedural pain in someone's future. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > ----- End forwarded message ----- > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --047d7b47215855405c04e2cd0846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew -

Thank you for your = constructive and useful questions and comments during the DMARC BOF in Berl= in. =A0And thank you for taking the time to share what you sent to the IAB = and IESG.

To be clear, though, this evaluation is more of an opin= ion than a full account of the BOF. =A0I wanted to be sure everyone on this= list knows that your note doesn't represent the consensus that emerged= from the participants in the BOF. =A0That's not to take away from your= viewpoint, but just to say that below I've inserted some commentary th= at I hope will help provide a more complete picture (especially for those c= opied on this who weren't privy to the conversations in the BOF).

To start, it should be clear that the consensus in the = room (including the remote participants in the Jabber Room) was in support = of the proposed Charter and associated work group items. =A0That's not = to say support was unanimous, as there were a couple of folks who indicated= they preferred to defer formation, but the support went far beyond rough c= onsensus.

Hurray! And thanks to everyone who participated in the = conversation.

Onward:


On Tue, Jul 30, 2013 at 6= :03 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:=
Dear colleagues,

Here's the report I sent to the IESG and IAB about the DMARC BoF. =A0I = hope this
report seems correct to you.

Best.
A

----- Forwarded message from Andrew Sullivan <ajs@anvilwalrusden.com> -----

Date: Tue, 30 Jul 2013 11:00:54 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: iesg@ietf.org, <= a href=3D"mailto:iab@iab.org" target=3D"_blank">iab@iab.org
Subject: [IAB] IETF 87 DMARC BOF evaluation
List-Id: "Internet Architecture Board \(IAB\)" <iab.iab.org>

Dear colleagues,

The proposal for a DMARC WG is, in effect, to assume that a large
existing spec gets adopted on the standards track outside any WG, and
then to make a number of small changes to that existing spec in a WG.
The BoF started with quite a lot of background info about, in effect,
status of the existing work. =A0The basic spec seems to me pretty well
worked out (I felt rather like I was listening to presentations at the
end of a WG: small issues that needed to get nailed down). =A0But there
are little edge issues.

Something that = you may have missed (though it was one of the major topics of the Agenda) w= as the need to develop a "Using DMARC Guide" as presented by Dave= Crocker. =A0The presentation made clear that there are a lot of interestin= g areas for exploration of technical choices to be made when implementing t= he base DMARC specification.

I won't reiterate the items identified and discusse= d at length (they're covered within the proposed draft as well as summa= rized in the presentation slides). =A0Rather, I wanted to ensure that you u= nderstood that we've been advised by a number of long-time IETF folks t= hat the specification itself, to be useful as a long-lived Standards Track = document, should not spend time discussing technical operational configurat= ion options. =A0Rather, they should exist in a separate document (or docume= nts).

The "Using DMARC Guide" is the first foray in= to that space, and it is packed with technical discussions that warrant muc= h work. =A0Given what you said here, it doesn't seem like it was clear = that this is a primary driver for the proposed DMARC WG. =A0Yes, I spoke ab= out some interesting extensions that could be added to the utility of the b= ase specification, but they were one component of the overall work for the = proposed DMARC WG, but not the entire (nor primary) focus.

BTW - You know this since you were in the room, but for= the people who couldn't make it, there was a fantastic discussion abou= t internationalization that was brought up on the floor as a possible work = item. =A0In fact, there were a few "+1" comments in support (with= a strong suggestion that this would be worth dealing with in the "Usi= ng DMARC Guide").
=A0

During the proposed charter discussion, I asked a number of questions
about why to set up a WG. =A0There's a cost to the IETF in having Yet Another WG: we already have too much work. =A0To the extent that this
spec is in good shape and complete, why can't the group that developed<= br> it complete the work?

It is great to se= e you share that you asked this question, but it's too bad you didn'= ;t also include the answer. =A0In the room, we replied to this excellent qu= estion (which we've been asked a number of times during this journey) t= hat the original authors have come to a point in our deliberations where we= 're seeking counsel from the broader community.

Since at least 2011 we've been advised that we shou= ld be openly engaging with the broader community. =A0At that time we weren&= #39;t quite ready, though we were actively heading in that direction, we ju= st needed to tie off some loose ends. =A0At the very earliest opportunity, = we began to steer the ship into (what we hoped would be) the welcoming wate= rs of the IETF.

At the advice of many (including public calls by an Are= a Director), we shut down private conversations a few months ago about the = technical development of the specification and moved the discussion to the = public IETF list. =A0This move means that we are essentially taking the exp= ert advice and can't really look back now.

The path is forward and open, not back and closed.
=A0

If the problem is that there are these issues for which the consortium
that developed the specification doesn't have the expertise to solve, then it's hard to understand why the base spec is out of scope in the proposed charter.

The base DMARC specif= ication is only closed insofar as expert reviewers convince Barry Leiba, as= our possible AD Sponsor, that it is ready to be moved to Standards Track (= extended) last call. =A0We've heard from a number of reviewers on the l= ist already that what remains is largely editorial (or else items that can = be disposed of during the last call phase).

The reason we didn't include the base specification= in the proposed DMARC WG Charter is that we have been advised that it is d= istinctly possible that there's not enough technical work to warrant be= ing included.

We did, however, anticipate that it may be necessary to= explore work on the base specification at some time in the future. =A0 =A0= If that happens during the lifetime of the DMARC WG, the proposed Charter c= alls out the possibility of re-chartering in order to tackle it.
=A0

Since I heard lots of suggestions that the DMARC originators are
anxious to make the spec better, why not just put the DMARC spec on
the charter of the WG and do all the work? =A0I very strongly agree that this basic work is an excellent basis for continued work. =A0But it
doesn't sound like it's done, and it seems to me therefore that the=
existing running code is a 0.9 effort; the 1.0 effort needs to go
through the WG to complete.

If you have= n't done so already, this seems like a fantastic opportunity for us to = ask you to provide a detailed review of the specification in response to Ba= rry's call for expert input. =A0I'm sure your detailed analysis wou= ld be greatly appreciated as he weighs the options and decides whether he f= eels comfortable sponsoring the specification.
=A0

In any case, I do see the potential for valuable work here, and it
does seem to me that the IETF is a natural place to do it since DMARC
builds on other enabling technologies created at the IETF. =A0
=

Indeed. =A0It's gratifying to see the work all come= together under a single umbrella rather than as scattered work.

=A0
At the
same time, I think the IESG ought to think very hard about its ability
to manage the number of WGs we already have, if the point is just to
fix things around the edges of the spec. =A0We have far too much work to do already. =A0I saw significant appetite to work on this specification
in the room, though most of the people volunteering to write documents
were people who came from the existing DMARC work.
On the one hand you say, "we have far too much work to do = already" and on the other hand you say "most of the people volunt= eering . . . came from the existing DMARC work." =A0Couple that with t= he fact that we're told that we should have brought this work in earlie= r (to a system that apparently has little energy for more work).

From my read, that means that the IETF gets a net incre= ase in capacity with the influx of new, energetic contributors to accomplis= h real, meaningful work. =A0Further, given that there is already wide adopt= ion of the pre-IETF specification, it also means that the IETF didn't h= ave to expend it's paucity of resources getting us to this point. =A0Wi= n!

In the end, the merit will win out. =A0Either the propo= sed DMARC WG Charter is accepted given the technical work, knowing that the= re is ready-and-willing volunteers committed to the work, or not. =A0I trus= t the IETF process enough to know that other issues won't cloud the jud= gement.

For your consideration,
Trent

<= /div>

=A0

I am convinced, in any case, that the chartering effort is being a
little too cute about the relationship to the base spec, and I believe
that, if it is chartered on the basis of the existing proposed charter
before the base spec is published as an RFC, there will be major
procedural pain in someone's future.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

----- End forwarded message -----

--
Andrew Sullivan
ajs@anvilwalrus= den.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc



-- J. Trent Adams
=3Djtrentadams

Profile: http://www.mediaslate.org/jtre= ntadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http:= //twitter.com/jtrentadams
--047d7b47215855405c04e2cd0846-- From jtrentadams@gmail.com Wed Jul 31 04:42:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545C821F9D90 for ; Wed, 31 Jul 2013 04:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H6xKHfk4Zem for ; Wed, 31 Jul 2013 04:42:29 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id B0FBF11E8171 for ; Wed, 31 Jul 2013 04:42:22 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so1261163oag.10 for ; Wed, 31 Jul 2013 04:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kN9FOIdCWHfon5/fOpZFfFFqtVNNCo+iHVDvLL5oqhM=; b=XM42yORTLa0D8GlNDRKI0SPmGITTh9Au6cOHvAHEFtAiaXoXr/JspxseDbnMOIie/P rDhrLQ2wpemEqjFMJlukjNmoja0EkVgxhH3PsSztANLZVX7NQqSzNl9oXsKeaYS9169t +Uuz2DxN5D7WBnds5RAogAviPdbLOk1pqQdjIDD2QMTAAnjsC13GuAbnKLcJjGCLAgXP D2VJp66PP+8s9f9kyL8yIBEr1HJ9Yk9YsjbI75qA0zA2v8GQue9rdmGy+jS4u5FXwoEl 5/nmBZ0cTqHSjYNEMx8Lx+pg9SZWcmM7Xlm05Cjx1vQyyzRE6ghaA/ko/s3pbAthOSHE fHmg== MIME-Version: 1.0 X-Received: by 10.60.79.3 with SMTP id f3mr66767008oex.50.1375270940609; Wed, 31 Jul 2013 04:42:20 -0700 (PDT) Received: by 10.76.160.41 with HTTP; Wed, 31 Jul 2013 04:42:20 -0700 (PDT) In-Reply-To: <51F8221A.9030503@cisco.com> References: <51F8221A.9030503@cisco.com> Date: Wed, 31 Jul 2013 13:42:20 +0200 Message-ID: From: Trent Adams To: Eliot Lear Content-Type: multipart/alternative; boundary=089e0117795be294d204e2cd3706 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:42:32 -0000 --089e0117795be294d204e2cd3706 Content-Type: text/plain; charset=ISO-8859-1 Eliot - Many thanks for sharing your note. And thanks for your interventions in the BOF (to borrow a term from OECD deliberations). Your input is clearly well-considered and valuable. Just as a point of clarification: On Tue, Jul 30, 2013 at 10:29 PM, Eliot Lear wrote: > > FYI > > Hi everyone, > > > > I also participated in the DMARC BOF. I will add a few points. The > > room was not mobbed, but there was, I think, clear interest in the room > > for the work to proceed, and that it was important. Barry asked the > > question whether or not there would be more authors in the room than > > just the folk who brought the spec, and the answer there was no, > > although I think there were a few more hands for implementers. And > > there were plenty willing to review. The charter, while requiring more > > review, is generally in the ballpark. I particularly like the idea on > > doing a BCP on operational practices, in as much as it would encourage > > operator participation. The structure and scope of that document, > > however, may need a little work. > > > > I do not worry so much as Andrew does over the number of working groups, > > being the chair of qresync, a group that never plans to meet and hopes > > to be finished by the next meeting. Moreover, I see this as an area > > where we as an organization can demonstrate that we are still doing > > stuff to improve the quality of email. > > > > I agree with Andrew that the WG should start AFTER the core spec is > > done, and the core spec is not done. But it is probably close, as > > Andrew wrote. Because of the above issue regarding the fact that the > > group of authors is not expanding, I think it's a good idea to keep them > > focused on getting the core at least past IETF last call. It's probably not clear, but the set of authors who would work on the items identified in the proposed DMARC WG Charter are not the same set as those who would work on the specification itself. There is some overlap, but the items could easily be handled in parallel rather than in series. > This also > > resolves Andrew's concerns as well. > That's an interesting strategic point on it's own worth considering. BTW - Who ultimately decides if a Charter is approved and the WG formed? Now that there was clear consensus in the room for the proposed DMARC WG Charter, and we identified volunteers to work on the identified work items, what's next? And beyond who is making the decision, by what criteria will the decision be made? Now that we've cleared the first hurdle of the BOF, I'm just wondering what the next obstacle is. . . or is it just a waiting game now as we await the results of the deliberations? Thanks again, Trent > > > > Eliot > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- J. Trent Adams =jtrentadams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams --089e0117795be294d204e2cd3706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Eliot -

Many thanks for sharing y= our note. =A0And thanks for your interventions in the BOF (to borrow a term= from OECD deliberations). =A0Your input is clearly well-considered and val= uable.

Just as a p= oint of clarification:

On Tue, Jul 30, 20= 13 at 10:29 PM, Eliot Lear <lear@cisco.com> wrote:

FYI
> Hi everyone,
>
> I also participated in the DMARC BOF. =A0I will add a few points. =A0T= he
> room was not mobbed, but there was, I think, clear interest in the roo= m
> for the work to proceed, and that it was important. =A0Barry asked the=
> question whether or not there would be more authors in the room than > just the folk who brought the spec, and the answer there was no,
> although I think there were a few more hands for implementers. =A0And<= br> > there were plenty willing to review. =A0The charter, while requiring m= ore
> review, is generally in the ballpark. =A0I particularly like the idea = on
> doing a BCP on operational practices, in as much as it would encourage=
> operator participation. =A0The structure and scope of that document, > however, may need a little work.
>
> I do not worry so much as Andrew does over the number of working group= s,
> being the chair of qresync, a group that never plans to meet and hopes=
> to be finished by the next meeting. =A0Moreover, I see this as an area=
> where we as an organization can demonstrate that we are still doing > stuff to improve the quality of email.
>
> I agree with Andrew that the WG should start AFTER the core spec is > done, and the core spec is not done. =A0But it is probably close, as > Andrew wrote. =A0Because of the above issue regarding the fact that th= e
> group of authors is not expanding, I think it's a good idea to kee= p them
> focused on getting the core at least past IETF last call.
=

It's probably not clear, but the set of authors who= would work on the items identified in the proposed DMARC WG Charter are no= t the same set as those who would work on the specification itself. =A0Ther= e is some overlap, but the items could easily be handled in parallel rather= than in series.
=A0
=A0This also
> resolves Andrew's concerns as well.

That's an interesting strategic point on it's own worth consi= dering.

BTW - Who ultimately decides if a Charter = is approved and the WG formed? =A0Now that there was clear consensus in the= room for the proposed DMARC WG Charter, and we identified volunteers to wo= rk on the identified work items, what's next?

And beyond who is making the decision, by what criteria= will the decision be made? =A0Now that we've cleared the first hurdle = of the BOF, I'm just wondering what the next obstacle is. . . or is it = just a waiting game now as we await the results of the deliberations?

Thanks again,
Trent

=A0
>
> Eliot
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc



--
J. Trent Ada= ms
=3Djtrentadams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtr= entadams
Twitter: http://twitter.com/jtre= ntadams
--089e0117795be294d204e2cd3706-- From ajs@anvilwalrusden.com Wed Jul 31 04:44:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAAA21E8083 for ; Wed, 31 Jul 2013 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbETAVeyEtda for ; Wed, 31 Jul 2013 04:43:59 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D862221E812D for ; Wed, 31 Jul 2013 04:43:58 -0700 (PDT) Received: from mx1.yitter.info (dhcp-650a.meeting.ietf.org [130.129.101.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 04C1F8A031 for ; Wed, 31 Jul 2013 11:43:57 +0000 (UTC) Date: Wed, 31 Jul 2013 07:44:03 -0400 From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20130731114402.GD56061@mx1.yitter.info> References: <20130730160355.GO52723@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dmarc-ietf] [ajs@anvilwalrusden.com: [IAB] IETF 87 DMARC BOF evaluation] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:44:04 -0000 On Wed, Jul 31, 2013 at 01:29:02PM +0200, Trent Adams wrote: > To be clear, though, this evaluation is more of an opinion than a full > account of the BOF. Totally correct. The note I sent is a report from an IAB member "covering" a BoF. The point of this is for the IAB member to raise questions, issues, views, and so on _from that IAB member's point of view_ for the IESG to consider. The BoF report is prepared by the Chair(s) and is supposed to discuss what consensus emerged and so on. And yes, it's just one view. The IESG knows that, and is as likely as not to discount any view that comes from me, if they're sane. :-) In any case, yes, my remarks are _not_ a complete view of what the exchanges were. They're really intended to raise issues/concerns/&c. I try to keep them as short as possible because the IESG has to read all of these, sometimes from multiple IAB members, for each BoF. I do sometimes sacrifice completeness to brevity and timliness in that case, and I do not wish anyone to think that I wasn't listening to the important details you've correctly filled in. And you're quite right that an influx of people who come and want to do work here -- particularly operators -- makes me quite happy. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dcrocker@gmail.com Wed Jul 31 05:24:34 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57AF21F9E45 for ; Wed, 31 Jul 2013 05:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqvAnS9ao7Zk for ; Wed, 31 Jul 2013 05:24:31 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DB89321F9DCA for ; Wed, 31 Jul 2013 05:24:28 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so216897bkc.41 for ; Wed, 31 Jul 2013 05:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5qVP4/TCwCQaNyO9sXyPkBDP2hvqZ52DtrM9C4No6xg=; b=XsMVpnetBUOwSvFmXkwvV8G7Watn7X22NHSCOFU9yBVvIz/3AW01U01kztcjiQzG+Y j+6503iug+sMPAkcY7X89B0I64dNybrCXSBcy+EQ/TVDZRro//NtOAgbX0eilnMjZDAZ IpGKsUOuncGX9jbt778KtNq5hAUmtnrBm+9wioPwvla8EmYChLGp0gYtxY8KGPAqpO2f 3ktRW3N6uvJetVMeOfyKKyCv6DGPxESFe89tfCgkA3zMHzKQ+HRE2UFVQX3sKTHRnvb/ yjT1RL5i9EYzGHU2P9x09TyR10eLmfMFYGn2Sn8rqd/foMB/8mYjlg6e2znZJyU4x++0 xMkw== X-Received: by 10.205.113.205 with SMTP id ex13mr9844308bkc.104.1375273467821; Wed, 31 Jul 2013 05:24:27 -0700 (PDT) Received: from [192.168.1.203] (e178124165.adsl.alicedsl.de. [85.178.124.165]) by mx.google.com with ESMTPSA id ps10sm450430bkb.14.2013.07.31.05.24.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 05:24:27 -0700 (PDT) Message-ID: <51F901F6.2080302@gmail.com> Date: Wed, 31 Jul 2013 14:24:22 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Sullivan References: <20130730160355.GO52723@mx1.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, Eliot Lear Subject: Re: [dmarc-ietf] [ajs@anvilwalrusden.com: [IAB] IETF 87 DMARC BOF evaluation] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:24:34 -0000 My own .02e: Because we are trying to navigate things in an unusual way, we have an especially challenging obligation to be precise in what we ask for, how we ask for it, and how we explain things. In spite of our efforts to do all that, I think some confusion persists. Yours and Eliot's comments are entirely reasonable, IMO. As you'll see, I disagree with an essential point about the charter, but it's exactly the one that would be expected, both as a point to be raised (by you guys) and as a disagreement from anyone in favor of what's been proposed. So... { caveat: I think my 'reply' mechanism or my reading has confused Andrew text with Trent text. So I'm responding to the text segments, without worrying who typed them. } > On Tue, Jul 30, 2013 at 6:03 PM, Andrew Sullivan > wrote: > The "Using DMARC Guide" is the first foray into that space, and it is > packed with technical discussions that warrant much work. Given what > you said here, it doesn't seem like it was clear that this is a primary > driver for the proposed DMARC WG. Yes, I spoke about some interesting > extensions that could be added to the utility of the base specification, > but they were one component of the overall work for the proposed DMARC > WG, but not the entire (nor primary) focus. That matches my own view of things... > BTW - You know this since you were in the room, but for the people who > couldn't make it, there was a fantastic discussion about > internationalization that was brought up on the floor as a possible work > item. In fact, there were a few "+1" comments in support (with a strong > suggestion that this would be worth dealing with in the "Using DMARC > Guide"). The problem with that process was that it had no actual substance. The topic is always an important one and it is often underserved, if served at all. But its application to the DMARC spec was entirely ad hoc, partly in the way concerns were raised or asserted, and partly in how they were processed. I see two key points, concerning the base spec: 1) The document does have an 'internationalization' bit of text; whether it's enough I can't answer. 2) We need to have qualified folk do an audit of the spec for this; if they come up with /specific/ required changes, then of course we have to do them. Only after #2 has occurred and produce a targeted requirement will there be a basis for saying that the base spec needs internationalization work. As for the draft BCP and adding internationalization discussion -- well, heck yeah. > During the proposed charter discussion, I asked a number of questions > about why to set up a WG. There's a cost to the IETF in having Yet > Another WG: we already have too much work. To the extent that this > spec is in good shape and complete, why can't the group that developed > it complete the work? > > It is great to see you share that you asked this question, but it's too > bad you didn't also include the answer. The problem with the question is that it was asked in an ad hoc manner, but is instead a strategic, global topic for the entire IETF organization. We do need to deal with it but we have no meaningful discussion base in the IETF -- and have in fact repeatedly resisted constructive discussion about it for perhaps 20 years -- and no metrics or even any shared frame of reference. This reduces the question to an ad hoc challenge to "say random stuff that sounds compelling", which might make for good theater but isn't a serious evaluation process. The simple fact is that dmarc is a topic relevant to the scope of IETF work, with people who want to pursue it and some basis for believing useful work can be done. If we have a more stringent evaluation metric for new working groups, please point us at it. > The base DMARC specification is only closed insofar as expert reviewers > convince Barry Leiba, as our possible AD Sponsor, that it is ready to be > moved to Standards Track (extended) last call. This is an absolutely key point (and nicely phrased, I might add.) > The reason we didn't include the base specification in the proposed > DMARC WG Charter is that we have been advised that it is distinctly > possible that there's not enough technical work to warrant being included. This needs to be stated more affirmatively: After multiple queries on two public lists, there have been no requests for technical changes to the base specification that have developed any traction. If and when that changes, the path for the base spec will (of course) be re-evaluated. > We did, however, anticipate that it may be necessary to explore work on > the base specification at some time in the future. If that happens > during the lifetime of the DMARC WG, the proposed Charter calls out the > possibility of re-chartering in order to tackle it. +1 > > Since I heard lots of suggestions that the DMARC originators are > anxious to make the spec better, why not just put the DMARC spec on > the charter of the WG and do all the work? I very strongly agree that > this basic work is an excellent basis for continued work. But it > doesn't sound like it's done, and it seems to me therefore that the > existing running code is a 0.9 effort; the 1.0 effort needs to go > through the WG to complete. If it doesn't sound like it's done, then we not have phrased things properly. To date, we have no evidence that the base spec needs technical changes. We now have John Levine asserting that some such work does need doing; if it's evaluated as indeed needing it, it will indeed be added to the charter (assuming the fixes can't be done instantly.) Absent that, it does not make sense charter a wg to work on a spec when there is no technical work known to be needed on it. One point of confusion concerns the various discussions of /possible/ extensions, including those cited in the draft charter. For one thing, we don't know whether they will be productive. For another, we don't expect them to affect the base. If it is evaluated that any of them /do/ affect the base, then the work will indeed be added to the wg. Absent such specifics, adding it to the wg charter is only an invitation to de-stabilize the spec. In separate conversations with others, I've noted an occasional lack of sensitivities to market perceptions of specification stability. The reality is that the market sees a spec going into a working group as a very strong argument against using the spec now. After all, it's going to change and we don't know when it will stop changing. This can have a very serious effect on market adoption momentum. > If you haven't done so already, this seems like a fantastic opportunity > for us to ask you to provide a detailed review of the specification in > response to Barry's call for expert input. +1 > At the > same time, I think the IESG ought to think very hard about its ability > to manage the number of WGs we already have, if the point is just to > fix things around the edges of the spec. Sure it should. In a careful, principled and equitable fashion... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Wed Jul 31 07:37:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144ED21E8123 for ; Wed, 31 Jul 2013 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 jEgRq-FycPcn for ; Wed, 31 Jul 2013 07:37:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8216521E80CA for ; Wed, 31 Jul 2013 07:37:29 -0700 (PDT) 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 r6VEbANJ002386; Wed, 31 Jul 2013 07:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1375281435; bh=A/gq9UQcQMvuEWpfanuWDW6RH4MEteW+E0myFNtwE/g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k7p/5dQvM92uO8ih9Vfy5VcJjanuSDTIbNgUkQYYQtEelyHurc+nwdqB0T+64cnox HwjDfw7pVhx2tQba9LapRVvs9LXRAmXE5jUasi/G0rNRhkB7DvD5tijHZgj6Pall7H zluWykfp1gjdaPLYuwKzjcwSJSMQat1JNzQpxato= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1375281435; i=@resistor.net; bh=A/gq9UQcQMvuEWpfanuWDW6RH4MEteW+E0myFNtwE/g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ar9gFEYVry+XyL22IRhZIRBatCRUDLZAOZeACJGaRvuPCLcq3DNwgL6L7TDRE94gN HkZKQouM/sWusSUizxavgBP+P+6sFx9EhYQ6MV37W4tTHpxjiGrovyXPW5azYpPN3p 65NYxoyddNikZxQDSUmFF7OnsQzQOK5Br121jjuI= Message-Id: <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 31 Jul 2013 07:29:10 -0700 To: Trent Adams , Eliot Lear From: SM In-Reply-To: References: <51F8221A.9030503@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:37:33 -0000 At 04:42 31-07-2013, Trent Adams wrote: >It's probably not clear, but the set of authors who would work on >the items identified in the proposed DMARC WG Charter are not the >same set as those who would work on the specification itself. There >is some overlap, but the items could easily be handled in parallel >rather than in series. Andrew and Eliot posted their IAB messages to this mailing list. This is not usually done or required. It's a nice initiative. In my individual opinion it would be better to have the new WG formed after the core specifications is done (see Andrew's and Eliot's comments). There is an unrelated review by Martin Thomson at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10132.html Some of his comments were: "I have reviewed the mailing list feedback, and it's not clear to me that there is consensus to publish this." "The fact that this work isn't a product of a working group still concerns me. I'm actually interested in why this is AD-sponsored rather than a working group product." The agreement of this mailing list does not have any formal standing (re. first quoted paragraph). If the WG is created while there is a working group the second quoted paragraph might be applicable. Regards, -sm From lear@cisco.com Wed Jul 31 06:25:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9067511E8191 for ; Wed, 31 Jul 2013 06:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.436 X-Spam-Level: X-Spam-Status: No, score=-109.436 tagged_above=-999 required=5 tests=[AWL=1.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 laxuTEraAMy8 for ; Wed, 31 Jul 2013 06:25:11 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D274B11E8171 for ; Wed, 31 Jul 2013 06:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5803; q=dns/txt; s=iport; t=1375277111; x=1376486711; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=rkXLDYloTfVHm41rAGC1V6hhwXQWrRA01p1HOr2ZiuM=; b=MznmSDgw14wsb53rIO9PFe32U759cQiSC68xtyuT5sDrHNMWHnVTBjmL eGmsseAl6nLJP32nAWlWw8IRunChIxQIiwbyxngfZmMjCarUopO7+KjsT 2jV2GNq8NDrNvP0HE2wydj+N3Pnnvrs3B8CC6e999VxAWb7N+WFp4DSQU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAMMP+VGQ/khM/2dsb2JhbABbgwaEFYVdtTCBGBZ0giQBAQEDASNVAQULCw4TFgsCAgkDAgECASsaBg0BBwEBiAYGpxyRUpAHB4JlgSYDlAiDV5FNgxY6 X-IronPort-AV: E=Sophos;i="4.89,729,1367971200"; d="scan'208,217";a="16185473" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 31 Jul 2013 13:25:10 +0000 Received: from mctiny.local ([10.61.196.104]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6VDP7KM020510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 13:25:07 GMT Message-ID: <51F91033.1060202@cisco.com> Date: Wed, 31 Jul 2013 15:25:07 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trent Adams References: <51F8221A.9030503@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------010904000600030807000305" X-Mailman-Approved-At: Wed, 31 Jul 2013 07:39:47 -0700 Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:25:16 -0000 This is a multi-part message in MIME format. --------------010904000600030807000305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Trent, Thanks for your comments. Answering you and Dave in one note: On 7/31/13 1:42 PM, Trent Adams wrote: > It's probably not clear, but the set of authors who would work on the > items identified in the proposed DMARC WG Charter are not the same set > as those who would work on the specification itself. There is some > overlap, but the items could easily be handled in parallel rather than > in series. Color me paranoid, but we said in the room that there was a need to close the base spec, and focus should be there now, even if there is no working group. People need to have their attention there. If, as Dave claims, the job is done, then this will be weeks, not months. If there are serious issues, then we'd better fix them. When it comes to internationalization, a good review from a person who is competent with EAI seems in order to figure out if DMARC clears the mark. While -01 is considerably better than -00, I need to do a full review as well. > > > This also > > resolves Andrew's concerns as well. > > > That's an interesting strategic point on it's own worth considering. > > BTW - Who ultimately decides if a Charter is approved and the WG > formed? Now that there was clear consensus in the room for the > proposed DMARC WG Charter, and we identified volunteers to work on the > identified work items, what's next? The IESG approves new working groups or changes to charters. Barry can comment further. > > And beyond who is making the decision, by what criteria will the > decision be made? Now that we've cleared the first hurdle of the BOF, > I'm just wondering what the next obstacle is. . . or is it just a > waiting game now as we await the results of the deliberations? > I'll leave this to Barry as well. Eliot --------------010904000600030807000305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Trent,

Thanks for your comments.  Answering you and Dave in one note:

On 7/31/13 1:42 PM, Trent Adams wrote:

It's probably not clear, but the set of authors who would work on the items identified in the proposed DMARC WG Charter are not the same set as those who would work on the specification itself.  There is some overlap, but the items could easily be handled in parallel rather than in series.

Color me paranoid, but we said in the room that there was a need to close the base spec, and focus should be there now, even if there is no working group.  People need to have their attention there.  If, as Dave claims, the job is done, then this will be weeks, not months.  If there are serious issues, then we'd better fix them.  When it comes to internationalization, a good review from a person who is competent with EAI seems in order to figure out if DMARC clears the mark.  While -01 is considerably better than -00, I need to do a full review as well.

 
 This also
> resolves Andrew's concerns as well.

That's an interesting strategic point on it's own worth considering.

BTW - Who ultimately decides if a Charter is approved and the WG formed?  Now that there was clear consensus in the room for the proposed DMARC WG Charter, and we identified volunteers to work on the identified work items, what's next?

The IESG approves new working groups or changes to charters.  Barry can comment further.


And beyond who is making the decision, by what criteria will the decision be made?  Now that we've cleared the first hurdle of the BOF, I'm just wondering what the next obstacle is. . . or is it just a waiting game now as we await the results of the deliberations?


I'll leave this to Barry as well.

Eliot
--------------010904000600030807000305-- From dcrocker@gmail.com Wed Jul 31 07:44:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A53C21F9E94 for ; Wed, 31 Jul 2013 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg6vWqnVHhR1 for ; Wed, 31 Jul 2013 07:44:34 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D3D3511E81A9 for ; Wed, 31 Jul 2013 07:44:20 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id 6so279508bkj.5 for ; Wed, 31 Jul 2013 07:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xUAUkRevCeTJsU4N4eMZY2YG4Wa4Gp5Ic9ntXaSGjww=; b=eJIxsfd+KgbkraLQG430Tb9iGJP5Pn63fE8Dk9C6faujo1xVVfTSerVGSWy6Bi0Qbl Xo2zs8EBfQHIv0oHlv2d0r7WsHNYMTxHMTzgbnEs11OO6aPHuTBP4OWLEG+V1zgrCf1D oGoY0LEpElQoXF0M/LT5roZKK9+ipEiV20b1CszJn0dvX6SpCIB7XW4QGx4KtkuEKJ/5 SQDYM2zNAxcxminkslNTSU8SW89TMVUJgk3V8WEZLyjlASZAynh7/6vKK8FiZd/5bmIJ eGNqboTtLfo6KsLGb+uvn7Mz+6Bn5guU+2jhGd46etUd5btMn37vkxdImLLCMuUjSj3O NdWw== X-Received: by 10.204.233.14 with SMTP id jw14mr4958068bkb.159.1375281859880; Wed, 31 Jul 2013 07:44:19 -0700 (PDT) Received: from [192.168.1.203] (e178124165.adsl.alicedsl.de. [85.178.124.165]) by mx.google.com with ESMTPSA id ps10sm630987bkb.14.2013.07.31.07.44.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 07:44:19 -0700 (PDT) Message-ID: <51F922BE.7040800@gmail.com> Date: Wed, 31 Jul 2013 16:44:14 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eliot Lear References: <51F8221A.9030503@cisco.com> <51F91033.1060202@cisco.com> In-Reply-To: <51F91033.1060202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , Trent Adams , Barry Leiba Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:44:35 -0000 On 7/31/2013 3:25 PM, Eliot Lear wrote: > Color me paranoid, but we said in the room that there was a need to > close the base spec, and focus should be there now, even if there is no > working group. People need to have their attention there. If, as Dave > claims, the job is done, then this will be weeks, not months. If there > are serious issues, then we'd better fix them. FWIW, I meant to entirely avoid commenting on the suggestion that the base be fully processed before chartering the wg. Apologies if I didn't succeed in that, but to be clear: I'm not expressing an opinion on that procedural suggestion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From franck@peachymango.org Wed Jul 31 08:03:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96BC21F9C99 for ; Wed, 31 Jul 2013 08:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN9Rg7Dd2gh7 for ; Wed, 31 Jul 2013 08:03:39 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 244E521F9B31 for ; Wed, 31 Jul 2013 08:03:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A34502940D9; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFvAXjk-6wFM; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 856D5294096; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6F3AE2940DA; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8ZRokKUlTyxs; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 2D5F42940D9; Wed, 31 Jul 2013 10:03:37 -0500 (CDT) Date: Wed, 31 Jul 2013 10:03:36 -0500 (CDT) From: Franck Martin To: SM Message-ID: <1979667371.14034.1375283016507.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <51F8221A.9030503@cisco.com> <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: IETF 87 DMARC BOF evaluation Thread-Index: WcTsFew7GBDgTtbF62g6vsYTFIEPmw== Cc: dmarc@ietf.org, Trent Adams , Eliot Lear Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:03:44 -0000 ----- Original Message ----- > From: "SM" > To: "Trent Adams" , "Eliot Lear" > Cc: dmarc@ietf.org > Sent: Wednesday, July 31, 2013 4:29:10 PM > Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation > > At 04:42 31-07-2013, Trent Adams wrote: > >It's probably not clear, but the set of authors who would work on > >the items identified in the proposed DMARC WG Charter are not the > >same set as those who would work on the specification itself. There > >is some overlap, but the items could easily be handled in parallel > >rather than in series. > > Andrew and Eliot posted their IAB messages to this mailing > list. This is not usually done or required. It's a nice initiative. Indeed it is nice, but in the APPS discussion early this week it was encouraged more transparency in relations to IAB and IESG with the authors. So I guess we are experimenting here this new direction. > > In my individual opinion it would be better to have the new WG formed > after the core specifications is done (see Andrew's and Eliot's > comments). There is an unrelated review by Martin Thomson at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10132.html > Some of his comments were: > > "I have reviewed the mailing list feedback, and it's not clear > to me that there is consensus to publish this." Seems to me the vote and mailing list indicates that the spec is suitable to move forward provided a few more reviews and comments are addressed, i.e. not really the work of a working group. Of course, If something substantial appears, then a WG will be indeed needed. > > "The fact that this work isn't a product of a working group > still concerns me. I'm actually interested in why this is > AD-sponsored rather than a working group product." > > The agreement of this mailing list does not have any formal standing > (re. first quoted paragraph). Email operators are coming back to IETF, so I guess we are learning on the way the IETF Fu... I however would suggest it does not matter if anyone was involved or not in the work before the spec came to IETF. I find the method of bringing comments from another list into this list, as if they were the result of an analysis of this list, hmmm, strange.... I think the best course of action here is to review -01. From ajs@anvilwalrusden.com Wed Jul 31 08:57:48 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104B321F9CB1 for ; Wed, 31 Jul 2013 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvrjkjj4aDpA for ; Wed, 31 Jul 2013 08:57:42 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 42DE721F97E6 for ; Wed, 31 Jul 2013 08:57:42 -0700 (PDT) Received: from mx1.yitter.info (dhcp-650a.meeting.ietf.org [130.129.101.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 659DD8A031 for ; Wed, 31 Jul 2013 15:57:41 +0000 (UTC) Date: Wed, 31 Jul 2013 11:57:42 -0400 From: Andrew Sullivan To: dmarc@ietf.org Message-ID: <20130731155741.GA56454@mx1.yitter.info> References: <51F8221A.9030503@cisco.com> <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dmarc-ietf] Copying IAB remarks (was: [IAB] IETF 87 DMARC BOF evaluation) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:57:48 -0000 On Wed, Jul 31, 2013 at 07:29:10AM -0700, SM wrote: > Andrew and Eliot posted their IAB messages to this mailing list. > This is not usually done or required. It's a nice initiative. Just to be clear, we did this because the responsible AD asked us to, and because I had no reason not to do. There are certainly cases where I would wish to give confidential advice to the IESG, and I don't think it would be appropriate under those circumstances to post the remarks. Also, as we can see from the subsequent threads, the follow-on discussion suggests that people are made anxious by these reports, partly because they tend to be pretty terse, leaving out all sorts of subtleties. (If an AD thought something was being missed, I assure you s/he'd ask.) That's important because as I understand it the IESG is looking for a broad picture from the IAB, not a lot of in depth review. They don't have time to read an in depth thing. So I'm actually not sure that this is a good long-term plan. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba@gmail.com Wed Jul 31 07:44:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7730D21F9E3B for ; Wed, 31 Jul 2013 07:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 0nGgwn0qYLXP for ; Wed, 31 Jul 2013 07:44:23 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 075FD11E81AC for ; Wed, 31 Jul 2013 07:44:11 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id f6so421332qej.12 for ; Wed, 31 Jul 2013 07:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YVI4awlrW9AYmM3RWaaQdPrZUj3bEodpc/LKRtvPuLA=; b=O6rAV4DaV8+RPrwsKL5fZ/WM+/1iDzM6x1sRs+sFGppZ9bZ6TBA1blVce6+/Q37vLc i877K+uEDhUbou7ZiHyoC/DZvFcB4cU98IlLbqSburGeUIPh+6MWDcYJrhQvmMNZbsMU rkyRtRXDsudreWdJ9e/o0PwcQhAvpVTMM6pKBoK9JTo2tbTWOiGcuLeonQv0L0amIhA5 xXgSoM7MTP3W4c5xkUDzjR48e+6YeGxdH7InMSLlk24RTbqAaPEMpNteNUdwCbBrmKYG KFY3pNESKvD1YjYomNpK2YR7rXVISEChyunYVimBdmaju4xumF+MostwugoFwZiJiKNy wD6g== MIME-Version: 1.0 X-Received: by 10.229.160.133 with SMTP id n5mr11330166qcx.98.1375281851366; Wed, 31 Jul 2013 07:44:11 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Wed, 31 Jul 2013 07:44:11 -0700 (PDT) In-Reply-To: <51F91033.1060202@cisco.com> References: <51F8221A.9030503@cisco.com> <51F91033.1060202@cisco.com> Date: Wed, 31 Jul 2013 10:44:11 -0400 X-Google-Sender-Auth: 2pUTMkLG5ly2Zbdyn1UgQS3SVKI Message-ID: From: Barry Leiba To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 31 Jul 2013 09:00:58 -0700 Cc: "dmarc@ietf.org" , Trent Adams Subject: Re: [dmarc-ietf] [IAB] IETF 87 DMARC BOF evaluation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:44:24 -0000 > Color me paranoid, but we said in the room that there was a need to close > the base spec, and focus should be there now, even if there is no working > group. People need to have their attention there. If, as Dave claims, the > job is done, then this will be weeks, not months. If there are serious > issues, then we'd better fix them. When it comes to internationalization, a > good review from a person who is competent with EAI seems in order to figure > out if DMARC clears the mark. While -01 is considerably better than -00, I > need to do a full review as well. There will definitely be at least one review targeted at Internationalization, to determine whether things look OK... or whether there are real Internationalization issues that need to be resolved. As Eliot says, it's likely that the base document could be sent for IETF Last Call in a relatively short time -- I would actually put it in months, but a small number of months (say, two-ish). And, in fact, I see no burning need to get a charter approved in a hurry. There's a mailing list and a charter proposal. The proposed work can begin informally at any time. Because of that, and because there are a few valid concerns about chartering a working group to do follow-on work on a specification that's not final, I think the best approach will be to hold the formal chartering process until the base spec is approved for publication (though with no need to wait for the RFC to actually come out). That need cause no significant delay, and will allay fears expressed by a few people (including some on the IESG and IAB). > BTW - Who ultimately decides if a Charter is approved and the WG formed? > Now that there was clear consensus in the room for the proposed DMARC WG > Charter, and we identified volunteers to work on the identified work items, > what's next? What's next is that I start the chartering process. When this mailing list is happy with the charter text, I can start that off in what we call "IESG Informal Review". That will allow anyone to review it, but doesn't start anything formal. When it's time for formal review, I change the state to "Internal Review", and the IESG and IAB have at it. When it's approved at that stage, an announcement goes out to the community (to ietf-announce) and to other SDOs (through the new-work mailing list), asking for comment, and the state is changed to External Review. Usually two weeks later it's up for final approval by the IESG (with the state changing to IESG Evaluation in the middle), and, if all goes well, it gets approved. The time from when Internal Review begins and when final approval happens is usually on the order of three or four weeks, though it can vary. > And beyond who is making the decision, by what criteria will the decision be > made? That's hard to say: Usually in the Internal Review stage, ADs can make all sorts of comments and raise all sorts of issues. We'll just have to see how that goes. External Review doesn't usually result in any further blocking points, though it's possible. Barry, Applications AD From barryleiba.mailing.lists@gmail.com Wed Jul 31 10:23:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB621F9A30 for ; Wed, 31 Jul 2013 10:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 aSl5qhcsyRYo for ; Wed, 31 Jul 2013 10:23:48 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 20AAF11E8186 for ; Wed, 31 Jul 2013 10:23:27 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so1006975vbg.25 for ; Wed, 31 Jul 2013 10:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=64MqmNKITJY0Pl4BJXfvQ0EZ/BUKUXSYHuZ8nPtjE4k=; b=iD7uvPzr3kttSRPJ4KLuEDdrpvRyNkN/I8L3JEWy9tdCneYhObQuV8eishVsfFM14o /NW6T5dDmy36iq1VYg/uhQTJyfz3hn1vHtPSeJrJ10IN5RNhoHZgk/9Ie3//q/t2Nmde YikrL3liB858o2OnoSw599CJyTLVEEK7uTB/pxvhLDrDcof1uHsH1/Ch+Lwzd6lXcaj/ ixa8pIdTfAygn6GBeljZzO87S9cz237jTKV3RRWtThaQUghpx6lE/AUWAwRCERpcT63M hNRqQhzyXjGkkVB6cqUlKH5moBNN3VdKzx7X45eB+3+VwZvtVunOi6GBx8RL/bf6A1io gCKQ== MIME-Version: 1.0 X-Received: by 10.52.109.69 with SMTP id hq5mr10844749vdb.85.1375291402890; Wed, 31 Jul 2013 10:23:22 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Wed, 31 Jul 2013 10:23:22 -0700 (PDT) In-Reply-To: <20130731155741.GA56454@mx1.yitter.info> References: <51F8221A.9030503@cisco.com> <6.2.5.6.2.20130731064015.0d5371a0@resistor.net> <20130731155741.GA56454@mx1.yitter.info> Date: Wed, 31 Jul 2013 13:23:22 -0400 X-Google-Sender-Auth: vq4hnEIgaPNTLz5VhF-YjJujV2w Message-ID: From: Barry Leiba To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Copying IAB remarks (was: [IAB] IETF 87 DMARC BOF evaluation) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:23:49 -0000 > Just to be clear, we did this because the responsible AD asked us to Yes, and thank you for doing it. > Also, as we can see from the subsequent threads, the follow-on > discussion suggests that people are made anxious by these reports, > partly because they tend to be pretty terse, leaving out all sorts of > subtleties. (If an AD thought something was being missed, I assure > you s/he'd ask.) That's important because as I understand it the IESG > is looking for a broad picture from the IAB, not a lot of in depth > review. They don't have time to read an in depth thing. So I'm > actually not sure that this is a good long-term plan. I think it is. Perhaps you could develop a preamble, much as some of the directorate reviews have, that explains the situation. But I'd like to see most of the IAB BoF reports sent publicly. Barry From housley@vigilsec.com Wed Jul 31 10:47:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FD721E810B for ; Wed, 31 Jul 2013 10:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 dHn-qpz9gIhC for ; Wed, 31 Jul 2013 10:47:40 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id AED9D21E80F3 for ; Wed, 31 Jul 2013 10:47:39 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9CE98F2407C for ; Wed, 31 Jul 2013 13:48:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id jozYye6GRQFE for ; Wed, 31 Jul 2013 13:47:05 -0400 (EDT) Received: from dhcp-540a.meeting.ietf.org (dhcp-540a.meeting.ietf.org [130.129.84.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CF109F24038 for ; Wed, 31 Jul 2013 13:48:03 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Jul 2013 13:47:30 -0400 Message-Id: <0C5F9CB0-FE27-4E02-9C38-37BA1CB22F99@vigilsec.com> To: dmarc@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [dmarc-ietf] Draft DMARC BOF Minutes X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:47:45 -0000 http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc I have posted the draft minutes. Thanks to John Levine for helping with = the notes. Please review and provide comments to make them better. Russ