From nobody Fri Jun 3 08:24:24 2016 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 C82C012D6D7 for ; Fri, 3 Jun 2016 08:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjg-ocLBbRoy for ; Fri, 3 Jun 2016 08:24:20 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF49A12B074 for ; Fri, 3 Jun 2016 08:24:20 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id n126so5443450itd.1 for ; Fri, 03 Jun 2016 08:24:20 -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:from:date:message-id :subject:to:cc; bh=iRoUuANjELY+4Bek/i0Fb0HIBkMxbxMctGqOPyvx67A=; b=MtGddxXKp0F5o0Bh2SoztnZcixQJXpeRp8P+eqXnYDkfgm1VI6LRaM6z1qoOmVWHxE xs5MrQQtjOd0Jdt6saLrWBHk5BQgdCLWCnS7oop9cJZCjHW9q23R0Vgtfws1sxVD7SMr DOH/ERWAOblZQSWnMSlmqXmYmXc2mgvA2FM1gyHZ9YxLoHJ9/7zsWdz744FZEBDsbd4Q F8SeGY+csi2n0E8fVJ2kcXI9FZfNoUbXAdFxEJMAXC/vwPr1VHI2LDEAp3gxdgI6hpyF tblIr5WLPTEesYqhiaAhLDerjSqjFq2hcecjWxySbe+fX2AEZQRc9o0gDMhdwlqfzgb6 n5vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iRoUuANjELY+4Bek/i0Fb0HIBkMxbxMctGqOPyvx67A=; b=C/KnlMz+15m9RbFOupU3/jD01D/rzLE3DTYTGynBzJwMH2Bv0XIJa7VTDdRab0UFI/ hMskOW3xeerqcqFJhJ0LcJ+TECW9d3tfvko/53ZCBvpbmxf8XWaAT7L0VZjDud7H41lk VI2yAIsn4d5bTOBZsKY8ImT5HQR5dtSiftCcosyFVvxpAsJi7T1EFC7w6y6fA/zPLLv3 2cduQilrIcvfhm+bHcrv9iHK3jNsq4U29Tz6yXInOL9cRNJyjvk8GUyrc15tbCRD3oca ClSYl2Mm2VGjccvfPE4B7i6mMlGAyJy/Dv8p9uWUZcgXJNywUzmakqRze5qo/PYBhlvw iIPg== X-Gm-Message-State: ALyK8tIVtZ+9bQ53LpshO5jdUy4Ebc6CjyXNJiUrf8nqZJHEIPttdDrN/KNBiO9hVQ8hu+eO450CU0NcSCJe8A== X-Received: by 10.36.120.12 with SMTP id p12mr212402itc.22.1464967459871; Fri, 03 Jun 2016 08:24:19 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.140.78 with HTTP; Fri, 3 Jun 2016 08:24:18 -0700 (PDT) In-Reply-To: <01Q0BB6RZ52800005M@mauve.mrochek.com> References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> <01Q0BB6RZ52800005M@mauve.mrochek.com> From: Barry Leiba Date: Fri, 3 Jun 2016 11:24:18 -0400 X-Google-Sender-Auth: KZKucS4_bMKPYhLq9mL164l9iHc Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 15:24:23 -0000 I hear that some people would like to consider other things besides ARC, and that's noted. The working group clearly does seem to want to work on ARC and to start with Kurt's draft in that endeavour. Murray, I've seen no response to Ned's note (which I agree with) that explains why we think the charter, as written, covers the ARC work. Do you have any follow-up, or did Ned's message address your concern? Barry On Wed, May 18, 2016 at 10:06 AM, wrote: >> There are a few different points here: > > >> 1. The proposed activity falls perfectly under "track" 1: > > >> > 1. Addressing the issues with indirect mail flows > > >> If anyone disagrees with that, that should probably be discussed as a >> distinct point, because I think it's obvious. > > > I concur. > >> 2. The constraint to "not develop additional mail authentication >> technologies" has a scope limited to the second "track", which is: > > >> > Reviewing and improving the base DMARC specification > > >> Since the proposed activity does not directly touch any aspect of the >> base DMARC specification, I again think that the INapplicability of the >> text for track 2 is also obvious. > > > Agreed again. > >> 3. Now we get to the difference between a track and a phase. And to >> state the issue is to state its resolution: these are different >> constructs, with different terminology. As if they are meant to be >> considered separately... > > > It never occured to me to think of the two as connected or cooresponding > or anything similar. > > >> The first item in Phase II is: > > >> > Phase II: >> > >> > Specification of DMARC improvements to support indirect mail flows > > >> And here's where I wish we'd phrased things a bit differently, although >> I don't think the current wording is a show-stopper. > > > It probably would have help to clearly link this item to track 1. > >> The proposed work falls under this first item in phase II. > > >> The catch is that the draft doesn't /say/ it's improving DMARC. (In >> fact, I've been quite vigorous in pressing to have the proposed spec >> carefully not say much about DMARC.) But really that's a >> document-writing point, not a working group functional point. > > > Agreed. > >> That is, ARC's development has been specifically motivated to respond to >> exactly this item in Phase II. > > >> If we did sloppy specification-writing, we'd have written this as a part >> of a DMARC enhancement. Not the 'base', of course, but an enhancement. >> The fact that it's been written as an independent component is so that >> its use is not /limited/ to DMARC. But again, that's merely a writing >> artifact. > > >> So, my reading of the charter says that the proposed spec falls under >> the first item of Phase two and the second sub-bullet of Track 1. > > > As does my own reading. > > Ned > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 3 15:44:56 2016 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 5A18012D8BB for ; Fri, 3 Jun 2016 15:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxrC-3w2eqgo for ; Fri, 3 Jun 2016 15:44:53 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D336012D8A9 for ; Fri, 3 Jun 2016 15:44:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x189so93803908ywe.3 for ; Fri, 03 Jun 2016 15:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=yGH7+uJ+htAz2UnibV88MRmCX/x+7MqhOtmrYPDUtDQ=; b=tzyjtxDVXAqkKyorrRxBvtxTFyAtqOiPqBMYjJiHHTENNVhnTar7CgY8Z/v6DbaDXR es9cBvCTT6OTu/JdZwEcyPkO90rrnNVd8OAYC3GM0W6wAlBoj3E1D+bqjxHpYJroNQGT xzq5NBwVSCj9ApBWArWzy8slMsNGM6JU5Tk90Wa8aYcPNfFFoIM1HfIIx9VhVbJ61YOD 0GYEDpyUaTDkn9yaE4rb55b+7MsheiO5bdlO2zZ+xwQxxwzQOT4ZpyI+0TTI03tjnUnM cY0115lhKxB7r2ppCgCXmQHpt+NZBZPMhvw5SlYMD5JtbiR/b2ysM5bhbdmnzkHuGuY0 ctBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=yGH7+uJ+htAz2UnibV88MRmCX/x+7MqhOtmrYPDUtDQ=; b=GouuICi3jwDbP9bgZxQdlUdyvlZOzXDbnC3NvNRlSNnvdD0zDFd1jcNfcRU10rWCum 0CK3Lz2ZL4zk8Hsas9RhfNGqq2SZz0HLddU4jU00sdrET7BOQ8ddR8J6MQ/Is5rlEDUd m5d2kBwvPlgyZYLHqewY34g3d2fxOOJtYycM1c8nhfu2pRCHKZ8cItZpRiE2ggKyS/fQ 0Rqc4wRGJzNn6ayfdFTU2pj5jYDnyShARl2I6JaKwUi+go/L1n+PacLxY1KJDWfAvFr3 GaiW8KzdQwH6gpp26Vnj+p5BfOi360S8h6zCkGtriz4HAJSVedUqPkWy8dRH6fwrl4fq tWeg== X-Gm-Message-State: ALyK8tLnplJ/PLAYSZbpCwZU/xbsgnafcLtxw8JmHExw64Vm9Bb5ovPEpMI1PC/ulAe1BiSZJZ9CE8+/P47nbA== X-Received: by 10.129.158.144 with SMTP id v138mr4581641ywg.9.1464993892013; Fri, 03 Jun 2016 15:44:52 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.37.6 with HTTP; Fri, 3 Jun 2016 15:44:51 -0700 (PDT) From: Barry Leiba Date: Fri, 3 Jun 2016 18:44:51 -0400 X-Google-Sender-Auth: 9cid7uIn8QGX2CvIY13vh_JZibs Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dmarc-ietf] Meeting in Berlin... or no? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 22:44:54 -0000 My sense is that we don't need to meet face to face in Berlin. We have lots of things to discuss on the list, but we're not stuck on issues that need in-person time. Does anyone think we *do* need to meet? If so, please suggest what would be on the agenda that really needs the face time. Barry, as chair From nobody Fri Jun 3 15:45:59 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7387E12D8BB; Fri, 3 Jun 2016 15:45:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603224557.19286.68307.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 15:45:57 -0700 Archived-At: Cc: dmarc@ietf.org, dmarc-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm Subject: [dmarc-ietf] dmarc - Not having a session at IETF 96 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 22:45:57 -0000 Barry Leiba, a chair of the dmarc working group, indicated that the dmarc working group does not plan to hold a session at IETF 96. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Jun 3 16:09:55 2016 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 44E9F12D62D for ; Fri, 3 Jun 2016 16:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiCozHhAViFH for ; Fri, 3 Jun 2016 16:09:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999DF12D5B5 for ; Fri, 3 Jun 2016 16:09:52 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id t40so93975234ioi.0 for ; Fri, 03 Jun 2016 16:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=bjrl/J63iYP2uWWO6Fivk8jT1nrnuBwdS+mUwcKQIJU=; b=SnMXTwQIb0zOMFRMXoh/+z4bj8m2ftT3HflsPcnUVj7NQ0R/c6gKEm4BRzb999ZLzS m2+XMzsTwZWglCGOwcbsR6W8Nql9DJEpoMr8jSqSiaZeMe71DKzYULPPM0oPHe5pqD5c VKRBK46HHslSXCuh1r/PD/81FfnPmDsQ58CJc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=bjrl/J63iYP2uWWO6Fivk8jT1nrnuBwdS+mUwcKQIJU=; b=alsjNzWWWHXx53F29vIq4SQHtLPYXcqDe2v8GQYpqRUsCl26jjJ3Gww+CQBWBu+Uws JW98ohrfgDMxrxht+AS6UYKRKyQd6vESapleR+18t0J0m4coV3OZ10xXbGu1Rli0G2jK fAlRiMaFykYolGHp37H+A24fxr99ErBmZCwgrzHze3qLMEwxxp0DJxrvwe58QuaeyX65 uqY7XiH/uFetIriO+JCmK6JFWNm//d302jFkr0Bj07omedIbp0l+MXj6uoRdFAQmIMCO Pijrq9qUA6tY4ermHqIF5Wa1KqpzmtJRtrFtlpjcl1P+SwtkrCvkjnm773b8QDEVKx2Y L1AQ== X-Gm-Message-State: ALyK8tJWzdaPZvdY+4H/Qt09KMoKW4AqQD7azVYuGlK/CI+77zCNw0RaLL8m8nESHx4B1ooFbRvxnAkJkXgl6Q== X-Received: by 10.107.10.100 with SMTP id u97mr8516708ioi.92.1464995391878; Fri, 03 Jun 2016 16:09:51 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.107.14.81 with HTTP; Fri, 3 Jun 2016 16:09:51 -0700 (PDT) From: "Kurt Andersen (b)" Date: Fri, 3 Jun 2016 16:09:51 -0700 X-Google-Sender-Auth: 3YR5D8vM-oYOLhIYVxNVDFnbpOU Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113ed836ee4ec0053467d129 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Meeting in Berlin... or no? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 23:09:54 -0000 --001a113ed836ee4ec0053467d129 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 3, 2016 at 3:44 PM, Barry Leiba wrote: > My sense is that we don't need to meet face to face in Berlin. We > have lots of things to discuss on the list, but we're not stuck on > issues that need in-person time. > Agreed. --Kurt --001a113ed836ee4ec0053467d129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 3, 2016 at 3:44 PM, Barry Leiba <barryleiba@computer.org= > wrote:
My sense is that we do= n't need to meet face to face in Berlin.=C2=A0 We
have lots of things to discuss on the list, but we're not stuck on
issues that need in-person time.

Agreed= .

--Kurt=C2=A0

