From nobody Wed Nov 1 10:02:51 2017 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 65A6013F8D8 for ; Wed, 1 Nov 2017 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=JLTcBECw; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=GaSvH9fe 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 7aiKd2EtOt6e for ; Wed, 1 Nov 2017 10:02:47 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id DC39413F8DF for ; Wed, 1 Nov 2017 10:02:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2164; t=1509555761; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=8PVhRiRv1L6E3+PRQ0yTWSBxQp8=; b=JLTcBECwgnH/Yev1nOSOE1o4Osftf9VxNp43fX5gMJzfp5J2lSU66Wt5NOlYhS wSHMJ3n67XWBPgn6DoDTxv3/a0IluOZfH5Mrz7yokan8N4koiKj3oeMRvq4tnXz3 rzZt1OwC/cqWsFQWOr41S61koZzdD1nsX4h9nEnDXy4LY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 01 Nov 2017 12:02:41 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3719480545.1.3328; Wed, 01 Nov 2017 12:02:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2164; t=1509555647; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Kqz/nuh aGICYMxuWsBcOVp4JkJc48gOa30neJRn9fhg=; b=GaSvH9febo0xDlR0olf/rtq 0OQs5jNwOGVW1xU7yl169lgYkYijpfm1GrsXud7aO481FbLyVTIkY2r3QmG+QNQ7 g4X8y8BHxvG0s/WarAZYQW9rEeepQdGGcsxRjxrLGswx/DDiMeTqP1scLfxl0XGL ClEHsC7hq5GUKaYBT2Wc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Wed, 01 Nov 2017 13:00:47 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3719455390.9.162996; Wed, 01 Nov 2017 13:00:46 -0400 Message-ID: <59F9FE2F.1080305@isdg.net> Date: Wed, 01 Nov 2017 13:02:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Barry Leiba , "dmarc@ietf.org" References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 01 Nov 2017 17:02:49 -0000 On 10/31/2017 10:57 AM, Barry Leiba wrote: > In a couple of days I will ask Alexey to cancel the dmarc session in > Singapore, unless someone very quickly shouts, “Noooooooo, don’t do > that! We need to meet and talk about .” > > Barry, as chair Once again, my expectations were off about what the key DKIM cogs would do to complete this long time project in regards to DKIM policy and even trust layers. I've been waiting for over a decade for the DKIM Policy layer to be established. Spent much dollars, engineering time, product development, sweat and tears working on ADSP, a then proposed standard, only to be "replaced" with non-proposed standard "Super ADSP" DMARC that did not solve the complaints about ADSP, but instead carried the problem on, and pushed it into the market place like the problem never existed. So are we going to complete this thing or what? I have been waiting and willing to "follow" the leaders to finally complete this thing. Is ARC resolving these 3rd party issues? It doesn't look that way, or at least I don't see it, other than ramming the overhead down our throats. You should at least have a meeting to decide what you are going to do with DMARC. It should be turned into a Proposed Standard. It needs 3rd party policy considerations. It needs more policy options, including describing how ARC is expected to work by domain owners who expect to use it. I really don't quite understand the engineering difficulty in completing a 3rd party solution we all know will work for "cheaper and better" than any ARC plan. DMARC is very limiting. I am proposing: 1) Rewrite DMARC as a IETF proposed standard, 2) Incorporate 3rd party authorization concepts like ATPS into DMARC as extension tags, 3) Incorporate ARC somehow into Policy that tells receivers what to expect, i.e. # of hops, etc. I would like to think these are all just DMARC options but it needs to be IETF sanctioned in order to get support which will finally give people a confident chancee to explore these options in earnest. -- Sincerely Hector Santos http://www.santronics.com -- HLS From nobody Wed Nov 1 11:05:57 2017 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 5094C13F9F1 for ; Wed, 1 Nov 2017 11:05:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z9GiSw3cZdUa for ; Wed, 1 Nov 2017 11:05:53 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 DA6B413F9E5 for ; Wed, 1 Nov 2017 11:05:52 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id e143so3460397lfg.12 for ; Wed, 01 Nov 2017 11:05:52 -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=kHt8qJHgv/YyTJe3qpEjV5/bie0TOPSnQZkErj1qffk=; b=QsGUpKvQN4TohX/KW6ZiWYrA+PsAWydvsx7ISQLAJh3pJGHq0FWt6SLL8JyDYoLz3r 8oUcYw3jJlY6VuQSTUDTjBjAPo+ypRV4r45Wc5lQkQKS8lDDihhHfX4RlJXMJmqWvGuW 6PFtozxDRuESrw+eYSdYdTrISVSy4XKKwNP3o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kHt8qJHgv/YyTJe3qpEjV5/bie0TOPSnQZkErj1qffk=; b=aSkfROu3zNB/qEU+A4i8Gs+/msELzpubO8Gg6Hw+ZPGwVm5EJ16kcfffOzljbcHEYk ykCnSkaBbpBNpF0fGqNeYK0YjI9xUGGRHuZLfgIPkhVkeb6xFfm2WYQ04crsppSsWfpb McrWtq2jMwxICAscN51Ur83dZLsaM7DcXbArZxbfmjDtk8R0q0o+97WDcvbOlqziLa+2 qK2zGj0Y1Ey+cZaMiucNZAKhBrIMGmceCSKcTfKpfgUbStaLl/VWpEvT9QWiFlyHgTHR bSevPr/ARno8MycUioP0G0TcP6kJVn5pY1bYmPosX/IZui9YEGGXn6Md6sm2cyqaOdAK jYuQ== X-Gm-Message-State: AMCzsaUm+e0yVC4tuBWN6yIr4G7pg+jI2r41pqRCFSFvKg5UFlAl3cZf cecUT+uQqc8Bquw6ZGWPJw95Kh+g8HZdqdpidhGouw== X-Google-Smtp-Source: ABhQp+Q9BnbjklxXPCAojF2UdSfIh0v+lNxdZMYWdYUJJtpN/EXChpGcSiPC7Odw5vVkgBB0A5EXLFcC8GRvRqe1BkU= X-Received: by 10.46.81.81 with SMTP id b17mr248351lje.185.1509559550796; Wed, 01 Nov 2017 11:05:50 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.158.77 with HTTP; Wed, 1 Nov 2017 11:05:50 -0700 (PDT) In-Reply-To: <59F9FE2F.1080305@isdg.net> References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> From: "Kurt Andersen (b)" Date: Wed, 1 Nov 2017 18:05:50 +0000 X-Google-Sender-Auth: EFzU7_qkY73y3uCmJoSmpNqeZDs Message-ID: To: Hector Santos Cc: Barry Leiba , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045ff67ccafcea055cefb889" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 01 Nov 2017 18:05:55 -0000 --f403045ff67ccafcea055cefb889 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 5:02 PM, Hector Santos wrote: > You should at least have a meeting to decide what you are going to do with > DMARC. It should be turned into a Proposed Standard. This is on the roadmap charter for the working group but we are not yet to the point of working on that milestone. --Kurt --f403045ff67ccafcea055cefb889 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 1, 2017 at 5:02 PM, Hector Santos <hsantos@isdg.net> = wrote:
You should at least have a meeting= to decide what you are going to do with DMARC.=C2=A0 It should be turned i= nto a Proposed Standard.=C2=A0

This is on t= he roadmap charter for the working group but we are not yet to the point of= working on that milestone.

--Kurt=C2=A0

--f403045ff67ccafcea055cefb889-- From nobody Wed Nov 1 22:13:34 2017 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 C0CAC13F452 for ; Wed, 1 Nov 2017 22:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 OdaDTKaZxLZL for ; Wed, 1 Nov 2017 22:13:30 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 ED62313EDE3 for ; Wed, 1 Nov 2017 22:13:29 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id n137so11108011iod.6 for ; Wed, 01 Nov 2017 22:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=L5U2OiYP5tXKczm/ZOD4cMDz8rn7wI3rfwbsbdgt8D0=; b=Hl68c9n+dVBUVbenKkYethI3KWlvfVO3e2XcR7KpBMtNoZ5H6bpFP3VBl3yLN9DnsG eKh1LlJICNB0D4JIVM/ss4z6XOh0HgCGHyo6GEvZyDeOEkB1810Xy2yVzRjeMjIgBhqk +AHvzhxjF9rHXrQ//PGzAloryMGopX8mXykZa/yRG+2bk2DyeDgBCC+JmZFjqrDDZ88M OW3OH5dN5wcY8XGbifEgL4rTUEpNQc2Kl6TLDR2NtrWvNZTkwbqD4buTGADEO2thMeBb 9aoAfSs9/r8Kr+QlkWfkWOf+0aZo8rOcZkcEgXvQ5fHwEkvA26huF+WDg5yoXBxVHo6B JiMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=L5U2OiYP5tXKczm/ZOD4cMDz8rn7wI3rfwbsbdgt8D0=; b=KO9p1cdvrV04GcREWp4cNZ1NQNHIqsijt2no2UqIevfiwR32LhHekTYvT2+4WTIsYa U+L6teIgEgKsEmzWjPFQEdXycwpsWppskM4Q9SMcJq+n1ediyno8LvzyqJM87EgQZxjd Un+6X6zbKgUHyb6wm7U8TbcFiMTBIxehXEL9glaCcwgVNvW0T+1J4yrDgc0xYawz6IJv uY5jZYBvDkC2ZXMemh2AmKg2vNZxl2rrtNwMuSbw/ibMkYtTWbuTA1mShfDU8qAZqMiL fxCbh9j7PFFfz2trumKdi9jYXTCASLcda+GdUboHG9GCGzdCj0FsbmYPtWF8hb4WXFkq qehg== X-Gm-Message-State: AMCzsaUTGC/Fy+QVFqIxulgMxW1hZ1MQAQbouR4CxiQY2JgK6JdnqPUy 2OnOsI0Re8Lz3+TeP5jxIjqqZTQf5rKGiUT7yhw= X-Google-Smtp-Source: ABhQp+St7E1cbR8cZlC3vaf08bEp6FbKSa/l7ybGr8FR1nmcbzNGOeBdKL0T3Br4ZgVGXa95o/KO5NsJuvKtDy+W+0A= X-Received: by 10.107.170.166 with SMTP id g38mr2852854ioj.207.1509599608888; Wed, 01 Nov 2017 22:13:28 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.130.19 with HTTP; Wed, 1 Nov 2017 22:13:28 -0700 (PDT) In-Reply-To: References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> From: Barry Leiba Date: Thu, 2 Nov 2017 09:13:28 +0400 X-Google-Sender-Auth: yM6mInK-zFZp7w4AegjjbSrU1ho Message-ID: To: "Kurt Andersen (b)" Cc: Hector Santos , "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 02 Nov 2017 05:13:33 -0000 >> You should at least have a meeting to decide what you are going to do with >> DMARC. It should be turned into a Proposed Standard. > > This is on the roadmap charter for the working group but we are not yet to > the point of working on that milestone. Yes, but more broadly, Hector is not wrong. We started with ADSP, which we thought was what we needed, but we quickly found that it had basic flaws that made it not work well. We rescinded it. That's good. So then some major email providers got together and beat out what they thought they *actually* needed. That's also good. They brought what they came up with to the IETF, but what that *is* is substantially the same as ADSP with the addition of feedback/reporting features. It suffers from very similar flaws to ADSP, and we're seeing the unfortunate results of that. That is bad. And so we're working on ARC, which attempts to partially address the flaws. Again, good, but it's taking quite some time to get it done. We initially planned to get it done quickly and then to move on to the next step with DMARC. We need to get there. We also need to understand whether there's really anything we intend to do with DMARC. Do we *know* what we might do? Do we have any plan for a way forward? Are we hoping that ARC will fix enough of it that we can make the combination into a standard? As always, I know this is all volunteer work, and we do things as can find the time to do them. That said, we really need to push this stuff up in priority, because we really need some mitigation to the DMARC damage, and developers such as Hector need to know what they should code into their products so they can get something stable in there and move on to other features. Barry From nobody Fri Nov 3 01:01:40 2017 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 BF01013FCDC for ; Fri, 3 Nov 2017 01:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 qLFPG9SIBoO4 for ; Fri, 3 Nov 2017 01:01:37 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 4EFB913FCD7 for ; Fri, 3 Nov 2017 01:01:37 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id q83so2238459qke.6 for ; Fri, 03 Nov 2017 01:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rozws++zhhQHGhKf3BJn61BqWRusqYwqHT4uoMTbmiI=; b=fFXmrkBFJd30AUaPpWAxgbIxO0NO2q+idFP2EAURXylqV1Rc0nk8wz86tAHmOFVHYi eegAAyhJeQkfTalUy5rMPkChzggsiAQlxU+GboM40vy5fLgwY/b2vvsrGGLCxh1jNBea /bGHB8ZQO2AdZhYnokFxIlG2n9abJYDnah4svDD3B6c+KepiY/DHgb2s1RqStJ28nwom RXOdMEQ7ZoOUKKTWTbNrh+y11thNvKT55IqKwJJOp2Oa4twxvgoojRhzHqAtGcvCdiNH lr+QIVCVwfLaWJiUcEz7e5JFxs4HiBU7DFfEd6ehYCKf5Jj8NenJC15vZB/H7DfybWnd pv2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rozws++zhhQHGhKf3BJn61BqWRusqYwqHT4uoMTbmiI=; b=B5APuZTHhs5T79De2QrG560bOUnFrl2D5aUer9lQ26pZLEwWOzhnsmXnMb+ckYM30q qAxrk3nLlFXON/FmAUlR85Q0pghLuvg/1qZjlZORH90MHqPXgDIeiNNjM+/qIjZOrht3 jLCg5dMuj84/wn2UZSY0KcF8OFWYbPceXybLmoMxEfh2omP0c1qppzKowJ5aLeuctWGY PFaCQcJB99xaCQZixrAzXu/Ch5e1pCzEG98JrhKynsbZOckJ1cYfqyLHuJA5CD1GRJc+ JCjMwjRNRyGvDQD8MoaOHnBAkVJp8nTI3HVoXBLIH7DWrpTE2ds1m22ciWXia0TbVvux M1VA== X-Gm-Message-State: AMCzsaXZpuQGOwEBc2Xi+gdb5xzfW4QV0w/oE5O1HTAoGnJ3Wx0Ot6lU UxhAy8ZhBBYECFXZb12wmqG3U11Ek0gieF3IxF0= X-Google-Smtp-Source: ABhQp+TijhJkonC7bursxedpWpb488QGGusShHB8riPOY4S/6l5oaYVru645pcvZ/cYnBYAd9FdBCSZjR67Q9e/2DA0= X-Received: by 10.55.160.18 with SMTP id j18mr8626154qke.327.1509696096360; Fri, 03 Nov 2017 01:01:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.61.145 with HTTP; Fri, 3 Nov 2017 01:01:35 -0700 (PDT) In-Reply-To: References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> From: "Murray S. Kucherawy" Date: Fri, 3 Nov 2017 01:01:35 -0700 Message-ID: To: Barry Leiba Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Hector Santos Content-Type: multipart/alternative; boundary="94eb2c05d50e8adbb1055d0f838e" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:01:39 -0000 --94eb2c05d50e8adbb1055d0f838e Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba wrote: > We also need to understand whether there's really anything we intend > to do with DMARC. Do we *know* what we might do? Do we have any plan > for a way forward? Are we hoping that ARC will fix enough of it that > we can make the combination into a standard? > I've been proceeding under the assumption that the last sentence is the plan. Am I the only one? Is something else the plan? -MSK --94eb2c05d50e8adbb1055d0f838e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba <barry= leiba@computer.org> wrote:
We also need to under= stand whether there's really anything we intend
to do with DMARC.=C2=A0 Do we *know* what we might do?=C2=A0 Do we have any= plan
for a way forward?=C2=A0 Are we hoping that ARC will fix enough of it that<= br> we can make the combination into a standard?

I've been proceeding under the assumption that the last sentence = is the plan.=C2=A0 Am I the only one?=C2=A0 Is something else the plan?
=

-MSK

--94eb2c05d50e8adbb1055d0f838e-- From nobody Fri Nov 3 09:47:31 2017 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 18B3013FEE6 for ; Fri, 3 Nov 2017 09:47: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LOLaHyAUrMgt for ; Fri, 3 Nov 2017 09:47:28 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 766F213FE2A for ; Fri, 3 Nov 2017 09:47:28 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id k40so3862761lfi.4 for ; Fri, 03 Nov 2017 09:47:28 -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=bysgUYEBh54NB8c/e6FCblaHAQPB81jHAGaZyiEIVu8=; b=VPj9cAtac2iDWuHOzcW28nDxDy4zJq/wq2fpCWqQ/31Th+11NTT59QkPTp3+Nv3SoR nAL+mxR+kBtQbajYCe7w0E7l5Jgj0JZ+dXZbVutzVtqXABE6KWyplz2JjLL+uZua/3Wz SZOOAJz+DKYvy8HPMQ57iwnCy7PDFqE0TAaSg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bysgUYEBh54NB8c/e6FCblaHAQPB81jHAGaZyiEIVu8=; b=iv6ZMp//tWf65ym069qIQeqHxYCP0LgouGWJKSftpPbiJAFb5YeV+2M/5vaCUW8284 MKHjjb2eseR+wwo0qK66dYv9+8fK/igwbvYxkmUeLSDjsUGIHjbUQOPuAr2CkGF5xycB RTpc0S3gaO3du7fR/DXzu+4p1QRWDxix0aIXhJJT/+Nzxira95dyGoxSgP5M1X3fQX7z GheSTiGkgOkYKpM/m2RBSNALBGohtZKnlAMtwtFt6yTTh4zGzfjUKvGnltnRrwCvBXRh CcrBR/HAdCnVZtr3TA0A942Qo4znjwPEuLAvvwgRYkiWSAcq3asiDy2nK2zyfsAAiQog Po/Q== X-Gm-Message-State: AMCzsaVoJtZ/iIJdwkTfN+6AStgxzv1mLH0CK9qXbrZW2YTSniFDY4ET IKzyQ6L+sGX9/n8IPQrEairCBPB2KFE2l3EtZV+yfQ== X-Google-Smtp-Source: ABhQp+TWj5hIuog63CKUiRM1/9KKPLnBJh3jSODGhVdYc004VFkLHrZ5yu+6MW2eiQ1HGyfjCXvRQ7fthcaH4b74SX4= X-Received: by 10.46.89.147 with SMTP id g19mr3166814ljf.26.1509727646656; Fri, 03 Nov 2017 09:47:26 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.158.77 with HTTP; Fri, 3 Nov 2017 09:47:25 -0700 (PDT) In-Reply-To: References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> From: "Kurt Andersen (b)" Date: Fri, 3 Nov 2017 16:47:25 +0000 X-Google-Sender-Auth: kRv3abp5arxIHdv-Z21QM5QUUcI Message-ID: To: "Murray S. Kucherawy" Cc: Barry Leiba , "dmarc@ietf.org" , Hector Santos Content-Type: multipart/alternative; boundary="001a114f5672163e38055d16dc67" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:47:30 -0000 --001a114f5672163e38055d16dc67 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 3, 2017 at 8:01 AM, Murray S. Kucherawy wrote: > On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba > wrote: > >> We also need to understand whether there's really anything we intend >> to do with DMARC. Do we *know* what we might do? Do we have any plan >> for a way forward? Are we hoping that ARC will fix enough of it that >> we can make the combination into a standard? >> > > I've been proceeding under the assumption that the last sentence is the > plan. Am I the only one? Is something else the plan? > > -MSK > While the exact method and details of accomplishing said "combination" are TBD, that is the general idea. --Kurt --001a114f5672163e38055d16dc67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 3, 2017 at 8:01 AM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba = <barryleiba= @computer.org> wrote:
We= also need to understand whether there's really anything we intend
to do with DMARC.=C2=A0 Do we *know* what we might do?=C2=A0 Do we have any= plan
for a way forward?=C2=A0 Are we hoping that ARC will fix enough of it that<= br> we can make the combination into a standard?

I've been proceeding under the assumption that the last se= ntence is the plan.=C2=A0 Am I the only one?=C2=A0 Is something else the pl= an?
<= span class=3D"HOEnZb">

-MSK

While the exact method and details of accomplishing said &quo= t;combination" are TBD, that is the general idea.

--Kurt
--001a114f5672163e38055d16dc67-- From nobody Fri Nov 3 12:32:32 2017 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 73E7613FF65 for ; Fri, 3 Nov 2017 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fiction.net 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 nBObAcaQbomQ for ; Fri, 3 Nov 2017 12:32:28 -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 6A48F13FF64 for ; Fri, 3 Nov 2017 12:32:28 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id b186so8558732iof.8 for ; Fri, 03 Nov 2017 12:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9WZmayJmWjLb2SX3OzkqWuGKfanIKc/ozuQWfzmheTo=; b=WUskYz3A5Mhv1JKYBCPYdfqQC/jDbOyqw8LLTMPNdW5U/KLsai/MhS+Cb3e6zPY+Zj PdDRZYp6itpVEOoTS5Qx/XnuvRGINj8VLRLW5VmilS96UwNBJnm8KLZ+1iW3gx0jjMNk IGjejrq5ocNTYdfYRmnXwn4Ozi0b4PwrNQvsZKhjqoc7mKMDS1dErI2XiwX5S2/19Hpy TGOoR3KqSPvd0OnI1I+bSjegXV+xOKoFGi3wxYrUWUrfdBQUv9m/ic988oN4AKjOLDii VhrUmqiLAS5tnnSLf9Mwbw0h6QXowklvfMGCxX9TIBv8lGmO4eftaxiOJpJ62nUwhAYe FU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9WZmayJmWjLb2SX3OzkqWuGKfanIKc/ozuQWfzmheTo=; b=Gq1ym5Qt66Fe+rlOuH0DrrV39tA6J0gtLvq6KtSwbygsJOAS9A113URot1n0buMEsm TbnlxTL/HhAk8Z5CxCqeVd8C0ElPoB1vf7BFFpXSojF1WkWqicT9utlBmr8Rch7sfBC+ e/ULtN40HngT4/YGAMEhVF/GHFJ6OzwJzGGvDk2tnbyQy7rnD232HeO1OHCUQ51npk+a 58z1MYBXVaOhtc2bLlz/yrdBQ/+ZR4bmMjk89igAj7gjm2d/u4HkoEC7Fss2alzmJrBP VIg3dsraOnWqKlyhq/GT6Nwkr59dyAfbh2a3NPDOzNwne1YrSVyrWC8G/Xl/RkgKOe8g jicQ== X-Gm-Message-State: AJaThX74tem3qTQGm883CfmgcNuazLLsbWK03lZM+Hlt6TJ8zb6LHG8J S69eseq99pf3TLJAYemgrYmYNlDbW6Q= X-Google-Smtp-Source: ABhQp+Sb7F6llVAG5MIcRikv4VaWkhjaiVfDxkj6eS1OFeD3yMb7QY07dUUfOKKWktgU+H4UVdiLHg== X-Received: by 10.36.122.1 with SMTP id a1mr120148itc.30.1509737547558; Fri, 03 Nov 2017 12:32:27 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id b185sm3192358ioa.24.2017.11.03.12.32.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 12:32:25 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id h70so8588304ioi.4 for ; Fri, 03 Nov 2017 12:32:25 -0700 (PDT) X-Received: by 10.36.227.7 with SMTP id d7mr40105ith.141.1509737545126; Fri, 03 Nov 2017 12:32:25 -0700 (PDT) MIME-Version: 1.0 References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> In-Reply-To: From: Brandon Long Date: Fri, 03 Nov 2017 19:32:12 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Kurt Andersen (b)" Cc: "Murray S. Kucherawy" , dmarc@ietf.org, Barry Leiba , Hector Santos Content-Type: multipart/alternative; boundary="94eb2c111b06158503055d192a09" Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:32:31 -0000 --94eb2c111b06158503055d192a09 Content-Type: text/plain; charset="UTF-8" If you look at RFC 7960, ARC is intended mostly for the mediators case, though it would also be for the MDA/MTA case. It does nothing for the MSA case, though there have been some proposals about having a hop=0 or just falsifying hop=1 for that. Most of the MSA issues, though, are mostly of the type "well, dmarc p=reject/quarantine means the domain holder doesn't want you doing that", so I'm not clear there's a solution there. Brandon On Fri, Nov 3, 2017 at 9:47 AM Kurt Andersen (b) wrote: > On Fri, Nov 3, 2017 at 8:01 AM, Murray S. Kucherawy > wrote: > >> On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba >> wrote: >> >>> We also need to understand whether there's really anything we intend >>> to do with DMARC. Do we *know* what we might do? Do we have any plan >>> for a way forward? Are we hoping that ARC will fix enough of it that >>> we can make the combination into a standard? >>> >> >> I've been proceeding under the assumption that the last sentence is the >> plan. Am I the only one? Is something else the plan? >> >> -MSK >> > > While the exact method and details of accomplishing said "combination" are > TBD, that is the general idea. > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --94eb2c111b06158503055d192a09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you look at RFC 7960, ARC is intended mostly for the me= diators case, though it would also be for the MDA/MTA case.=C2=A0 It does n= othing for the MSA case, though there have been some proposals about having= a hop=3D0 or just falsifying hop=3D1 for that.

Most of = the MSA issues, though, are mostly of the type "well, dmarc p=3Dreject= /quarantine means the domain holder doesn't want you doing that", = so I'm not clear there's a solution there.

Brandon


On = Fri, Nov 3, 2017 at 9:47 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Fri, Nov 3, 2017 at 8:01 AM, Murray S. Kucherawy &= lt;superuser@gmail= .com> wrote:
On Wed, Nov 1, 2017 at 10:13 PM, Barry Leiba <= ;barryleiba@co= mputer.org> wrote:
We also need to = understand whether there's really anything we intend
to do with DMARC.=C2=A0 Do we *know* what we might do?=C2=A0 Do we have any= plan
for a way forward?=C2=A0 Are we hoping that ARC will fix enough of it that<= br> we can make the combination into a standard?

I've been proceeding under the assumption that the last se= ntence is the plan.=C2=A0 Am I the only one?=C2=A0 Is something else the pl= an?

-MSK

While the exact m= ethod and details of accomplishing said "combination" are TBD, th= at is the general idea.