--001a113ed836ee4ec0053467d129-- From nobody Fri Jun 3 17:12:14 2016 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 6E19312D09B for ; Fri, 3 Jun 2016 17:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF3Pts_o6c9T for ; Fri, 3 Jun 2016 17:12:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4508512B024 for ; Fri, 3 Jun 2016 17:12:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q0Y8P25ZGG001SNW@mauve.mrochek.com> for dmarc@ietf.org; Fri, 3 Jun 2016 17:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1464998828; bh=Avgiut9SbZqRTW33QCsE4FJdh7ezLtlZfuxf0XZM2Qo=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=W9uCc5aJCgrEi8Zd+QM80PnFWgnqVgSaOamNc+WXRWRfMvHMMkNo91YP6SvePFHaQ BOv6wzQ+JkU6Ssa0nAlBPMlQRO7UX6ZA0o807DbH4sYW09rUucbpFazLYVAdZGKRBT OH596Jb/CWRltt/j08OpOYbwq6S4yCufjKOuXXUg= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q0Y72AJMV400005N@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 03 Jun 2016 17:07:05 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01Q0Y8P0MT4S00005N@mauve.mrochek.com> Date: Fri, 03 Jun 2016 17:06:48 -0700 (PDT) In-reply-to: "Your message dated Fri, 03 Jun 2016 16:09:51 -0700" References: To: "Kurt Andersen (b)" Archived-At: Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Meeting in Berlin... or no? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 00:12:12 -0000 > On Fri, Jun 3, 2016 at 3:44 PM, Barry Leiba wrote: > > My sense is that we don't need to meet face to face in Berlin. We > > have lots of things to discuss on the list, but we're not stuck on > > issues that need in-person time. > > > Agreed. Agreed as well. Ned From nobody Fri Jun 3 17:42:53 2016 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 440E112D523 for ; Fri, 3 Jun 2016 17:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiN3-danKjD2 for ; Fri, 3 Jun 2016 17:42:50 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F8612D572 for ; Fri, 3 Jun 2016 17:42:48 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x189so95508928ywe.3 for ; Fri, 03 Jun 2016 17:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wXyqWf1ThuRwSCPQ0H6kfvb1LJZmZp3cyPIw3Zra3eM=; b=NgVmrRf9u5IDqJawb9OsjoFJF3VFGgeGXsHd6HcwPwlx9F1Um852Nh22x0SoFCOuhX r4a1urfghP9iSTJGpCiGoRa45sBs7JNFy0f0F80Hdae0w/zchMA/VhghYVW4Ty2NtpUN /CF3n7IWRRvjaLur8fffKZdUy8DHUIOa7wjl+GNLf4S9JJGV5Hr/IH0c5sxEJUk4O09e HkrLegPGd2SEUEazZDhTyU8jVgcKbt4mdnTmhnoJek5FirsEFkkX9ijN6urrPQhbPetC IY9gTqO89p10z123Q4/0KNWPlzfU20qObwCiWoDePljf1u6sJ53dHkf072l5xCDLPxZ1 1DTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wXyqWf1ThuRwSCPQ0H6kfvb1LJZmZp3cyPIw3Zra3eM=; b=O4VoLz3Oj+mnMCTj9BTlDWqWtHY/b38dfhmMwYb5f3ewCPLm+hEkkHgo9Ekv86xWg8 uENOS6PFVW/R4FDmuepxvYoPgB3y0Vgw+CnWMsYR9c5i69kaFjLWAuAyPX4FMcRR5SiJ J/vgkrs+aETQJVTYKt1+g0us/ijT50hTMvcWsn4VvMXDGw5VWNSI7sQU9wtiZbWIh7a0 2GVScUvYfeqfWHXXwFN2rs28jFZ/LSiqGwX+l/4g2iGNxBTfoREhHeBzBR8MSwaOGU36 uVy1MoPIKpkdqDxnSSSZinGBTKtcsZhm5p6DFDQune2/VBbSIAGuh3zC+tXADvexXWCv eMWw== X-Gm-Message-State: ALyK8tIypQggI5NP84+AlFhG5hCFTArANYdD7yqSK+zKSRouvpTswEB8LlvQYugtweyavccvvplM87zDCW6VXQ== X-Received: by 10.13.203.2 with SMTP id n2mr4317763ywd.57.1465000967326; Fri, 03 Jun 2016 17:42:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.214 with HTTP; Fri, 3 Jun 2016 17:42:45 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> <01Q0BB6RZ52800005M@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Fri, 3 Jun 2016 17:42:45 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a114e3e2040ea7f0534691e48 Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jun 2016 00:42:52 -0000 --001a114e3e2040ea7f0534691e48 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 3, 2016 at 8:24 AM, Barry Leiba wrote: > Murray, I've seen no response to Ned's note (which I agree with) that > explains why we think the charter, as written, covers the ARC work. > Do you have any follow-up, or did Ned's message address your concern? I think we can call it "addressed" by me accepting that I'm in the rough in terms of consensus. If my interpretation is singular, there's no need to dwell on it. -MSK --001a114e3e2040ea7f0534691e48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 3, 2016 at 8:24 AM, Barry Leiba <barryl= eiba@computer.org> wrote:
Murray, I've seen = no response to Ned's note (which I agree with) that
explains why we think the charter, as written, covers the ARC work.
Do you have any follow-up, or did Ned's message address your concern?

I think we can call it "addressed"= by me accepting that I'm in the rough in terms of consensus.=C2=A0 If = my interpretation is singular, there's no need to dwell on it.

<= /div>
-MSK
--001a114e3e2040ea7f0534691e48-- From nobody Mon Jun 6 03:15:21 2016 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 2D99C12B022 for ; Mon, 6 Jun 2016 03:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMsdszz91Gtp for ; Mon, 6 Jun 2016 03:15:18 -0700 (PDT) Received: from EDC2VMOUT01.edc.trendmicro.com (edc2vmout01.edc.trendmicro.com [216.104.20.206]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD91F12D0FB for ; Mon, 6 Jun 2016 03:15:17 -0700 (PDT) Received: from EDC2VMOUT01.edc.trendmicro.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 33038388061; Mon, 6 Jun 2016 12:15:15 +0200 (CEST) Received: from EDC2VMEXCH02.eu.trendnet.org (unknown [10.34.168.162]) by EDC2VMOUT01.edc.trendmicro.com (Postfix) with ESMTP id 24FAD388058; Mon, 6 Jun 2016 12:15:15 +0200 (CEST) Received: from EDC2EXMBX01.eu.trendnet.org ([fe80::d1c6:2dad:52d:ac7f]) by EDC2VMEXCH02.eu.trendnet.org ([fe80::b1b9:defe:2d45:2693%11]) with mapi id 14.03.0279.002; Mon, 6 Jun 2016 12:15:14 +0200 From: "morton_swimmer@trendmicro.de" To: Barry Leiba , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Meeting in Berlin... or no? Thread-Index: AQHRvemTP9t2mdluN0Obf2t4t7JpA5/cPMqA Date: Mon, 6 Jun 2016 10:15:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.1.98] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-8.0.0.1202-22374.006 X-TMASE-Version: IMSVA-8.2.0.1679-8.0.1202-22374.006 X-TMASE-Result: 10--48.989200-5.000000 X-TMASE-MatchedRID: HUaxhRiEgrNeiAFAd7Dwq+5i6weAmSDKvWY9kbV8t/daW2Ktn+I8/tOG jZUqGWjE1Fc61VCGvh25VJd66JUGD/aem1tLpQOV/c0+LJTMrN3jmgMQ17h56wzvg1/q1MH2uml LC5g94HuPWZvDr+0qazwxeGjpS2MHSpebgw+pOvYSluJ3G6/rcyRuLNu6LJ+V4wCJoBGLUMifoi mXYlcqJcaPMwWhbR7xwHuzr+9N/8V+8pJxtgLtfErx1IkyZlRH3TJx7pij2heG/PWfM8CUTtaNn 4bJ67upu8U3TkjC8AwlP4fFPnrrFjIMh0gavIxowvqOGBrge3sZskwWqoib3AKCOvtvTK0ZV3on IP+5EDB9lTA2ve4I4P7VZGIRMM+aJye4cEeBTABPuMJi/ZAk8S4tncCojEfcmyiLZetSf8lRfLa SAVDtyiq2rl3dzGQ1A/3R8k/14e0= Archived-At: Subject: Re: [dmarc-ietf] Meeting in Berlin... or no? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jun 2016 10:15:20 -0000 Well, I=B9ll be there no matter. Cheers, Morton On 04/06/16 00:44, "dmarc on behalf of Barry Leiba" wrote: >My sense is that we don't need to meet face to face in Berlin. We >have lots of things to discuss on the list, but we're not stuck on >issues that need in-person time. > >Does anyone think we *do* need to meet? If so, please suggest what >would be on the agenda that really needs the face time. > >Barry, as chair > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc TREND MICRO Deutschland GmbH, Zeppelinstrasse 1, 85399 Hallbergmoos, Germ= any Geschaeftsfuehrer: Raimund Genes (Spr.), Frank Schwittay, Norma O'Callagh= an, Guenter Untucht, Amtsgericht Muenchen - HRB 114739 Die in dieser E-Mail und ihren etwaigen Anhaengen enthaltenen Information= en sind vertraulich und koennen gewerblichen Schutzrechten unterliegen. S= ollten Sie keiner der vorgesehenen Empfaenger sein, sind Sie nicht berech= tigt, diese Nachricht in irgendeiner Weise zu benutzen oder weiterzugeben= . Bitte benachrichtigen Sie uns ggf. per Rueckantwort oder telefonisch (0= 811-88990700) und loeschen Sie diese E-Mail aus Ihrem E-Mail-System. The information contained in this email and any attachments is confidenti= al and may be subject to copyright or other intellectual property protect= ion. If you are not the intended recipient, you are not authorized to use= or disclose this information, and we request that you notify us by reply= mail or telephone and delete the original message from your mail system. From nobody Tue Jun 7 07:06:45 2016 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 C154812D62D for ; Tue, 7 Jun 2016 07:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIyJzgQdc0ws for ; Tue, 7 Jun 2016 07:06:38 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECE612D681 for ; Tue, 7 Jun 2016 07:06:37 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id h190so11999940ith.1 for ; Tue, 07 Jun 2016 07:06:37 -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:from:date:message-id :subject:to:cc; bh=T3lvdJcl4Kasx/TuzcVxoGrG3qBzyuJgz15q9CCoC60=; b=VMpBzdgG4R5+ZnzaV88HZDiroEz+BcpQS6/lxoFSZTzzGYPDpcknYwUH/aOQJb/exa 3nmfbTLmIgPS78Lmw4v4KAWWUZx3QvrjxqSTiTckr8EQLmI/azw0zMNmdRaTtDqhjYUu 5dwR43CAbydVOAEi3ZcJSi9F8jAvjkB2WnJvwGRQXnD+cs66uC18MLhlkSmgtbs0/zU6 8g0pNtzNxU65t0wsj2ONRPEnQH5cdFo0LvfuQk1ZmEgx5BvNF9L0WqKUdgf9wvgT1wI7 9Z504vwkS24n/xGGMduuGcm4HI0eqD34wjBys7AU+V2fBzsmr+4TrtWyOYLS/InMqruz ZYFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=T3lvdJcl4Kasx/TuzcVxoGrG3qBzyuJgz15q9CCoC60=; b=AbIkSI9xZ1R6ez3npz9xuXaznbcKDtQ8eiPoJPwX7E7pcTMyEPBt61fiM6kMzK7LvT oZLDzhpwcL25Mzq8sWsLZBuyonYXLcmF3ib34qhBQwDHJTwUgD6zt9yV5if5aj7hnBYQ X6TwPpZFSpQWiLRJSqP97zkpJwpPziaVQo9shqnQSONhsnES2s+hxj8fq2wlMx8TiKRZ xK4+g1eRiYCNdQD5KTTFPc6roTl3zw11SDXbN0x+C0x//MKI3mdIM+MAQo4TAvMCe5MO y6IORoIltRfro7BKKgRoLDcKRTdHiIfAZ1L2FJTJCWJI49iaqyLThj9cp6q3yiKAFF1c h+nA== X-Gm-Message-State: ALyK8tLIP7JpcS/cbAbMTLFlnnpgMpT3IK9mrV4K/uqKZCqLda8W6rz7hCBP8b2pat3/8mKq/+if87K6BhNklA== X-Received: by 10.107.140.207 with SMTP id o198mr2818266iod.70.1465308395958; Tue, 07 Jun 2016 07:06:35 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.148 with HTTP; Tue, 7 Jun 2016 07:06:34 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> <01Q0BB6RZ52800005M@mauve.mrochek.com> From: Barry Leiba Date: Tue, 7 Jun 2016 10:06:34 -0400 X-Google-Sender-Auth: rEh14BKvm8ZFOfjZEDJX8kUG6PI Message-ID: To: Kurt Andersen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 14:06:44 -0000 >> Murray, I've seen no response to Ned's note (which I agree with) that >> explains why we think the charter, as written, covers the ARC work. >> Do you have any follow-up, or did Ned's message address your concern? > > I think we can call it "addressed" by me accepting that I'm in the rough in > terms of consensus. If my interpretation is singular, there's no need to > dwell on it. Great; then the work is accepted, and the starting-point documents will become working group documents. Please submit new versions of those documents with working group file names, as follows: draft-andersen-arc -> draft-ietf-dmarc-arc-protocol-00 draft-jones-arc-usage -> draft-ietf-dmarc-arc-usage-00 When you submit them, please be sure to fill in the "replaces" field on the second page of the submission form with the old file name. Barry From nobody Tue Jun 7 07:46:48 2016 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 2BB8612D753 for ; Tue, 7 Jun 2016 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLu98oQR1C7C for ; Tue, 7 Jun 2016 07:46:45 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB65E12D732 for ; Tue, 7 Jun 2016 07:46:45 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h62so28411577itb.1 for ; Tue, 07 Jun 2016 07:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XyHkAA5LaM7uXIm46iX+2OSgxEeLRTFFHQeea1+fygc=; b=bHDOzCac+vfauWOG1u3xb0Sdw2HmpaVO1LhXjrsDfRVJfsDlhOBf0M9hu/Pim7yXo/ wGzWESndMFKh19jKhqg2s88vjAG1EWNY+PkceN6R6hpL9TzZwT6q4JPuhNsIfdcZBhiK bGqrSV6yvsKkfJQ+QFuH9qBXFyvZ8ITNl0hGU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XyHkAA5LaM7uXIm46iX+2OSgxEeLRTFFHQeea1+fygc=; b=Yh1WNMIxRdT9WDUOOSsc6Frc5nq2h/6n3syB/Xkh7vZQ/CzAQM8oZoe8fU/67aKH4M 9FB/Yyj6a0yKowDZsjmMWOXjIU1wzKLzINIiYrtDOcI2NKcgdXWNdD1+m2p+2OQjClKE HsbvWjRRRXEAtl950k5TzOI8Y9MWIBklbuh4x582JzLsn0PLtKdwR9YNjvdppkIW/+yx jIOHWFs2bCRVDqwrtMaTLS8qEoDZhYAPfp2+R5O93zaI+M+AW4UGjTlTmp3ymYRABOBU 1tN6QxFwLgFmSPQ30VGd56pBx15wtljGITmEIm+BX5Tor4Y0jg+CUC8Kocy3IhTjqbOg it5A== X-Gm-Message-State: ALyK8tILQ7MTLM2NfREbvvZNvPtG2aXFJUWrQA1LQm4/hcT/lLBeyAB8BIMaLe/Seka5RqCtV/+KEwUk1UqI+A== X-Received: by 10.107.129.95 with SMTP id c92mr179047iod.102.1465310804028; Tue, 07 Jun 2016 07:46:44 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.107.14.81 with HTTP; Tue, 7 Jun 2016 07:46:42 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> <01Q0BB6RZ52800005M@mauve.mrochek.com> From: "Kurt Andersen (b)" Date: Tue, 7 Jun 2016 07:46:42 -0700 X-Google-Sender-Auth: diQckPzvFjVvNaUiegtYBnLKmiA Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113ecac4f5bbaa0534b1413b Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jun 2016 14:46:47 -0000 --001a113ecac4f5bbaa0534b1413b Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 7:06 AM, Barry Leiba wrote: > . . . the work is accepted, and the starting-point documents > will become working group documents. > > Please submit new versions of those documents with working group file > names, as follows:. . . > Will do! Probably later this week. --Kurt --001a113ecac4f5bbaa0534b1413b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 7, 2016 at 7:06 AM, Barry Leiba <barryleiba@computer.org= > wrote:
. . . the work is acce= pted, and the starting-point documents
will become working group documents.