--Kurt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--94eb2c111b06158503055d192a09-- From nobody Sun Nov 5 19:30:11 2017 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 8A46813FAE2 for ; Sun, 5 Nov 2017 19:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=WyKmXNta; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=m35XbUxG 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 zWfAkUbHPaoQ for ; Sun, 5 Nov 2017 19:30:07 -0800 (PST) Received: from listserv.winserver.com (ntbbs.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF813FAD8 for ; Sun, 5 Nov 2017 19:30:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2220; t=1509939001; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=6f+SSZx9gOwNwYmcm6bKNzzYMXU=; b=WyKmXNtaoAA3SfpwQcSzIi8Z5R8RYODQJTaDSNCXjuoK8alziMdlusULGF3s50 3oLQj24F/w7T1cthWk2YGjhTlOAzena2NbRxYtitRZQvlCp1kF8ll04DB6KNHAd/ XdlGPWldLJOLac1y74aZ+MakuZxpsLetRkZHT1QoNpLoE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 05 Nov 2017 22:30:01 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 4102715159.1.3320; Sun, 05 Nov 2017 22:29:59 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2220; t=1509938879; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=AiCZe0Q OJ+pWSk0vZZBc/3GVqkYNpBkS1aQEF9C3hbY=; b=m35XbUxGCR2MdRsGTno7CI2 BbXETVFbihtexWOl/0nN8HK0BaOtbO/O4nnwr691G2LUNmdKa4U/Bv05EW6OZ6xR 9EwFwkMngQHr4+HZUC0vUKROoCvBsdc9IcCiwX2LoZDZZsNNT2CIJcsk9hnor4nA gEWURLlnpW1mdjORWH6c= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Sun, 05 Nov 2017 22:27:59 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 4102687203.9.183260; Sun, 05 Nov 2017 22:27:58 -0500 Message-ID: <59FFD733.3020800@isdg.net> Date: Sun, 05 Nov 2017 22:29:55 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Brandon Long , "Kurt Andersen (b)" CC: dmarc@ietf.org, "Murray S. Kucherawy" , Barry Leiba References: <150854546778.20809.10608584063019040033.idtracker@ietfa.amsl.com> <59F9FE2F.1080305@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] dmarc - Requested session has been scheduled for IETF 100 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:30:09 -0000 On 11/3/2017 3:32 PM, Brandon Long wrote: > If you look at RFC 7960, ARC is intended mostly for the mediators > case, though it would also be for the MDA/MTA case. It does nothing > for the MSA case, though there have been some proposals about having a > hop=0 or just falsifying hop=1 for that. > > Most of the MSA issues, though, are mostly of the type "well, dmarc > p=reject/quarantine means the domain holder doesn't want you doing > that", so I'm not clear there's a solution there. > If I still understand ARC and its attempt to do a chain of trust concept, I think there would still be a need for a 3rd Party Seal authorized domain or "registration" concept, otherwise, only the entire chain validity matters. We can have policies for strong and relaxed ARC seal requirements. Overall, the integrated DKIM policy solution begins with RFC7489.DMARC Tag Extensions: 3.1.3. Alignment and Extension Technologies If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. We can consider an "atps=" tag and "arc=" tag as experimental concepts. One is DNS-based, no additional RFC5322 overhead, the other has additional RFC5322 modification and processing requirements. I suggest there will be a significant percentage of smaller/private domains that will not have the same requirements as the larger "public service" ESP domains. If a DMARC record has an "atps=1" it uses rfc6541 to check the 3rd party signer DKIM.SDID domain. If a DMARC record has an "arc=1" it uses the ARC proposal and some new "policy" proposal (TBD) to check the 3rd party seals and probably 1 or more sealer domain. I would even consider adding to the experiment the exploration of Levine's Conditional DKIM Signer proposal, with a "cond=1" tag. This proposal is a non-DNS lookup idea to authorize an expected 3rd party signer I believe added to the original signature. The DMARC extended "cond=1" tag could say "a failed p=reject message can be promoted to pass with valid 3rd party conditional signer." -- HLS From nobody Wed Nov 22 18:18:36 2017 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 8A023128954 for ; Wed, 22 Nov 2017 18:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 1zJGxm7JTD-F for ; Wed, 22 Nov 2017 18:18:33 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 CDF1A1205D3 for ; Wed, 22 Nov 2017 18:18:32 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id w47so11892515uah.3 for ; Wed, 22 Nov 2017 18:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/zW39Zt6OS2bGY0E1/N+XHoiFTXte6h+45mTrNxFB84=; b=ieKnLpiGez4DujPgxKjXl382zjy57nB2dy6US7dJId0LpdjuhEuUKZTuMus3xd/dBD 6pNWSnLUxQzO57Pm/7EIe8l7InIMtL+hJApGEhNsZqcSi4GGsIQhQNX9Ox+csgMZntjq LZoaqbGBO5NWZ78zUlhCtuKl+7b12aCj+y4xW5xD420s5T1dvNt3sGPLwisGjnY3t6us Z3MoTHsZpfO7vNYG4wnla2xTmrNENCdWVvIfvRDn+GZr10zSGwPH073fGO64kQlUC5cf Ok5AVlhAs0RH3FPOyflj/o0t8Z7D/qX0JNlQ3GZ/EPCg9kQaPCEMY/rxqYjd+bTc2C1Y 7W/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/zW39Zt6OS2bGY0E1/N+XHoiFTXte6h+45mTrNxFB84=; b=EHUlhIOC6I3TeJ4nJa8u08nSDhBlb/UcwpnY/Jxkb9itrFJHij7i2t6rAuw5oSKKk0 UsGWXPIvOvOYEowQTzeOW9G2Mi9smH9iPAnDIP++J3CZnXBX1fA8lQhEPMalNOLkkHAS DH4VWNJGoOa9pKtIcyjwiOKttWkklfqZTk2jOXicNIHkzJpN41WkFVMLuD1TvxrYwquj 8T8p8pIUGFX6h4Z4NCR4XyuAbJbadXEVb2IRHKxpqE2MfRTZroalZFa3F/jx4ma6RQDS fivIU8gl55hLrngsGfEglp/fJcN3JcGg718LlGVGAPzvs5iWJ7ikgatKnnTMIZ6IOpy8 t/Ew== X-Gm-Message-State: AJaThX65fyDk0Ce+3Qo7N2uK7jqKIM7BZEP1Kb6E3WdcgecAN+W40Qys /jRY1GPicF9YkOpPkI1uKXLNy+9D+uxbUbDPPbBn8NDMDKY= X-Google-Smtp-Source: AGs4zMZ8LgECR+Hd7aqzz/bnijp9UxgS1LK9x8MQyELnVri0HD4K+vjO66Yliy6x4Gql3LCSvOYFgCChtOfLz0VN2XU= X-Received: by 10.176.77.175 with SMTP id s47mr19940243uag.116.1511403511413; Wed, 22 Nov 2017 18:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.135 with HTTP; Wed, 22 Nov 2017 18:18:10 -0800 (PST) From: Seth Blank Date: Thu, 23 Nov 2017 02:18:10 +0000 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f4030437a0ec6914be055e9d0d63" Archived-At: Subject: [dmarc-ietf] Proposed ARC "Protocol Elements" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 23 Nov 2017 02:18:35 -0000 --f4030437a0ec6914be055e9d0d63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All- there has been back and forth about the current draft ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing context for a new reader to understand the purpose of ARC and how the components fit together. Cribbing from DKIM, I'm proposing a Protocol Elements section, which would replace section 4 of the current draft. I believe this section provides the missing context, and allows a significant amount of other explanatory text and additional sections to be removed or condensed. Because I haven't written something like this before, I wanted to get the working group's feedback on the proposal (below), its content, ordering, and anything else that should (or should not) be there before submitting as an I-D. Feedback please! Seth -------- 4 Protocol Elements As with SPF, DKIM, and DMARC, ARC makes no claims about the contents of the email message it has sealed. However, for a valid and passing ARC chain, a Final Receiver is able to ascertain: * all domains that claim responsibility for modifying the email message in transit; * participating domains that claim responsibility for handling but not modifying the message; * and trace information, including: * the [7601] authentication results each participating ADMD saw; * and otherwise missing data needed to complete a DMARC report for the sending domain; Given this information, a Final Receiver is able to make a determination if message delivery around a DMARC failure is warranted per local policy. Every participant in an ARC Chain, except for the originating sender and Final Receiver, are both an ARC Validator and then an ARC Sealer. The validated chain status must be passed to the sealer in order for sealing to occur properly; how this is done is considered ADMD specific and an implementation detail. INFORMATIONAL: It is important to understand that validating and then immediately sealing a message leaves no room for message modification, and many early implementations of ARC did not initially work because both operations were performed in the same pass. The following Protocol Elements are conceptual parts and design decisions of the protocol that are not specific to either Validators or Sealers, but ensure the ARC Chain conveys this information to a Final Receiver. 4.1 Chain of Custody At a high level, an ARC Chain represents a chain of custody of authentication and other trace information (AAR) surrounding a message, signed by each handler of the message. Each link in the chain (AMS) is designed to be brittle, insofar as it survives only until the next modification of the message. However, the overarching information around who added links and what they claimed responsibility for (AS) is designed to remain intact over the entirety of the chain. An ARC chain that is valid and passing has the attributes listed above in [X]. An ARC chain that is invalid or does not pass can make none of these claims. Until ARC usage is widespread, there will continue to be intermediaries that modify messages but do not ARC seal. As with a failing DKIM signature (https://tools.ietf.org/html/rfc6376#section-6.3), a failing ARC Chain SHOULD be treated the same as a message with no ARC Chain. [[ NOTE TO WORKING GROUP: This paragraph probably is better places in Verifier actions; I=E2=80=99ll move it when I suggest language for that, but am surf= acing it now in case the WG believes it belongs here/has problems with this statement in general. ]] 4.2 Participation is optional Validating an existing Chain and then adding your own ARC Set to a message allows you to claim responsibility for modifications done by your ADMD to benefit message delivery downstream. However, no ADMD is obligated to perform these actions. 4.3 Only one ARC Chain A message can have only one ARC Chain on it at a time. Once broken, the chain cannot be restarted, as the chain of custody is no longer valid and responsibility for the message has been lost. 4.4 Benign nature of an ARC Set Even when an ARC chain is valid and passes, its use is limited to very specific cases. An ARC Chain only adds value to a Final Receiver evaluating message delivery in the context of a DMARC failure. An ARC Chain in general, and an ARC Set in particular, were designed to only add useful information, and otherwise be benign. Specifically: * adding an ARC set to a message does not damage or invalidate an existing Chain; * validating a message exposes no new threat vectors [see:Security Considerations:DNS Overhead]; INFORMATIONAL: The ability to ARC Seal safely if an ADMD is unsure if it will be modifying a message is crucial to the success and adoption of the protocol. Some larger ADMDs ARC Seal all inbound mail, so that if messages are modified within their ADMD they can be ARC Sealed again on egress. This is a feature of ARC, not a bug. 4.5 Key Management The public keys for ARC header fields follow the same requirements, syntax and semantics as those for DKIM signatures, described in Section 3.6 of {{RFC6376}}. ARC places no requirements on the selectors and/or domains used for the ARC header field signatures. 4.6 Trace Information ARC includes trace information encoded in the AAR. While section [AAR] defines what information must be provided, Sealing ADMDs may provide additional information, and Validating receivers may use or ignore this Trace information as they wish. [[ NOTE TO WG: There is a separate section I=E2=80=99m writing on The ARC Experiment that will go into more detail on trace information, that this section should reference. ]] 4.7 Instance Tags [[ NOTE TO WG: Exactly the same as https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09#section-4 - it will need some cleanup later ]] X.8 Chain Validation Status [[ NOTE TO WG: Exactly the same as https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09#section-5.3.1 ]] 4.9 All failures are permanent Due to the nature of transmission of ARC Chains across multiple intermediaries, all errors, even temporary ones, become unrecoverable and are considered permanent. Any error validating or sealing a chain, for whatever reason, should be treated the same and MUST result in a =E2=80=9Ccv=3Dfail=E2=80=9D verdict. --f4030437a0ec6914be055e9d0d63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All- there has been back and forth about the current draft= (= https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing c= ontext for a new reader to understand the purpose of ARC and how the compon= ents fit together.

Cribbing from DKIM, I'm proposing= a Protocol Elements section, which would replace section 4 of the current = draft. I believe this section provides the missing context, and allows a si= gnificant amount of other explanatory text and additional sections to be re= moved or condensed.

Because I haven't written someth= ing like this before, I wanted to get the working group's feedback on t= he proposal (below), its content, ordering, and anything else that should (= or should not) be there before submitting as an I-D.

Feedback please!

Seth

= --------

4=C2=A0 Protocol Elements
=
As with SPF, DKIM, and DMARC, ARC makes no claims about the = contents of the email message it has sealed. However, for a valid and passi= ng ARC chain, a Final Receiver is able to ascertain:

* all domains that claim responsibility for modifying the email message = in transit;
* participating domains that claim responsibility for= handling but not modifying the message;
* and trace information,= including:
=C2=A0 * the [7601] authentication results each parti= cipating ADMD saw;
=C2=A0 * and otherwise missing data needed to = complete a DMARC report for the sending domain;

Gi= ven this information, a Final Receiver is able to make a determination if m= essage delivery around a DMARC failure is warranted per local policy.
=

Every participant in an ARC Chain, except for the origi= nating sender and Final Receiver, are both an ARC Validator and then an ARC= Sealer. The validated chain status must be passed to the sealer in order f= or sealing to occur properly; how this is done is considered ADMD specific = and an implementation detail.

=C2=A0 INFORMATIONAL= : It is important to understand that validating and then immediately sealin= g a message leaves no room for message modification, and many early impleme= ntations of ARC did not initially work because both operations were perform= ed in the same pass.

The following Protocol Elemen= ts are conceptual parts and design decisions of the protocol that are not s= pecific to either Validators or Sealers, but ensure the ARC Chain conveys t= his information to a Final Receiver.


4.1=C2=A0 Chain of Custody

At a high level, an A= RC Chain represents a chain of custody of authentication and other trace in= formation (AAR) surrounding a message, signed by each handler of the messag= e. Each link in the chain (AMS) is designed to be brittle, insofar as it su= rvives only until the next modification of the message. However, the overar= ching information around who added links and what they claimed responsibili= ty for (AS) is designed to remain intact over the entirety of the chain.

An ARC chain that is valid and passing has the attri= butes listed above in [X].

An ARC chain that is in= valid or does not pass can make none of these claims. Until ARC usage is wi= despread, there will continue to be intermediaries that modify messages but= do not ARC seal. As with a failing DKIM signature (https://tools.ietf.org/html/rfc6376#se= ction-6.3), a failing ARC Chain SHOULD be treated the same as a message= with no ARC Chain.=C2=A0 [[ NOTE TO WORKING GROUP: This paragraph probably= is better places in Verifier actions; I=E2=80=99ll move it when I suggest = language for that, but am surfacing it now in case the WG believes it belon= gs here/has problems with this statement in general. ]]


4.2 Participation is optional

Validating an existing Chain and then adding your own ARC Set to a message= allows you to claim responsibility for modifications done by your ADMD to = benefit message delivery downstream. However, no ADMD is obligated to perfo= rm these actions.


4.3 Only one ARC = Chain

A message can have only one ARC Chain on it = at a time. Once broken, the chain cannot be restarted, as the chain of cust= ody is no longer valid and responsibility for the message has been lost.


4.4 Benign nature of an ARC Set
=

Even when an ARC chain is valid and passes, its use is = limited to very specific cases. An ARC Chain only adds value to a Final Rec= eiver evaluating message delivery in the context of a DMARC failure. An ARC= Chain in general, and an ARC Set in particular, were designed to only add = useful information, and otherwise be benign. Specifically:

* adding an ARC set to a message does not damage or invalidate an = existing Chain;
* validating a message exposes no new threat vect= ors [see:Security Considerations:DNS Overhead];

= =C2=A0 INFORMATIONAL: The ability to ARC Seal safely if an ADMD is unsure i= f it will be modifying a message is crucial to the success and adoption of = the protocol. Some larger ADMDs ARC Seal all inbound mail, so that if messa= ges are modified within their ADMD they can be ARC Sealed again on egress. = This is a feature of ARC, not a bug.


4.5 Key Management

The public keys for ARC heade= r fields follow the same requirements, syntax and
semantics as th= ose for DKIM signatures, described in Section 3.6 of {{RFC6376}}.
ARC places no requirements on the selectors and/or domains used for the AR= C header field signatures.


4.6 Trac= e Information

ARC includes trace information encod= ed in the AAR. While section [AAR] defines what information must be provide= d, Sealing ADMDs may provide additional information, and Validating receive= rs may use or ignore this Trace information as they wish.

[[ NOTE TO WG: There is a separate section I=E2=80=99m writing on T= he ARC Experiment that will go into more detail on trace information, that = this section should reference. ]]


4= .7 Instance Tags

[[ NOTE TO WG: Exactly the same a= s https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09#sect= ion-4 - it will need some cleanup later ]]

X.8 Chain Validation Status



4.9 All failures are permanent
Due to the nature of tran= smission of ARC Chains across multiple intermediaries, all errors, even tem= porary ones, become unrecoverable and are considered permanent.
<= br>
Any error validating or sealing a chain, for whatever reason,= should be treated the same and MUST result in a =E2=80=9Ccv=3Dfail=E2=80= =9D verdict.

--f4030437a0ec6914be055e9d0d63-- From nobody Wed Nov 22 21:35:17 2017 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 25C4612EE8D for ; Wed, 22 Nov 2017 21:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 YWBHShKa3fgG for ; Wed, 22 Nov 2017 21:35:12 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 9B7BB12EE45 for ; Wed, 22 Nov 2017 21:35:12 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 31so6930626uaj.6 for ; Wed, 22 Nov 2017 21:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=HOA5Y7w3dTax7aAXr93/MFrd9joKjswjl4KYa3W66+8=; b=r/MWqOrNVTX96JtOVTaevdyYbOQ/AirAf/fL/agKB+JI4yqWr5aaB5se1kQJL/bwsf gUKwDOQwWx20q10vEKERDc9YuSrow54V+7GXslIibnG1qn2IYmqP6IExspOX29KDT2tD u5/A6ymr+vsSRXhXeQeN8nC7/zELlM1UQZG6NlDQwdTQy3fOO9Sa0nMhoKQC/xICoAGV +LIHaozE8KAYv2flIC2+UwEl3OtC9aB2eP14UHqjaz+QQt0Q3msV0qzJruAYY5nQMc1g Qm9pqU8eKiks9wr1zaX9tgb2eBMtJmnr9rLDl1GX6bhanQSXRPTaVCi6xENsGjIaft/w DkBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HOA5Y7w3dTax7aAXr93/MFrd9joKjswjl4KYa3W66+8=; b=dpn2epws9kYOGzzPUINXWfTyb42NSYER5M4peuCH9jrmA2YZMpITqZs3t/SCo4C+PP uNTX5KwA1C8kv4mIYbSz8frTJc01tmwqAsaAaXPwsakYgaMk9SfxfEApuReovBBwyc4v F2BaEXQCDFFUPkZhH1hR3dPH3pyvNSzTr1zoVlHPnmWVNth1L51KH0v2UyXvsqKl4N2u qMUpUhDlgqkziUCHwBfaq2EJ0lclX/a8J+QEaX85kneRKqmy1uhBRXCmHYdsUFy0lP76 sagWA92/Nx4SUGfRqk9wg3FQnstRbPj1N4vF96S59e6qXcRSrmaqwyAyHC2jFAdh02co DTgQ== X-Gm-Message-State: AJaThX7DfxOMiRkG1qNuN8n2LuOXfW9F3dNOesSjv89Y4ifq/DENPDIj 6IfLFlaW+qzpkNv1F33hKE47elm2l16DkZslnPiaYfW3G7M= X-Google-Smtp-Source: AGs4zMbbhOXW4GsZTIF51ADyFPgQ/P+KXSyYKGYcDR1N8yODHQNjt7nEelWY+AJrzVwC7CYgH1I0HgxEygagSUx0XSo= X-Received: by 10.176.83.144 with SMTP id k16mr17028149uaa.97.1511415311300; Wed, 22 Nov 2017 21:35:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.135 with HTTP; Wed, 22 Nov 2017 21:34:50 -0800 (PST) From: Seth Blank Date: Thu, 23 Nov 2017 05:34:50 +0000 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="f403045e2382bd9403055e9fcc00" Archived-At: Subject: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 23 Nov 2017 05:35:16 -0000 --f403045e2382bd9403055e9fcc00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since we're aiming for an Experimental document, it was discussed that it makes sense to define that experiment. I'm proposing the following section, and suggest it be the final section after Security Considerations but before References. For this section, I'm taking the stance "the best way to get the right answer online is to give the wrong answer online." The one thing I know is that what I've proposed below is wrong. It's just a matter of how, why, and to what degree. I'm also certain I'm missing critical design decisions, and the success criteria probably needs some hard watermark (like 90% of mail that fails/was subject to override now passes due to ARC alone). Anyway, let's attack this straw man to figure out what the right form of this section should be. Seth -------- 16 Experimental Considerations [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be removed by the document editor, or should it stay with the document as long as it=E2=80=99s experimental? ]] It must be demonstrated that ARC actually solves the problem it is supposed to - mainly, that ARC provides an effective signal to a Final Receiver that allows messages indirectly delivered to properly be rescued after a DMARC failure. This section defines what success and failure look like, the protocol design decisions that influence those criteria, and open issues that the experiment should shine light on. 16.1 Design Decisions 16.1.1 Trace information is valuable Because it is unclear exactly what information will be meaningful to Final Receivers to make delivery decisions, it was decided that the protocol would lean towards providing more information than less. 16.1.2 Chains can=E2=80=99t be restarted Originally, it was expected that ARC Chains would be restartable. However, this turned out to be a deeply complicated and implementation dependent mechanism, for a use case that wasn=E2=80=99t clear would ever occur. The A= RC-Seal was necessary when restarting a chain to guarantee that the restarter knew everyone who had been involved in the chain previously. 16.2 Success Criteria Currently, many receivers have heuristic based overrides in place to attempt to rescue mail from DMARC failures that they believe have been delivered indirectly so as not to reject or junk mail their users legitimately wish to receive. ARC will be a success if, for ARC Sealed messages, receivers show equal or better delivery rates than achieved through their overrides. 16.3 Failure Criteria The intent of ARC is to be at most value-add and at worst benign. If ARC opens up new vectors for abuse - beyond DKIM replay attacks and other known issues (see:Security Considerations) inherent in the mail protocols ARC is built upon - then ARC will be a failure. 16.4 Open Questions The following open questions are academic and have no clear answer at the time of the writing of this document. However, the ARC experiment should gather the necessary data to conclusively answer some or all of them. 16.4.1 Value of ARC Seal Because the ARC Seal was initially intended to provide context when restarting a chain, now that restarting the chain is not something ARC attempts to do, the value of the ARC Seal appears limited. As part of the ARC experiment, data should be collected to show if the ARC Seal provides value beyond the ARC Message Signature for either making delivery decisions or catching malicious actors trying to craft or replay malicious chains. 16.4.2 DNS Overhead The longer an ARC Chain, the more queries that are needed to retrieve keys to validate the Chain. It is not believed this will be a security issue (see Security Considerations:DNS Attacks), but it is unclear how much overhead will truly be added. As part of the ARC experiment, data should be collected to better understand the DNS impact of ARC Chains. 16.4.3 What trace information is valuable There are several edge cases where the information in the AAR can make the difference between message delivery or rejection. For example, if there is a well known mailing list that ARC Seals but doesn=E2=80=99t do its own ini= tial DMARC checks, a Final Receiver with this knowledge could make a delivery decision based upon the authentication information it sees in AAR[1]. Certain trace information in the AAR is useful in the construction of DMARC reports. Furthermore, certain large receivers believe the entire set of trace information would be valuable to feed into machine learning system to shine light on fraud or determine other signals related to message delivery. However, it is unclear what trace information will be consistently valuable for all receivers, regardless of size. As part of the ARC experiment, data should be collected on what trace information receivers are using that provide signal that affects deliverability, and what portions of the trace data are left untouched or provide no useful information. --f403045e2382bd9403055e9fcc00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since we're aiming for an Experimental document, = it was discussed that it makes sense to define that experiment. I'm pro= posing the following section, and suggest it be the final section after Sec= urity Considerations but before References.

For th= is section, I'm taking the stance "the best way to get the right a= nswer online is to give the wrong answer online." The one thing I know= is that what I've proposed below is wrong. It's just a matter of h= ow, why, and to what degree.

I'm also certain = I'm missing critical design decisions, and the success criteria probabl= y needs some hard watermark (like 90% of mail that fails/was subject to ove= rride now passes due to ARC alone).

Anyway, let= 9;s attack this straw man to figure out what the right form of this section= should be.

Seth

--------=

16 Experimental Considerations

[[ NOTE TO WORKING GROUP: Should this section be for the IESG only t= o be removed by the document editor, or should it stay with the document as= long as it=E2=80=99s experimental? ]]

It must be = demonstrated that ARC actually solves the problem it is supposed to - mainl= y, that ARC provides an effective signal to a Final Receiver that allows me= ssages indirectly delivered to properly be rescued after a DMARC failure.

This section defines what success and failure look = like, the protocol design decisions that influence those criteria, and open= issues that the experiment should shine light on.

16.1 Design Decisions

16.1.1 Trace information is= valuable

Because it is unclear exactly what infor= mation will be meaningful to Final Receivers to make delivery decisions, it= was decided that the protocol would lean towards providing more informatio= n than less.

16.1.2 Chains can=E2=80=99t be restar= ted

Originally, it was expected that ARC Chains wo= uld be restartable. However, this turned out to be a deeply complicated and= implementation dependent mechanism, for a use case that wasn=E2=80=99t cle= ar would ever occur. The ARC-Seal was necessary when restarting a chain to = guarantee that the restarter knew everyone who had been involved in the cha= in previously.

16.2 Success Criteria
Currently, many receivers have heuristic based overrides in pla= ce to attempt to rescue mail from DMARC failures that they believe have bee= n delivered indirectly so as not to reject or junk mail their users legitim= ately wish to receive.

ARC will be a success if, f= or ARC Sealed messages, receivers show equal or better delivery rates than = achieved through their overrides.

16.3 Failure Cri= teria

The intent of ARC is to be at most value-add= and at worst benign. If ARC opens up new vectors for abuse - beyond DKIM r= eplay attacks and other known issues (see:Security Considerations) inherent= in the mail protocols ARC is built upon - then ARC will be a failure.

16.4 Open Questions

The follo= wing open questions are academic and have no clear answer at the time of th= e writing of this document. However, the ARC experiment should gather the n= ecessary data to conclusively answer some or all of them.

16.4.1 Value of ARC Seal

Because the ARC S= eal was initially intended to provide context when restarting a chain, now = that restarting the chain is not something ARC attempts to do, the value of= the ARC Seal appears limited.

As part of the ARC = experiment, data should be collected to show if the ARC Seal provides value= beyond the ARC Message Signature for either making delivery decisions or c= atching malicious actors trying to craft or replay malicious chains.
<= div>
16.4.2 DNS Overhead

The longer = an ARC Chain, the more queries that are needed to retrieve keys to validate= the Chain. It is not believed this will be a security issue (see Security = Considerations:DNS Attacks), but it is unclear how much overhead will truly= be added.

As part of the ARC experiment, data sho= uld be collected to better understand the DNS impact of ARC Chains.

16.4.3 What trace information is valuable

<= /div>
There are several edge cases where the information in the AAR can= make the difference between message delivery or rejection. For example, if= there is a well known mailing list that ARC Seals but doesn=E2=80=99t do i= ts own initial DMARC checks, a Final Receiver with this knowledge could mak= e a delivery decision based upon the authentication information it sees in = AAR[1].

Certain trace information in the AAR is us= eful in the construction of DMARC reports.

Further= more, certain large receivers believe the entire set of trace information w= ould be valuable to feed into machine learning system to shine light on fra= ud or determine other signals related to message delivery.

However, it is unclear what trace information will be consistently= valuable for all receivers, regardless of size.

A= s part of the ARC experiment, data should be collected on what trace inform= ation receivers are using that provide signal that affects deliverability, = and what portions of the trace data are left untouched or provide no useful= information.

--f403045e2382bd9403055e9fcc00-- From nobody Wed Nov 22 21:40:03 2017 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 8C22C12F299 for ; Wed, 22 Nov 2017 21:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 43vTianwOxdx for ; Wed, 22 Nov 2017 21:39:59 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 5695712F29A for ; Wed, 22 Nov 2017 21:39:59 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id h21so7154550vke.7 for ; Wed, 22 Nov 2017 21:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EHQ3SqOOIkcKpb3JYbKp7LndP0fvqvG8xV6DSFMVdDc=; b=c3DB2thoE6JcjX6urzdHKK8pAzjiXbM9ycCK7dDzeHUUYlDt1ztpnehwplvLbJdTLV 5nne57I9sWcgscmBVn6CRPy2K1cctJ2R8FFLcAajINjFXqUPhJkZzni3xTvZ/Q1YX3Bp Ah90kKa7RoBT4b1Ra8eY71V6Ol6wIkRG9exDEHDXDjf/PzYhPNlHAsfOhgbJ08WjJaYW IYmosPMbgeIztQadbV+rM8CG9hzqiCpsxhOElmBTAOueFtQOGtN05OvDPcVmYKjwHtkM wNfHBqAFlmp09ScqO+IHCcgugrf6wvt/epeo9ENV0VhXd6arBJ57+ZFHFXkPm35xb0iJ dL+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EHQ3SqOOIkcKpb3JYbKp7LndP0fvqvG8xV6DSFMVdDc=; b=gaMdj3omjS96av8+RJ8vh7TN0aRwc5K6VsJcryySRPIJA5vIVnp2Us8zS4v9lmfG0I abTS1cd4OajhRm+Ch03uKdqP0o40tjmrLA2wtbI3ibW9sJJVLM4DLnpXRtepmv0EaEqD xCVpp94v0IpvkmM4a8kQVp055S3x6hSH08vExoI7NHkLNAWuwV+Q3fzm2/5KGb6LBM1s KzHDp3qhS0eec5AsTyFGQHgWrqGlKr7p6856oiw300gt1dabVpuWyZ3Xul5ed8nGD8D2 DM5HTm7q98jjOQtnqKcTXaT/plBtzIpZvrLzekrLX6FKevB+nNXM/iPdW4ENPdQUHn7H xHhw== X-Gm-Message-State: AJaThX7hmoALgHxXx1ADKoOsbZHen9ZQSlpiez8XR/jEa1kJGZoHuXXK PS/lEROmOyZmva8UwP++WHwwjVQG2pTyh+Annp6RLGod X-Google-Smtp-Source: AGs4zMaT1YFUYzyNBB8Ba6RREt3drwBrUd90zMnVqR9loTR1pOa3wxqDHkUMhtbIyGxONt2JY6g2T0oWswidEHnkXdo= X-Received: by 10.31.135.197 with SMTP id j188mr9958383vkd.34.1511415598099; Wed, 22 Nov 2017 21:39:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.135 with HTTP; Wed, 22 Nov 2017 21:39:37 -0800 (PST) In-Reply-To: References: From: Seth Blank Date: Thu, 23 Nov 2017 05:39:37 +0000 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a114417ced542e5055e9fdd84" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 23 Nov 2017 05:40:01 -0000 --001a114417ced542e5055e9fdd84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bumping this, too. All items below are still open. On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank wrote: > Questions 1, 2, and 4 as they relate to the text I suggested are still > open - and I don't believe the text that was pulled into -09 is correct > until these questions are answered. > > On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank wrote: > >> There have been substantial comments both on and off list about section >> 5.1.1. I've suggested new language for all of 5.1, below, to remove >> normative modification of 7601, and address several other issues. There = are >> questions for the WG below the suggested text. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Replace 5.1 with: >> >> The ARC-Authentication-Results (AAR) header field is semantically and >> syntactically identical to the Authentication-Results header defined in >> [RFC7601#2.2] as authres-header (A-R), except that the first element >> =E2=80=9CAuthentication-Results:=E2=80=9D in authres-header is replaced = with >> arc-authres-prefix as follows: >> >> arc-authres-header-prefix =3D "ARC-Authentication-Results:" [CFWS] >> arc-info >> >> arc-info =3D %x69 =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;= =E2=80=9D [CFWS] propspec) [CFWS] =E2=80=9C;=E2=80=9D >> >> arc-hop =3D 1*2DIGIT ; 1-50 >> >> The purpose of this header field is to transmit the results of any >> authentication done on the message upstream to participating ADMDs >> validating and continuing the chain. >> >> The AAR MUST contain all A-R results from within the participating ADMD, >> regardless of how many A-R headers are on the message. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Replace 5.1.1 with: >> >> 5.1.1. ptypes and properties for arc-info >> >> Certain information pertinent to ascertaining message disposition can be >> lost in transit when messages are handled by intermediaries. For example= , >> failing DKIM signatures are sometimes removed by MTAs, and most DKIM >> signature on messages modified by intermediaries will fail. Therefore, a >> passing DKIM-Signature from the first ARC signer is likely to have been >> removed by final receipt of the message. >> >> The AAR, and in particular the ptype-properties stamped in arc-info, >> provide a mechanism for this information to survive transit. >> >> The ptypes and properties defined in this section SHOULD be stamped in >> the AAR: >> >> * smtp.client_id - The connecting client IP address from which the >> message is received; >> * header.ds - The domain/selector pair for each dkim signature on the >> message (header.ds=3Dexample.com,selector) >> * arc.closest_fail - The hop number of the most recent AMS that fails to >> validate, or 0 if all hops pass. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Open questions: >> >> 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601= . >> Unfortunately, authres-header was defined in a way that makes this >> difficult. Is there a better way to say that the AAR inherits the A-R >> payload, and if anything modifies the definition of authres-header in 76= 01, >> the AAR also needs to inherit this change? >> >> To be super specific, this is the current authres-header ABNF from 7601: >> >> authres-header =3D "Authentication-Results:" [CFWS] authserv-id >> [ CFWS authres-version ] >> ( no-result / 1*resinfo ) [CFWS] CRLF >> >> Optimally, there would be: >> >> authres-payload =3D [CFWS] authserv-id >> [ CFWS authres-version ] >> ( no-result / 1*resinfo ) [CFWS] CRLF >> >> And then we could have: >> >> arc-authres-header =3D "ARC-Authentication-Results:" [CFWS] arc-info >> authres-payload >> >> 2) The optimal way to transmit DKIM selector information is in the DKIM >> A-R methodspec as header.s. If we want to prevent a normative modificati= on >> of 7601, I've proposed "header.ds" which will accomplish the same thing. >> >> 3) In the ARC-Seal megathread, there was an aside about knowing the last >> hop which validated: >> >> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana >> wrote: >> > That seems like it would be enough to fix that objection. An >> additional "first AMS failure" header at each hop would give you a list = of >> who actually modified the message. >> >> arc.closest_fail has been defined to accomplish this. >> >> 4) Have the ptype-properties been defined properly, and will these AAR >> ptype-properties need an IANA registry? >> >> 5) Finally, the ams[n] and as[n] entities were dropped, as these values >> are guaranteed to be on the final message if an ARC chain passes, so >> there's no need to encode them separately. >> >> Seth >> > > --001a114417ced542e5055e9fdd84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bumping this, too. All items below are still open.

On Fri, Oct 6, 2017 a= t 8:27 PM, Seth Blank <seth@sethblank.com> wrote:
Questions 1, 2, and 4 as they rel= ate to the text I suggested are still open - and I don't believe the te= xt that was pulled into -09 is correct until these questions are answered.<= div>

On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank <seth@sethblank.com&g= t; wrote:
There h= ave been substantial comments both on and off list about section 5.1.1. I&#= 39;ve suggested new language for all of 5.1, below, to remove normative mod= ification of 7601, and address several other issues. There are questions fo= r the WG below the suggested text.

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Replace 5.1 with:

The ARC-Authentication-Results (AAR) header field is= semantically and syntactically identical to the Authentication-Results hea= der defined in [RFC7601#2.2] as authres-header (A-R), except that the first= element =E2=80=9CAuthentication-Results:=E2=80=9D in authres-header is rep= laced with arc-authres-prefix as follows:

=C2=A0 = =C2=A0arc-authres-header-prefix =3D "ARC-Authentication-Results:"= [CFWS] arc-info

=C2=A0 =C2=A0 arc-info =3D %x69 = =E2=80=9C=3D=E2=80=9D arc-hop *([CFWS] =E2=80=9C;=E2=80=9D [CFWS] propspec)= [CFWS] =E2=80=9C;=E2=80=9D

=C2=A0 =C2=A0 arc-hop = =3D 1*2DIGIT =C2=A0; 1-50

The purpose of this head= er field is to transmit the results of any authentication done on the messa= ge upstream to participating ADMDs validating and continuing the chain.

The AAR MUST contain all A-R results from within the = participating ADMD, regardless of how many A-R headers are on the message.<= /div>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Replace 5.1.1 with:

5.1.1. ptypes and properties for arc-info

= Certain information pertinent to ascertaining message disposition can be lo= st in transit when messages are handled by intermediaries. For example, fai= ling DKIM signatures are sometimes removed by MTAs, and most DKIM signature= on messages modified by intermediaries will fail. Therefore, a passing DKI= M-Signature from the first ARC signer is likely to have been removed by fin= al receipt of the message.

The AAR, and in particu= lar the ptype-properties=C2=A0stamped in arc-info, provide a mechanism for = this information to survive transit.

The ptypes an= d properties=C2=A0defined in this section SHOULD be stamped in the AAR:

* smtp.client_id - The connecting client IP address f= rom which the message is received;
* header.ds - The domain/selec= tor pair for each dkim signature on the message (header.ds=3Dexample.com,selector)
* arc.closest_fail - The hop number of the most recent AMS that fails to v= alidate, or 0 if all hops pass.

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Open questio= ns:

1) The optimal ABNF for AAR would inherit the = A-R payload ABNF from 7601. Unfortunately, authres-header was defined in a = way that makes this difficult. Is there a better way to say that the AAR in= herits the A-R payload, and if anything modifies the definition of authres-= header in 7601, the AAR also needs to inherit this change?

To be super specific, this is the current authres-header ABNF from= 7601:

=C2=A0 =C2=A0 =C2=A0authres-header =3D= "Authentication-Results:" [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

Optimally, there would be:=

=C2=A0 =C2=A0 =C2=A0authres-payload =3D [CFW= S]=C2=A0authserv-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

And then we could have:

=C2=A0 =C2=A0arc-aut= hres-header =3D "ARC-Authentication-Results:" [CFWS] arc-info aut= hres-payload

2) The optimal way to transmit = DKIM selector information is in the DKIM A-R methodspec as header.s. If we = want to prevent a normative modification of 7601, I've proposed "h= eader.ds" which will accomplish the same thing.

3) In the ARC-Seal megathread, there was an aside about knowing the last= hop which validated:

On Mon, Aug 14, 2017 at= 5:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
> That seem= s like it would be enough to fix that objection.=C2=A0 An additional "= first AMS failure" header at each hop would give you a list of who act= ually modified the message.

arc.closest_= fail has been defined to accomplish this.

4) Have = the ptype-properties been defined properly, and will these AAR ptype-proper= ties need an IANA registry?

5) Finally, the ams[n]= and as[n] entities were dropped, as these values are guaranteed to be on t= he final message if an ARC chain passes, so there's no need to encode t= hem separately.

Seth


--001a114417ced542e5055e9fdd84-- From nobody Fri Nov 24 08:39:21 2017 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 E4DDA128C84 for ; Fri, 24 Nov 2017 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=RaBRbEBV; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=AHcNFLhw 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 C-is3xBUH327 for ; Fri, 24 Nov 2017 08:39:19 -0800 (PST) Received: from winserver.com (listserv.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 02B27128BBB for ; Fri, 24 Nov 2017 08:39:18 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1539; t=1511541549; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=+rSoFgBXzj1Wpd1TaP292Jke/XE=; b=RaBRbEBVzQz98S2KcmkxjFqGBnaFgR2X2eIO/xK0bUp0QTuaF9UfQ+jfudPaHo bYkqoU+FnXLr1rsyhiGgyijIZVWdKD2sUc8gKLAbrzRoWYiUQHoQvq4t19/O75td 2JOiPW8GnvaCsaVMRU12W50B/9BN90lBKF6ygqVdjQVdc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 24 Nov 2017 11:39:09 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1410277650.13.3760; Fri, 24 Nov 2017 11:39:07 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1539; t=1511541391; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jhFqx9X PXxlZ42YtQuiCRq7zNums0niUdtPRQt4jQv8=; b=AHcNFLhwmgC+ny+kQ9hSMMe jw9NKnDwscQ7oWtkOHNkgLnEJPNo/tJXjpgjOBVjjMBOPQgx+U93GHJOG2UEKmgk hJyoouY3QcNUiiyLImmX13Fgz8ElE/5b8/Ed1Y+hnA8IJmwibUqO5Dl4AankZIpY n2/tmZVrTaOMhl0Mxy0k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 24 Nov 2017 11:36:31 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1410232032.9.289304; Fri, 24 Nov 2017 11:36:30 -0500 Message-ID: <5A184B2C.9000009@isdg.net> Date: Fri, 24 Nov 2017 11:39:08 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Nov 2017 16:39:21 -0000 On 11/23/2017 12:34 AM, Seth Blank wrote: > 16 Experimental Considerations > > [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to > be removed by the document editor, or should it stay with the document > as long as it’s experimental? ]] > > It must be demonstrated that ARC actually solves the problem it is > supposed to - mainly, that ARC provides an effective signal to a Final > Receiver that allows messages indirectly delivered to properly be > rescued after a DMARC failure. Fwiw ..... DMARC is an DKIM Author Domain Policy System. A DMARC (p=reject/quarantine) policy failure is Author Domain defined. Hence an ARC "signal" to correct this failure must also be Author Domain defined, otherwise there will exist a security loop hole. The DMARC should have an dedicator, i.e. tag extension, that allows the Author Domain to publish and declare to the world receivers that some sort of successful ARC calculation (TBD) promotes the DMARC failure to a "pass" (or non-fail) condition. Conversely, DMARC should also have an dedicator (by default) that ARC (or anything else) should not correct/rescue DMARC mail failures. To avoid adding DMARC tags, possibly the first ARC seal created by the original DMARC author domain could be a method to trigger the ARC corrections. Something like: If the receiver detects a DMARC failure, but also sees a valid ARC seal where seal #1 is tied to the author domain, then the receiver MAY promote the failure to pass. -- HLS From nobody Fri Nov 24 13:53:14 2017 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 315C71270AC for ; Fri, 24 Nov 2017 13:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.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 GtE6T1zjH5oC for ; Fri, 24 Nov 2017 13:53:11 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 992EA120454 for ; Fri, 24 Nov 2017 13:53:11 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id g12so15534170uaa.1 for ; Fri, 24 Nov 2017 13:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Cwe50g0vyJaQEHH9MWrk5AB43LdUupsNxp+FIvO/ay8=; b=Kn3SGot8HqYS2nNVPAI3At5dNm8hcV1bokQOYI7Z566GUp2pdgD2wmKulsLASx8TJR Q6ogfpNcoF607u+xFUlCr4jJAb7hX2NL7cOPbosOUGpACaaV15a8f14O2Q+5bi0d9yn3 rCQvzsc4inkPn+CPbzQ74U25VVFCsk4hdlCzE3gLwk3zASichO97nOVbfcVZXGKwNaqX t6kT/yzK5WZ89hNA+LGUCA/ykTqwR2zFivsbM9i+55yP5WjLPOXfUrd1t4NojzaJj3gn wZyZZ2IkEFhEiTW0gG6xZxlnwicwM/olhdko0zvCK15fB6s6bm7FlXeopkdel2WP9JN3 JDLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Cwe50g0vyJaQEHH9MWrk5AB43LdUupsNxp+FIvO/ay8=; b=BrvOc5ZDM51COgbHoYoq69TMDV4xEEH8CDFIMlpgP+16NjPNphHlpAmayV1Eao0onL m46NbcyeP/UqBaqVAhw4IdKqK0xKRmfB69/88dHg0lCf+OE8/qjGod8BPdUikynrYQkQ OtJPPtLy6lhFc+I2dGzdZBVptO/i08vaJ6+BKCXeMDWbJKkhObqUKpCACqkNCPKpplmJ E39hoGKTOQQ0jDYINEp30oCQJ3x5fIwGLjHd28ph3NBGv2zc15PV1q2vxecCoIERqpfR ChjPiqjl5ddHP836Vmf45I8ZL1F5bZrc+e7dmwI8LgRUdMl1SKFkSwWTaT8rYRwZ72+Q ahDQ== X-Gm-Message-State: AJaThX7DOjID707ij4xP9JNvgVUd8sd/d22iUlx/k5jO1gybNCuukJnw ngDQAT17zCjLHYPYOh3tFLv5AsLNSLrSVLoCe0BUVXsT X-Google-Smtp-Source: AGs4zMZ3dUAVGapc7fWdCrQNf52fV+gV6DBkgu5ZZlnOcxnze9Dcq8Gxhy3wAleJXMZZAImt/sc+Wk1Kvq9ZG06WWU4= X-Received: by 10.176.82.216 with SMTP id w24mr15922036uaw.13.1511560390331; Fri, 24 Nov 2017 13:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.135 with HTTP; Fri, 24 Nov 2017 13:52:49 -0800 (PST) In-Reply-To: <5A184B2C.9000009@isdg.net> References: <5A184B2C.9000009@isdg.net> From: Seth Blank Date: Fri, 24 Nov 2017 21:52:49 +0000 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18f62c1f6afa055ec19423" Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 24 Nov 2017 21:53:13 -0000 --94eb2c18f62c1f6afa055ec19423 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 24, 2017 at 4:39 PM, Hector Santos wrote: > > Fwiw ..... > > DMARC is an DKIM Author Domain Policy System. A DMARC > (p=reject/quarantine) policy failure is Author Domain defined. Hence an > ARC "signal" to correct this failure must also be Author Domain defined, > otherwise there will exist a security loop hole. > Agreed with you that the language needs to be less DMARC-specific. ARC should assist any authentication mechanism that loses signal due to transmission via an intermediary. I'll clarify the language. --94eb2c18f62c1f6afa055ec19423 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 24, 2017 at 4:39 PM, Hector Santos <hsantos@isdg.net>= wrote:
Fwiw .....