Please submit new versions of those documents with working group file
names, as follows:. . .

Will do! Probab= ly later this week.

--Kurt
--001a113ecac4f5bbaa0534b1413b-- From nobody Wed Jun 8 06:14:44 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E59F212B03D; Wed, 8 Jun 2016 06:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160608131442.20083.33998.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2016 06:14:42 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-16.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:14:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-16.txt Pages : 25 Date : 2016-06-08 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 13 13:44:30 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 746F612DA0A; Mon, 13 Jun 2016 13:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613204409.6907.79045.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 13:44:09 -0700 Archived-At: Cc: dmarc@ietf.org, draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, dmarc-chairs@ietf.org Subject: [dmarc-ietf] Ben Campbell's Yes on draft-ietf-dmarc-interoperability-16: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 20:44:26 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmarc-interoperability-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Abstract: Please expand DMARC on first mention. - 4.1.1.1, last bullet: "However, for known brands, all active domains are likely to be targeted equally by abusers." I'm not sure quite what is meant by "known brands". Is this the same as well known email services? 6. Some of the mentioned mitigations involved relaxing alignment checks. Do those warrant a mention here? -- last paragraph: " Section 4.1.3.3 warns that rewriting the RFC5322.From header field and changing the domain name should not be done with any domain." I'm not sure I understand that sentence, especially around "not be done with any domain". Nor do I see which text in 4.1.3.3 specifically says that. From nobody Tue Jun 14 09:12:48 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9412D7F7 for ; Tue, 14 Jun 2016 09:12:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614161247.19225.38020.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 09:12:47 -0700 From: IETF Secretariat Archived-At: Subject: [dmarc-ietf] Milestones changed for dmarc WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jun 2016 16:12:47 -0000 Changed milestone "Complete draft on DMARC interop issues + possible methods to address", set due date to June 2015 from February 2015, resolved as "Done". URL: https://datatracker.ietf.org/wg/dmarc/charter/ From nobody Wed Jun 15 07:39:36 2016 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 633FF12D75D for ; Wed, 15 Jun 2016 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V115SB_6YvvP for ; Wed, 15 Jun 2016 07:39:32 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F68C12D6AB for ; Wed, 15 Jun 2016 07:39:32 -0700 (PDT) Received: by mail-ob0-x229.google.com with SMTP id hx8so570407obb.3 for ; Wed, 15 Jun 2016 07:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=zLAvm3jVBZADOIXqWmn4ADus6C8qUuWHvLUDEwBfEtk=; b=TN6xvw1Q4epmsKRxPJFEbnGikBVWWTOgwlWg4sOThRsFSGE5hAsuUQLqWt3c7DUKYq 8zXUtytbAqB5B+d3CKhzHwi0JNXnUsYpuOYckd6Suluis0KMXaOEZrDX04MHz8RskEVg xVi9965ozFKhrdIHf1BCPKlqQUa/4dAwriHMpbbuFaT+/PmnykcP0X1HHyWRVCRUxrim nzZIKcj83u8MVkmR8EKHieprx6zctLpFM73qE39F0XnUhdwx9yAz4MuZQdOSjTD7qHZw OPBCO4Sqydhmko3mSj8Xnqg0muy5QwZdk5AEFQZtsLWhghCX1l/mA0MZRf7FZad6Dfte n+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zLAvm3jVBZADOIXqWmn4ADus6C8qUuWHvLUDEwBfEtk=; b=VIi67y43W4EZe6wANWuzegdKHmZXZn9fwJlIC5rfpirKfTAs4Bi6mE936pJMvfsGw8 7UneuF/5YqIv0gW35QbOK7W+3UElNOwGRiqZY52ax/3fbC2y3yKkxDuR/BGAnmqSUdBL tvTuJOF/ZQLbQ8z1zJEpCwoXqkRGsPT9EUU1hn6RYiOfKEdnNjAkDgXWhEAwly7ahxS5 7ZjCVNh7LAH7oIcyQzECqPLQxXPyJNsQ1adB/sgSQzR+JQUhgOLvAhupxCKIvbBhPil8 t3xNMkHsd5NdPuLd7+f4rTwQ8e5fQyVGDLqSX8vFwRTkVtYLaj+0v4EN+9y8DeVcmvbw bPGg== X-Gm-Message-State: ALyK8tJg/1QVxPJw9HYz7/RteqvaON1Ps+0+4mrp9QO9CGgD1l32C97o4uH6Q5NBH0UaQzfY4Cv+WeXO7A+SQYon X-Received: by 10.202.85.6 with SMTP id j6mr12320938oib.100.1466001570631; Wed, 15 Jun 2016 07:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.45.99 with HTTP; Wed, 15 Jun 2016 07:39:29 -0700 (PDT) From: Brandon Long Date: Wed, 15 Jun 2016 07:39:29 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113d2364dc118205355216f9 Archived-At: Subject: [dmarc-ietf] new dkimpy based arc implementation X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jun 2016 14:39:33 -0000 --001a113d2364dc118205355216f9 Content-Type: text/plain; charset=UTF-8 available here: https://drive.google.com/open?id=0B4vtkmD_MKfuV3pWVC1iMWVsZk0 I've also sent it to the dkimpy owners for merging, so consider this alpha code at this point. In particular, I tried to make it mostly an addition to the existing dkimpy code, instead of refactoring the code to have a common base. It's not the prettiest code I've written... Brandon --001a113d2364dc118205355216f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
available here:=C2=A0https://drive.google.com/open?id=3D0= B4vtkmD_MKfuV3pWVC1iMWVsZk0

I've also sent it to= the dkimpy owners for merging, so consider this alpha code at this point.= =C2=A0 In particular, I tried to make it mostly an addition to the existing= dkimpy code, instead of refactoring the code to have a common base.
<= div>
It's not the prettiest code I've written...

Brandon
--001a113d2364dc118205355216f9-- From nobody Thu Jun 16 05:37:28 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 465CA12D195; Thu, 16 Jun 2016 05:37:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160616123726.10413.74962.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2016 05:37:26 -0700 Archived-At: Cc: dmarc@ietf.org, draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, dmarc-chairs@ietf.org Subject: [dmarc-ietf] Stephen Farrell's No Objection on draft-ietf-dmarc-interoperability-16: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jun 2016 12:37:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dmarc-interoperability-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I think the abstract and intro are too coy in saying that DMARC "can" introduce interop issues when we know that it definitely does introduce such issues. Better to be up front about that I think. The same issue arises elsewhere (e.g. in 3.2.3.1) and I don't see any real benefit in almost pretending that this isn't a real issue. - I think the abstract and intro would be better if they explicitly ack'd that DMARC affects mailing lists. So maybe replacing the relevant sentence with something like: "Collectively these email flows are referred to as indirect email flows, and include mailing lists, such as those used to discuss this document." - 2.3: I'm surprised that we don't know the prevalence of simple vs. relaxed support and use. - 3.1.2: Saying that the MTA is the thing to "introduce" the interop issue here seems a bit wrong - isn't the issue caused by the existing MTA practice combined with the introduction of DMARC? From nobody Tue Jun 21 22:08:29 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E130D12D744; Tue, 21 Jun 2016 22:08:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622050823.24966.47659.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2016 22:08:23 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-17.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 05:08:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Kurt Andersen Filename : draft-ietf-dmarc-interoperability-17.txt Pages : 26 Date : 2016-06-21 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The use of restrictive policies through the DMARC framework can cause interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 22 14:55:24 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7E12DCA7 for ; Wed, 22 Jun 2016 14:55:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622215522.11091.36074.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 14:55:22 -0700 From: IETF Secretariat Archived-At: Subject: [dmarc-ietf] Milestones changed for dmarc WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 21:55:23 -0000 Deleted milestone "Complete draft specification of DMARC improvements to better support indirect email flows". Deleted milestone "Complete draft DMARC Usage Guide". Deleted milestone "Complete draft on changes to DMARC base spec". URL: https://datatracker.ietf.org/wg/dmarc/charter/ From nobody Wed Jun 22 14:59:17 2016 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 A537912D7DC for ; Wed, 22 Jun 2016 14:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frcsWmgbnsFU for ; Wed, 22 Jun 2016 14:59:13 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6ED12D732 for ; Wed, 22 Jun 2016 14:59:13 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f30so56033843ioj.2 for ; Wed, 22 Jun 2016 14:59:13 -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:from:date:message-id :subject:to:cc; bh=uE2bt0mlERSSn7YBXKQzbQNS8bXoPCVtZYfcIA4t3Z4=; b=l+H4Yf7aqp4MmH9H/VC9c2yf1CFQOqaduvkvurTMIO10+k61zo0Z+Q9sTRLs6L2Mzo gZnpoQTXlDg83hRI8sfCp0D9Dx6plFSHLZVKg9gcU3wW9fQ5PVc2HXmEdcIZTfY1VvqF XLxvgdpysxfza47xTAe8GqDnWEoeKYBg3Nrf7DImOqf4ph7TgBdKlFn+XFOKH/t5fdZh 6rI1vkqi2QOJS9O+nUHiyVfTn+ykxDI3ni1TNPY0YxVbQ6DH4BHvXnKHMqsI4jxk9b/t pad1lHGC9iDAhH2O89E/+ju164pzTK1x3WpmlUrhHfOm/AZFej+QmW5pjYgPnfPWN49l /XOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uE2bt0mlERSSn7YBXKQzbQNS8bXoPCVtZYfcIA4t3Z4=; b=FAc7a0wtOlDXm8uMxKFhyZHsn41JBHT2fsD8wOCeXb1gWsusMXkVOxNZ2AnhDTiFzt xKAKqRliM2k5DH+w+utOU6UzKIxQ4bcD5W4sRI/pg+FG1A+W2hPPpa0N3mNjAdm8VT6W qQqvqB9Up54FLGIz9ZtyqMd6ceCHc9SKdlNRRALHsJSghKitrKSmPLsVMTVrvopQzXDc Qro7ZulXUI0/5g4DtJCx8KUzz8la5T2X8SEhuCD67XBxb7DDVSHPOwKhHt8pRTt5JFdR 6YYdqIy5UhmWPzGLVm1YZXP99qZ/c6mJa2tDfXlX5Va+xFRRMGh2auE/yUPGfmsa/Yh3 hs8A== X-Gm-Message-State: ALyK8tKsJU0ltZFepHUu86MdsBRdANWzrue9nbchxzS/CMYqwM4cF76bDN5531UzLwm9ZoL/MMBtmtNCU3OOiA== X-Received: by 10.107.134.101 with SMTP id i98mr45902370iod.41.1466632752625; Wed, 22 Jun 2016 14:59:12 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Wed, 22 Jun 2016 14:59:11 -0700 (PDT) In-Reply-To: References: <20160511002303.14397.qmail@ary.lan> <57327D81.6050306@gmail.com> <57331D94.2010004@tana.it> <573B33DD.5040802@tana.it> <7ff3f3d4-4dc2-6629-64ae-5263f79d5b34@gmail.com> <01Q0BB6RZ52800005M@mauve.mrochek.com> From: Barry Leiba Date: Wed, 22 Jun 2016 17:59:11 -0400 X-Google-Sender-Auth: Ir5IB-ymA_lhi2IPfT8kE92EWYs Message-ID: To: "Kurt Andersen (b)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DMARC Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 21:59:16 -0000 >> . . . the work is accepted, and the starting-point documents >> will become working group documents. >> >> Please submit new versions of those documents with working group file >> names, as follows:. . . >> Great; then the work is accepted, and the starting-point documents >> will become working group documents. >> >> Please submit new versions of those documents with working group file >> names, as follows: >> >> draft-andersen-arc -> draft-ietf-dmarc-arc-protocol-00 >> >> draft-jones-arc-usage -> draft-ietf-dmarc-arc-usage-00 >> >> When you submit them, please be sure to fill in the "replaces" field >> on the second page of the submission form with the old file name. > > > Will do! Probably later this week. ...which is now two weeks ago. New versions soon? Barry From nobody Thu Jun 23 05:23:48 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC212D0E9 for ; Thu, 23 Jun 2016 05:23:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623122347.31233.72366.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 05:23:47 -0700 From: IETF Secretariat Archived-At: Subject: [dmarc-ietf] Milestones changed for dmarc WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jun 2016 12:23:47 -0000 Changed milestone "Complete Authenticated Received Chain (ARC) protocol spec", set state to active from review, accepting new milestone. Changed milestone "Complete Authenticated Received Chain (ARC) usage recommendations", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/dmarc/charter/ From nobody Sat Jun 25 08:36:14 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7966D12D095; Sat, 25 Jun 2016 08:36:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160625153609.17116.28762.idtracker@ietfa.amsl.com> Date: Sat, 25 Jun 2016 08:36:09 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jun 2016 15:36:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen John Rae-Grant Brandon Long J. Trent Adams Steven Jones Filename : draft-ietf-dmarc-arc-protocol-00.txt Pages : 42 Date : 2016-06-25 Abstract: Authenticated Received Chain (ARC) permits an organization which is creating or handling email to indicate its involvement with the handling process. It defines a set of cryptographically signed header fields in a manner analagous to that of DKIM. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Changes in the message that might break DKIM can be identified through the ARC set of header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 25 08:36:40 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB9712D5CD; Sat, 25 Jun 2016 08:36:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160625153635.17173.21845.idtracker@ietfa.amsl.com> Date: Sat, 25 Jun 2016 08:36:35 -0700 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jun 2016 15:36:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance of the IETF. Title : Recommended Usage of the Authenticated Received Chain (ARC) Authors : Steven Jones John Rae-Grant J. Trent Adams Kurt Andersen Filename : draft-ietf-dmarc-arc-usage-00.txt Pages : 15 Date : 2016-06-25 Abstract: The Authentication Received Chain (ARC) provides a means to preserve email authentication results and verify the identity of email message handlers, each of which participates by inserting certain header fields before passing the message on. But the specification does not indicate how intermediaries and receivers should interpret or utilize ARC. This document will provide guidance in these areas. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 26 00:05:32 2016 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 EDA6212B071 for ; Sun, 26 Jun 2016 00:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_o-Bt-fDiCr for ; Sun, 26 Jun 2016 00:05:29 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7844212B05A for ; Sun, 26 Jun 2016 00:05:29 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v77so132649295ywg.0 for ; Sun, 26 Jun 2016 00:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xRnKSx9mfWwEk6Tge2Q13B4QBFijz/i4OFUPVJUyvXc=; b=ubrQ9JXGHt+HBJ/S7udtjD7zR8EkHfbfgHbnE/kRux15kkvABz6/jLTOd4caSeNRn2 UB8pZyKXjFafICut3YpD/MtXRpme3Y6FjgcwJ2g6tv5eiu5Iu9Xy+8H2b8Gp+Sj3zQdz nylJHjOwoxolTDH1oggFI7nQNl+4IDhmtoo2ev9HGFoP5Pf5SRFPrV4Re2UVmbFJ/YPy m/V1wKf1mqfkq1FpfVced3Vst1PYp4E8DxM/IB73i9Uhl82C5m4bqP16f6ps2juqi6GG JMmk3tMYo9IRriVUA2bJA10dtFV4Q8f93hOWbVLXXwMKep9M6wxEi3FB7d+Y0xaPhQQN AWqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xRnKSx9mfWwEk6Tge2Q13B4QBFijz/i4OFUPVJUyvXc=; b=CXxmmXh9Ea4Pm8Mu0bLlTj70z8I4fy96qQM3tHyCIA9XVkWD1WS73T2cziyl8KHHTR TllM39ntxO2ucLtoMevNQJn75R6I1OpSY+fWMIPGasId+2/cnqTD5BikBEybNM2wgb3m V/Y+YjMY2NVowCEo/lcfsRLnulPd8wWd36hxCLzLUCpwRPfAESntjZFQXIdE7S+MRM1x vjgWjx4+OkousXl57mfkW+hxhMTb5/AIdxFpnOj5b2nfcQN7bzuPHqeaCATXPI/OgRpt tjg55J8MwtKQHNNye2nDdXF4Xv7FcoobSmyWS5tfCWGAFzpH82TSn7v+CdpefNu5RWNg UQKg== X-Gm-Message-State: ALyK8tIJXUl2PTbRbszOdUrRMJip3F81jS+4WwTa5oj9EKd98yU8OYrUjOzPPF2NB2aVg2S7zj6DpYH3Z7VI4g== X-Received: by 10.37.4.6 with SMTP id 6mr7944385ybe.138.1466924728537; Sun, 26 Jun 2016 00:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.145 with HTTP; Sun, 26 Jun 2016 00:05:27 -0700 (PDT) In-Reply-To: <20160625153635.17173.21845.idtracker@ietfa.amsl.com> References: <20160625153635.17173.21845.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 26 Jun 2016 00:05:27 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c053345b593d0536290797 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jun 2016 07:05:31 -0000 --001a11c053345b593d0536290797 Content-Type: text/plain; charset=UTF-8 A minor point: On Sat, Jun 25, 2016 at 8:36 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance of the IETF. > > Title : Recommended Usage of the Authenticated Received > Chain (ARC) > Authors : Steven Jones > John Rae-Grant > J. Trent Adams > Kurt Andersen > Filename : draft-ietf-dmarc-arc-usage-00.txt > Pages : 15 > Date : 2016-06-25 > > Abstract: > The Authentication Received Chain (ARC) provides a means to preserve > email authentication results and verify the identity of email message > handlers, each of which participates by inserting certain header > fields before passing the message on. But the specification does not > indicate how intermediaries and receivers should interpret or utilize > ARC. This document will provide guidance in these areas. > > This version shows an "Obsoletes" on the title page. It should be removed; "Obsoletes" is used when one published RFC replaces another. The draft named there in this version has already ceased to exist. -MSK --001a11c053345b593d0536290797 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A minor point:

On Sat, Jun 25, 2016 at 8:36 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Recommended Usage of the Authenticated Received Chain (ARC)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Stev= en Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Rae-Grant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 J. Trent Adams
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kurt Andersen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-arc-usage-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-25

Abstract:
=C2=A0 =C2=A0The Authentication Received Chain (ARC) provides a means to pr= eserve
=C2=A0 =C2=A0email authentication results and verify the identity of email = message
=C2=A0 =C2=A0handlers, each of which participates by inserting certain head= er
=C2=A0 =C2=A0fields before passing the message on.=C2=A0 But the specificat= ion does not
=C2=A0 =C2=A0indicate how intermediaries and receivers should interpret or = utilize
=C2=A0 =C2=A0ARC.=C2=A0 This document will provide guidance in these areas.=


This version shows an "Obsoletes&= quot; on the title page.=C2=A0 It should be removed; "Obsoletes" = is used when one published RFC replaces another.=C2=A0 The draft named ther= e in this version has already ceased to exist.

-MSK
<= /div>
--001a11c053345b593d0536290797-- From nobody Tue Jun 28 08:14:02 2016 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 3F8C712B053 for ; Tue, 28 Jun 2016 08:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK6CB5F94n7z for ; Tue, 28 Jun 2016 08:13:59 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961A912D09F for ; Tue, 28 Jun 2016 08:13:59 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id f6so17602076ith.0 for ; Tue, 28 Jun 2016 08:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IRcNpuvsVz6+lP9UQrYvVfTloo1l05cy60NxsAFKmXU=; b=YW9d+iQHRVxf2BxQPUgAJZrtcIF4+u3vBZPu0nUUEIlpczZHcZwJxkKAMGjFgmHO2T zM77ot8uzbvEp7xyOa3/oLyB7YcsEXQ3foVwsSIXkZiVUl4stZj0HMP+zHxechyJ4hqp 4sV2ExBUyBS7eYg4P4ebUCZ/xTjNgkoqTRuxM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IRcNpuvsVz6+lP9UQrYvVfTloo1l05cy60NxsAFKmXU=; b=cZiX8xiKPetTydIIDxWteDWGzl4fUZLnpJt4+1rJwHVRIy94HJa01EKYixzuVMjuKr NANzV8A2HHdBmi2TKd5r7XTk/beCaelZGkwOSKHtdSa1OYUe0e1FCQ2WX1Pk8Bgs82Iu A2qDw1Vaw5lJMeiFyH740nvke+ZO5VYbQkAALGj+GNcY3wDnPFvl1y5fZP2TFkuboyPy b58mTkLxIM10IQQbEdt1FCMIOB311A1cVGSjUwGH7q6Uq5MvjGCD4/0itfqUip9PxiKL LkX17oTO3FD2eCOlqBCoLUQ1gkA3r8eit9MSVj2pcpno+l7K6knlBfTfSpeSg8QlOIxY EeeQ== X-Gm-Message-State: ALyK8tIlf2A0caWNn0GyrSqj3jgIfSEIwgQHHukIePhVMRlka08oVRZRhlBq/EB5q9QwfeYNsiZxeFlK5aov+g== X-Received: by 10.36.46.133 with SMTP id i127mr14476061ita.69.1467126838773; Tue, 28 Jun 2016 08:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.2 with HTTP; Tue, 28 Jun 2016 08:13:58 -0700 (PDT) In-Reply-To: References: From: Kurt Andersen Date: Tue, 28 Jun 2016 08:13:58 -0700 Message-ID: To: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114ab09a10dfd105365816a2 Archived-At: Cc: Brandon Long , ARC Discussion Subject: Re: [dmarc-ietf] [arc-discuss] arc-05 draft released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 15:14:01 -0000 --001a114ab09a10dfd105365816a2 Content-Type: text/plain; charset=UTF-8 +dmarc@ietf.org since the protocol has been adopted there... On Sat, Jun 25, 2016 at 11:27 PM, Murray S. Kucherawy wrote: > On Sun, Jun 19, 2016 at 1:34 AM, Brandon Long wrote: > >> I recently wrote an authres parser and it seemed fairly easy to support >> both authres and aar, but I also wrote the parser with that expectation, >> not sure how easy/hard it would be to change that now. >> >> > The authres syntax is fairly irritating, an over abundance of allowance >> for CFWS and then using actual WS as a delimiter... that and the /version >> stuff made it hard to take short cuts. >> > > AR's CFWS use and use of WS as a delimiter is pretty much the same as most > other things in email as I recall, with the notable exception of DKIM. > > And, I'd think you can recycle it, you just pass it the part after the >> first semi-colon assuming the first stanza consists of i=N. >> > > The section defining AAR doesn't actually say that it's "i=N;" (with the > semi-colon). It should. Note though that the rest of that header field is > not pure tag=value syntax. > > So here's a bit of hand grenade: You could separate the AAR parts from the > AR parts by doing something like: > > ARC-Authentication-Results: i=1; > ar= > > That makes AAR into a purely tag=value syntax. If there's no need for any > part of ARC to care what the preserved thing is, this seems mighty clean. > > -MSK > I'm OK with this sort of strategy. Presumably the ar tag value would be canonicalized before encoding? --Kurt --001a114ab09a10dfd105365816a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+dmarc@ietf.org since the protocol has been adopted there...

=
On Sat, Jun 25, 2016 at 11:27 PM, Murray S. Kuch= erawy <superuser@gmail.com> wrote:
On Sun, Jun 19, 2016 at 1:3= 4 AM, Brandon Long <blong@google.com> wrote:
I recently wrote an authres parser and it seemed = fairly easy to support both authres and aar, but I also wrote the parser wi= th that expectation, not sure how easy/hard it would be to change that now.=
=C2=A0
The authres syntax is fairly irritating, an over abundance of allowa= nce for CFWS and then using actual WS as a delimiter... that and the /versi= on stuff made it hard to take short cuts.

=
AR's CFWS use and use of WS as a delimiter is pretty = much the same as most other things in email as I recall, with the notable e= xception of DKIM.

And, I'd think you can recycle it, you just p= ass it the part after the first semi-colon assuming the first stanza consis= ts of i=3DN.

The section= defining AAR doesn't actually say that it's "i=3DN;" (wi= th the semi-colon).=C2=A0 It should.=C2=A0 Note though that the rest of tha= t header field is not pure tag=3Dvalue syntax.

So here= 9;s a bit of hand grenade: You could separate the AAR parts from the AR par= ts by doing something like:

ARC-Authentication-Results: i= =3D1; ar=3D<base64-or-qp-encoded-copy-of-AR-you-want-to-preserve>
=
That makes AAR into a purely tag=3Dvalue syntax.=C2=A0 If th= ere's no need for any part of ARC to care what the preserved thing is, = this seems mighty clean.
=
-MSK

I'm OK with thi= s sort of strategy. Presumably the ar tag value would be canonicalized befo= re encoding?

--Kurt
--001a114ab09a10dfd105365816a2-- From nobody Tue Jun 28 09:35:19 2016 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 6A36912D0B8 for ; Tue, 28 Jun 2016 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dui5d8pdBSam for ; Tue, 28 Jun 2016 09:35:16 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3995012D094 for ; Tue, 28 Jun 2016 09:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1467131711; bh=YyszTAuA/puuAmXkdjjXPBnsHRpCE6kYv8T5JavgVT0=; l=1310; h=To:References:From:Date:In-Reply-To; b=fy39uN8DZaDRL+UpxlEqbFtPbQfDR4Olm6lTHhCiozjoivtq1YyZq/K3G5vWLuaLt KtwYKRtXFDuQHBwO/56f5gxb+b0uF5gpyRl9LBEoqu0SWj76Zwt5wg9ZlKZMTymeZr oEC3wifpursY3qDwYoh9m+fWYQZHnXZVbdA8WWow= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 28 Jun 2016 18:35:11 +0200 id 00000000005DC050.000000005772A73F.00000991 To: "dmarc@ietf.org" References: From: Alessandro Vesely Message-ID: <5772A73F.3020405@tana.it> Date: Tue, 28 Jun 2016 18:35:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [arc-discuss] arc-05 draft released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 16:35:18 -0000 On Tue 28/Jun/2016 17:13:58 +0200 Kurt Andersen wrote: > +dmarc@ietf.org since the protocol has been adopted > there... -ARC Discussion to reduce cross-posting... > On Sat, Jun 25, 2016 at 11:27 PM, Murray S. Kucherawy > wrote: > >> The section defining AAR doesn't actually say that it's "i=N;" (with the >> semi-colon). It should. Note though that the rest of that header field >> is not pure tag=value syntax. >> >> So here's a bit of hand grenade: You could separate the AAR parts from >> the AR parts by doing something like: >> >> ARC-Authentication-Results: i=1; >> ar= >> >> That makes AAR into a purely tag=value syntax. If there's no need for >> any part of ARC to care what the preserved thing is, this seems mighty >> clean. > > I'm OK with this sort of strategy. Presumably the ar tag value would be > canonicalized before encoding? What's wrong with something readable? E.g.: arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-instance [ CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF arc-instance = %x69 [FWS] "=" [FWS] 1*3DIGIT ";" ; i=N; Ale -- From nobody Tue Jun 28 10:18:05 2016 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 1F14712B078 for ; Tue, 28 Jun 2016 10:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAVoYs4jgTNp for ; Tue, 28 Jun 2016 10:18:02 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD9112B048 for ; Tue, 28 Jun 2016 10:18:02 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id a125so42021003qkc.2 for ; Tue, 28 Jun 2016 10:18: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:from:date:message-id:subject:to :cc; bh=odySb8rHFU73jntULZPjPjsPWTJBDJyKzVnXJS/7aFY=; b=l7+Z40brKY34TKBrVtkc+Th10QBB1KVwLM+5yvHg43/umDZwUMmfG9ZDtGXIT9fPQm LPIcLNk0fTZYIHKAn8cTyrvMsyTo+PTcVEWBcFHf3Qy4ZWkKRqkGbeizu8iw85/y56QJ xU5WrHEhzJNPgyu/qkeiUU0jhKh5jgge1vRfZeNwaxz5gbSM+8RHd92PpbXDN35Ybejf Zu9xVf38UtjV7uIi6pIYBKu3QqGZtGib7vDkAkYgJhQVHkLPHAcg2w6v/XmvsKKAL8WA nLRFNth7rcTkD2XEFthB7IDhexkjE4d7N7QPAsoCngo36CMFpoMlz7y/ye/YACpGWyqX mbUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=odySb8rHFU73jntULZPjPjsPWTJBDJyKzVnXJS/7aFY=; b=LjdDUuFGw7LYDmIvrtDWZnmga3UdWVLSrjm/Rtjq6ADqsSB4S3+bIYmEkZsuNg2Azd P7DK2QxNX86gO1/nFicqgjhUL/vKFx5Oe9W/+tLWNKYIxx9VBNbTvzuiF1Ho1DHBq3IT quVcxNBPK2INMqXBUAtSA5MU4sLLYJTGXTvi8A/3MdGQFccgumpGk72q6WgMPYA/bwVp pQfmnGQJgjL5brYUPuWA0OXvQd7HVaTOvh6YtFU/ATGR6Cfa4fbJ7oGQ43ZxrB/lEygI fX4bwbVHhM6RB8fFYpSQQGQD7NTi2+awSLVF+U4GxpirxMye81khKXwNceDnXPZEMHg/ PYGQ== X-Gm-Message-State: ALyK8tKHwCrArKFiLqnucn9lpS+UhJQt7PSZPyz3meRNySXFR/wt7FiwGVDIKu3aXs4trRoB0W3hCeNgvmms9w== X-Received: by 10.129.159.17 with SMTP id w17mr1508823ywg.168.1467134281226; Tue, 28 Jun 2016 10:18:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.145 with HTTP; Tue, 28 Jun 2016 10:18:00 -0700 (PDT) In-Reply-To: <5772A73F.3020405@tana.it> References: <5772A73F.3020405@tana.it> From: "Murray S. Kucherawy" Date: Tue, 28 Jun 2016 10:18:00 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=94eb2c0bd096aba850053659d174 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] [arc-discuss] arc-05 draft released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 17:18:04 -0000 --94eb2c0bd096aba850053659d174 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 28, 2016 at 9:35 AM, Alessandro Vesely wrote: > > What's wrong with something readable? E.g.: > > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-instance > [ CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > arc-instance = %x69 [FWS] "=" [FWS] 1*3DIGIT ";" > ; i=N; > I didn't say there was anything wrong with it. I'm just looking for a way to have all three ARC fields be parsable by a single grammar. Currently, AAR isn', because it's not a pure DKIM-style tag-value sequence. -MSK --94eb2c0bd096aba850053659d174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 28, 2016 at 9:35 AM, Alessandro Vesely <vesely@t= ana.it> wrote:

What's wrong with something readable?=C2=A0 E.g.:

=C2=A0 =C2=A0 =C2=A0arc-authres-header =3D "ARC-Authentication-Results= :" [CFWS] arc-instance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS] authserv-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS authres-version ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( no-result / 1*resinfo ) = [CFWS] CRLF

=C2=A0 =C2=A0 =C2=A0arc-instance =3D %x69 [FWS] "=3D" [FWS] 1*3DI= GIT ";"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; i=3DN;

I didn't say there was anything wrong with it.= =C2=A0 I'm just looking for a way to have all three ARC fields be parsa= ble by a single grammar.=C2=A0 Currently, AAR isn', because it's no= t a pure DKIM-style tag-value sequence.

-MSK
<= /div> --94eb2c0bd096aba850053659d174-- From nobody Tue Jun 28 15:09:28 2016 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 5CAE312D8F9 for ; Tue, 28 Jun 2016 15:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_-FjLb46W_E for ; Tue, 28 Jun 2016 15:09:25 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0973312D887 for ; Tue, 28 Jun 2016 15:09:25 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u5SM9BgG042898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 28 Jun 2016 15:09:17 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u5SM9BgG042898 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1467151757; bh=AGkxVuY8wqsxK7hOWsmUB9J952byMIAltWobE98aHok=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nVCunXpUtJMWmRmfv+sSkiegrWEihh7mgn7eleeWH+AaWCzlGveFjXypa1/7Uwc4V ahlsC2qCjrC1NTzxp6mCptN9nsU/Ymj9Agq2eb7RhykTz7oiqHS4zMoLtB8QW52Fjh qeTSEL84HvvKRbnuUBEiir//ez2r2U31HsH3Ubwa35f9+509LuEqETuHbEPz4gxY00 wmLdbj2+qXlf5gYv9pQ/LmntNZVhzisSFKrzs4p3SLWJohp4z7iF9FlgAZpoOQoVKt E7sK9lhzw6PO13H5gX/9zmQ5s6JoIvUPWIvDmMpDrnEIUmjMBAAwkUhIb2nPLWypmB K/Qr56kfPrJOg== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com To: dmarc-discuss@dmarc.org, dmarc@ietf.org References: <5c839231-2f7f-1140-aab0-92076cdbde65@andreasschulze.de> From: Steven M Jones Organization: Crash Computing Message-ID: Date: Tue, 28 Jun 2016 15:09:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5c839231-2f7f-1140-aab0-92076cdbde65@andreasschulze.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 28 Jun 2016 15:09:17 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] [dmarc-discuss] ARC adoption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 22:09:27 -0000 + dmarc@ietf.org list to capture for ARC discussion/archive On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > Kurt just mention adoption in his last message. > Adoption is a good point, I've two questions: > > 1) > are there implementation available as open source? There is an OpenARC milter under development - it currently runs and signs messages. A few bugs turned up at the last interop have been fixed, but I have to see if the signatures/seals now verify. There are two modified versions of the dkimpy library that perform ARC operations. If one - as planned - will be the basis for an implementation in a mailing list manager, it will become publicly available. The author of the other implementation is on these lists, but it's up to them whether or not to discuss it further publicly. I was told of another effort that might result in a Perl module/library for performing ARC operations, but it had stalled and I haven't had an update on that for a while. > I'm aware Google has some code. There is one other large mailbox provider who has a functioning implementation, and these two implementations are working when tested against each other, and with one of the dkimpy libraries. > 2) > a general point I'm still unsure about: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) > "If the mailing list implemented ARC, ..." > > ARC *require* the list operator (Intermediary) to install new or update > existing - right? > But the list operators fail over the last years to do so. Why should I > expect they will do now? > p=reject on google/gmail/googlemail may generate the required pressure > but that doesn't sound like the best way to achieve adoption. Section 2 of the Usage doc describes how ARC works. The phrase "If the mailing list..." just indicates what would happen differently after ARC functionality was added - it isn't addressing the question of when, how, or why an MLM operator would update their software. Some kind of change will be required for virtually any application - MLM, forwarding service, etc - to implement ARC. The only scenario I can see where the application operator themselves didn't make a change, is if a different group deployed an ARC signing capability to a downstream MTA still within the ADMD that the application operates in. But somebody is still making a change... Your question about motivation is a good one. I don't think there's any way to coerce everybody to implement ARC - or anything else, for that matter. If there were, the Internet would be a very different place. However I think we will see a standard "long tail" curve of adoption. Once the protocol is fully tested and implementations released, there will be a surge of early adopters - people who do it because they always look for better ways to operate, ways to make sure their mail - or their customers' mail - gets delivered cleanly everywhere, etc. Another increment will raise the level slowly as packages like Mailman and Sympa are updated (assuming they will be) and a natural upgrade cycle occurs. This is a slow process, and not everybody will do so. Will there be spikes as more senders or mailbox providers publish DMARC p=reject policies? Maybe - if the provider is large enough, then "definitely." But there are only so many of those that would make a measurable impact, and even then it won't be universal. I think smaller application operators - MLMs, forwarding services, etc - may feel pressure to adopt ARC simply because they are below the volume thresholds where medium to large mailbox providers make exceptions for them, or even identify them as such. In some percentage of cases where their messages are misidentified, or have some tricky content, they'll have issues and in some cases turn to ARC. FOSS options, and MLM support, will be critical for these cases. Will they all do so? Of course not. Just as I'm sure somebody out there is still running sendmail 5.65 on SunOS 4.x, somebody out there will continue to run some version of Majordomo and never change it. Anybody have data on the adoption rate of the RFC2369 List-*: headers? I doubt those jumped from 0 to 100 overnight, but they're very wide-spread now. And I suspect there would be an interesting comparison to the uptake of ARC over time. --Steve. Steve Jones DMARC.org e: smj@dmarc.org, smj@crash.com From nobody Tue Jun 28 15:14:56 2016 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 9072412D905 for ; Tue, 28 Jun 2016 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2otov4He0jat for ; Tue, 28 Jun 2016 15:14:52 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA1312D907 for ; Tue, 28 Jun 2016 15:14:50 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id s63so29925405ioi.3 for ; Tue, 28 Jun 2016 15:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=GEuy1r3+m6pHjkegfCs3uRuvVkfGNrd/TEXvCRoQUE8=; b=XXegWEE6VfHxmAWulsXVDb2xIZ0JDR+YqE/deAZ7yPb+FUkex9ZXInlBBmucQeBjkp 2E20yKYgCJRW1164ivbjeovjRULcGmsVISmlEzOKaFHAGeCIuWycXjITRvkzburOx7T+ WtiO2SRMyL7JtvvKfGuYy1FSR6UFS9ufIZdSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=GEuy1r3+m6pHjkegfCs3uRuvVkfGNrd/TEXvCRoQUE8=; b=Rh44tOZsvEltcvaIG1xs/k93GndKVEDneVmB9Mxh8cysc3n62cGj6A+MIf3vSITaOY v0xU4vB+2p1qeT1bvWTQC8kVrIsJvnuFRKgPhqGbezcmmFeQh5ylVIktch7nhdyrTKGk ANCn0fa0Q8FCOL/xHpdfKf7xoPbg7JuFHN7jL6eCBvzCILN55ZYkqHJ3s5FdolRR5DZg TpsR1TerbZ/EbSF1UuqyjAQLs15MSDyg3B/Dp8ldVZ4IG8KCEuufdevDlRsEAehhDIMa FArsNApE5eDNCDPfLTLmpi5ku1ccNbLJBjLDF9Agh3MpJfvfPS1qyNe1sJGsMoc6EUwP VbSw== X-Gm-Message-State: ALyK8tKMzFQHPqSijk6awUkhngyiOtiw38jvtrYg1bDRQty/3QjgFfaeLpdxW10AemetW+fU1bKYBvKB4RQSBQ== X-Received: by 10.107.10.35 with SMTP id u35mr6024238ioi.92.1467152089572; Tue, 28 Jun 2016 15:14:49 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.107.5.2 with HTTP; Tue, 28 Jun 2016 15:14:49 -0700 (PDT) From: "Kurt Andersen (b)" Date: Tue, 28 Jun 2016 15:14:49 -0700 X-Google-Sender-Auth: 2jmVu0pZAtmRyUhs7xJfvA5Gfbc Message-ID: To: Steven M Jones Content-Type: multipart/alternative; boundary=001a113f9196217f0905365df71a Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ARC adoption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 22:14:54 -0000 --001a113f9196217f0905365df71a Content-Type: text/plain; charset=UTF-8 -dmarc-discuss On Tue, Jun 28, 2016 at 3:09 PM, Steven M Jones wrote: > + dmarc@ietf.org list to capture for ARC discussion/archive > > On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > > > Kurt just mention adoption in his last message. > > Adoption is a good point, I've two questions: > > > > 1) are there implementation available as open source? > For additional details about the current "Implementation Status" of ARC, you can check out the section of the document bearing that phrase. --Kurt --001a113f9196217f0905365df71a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-dma= rc-discuss

On Tue, Jun 28, 2016 at 3:09 PM, Steven M Jones <= smj@crash.com> wrote:
+ dmarc@ietf.org list to capture for ARC discussion/archive

On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote:
>
> Kurt just mention adoption in his last message.
> Adoption is a good point, I've two questions:
>
> 1)=C2=A0are there implementation available as open source?
=C2=A0
For additional details about the current "I= mplementation Status" of ARC, you can check out the section of the doc= ument bearing that phrase.

--Kurt=C2=A0
--001a113f9196217f0905365df71a-- From nobody Tue Jun 28 15:30:34 2016 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 64D2712D86D for ; Tue, 28 Jun 2016 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPk3UIOJsQMd for ; Tue, 28 Jun 2016 15:30:30 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3586C12D695 for ; Tue, 28 Jun 2016 15:30:30 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 5AF70520298; Tue, 28 Jun 2016 18:30:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 0C658C214B; Tue, 28 Jun 2016 17:30:29 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FZIRdnHCo68B; Tue, 28 Jun 2016 17:30:28 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 197D8C2E58; Tue, 28 Jun 2016 17:30:28 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com 197D8C2E58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1467153028; bh=WKKPBR4O82Yp4ckB3RZcVSBRUcRVe9rdFnSUY5jAdXY=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=m+ERjFOhrzx94KyZWeAE8L2wsEhcKTooMulqgVi4FQUI0TGTTZTiolaQYMj9siQFa ScBEiPBQTctzTNENGBMBl/EFWERWi+CvJsqiBXsUdFxbqin2RyR/1LxPJ3mOP/whdX s754zgj3sohIV48emTi0Cg9tzTQKEGBuNGuyVIGQ= X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id natelG8ssGMB; Tue, 28 Jun 2016 17:30:27 -0500 (CDT) Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id DBD04C2B80; Tue, 28 Jun 2016 17:30:27 -0500 (CDT) Date: Tue, 28 Jun 2016 17:30:27 -0500 (CDT) From: Franck Martin To: "Kurt Andersen (b)" Message-ID: <174419358.1060459.1467153027708.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1060458_1789019259.1467153027707" X-Originating-IP: [208.184.221.212] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF47 (Mac)/8.6.0_GA_1194) Thread-Topic: ARC adoption Thread-Index: C1zuI5WBWX8SqyxGh32N6Mrzttp3qw== Archived-At: Cc: dmarc@ietf.org, Steven M Jones Subject: Re: [dmarc-ietf] ARC adoption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jun 2016 22:30:32 -0000 ------=_Part_1060458_1789019259.1467153027707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > From: "Kurt Andersen (b)" > To: "Steven M Jones" > Cc: dmarc@ietf.org > Sent: Tuesday, June 28, 2016 3:14:49 PM > Subject: Re: [dmarc-ietf] ARC adoption > -dmarc-discuss > On Tue, Jun 28, 2016 at 3:09 PM, Steven M Jones < smj@crash.com > wrote: >> + dmarc@ietf.org list to capture for ARC discussion/archive >> On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: >> > Kurt just mention adoption in his last message. >> > Adoption is a good point, I've two questions: >> > 1) are there implementation available as open source? > For additional details about the current "Implementation Status" of ARC, you can > check out the section of the document bearing that phrase. Also, when a tarball is released, someone needs to do a rpm (or package) of it, then this rpm needs to be included in the linux distro. It seems to me this cycle is about a year. I don't ex pect many people to upgrade from tarballs. ------=_Part_1060458_1789019259.1467153027707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Kurt Andersen (b)" <kboth@drkurt.com>
To: "Steven M Jones= " <smj@crash.com>
Cc: dmarc@ietf.org
Sent: Tuesda= y, June 28, 2016 3:14:49 PM
Subject: Re: [dmarc-ietf] ARC adoptio= n
-dmarc-discuss