DMARC is an DKIM Author Domain Policy System.=C2=A0 A DMARC (p=3Dreject/qua= rantine) policy failure is Author Domain defined.=C2=A0 Hence an ARC "= signal" to correct this failure must also be Author Domain defined, ot= herwise there will exist a security loop hole.

Agreed with you that the language needs to be less DMARC-specific. = ARC should assist any authentication mechanism that loses signal due to tra= nsmission via an intermediary. I'll clarify the language.=C2=A0
--94eb2c18f62c1f6afa055ec19423-- From nobody Wed Nov 29 09:09:35 2017 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 1F886127867 for ; Wed, 29 Nov 2017 09:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, 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 KY-S59Uw7cul for ; Wed, 29 Nov 2017 09:09:32 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 C4BE3126B72 for ; Wed, 29 Nov 2017 09:09:31 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id 94so4702525lfy.10 for ; Wed, 29 Nov 2017 09:09:31 -0800 (PST) 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=q47WQ1/bnKVLnlUQQsuqinPgussRbpXZzC3SfDk6P7U=; b=Obpfsbi/U1hnUG+cFVzViISG0qZMsh6T7HBncRyV745J6HEBzx6SEMkVikB/z4I2Nn 89Pl1tq6Lk4vMbNKvVciN4jg3j9rVyDRLlk+79mQk4zjaYJ8b62Gu22khAj512RxCAH0 xsm8Ql23N4PzaDBwa5jd2nfD9dPKIwTuF531k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=q47WQ1/bnKVLnlUQQsuqinPgussRbpXZzC3SfDk6P7U=; b=hRqbqeBEd1wIBWo0Unyea9KIypeFWrJ+XDCnkvwVDcohNCeu8xQLz008UqSpZ1P03W oTjopCBKJeb/ysXCqWFvNI7IQdo3VcRa61knTw9vVepolz05U10x2Fv3gk9YwDvQw7D9 6s+yq0CLguTZ0zqrQasUl7Nk3zQzZxTohAmoGiD33F7GNj76ukeyPk7QpxufuZHj0n/x r02L0WYU8e/gAiMwhNOHUT+1ulNFHB5G1pqowRHJmQdhFaVExXDmOtrH7s5OkwaJOoB1 OBEveK5Pyat0TsNajxIDMDt4BhIgj3pkGQ2DvVY7oUNdPaXv0F8JZCkE0KaAvk3CjwgC 1aUw== X-Gm-Message-State: AJaThX4xpJOxc/pC5Djez/gDujH/XgcB+ggohlMbPQxj6p7ubhP5hXbj JwpS7h8teK025BgOnSqR6DvH/l6laC4NUNsVZE4tbAeUH7IKpg== X-Google-Smtp-Source: AGs4zMZ+UJ6X/NbXpLgxeYcu1th/uSxz4W3vC5Rznm+wqbE1H9Ou94NSiNKboy45qm/df6B6P3f9KKwqbFfBkl/lM3k= X-Received: by 10.46.66.140 with SMTP id h12mr1697779ljf.140.1511975369730; Wed, 29 Nov 2017 09:09:29 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.9 with HTTP; Wed, 29 Nov 2017 09:09:28 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 29 Nov 2017 17:09:28 +0000 X-Google-Sender-Auth: iaVP-EEdUzWRzzmlvOPfvUpYMDE Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1c18c2d27cd7055f22326f" Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Protocol Elements" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:09:34 -0000 --94eb2c1c18c2d27cd7055f22326f Content-Type: text/plain; charset="UTF-8" On Thu, Nov 23, 2017 at 2:18 AM, Seth Blank wrote: > All- there has been back and forth about the current draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09) missing > context for a new reader to understand the purpose of ARC and how the > components fit together. > > Cribbing from DKIM, I'm proposing a Protocol Elements section, which would > replace section 4 of the current draft. I believe this section provides the > missing context, and allows a significant amount of other explanatory text > and additional sections to be removed or condensed. > In general, this looks pretty good. I'll work on integrating it into the -10 work in progress. There are a few grammatical tweaks that I'll do as I integrate it. --Kurt --94eb2c1c18c2d27cd7055f22326f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 23, 2017 at 2:18 AM, Seth Blank <seth@sethblank.com> wrote:
All- there has been back and forth about the current draft (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-09= ) missing context for a new reader to understand the purpose of ARC and= how the components fit together.

Cribbing from DKIM, I&= #39;m proposing a Protocol Elements section, which would replace section 4 = of the current draft. I believe this section provides the missing context, = and allows a significant amount of other explanatory text and additional se= ctions to be removed or condensed.

<= div>In general, this looks pretty good. I'll work on integrating it int= o the -10 work in progress. There are a few grammatical tweaks that I'l= l do as I integrate it.

--Kurt=C2=A0
--94eb2c1c18c2d27cd7055f22326f-- From nobody Wed Nov 29 09:12:53 2017 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 E15F01273E2 for ; Wed, 29 Nov 2017 09:12:51 -0800 (PST) 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 Qranicdsb-GH for ; Wed, 29 Nov 2017 09:12:50 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 06B73126B72 for ; Wed, 29 Nov 2017 09:12:50 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id x204so4699011lfa.11 for ; Wed, 29 Nov 2017 09:12:49 -0800 (PST) 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=Lo4ZvkxB8Tbh0KYitxVRd646gIpGPylqyNadKDB47A8=; b=U4SQJ4GY/BAFQxQBHC+62No24py8ApdF7wsuh5gtR1osdLa5+ijghyp7qq0YEeJB7R oDz2zJmXsg8mJClsuiEcbNA+hYxZQ6v0M8Bapx5P+0Db2WiIZq35rWEiTVC5BCljyEh8 aKf6jWAo8DbiWuM7h1xGXOCx1zs9oRaFcOk3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Lo4ZvkxB8Tbh0KYitxVRd646gIpGPylqyNadKDB47A8=; b=rKXBzGxDM+3UNnlpm70RBLtMg+D4apm4aHEJlJxl/wEFfqQ9JEg2dEcbUls/x+dqBR VFPRir6ycecy6JhswOeCFeZO2KW0fiT2jVKtjFx+tu8psSZJWuUEswibwsn1PW4RhhZW YC3T7hzB3LswxrymEFMIq17RdAHG569nmhGkXioG9unORUASqAlPahJK7nWkdubp4XEe p3gKihvuo5E4Mei8Gx3qSWkRmAfoh0BS1MOzlfUWZoa45FGg8zD/7AIlaT5OLqXbjTqe M3uEAWDT4+udlcGAnQfAOGdeeoM997t3vF2zZhKBRhhqR3ebWKfpmi6EhxjBpuy98Okq GagQ== X-Gm-Message-State: AJaThX6fz/2UV5rkWQEczTlRLK0YsADMD9cJVwWzcIiBPmv6mmYN23cT jwoDZ75ZwlUFZGdr3cpPjpUuoeQTekvjBW9jDl/rXZjV8OU= X-Google-Smtp-Source: AGs4zMaj7eGAAIiQMnGCaaeVHWwMVw7dzKIsdBJ4jf2hIvyOYRH5ORxCS+QtcO25OcvADYM0iIYXyiSmTaNNHJBY0+4= X-Received: by 10.46.29.13 with SMTP id d13mr1734096ljd.8.1511975568136; Wed, 29 Nov 2017 09:12:48 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.9 with HTTP; Wed, 29 Nov 2017 09:12:47 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 29 Nov 2017 17:12:47 +0000 X-Google-Sender-Auth: OdNG-kCGrOvcBbE4wzrzf1pT-Jg Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c082cdca5f0bf055f223ea7" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:12:52 -0000 --94eb2c082cdca5f0bf055f223ea7 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 23, 2017 at 5:39 AM, Seth Blank wrote: > Bumping this, too. All items below are still open. > > On Fri, Oct 6, 2017 at 8:27 PM, Seth Blank wrote: > >> Questions 1, 2, and 4 as they relate to the text I suggested are still >> open - and I don't believe the text that was pulled into -09 is correct >> until these questions are answered. >> >> On Tue, Sep 5, 2017 at 5:52 PM, Seth Blank wrote: >> >>> >>> >>> Open questions: >>> >>> 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from >>> 7601. Unfortunately, authres-header was defined in a way that makes this >>> difficult. Is there a better way to say that the AAR inherits the A-R >>> payload, and if anything modifies the definition of authres-header in 7601, >>> the AAR also needs to inherit this change? >>> >>> To be super specific, this is the current authres-header ABNF from 7601: >>> >>> authres-header = "Authentication-Results:" [CFWS] authserv-id >>> [ CFWS authres-version ] >>> ( no-result / 1*resinfo ) [CFWS] CRLF >>> >>> Optimally, there would be: >>> >>> authres-payload = [CFWS] authserv-id >>> [ CFWS authres-version ] >>> ( no-result / 1*resinfo ) [CFWS] CRLF >>> >>> And then we could have: >>> >>> arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info >>> authres-payload >>> >> Has there been any traction on the idea of modifying 7601 to implement this partitioning (bis)? Or should we bake in our own "hotwire" of the existing spec? --Kurt --94eb2c082cdca5f0bf055f223ea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 23, 2017 at 5:39 AM, Seth Blank <seth@sethblank.com> wrote:
Bumping this, too. All items below are still open.

On Fri, Oct 6, = 2017 at 8:27 PM, Seth Blank <seth@sethblank.com> wrote:
=
Question= s 1, 2, and 4 as they relate to the text I suggested are still open - and I= don't believe the text that was pulled into -09 is correct until these= questions are answered.

On Tue, Sep 5, 2017 at = 5:52 PM, Seth Blank <seth@sethblank.com> wrote:
<elided&= gt;

Open questions:

1) Th= e optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. Unfort= unately, authres-header was defined in a way that makes this difficult. Is = there a better way to say that the AAR inherits the A-R payload, and if any= thing modifies the definition of authres-header in 7601, the AAR also needs= to inherit this change?

To be super specific, thi= s is the current authres-header ABNF from 7601:

=C2=A0 =C2=A0 =C2=A0authres-header =3D "Authentication-Results:&quo= t; [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

Optimally, there would be:

= =C2=A0 =C2=A0 =C2=A0authres-payload =3D [CFWS]=C2=A0authserv-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*r= esinfo ) [CFWS] CRLF

And then we could have:
<= div>
=C2=A0 =C2=A0arc-authres-header =3D "ARC-Authe= ntication-Results:" [CFWS] arc-info authres-payload
<= /blockquote>

Has there been any traction on t= he idea of modifying 7601 to implement this partitioning (bis)? Or should w= e bake in our own "hotwire" of the existing spec?=C2=A0