=
On Tue, Jun 28, 2016 at 3:09 PM, Steven M Jones = <smj@crash.com> wrote:
+ dmarc@= ietf.org list to capture for ARC discussion/archive

On 06/28/20= 16 09:12, A. Schulze via dmarc-discuss wrote:
>
> Kurt just m= ention adoption in his last message.
> Adoption is a good point, I'v= e two questions:
>
> 1) are there implementation availab= le as open source?
For additional details about the cu= rrent "Implementation Status" of ARC, you can check out the section of the = document bearing that phrase.

Also, = when a tarball is released, someone needs to do a rpm (or package) of it, t= hen this rpm needs to be included in the linux distro. It seems to me this = cycle is about a year.

= I don't expect m= any people to upgrade from tarballs.
------=_Part_1060458_1789019259.1467153027707-- From nobody Wed Jun 29 00:22:29 2016 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 06FBB12D8F0 for ; Wed, 29 Jun 2016 00:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ma5kn2DNjN8 for ; Wed, 29 Jun 2016 00:22:26 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C6212D1D7 for ; Wed, 29 Jun 2016 00:22:26 -0700 (PDT) Received: from shiny.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u5T7M5bA048538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2016 00:22:11 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u5T7M5bA048538 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1467184931; bh=AlrMSYEo1e9EzE/17EgoD8A881F+0P8eeVokPqrW4Fw=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H1pfyJbr1dzErPNL+kC5kuQ8AlNpjWdxmYdr4LBovxPqfeq6fJmfFPaoAMAaHvTgI ZlCbV0fa47DAthP+PQwol5oyiFnJ216iuj/obaB5kD/YJvqI0ThXdvwfhsMXsts0V4 ULvZ9VnYfKizX71OBQkvZNIPOttLsaw8gSBLj0nRDVMXQ/t0zk9XfLLAe4UYBYpX2S 5XbmepxQKaRhvWTBgTWHmGHl1Aq/mFy3sZ+qlLnVS3+blUKDUfAQ+pjy65csqAuaOE tfWkoNIQg3VqjVfKF5ULNamzlUFvII33Xc7GlntiuqrGsJkf7u4bdVxxgPtR4MzoER S0FXPs86a1VlQ== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be shiny.crash.com To: dmarc-discuss@dmarc.org, dmarc@ietf.org References: <5c839231-2f7f-1140-aab0-92076cdbde65@andreasschulze.de> From: Steven M Jones Message-ID: <60a3eab5-178f-0d5c-eea6-e9a668dc656d@crash.com> Date: Wed, 29 Jun 2016 00:22:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Wed, 29 Jun 2016 00:22:11 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] [dmarc-discuss] ARC adoption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 29 Jun 2016 07:22:28 -0000 + dmarc@ietf.org because Roland's responses should be considered/captured there too. Additional comment bottom-posted. On 6/29/16 12:09 AM, Roland Turner via dmarc-discuss wrote: > Andreas Schulze wrote: > >> 2) >> a general point I'm still unsure about: >> >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) >> >>> "If the mailing list implemented ARC, ..." >> ARC *require* the list operator (Intermediary) to install new or update existing - right? > No. ARC seeks to construct a situation in which forwarders and receivers will each gain incremental benefit if they choose to implement; it neither requires nor assumes implementation by any particular participant. > >> But the list operators fail over the last years to do so. Why should I expect they will do now? > List operators typically cite two compelling reasons for not making changes to support pre-ARC schemes: > > 1) the assumption that they're being asked to expend resources to solve someone else's problems; and > 2) even if resource constraints are ignored, each of the proposed changes imposes harmful dilemmas (each option, including do nothing, is harmful). > > ARC directly addresses (2). Unlike the measures for interoperating with earlier schemes, adding an ARC-* header set does not in any way impede or alter the traditional operation of mailing lists. Consequently: if list operators perceive benefit in implementing ARC, then they're free to do so without having to incur additional operational problems, in particular without changing user experience. > > (1) is not a big problem; for a list operator who doesn't have a problem that ARC addresses there is no reason for them to implement ARC, and it doesn't matter to anyone else if they don't. > > - Roland Well put, Roland. I was so concerned with addressing the frequently asked question of "why will people upgrade" that I overlooked other considerations in my earlier response. --S. From nobody Wed Jun 29 17:41:55 2016 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 BDA5D12D96E for ; Wed, 29 Jun 2016 17:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh_fSNsq8w4R for ; Wed, 29 Jun 2016 17:41:51 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB07312D6A9 for ; Wed, 29 Jun 2016 17:41:51 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id u201so43326325oie.0 for ; Wed, 29 Jun 2016 17:41:51 -0700 (PDT) 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; bh=0kxL+FsBIZZhEph/cf0rUeM3rJ4yPyD1X9WMjuvurF8=; b=JXgx5vUqrgxyGKJCt9l+Kc8lu3Muav5t7iakxMm7xmv45y4RzIlGt3J7+96nxElPEH tO/OuZf+odwdseHIwYxU/hfRKAHjHecwu4SeTaMCQqNv+w5ETwYGlIrbo8XpTTNieWg1 J3QanmPgLF48ENNzayuXVnF69pqe+0faNMyU/Cli59ByT1UiL3eDrs95nbGUDIA00W7W rOUj3cGVDk+zRHoKcS/Kf8BNqqDgT7pTU/i8zTa4aGNg69PhWSCGJiER6UXmzRNxN3EJ r51Uj/ZwYmwRXFHyo39fvfh8EUo0FMAEh9HTWJweu2g4kTa/5DWb0SJgMdIcENUgOOYU A3YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0kxL+FsBIZZhEph/cf0rUeM3rJ4yPyD1X9WMjuvurF8=; b=KmZeLuqlydiq8nXsipJrkQEwkCDsJVQoG8w3xJyNngcRYa+N46NzP6bAWC15ucwpGO F10i4d4CIvoUfTGLTVx7QcM6P+SSACzfuckPJlRm5Y0RwabEG85psnqu15NJRTREcNKv SIrIqhEDLU0L3665jBH/zvS9jhtpofCKEWzPJJ0txYp8Q+MISgmh6/j7D2aRTmgM0g3s /VPe7eAxXhtyaTY1UOWO+iHu2bshkK8oD2AlQFBN0xaTGX3ePgEwG01vRheHAylVnVUg KhCZMRxh0GCeGDen70BCiOUaHh3vYhfeGv5LPvBKwczxoePTaz0boTZwOhr0pw0FAqnQ 9AIg== X-Gm-Message-State: ALyK8tIS/eUIQAEFIMr40xibEu4cUm/5OBJFQBHfjyzyuIE9gqaXEhYdurzEa1T7KbAWqdVFzwbimO3brZayFwHG MIME-Version: 1.0 X-Received: by 10.157.39.75 with SMTP id r69mr7250129ota.181.1467247310972; Wed, 29 Jun 2016 17:41:50 -0700 (PDT) Received: by 10.157.45.99 with HTTP; Wed, 29 Jun 2016 17:41:50 -0700 (PDT) Received: by 10.157.45.99 with HTTP; Wed, 29 Jun 2016 17:41:50 -0700 (PDT) In-Reply-To: References: <5772A73F.3020405@tana.it> Date: Wed, 29 Jun 2016 17:41:50 -0700 Message-ID: From: Brandon Long To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a113cf512c53b42053674222b Archived-At: Cc: dmarc@ietf.org, Alessandro Vesely Subject: Re: [dmarc-ietf] [arc-discuss] arc-05 draft released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 00:41:54 -0000 --001a113cf512c53b42053674222b Content-Type: text/plain; charset=UTF-8 I'd hate to lose the readability of this field by encoding it like that. I understand the desire to simplify, but arc users are going to need an authres parser to take advantage of the data it provides, so it seems like a good idea to include one. Brandon On Jun 28, 2016 12:18 PM, "Murray S. Kucherawy" wrote: > On Tue, Jun 28, 2016 at 9:35 AM, Alessandro Vesely wrote: > >> >> What's wrong with something readable? E.g.: >> >> arc-authres-header = "ARC-Authentication-Results:" [CFWS] >> arc-instance >> [ CFWS] authserv-id >> [ CFWS authres-version ] >> ( no-result / 1*resinfo ) [CFWS] CRLF >> >> arc-instance = %x69 [FWS] "=" [FWS] 1*3DIGIT ";" >> ; i=N; >> > > I didn't say there was anything wrong with it. I'm just looking for a way > to have all three ARC fields be parsable by a single grammar. Currently, > AAR isn', because it's not a pure DKIM-style tag-value sequence. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113cf512c53b42053674222b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd hate to lose the readability of this field by encodi= ng it like that.

I understand the desire to simplify, but arc users are going= to need an authres parser to take advantage of the data it provides, so it= seems like a good idea to include one.

Brandon


On Jun 28, 2016 1= 2:18 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
On Tue, Jun 28, 2016 at 9:35 AM, A= lessandro Vesely <vesely@tana.it> wrote:

What's wrong with something readable?=C2=A0 E.g.:

=C2=A0 =C2=A0 =C2=A0arc-authres-header =3D "ARC-Authentication-Results= :" [CFWS] arc-instance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS] authserv-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ CFWS authres-version ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( no-result / 1*resinfo ) = [CFWS] CRLF

=C2=A0 =C2=A0 =C2=A0arc-instance =3D %x69 [FWS] "=3D" [FWS] 1*3DI= GIT ";"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; i=3DN;

I didn't say there was anything wrong with it.= =C2=A0 I'm just looking for a way to have all three ARC fields be parsa= ble by a single grammar.=C2=A0 Currently, AAR isn', because it's no= t a pure DKIM-style tag-value sequence.

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

--001a113cf512c53b42053674222b-- From nobody Wed Jun 29 17:49:20 2016 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 AB21212D974 for ; Wed, 29 Jun 2016 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO6fSBjNe7D0 for ; Wed, 29 Jun 2016 17:49:14 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADE912D8B7 for ; Wed, 29 Jun 2016 17:49:13 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id r2so43509042oih.2 for ; Wed, 29 Jun 2016 17:49:13 -0700 (PDT) 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; bh=S+b6idY5wDTLlh7wnJ6gZZWPK5fIGdRu7DE6psjuYhU=; b=M/fE7IgtKbGCxxoW6a6TrZNfCem8yE5o5myjwPSe3I7ZzftcW0l3EsvVAusNqDOUtg XKMYlxGI/LvjgUwMan8VgZ7XvpN2CtnxZ0ETcO5FH5jFPhNrxeD/yGnCRr5a0zjNQabk oqWveTU6EmW7/d9k/vvy7iLPToVhrUq5nQvDe3OHZsscwlAIDZr0RGXQDNraf5lt28tO uImOvsDsllzVUkPXBW+mYz11hgUGeGtBLA9qKhxZLHPBSaPDPB1ZkAK4HIexNUK1nd6p LeBGltfpAJxb6J5ht9zvptc4SX2ifbaKQAVUQnnkeSSuxqLQ61uAKATPNiE6KQV7VKoa 8ZaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S+b6idY5wDTLlh7wnJ6gZZWPK5fIGdRu7DE6psjuYhU=; b=OmuCM4QDhTi13SYdjuMaoBsWVODzC+UvhfkvFaSKM/hHHT1J7KpkW+hOlqN2oTcPbs 77eCUHkYRUgU0WKVDOo9qsqdRM6AuR0y0L5fZ4/7hjsFWpptkEuA2YSjID7XyfI3jYs0 Zv52R5H/mhkG4R6JH/8jQGOcJQgo9roMpxeJmBeOq0ucJV9jvqxnsFTcJ2IG9KXxzKGK vXrJUFVh5H6/ZAAC2bcgoKhihdMlicIIwi1xoXAezC+YKNiGqBLN6+A6RiAtIQ9cczWJ MhoOUuT8hXFFBb2ELV70UNoQFyR30ze53lwCw5Rv5WEdGr0GJQ+Jx02ihuSiKELLf/fv LPkA== X-Gm-Message-State: ALyK8tJ8Ciitiu4Wq3+XrJ8J2uYCA58O0gPZtK5612Z8GPj/2zXWHkiQERKQcUT0jHhJ9pRJkkArFPJ+6kDLn027 MIME-Version: 1.0 X-Received: by 10.157.34.170 with SMTP id y39mr7886792ota.66.1467247752857; Wed, 29 Jun 2016 17:49:12 -0700 (PDT) Received: by 10.157.45.99 with HTTP; Wed, 29 Jun 2016 17:49:09 -0700 (PDT) Received: by 10.157.45.99 with HTTP; Wed, 29 Jun 2016 17:49:09 -0700 (PDT) In-Reply-To: References: <5c839231-2f7f-1140-aab0-92076cdbde65@andreasschulze.de> Date: Wed, 29 Jun 2016 17:49:09 -0700 Message-ID: From: Brandon Long To: Steven M Jones Content-Type: multipart/alternative; boundary=94eb2c0363441baf090536743d92 Archived-At: Cc: dmarc@ietf.org, dmarc-discuss@dmarc.org Subject: Re: [dmarc-ietf] [dmarc-discuss] ARC adoption X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 00:49:19 -0000 --94eb2c0363441baf090536743d92 Content-Type: text/plain; charset=UTF-8 I'm the author of one of the dkimpy mods to support arc, and I'm happy to share it. It's been sent to the dkimpy maintainer for inclusion, but he's been busy. It appears at this point to be correct, but it may not be pretty. Brandon On Jun 28, 2016 5:09 PM, "Steven M Jones" wrote: > + dmarc@ietf.org list to capture for ARC discussion/archive > > On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote: > > > > Kurt just mention adoption in his last message. > > Adoption is a good point, I've two questions: > > > > 1) > > are there implementation available as open source? > > There is an OpenARC milter under development - it currently runs and > signs messages. A few bugs turned up at the last interop have been > fixed, but I have to see if the signatures/seals now verify. > > There are two modified versions of the dkimpy library that perform ARC > operations. If one - as planned - will be the basis for an > implementation in a mailing list manager, it will become publicly > available. The author of the other implementation is on these lists, but > it's up to them whether or not to discuss it further publicly. > > I was told of another effort that might result in a Perl module/library > for performing ARC operations, but it had stalled and I haven't had an > update on that for a while. > > > I'm aware Google has some code. > > There is one other large mailbox provider who has a functioning > implementation, and these two implementations are working when tested > against each other, and with one of the dkimpy libraries. > > > > 2) > > a general point I'm still unsure about: > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) > > "If the mailing list implemented ARC, ..." > > > > ARC *require* the list operator (Intermediary) to install new or update > > existing - right? > > But the list operators fail over the last years to do so. Why should I > > expect they will do now? > > p=reject on google/gmail/googlemail may generate the required pressure > > but that doesn't sound like the best way to achieve adoption. > > Section 2 of the Usage doc describes how ARC works. The phrase "If the > mailing list..." just indicates what would happen differently after ARC > functionality was added - it isn't addressing the question of when, how, > or why an MLM operator would update their software. > > Some kind of change will be required for virtually any application - > MLM, forwarding service, etc - to implement ARC. The only scenario I can > see where the application operator themselves didn't make a change, is > if a different group deployed an ARC signing capability to a downstream > MTA still within the ADMD that the application operates in. But somebody > is still making a change... > > Your question about motivation is a good one. I don't think there's any > way to coerce everybody to implement ARC - or anything else, for that > matter. If there were, the Internet would be a very different place. > > However I think we will see a standard "long tail" curve of adoption. > Once the protocol is fully tested and implementations released, there > will be a surge of early adopters - people who do it because they always > look for better ways to operate, ways to make sure their mail - or their > customers' mail - gets delivered cleanly everywhere, etc. > > Another increment will raise the level slowly as packages like Mailman > and Sympa are updated (assuming they will be) and a natural upgrade > cycle occurs. This is a slow process, and not everybody will do so. > > Will there be spikes as more senders or mailbox providers publish DMARC > p=reject policies? Maybe - if the provider is large enough, then > "definitely." But there are only so many of those that would make a > measurable impact, and even then it won't be universal. > > I think smaller application operators - MLMs, forwarding services, etc - > may feel pressure to adopt ARC simply because they are below the volume > thresholds where medium to large mailbox providers make exceptions for > them, or even identify them as such. In some percentage of cases where > their messages are misidentified, or have some tricky content, they'll > have issues and in some cases turn to ARC. FOSS options, and MLM > support, will be critical for these cases. > > Will they all do so? Of course not. Just as I'm sure somebody out there > is still running sendmail 5.65 on SunOS 4.x, somebody out there will > continue to run some version of Majordomo and never change it. > > Anybody have data on the adoption rate of the RFC2369 List-*: headers? I > doubt those jumped from 0 to 100 overnight, but they're very wide-spread > now. And I suspect there would be an interesting comparison to the > uptake of ARC over time. > > --Steve. > > Steve Jones > DMARC.org > > e: smj@dmarc.org, smj@crash.com > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c0363441baf090536743d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm the author of one of the dkimpy mods to support arc,= and I'm happy to share it.=C2=A0 It's been sent to the dkimpy main= tainer for inclusion, but he's been busy.=C2=A0 It appears at this poin= t to be correct, but it may not be pretty.