--Kurt
--94eb2c082cdca5f0bf055f223ea7-- From nobody Wed Nov 29 09:18:02 2017 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 CC33C128768 for ; Wed, 29 Nov 2017 09:18:00 -0800 (PST) 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 c9SVobuMPM-7 for ; Wed, 29 Nov 2017 09:17:59 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 31E50127867 for ; Wed, 29 Nov 2017 09:17:59 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id f13so4711796lff.12 for ; Wed, 29 Nov 2017 09:17:59 -0800 (PST) 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=iUNVAVBYU0LoiJhqNufcNRFQvseeTKanNsKDcDzFROU=; b=aLZySA63MIlX1jrb0k1jbngNTu53WCJhCXAbLr8uWWSgemyQfQbQEWTII48xSp9JZE RBg/gWYfBHk8cgFM6UEMU+zaiEPSSiPIDg9ZmH6NxNeodM5wmlEi4ntsl6BQws8hHLxf 10HO/ylqnTeA1suf1WcpliGv1l7yMm8CU4FQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iUNVAVBYU0LoiJhqNufcNRFQvseeTKanNsKDcDzFROU=; b=CI4kPeInImF/L6Cq0iT44o7ZUDCO1Eg+Ag7cMuVQ89tlk8prdmeisa4G/v2Rd1uNrd 4gCeRI9hB18ldtyEMyRS0YSED1zT35SH1LHsBWS0a/OMy8VtTrWmPFZziwhApMjlAUuU BQDuS8lr4ag9XeHv9mLwETZCe63CCRwlnTGyhfxfo73UXbSSha0YF/xOMSS83VlFVRDK OJbkp0IXBs14i0FFtdVk9YBkYoPgjfDVXc5c1ls82Wvn4p+Qej6dmGkXYtRYkXM+9VF1 I6fAponRDntt2GF+wQ9eavvB/MiYO+cqgqzVnVijfVW4N6ixmC9VkiqG+S2sx2yBvg1U GMlA== X-Gm-Message-State: AJaThX4uLrndBOAI0x/ptczHjB4QvlUTf3oYJtxxbMnYxkEDqaR9GLwP bRusH28FsGfQ9U2nU0nduIgQxxsvimQLXv8uHDcMFywoyn4= X-Google-Smtp-Source: AGs4zMZMycnq2iqbL9tsFBMn3sUUIZAYJD+T1afKnDfA8/262w5uyjk/I/4fctDoucF2JeZbNB7MBTXcF37kS5mOziM= X-Received: by 10.25.21.11 with SMTP id l11mr1462676lfi.142.1511975877360; Wed, 29 Nov 2017 09:17:57 -0800 (PST) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.25.56.9 with HTTP; Wed, 29 Nov 2017 09:17:56 -0800 (PST) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 29 Nov 2017 17:17:56 +0000 X-Google-Sender-Auth: Dj__njGC4yczn708pUGuRidsbv4 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113f240e145712055f225194" Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:18:01 -0000 --001a113f240e145712055f225194 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 23, 2017 at 5:34 AM, Seth Blank wrote: > Since we're aiming for an Experimental document, it was discussed that it > makes sense to define that experiment. I'm proposing the following section, > and suggest it be the final section after Security Considerations but > before References. > > For this section, I'm taking the stance "the best way to get the right > answer online is to give the wrong answer online." The one thing I know is > that what I've proposed below is wrong. It's just a matter of how, why, and > to what degree. > While I have a number of issues with the details of the proposal, I'll tackle those in another thread. The fundamental problem that I have with the whole "experiment" approach is that it is something like throwing a baseball into a pool of quiescent sharks. I have no confidence that "hoping" for people to do something that a random group of people propose in an RFC will bear any fruit at all. It's not an experiment, it's an exercise in futility. --Kurt --001a113f240e145712055f225194 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 23, 2017 at 5:34 AM, Seth Blank <seth@sethblank.com> wrote:
Since we&#= 39;re aiming for an Experimental document, it was discussed that it makes s= ense to define that experiment. I'm proposing the following section, an= d suggest it be the final section after Security Considerations but before = References.

For this section, I'm taking the s= tance "the best way to get the right answer online is to give the wron= g answer online." The one thing I know is that what I've proposed = below is wrong. It's just a matter of how, why, and to what degree.

While I have a number of issues wi= th the details of the proposal, I'll tackle those in another thread. Th= e fundamental problem that I have with the whole "experiment" app= roach is that it is something like throwing a baseball into a pool of quies= cent sharks. I have no confidence that "hoping" for people to do = something that a random group of people propose in an RFC will bear any fru= it at all. It's not an experiment, it's an exercise in futility.

--Kurt=C2=A0

--001a113f240e145712055f225194-- From nobody Thu Nov 30 23:12:53 2017 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 975BD126D74 for ; Thu, 30 Nov 2017 23:12:52 -0800 (PST) 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 qsE34eCcLXse for ; Thu, 30 Nov 2017 23:12:51 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 6157D124D37 for ; Thu, 30 Nov 2017 23:12:51 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id d141so12014520qkc.12 for ; Thu, 30 Nov 2017 23:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZbVXOLh3u1T/GrTVUoW8FBdw6YIXdS/dbhlwimmUtCY=; b=u0W+iyuH2uAPRWyoBct8avjs6XKhFeKet6pkiK65njC1JUYtAlZuij4fssr+9VCJB0 WpQ3ZdYEni0smk9C0nRW4n9Nonq2OR0/1lCgRySzKf/vO5bl2pk2ZIjHWfJsyKTkeWQI K8EMT4+P7N77Yj/K4lesMGsDOAeSzUNGAhF2CzY1QenXLB5CF0UDrAATvED1c7DDE51H EgjVSyZ/dpfliSnFlqqs76E60Wm6yW2W1LwhBoN0s27nT5cvsGll/vTFb+VJDE29KAjc i0blcLmRLFuR1L+9sAJivyY0yHFOvGsaGft2Qc06oL1pfRXXRdYhrhlHXuBTRAotorFX S34g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZbVXOLh3u1T/GrTVUoW8FBdw6YIXdS/dbhlwimmUtCY=; b=QuRTLFDALWo83Rv/pKmaqCBC8qICtHipNy8RWOt50ugBAnAO/l9cTsefwVitXmWKQn 8co6lpB6u+n3HBCzUcd/aM58Ta/X6aD3uAGYcuAypu1s6DyHnzmc29wdIstIz06nFR1b hr3b0A43ZMvrKuI0j6jfOExylhMoscnI5QIGfyyVR9qBJE6BMOncAVqyrjLGEEKg447c Z/YSw2hK9/+ESK/5ls/i6t8EGwwFuahqQVq968hJpMxGeBbVPuD5uoyy1Vt/O3E3c7vW xp8bb4VmS8T8E8rWtd0RDyiH+gxGgK9gMkJBkkvaSF5pVTNXaqCV/bZcxBaLLGKv0ejv jgFg== X-Gm-Message-State: AJaThX6Robwd4qZPDndG6PHWAG9HIgqnWHgYeR9vTY55CHAGMbjCz0L3 0WZdrRgEagrPppN2VAsD7vSVuBqSZAs8OelYUZ4= X-Google-Smtp-Source: AGs4zMYYT8YliFMK2SK9T3jElYJ6EGewCt8ONC4Fi3Dho96zgXuP6UrBnhD7PFXbdoavyR2yMK94smhKmaIea3UQybk= X-Received: by 10.55.73.87 with SMTP id w84mr6605764qka.215.1512112370408; Thu, 30 Nov 2017 23:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.196 with HTTP; Thu, 30 Nov 2017 23:12:49 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 30 Nov 2017 23:12:49 -0800 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114a7394b2e232055f42182c" Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 07:12:52 -0000 --001a114a7394b2e232055f42182c Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 9:17 AM, Kurt Andersen (b) wrote: > While I have a number of issues with the details of the proposal, I'll > tackle those in another thread. The fundamental problem that I have with > the whole "experiment" approach is that it is something like throwing a > baseball into a pool of quiescent sharks. I have no confidence that > "hoping" for people to do something that a random group of people propose > in an RFC will bear any fruit at all. It's not an experiment, it's an > exercise in futility. > I suppose that depends on the audience. If the audience is motivated, something will happen. But what would you hope sharks would do with a baseball anyway? -MSK --001a114a7394b2e232055f42182c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 29, 2017 at 9:17 AM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
While I have a number of issues with the details of the = proposal, I'll tackle those in another thread. The fundamental problem = that I have with the whole "experiment" approach is that it is so= mething like throwing a baseball into a pool of quiescent sharks. I have no= confidence that "hoping" for people to do something that a rando= m group of people propose in an RFC will bear any fruit at all. It's no= t an experiment, it's an exercise in futility.

I suppos= e that depends on the audience.=C2=A0 If the audience is motivated, somethi= ng will happen.

But what would you hope sharks wou= ld do with a baseball anyway?

-MSK
=C2=A0=
--001a114a7394b2e232055f42182c-- From nobody Thu Nov 30 23:21:21 2017 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 C81B6127275 for ; Thu, 30 Nov 2017 23:21:19 -0800 (PST) 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 I8VFPvDHS8Fl for ; Thu, 30 Nov 2017 23:21:18 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 E9BDB1201F2 for ; Thu, 30 Nov 2017 23:21:17 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id b184so12036572qkc.13 for ; Thu, 30 Nov 2017 23:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G3x+yA22KN7hsZkIucpZWnOaexcRlNFJUSrxv3YkzP8=; b=ZHj4iVCsET+7KHznH9CjFP/sSGlIP98YQeZ2gAkbyi8oPEdo2vN8yDb8+0cdGYdCyo oOetiZJd5A2v01+S+NuFL34/CZ1WeZmxHh0Q2X5v33oJv4ke4S9f9kNFyLDT8z27vmIe asr3z9O4MNAr2oPYSPr1FUWRp5BCY/AHsdQDq2l8HLgcSjWYGuWHFcaxUk8AjvEjYum+ V/kTtMlwU7lhXbsy/YTUqbPbKAz+eGzcsHDDYrXtvi9RDYBnc7CmEjUOpmavhAwAkZ8c pqaqCpUd+6wHBj/fze6d7o9NmsnP2n/+5INr7CjPa4qJsm0o7a7u4g5spSQjukF8M6dp Ft8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G3x+yA22KN7hsZkIucpZWnOaexcRlNFJUSrxv3YkzP8=; b=RWK3kM/8uorKvXPi5BC2WhdjvWirtbB3kVNwNyzOLQinrBb8hOdK+AfvLN8hgvQWjQ EABMi+qmABM/2iut5TV/ei4x1884tIHIQX6XALk9Sw7L+w+a1/hu26iB7cnY/69wmTiw GZ6eSxucssjkcEAnNYqP3TkOYsr8fOSLkxlRgvM56p6CPBGkeRxNxn5A+jGe84NMl8V1 7I+3YPZ3xU12e4H6DK29/EMp2IwPWuym85vyUL6jjdlSrtqOig3PQGtaLm2Eszw3hNX8 ICg4VscgyzVuLobcM1EJcfx8c7rOrqs4sI8QpPawiUFSuVPTkk17HvUIi17UTduYVKnd QbDA== X-Gm-Message-State: AJaThX43wrchlalRraK8RzZ11nOEcAT9PAlaBdBVB3z/FgDydasSxjCm Mso46xa8r1OMxZMWVvEZwcbMuZbftA0b2eIQTHY= X-Google-Smtp-Source: AGs4zMbypdY+5rwcnPi8NWB1B1Sez0kE3a4gqCdVL9KBvBIItl4eJzi1LZuVLlzZBTxM093vads+cgc/aEl1eVhwqvY= X-Received: by 10.55.73.87 with SMTP id w84mr6629609qka.215.1512112876933; Thu, 30 Nov 2017 23:21:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.196 with HTTP; Thu, 30 Nov 2017 23:21:16 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 30 Nov 2017 23:21:16 -0800 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114a7394e3d6d9055f423660" Archived-At: Subject: Re: [dmarc-ietf] Proposed ARC "Experimental Considerations" section X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 07:21:20 -0000 --001a114a7394e3d6d9055f423660 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Omitting stylistic nits for now: On Wed, Nov 22, 2017 at 9:34 PM, Seth Blank wrote: > 16 Experimental Considerations > > [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be > removed by the document editor, or should it stay with the document as lo= ng > as it=E2=80=99s experimental? ]] > For what it's worth, RFC6541 was also an experimental RFC I did some time ago and it had a section that described (albeit briefly) what the experiment process would be. The AD sponsoring that document suggested it, and it seems to have worked. So I think leaving something like this in the document through to publication is a good idea. [...] > > 16.1.2 Chains can=E2=80=99t be restarted > > Originally, it was expected that ARC Chains would be restartable. However= , > this turned out to be a deeply complicated and implementation dependent > mechanism, for a use case that wasn=E2=80=99t clear would ever occur. The= ARC-Seal > was necessary when restarting a chain to guarantee that the restarter kne= w > everyone who had been involved in the chain previously. > I think a reader without context won't know what "restarting" a chain means= . [...] > > 16.4 Open Questions > Maybe "Questions To Be Resolved By The Experiment" and then drop the prose. 16.4.1 Value of ARC Seal > > Because the ARC Seal was initially intended to provide context when > restarting a chain, now that restarting the chain is not something ARC > attempts to do, the value of the ARC Seal appears limited. > I don't know what this means without describing "restart" (as above). As part of the ARC experiment, data should be collected to show if the ARC > Seal provides value beyond the ARC Message Signature for either making > delivery decisions or catching malicious actors trying to craft or replay > malicious chains. > ... or indeed, beyond DKIM. > 16.4.3 What trace information is valuable > > There are several edge cases where the information in the AAR can make th= e > difference between message delivery or rejection. For example, if there i= s > a well known mailing list that ARC Seals but doesn=E2=80=99t do its own i= nitial > DMARC checks, a Final Receiver with this knowledge could make a delivery > decision based upon the authentication information it sees in AAR[1]. > It might also be worth noting in the experiment what ARC provides to those operators with large knowledge bases, like the one to which you alluded here, and those without. Furthermore, certain large receivers believe the entire set of trace > information would be valuable to feed into machine learning system to shi= ne > light on fraud or determine other signals related to message delivery. > Given that this involves secret sauce on the part of such operators, the best they can provide is an anecdote here, not actual data. -MSK --001a114a7394e3d6d9055f423660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Omitting stylistic nits for now:

On Wed, Nov 2= 2, 2017 at 9:34 PM, Seth Blank <seth@sethblank.com> wrote:<= br>
16 Experimental Considerations

[[ NOTE TO WORKING GROUP: Should this section be for the IESG only to= be removed by the document editor, or should it stay with the document as = long as it=E2=80=99s experimental? ]]

For what it's worth, RFC6541 was also an experimental RFC I did = some time ago and it had a section that described (albeit briefly) what the= experiment process would be.=C2=A0 The AD sponsoring that document suggest= ed it, and it seems to have worked.=C2=A0 So I think leaving something like= this in the document through to publication is a good idea.
[...]

16= .1.2 Chains can=E2=80=99t be restarted

Originally,= it was expected that ARC Chains would be restartable. However, this turned= out to be a deeply complicated and implementation dependent mechanism, for= a use case that wasn=E2=80=99t clear would ever occur. The ARC-Seal was ne= cessary when restarting a chain to guarantee that the restarter knew everyo= ne who had been involved in the chain previously.
<= div>
I think a reader without context won't know what &qu= ot;restarting" a chain means.

[...]

16.4 Open Questions

Maybe "Questions To Be Resol= ved By The Experiment" and then drop the prose.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
16.4.1 Value of ARC Seal
Because the ARC Seal was initially intended to provide cont= ext when restarting a chain, now that restarting the chain is not something= ARC attempts to do, the value of the ARC Seal appears limited.
=

I don't know what this means without d= escribing "restart" (as above).

As part of the ARC experiment, dat= a should be collected to show if the ARC Seal provides value beyond the ARC= Message Signature for either making delivery decisions or catching malicio= us actors trying to craft or replay malicious chains.

... or indeed, beyond DKIM.
=C2=A0
16.4.3 What trace information= is valuable

There are several edge cases where the info= rmation in the AAR can make the difference between message delivery or reje= ction. For example, if there is a well known mailing list that ARC Seals bu= t doesn=E2=80=99t do its own initial DMARC checks, a Final Receiver with th= is knowledge could make a delivery decision based upon the authentication i= nformation it sees in AAR[1].

I= t might also be worth noting in the experiment what ARC provides to those o= perators with large knowledge bases, like the one to which you alluded here= , and those without.

Furthermore, certain large receivers believe the entire set o= f trace information would be valuable to feed into machine learning system = to shine light on fraud or determine other signals related to message deliv= ery.

Given that this involves secret = sauce on the part of such operators, the best they can provide is an anecdo= te here, not actual data.

<= div class=3D"gmail_quote">-MSK
--001a114a7394e3d6d9055f423660-- From nobody Thu Nov 30 23:38:54 2017 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 5772C127077 for ; Thu, 30 Nov 2017 23:38:52 -0800 (PST) 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 bkOzi4gcb_r5 for ; Thu, 30 Nov 2017 23:38:50 -0800 (PST) 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 0BB63120721 for ; Thu, 30 Nov 2017 23:38:50 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 63so12136283qke.0 for ; Thu, 30 Nov 2017 23:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BI5ltgjgIgRU3+bltjl4XGor1RA595RW+uy4j2dfZsQ=; b=gB1WG0C71Fkmt0mhwP3hxHKQvVYkCJR47onqu794/eBqETbAnHwUMQcuxGod1EoYt4 HrCLJolJ87cprVcZr5Ymxl2nhMzg25jKH+nTNDkuUh1XLbyABDyzYwtocgxI8DYtA3CE if1Ln7lBuzQ9fLbPu6LIzntydXnawwmHSNRjbwBrLoa6LgVF3slXG7U6P6TZluF9LRcf HYKpahVhSDo9hjZn1/8VSbngbYDL8fc+1h9rwwS0MpogMw2cyUQAY66JnGL5SNypuxWj vs0q2wsyE8faYy9ea7JFGNpb/7N7AmcYZyZrXigSP8SfecpKIbkqb8oIaJY9AcFKqPpt /JTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BI5ltgjgIgRU3+bltjl4XGor1RA595RW+uy4j2dfZsQ=; b=msXx8mcGfaC6AXNbPl7EXaBX1/Ooe3zEAPcp8XQieig7eJAKXdNg6Pw0wckwuj/fRF Pt5gtTu4PxKUMbOaCnLkFPQFr4iwCTtioSySCvxD+cBe+aPAjq3MHMyDrQVCqmnKft22 uPlAYxita87J1uARJ+wb9wEhLor3isGcY5Q5LLRmWA457oBRmH14I8A5mE3J1XQ+I0Uw bheZAvZa87FgKfJ6ZZZ713fOaaQoUTDV7epjixo76ybdjmI2j179J96CjTjjC3wpTDP7 TqVPWy8OlqNI1N1p9eWAuw7nti9L5Eta0bMH+SoI5MFXI2UPRCKcrlFOczfgLXHgjq5h p7sg== X-Gm-Message-State: AKGB3mLsFSf8F22KAEK3duMj3BF/hBcBB5+RR1mHAbx4vLUDPZkVfZyy 19wmcIvbtWzoR6f4Lv5eGt/wKi9Bx7iqCJbJu8M= X-Google-Smtp-Source: AGs4zMZDfq/YwjNRpgdfPsE3AtFfRquq+kEsVfBaA1R+cdv3lE+6ubd9uRGVMsdr2h3yDvUPQXnIii+FTeYsu8NQ0FA= X-Received: by 10.55.222.21 with SMTP id h21mr6581297qkj.324.1512113929001; Thu, 30 Nov 2017 23:38:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.196 with HTTP; Thu, 30 Nov 2017 23:38:48 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Thu, 30 Nov 2017 23:38:48 -0800 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="089e082de984991e1c055f427545" Archived-At: Subject: Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 07:38:52 -0000 --089e082de984991e1c055f427545 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank wrote: > Replace 5.1.1 with: > > 5.1.1. ptypes and properties for arc-info > > Certain information pertinent to ascertaining message disposition can be > lost in transit when messages are handled by intermediaries. For example, > failing DKIM signatures are sometimes removed by MTAs, and most DKIM > signature on messages modified by intermediaries will fail. Therefore, a > passing DKIM-Signature from the first ARC signer is likely to have been > removed by final receipt of the message. > > The AAR, and in particular the ptype-properties stamped in arc-info, > provide a mechanism for this information to survive transit. > > The ptypes and properties defined in this section SHOULD be stamped in the > AAR: > > * smtp.client_id - The connecting client IP address from which the message > is received; > * header.ds - The domain/selector pair for each dkim signature on the > message (header.ds=example.com,selector) > * arc.closest_fail - The hop number of the most recent AMS that fails to > validate, or 0 if all hops pass. > Why "client_id" instead of "client-ip"? (it's an IP address, not some opaque identifier) Why "header.ds" and not "header.d" and "header.s"? (why combine them?) Why "arc.closest_fail" and not "arc.closest-fail"? (use a hyphen, to be consistent with other entries already in the registry) Unless someone wants to point me at the part of the spec that says otherwise, the IP address is utterly orthogonal to anything ARC is doing. I'd rather not shoe-horn it in here, even if DMARC operators might want it. Rather, we should do a separate document (outside this WG if needed) that registers a header field for this, since there's been something like X-Original-IP in public use for years anyway, and then just require that it be signed or something. Or if we really want it in A-R, register it accordingly, independent of ARC. But if we want to do that last thing, I'd like to have some sort of discussion on the record for changing the scope of A-R, which is really what we're talking about here. As I've said before, A-R's original purpose was to collect data about authentication work done at the ingress MTA that might be of interest to users or filters. We've specifically kept things like IP addresses unregistered on the basis that your average human won't know whether to trust one string of octets over another, and there's a treatise in the appendix of RFC7601 and all of its predecessors that lays out why. But that's the logic we applied eight years ago when RFC5451 was written. If in the intervening time we've decided we want to repurpose it to carry arbitrary stuff that might be of benefit to filters and concede that users aren't the likely primary consumers as we intended, then we should probably do up an RFC7601bis that says so, and renovate the prose and registries accordingly. I'll put the editing work in, but there has to be recorded consensus to back that move. =============== > > Open questions: > > 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601. > Unfortunately, authres-header was defined in a way that makes this > difficult. Is there a better way to say that the AAR inherits the A-R > payload, and if anything modifies the definition of authres-header in 7601, > the AAR also needs to inherit this change? > > To be super specific, this is the current authres-header ABNF from 7601: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > Optimally, there would be: > > authres-payload = [CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > And then we could have: > > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info > authres-payload > That seems reasonable to me. 2) The optimal way to transmit DKIM selector information is in the DKIM A-R > methodspec as header.s. If we want to prevent a normative modification of > 7601, I've proposed "header.ds" which will accomplish the same thing. > Why the merge? 3) In the ARC-Seal megathread, there was an aside about knowing the last > hop which validated: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana > wrote: > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > I'm not sure I like a hop number in here, which harkens back to Received counts. I'd rather say it's an instance number, or better yet the sealing domain name. 4) Have the ptype-properties been defined properly, and will these AAR > ptype-properties need an IANA registry? > If we decide we want AAR separate from of AR, then we also need to decide if AAR uses the AR registry (in which case all of this has to get mushed in with regular A-R stuff, but flagged "ARC use only" or something (ick), or we'll need our own registry (ugh). -MSK --089e082de984991e1c055f427545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank <seth@sethbla= nk.com> wrote:
Replace 5.1.1 wi= th:

5.1.1. ptypes and properties for arc-info
=

Certain information pertinent to ascertaining message d= isposition can be lost in transit when messages are handled by intermediari= es. For example, failing DKIM signatures are sometimes removed by MTAs, and= most DKIM signature on messages modified by intermediaries will fail. Ther= efore, a passing DKIM-Signature from the first ARC signer is likely to have= been removed by final receipt of the message.

The= AAR, and in particular the ptype-properties=C2=A0stamped in arc-info, prov= ide a mechanism for this information to survive transit.

The ptypes and properties=C2=A0defined in this section SHOULD be sta= mped in the AAR:

* smtp.client_id - The connecting= client IP address from which the message is received;
* header.d= s - The domain/selector pair for each dkim signature on the message (header= .ds=3Dexample.com,selector)
* arc.closest_fail - The hop number of the most recent= AMS that fails to validate, or 0 if all hops pass.

Why "client_id" instead of "clien= t-ip"?=C2=A0 (it's an IP address, not some opaque identifier)
<= br>
Why "header.ds" and not "header.d" and &q= uot;header.s"?=C2=A0 (why combine them?)

Why "a= rc.closest_fail" and not "arc.closest-fail"?=C2=A0 (use a hy= phen, to be consistent with other entries already in the registry)

Unless someone wants to point me at the part of the spec t= hat says otherwise, the IP address is utterly orthogonal to anything ARC is= doing.=C2=A0 I'd rather not shoe-horn it in here, even if DMARC operat= ors might want it.=C2=A0 Rather, we should do a separate document (outside = this WG if needed) that registers a header field for this, since there'= s been something like X-Original-IP in public use for years anyway, and the= n just require that it be signed or something.=C2=A0 Or if we really want i= t in A-R, register it accordingly, independent of ARC.

But if we want to do that last thing, I'd like to have some so= rt of discussion on the record for changing the scope of A-R, which is real= ly what we're talking about here.=C2=A0 As I've said before, A-R= 9;s original purpose was to collect data about authentication work done at = the ingress MTA that might be of interest to users or filters.=C2=A0 We'= ;ve specifically kept things like IP addresses unregistered on the basis th= at your average human won't know whether to trust one string of octets = over another, and there's a treatise in the appendix of RFC7601 and all= of its predecessors that lays out why.=C2=A0 But that's the logic we a= pplied eight years ago when RFC5451 was written.=C2=A0 If in the intervenin= g time we've decided we want to repurpose it to carry arbitrary stuff t= hat might be of benefit to filters and concede that users aren't the li= kely primary consumers as we intended, then we should probably do up an RFC= 7601bis that says so, and renovate the prose and registries accordingly.=C2= =A0 I'll put the editing work in, but there has to be recorded consensu= s to back that move.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Open questions:

1) The opti= mal ABNF for AAR would inherit the A-R payload ABNF from 7601. Unfortunatel= y, authres-header was defined in a way that makes this difficult. Is there = a better way to say that the AAR inherits the A-R payload, and if anything = modifies the definition of authres-header in 7601, the AAR also needs to in= herit this change?

To be super specific, this is t= he current authres-header ABNF from 7601:

=C2= =A0 =C2=A0 =C2=A0authres-header =3D "Authentication-Results:" [CF= WS] 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

Optimally, there would be:

=C2=A0 = =C2=A0 =C2=A0authres-payload =3D [CFWS]=C2=A0authserv-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

And then we could have:
=C2=A0 =C2=A0arc-authres-header =3D "ARC-Authenticati= on-Results:" [CFWS] arc-info authres-payload

That seems reasonable to me.

=
2) The optimal way to = transmit DKIM selector information is in the DKIM A-R methodspec as header.= s. If we want to prevent a normative modification of 7601, I've propose= d "header.ds" which will accomplish the same thing.

Why the merge?

3) In the ARC-Seal megathread,= there was an aside about knowing the last hop which validated:
<= br>
On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <brong@fastmailteam.c= om> wrote:
> That seems like it would be enough to fix = that objection.=C2=A0 An additional "first AMS failure" header at= each hop would give you a list of who actually modified the message.

arc.closest_fail has been defined to accompli= sh this.

I'm not sure I lik= e a hop number in here, which harkens back to Received counts.=C2=A0 I'= d rather say it's an instance number, or better yet the sealing domain = name.

=
4) Have the ptype-properties been defined properly, and will these AAR= ptype-properties need an IANA registry?

<= /div>
If we decide we want AAR separate from of AR, then we also need t= o decide if AAR uses the AR registry (in which case all of this has to get = mushed in with regular A-R stuff, but flagged "ARC use only" or s= omething (ick), or we'll need our own registry (ugh).

-MSK
--089e082de984991e1c055f427545--