Brandon


On Jun 28, 2016 5= :09 PM, "Steven M Jones" <smj= @crash.com> wrote:
+ dmarc@ietf.org list to captur= e for ARC discussion/archive

On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote:
>
> Kurt just mention adoption in his last message.
> Adoption is a good point, I've two questions:
>
> 1)
> are there implementation available as open source?

There is an OpenARC milter under development - it currently runs and
signs messages. A few bugs turned up at the last interop have been
fixed, but I have to see if the signatures/seals now verify.

There are two modified versions of the dkimpy library that perform ARC
operations. If one - as planned - will be the basis for an
implementation in a mailing list manager, it will become publicly
available. The author of the other implementation is on these lists, but it's up to them whether or not to discuss it further publicly.

I was told of another effort that might result in a Perl module/library
for performing ARC operations, but it had stalled and I haven't had an<= br> update on that for a while.

> I'm aware Google has some code.

There is one other large mailbox provider who has a functioning
implementation, and these two implementations are working when tested
against each other, and with one of the dkimpy libraries.


> 2)
> a general point I'm still unsure about:
>
> https://datatracker.ietf.org/doc/dra= ft-ietf-dmarc-arc-usage say in 2.)
> "If the mailing list implemented ARC, ..."
>
> ARC *require* the list operator (Intermediary) to install new or updat= e
> existing - right?
> But the list operators fail over the last years to do so. Why should I=
> expect they will do now?
> p=3Dreject on google/gmail/googlemail may generate the required pressu= re
> but that doesn't sound like the best way to achieve adoption.

Section 2 of the Usage doc describes how ARC works. The phrase "If the=
mailing list..." just indicates what would happen differently after AR= C
functionality was added - it isn't addressing the question of when, how= ,
or why an MLM operator would update their software.

Some kind of change will be required for virtually any application -
MLM, forwarding service, etc - to implement ARC. The only scenario I can see where the application operator themselves didn't make a change, is<= br> if a different group deployed an ARC signing capability to a downstream
MTA still within the ADMD that the application operates in. But somebody is still making a change...

Your question about motivation is a good one. I don't think there's= any
way to coerce everybody to implement ARC - or anything else, for that
matter. If there were, the Internet would be a very different place.

However I think we will see a standard "long tail" curve of adopt= ion.
Once the protocol is fully tested and implementations released, there
will be a surge of early adopters - people who do it because they always look for better ways to operate, ways to make sure their mail - or their customers' mail - gets delivered cleanly everywhere, etc.

Another increment will raise the level slowly as packages like Mailman
and Sympa are updated (assuming they will be) and a natural upgrade
cycle occurs. This is a slow process, and not everybody will do so.

Will there be spikes as more senders or mailbox providers publish DMARC
p=3Dreject policies? Maybe - if the provider is large enough, then
"definitely." But there are only so many of those that would make= a
measurable impact, and even then it won't be universal.

I think smaller application operators - MLMs, forwarding services, etc - may feel pressure to adopt ARC simply because they are below the volume
thresholds where medium to large mailbox providers make exceptions for
them, or even identify them as such. In some percentage of cases where
their messages are misidentified, or have some tricky content, they'll<= br> have issues and in some cases turn to ARC. FOSS options, and MLM
support, will be critical for these cases.

Will they all do so? Of course not. Just as I'm sure somebody out there=
is still running sendmail 5.65 on SunOS 4.x, somebody out there will
continue to run some version of Majordomo and never change it.

Anybody have data on the adoption rate of the RFC2369 List-*: headers? I doubt those jumped from 0 to 100 overnight, but they're very wide-sprea= d
now. And I suspect there would be an interesting comparison to the
uptake of ARC over time.

--Steve.

Steve Jones
DMARC.org

e: smj@dmarc.org, smj@crash.com


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--94eb2c0363441baf090536743d92-- From nobody Thu Jun 30 06:43:58 2016 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 3749712D7CD for ; Tue, 21 Jun 2016 22:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linkedin.com header.b=TmUCefMX; dkim=pass (1024-bit key) header.d=linkedin.com header.b=SsmEP0zi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jpCo8cOeFUZ for ; Tue, 21 Jun 2016 22:08:51 -0700 (PDT) Received: from mail521.linkedin.com (mail521.linkedin.com [108.174.6.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC9012D8B9 for ; Tue, 21 Jun 2016 22:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1466572125; bh=W4xfICZtKlbdZ04GvDqxY0V7ziwYPj84M0uElSAAVF0=; h=MIME-Version:Date:Subject:From:To:Content-Type; b=TmUCefMX/900oB7c9qY6ImJW038J8/s1m5QjK+iJ5PrlpnI7FN/fdVPYkrABJaF9C CLyaSUlUsBWBEYarBSAbX3zV83qt6e0WjXfyctwakexa2nNGQhnY/fitEI0QVY0DgG L/UgqmwkYmzqTH9eCK20PrkqLwPVFvhz2Z2/6m/I= Authentication-Results: mail521.prod.linkedin.com x-tls.subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com"; auth=pass (cipher=ECDHE-RSA-AES128-GCM-SHA256) Authentication-Results: mail521.prod.linkedin.com; iprev=pass policy.iprev="2607:f8b0:4003:c01::248"; spf=softfail smtp.mailfrom="kandersen@linkedin.com" smtp.helo="mail-ob0-x248.google.com"; dkim=pass header.d=linkedin.com; tls=pass (verified) key.ciphersuite="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" key.length="128" tls.v="tlsv1.2" cert.client="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com" cert.clientissuer="C=US,O=Google Inc,CN=Google Internet Authority G2" Received: from [2607:f8b0:4003:c01::248] ([2607:f8b0:4003:c01::248.34454] helo=mail-ob0-x248.google.com) by mail521.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=ECDHE-RSA-AES128-GCM-SHA256 subject="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com") id 46/79-06186-D5D1A675; Wed, 22 Jun 2016 05:08:45 +0000 Received: by mail-ob0-x248.google.com with SMTP id at7so10175786obd.1 for ; Tue, 21 Jun 2016 22:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=google; h=mime-version:date:message-id:subject:from:to:cc; bh=W4xfICZtKlbdZ04GvDqxY0V7ziwYPj84M0uElSAAVF0=; b=SsmEP0zigX2qtvr5yFcfjXUB5zibThgexkLLLf1OMnpTlx8xJz8SCZZG6sCh0Ni5/a tjdNr4OkQrf/524+NHcmdmVOhWmkFceXMcn6mCX7tTdxa+TDg8akkZUtJvZQWMnkESaY LZowpDxM4ftW50ttn+RlXUv4btppXKg1yXG7E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=W4xfICZtKlbdZ04GvDqxY0V7ziwYPj84M0uElSAAVF0=; b=RkvxmfGtqiGU95xyeps/s+mn4o0BD5h0ZSwLwlSG4D9dO8mEOtJ8zjWCxvmJEGz85p /owJ3awaiHq6HKwvPqmp9V511hpTOwQ930Hy44n0qjN69Jo2mu3n6covnIn2sxwMsiPy Ys0syFgzdfGhAx2TmbXvCJWOiv8xfjwElAqlwaEacqp7S7d5lxeazPmgu34iYioAiFsV VRsnci/rfkD5+8XnZG2NTuBqZyfzSX/C2eOZKYIu9JwYwX+lsE+8HmileX6vLjFvEoBI vW6OseGAOWZ11CFeejrp8vEgzNgcxBKoZnOtq8FfObFM9QDI1UvASCQq1A4sq8yGqMIm LXyQ== X-Gm-Message-State: ALyK8tKlcNPkKebbRFOMZtPu17lFM3f/J7yWvQukwixjyM/nS73cFYiIsuCLlJ76gg3EK+HWFA6TIsPiWFW15teMG7S0o9VX4bqk/jvxGA7l/wPVJQHvBQviJgSgq4XSjLdCDhGjm+kuM2oiRipGwvGMfUYz X-Received: by 10.107.130.195 with SMTP id m64mr39992638ioi.137.1466572124732; Tue, 21 Jun 2016 22:08:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.130.195 with SMTP id m64mr39992616ioi.137.1466572124439; Tue, 21 Jun 2016 22:08:44 -0700 (PDT) Received: by 10.36.84.18 with HTTP; Tue, 21 Jun 2016 22:08:44 -0700 (PDT) Date: Tue, 21 Jun 2016 22:08:44 -0700 Message-ID: From: Kurt Andersen To: Alexey Melnikov , stephen.farrell@cs.tcd.ie, ben@nostrum.com Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 30 Jun 2016 06:43:56 -0700 Cc: draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , Tim Draegen , dmarc@ietf.org, draft-ietf-dmarc-interoperability.authors@ietf.org, Barry Leiba , dmarc-chairs@ietf.org Subject: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 05:08:53 -0000 I've reviewed all of the comments by the IESG reviewers and have made a number of edits to produce a -17 version of the draft. Not all of the comments were directly answerable so I've included some explanation below. --Kurt On Mon, Jun 13, 2016 at 1:44 PM, Ben Campbell wrote: > ---------------------------------------------------------------------- > > - Abstract: Please expand DMARC on first mention. Done > - 4.1.1.1, last bullet: "However, for known brands, all active domains > are likely to be targeted equally by abusers." > > I'm not sure quite what is meant by "known brands". Is this the same as > well known email services? No. I've clarified the intent by changing the sentence to read "...for all well-known brands..." > 6. Some of the mentioned mitigations involved relaxing alignment checks. > Do those warrant a mention here? I think that it is more accurate to say that some of the proposed mechanisms either bypass or transcend the straight-forward alignment logic. None of them have enough momentum at this time to merit special call-outs in section 6 (IMO). If they progress, they will each have to handle their own security considerations. > -- last paragraph: " Section 4.1.3.3 warns that rewriting the > RFC5322.From header field and changing the domain name should not > be done with any domain." > > I'm not sure I understand that sentence, especially around "not be done > with any domain". Nor do I see which text in 4.1.3.3 specifically says > that. The reference that I had in mind was to item 3 of the first bullet in 4.1.3.3. I've adjusted the text in 6 to now read: "Section 4.1.3.3 warns that rewriting the RFC5322.From header field to create an artificial domain name should not be done with any domain." > ---------------------------------------------------------------------- On Thu, Jun 16, 2016 at 5:37 AM, Stephen Farrell wrote: > ---------------------------------------------------------------------- > > - I think the abstract and intro are too coy in saying that > DMARC "can" introduce interop issues I added text to these sections to be more explicit about the conditions which lead to interoperability problems. In the abstract: "The use of restrictive policies through the DMARC framework can cause interoperability issues when messages do not flow. . ." In the intro: " The DMARC mechanism, especially when employed with restrictive policies, encounters several different types of interoperability issues. . ." Section 3.2.3.1 is pretty straightforward already. I did not see a need to change the text in that section. > - I think the abstract and intro would be better if they > explicitly ack'd that DMARC affects mailing lists. . . While mailing lists can be adversely impacted, I don't think that they are necessarily more impacted than the other items which are called out in the body of the document. > - 3.1.2: Saying that the MTA is the thing to "introduce" the > interop issue here seems a bit wrong - isn't the issue caused by > the existing MTA practice combined with the introduction of > DMARC? IMO, DMARC is causing a latent interoperabilty to become overt. Neither component is "introducing" the problem, it is more of a matter of revealing something that was already broken. I changed the text to read: "Some common message handling strategies break the integrity of DKIM signatures. A restrictive DMARC policy along with a broken DKIM signature causes latent interoperability problems to become overt problems." From nobody Thu Jun 30 06:44:02 2016 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 2887912D08D; Wed, 22 Jun 2016 03:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdbfyT6NJxEA; Wed, 22 Jun 2016 03:08:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F360412D0E0; Wed, 22 Jun 2016 03:08:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51E8CBE33; Wed, 22 Jun 2016 11:08:41 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhh7pcGUZfvF; Wed, 22 Jun 2016 11:08:41 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB8D4BE2F; Wed, 22 Jun 2016 11:08:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466590121; bh=4ndpT5fTXha64cjqA909oIs6oxqnAGnkY3iAA7V/dFQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gaWG/uWduUdcUepI5eagbvSfqJW2qbDGJhnZnuNDt4QaXMK15lQpWoo5MMmyIQIsi kBt0tHPmWho9kt83SxC5KpgT3IzwAaYwaeZdaaw8ns4+fn7lqVQtH2L7GF5muMUato nVj3RrGmXIOVUXJlzbcdVk2syWU9mtKu2txmH/yE= To: Kurt Andersen , Alexey Melnikov , ben@nostrum.com References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <576A63A8.7060404@cs.tcd.ie> Date: Wed, 22 Jun 2016 11:08:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060602070006010506080100" Archived-At: X-Mailman-Approved-At: Thu, 30 Jun 2016 06:43:56 -0700 Cc: draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , Tim Draegen , dmarc@ietf.org, draft-ietf-dmarc-interoperability.authors@ietf.org, Barry Leiba , dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jun 2016 10:08:46 -0000 This is a cryptographically signed message in MIME format. --------------ms060602070006010506080100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noting again that my comments are non-blocking (so you should feel free to ignore me:-), but ... On 22/06/16 06:08, Kurt Andersen wrote: >> > - I think the abstract and intro would be better if they >> > explicitly ack'd that DMARC affects mailing lists. . . > While mailing lists can be adversely impacted, I don't think s/can/are/ above, as previously agreed. > that they are necessarily more impacted than the other items > which are called out in the body of the document. >=20 It is IMO entirely noteworthy that the primary mechanism used to discuss the definition of mail protocols, including this one, has been adversely affected by this mail protocol. One can quite rightly and fairly claim that that trade-off is overall a win for the mail ecosystem, but not being explicit about what has been the biggest downside of dmarc, from the IETF participant perspective, seems plain wrong. S. --------------ms060602070006010506080100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjIx MDA4NDBaMC8GCSqGSIb3DQEJBDEiBCCO44fL5FIKZdXtUNMZq2bd1qmU8NbDXvAv4CJ5NyOJ TjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBgnuYSvXzn82VgLkek4yjwfoXgDQ1G8AvEpDrOt0cL9Q5XhN0pj7Ms Onca/GJt/FQQHLu1yRqmCA4r1R2F3oY8usNlBcePH3FZh1LLHEYH1FlZa0Kr0ojvVX8lcCRc L9YWMuCBxRN/OdnGNb+egGRqP4Wdx43BXMGdtaM7gJgZgufqGqBlbBM0aTd0QV0UN8zavHGN oiIMJyQosSUacMpPrvXUvohxY2/vjiRFy3c8Jtg1Dfdbs+0OPOwp+2lr4TiI2vtd7snVzqtv ICYCQc7kMt1xOCRHVnZb6pVEMwg76QCJaT1QtjMv14h24hEtdP+gLu0EeAFyTS62TAtx+8RN AAAAAAAA --------------ms060602070006010506080100-- From nobody Thu Jun 30 06:56:16 2016 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 7F3FD12B068 for ; Thu, 30 Jun 2016 06:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJpkHXHmdfKu for ; Thu, 30 Jun 2016 06:56:12 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EBB12B061 for ; Thu, 30 Jun 2016 06:56:12 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t127so145829426qkf.1 for ; Thu, 30 Jun 2016 06:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cWb7FwmaXkgjTk+qQM6Z2ylZbwkd+a9GkZ2B75a/GXs=; b=OEl8ExaLnl+fT84JkIbAoL4kFUJ4mfcxhw8D7GsT0/1vLPYdL3wDBUYbVre4BgJkMZ 4DitPpgKp9meqk2yB5GRgItJTVJwFIuW7+sx/JxKe0JCSGOYTLAbBLrqjGh2GeIPyqMA aQIRY5xeXhxW5fjhmlrtdmrMm0f63ZYKxblkiS7NQfHuZy7dHwdi9kxJ5zl4F2Icplel x8wUevI2W3kdURex/JI0jcvtoqgnyZOGuXGC7HsPz0ZnoJAkxTwl2mzVn6wZfKHMtv43 KFz7tDCOzNYwKM9xder45s2GMAuz+4E/0dl290nlkF71k/YxN0LEwpVK9oXj6zg1oFJz PDhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cWb7FwmaXkgjTk+qQM6Z2ylZbwkd+a9GkZ2B75a/GXs=; b=X+midnrWUyX2+OltMqEW/lMmaN2O7EAJUAP/JB2axD63rJkuX2Rd4B+/IqkRqdrp4D KlquoFr4yd+OXusrYnhaHNdw8dIphgvNsgiMcKrCxXvt3i6lTiyZBHdJFpKteNjACW9V 0LtlOd3hRMRZuR5PCsyipeQSNEqma5ekwXPFQ9a/Lp+26N6MNcomzM2IHqVz6wDH9sPy AVYAnJYMyMLXlb3fY8VLyqI4uHR062tJdvArEsKpffAsMgr/tW5XvsMP8rjSWmkuxL/3 H9JNLgRb0CGiRveUUjgWjaPF2kFOkBvaCMS8JxoS6vuP2CVbIPpDa/P5WNHGZhvmzIeM 7O4A== X-Gm-Message-State: ALyK8tJJPsVnvZPIN7z8SYWFv0io/rjNrAXAwrsnOc4sbIB0F0TRJ3rDkIg38bPZz3RcOX0CuScLZUie8eB7lg== X-Received: by 10.13.216.212 with SMTP id a203mr6517755ywe.278.1467294971627; Thu, 30 Jun 2016 06:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.145 with HTTP; Thu, 30 Jun 2016 06:56:10 -0700 (PDT) In-Reply-To: References: <5772A73F.3020405@tana.it> From: "Murray S. Kucherawy" Date: Thu, 30 Jun 2016 06:56:10 -0700 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=001a114e6e7c908e2b05367f3b68 Archived-At: Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] [arc-discuss] arc-05 draft released X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 13:56:14 -0000 --001a114e6e7c908e2b05367f3b68 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 29, 2016 at 5:41 PM, Brandon Long wrote: I understand the desire to simplify, but arc users are going to need an > authres parser to take advantage of the data it provides, so it seems like > a good idea to include one. Yeah, just an idea. In either case, the document needs to include an ABNF for the modified format. -MSK --001a114e6e7c908e2b05367f3b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 29, 2016 at 5:41 PM, Brandon Long <blong@googl= e.com> wrote:

I understand the desire to sim= plify, but arc users are going to need an authres parser to take advantage = of the data it provides, so it seems like a good idea to include one.

Yeah, just an idea.=C2=A0 In= either case, the document needs to include an ABNF for the modified format= .

-MSK
--001a114e6e7c908e2b05367f3b68-- From nobody Thu Jun 30 07:00:49 2016 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 852EC12D150; Thu, 30 Jun 2016 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMw9HAkG9tYk; Thu, 30 Jun 2016 07:00:41 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB3512B068; Thu, 30 Jun 2016 07:00:40 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id j2so91609851qkf.3; Thu, 30 Jun 2016 07:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wSeKZPaKlcgNYMyWFPPgcJGKQC38ILCSagQ24f/yLDU=; b=W35XqvtQIOVPYfDT3dvqDJWSYM/wbhz96nRerPYeVuKz3IgisRKfsNATgeuP5XJCnD gabhHIxGLZzoqT5lGJZqAu94SdEVAzXV0nuWtzYGyZxavJqnFcvX9b6ql6KQhramsFJE t0dM0Z1bt1OEwLpjQLJfnadLxvb6GLriVfrthI5ydt076v/61dR2LUTvGOCt+I36ln+S ae64WiN6slwga3j1OWv/JHbGcQ+ZKgRs62P/yx62NRNaqfku8srw/PzV7qByFpTdfHwG jfrCIvqG7MHzhCodEtAN7uJII307wQpHTxMkBkVedVCI2o0yGkqvqwanOse7UIGnhsQL eahA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wSeKZPaKlcgNYMyWFPPgcJGKQC38ILCSagQ24f/yLDU=; b=QeLnqoog/IN5Bkox+QN70jdr6MdYP9cp77QBSJ9RhQNYik+1vvZPfp7n6pWcjLPcDj uPdvijvYb3J0eG41t35fL6LZVqu4y6W1GCeeCziQFuQkUj0FBz0bKKg/MuW5IZx1PFmL pgehCf2MNzjrfAx8GsT3SJ/OUX6FaJmj83mG6qhDu7HM2mJhZnKN1ux/yYS08duQkom1 iMPaGaqD2qktnTpYXYSXUI0FnF9+RKdHzFMiXcKN68Fw5CdlBsoJhgh9c4AdBwn4FpkM qtVbRDnI8O6BJD45fEbvw0XsLVBIpvYRUaJh+BX5a2zgj1nMVSOxAJJhj0QKfSO2pyAa uyYw== X-Gm-Message-State: ALyK8tKy6jA3uJW2dUZdLj9MwL33OvWo1UtkeQkger6fyTgEFxDuHEhrYtBZah8G++rKDXD2v34ebR41q5QtUw== X-Received: by 10.129.56.138 with SMTP id f132mr6779907ywa.240.1467295240018; Thu, 30 Jun 2016 07:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.145 with HTTP; Thu, 30 Jun 2016 07:00:39 -0700 (PDT) In-Reply-To: <576A63A8.7060404@cs.tcd.ie> References: <576A63A8.7060404@cs.tcd.ie> From: "Murray S. Kucherawy" Date: Thu, 30 Jun 2016 07:00:39 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114d6f308fdec705367f4b1b Archived-At: Cc: Ben Campbell , dmarc-chairs@ietf.org, Alexey Melnikov Subject: Re: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 14:00:47 -0000 --001a114d6f308fdec705367f4b1b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 3:08 AM, Stephen Farrell wrote: > > > While mailing lists can be adversely impacted, I don't think > > s/can/are/ above, as previously agreed. > > > that they are necessarily more impacted than the other items > > which are called out in the body of the document. > > It is IMO entirely noteworthy that the primary mechanism used > to discuss the definition of mail protocols, including this one, > has been adversely affected by this mail protocol. > > One can quite rightly and fairly claim that that trade-off is > overall a win for the mail ecosystem, but not being explicit > about what has been the biggest downside of dmarc, from the > IETF participant perspective, seems plain wrong. +1. -MSK --001a114d6f308fdec705367f4b1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 22, 2016 at 3:08 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> While mailing lists can be adversely impacted, I don't think

s/can/are/ above, as previously agreed.

> that they are necessarily more impacted than the other items
> which are called out in the body of the document.

It is IMO entirely noteworthy that the primary mechanism used
to discuss the definition of mail protocols, including this one,
has been adversely affected by this mail protocol.

One can quite rightly and fairly claim that that trade-off is
overall a win for the mail ecosystem, but not being explicit
about what has been the biggest downside of dmarc, from the
IETF participant perspective, seems plain wrong.

+1.
-MSK
--001a114d6f308fdec705367f4b1b-- From nobody Thu Jun 30 07:42:29 2016 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 1F90512D0EE for ; Thu, 30 Jun 2016 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRDHZ1wmbdS8 for ; Thu, 30 Jun 2016 07:38:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87E712B030 for ; Thu, 30 Jun 2016 07:38:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1ZEJGZPTC0091I6@mauve.mrochek.com> for dmarc@ietf.org; Thu, 30 Jun 2016 07:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1467297225; bh=XfoVoWmW6J7Eot9RerFk/lESkHXCQ9kapbX+AqCJYKw=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=DsvSg0LWltfErADApwPvq4rL1BPJ0tVgs1vRKfyzkRf9NoqSCE0eS79uGKI46cfq6 +txfNULtZvVT6EpBFA1i+TwXB63bHErypShHSMhG7olKeRArLu99GB2CT26qQBRdod XLS3a4VXsFE3sySFap75YlpvCmcPsSzRG1wrb0M0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q1LMPRIMLS00005M@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 30 Jun 2016 07:33:41 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01Q1ZEJEU2FU00005M@mauve.mrochek.com> Date: Thu, 30 Jun 2016 07:26:08 -0700 (PDT) In-reply-to: "Your message dated Wed, 22 Jun 2016 11:08:40 +0100" <576A63A8.7060404@cs.tcd.ie> References: <576A63A8.7060404@cs.tcd.ie> To: Stephen Farrell Archived-At: X-Mailman-Approved-At: Thu, 30 Jun 2016 07:42:27 -0700 Cc: ben@nostrum.com, draft-ietf-dmarc-interoperability@ietf.org, Ned Freed , Alexey Melnikov , Tim Draegen , Kurt Andersen , draft-ietf-dmarc-interoperability.authors@ietf.org, dmarc@ietf.org, Barry Leiba , dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 14:38:51 -0000 > Noting again that my comments are non-blocking (so you > should feel free to ignore me:-), but ... > On 22/06/16 06:08, Kurt Andersen wrote: > >> > - I think the abstract and intro would be better if they > >> > explicitly ack'd that DMARC affects mailing lists. . . > > While mailing lists can be adversely impacted, I don't think > s/can/are/ above, as previously agreed. > > that they are necessarily more impacted than the other items > > which are called out in the body of the document. > > > It is IMO entirely noteworthy that the primary mechanism used > to discuss the definition of mail protocols, including this one, > has been adversely affected by this mail protocol. > One can quite rightly and fairly claim that that trade-off is > overall a win for the mail ecosystem, but not being explicit > about what has been the biggest downside of dmarc, from the > IETF participant perspective, seems plain wrong. On reflection and after reviewing the document, I have to agree with Stephen here. The conditional language makes it sound too much like the problems DMARC causes can be avoided, when in fact doing so almost always has an adverse impact on the overall functionality of the mail system. IMO Stephen's suggestion is a good one and should be implemented. Ned