From nobody Tue May 2 17:00:43 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 04F12129C70 for ; Tue, 2 May 2017 17:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG5mVq0hP7G1 for ; Tue, 2 May 2017 17:00:40 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36F3129B23 for ; Tue, 2 May 2017 16:59:02 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l18so16034243oig.2 for ; Tue, 02 May 2017 16:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zk2xo3uUSFnMKrZNbWHGM+yTz67Xx/hvnGJWXJ3tqZE=; b=qsApqZRSwDgKAKb4GSiqkgWX0Hx4czSaS9CJWGSQQj6lGYuzGt/GdO/Yia9GRgrjYH hXjjhuyTdNoaflJK3/YSOySptrYRxfkM11ulyVCRF3pWzeZAezfdcTbyX2d7/dZqiEgf dTcCALZr9Uyeh2vsVoQ1f/kuN1hMeHk4CUwwpleKFGvAH3XW4/6zWBejwkv1+mKZO4Zz Qv+IZLjijOSUAAcLRG0sS6+HtKGHO1K4xcRHqnuVMUqtES07lK5R2gaSOuxOScOOXdaj cBL2m6QklM4/Cb7A9c66p71eoEbV4uUowCBRQLYbAyjYUe9gfj822CvwNFZHpBA2rDF5 11YQ== 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=Zk2xo3uUSFnMKrZNbWHGM+yTz67Xx/hvnGJWXJ3tqZE=; b=hpGxlnow+jaQQhho9IP996X6OpA/58JJ8Ub9TYoekXwnNMIoaFux+IfAEnYQrh1H6T c7x6U6Ht9r76gGWvPJDZWn8eMyT+Gm5sK/ik/mzC8Yu/evZMNffAYuAnQ1F9SJG9Y3b8 8t/SPUVjJbp9axpl2zyp4cERiC4yO54n7gmP/aVO2zPlgMZKNJuJysUaKn7GXnfJgDew RIA3RAQyA3HzUYVKSnRca+Y1Y02GVOkenHyfz2vLb8Ywc0h5VGjCJgrxisoRPDDtiiH1 ZEOPLKrXtEd7bAH6QZrD5TuKg3Nk6wU3BGufxbXSDeIhekLsT5i0w+iY/7ohBCngscuH rgKg== X-Gm-Message-State: AN3rC/5tElPAy7BqLxkXYPXlSdVGt6j1F/lzyl9MYMVlonZ4e2TkfZsc EMD9m0RLhlnY8gEq24pwL191eOnuU+Ss X-Received: by 10.202.204.197 with SMTP id c188mr4697398oig.194.1493769542019; Tue, 02 May 2017 16:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 2 May 2017 16:59:01 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 2 May 2017 16:59:01 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c17710ee087b054e93525c Archived-At: Subject: Re: [dmarc-ietf] Just posted dmarc-arc-protocol-03 . . . 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, 03 May 2017 00:00:42 -0000 --001a11c17710ee087b054e93525c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 28, 2017 at 4:04 PM, Kurt Andersen (b) wrote= : > Based on the dialog around the AAR header unclarity in section 5.1.3, I > adjusted the first paragraph to read: > > ARC-Authentication-Results is a copy of the Authentication-Results header >> field [RFC7601] value with the corresponding ARC-set instance (=E2=80=9C= i=3D=E2=80=9D) tag >> value prefixed to the Authentication-Results value string. Since >> Authentication-Results headers are frequently deleted from a message=E2= =80=99s >> header list, the AAR is created for archival purposes by each >> ARC-participating ADMD outside of the trust boundary of the originating >> system. > > "frequently deleted"... In fact, RFC 7601 section 5 "Removing Existing Header Fields" recommends it: "For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA." and has other advice as well... as well as a hint at doing what ARC now codifies: "It is entirely possible that a border MTA for example.com will explicitly trust authentication results asserted by upstream host example.net even though they exist in completely disjoint administrative boundaries. In that case, the border MTA MAY elect not to delete those results; moreover, the upstream host doing some authentication work could apply a signing technology such as [DKIM] on its own results to assure downstream hosts of their authenticity. An example of this is provided in Appendix B." Should we reference this directly? --001a11c17710ee087b054e93525c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 28, 2017 at 4:04 PM, Kurt Andersen (b) <k= both@drkurt.com> wrote:
<= div class=3D"gmail_quote">
Based on the dialog around the AAR header unclarity in se= ction 5.1.3, I adjusted the first paragraph to read:

ARC-Authentication-Results i= s a copy of the Authentication-Results header field [RFC7601] value with the corresponding ARC-set instance (=E2=80=9Ci=3D=E2=80=9D) tag= value prefixed to the Authentication-Results value string. Since=20 Authentication-Results headers are frequently deleted from a message=E2=80= =99s=20 header list, the AAR is created for archival purposes by each=20 ARC-participating ADMD outside of the trust boundary of the originating=20 system.

"freq= uently deleted"... In fact, RFC 7601 section 5 "Removing Existing= Header Fields" recommends it:

"For security = reasons, any MTA conforming to this specification MUST
delete any discov= ered instance of this header field that claims, by
virtue of its authent= ication service identifier, to have been added
within its trust boundary= but that did not come directly from another
trusted MTA."

=
and has other advice as well... as well as a hint at doing what = ARC now codifies:
"It is entirely possible that a border
MTA for example.com will explicit= ly trust authentication results
asserted by upstream host example.net even though they exist in
completely disjoint administrative boundaries.=C2=A0 In that case, the
border MTA MAY elect not to delete those results; moreover, the
upstream host doing some authentication work could apply a signing
technology such as [DKIM] on its own results to assure downstream
hosts of their authenticity.=C2=A0 An example of this is provided = in
Appendix B."

Should we reference= this directly?
--001a11c17710ee087b054e93525c-- From nobody Wed May 3 09:23:47 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 1FDD7128792 for ; Wed, 3 May 2017 09:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51utUyEIvu-G for ; Wed, 3 May 2017 09:23:42 -0700 (PDT) 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 21488128E19 for ; Wed, 3 May 2017 09:21:37 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id g49so44715757uaa.1 for ; Wed, 03 May 2017 09:21:37 -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=06A3RwNnGCRqjoh4GdkIVgH5FvpuOi0W96JHP1xsM34=; b=Zon/w6T4x5Dzg/28QFFAj5ZAQEnePjN9koBILDdEjCzmTVU5D9YusyiS8KOHiqvR1/ 6R5xzvEvbvlVzQM7gzYBS/YHVGsaBby7WCtcbcEcSVCexjSoycqZ2NKfDvRZENwAVFAb EWoo/z3qQZqaxh3V7yqFsynTQj7cAbUpLizZ4= 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=06A3RwNnGCRqjoh4GdkIVgH5FvpuOi0W96JHP1xsM34=; b=rMxLXMFL5nsx76c7MkxlbwVsdiaIHbuG+KMlgopaXcGvn5d0/87se5u4tzexHVWaAI U2YFsz0hh09+VVGIowwtlV5ORbLmXBKLRxhgy7KdkP/R2l9oklcxz4kzcZUeJCQGnlFL kPFpapG538P5tFOd9Xr6t7K8k32izNsEHQL9kdjWzlw+2q6jgZN5+NUVccUYRel3Ul3e YtRVyAw6cKySp8C3SS8aP8fZwoxdrVrgC7hhEae1MAXbli5Weq7h192VtJbXjfv/wbMu BCu5jXSI2mpGNOooPPcDOwwjWyJO8Fa6efP0BkiWp3juE788ZP9tqbvoHIu2sMjujWPb pMIA== X-Gm-Message-State: AN3rC/7xS2EgGdOa+SWEgLThQ9cibkSZZ7nWuxcF2cwwkP6+zMw0dMjQ yhr0pmq5ETwhkJT70QPbSzBUzwI2pA== X-Received: by 10.176.71.7 with SMTP id h7mr20216243uac.82.1493828496145; Wed, 03 May 2017 09:21:36 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.80.33 with HTTP; Wed, 3 May 2017 09:21:35 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 3 May 2017 09:21:35 -0700 X-Google-Sender-Auth: reZQJCk5bakcZJ_vQgRJzO6Q4TU Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403045e6248de5a24054ea10c80 Archived-At: Subject: Re: [dmarc-ietf] Just posted dmarc-arc-protocol-03 . . . 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, 03 May 2017 16:23:45 -0000 --f403045e6248de5a24054ea10c80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2017 at 4:59 PM, Brandon Long wrote: > On Fri, Apr 28, 2017 at 4:04 PM, Kurt Andersen (b) > wrote: > >> Based on the dialog around the AAR header unclarity in section 5.1.3, I >> adjusted the first paragraph to read: >> >> ARC-Authentication-Results is a copy of the Authentication-Results heade= r >>> field [RFC7601] value with the corresponding ARC-set instance (=E2=80= =9Ci=3D=E2=80=9D) >>> tag value prefixed to the Authentication-Results value string. Since >>> Authentication-Results headers are frequently deleted from a message=E2= =80=99s >>> header list, the AAR is created for archival purposes by each >>> ARC-participating ADMD outside of the trust boundary of the originating >>> system. >> >> > "frequently deleted"... In fact, RFC 7601 section 5 "Removing Existing > Header Fields" recommends it: > > "For security reasons, any MTA conforming to this specification MUST > delete any discovered instance of this header field that claims, by > virtue of its authentication service identifier, to have been added > within its trust boundary but that did not come directly from another > trusted MTA." > Yes, I think that referring to this is reasonable (in the protocol doc). > and has other advice as well... as well as a hint at doing what ARC now > codifies: > "It is entirely possible that a border > MTA for example.com will explicitly trust authentication results > asserted by upstream host example.net . . . > > Should we reference this directly? > Seems like a reasonable thing to put into the usage doc. I'm working on some explanations about ARC vs. ADMDs for said document at this time and will add this reference. --Kurt --f403045e6248de5a24054ea10c80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 2, 2017 at 4:59 PM, Brandon Long <blong@google.com> w= rote:
<= div>On Fri, Apr 28, 2017 at 4:04 PM, Kurt Andersen (b) &l= t;kboth@drkurt.com> wrote:


"For se= curity reasons, any MTA conforming to this specification MUST
delete any= discovered instance of this header field that claims, by
virtue of its = authentication service identifier, to have been added
within its trust b= oundary but that did not come directly from another
trusted MTA."


Should we reference= this directly?

See= ms like a reasonable thing to put into the usage doc. I'm working on so= me explanations about ARC vs. ADMDs for said document at this time and will= add this reference.

--Kurt=C2=A0

<= /div>
--f403045e6248de5a24054ea10c80-- From nobody Thu May 4 00:56: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 04568129BC5 for ; Thu, 4 May 2017 00:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 IJ7bwIwIE3vp for ; Thu, 4 May 2017 00:56:08 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F03129BAC for ; Thu, 4 May 2017 00:56:01 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id q1so4515490qkd.2 for ; Thu, 04 May 2017 00:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0kvfnGtmEqSCP90zrfykvoyBdrzdoXom2O5fGTdi0p4=; b=Xj+S/poHQ5Vk5tMM/FIV+LowsxslFySWUcgAXnRnNvGkmjwJLxk2cqCKIZh7WoqOvE i1c3Qf8IUkDD2YWOaU3TU1LItxzdE4XR7abEvdOT4SfXuYrloY5RGDi8dkiZqqrnZtST mxCOOSJpNK0ZsgJwQenuA6rghvdWalu/qbFAIE8oJ/F9WMF1xt4yGbqcqic6+oScVj15 rAzlkVy6cLK7X9klS6tBigkPQ29baAKcpAkeVOLFXUtE3L6MJLBvly1zaAwUXVZypBxR AwIXevJw7mSL0rj8h58tPnL1Z4W6Q6xb+1RXKY3ldYh05wi9XylpcScss61ZPHxOaLcu HB7w== 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=0kvfnGtmEqSCP90zrfykvoyBdrzdoXom2O5fGTdi0p4=; b=qC/VMQKsNAd63bwwbSabeNnsHSx3FyH5J9M9Hr1mesk1YZ/QFTSQVPfQvatFbPgBA2 HUGEjBKz0XoQSJCZ1tFAdLTBQ/84qAwRM/kom9lmmbFDRs3HJCmGWkIIZp7lQSStVf8V kM9Z0FLDY5OdjHSB06l8dxZEr8cuuTpS/46P79NgcIw14UUAVbDx9DOOy6PocV8LnRSU /K81/3ZZqt+zbDQesi/pUkQyzNgXBY4UoW9iB41uOirVn5i9n4PBFl8Hw6+6gtgYcUiv ohBQYOGVxgIawt6tWP+saWjZEvkIlmx0Hkvfe4WynnPu3o8g6Ia3+Nokq6J5AYmjhbhK ZsVQ== X-Gm-Message-State: AODbwcDeQxLbz+uZYA6ntBSegyczNMbMOdPTjjZfZsvGMUxIfKT/Wjg6 DnRNhE8809P2ZGqtExOz1sJfaV3t8qkPL7M= X-Received: by 10.55.18.23 with SMTP id c23mr3658068qkh.41.1493884560841; Thu, 04 May 2017 00:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.163 with HTTP; Thu, 4 May 2017 00:56:00 -0700 (PDT) From: "Murray S. Kucherawy" Date: Thu, 4 May 2017 00:56:00 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11473ff695a2db054eae1aad Archived-At: Subject: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 04 May 2017 07:56:10 -0000 --001a11473ff695a2db054eae1aad Content-Type: text/plain; charset=UTF-8 Colleagues, As I progress (slowly, alas) toward completing my sample implementation of OpenARC, I've found myself taking a lot of notes about the current draft. This has helped me make progress; in some cases it became things I posted to the list, and in others it was just to help or confirm my understanding of the protocol. I have developed this enough to become a fairly comprehensive alternative text to the current draft. I find the layout of this version to flow better for my own purposes, and in a few places I've tried to clarify some of the material by rewriting chunks of it. None of this is meant to assert that the current draft is deficient; I've just found it to be a helpful exercise for me. I offer it here to the WG as a contribution; the WG of course is free to use some, all, or none of it as it wishes. http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt If it would be more helpful to post this as an I-D, please let me know. -MSK --001a11473ff695a2db054eae1aad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

As I progress (slo= wly, alas) toward completing my sample implementation of OpenARC, I've = found myself taking a lot of notes about the current draft.=C2=A0 This has = helped me make progress; in some cases it became things I posted to the lis= t, and in others it was just to help or confirm my understanding of the pro= tocol.

I have developed this enough to become a fairly compreh= ensive alternative text to the current draft.=C2=A0 I find the layout of th= is version to flow better for my own purposes, and in a few places I've= tried to clarify some of the material by rewriting chunks of it.=C2=A0 Non= e of this is meant to assert that the current draft is deficient; I've = just found it to be a helpful exercise for me.

I offer it here to th= e WG as a contribution; the WG of course is free to use some, all, or none = of it as it wishes.

http://blackops.org/~msk/draft-kucherawy-dmarc-arc-= base.txt

If it would be more helpful to post this as = an I-D, please let me know.

-MSK
--001a11473ff695a2db054eae1aad-- From nobody Thu May 4 08:00:46 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 3A8F1128616 for ; Thu, 4 May 2017 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 ySwqauFGd5mP for ; Thu, 4 May 2017 08:00:41 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 20351124281 for ; Thu, 4 May 2017 08:00:41 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id j29so12305878qtj.1 for ; Thu, 04 May 2017 08:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J4GZJ1k/GckobbkWjyPO0r8OZ+f6opIMSRGjpttfpGE=; b=Mj28x4U4dOgN81PD/Y3wE7DnHe+fDdtKMxEpsHpYmCgbBR881gNWVeLXid3pviC1A1 BE/DaHtxoZHKByO9neBw3MnzURo+nlScswpUuDzXRrbRt9hdiGfTKEq2qwswIAYhyeuU oiLScnFbkyg/sRuKq4BDDPpgnBzqdIratE0wF21HihGiXu0f02Lq3LIoZ2wpM1cCFO7I iU2CpAc9PWFv6L3r5NkSn5WdxkxVFSC1gaPPWCQfNi9vobBQjMKn7FnFN/YubUnqDPp4 HfDqTu+21PJE17GtwdadF1O3ajJJ1qilQx7q8r26bYdJL31wy7601bEDr0R+tKAMbvlE 3gbg== 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=J4GZJ1k/GckobbkWjyPO0r8OZ+f6opIMSRGjpttfpGE=; b=Dx8WjCVjf7EOcHQgHI/uJ2drNLTSYbBlJNcr1Oacdt2kvInDMiRZLyyXt+5znxVgek RCmRbQISkOdmo8aSb+8H95AfvEXaW2CKRwZq2QleLcawzoApi0kQvq7/N21dnsUnRBmT Gnz6u/p76Gz+mNGfZF28nWHLngaCrgkzh1G0OTy66g5CKCWyyGauXyxn/6b2EzUBjQ4A 3zxVfmCWIFjY/hIHSCG7coO9c5onIdlUtqv/H2crM5Kk/AtXEB8FfBSLW9uSecqvBFGG wRL/MVYUPB7IfFzAG79Fj+Kv+Rk5MfNPN7x7Rpx68MHJmzpChCrQkjAWiFottZnaR4/l Bd2w== X-Gm-Message-State: AN3rC/7VlWJVNATpjTFrv18xNaCohN0w32uALAdz97/Z9TZ7ZdFOIW1Q 6E0b8yUDyMJAH7fVlthUrQgDorm/zA== X-Received: by 10.200.56.156 with SMTP id f28mr1654903qtc.252.1493910040293; Thu, 04 May 2017 08:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.120 with HTTP; Thu, 4 May 2017 08:00:19 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Thu, 4 May 2017 08:00:19 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113bca80474e60054eb4095e Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 04 May 2017 15:00:44 -0000 --001a113bca80474e60054eb4095e Content-Type: text/plain; charset=UTF-8 Murray, This is very helpful, thank you. I find section 7 easier to follow than Kurt's pseudo code in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.1.5.1 Quick bug (I think): In 7.5, you say "If no seals pass validation" but I think you mean "If all seals pass validation". Additionally there is a discrepancy between your section 7 item 5 and Kurt's pseudo code. As I'm reading it, your logic allows a chain with a cv=pass at i=1 to be valid, and Kurt's does not. I believe Kurt's is correct, especially based on your definition of the cv=none value in 5.3.1 of your draft. Thanks! Sure I'll have more feedback soon, Seth On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy wrote: > Colleagues, > > As I progress (slowly, alas) toward completing my sample implementation of > OpenARC, I've found myself taking a lot of notes about the current draft. > This has helped me make progress; in some cases it became things I posted > to the list, and in others it was just to help or confirm my understanding > of the protocol. > > I have developed this enough to become a fairly comprehensive alternative > text to the current draft. I find the layout of this version to flow > better for my own purposes, and in a few places I've tried to clarify some > of the material by rewriting chunks of it. None of this is meant to assert > that the current draft is deficient; I've just found it to be a helpful > exercise for me. > > I offer it here to the WG as a contribution; the WG of course is free to > use some, all, or none of it as it wishes. > > http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt > > If it would be more helpful to post this as an I-D, please let me know. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113bca80474e60054eb4095e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Murray,

This is very helpful, thank you= . I find section 7 easier to follow than Kurt's pseudo code in=C2=A0https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#s= ection-5.1.1.5.1

Quick bug (I think): In = 7.5, you say "If= no seals pass validation" but I think you mean "If all seals pas= s validation".

Additionally ther= e is a discrepancy between your section 7 item 5 and Kurt's pseudo code= . As I'm reading it, your logic allows=C2=A0a chain with a cv=3Dpass at i=3D1 to be valid, a= nd Kurt's does not. I believe Kurt's is correct, especially based o= n your definition of the cv=3Dnone value in 5.3.1 of your draft.

Thanks! Sure I'll have more feedback soon,=C2=A0<= /div>

Seth

On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucheraw= y <superuser@gmail.com> wrote:
Colleagues,

As I progre= ss (slowly, alas) toward completing my sample implementation of OpenARC, I&= #39;ve found myself taking a lot of notes about the current draft.=C2=A0 Th= is has helped me make progress; in some cases it became things I posted to = the list, and in others it was just to help or confirm my understanding of = the protocol.

I have developed this enough to become a fairly = comprehensive alternative text to the current draft.=C2=A0 I find the layou= t of this version to flow better for my own purposes, and in a few places I= 've tried to clarify some of the material by rewriting chunks of it.=C2= =A0 None of this is meant to assert that the current draft is deficient; I&= #39;ve just found it to be a helpful exercise for me.

I offer it her= e to the WG as a contribution; the WG of course is free to use some, all, o= r none of it as it wishes.

http://blackops.org/~msk/<= wbr>draft-kucherawy-dmarc-arc-base.txt

If it wou= ld be more helpful to post this as an I-D, please let me know.

-MSK

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




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113bca80474e60054eb4095e-- From nobody Thu May 4 15:44: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 12E9D1294B3 for ; Thu, 4 May 2017 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSSi6E7geCSP for ; Thu, 4 May 2017 15:44:29 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 1F6B51294E9 for ; Thu, 4 May 2017 15:44:29 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id p24so41216762ioi.0 for ; Thu, 04 May 2017 15:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OXcdqfolewQt5tA0/ymCTzbpQXu/YYWNJn7f/bNa80g=; b=hCaSifZLbA/RAjDqQGgFKSACuRP6k1A7Yad7BR/+nxQFcoxrbwbSjN1pKwuBdbwVVz RL5qhkaB4VohbtjuYS2YdL0Hz6Ej6ymfnuovZXUoq4TcpVkyAUH1tU/F0caeGf+BX/N2 s27AD8RS1xuWwPXdToUpVh75E8X5ZulpPQ41xJRFTYwWqFQzc6S9K85T9o9KaQUAD3dU NRerkUCY13HA6d96Z0Vm9E10hfGH38PevKLpgffKWFM+nfLC6QCMDMEpMz0OuGIWk7QH bIbOsf1ga4XPgU/b0X5EevrW+WO93MLdHjDxosQQ/ZaQPMg8S66A1wEZZIKu2PJZ6Jb0 lkAQ== 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=OXcdqfolewQt5tA0/ymCTzbpQXu/YYWNJn7f/bNa80g=; b=KVaRYkBalIH+WnnPtHu3GsFlxVCrFjsOeYc5BxxatNoOauIHcNci6tURp+VeBvfor4 MT7l2OUEP92LgirQMqAt5lQLqheD46JqU0hdhjL/d9Ykoe2L3q/le49P1rwQNYc7fYpr /8YKX2b2Sm2u0thgbeQVmoSYdXR59tzUVaB2EeqaOSfVkBAP4YH5sNYwWYKV5CGVFmVU BT83NMqiz8LnLy0M5tId04ExY0qxbDlVHorDHsqH2d0DSFCacDp7QcDfNFyhQU50WFlf MAaTT768zdOAkz0VpA8ilF/mzWTa5cOj+vRRwZyd6J2C/EV9GXilQ+zOohQXWYK0ALA4 7b8w== X-Gm-Message-State: AODbwcB9KW4vegZxD0rm1bLNcYZpX2yPYPA75tcp7Kc8kk/oAmTtZeUl jSf+0Id1B7cu2Iz2PJ3U11Bw6ScExitc2+s= X-Received: by 10.157.82.136 with SMTP id f8mr1398940oth.135.1493937868162; Thu, 04 May 2017 15:44:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 4 May 2017 15:44:27 -0700 (PDT) From: Brandon Long Date: Thu, 4 May 2017 15:44:27 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f40304355418f3198d054eba8376 Archived-At: Subject: [dmarc-ietf] signing keys for arc-seal/arc-message-signature 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, 04 May 2017 22:44:31 -0000 --f40304355418f3198d054eba8376 Content-Type: text/plain; charset=UTF-8 When thinking about how to extract information from an arc chain, I was wondering at the "owner" of a section of the chain. Theoretically, that's the ADMD. A single hop, however, has three separate domain ownerships, the srv_id from the AAR, and the d= field from the AS and AMS. Our current implementation uses google.com for the d= field, and we have three different srv_id's for different pools that serve different purposes. That said, the srv_id has no "validation" except for by the key signature, so d= seems like a stronger "owner". Except, the AMS and AS can have separate selectors and domains. I'm not sure if that's useful or desirable. I'm tempted to only consider a chain valid if the domains are the same, and I guess not care if the selectors are. Should we require them to be the same? If we do, should they only be specified once? For changing algorithms, I guess s would be different, along with a, though I would think you would need a separate set of headers for the hop for each a in transition... So: Should we require d= to be the same? Should we specify it only once? If not, why not? Brandon --f40304355418f3198d054eba8376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When thinking about how to extract information from an arc= chain, I was wondering at the "owner" of a section of the chain.=

Theoretically, that's the ADMD.=C2=A0 A single hop,= however, has three separate domain ownerships, the srv_id from the AAR, an= d the d=3D field from the AS and AMS.

Our current = implementation uses google.com for the d= =3D field, and we have three different srv_id's for different pools tha= t serve different purposes.=C2=A0 That said, the srv_id has no "valida= tion" except for by the key signature, so d=3D seems like a stronger &= quot;owner".

Except, the AMS and AS can have = separate selectors and domains.=C2=A0 I'm not sure if that's useful= or desirable.=C2=A0 I'm tempted to only consider a chain valid if the = domains are the same, and I guess not care if the selectors are.
=
Should we require them to be the same?=C2=A0 If we do, shoul= d they only be specified once?

For changing algori= thms, I guess s would be different, along with a, though I would think you = would need a separate set of headers for the hop for each a in transition..= .

So:
Should we require d=3D to be the s= ame?=C2=A0 Should we specify it only once?=C2=A0 If not, why not?

Brandon
--f40304355418f3198d054eba8376-- From nobody Thu May 4 15:58: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 76480129469 for ; Thu, 4 May 2017 15:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLvIq6vYj2R2 for ; Thu, 4 May 2017 15:58:49 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 CAE3B126C26 for ; Thu, 4 May 2017 15:58:49 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f102so40736655ioi.2 for ; Thu, 04 May 2017 15:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l5njefP3Kw678371BppBKbS23/kmyV6VVcLNtyZ4kJU=; b=kF8eK/pXWtD48CAaBJ4dYogx8p5lVHO2SCp8GShfs0POxJsnw981zx1N/JlRoQ8o+y +hOtL+oeHQoWVaZdiADKSUHlNInXKOCwZUZzzISjandKd8QHv3NXrxpzoyYGyscTKXF3 h5Ol65vV3KvWaceasqN5PG6KS/RPjAeU4JdJXiXxLqmF82XyhMX6/kIy9kouiafvumBx uNVOHYtD0wOpl95ZhISPpfh2hbQ0rGXX6oloJ4ImRYk6ykIwBUGxUChv3HM23sx1s4BF DFViJX2ID5FnrOP9TBZDJe+Iw9AgB4wImH+6NVg42kWWNn5EqRuraJxxozvGvbLrW85a MTfw== 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=l5njefP3Kw678371BppBKbS23/kmyV6VVcLNtyZ4kJU=; b=khngpeJFc8WaGD6MjC5OrzV3mPXHA6FF91otSBhdrI4pmYT1buCiLy2zrBlCrHpVJ7 veJpNgnX4XrrFtaXXNfu2vqRu9HF/3TkaBHGL+VFQwALrqsGOgL9sv9X+t/JCzCO3QoX 7nTlPD4sQ8lKVtBIme479qfTY7GmOll7xDXydPFMqcd1ziBlbVqmfUVH502gjW6C06kx yacfQ4Ye1hp5ObDebOqJjWlw/l3Ylbndp0FcggMn86wwR4P3ofTAdhxK3lxYFxWbFDph /ctGBFysU3rsbgPXx5E3Hjc+H417NBsrxEpxaROBO+h5y3XEuOKKLLTj9X8xjJnJxgpy gwYw== X-Gm-Message-State: AODbwcAe0xnAi5+lLGyHlJuNR/iVMvgEYNEYWXNicB7k+EKA2NSY6Yvd +PIzFTPA6sZYmxE3sP8h833zFQTDmrZ4wHy6Mw== X-Received: by 10.157.26.125 with SMTP id u58mr1605028otu.167.1493938728897; Thu, 04 May 2017 15:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 4 May 2017 15:58:48 -0700 (PDT) From: Brandon Long Date: Thu, 4 May 2017 15:58:48 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1137ae4840e7ab054ebab778 Archived-At: Subject: [dmarc-ietf] reporting arc local_policy to dmarc rua 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, 04 May 2017 22:58:51 -0000 --001a1137ae4840e7ab054ebab778 Content-Type: text/plain; charset=UTF-8 6.4.5 in the current spec specifies the following as how to report the local_policy override from arc: delivered fail fail local_policy arc=pass ams=d1.example d=d1.example,d2.example The comment is obviously completely unspecified, though maybe some inferences can be done... though I'm not sure what it's saying myself. Are we attempting to dictate the comment? Or is that just an example and it could be anything? If anything, then folks who ingest these may need to look at a bunch, or folks may just say arc=pass. Is the more extensive information useful? I came up with random format for use in the comment field for the authres header, ie something like: arc=pass (i=2 spf=pass spfdomain=example.com dkim=pass dkdomain=example.com) (only partially rolled out, most servers are just saying (i=2)) but I'm not sure that's useful directly either. Brandon --001a1137ae4840e7ab054ebab778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
6.4.5 in the current spec specifies the following as how t= o report the local_policy override from arc:

=C2=A0 =C2= =A0<policy_evaluated>
=C2=A0 =C2=A0 =C2=A0<disposition&g= t;delivered</disposition>
=C2=A0 =C2=A0 =C2=A0<dkim>f= ail</dkim>
=C2=A0 =C2=A0 =C2=A0<spf>fail</spf><= /div>
=C2=A0 =C2=A0 =C2=A0<reason>
=C2=A0 =C2=A0 =C2=A0= <type>local_policy</type>
=C2=A0 =C2=A0 =C2=A0 <c= omment>arc=3Dpass ams=3Dd1.example d=3Dd1.example,d2.example</comment= >
=C2=A0 =C2=A0 =C2=A0</reason>
=C2=A0 =C2=A0&= lt;/policy_evaluated>

The comment i= s obviously completely unspecified, though maybe some inferences can be don= e... though I'm not sure what it's saying myself.

Are we attempting to dictate the comment?=C2=A0 Or is that just an = example and it could be anything?

If anything, the= n folks who ingest these may need to look at a bunch, or folks may just say= arc=3Dpass.

Is the more extensive information use= ful?

I came up with random format for use in the c= omment field for the authres header, ie something like:

arc=3Dpass (i=3D2 spf=3Dpass spfdomain=3Dexample.com dkim=3Dpass dkdomain=3Dex= ample.com) (only partially rolled out, most servers are just saying (i= =3D2)) but I'm not sure that's useful directly either.
Brandon
--001a1137ae4840e7ab054ebab778-- From nobody Thu May 4 16:19: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 32CD2129469 for ; Thu, 4 May 2017 16:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 KIH_yccZFf2d for ; Thu, 4 May 2017 16:19:30 -0700 (PDT) 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 488E5126D05 for ; Thu, 4 May 2017 16:19:30 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id q1so23671941qkd.2 for ; Thu, 04 May 2017 16:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFzVvKYNvbNyrzuQm87RZAqDGaNig1oBbIugnFr9jk8=; b=C9wuzf/VtxnMYmdCoCU30G9DVy/LAw2RJ7MIEVwd0tdYncV1OSrirMmMQ0Vb7nVQRA Tz2fTSmy7eq7FRAVzS02cLR6CSi4tQ6aPjxqn3Z4xwVSF3TNCXqaBPWs8Fy6lZVBybXJ 4tdIk8/klg+QW8Jny+avRWRoGJTWLVgEXoAsbOlUJh36PLQw2lX7K038LcifoqVfuI2Z 5TwvdcjIeb5mLp7GjIgBGAkuPEOOTk0kIAC9SuPKzG+UUXNMiu8+jQNPsHsSq9R74nJM +mRaX5LF37jXP2615g0VXMzm2ZYCFOaGkGNmgXoUdEwudUT8gWQzWyqz+ygRGI2oa2wX QLaQ== 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=UFzVvKYNvbNyrzuQm87RZAqDGaNig1oBbIugnFr9jk8=; b=Rj8d3cL+VD3TK6Q8KXSQu/AL5WNlhFy8Aw8U2uJp8y4p/bzoSEyEHkout4Phltva8f 4rtHJ+aL86q7UAc/vompSN5yq7zfpW0ThCeZg50cC1P9zzCOPlAGZHv53PgYbE/xxOvK 2N1Vymx3GN8YpZNBg0RKD1aIIG/LPaYpcqop1bWEHIuU7/l71fEKdHRleW/MmwwQcs8B LCtnBvQr7X3Ymdq2NtSr3w9IXTo2SLEPYSnJMKtsdHeH3sZYxzRsPrNs+DNEmYcTkl6G vyiSN460wYcqtc5i6yHMS4PBH3QNRFehQbt8q29OoN08ahav2B+7jUdn5mbrbEnsWrpy ufrw== X-Gm-Message-State: AN3rC/7CGrxCHOkmcT9Ufb0UEnaebw9a+6dIo7+aqh56Mi5n8pUF1iWr cOAePGVItm78jTIWZ2rnzfSYc4ofKJf6eMY= X-Received: by 10.55.15.143 with SMTP id 15mr9673946qkp.44.1493939969402; Thu, 04 May 2017 16:19:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.179.10 with HTTP; Thu, 4 May 2017 16:19:29 -0700 (PDT) In-Reply-To: References: From: Peter Goldstein Date: Thu, 4 May 2017 16:19:29 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1146cc10314a7d054ebb017b Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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, 04 May 2017 23:19:33 -0000 --001a1146cc10314a7d054ebb017b Content-Type: text/plain; charset=UTF-8 So as a consumer of these reports I'd definitely like to see a structured value with as much information as possible. The ideal would be to get as much information as we'd get if the final receiver had seen the original email directly at i=0. So that would mean: - SPF Result and SPF domain - For each DKIM signature on the i=0 email, the result and the domain. This should show all signatures from the original message, regardless of status - DKIM Selectors - Unfortunately we probably can't get the DKIM signature selectors (because they aren't generally recorded in the Authentication-Results, and so won't be available to downstream hops), but if we can get them, that would be very helpful. The above will aid in classification and tracking down problems with authentication. In addition, we probably want to record the # of hops (i.e. i=2) The proposal above is a good start, but I don't think it handles the multi-DKIM signature case well. Do you have thoughts on how you'd record and propagate information on multiple signatures in the report? Best, Peter On Thu, May 4, 2017 at 3:58 PM, Brandon Long wrote: > 6.4.5 in the current spec specifies the following as how to report the > local_policy override from arc: > > > delivered > fail > fail > > local_policy > arc=pass ams=d1.example d=d1.example,d2.example > > > > The comment is obviously completely unspecified, though maybe some > inferences can be done... though I'm not sure what it's saying myself. > > Are we attempting to dictate the comment? Or is that just an example and > it could be anything? > > If anything, then folks who ingest these may need to look at a bunch, or > folks may just say arc=pass. > > Is the more extensive information useful? > > I came up with random format for use in the comment field for the authres > header, ie something like: > > arc=pass (i=2 spf=pass spfdomain=example.com dkim=pass dkdomain= > example.com) (only partially rolled out, most servers are just saying > (i=2)) but I'm not sure that's useful directly either. > > Brandon > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a1146cc10314a7d054ebb017b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So as a consumer of these reports I'd definitely like = to see a structured value with as much information as possible.

The ideal would be to get as much information as we'd get if th= e final receiver had seen the original email directly at i=3D0.=C2=A0 So th= at would mean:
  • SPF Result and SPF domain
  • For = each DKIM signature on the i=3D0 email, the result and the domain.=C2=A0 Th= is should show all signatures from the original message, regardless of stat= us
  • DKIM Selectors - Unfortunately we probably can't get the= DKIM signature selectors (because they aren't generally recorded in th= e Authentication-Results, and so won't be available to downstream hops)= , but if we can get them, that would be very helpful.
<= div>The above will aid in classification and tracking down problems with au= thentication.

In addition, we probably want to rec= ord the # of hops (i.e. i=3D2)

The proposal = above is a good start, but I don't think it handles the multi-DKIM sign= ature case well.=C2=A0 Do you have thoughts on how you'd record and pro= pagate information on multiple signatures in the report?

Best,

Peter


On Thu, May 4, 2017 at= 3:58 PM, Brandon Long <blong@google.com> wrote:
6.4.5 in the current spec specifies = the following as how to report the local_policy override from arc:

=
=C2=A0 =C2=A0<policy_evaluated>
=C2=A0 =C2=A0 =C2= =A0<disposition>delivered</disposition>
=C2=A0 = =C2=A0 =C2=A0<dkim>fail</dkim>
=C2=A0 =C2=A0 =C2=A0&l= t;spf>fail</spf>
=C2=A0 =C2=A0 =C2=A0<reason>
=C2=A0 =C2=A0 =C2=A0 <type>local_policy</type>
= =C2=A0 =C2=A0 =C2=A0 <comment>arc=3Dpass ams=3Dd1.example d=3Dd1.exam= ple,d2.example</comment>
=C2=A0 =C2=A0 =C2=A0</reas= on>
=C2=A0 =C2=A0</policy_evaluated>

The comment is obviously completely unspecified, though m= aybe some inferences can be done... though I'm not sure what it's s= aying myself.

Are we attempting to dictate the com= ment?=C2=A0 Or is that just an example and it could be anything?
=
If anything, then folks who ingest these may need to look at= a bunch, or folks may just say arc=3Dpass.

Is the= more extensive information useful?

I came up with= random format for use in the comment field for the authres header, ie some= thing like:

arc=3Dpass (i=3D2 spf=3Dpass spfdomain= =3Dexample.com dkim=3D= pass dkdomain=3Dexample.co= m) (only partially rolled out, most servers are just saying (i=3D2)) bu= t I'm not sure that's useful directly either.

Brandon

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




--
=
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &a= mp; Co-Founder

peter@valimail.com

+1.415.793.5783<= /span>
--001a1146cc10314a7d054ebb017b-- From nobody Thu May 4 17:02:04 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 30498129A97 for ; Thu, 4 May 2017 17:02:03 -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_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ShXLTR6B0e2 for ; Thu, 4 May 2017 17:02:02 -0700 (PDT) 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 0300412956B for ; Thu, 4 May 2017 17:02:02 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id z47so19903246uaz.0 for ; Thu, 04 May 2017 17:02:01 -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=36oWMlDBj13tk38ipddaftFywrkHFAEnkQGp2Cj/aD8=; b=YamEPPUYcMKBzl2yU5Oer94wAiAqqCqEuzKarjwc5bn1XFK6ON0mQ7S41TJpG+zuZe X9F7AtEl2PXXRQyrqQw/BpIj0spwlDNRn8NO+wjyK7bUQGxTyw6RfVtP9B2og5+k2+nG cYJ4hwZH55f2y+5PuqCUFgby7ROAL3PDEtGvY= 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=36oWMlDBj13tk38ipddaftFywrkHFAEnkQGp2Cj/aD8=; b=gdfbnPOlJHOtSXo+1uHZjgY4cCiTXrknifLsK7dDXIqh+diUCqneIHNcy7E5+gHfxB Mm6PqP1mD4rZ8a08DZl4ZBsiMTG219XKC/5TEmS8eQpx1EFw/pz4JWlfTQFnIAml6mBQ qBv+hquB98VwSxatOIkAAM9LEGV+nF2KyBtIWDt2MgG3vfVqRyX7ABb5fhc3DIxb2KTD jyWLHixGfNzAJS+Ies5KZ+TpItj3RPwj/FA2u4sng830LDy2R7FpaqecVS9p3jIT/T1t 86aSS6Xmx20pjqfoLU7+lMnxL/Qa/Lv6Kn75kbR0C5mQbnZzxaor96k426c3IzpjY22g 6PDw== X-Gm-Message-State: AN3rC/4qkuUIYw2NKC+RAJmR66CnTurn6lXo0yB//lnj1vBil+gYJ1nJ 4q1V3KhslIpKcZbj/VJ3mzDfu4z3eg== X-Received: by 10.159.52.84 with SMTP id s20mr13202284uab.8.1493942521111; Thu, 04 May 2017 17:02:01 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.80.33 with HTTP; Thu, 4 May 2017 17:02:00 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 4 May 2017 17:02:00 -0700 X-Google-Sender-Auth: iibDMgnmKtCzUHf1A8Ln2v24rek Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f403043ec0cc4935a2054ebb99ce Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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, 05 May 2017 00:02:03 -0000 --f403043ec0cc4935a2054ebb99ce Content-Type: text/plain; charset=UTF-8 On Thu, May 4, 2017 at 3:58 PM, Brandon Long wrote: > > The comment is obviously completely unspecified, though maybe some > inferences can be done... though I'm not sure what it's saying myself. > > Are we attempting to dictate the comment? Or is that just an example and > it could be anything? > In the draft, the comment was simply an example. That's why there is no further explanation of "required content". If we want to specify how local-policy is reported, I think we risk derailing the spec, though I understand the desire for a tightly specified syntax and content. The consumption of it will be for people who process reports. We had asked various folks from current processors and got no particular input earlier. --Kurt --f403043ec0cc4935a2054ebb99ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 4, 2017 at 3:58 PM, Brandon Long <blong@google.com> w= rote:

The comment is obviously completely unspecified, though maybe some infere= nces can be done... though I'm not sure what it's saying myself.

Are we attempting to dictate the comment?=C2=A0 Or i= s that just an example and it could be anything?

In the draft, the comment was simply an example. That'= ;s why there is no further explanation of "required content". If = we want to specify how local-policy is reported, I think we risk derailing = the spec, though I understand the desire for a tightly specified syntax and= content. The consumption of it will be for people who process reports. We = had asked various folks from current processors and got no particular input= earlier.

--Kurt=C2=A0
--f403043ec0cc4935a2054ebb99ce-- From nobody Fri May 5 14:30:41 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 5A3B7128ACA for ; Fri, 5 May 2017 14:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 xgMoA8w1liw1 for ; Fri, 5 May 2017 14:30:37 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 D71131271FD for ; Fri, 5 May 2017 14:30:36 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id k74so16088875qke.1 for ; Fri, 05 May 2017 14:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GHKxUTGR1XpMzg2MjtAyA+PX+JDX04NfSwy7mZCmiAg=; b=Qngu0aKMP43hCLfflMTNcAMeHDfZvGgPL41v3EU9qfeh9xkdLfrD6ZZ904XDC8kjLH 2CsbHD3A4GjL+5ajpSw5s142LaD6y9VC6UP6J8ZKI/0jt5Wgz/YkooU4a9nhGG0O+i+m 67uonHi9oAuGTwGf/syHPXD2o4OhUo2D3bQbSaMGhBUBBLdXK4iyp67eQxiUbp378qv1 TcG/WBuASZ7tLNoRBbJHQRIaflenNIn3A4wY0auHWx3K7yrwrCVmMjkZFDp1zbh8NEbB DVTzzWxex2FwC8/i8ymLg/mlv5efTi7MDZQUYq6qiDVMMLNVAB1Amp9xxIvW5kWvdoR+ O3pw== 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=GHKxUTGR1XpMzg2MjtAyA+PX+JDX04NfSwy7mZCmiAg=; b=KnPQLBzK7p8YSjdv5+fZXOGJnaVZxkUSN15gOrO2O1/5b0A4y8kinqkxWrlW/umlEz Al/TqPXRKzsO00EWZOiOKl82HASgst/OWLI+D/VULsuB8A2DS95Kik3XHXetWarBFyEh zRzfK5rlFf2/jvDcKEcmjIoMOI8CeuyIpg7IRbPMQdKjgsuwWCl/kVrYRaXjKiMGMIiO uGIqefEOHs/b529gUa4rycWrddOG3WUHu/oC9LOr3ivIQWQAtrYJp3mT0FqHTlCddB3O ElWk8svFOD7tWE4AEgrV1/hUaf06lL3fdPIyyYQUQJgBpxYamnwJRXHnDt/lrbsz5Xcw QNRw== X-Gm-Message-State: AODbwcANXcnkGoct0lZsSHFyzeCNdMT7LVWRfnDueVbAVuNlJrU95LRY HlMQn2RmkEDw5yiVC84fuZO7OPQBGw== X-Received: by 10.55.176.135 with SMTP id z129mr14591824qke.308.1494019835918; Fri, 05 May 2017 14:30:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.120 with HTTP; Fri, 5 May 2017 14:30:15 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 5 May 2017 14:30:15 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" , Kurt Andersen , Murray superuser Kucherawy Content-Type: multipart/alternative; boundary=94eb2c0656949b9160054ecd9945 Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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, 05 May 2017 21:30:40 -0000 --94eb2c0656949b9160054ecd9945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brandon, thanks for this email. Your question has solidified two matters for clarification that I have about the end to end functionality of ARC with respect to the AAR header and what that means for information reported back via DMARC. For context, these questions come from the point of view of a domain owner who wants to publish a DMARC policy of p=3Dnone to collect authentication information with the goal of getting to a p=3Dquarantine or p=3Dreject poli= cy, and as a generator of reports who wishes to provide the most valuable information to that domain owner to help with this process. With no intermediaries, the useful pieces of information to identify services that fail authentication are: - The source IP - SPF result and SPF domain - For each DKIM signature on the message, its result, domain, and selector - The policy disposition of the message At the end of an ARC chain, we=E2=80=99re generally left with an i=3D1 AAR = with only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy report which says arc=3Dpass|fail. As a domain owner at p=3Dnone who wants to get to p=3Dreject, this is not sufficient information to uncover authentication failures that are obscured by mailing lists or forwarding that modified the message. A DMARC report which provides the above pieces of original authentication information as part of the ARC reporting, not just the SPF and DKIM pass/fail results, would be valuable in helping get to DMARC enforcement. Forgetting the specifics of what I outlined above, to me there are two important questions here for discussion: 1) What is the appropriate information to return via a DMARC report for messages with an ARC chain to help a domain owner identify unauthenticated sources of email? 2) How can this information be encoded to survive transit and be reported by a final receiver? What do you all think? Seth On Thu, May 4, 2017 at 3:58 PM, Brandon Long wrote: > 6.4.5 in the current spec specifies the following as how to report the > local_policy override from arc: > > > delivered > fail > fail > > local_policy > arc=3Dpass ams=3Dd1.example d=3Dd1.example,d2.example > > > > The comment is obviously completely unspecified, though maybe some > inferences can be done... though I'm not sure what it's saying myself. > > Are we attempting to dictate the comment? Or is that just an example and > it could be anything? > > If anything, then folks who ingest these may need to look at a bunch, or > folks may just say arc=3Dpass. > > Is the more extensive information useful? > > I came up with random format for use in the comment field for the authres > header, ie something like: > > arc=3Dpass (i=3D2 spf=3Dpass spfdomain=3Dexample.com dkim=3Dpass dkdomain= =3D > example.com) (only partially rolled out, most servers are just saying > (i=3D2)) but I'm not sure that's useful directly either. > > Brandon > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --=20 [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c0656949b9160054ecd9945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brandon, thanks for this email.

<= div>Your question has solidified two matters for clarification that I have = about the end to end functionality of ARC with respect to the AAR header an= d what that means for information reported back via DMARC.

For context, these questions come from the point of view of a doma= in owner who wants to publish a DMARC policy of p=3Dnone to collect authent= ication information with the goal of getting to a p=3Dquarantine or p=3Drej= ect policy, and as a generator of reports who wishes to provide the most va= luable information to that domain owner to help with this process.

With no intermediaries, the useful pieces of information t= o identify services that fail authentication are:
- The source IP=
- SPF result and SPF domain
- For each DKIM signature = on the message, its result, domain, and selector
- The policy dis= position of the message

At the end of an ARC chain= , we=E2=80=99re generally left with an i=3D1 AAR with only SPF, DKIM, and D= MARC pass/fail, and potentially a local_policy report which says arc=3Dpass= |fail. As a domain owner at p=3Dnone who wants to get to p=3Dreject, this i= s not sufficient information to uncover authentication failures that are ob= scured by mailing lists or forwarding that modified the message.
=
A DMARC report which provides the above pieces of original a= uthentication information as part of the ARC reporting, not just the SPF an= d DKIM pass/fail results, would be valuable in helping get to DMARC enforce= ment.

Forgetting the specifics of what I outlined = above, to me there are two important questions here for discussion:
1) What is the appropriate information to return via a DMARC report for = messages with an ARC chain to help a domain owner identify unauthenticated = sources of email?
2) How can this information be encoded to survi= ve transit and be reported by a final receiver?

Wh= at do you all think?

Seth

On Thu, May 4, 2017 at 3:58 PM, Bran= don Long <blong@google.com> wrote:
6.4.5 in the current spec specifies the followin= g as how to report the local_policy override from arc:

= =C2=A0 =C2=A0<policy_evaluated>
=C2=A0 =C2=A0 =C2=A0<dis= position>delivered</disposition>
=C2=A0 =C2=A0 =C2= =A0<dkim>fail</dkim>
=C2=A0 =C2=A0 =C2=A0<spf>f= ail</spf>
=C2=A0 =C2=A0 =C2=A0<reason>
=C2= =A0 =C2=A0 =C2=A0 <type>local_policy</type>
=C2=A0 = =C2=A0 =C2=A0 <comment>arc=3Dpass ams=3Dd1.example d=3Dd1.example,d2.= example</comment>
=C2=A0 =C2=A0 =C2=A0</reason><= /div>
=C2=A0 =C2=A0</policy_evaluated>

=
The comment is obviously completely unspecified, though maybe so= me inferences can be done... though I'm not sure what it's saying m= yself.

Are we attempting to dictate the comment?= =C2=A0 Or is that just an example and it could be anything?

<= /div>
If anything, then folks who ingest these may need to look at a bu= nch, or folks may just say arc=3Dpass.

Is the more= extensive information useful?

I came up with rand= om format for use in the comment field for the authres header, ie something= like:

arc=3Dpass (i=3D2 spf=3Dpass spfdomain=3Dexample.com dkim=3Dpass = dkdomain=3Dexample.com= ) (only partially rolled out, most servers are just saying (i=3D2)) but I&#= 39;m not sure that's useful directly either.

Brandon<= /div>

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




--

Bringing Trust to E= mail

Seth Blank | Head of Product for Open Source and Protocols=

= seth@valimail.com
+1-415-894-2724
--94eb2c0656949b9160054ecd9945-- From nobody Fri May 5 18:13: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 5ECF1126D05 for ; Fri, 5 May 2017 18:13:35 -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_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiMqdC0MUIrn for ; Fri, 5 May 2017 18:13:33 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 CFC0F1200CF for ; Fri, 5 May 2017 18:13:32 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id e55so16859008uaa.2 for ; Fri, 05 May 2017 18:13:32 -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=oiL2W0AlpnMEZ7tefw+zCgMzzHhnbFw7MEoVkGtYvuM=; b=LwkcIXhxDAmjHlYvZ+73pVvyuUJ6EcUXmLvrCn2XLWNDLxqZqnVO+UdlAxtkMqA/x9 Lm4LfoOMYVmtsEeQRt1THBU8gqyFUMUD3wT1DHAG72YmgHyXscBlkubfjEU7yZ/A+DC5 GyFSjWeqH5eVz20LJyV++zPUw60GCFxcHUL9o= 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=oiL2W0AlpnMEZ7tefw+zCgMzzHhnbFw7MEoVkGtYvuM=; b=Ofaj5ipBxokho9Q9vNAFO+tB7bjLFCJBnOm/94x/VbeF9Z+kD5GfjyidKvaOdpTIhM v8UWAZ0dTHsP79yrxGm+vxGRDfCRLOZ1eng3T6z/Ue9eB010KeO5y28u8nQBOb/lX+Py 6D/ierpYN30a+j89rsCcKr/jOjRbm1o0VDGwdWMYKYZMmAMt5JzZU3mH+VnWUlszoWgA wSlkGBXJG49u5tGy5D13J1MG2rxu2Toqjvxb9+K3Xqm739MVTjsUhD9SsEgMxzFMV8sA H3xXu89hERGZssuTYfwc9Fe3v5o2jfPr1x40X8FVTOKoVL+VEvb6yyBZPc3QFov+PT6J 0cow== X-Gm-Message-State: AN3rC/5HE3KON/IC/NYGD1Yvi/CUPdmmoO42GEbhSqbS9Ll6LorqdBwz pctrTYlZ7vNhA4TU/pPqw7YkT9BBMw== X-Received: by 10.176.2.178 with SMTP id 47mr18215304uah.36.1494033211861; Fri, 05 May 2017 18:13:31 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.80.33 with HTTP; Fri, 5 May 2017 18:13:31 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Fri, 5 May 2017 18:13:31 -0700 X-Google-Sender-Auth: goX4xvSYcHFhWheYlqbFdEsJGiI Message-ID: To: Seth Blank Cc: Brandon Long , "dmarc@ietf.org" , Murray superuser Kucherawy Content-Type: multipart/alternative; boundary=001a113cd3cae049db054ed0b661 Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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: Sat, 06 May 2017 01:13:35 -0000 --001a113cd3cae049db054ed0b661 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 5, 2017 at 2:30 PM, Seth Blank wrote: > > At the end of an ARC chain, we=E2=80=99re generally left with an i=3D1 AA= R with only > SPF, DKIM, and DMARC pass/fail, and potentially a local_policy report whi= ch > says arc=3Dpass|fail. As a domain owner at p=3Dnone who wants to get to > p=3Dreject, this is not sufficient information to uncover authentication > failures that are obscured by mailing lists or forwarding that modified t= he > message. > I don't quite understand this assertion. At the end of an ARC chain, we have the list of all the members of the chain and (for a domain asserting p=3Dnone) the results of DMARC evaluations at each step. Forgetting the specifics of what I outlined above, to me there are two > important questions here for discussion: > 1) What is the appropriate information to return via a DMARC report for > messages with an ARC chain to help a domain owner identify unauthenticate= d > sources of email? > Why would you be looking to ARC to discover "unauthenticated sources of email"? That's not really ARC's role. If all of the intermediaries are enforcing DMARC and reporting results, it seems like ARC would be somewhat superfluous. > 2) How can this information be encoded to survive transit and be reported > by a final receiver? > I'll defer thoughts on this until we hammer out #1 :-) I would really like to get some thoughts from rua aggregators... --Kurt --001a113cd3cae049db054ed0b661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 5, 2017 at 2:30 PM, Seth Blank <seth@valimail.com> w= rote:

At the end of an ARC chain, we=E2=80=99re generally left with an i=3D1 AA= R with only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy = report which says arc=3Dpass|fail. As a domain owner at p=3Dnone who wants = to get to p=3Dreject, this is not sufficient information to uncover authent= ication failures that are obscured by mailing lists or forwarding that modi= fied the message.

I don't q= uite understand this assertion. At the end of an ARC chain, we have the lis= t of all the members of the chain and (for a domain asserting p=3Dnone) the= results of DMARC evaluations at each step.

Forgetting the specifics of what = I outlined above, to me there are two important questions here for discussi= on:
1) What is the appropriate information to return via a DM= ARC report for messages with an ARC chain to help a domain owner identify u= nauthenticated sources of email?

Why would you be looking to ARC to discover "unauthenticated sources= of email"? That's not really ARC's role. If all of the interm= ediaries are enforcing DMARC and reporting results, it seems like ARC would= be somewhat superfluous.
=C2=A0
2) How can this information be encoded to survive= transit and be reported by a final receiver?
=
I'll defer thoughts on this until we hammer out #1 :-) I= would really like to get some thoughts from rua aggregators...
<= br>
--Kurt=C2=A0
--001a113cd3cae049db054ed0b661-- From nobody Fri May 5 22:28:29 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 7C26312426E for ; Fri, 5 May 2017 22:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 jJKVA8Chk0fw for ; Fri, 5 May 2017 22:28:24 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 71D98120725 for ; Fri, 5 May 2017 22:28:24 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m91so19573276qte.3 for ; Fri, 05 May 2017 22:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zIfNk7h3CSCmFfv+9BiyaJn0jAImuC+/ionjQuee0jo=; b=F5BMsF7JEAntrC6IjxNzzsT/4MugMslbB5hEgd0Ghkgzqljr07EUMIAoixEAPvspCQ GnaJ3SwxTPU7C2ffVA2wQXCBf+Ih0QCj6Y9ONa+b9JQF1OnGtCmJ1arBWsGDviDOWW3X vmp4uzR5EA6DsxiJedZ6zM3aW+GECz4JV22i0UqK2sVt9NWurSgBgDacZAhwwQwRrT7O zx6RBnVZj0XPDkF2zHlcFWqitC8xs+RHkjVsV/wTxG3LbaBurcJdR8+3ecyc1sHi9Ny5 aMamd2q3Lok4VvzPHjaVRw0OlWxofk1B3UBrtoqbx22++pfYo5IrxOwkkWvU+ZCFkWDQ 3ESA== 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=zIfNk7h3CSCmFfv+9BiyaJn0jAImuC+/ionjQuee0jo=; b=BxNCc0sTIDiMLvbuhQalXOZ7FXSd3frCsoWL+ilqdn5eTrRBQnJ7voo524toJoFkl7 FHLvEwGW8lGs8p0/npIH/149qeW+1NxAQBn2PPUbtgscbbq1isBJerj7xBVotDUA5DXZ fsXewGxKuPC0PpowA0v3l9Hr4MiWXN/zp/gd+5E7Fm1qlxX5Yyi4avjpXXcr2Cw8YzA+ UP42SleNtmF2X7OkNFKNPmB/TsrGlms2VDETag70rf/rfkeVWRtI9ZHyoz0I4DoJ2Ics K3Z1y5R5vV9xLhfaQcH/clfN5gzw/Ky/MdyUcq/KlpN70wVP/J3s75Qw6dyPOxZJQaRo tamQ== X-Gm-Message-State: AN3rC/4IvH6KznvRv6vP5Iap+ABMfcyYD4YuyAl5o0besOp6zMMGPNOt PfzSVUUqpLOSS7+aaywNcdmgVr8fPg== X-Received: by 10.200.2.145 with SMTP id p17mr48248416qtg.180.1494048503577; Fri, 05 May 2017 22:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.120 with HTTP; Fri, 5 May 2017 22:28:03 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 5 May 2017 22:28:03 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Brandon Long , "dmarc@ietf.org" , Murray superuser Kucherawy Content-Type: multipart/alternative; boundary=f4030435a9c45573b3054ed44673 Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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: Sat, 06 May 2017 05:28:27 -0000 --f4030435a9c45573b3054ed44673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) wrote: > On Fri, May 5, 2017 at 2:30 PM, Seth Blank wrote: > >> >> At the end of an ARC chain, we=E2=80=99re generally left with an i=3D1 A= AR with >> only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy repo= rt >> which says arc=3Dpass|fail. As a domain owner at p=3Dnone who wants to g= et to >> p=3Dreject, this is not sufficient information to uncover authentication >> failures that are obscured by mailing lists or forwarding that modified = the >> message. >> > > I don't quite understand this assertion. At the end of an ARC chain, we > have the list of all the members of the chain and (for a domain asserting > p=3Dnone) the results of DMARC evaluations at each step. > > Forgetting the specifics of what I outlined above, to me there are two >> important questions here for discussion: >> 1) What is the appropriate information to return via a DMARC report for >> messages with an ARC chain to help a domain owner identify unauthenticat= ed >> sources of email? >> > > Why would you be looking to ARC to discover "unauthenticated sources of > email"? That's not really ARC's role. If all of the intermediaries are > enforcing DMARC and reporting results, it seems like ARC would be somewha= t > superfluous. > I'm specifically talking about what most domain owners go through when first implementing DMARC prior to enforcement, as outlined in https://tools.ietf.org/html/rfc7489#appendix-B.2 With no intermediaries, a DMARC report will give you back the source IP of the originating sender, which is useful for validating or correcting authentication mechanisms under the domain owner's control. If I understand the current spec correctly, with ARC, the DMARC report will have the IP of the last intermediary, but not necessarily of the original sender, which obfuscates the information needed to fix broken authentication. In other words, if a message sent through an ARC chain failed DMARC initially, it still won't be delivered and the information needed to fix this failure will not be in the final DMARC report. To take a trivial example with no intermediaries (example.com at p=3Dnone): - An unsigned email is sent from an example.com server of 192.0.2.50. Ultimately, example.com receives a DMARC aggregate report with a record for 192.0.2.50 that shows spf and dkim fails. Now that IP can be added to the example.com SPF record for future messages to pass DMARC. And the same example but through an ARC signing intermediary (example.com at p=3Dnone): - An unsigned email is sent from an example.com server of 192.0.2.50 through a single hop at example.net with IP 198.51.100.100. Ultimately, example.com receives a DMARC aggregate report with a record for 198.51.100.100 that shows spf and dkim fails and a local policy comment of "arc=3Dpass (i=3D1 spf=3Dfail spfdomain=3Dexample.com dkim=3Dfail dkdomain=3Dexample.com)". Wh= en example.com receives this report, there is insufficient information in the data to go fix the example.com SPF record. My questions are: 1) should ARC help a domain owner at p=3Dnone get visibility into the authentication status of originating senders? 2) if so, what information is worth preserving in addition to spf/dkim/dmarc status for the express purpose of adding to the final receiver's DMARC report? > > >> 2) How can this information be encoded to survive transit and be reporte= d >> by a final receiver? >> > > I'll defer thoughts on this until we hammer out #1 :-) I would really lik= e > to get some thoughts from rua aggregators... > Agreed :-) > > --Kurt > Seth --=20 [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --f4030435a9c45573b3054ed44673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Fri, May 5, 2017 at 2:30 PM, Seth Blank <seth@valimail.com&= gt; wrote:

At the end of an ARC chain, we=E2=80=99re = generally left with an i=3D1 AAR with only SPF, DKIM, and DMARC pass/fail, = and potentially a local_policy report which says arc=3Dpass|fail. As a doma= in owner at p=3Dnone who wants to get to p=3Dreject, this is not sufficient= information to uncover authentication failures that are obscured by mailin= g lists or forwarding that modified the message.

I don't quite understand this assertion. At th= e end of an ARC chain, we have the list of all the members of the chain and= (for a domain asserting p=3Dnone) the results of DMARC evaluations at each= step.=C2=A0

Forgetting the speci= fics of what I outlined above, to me there are two important questions here= for discussion:
1) What is the appropriate information to re= turn via a DMARC report for messages with an ARC chain to help a domain own= er identify unauthenticated sources of email?
=
Why would you be looking to ARC to discover "una= uthenticated sources of email"? That's not really ARC's role. = If all of the intermediaries are enforcing DMARC and reporting results, it = seems like ARC would be somewhat superfluous.


I'm specifically talking abou= t what most domain owners go through when first implementing DMARC prior to= enforcement, as outlined in=C2=A0https://tools.ietf.org/html/rfc7489#appendix-B.2

With no intermediaries, a DMARC report will give you= back the source IP of the originating sender, which is useful for validati= ng or correcting authentication mechanisms under the domain owner's con= trol.

If I understand the current spec correctly, = with ARC, the DMARC report will have the IP of the last intermediary, but n= ot necessarily of the original sender, which obfuscates the information nee= ded to fix broken authentication. In other words, if a message sent through= an ARC chain failed DMARC initially, it still won't be delivered and t= he information needed to fix this failure will not be in the final DMARC re= port.

To take a trivial example with no intermedia= ries (example.com at p=3Dnone):
- An unsigned email is sent from an exampl= e.com server of 192.0.2.50. Ultimately, = example.com receives a DMARC aggregate report with a record for 192.0.2= .50 that shows spf and dkim fails. Now that IP can be added to the example.com SPF record for future messages to p= ass DMARC.

And the same example but through an ARC= signing intermediary (example.com at p= =3Dnone):
- An unsigned email is sent from an example.com server of 192.0.2.50 through a single hop at example.net with IP 198.51.100.100. Ultima= tely, example.com receives a DMARC aggre= gate report with a record for 198.51.100.100 that shows spf and dkim fails = and a local policy comment of "arc=3D= pass=C2=A0(i=3D1 spf=3Dfail spfdomain=3Dexam= ple.com dkim=3Dfail dkdomain=3Dexample.c= om)". When example.com r= eceives this report, there is insufficient information in the data to go fi= x the example.com SPF record.
=
My questions are:
1) should ARC help a domain owne= r at p=3Dnone get visibility into the authentication status of originating = senders?
2) if so, what information is worth preserving in additi= on to spf/dkim/dmarc status for the express purpose of adding to the final = receiver's DMARC report?

=C2=A0
=C2=A0
2= ) How can this information be encoded to survive transit and be reported by= a final receiver?

I'= ;ll defer thoughts on this until we hammer out #1 :-) I would really like t= o get some thoughts from rua aggregators...


Agreed :-)

=C2=A0

--Kurt=C2=A0
=


Seth


--

3D"logo

Seth Blank | Head of Product = for Open Source and Pr= otocols

seth@valimail.com
+1-415-894-2724
--f4030435a9c45573b3054ed44673-- From nobody Sat May 6 09:31: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 72A941275AB for ; Sat, 6 May 2017 09:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 AzOClyLmrDmu for ; Sat, 6 May 2017 09:31:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE16D12871F for ; Sat, 6 May 2017 09:31:50 -0700 (PDT) Received: from [10.235.246.227] (mobile-166-171-58-32.mycingular.net [166.171.58.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6F18EC40298; Sat, 6 May 2017 11:31:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1494088308; bh=vHpNpTv89DDaCjUtJy42vEPbzC2JLda3d3DDzTFpbcc=; h=Date:In-Reply-To:References:Subject:To:From:From; b=dT37gpw/DE81bQuiPVMHee5efsBFYSNuylIHZaLJH136/ktokNEIWNqsIKSvmu7FL /lf2e9Lfm6DDTIOL9/c3yb4IBY8D2/o6ex9NxplGiuo4PT0gRSXkF66+sf+hoNVDE9 JnOXr2h+ipnLVU/ZPHHhbJZ50JOgD4Ca/LmwCEKM= Date: Sat, 06 May 2017 16:31:46 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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: Sat, 06 May 2017 16:31:52 -0000 On May 6, 2017 1:28:03 AM EDT, Seth Blank wrote: >On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) >wrote: > >> On Fri, May 5, 2017 at 2:30 PM, Seth Blank wrote: >> >>> >>> At the end of an ARC chain, we=E2=80=99re generally left with an i=3D1= AAR >with >>> only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy >report >>> which says arc=3Dpass|fail=2E As a domain owner at p=3Dnone who wants = to >get to >>> p=3Dreject, this is not sufficient information to uncover >authentication >>> failures that are obscured by mailing lists or forwarding that >modified the >>> message=2E >>> >> >> I don't quite understand this assertion=2E At the end of an ARC chain, >we >> have the list of all the members of the chain and (for a domain >asserting >> p=3Dnone) the results of DMARC evaluations at each step=2E >> > >> Forgetting the specifics of what I outlined above, to me there are >two >>> important questions here for discussion: >>> 1) What is the appropriate information to return via a DMARC report >for >>> messages with an ARC chain to help a domain owner identify >unauthenticated >>> sources of email? >>> >> >> Why would you be looking to ARC to discover "unauthenticated sources >of >> email"? That's not really ARC's role=2E If all of the intermediaries >are >> enforcing DMARC and reporting results, it seems like ARC would be >somewhat >> superfluous=2E >> > > >I'm specifically talking about what most domain owners go through when >first implementing DMARC prior to enforcement, as outlined in >https://tools=2Eietf=2Eorg/html/rfc7489#appendix-B=2E2 > >With no intermediaries, a DMARC report will give you back the source IP >of >the originating sender, which is useful for validating or correcting >authentication mechanisms under the domain owner's control=2E > >If I understand the current spec correctly, with ARC, the DMARC report >will >have the IP of the last intermediary, but not necessarily of the >original >sender, which obfuscates the information needed to fix broken >authentication=2E In other words, if a message sent through an ARC chain >failed DMARC initially, it still won't be delivered and the information >needed to fix this failure will not be in the final DMARC report=2E > >To take a trivial example with no intermediaries (example=2Ecom at >p=3Dnone): >- An unsigned email is sent from an example=2Ecom server of 192=2E0=2E2= =2E50=2E >Ultimately, example=2Ecom receives a DMARC aggregate report with a record >for >192=2E0=2E2=2E50 that shows spf and dkim fails=2E Now that IP can be adde= d to >the >example=2Ecom SPF record for future messages to pass DMARC=2E > >And the same example but through an ARC signing intermediary >(example=2Ecom >at p=3Dnone): >- An unsigned email is sent from an example=2Ecom server of 192=2E0=2E2= =2E50 >through a single hop at example=2Enet with IP 198=2E51=2E100=2E100=2E Ult= imately, >example=2Ecom receives a DMARC aggregate report with a record for >198=2E51=2E100=2E100 that shows spf and dkim fails and a local policy >comment of "arc=3Dpass (i=3D1 >spf=3Dfail spfdomain=3Dexample=2Ecom dkim=3Dfail dkdomain=3Dexample=2Ecom= )"=2E When >example=2Ecom receives this report, there is insufficient information in >the >data to go fix the example=2Ecom SPF record=2E > >My questions are: >1) should ARC help a domain owner at p=3Dnone get visibility into the >authentication status of originating senders? =2E=2E=2E I think no=2E Ultimately receivers will need to decide if they trust ARC to override a D= MARC failure=2E I don't think this is a technical question of if the ARC s= igner is correctly determining the authentication status of mail, I think i= t is a reputation question=2E ARC is used to upgrade the status of a message=2E Deciding to do that is = all about the ARC signer, not the original authentication mechanism=2E It might not hurt to describe how to structure the comment to provide such= information for those that care (if providing authentication trace details= in the comment, then SHALL do it this way), but no more than that=2E That= could even be done as a separate draft to minimize the requirements creep = in this one=2E Scott K From nobody Mon May 8 18: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 DF04C126DC2 for ; Mon, 8 May 2017 18:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=valimail.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 JrlwdgmWxswY for ; Mon, 8 May 2017 18:38:51 -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 F2448126C83 for ; Mon, 8 May 2017 18:38:45 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u75so67342667qka.3 for ; Mon, 08 May 2017 18:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=87Doi7prQw2SlrG3O2OFhShZqh0Xa3xht6VMIL3CVEc=; b=XDO/r7Ia4iNFSQdfb8Ri6VTBJrdNh0El439ZRhjhqUyYuz+V7+PwN+yVJCdQLCit5K 96A+FyyuodekHba9lUuhOZXK3OuY6WiVgqGP4OrtT2q7UEtLBhcntgRSP82fNtMrL4e2 VEJkGLJs6mCJWdWLtuQ5VUltnjll9tdy2bud4lW4o5Uw5VCPFYi7f9PqwR7hLK2Mgh39 fjB+/l2OG5uuXM3/06yyaO+2z1TNmOHyWDjKiCelgG138rOjGw5it6OGjWgVd8nGJeu8 IOxCfHacBHHd3IH5UvNOcq+AqPGnvoDc/Ks3h4lu6Hc2Q58kKEJNxX9de4iwS7aUPHGh KtAA== 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=87Doi7prQw2SlrG3O2OFhShZqh0Xa3xht6VMIL3CVEc=; b=Cfarl9mLJxLrtLg1rbZuW8UjZKTIlc62KaCmVeAZ6FRO2QS56Y+UsgT/L/FV7q6jwY T1fLbPv4iH5fSlfjEUpSndATGcyZp5xpHWkFt7xI+36G/I2L2PdPDLerQb04cq/O7qFa v0JKbORtaaH32lSIKYGDAgJaNU1WzPAzM9TCA5fpOzHqlWHvO8P3gp6aXM5p6wtUJiHw BFNDixk3PVNxdxmuOjMMyGYusv622WNnBQrZxVgoC4DSakl1xO/uh/QjRuGjZKbOXrrS uB2XF6alYZsWLQsVo0nMYA39Fdi4uwJT2Ik4f3DxUpXWHei7I+Kd61/mMAdPJUjcxhB7 twlg== X-Gm-Message-State: AODbwcA3PCY8sA/ii3led3JwLdmXsWjW51umGaShZv9GoDJU8FSZ3G/Q FwYUusnv75arq//qKGZJuQIz02UNtWGg X-Received: by 10.55.66.78 with SMTP id p75mr25939656qka.192.1494293925087; Mon, 08 May 2017 18:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.120 with HTTP; Mon, 8 May 2017 18:38:24 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Mon, 8 May 2017 18:38:24 -0700 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a11489bb8985832054f0d6a64 Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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: Tue, 09 May 2017 01:38:54 -0000 --001a11489bb8985832054f0d6a64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree 100% with you in the case of a receiver dealing with an ARC signed message from a domain with a policy of quarantine or reject. What I think you're saying is that in the case of a p=3Dnone, it's not necessary for ARC to provide information on originating services, but if a receiver has the information, the spec could provide guidance so long it doesn't introduce new requirements or creep. This makes a lot of sense if written tightly (otherwise I agree we're talking about a separate doc that should be considered separately). I'm happy to suggest something concise unless anyone else has a strong opinion. Seth On Sat, May 6, 2017 at 9:31 AM, Scott Kitterman wrote: > > > On May 6, 2017 1:28:03 AM EDT, Seth Blank wrote: > >On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) > >wrote: > > > >> On Fri, May 5, 2017 at 2:30 PM, Seth Blank wrote: > >> > >>> > >>> At the end of an ARC chain, we=E2=80=99re generally left with an i=3D= 1 AAR > >with > >>> only SPF, DKIM, and DMARC pass/fail, and potentially a local_policy > >report > >>> which says arc=3Dpass|fail. As a domain owner at p=3Dnone who wants t= o > >get to > >>> p=3Dreject, this is not sufficient information to uncover > >authentication > >>> failures that are obscured by mailing lists or forwarding that > >modified the > >>> message. > >>> > >> > >> I don't quite understand this assertion. At the end of an ARC chain, > >we > >> have the list of all the members of the chain and (for a domain > >asserting > >> p=3Dnone) the results of DMARC evaluations at each step. > >> > > > >> Forgetting the specifics of what I outlined above, to me there are > >two > >>> important questions here for discussion: > >>> 1) What is the appropriate information to return via a DMARC report > >for > >>> messages with an ARC chain to help a domain owner identify > >unauthenticated > >>> sources of email? > >>> > >> > >> Why would you be looking to ARC to discover "unauthenticated sources > >of > >> email"? That's not really ARC's role. If all of the intermediaries > >are > >> enforcing DMARC and reporting results, it seems like ARC would be > >somewhat > >> superfluous. > >> > > > > > >I'm specifically talking about what most domain owners go through when > >first implementing DMARC prior to enforcement, as outlined in > >https://tools.ietf.org/html/rfc7489#appendix-B.2 > > > >With no intermediaries, a DMARC report will give you back the source IP > >of > >the originating sender, which is useful for validating or correcting > >authentication mechanisms under the domain owner's control. > > > >If I understand the current spec correctly, with ARC, the DMARC report > >will > >have the IP of the last intermediary, but not necessarily of the > >original > >sender, which obfuscates the information needed to fix broken > >authentication. In other words, if a message sent through an ARC chain > >failed DMARC initially, it still won't be delivered and the information > >needed to fix this failure will not be in the final DMARC report. > > > >To take a trivial example with no intermediaries (example.com at > >p=3Dnone): > >- An unsigned email is sent from an example.com server of 192.0.2.50. > >Ultimately, example.com receives a DMARC aggregate report with a record > >for > >192.0.2.50 that shows spf and dkim fails. Now that IP can be added to > >the > >example.com SPF record for future messages to pass DMARC. > > > >And the same example but through an ARC signing intermediary > >(example.com > >at p=3Dnone): > >- An unsigned email is sent from an example.com server of 192.0.2.50 > >through a single hop at example.net with IP 198.51.100.100. Ultimately, > >example.com receives a DMARC aggregate report with a record for > >198.51.100.100 that shows spf and dkim fails and a local policy > >comment of "arc=3Dpass (i=3D1 > >spf=3Dfail spfdomain=3Dexample.com dkim=3Dfail dkdomain=3Dexample.com)".= When > >example.com receives this report, there is insufficient information in > >the > >data to go fix the example.com SPF record. > > > >My questions are: > >1) should ARC help a domain owner at p=3Dnone get visibility into the > >authentication status of originating senders? > ... > I think no. > > Ultimately receivers will need to decide if they trust ARC to override a > DMARC failure. I don't think this is a technical question of if the ARC > signer is correctly determining the authentication status of mail, I thin= k > it is a reputation question. > > ARC is used to upgrade the status of a message. Deciding to do that is > all about the ARC signer, not the original authentication mechanism. > > It might not hurt to describe how to structure the comment to provide suc= h > information for those that care (if providing authentication trace detail= s > in the comment, then SHALL do it this way), but no more than that. That > could even be done as a separate draft to minimize the requirements creep > in this one. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a11489bb8985832054f0d6a64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree 100% with you in the case of a receiver dealing wi= th an ARC signed message from a domain with a policy of quarantine or rejec= t.

What I think you're saying is that in the case of= a p=3Dnone, it's not necessary for ARC to provide information on origi= nating services, but if a receiver has the information, the spec could prov= ide guidance so long it doesn't introduce new requirements or creep.

This makes a lot of sense if written tightly (otherw= ise I agree we're talking about a separate doc that should be considere= d separately). I'm happy to suggest something concise unless anyone els= e has a strong opinion.

Seth

On Sat, May 6, 2017 at = 9:31 AM, Scott Kitterman <sklist@kitterman.com> wrote:

On May 6, 2017 1:28:03 AM EDT, Seth Blank <seth@valimail.com> wrote:
>On Fri, May 5, 2017 at 6:13 PM, Kurt Andersen (b) <kboth@drkurt.com>
>wrote:
>
>> On Fri, May 5, 2017 at 2:30 PM, Seth Blank <seth@valimail.com> wrote:
>>
>>>
>>> At the end of an ARC chain, we=E2=80=99re generally left with = an i=3D1 AAR
>with
>>> only SPF, DKIM, and DMARC pass/fail, and potentially a local_p= olicy
>report
>>> which says arc=3Dpass|fail. As a domain owner at p=3Dnone who = wants to
>get to
>>> p=3Dreject, this is not sufficient information to uncover
>authentication
>>> failures that are obscured by mailing lists or forwarding that=
>modified the
>>> message.
>>>
>>
>> I don't quite understand this assertion. At the end of an ARC = chain,
>we
>> have the list of all the members of the chain and (for a domain >asserting
>> p=3Dnone) the results of DMARC evaluations at each step.
>>
>
>> Forgetting the specifics of what I outlined above, to me there are=
>two
>>> important questions here for discussion:
>>> 1) What is the appropriate information to return via a DMARC r= eport
>for
>>> messages with an ARC chain to help a domain owner identify
>unauthenticated
>>> sources of email?
>>>
>>
>> Why would you be looking to ARC to discover "unauthenticated = sources
>of
>> email"? That's not really ARC's role. If all of the i= ntermediaries
>are
>> enforcing DMARC and reporting results, it seems like ARC would be<= br> >somewhat
>> superfluous.
>>
>
>
>I'm specifically talking about what most domain owners go through w= hen
>first implementing DMARC prior to enforcement, as outlined in
>https://tools.ietf.org/html/rfc7489#appendi= x-B.2
>
>With no intermediaries, a DMARC report will give you back the source IP=
>of
>the originating sender, which is useful for validating or correcting >authentication mechanisms under the domain owner's control.
>
>If I understand the current spec correctly, with ARC, the DMARC report<= br> >will
>have the IP of the last intermediary, but not necessarily of the
>original
>sender, which obfuscates the information needed to fix broken
>authentication. In other words, if a message sent through an ARC chain<= br> >failed DMARC initially, it still won't be delivered and the informa= tion
>needed to fix this failure will not be in the final DMARC report.
>
>To take a trivial example with no intermediaries (example.com at
>p=3Dnone):
>- An unsigned email is sent from an example.com server of 192.0.2.50.
>Ultimately, example.com receives a DMARC aggregate report with a record >for
>192.0.2.50 that shows spf and dkim fails. Now that IP can be added to >the
>exa= mple.com SPF record for future messages to pass DMARC.
>
>And the same example but through an ARC signing intermediary
>(ex= ample.com
>at p=3Dnone):
>- An unsigned email is sent from an example.com server of 192.0.2.50
>through a single hop at example.net with IP 198.51.100.100. Ultimately, >exa= mple.com receives a DMARC aggregate report with a record for
>198.51.100.100 that shows spf and dkim fails and a local policy
>comment of "arc=3Dpass (i=3D1
>spf=3Dfail spfdomain=3Dexample.com dkim=3Dfail dkdomain=3Dexample.com)".= When
>exa= mple.com receives this report, there is insufficient information in
>the
>data to go fix the example.com SPF record.
>
>My questions are:
>1) should ARC help a domain owner at p=3Dnone get visibility into the >authentication status of originating senders?
...
I think no.

Ultimately receivers will need to decide if they trust ARC to override a DM= ARC failure.=C2=A0 I don't think this is a technical question of if the= ARC signer is correctly determining the authentication status of mail, I t= hink it is a reputation question.

ARC is used to upgrade the status of a message.=C2=A0 Deciding to do that i= s all about the ARC signer, not the original authentication mechanism.

It might not hurt to describe how to structure the comment to provide such = information for those that care (if providing authentication trace details = in the comment, then SHALL do it this way), but no more than that.=C2=A0 Th= at could even be done as a separate draft to minimize the requirements cree= p in this one.

Scott K

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a11489bb8985832054f0d6a64-- From nobody Tue May 9 14:04:59 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 0959A12922E for ; Tue, 9 May 2017 14:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiKJCKFmRdWq for ; Tue, 9 May 2017 14:04:55 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 9A73A129573 for ; Tue, 9 May 2017 14:04:55 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id h4so14866233oib.3 for ; Tue, 09 May 2017 14:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bCBP80vUIG17NKiiAa0bi38pVBTCFNAHf0uUjKYmUMU=; b=r1Xybh307eHOMnsEbjBJ6qQTJRKIoOTDtCxfudsAddAC9MsxhuDW0Pw5flTDyq18do VR3dUf9AWGtW4T3UU8BuU2kmiezigdAu7UdOj0S6n7Kf/T+1Oe81UON6DlVFc8FS3EhC CTpZSUfN4zc1SMICEg/YJG6Y+GeBMRxqYD2bAz7SPFIRDuePKicXbZnee3mnGeJjJrcP sb9zrKCBFOKLDP6UDR048h5LiP9ZzBU5Y8yHD8993ONr8gfMublgZRs7OiiyYNGPvSpD D1V4IldXwVyARJskclcBUCfw6+2FzeJ+a5TemkIH3frbLZO9vSklCRW8+eOaHR6DXHp2 XCtQ== 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=bCBP80vUIG17NKiiAa0bi38pVBTCFNAHf0uUjKYmUMU=; b=Dr/583pYSQYTMcHKjetfQsIsOL7j5armHb+WO9TB+5VJX0oamJlHrVMKvae3XRHYWh UGdlNgCFlK2FxkdhhAWEckhixQllRQJ4UNxOz2vtpeAiddCLWFZl5bzJXAlYKilCTBFu Weq0SSau9OswIOeaZFDqmcxt6GPypk3UIELJz/tU9H2owMpq7QUaqosYL8aFpTFyDVGs 6A6ElXfj4/N7WjRchYSHAAE4Iucoopg11Ol/279TpEAcgmzU2yy78IPvq3kyoL1rZV39 5u5k16I6lvu/1X3GsRZph/WFfoI7eOksKQlsQSb1sSxWmPh8DPbQdZqRnWiIliPLePhc TQAg== X-Gm-Message-State: AODbwcBKQT5P6WKRE2JBoKAmeOxHRUUKrmroC4V2qRgWYv6FeVIETyk3 Xay3PzMjcwDwMggJOQNKYjru/le0aswb X-Received: by 10.157.46.234 with SMTP id w97mr936681ota.78.1494363894719; Tue, 09 May 2017 14:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 9 May 2017 14:04:54 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 9 May 2017 14:04:54 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114639d01c9128054f1db5e6 Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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: Tue, 09 May 2017 21:04:58 -0000 --001a114639d01c9128054f1db5e6 Content-Type: text/plain; charset=UTF-8 In 5.1 defining the AMS, you say that it should cover DKIM-Signature and AuthRes headers. In particular, AuthRes headers are expected to be removed by ADMDs, especially if the message transits the same ADMD multiple times. Also, the information in the AuthRes header is superseded by the ArcAuthRes header. Including it means an arbitrary AMS breakage for something pretty minor, so I would recommend to not include it. Our implementation explicitly blacklists that header. I know some mailing lists also strip the DKIM-Signature header, but since they are likely to break the AMS anyways, that's less important. I'm not sure what the benefit is to including it, but it seems harmless. In particular, if the DKIM-Signature still passes, then the ARC isn't adding that much, and removing the DKIM-Signature header doesn't mean all that much either since it's validity was already assessed and that assessment included in the AAR. We don't blacklist the DKIM-Signature method in our implementation, but I don't understand the advisement. You also talk about "responsibility". I'm not sure that's how I would describe it. An ARC hop is documenting that a message passed through it, and that it evaluated the authentication of the message. The only responsibility of a hop is to correctly validate the SPF/DKIM/ARC information, there is no ownership implied over the message itself. With AMS, you can answer the question: which ADMD is the last ADMD to have modified the message. I guess in that sense, the last modifier is "responsible" for the current state of the message... but that kind of means that the AMS of previous hops allows them to disown responsibility for the current state of the message... 5.2 - should we point out that there should be only one of these per hop? The openspf/dkim/dmarc implementations tend to add separate AuthRes headers for each evaluation, but ARC requires those to be a single instance. 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my understanding of those terms is slightly odd, but I would think that an MSA usually uses an MTA to actually send the message, and it isn't that "sending" MTA that's the first hop, it should be the first "receiving" MTA. I mean, that's usually the point at which the DKIM signature is applied, and the SPF would be "from" there, not based on the location of the MUA. There are some missing pieces here, corresponding to the current draft sections 5.4 (alternate signing algorithms), 6.4.3 (arc email authentication method for AuthRes), 6.4.5 for dmarc xml. I see that the arc is included in your IANA section, not sure if the call out outside of the definition is necessary or not. Overall, I think your draft makes some things clearer, and some things in the original are clearer. It's worth looking into either combining or choosing. Brandon On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy wrote: > Colleagues, > > As I progress (slowly, alas) toward completing my sample implementation of > OpenARC, I've found myself taking a lot of notes about the current draft. > This has helped me make progress; in some cases it became things I posted > to the list, and in others it was just to help or confirm my understanding > of the protocol. > > I have developed this enough to become a fairly comprehensive alternative > text to the current draft. I find the layout of this version to flow > better for my own purposes, and in a few places I've tried to clarify some > of the material by rewriting chunks of it. None of this is meant to assert > that the current draft is deficient; I've just found it to be a helpful > exercise for me. > > I offer it here to the WG as a contribution; the WG of course is free to > use some, all, or none of it as it wishes. > > http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt > > If it would be more helpful to post this as an I-D, please let me know. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114639d01c9128054f1db5e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In 5.1 defining the AMS, you say that it should cover DKIM= -Signature and AuthRes headers.=C2=A0 In particular, AuthRes headers are ex= pected to be removed by ADMDs, especially if the message transits the same = ADMD multiple times.=C2=A0 Also, the information in the AuthRes header is s= uperseded by the ArcAuthRes header.=C2=A0 Including it means an arbitrary A= MS breakage for something pretty minor, so I would recommend to not include= it.

Our implementation explicitly blacklists that heade= r.

I know some mailing lists also strip the DKIM-S= ignature header, but since they are likely to break the AMS anyways, that&#= 39;s less important.=C2=A0 I'm not sure what the benefit is to includin= g it, but it seems harmless.=C2=A0 In particular, if the DKIM-Signature sti= ll passes, then the ARC isn't adding that much, and removing the DKIM-S= ignature header doesn't mean all that much either since it's validi= ty was already assessed and that assessment included in the AAR.=C2=A0 We d= on't blacklist the DKIM-Signature method in our implementation, but I d= on't understand the advisement.

You also talk = about "responsibility".=C2=A0 I'm not sure that's how I w= ould describe it.=C2=A0 An ARC hop is documenting that a message passed thr= ough it, and that it evaluated the authentication of the message.=C2=A0 The= only responsibility of a hop is to correctly validate the SPF/DKIM/ARC inf= ormation, there is no ownership implied over the message itself.
=
With AMS, you can answer the question: which ADMD is the las= t ADMD to have modified the message.=C2=A0 I guess in that sense, the last = modifier is "responsible" for the current state of the message...= but that kind of means that the AMS of previous hops allows them to disown= responsibility for the current state of the message...

5.2 - should we point out that there should be only one of these per = hop?=C2=A0 The openspf/dkim/dmarc implementations tend to add separate Auth= Res headers for each evaluation, but ARC requires those to be a single inst= ance.

5.3.1 - none as defined as "arrives at = an MTA from an MSA", perhaps my understanding of those terms is slight= ly odd, but I would think that an MSA usually uses an MTA to actually send = the message, and it isn't that "sending" MTA that's the f= irst hop, it should be the first "receiving" MTA.=C2=A0 I mean, t= hat's usually the point at which the DKIM signature is applied, and the= SPF would be "from" there, not based on the location of the MUA.=

There are some missing pieces here, corresponding= to the current draft sections 5.4 (alternate signing algorithms), 6.4.3 (a= rc email authentication method for AuthRes), 6.4.5 for dmarc xml.=C2=A0 I s= ee that the arc is included in your IANA section, not sure if the call out = outside of the definition is necessary or not.

Ove= rall, I think your draft makes some things clearer, and some things in the = original are clearer.=C2=A0 It's worth looking into either combining or= choosing.


Brandon

On Thu, May 4, 2017 at= 12:56 AM, Murray S. Kucherawy <superuser@gmail.com> wrote= :
Colleag= ues,

As I progress (slowly, alas) toward completing my sample = implementation of OpenARC, I've found myself taking a lot of notes abou= t the current draft.=C2=A0 This has helped me make progress; in some cases = it became things I posted to the list, and in others it was just to help or= confirm my understanding of the protocol.

I have developed th= is enough to become a fairly comprehensive alternative text to the current = draft.=C2=A0 I find the layout of this version to flow better for my own pu= rposes, and in a few places I've tried to clarify some of the material = by rewriting chunks of it.=C2=A0 None of this is meant to assert that the c= urrent draft is deficient; I've just found it to be a helpful exercise = for me.

I offer it here to the WG as a contribution; the WG of cours= e is free to use some, all, or none of it as it wishes.

http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt

-MSK

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


--001a114639d01c9128054f1db5e6-- From nobody Tue May 9 15:56:06 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 6FAD812EB33 for ; Tue, 9 May 2017 15:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 CmguaJvYDShv for ; Tue, 9 May 2017 15:56:03 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85C2124B0A for ; Tue, 9 May 2017 15:56:02 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l135so7863382ywb.2 for ; Tue, 09 May 2017 15:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9XYFDhV6x1x96wg8VXZABjnrD+hfKeXxQLiIt6G8ILI=; b=CZlsAxkqjOGOp1NEGaRroN8FMZHkpRA/rD8mTsR4g9YkE7aGho1SsIWpBfwXQa4maV Jz7yK+r5Yk+AaYY6Il6zNzVsAcwwW1zMTi2P+MOqjqrLG5kk9UBRBCAKllPzUQQn5iIt 0AG8hWQgdb+RmFqzWr4MqfPU2fOv9W+B3tkcqSeyETTQgWYoO3pZpr11G4VXQ5UqRkia 0/rfgcb+5lBSF1Y4OYIutQdGROKPzYyURocCl7P2hQqtwr+ZwhZiLTVL+C5tB48PT6Nz C6n7E5uEvYxQcZsyeO2tWRPAoiTVoYbAD2aDEVGuHd6kArNOrp4Sb/StLFkDAn+kUpXD GTZQ== 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=9XYFDhV6x1x96wg8VXZABjnrD+hfKeXxQLiIt6G8ILI=; b=rx/GtE2LbqzxA4J96mp+iX3K3mNIUnXz3eLD4ia/X+FuE9KbAaNmAhxM+o3eEaXORh aRKEKX6MBH+A/3v252Clms26czRVFvk6A4IDsMzI1Pp1xln4Gdb3ztVTi7v/vStEP+Mm LUFESieOh+EhTNV3/flo7JrISc9uUFhwVnXeww5hkLAqp8TCmmZFUhYaXTOAi16hE00B Z/E/9VNdgYqwVcRj6lU49BACb+AVpYbjhMzCqO/agmRNL3s/z9FkpdvLtxC02lAKs3Jm RiXYHkw7g9iH1DWzUjQeCJOe/ZkXT4NwgXI6QXcmqQdsbTtnGZr4y6iHaO+oaDu2Hxty 5N/g== X-Gm-Message-State: AODbwcBV8cttCrqWMEmGzo9nH536u0s8mQ4L3SP0h8wf5O7zBlC0+zER mYqhcvqJcmrRSmWevAo7aYtspI2MBg== X-Received: by 10.13.216.209 with SMTP id a200mr2416989ywe.5.1494370562035; Tue, 09 May 2017 15:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.195 with HTTP; Tue, 9 May 2017 15:56:01 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 9 May 2017 15:56:01 -0700 Message-ID: To: Brandon Long Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114e44848383bd054f1f4299 Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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: Tue, 09 May 2017 22:56:05 -0000 --001a114e44848383bd054f1f4299 Content-Type: text/plain; charset=UTF-8 I've taken a look at the proposed draft and have a few notes as well. 4. The currently specified limits on i= are not included MUST >10, SHOULD > 50, etc 5.1 - In the current draft, it's mandated that AMS must use relaxed header canonicalization, but that's missing from the proposed draft 5.2 - I'm a bit confused by the comment noting the importance of i=2. What is it that you're intending there? 5.3.1 - typo: one of three possible values: -> one of *four* possible values 7.2 - It may be worth elaborating more on the possible ways in which cv=invalid can arise, if not here, maybe somewhere else 7.4 - In general I prefer this to the psuedo code in the current draft, but I think it could still use a bit of work. In particular, sections C-H are exactly describing how to validate a DKIM signature and seems somewhat unnecessary. Is there any particular reason you decided to include this, as opposed to just relying on the DKIM spec for this? 7.5 - typo: no -> all In general though, I agree with Brandon, the proposed draft definitely makes some things clearer, which I think is a step in the right direction. =Gene On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > In 5.1 defining the AMS, you say that it should cover DKIM-Signature and > AuthRes headers. In particular, AuthRes headers are expected to be removed > by ADMDs, especially if the message transits the same ADMD multiple times. > Also, the information in the AuthRes header is superseded by the ArcAuthRes > header. Including it means an arbitrary AMS breakage for something pretty > minor, so I would recommend to not include it. > > Our implementation explicitly blacklists that header. > > I know some mailing lists also strip the DKIM-Signature header, but since > they are likely to break the AMS anyways, that's less important. I'm not > sure what the benefit is to including it, but it seems harmless. In > particular, if the DKIM-Signature still passes, then the ARC isn't adding > that much, and removing the DKIM-Signature header doesn't mean all that > much either since it's validity was already assessed and that assessment > included in the AAR. We don't blacklist the DKIM-Signature method in our > implementation, but I don't understand the advisement. > > You also talk about "responsibility". I'm not sure that's how I would > describe it. An ARC hop is documenting that a message passed through it, > and that it evaluated the authentication of the message. The only > responsibility of a hop is to correctly validate the SPF/DKIM/ARC > information, there is no ownership implied over the message itself. > > With AMS, you can answer the question: which ADMD is the last ADMD to have > modified the message. I guess in that sense, the last modifier is > "responsible" for the current state of the message... but that kind of > means that the AMS of previous hops allows them to disown responsibility > for the current state of the message... > > 5.2 - should we point out that there should be only one of these per hop? > The openspf/dkim/dmarc implementations tend to add separate AuthRes headers > for each evaluation, but ARC requires those to be a single instance. > > 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my > understanding of those terms is slightly odd, but I would think that an MSA > usually uses an MTA to actually send the message, and it isn't that > "sending" MTA that's the first hop, it should be the first "receiving" > MTA. I mean, that's usually the point at which the DKIM signature is > applied, and the SPF would be "from" there, not based on the location of > the MUA. > > There are some missing pieces here, corresponding to the current draft > sections 5.4 (alternate signing algorithms), 6.4.3 (arc email > authentication method for AuthRes), 6.4.5 for dmarc xml. I see that the > arc is included in your IANA section, not sure if the call out outside of > the definition is necessary or not. > > Overall, I think your draft makes some things clearer, and some things in > the original are clearer. It's worth looking into either combining or > choosing. > > > Brandon > > On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy > wrote: > >> Colleagues, >> >> As I progress (slowly, alas) toward completing my sample implementation >> of OpenARC, I've found myself taking a lot of notes about the current >> draft. This has helped me make progress; in some cases it became things I >> posted to the list, and in others it was just to help or confirm my >> understanding of the protocol. >> >> I have developed this enough to become a fairly comprehensive alternative >> text to the current draft. I find the layout of this version to flow >> better for my own purposes, and in a few places I've tried to clarify some >> of the material by rewriting chunks of it. None of this is meant to assert >> that the current draft is deficient; I've just found it to be a helpful >> exercise for me. >> >> I offer it here to the WG as a contribution; the WG of course is free to >> use some, all, or none of it as it wishes. >> >> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt >> >> If it would be more helpful to post this as an I-D, please let me know. >> >> -MSK >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114e44848383bd054f1f4299 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've taken a look at the proposed draft and have a few= notes as well.

4.=C2=A0 The currently specified limits = on i=3D are not included MUST >10, SHOULD > 50, etc

5.1 - In the current draft, it's mandated that AMS must use rel= axed header canonicalization, but that's missing from the proposed draf= t

5.2 - I'm a bit confused by the comment = noting the importance of i=3D2.=C2=A0 What is it that you're intending = there?

5.3.1 - typo: =C2=A0one of three possible v= alues: -> one of four possible values

7.= 2 - It may be worth elaborating more on the possible ways in which cv=3Dinv= alid can arise, if not here, maybe somewhere else

= 7.4 - In general I prefer this to the psuedo code in the current draft, but= I think it could still use a bit of work.=C2=A0 In particular, sections C-= H are exactly describing how to validate a DKIM signature and seems somewha= t unnecessary. Is there any particular reason you decided to include this, = as opposed to just relying on the DKIM spec for this?

<= div>7.5 - typo: no -> all

In general though, I = agree with Brandon, the proposed draft definitely makes some things clearer= , which I think is a step in the right direction.

<= div>=3DGene


On Tue, May 9, 2017 at 2:04 PM, Brandon Long <blong@go= ogle.com> wrote:
In 5.1 defining the AMS, you say that it should cover DKIM-Signatu= re and AuthRes headers.=C2=A0 In particular, AuthRes headers are expected t= o be removed by ADMDs, especially if the message transits the same ADMD mul= tiple times.=C2=A0 Also, the information in the AuthRes header is supersede= d by the ArcAuthRes header.=C2=A0 Including it means an arbitrary AMS break= age for something pretty minor, so I would recommend to not include it.
Our implementation explicitly blacklists that header.
=

I know some mailing lists also strip the DKIM-Signature= header, but since they are likely to break the AMS anyways, that's les= s important.=C2=A0 I'm not sure what the benefit is to including it, bu= t it seems harmless.=C2=A0 In particular, if the DKIM-Signature still passe= s, then the ARC isn't adding that much, and removing the DKIM-Signature= header doesn't mean all that much either since it's validity was a= lready assessed and that assessment included in the AAR.=C2=A0 We don't= blacklist the DKIM-Signature method in our implementation, but I don't= understand the advisement.

You also talk about &q= uot;responsibility".=C2=A0 I'm not sure that's how I would des= cribe it.=C2=A0 An ARC hop is documenting that a message passed through it,= and that it evaluated the authentication of the message.=C2=A0 The only re= sponsibility of a hop is to correctly validate the SPF/DKIM/ARC information= , there is no ownership implied over the message itself.

With AMS, you can answer the question: which ADMD is the last ADMD t= o have modified the message.=C2=A0 I guess in that sense, the last modifier= is "responsible" for the current state of the message... but tha= t kind of means that the AMS of previous hops allows them to disown respons= ibility for the current state of the message...

5.= 2 - should we point out that there should be only one of these per hop?=C2= =A0 The openspf/dkim/dmarc implementations tend to add separate AuthRes hea= ders for each evaluation, but ARC requires those to be a single instance.

5.3.1 - none as defined as "arrives at an MTA = from an MSA", perhaps my understanding of those terms is slightly odd,= but I would think that an MSA usually uses an MTA to actually send the mes= sage, and it isn't that "sending" MTA that's the first ho= p, it should be the first "receiving" MTA.=C2=A0 I mean, that'= ;s usually the point at which the DKIM signature is applied, and the SPF wo= uld be "from" there, not based on the location of the MUA.
<= div>
There are some missing pieces here, corresponding to the= current draft sections 5.4 (alternate signing algorithms), 6.4.3 (arc emai= l authentication method for AuthRes), 6.4.5 for dmarc xml.=C2=A0 I see that= the arc is included in your IANA section, not sure if the call out outside= of the definition is necessary or not.

Overall, I= think your draft makes some things clearer, and some things in the origina= l are clearer.=C2=A0 It's worth looking into either combining or choosi= ng.


Brandon

On T= hu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Colleagues,

As = I progress (slowly, alas) toward completing my sample implementation of Ope= nARC, I've found myself taking a lot of notes about the current draft.= =C2=A0 This has helped me make progress; in some cases it became things I p= osted to the list, and in others it was just to help or confirm my understa= nding of the protocol.

I have developed this enough to become = a fairly comprehensive alternative text to the current draft.=C2=A0 I find = the layout of this version to flow better for my own purposes, and in a few= places I've tried to clarify some of the material by rewriting chunks = of it.=C2=A0 None of this is meant to assert that the current draft is defi= cient; I've just found it to be a helpful exercise for me.

I off= er it here to the WG as a contribution; the WG of course is free to use som= e, all, or none of it as it wishes.

http://blackops.o= rg/~msk/draft-kucherawy-dmarc-arc-base.txt

If it= would be more helpful to post this as an I-D, please let me know.

=
-MSK

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



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


--001a114e44848383bd054f1f4299-- From nobody Tue May 9 16:02:05 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 7FA61129562 for ; Tue, 9 May 2017 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 vnxPkRCoGpVS for ; Tue, 9 May 2017 16:02:02 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550481294DB for ; Tue, 9 May 2017 16:02:02 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l135so7912209ywb.2 for ; Tue, 09 May 2017 16:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SRZf9zVTujYeMDJQ+bZ29PoVPF0HJLn23pYElqQsMlk=; b=e57UcmuWW8EuBNRMuQXiFCZSROgMsoVZOF4cfNGWe4Gi/EfmE6Za9WX92e1kizWaPa KTdtTqA93FMJP1obZsjD2Q1Be4x7nRanH1/19AExPJCqA/t3h9Nhu6egTM09u30inDcM vqIxAV0WG6s1Wso2+Q5suIIZ0xufGG7W6vPUPBhY1UwcQfDSoj3OSLvII5VZbs/AQ0vy zp4zG0AJ6N/mytSjSGqqTTBF4YyNdEvqkKIPoTd6eilPlq/4MKiZzCFCwK4Mb3GJpfeM iXmBL7tK1Wkg0eJ6lwe5ibiLcgs/9pBvVYzG2QR5cgABRQpekFzm7/R9NOxbcmqnJAVa gmag== 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=SRZf9zVTujYeMDJQ+bZ29PoVPF0HJLn23pYElqQsMlk=; b=M63TOKJ5j3GvEs3Z02lmLZ+9Z5tVVSiaH9rjWVz2Xm8wgmzf34mY7RbQp8jm0R9rTH 3wKsvJG+S0p9yNjVu+mqBbm2ATAobYyLyxKdIgm+y8M4TjLIpK6F7Vz3snt1SfDENecv zgXqic0ZKGj0sW0t+JseNCy1/797t8tteDdO/GSn61DM6MKnLgJxY59siYfIzt0k3+jg iEN6sZRBNHdbdC52IBj9ROKnCWx7b594zD+GUnowlT09ooJiLmshKSZLHM2p1iZFg0DZ 5/DOhry3D0x+//nICRZBrRqr+s3u+GuzM3Njh4gLazv7+YmgRuVO62YAaP5PGbReZJf8 fjtw== X-Gm-Message-State: AODbwcBy6VFf9dgcag4VF2tjsaw7JEQoRw66MNg3Iba9mu95+b21wcO1 nEWWxslWw1Ueh7Uh3l+0agedUz6B3A== X-Received: by 10.129.92.68 with SMTP id q65mr2278961ywb.235.1494370921552; Tue, 09 May 2017 16:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.195 with HTTP; Tue, 9 May 2017 16:02:01 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 9 May 2017 16:02:01 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a114d6be8f1b3f1054f1f5774 Archived-At: Subject: Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature 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: Tue, 09 May 2017 23:02:04 -0000 --001a114d6be8f1b3f1054f1f5774 Content-Type: text/plain; charset=UTF-8 I definitely can't imagine any sensible case in which the d= tags should be different. I do think the tag should still be specified in both the AS & AMS though. While not strictly necessary technically, it does make the language in the spec & implementation details a bit cleaner. So I would suggest simply adding a line/section in the chain validation section of the draft or somewhere else that says cv=fail(or invalid?) if the d= tags aren't identical. I think this is an entirely reasonable restriction. =Gene On Thu, May 4, 2017 at 3:44 PM, Brandon Long wrote: > When thinking about how to extract information from an arc chain, I was > wondering at the "owner" of a section of the chain. > > Theoretically, that's the ADMD. A single hop, however, has three separate > domain ownerships, the srv_id from the AAR, and the d= field from the AS > and AMS. > > Our current implementation uses google.com for the d= field, and we have > three different srv_id's for different pools that serve different > purposes. That said, the srv_id has no "validation" except for by the key > signature, so d= seems like a stronger "owner". > > Except, the AMS and AS can have separate selectors and domains. I'm not > sure if that's useful or desirable. I'm tempted to only consider a chain > valid if the domains are the same, and I guess not care if the selectors > are. > > Should we require them to be the same? If we do, should they only be > specified once? > > For changing algorithms, I guess s would be different, along with a, > though I would think you would need a separate set of headers for the hop > for each a in transition... > > So: > Should we require d= to be the same? Should we specify it only once? If > not, why not? > > Brandon > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a114d6be8f1b3f1054f1f5774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I definitely can't imagine any sensible case in which = the d=3D tags should be different.=C2=A0 I do think the tag should still be= specified in both the AS & AMS though.=C2=A0 While not strictly necess= ary technically, it does make the language in the spec & implementation= details a bit cleaner.=C2=A0 So I would suggest simply adding a line/secti= on in the chain validation section of the draft or somewhere else that says= cv=3Dfail(or invalid?) if the d=3D tags aren't identical.=C2=A0 I thin= k this is an entirely reasonable restriction. =C2=A0

=3D= Gene

O= n Thu, May 4, 2017 at 3:44 PM, Brandon Long <blong@google.com> wrote:
When thinking= about how to extract information from an arc chain, I was wondering at the= "owner" of a section of the chain.

Theoretica= lly, that's the ADMD.=C2=A0 A single hop, however, has three separate d= omain ownerships, the srv_id from the AAR, and the d=3D field from the AS a= nd AMS.

Our current implementation uses google.com for the d=3D field, an= d we have three different srv_id's for different pools that serve diffe= rent purposes.=C2=A0 That said, the srv_id has no "validation" ex= cept for by the key signature, so d=3D seems like a stronger "owner&qu= ot;.

Except, the AMS and AS can have separate sele= ctors and domains.=C2=A0 I'm not sure if that's useful or desirable= .=C2=A0 I'm tempted to only consider a chain valid if the domains are t= he same, and I guess not care if the selectors are.

Should we require them to be the same?=C2=A0 If we do, should they only b= e specified once?

For changing algorithms, I guess= s would be different, along with a, though I would think you would need a = separate set of headers for the hop for each a in transition...
<= br>
So:
Should we require d=3D to be the same?=C2=A0 Sh= ould we specify it only once?=C2=A0 If not, why not?

Brandon

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


--001a114d6be8f1b3f1054f1f5774-- From nobody Tue May 9 17:40:12 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 6627A129553 for ; Tue, 9 May 2017 17:40:10 -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 (2048-bit key) header.d=valimail.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 Tsh4Wjp6ksxB for ; Tue, 9 May 2017 17:40:07 -0700 (PDT) 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 D99E7124217 for ; Tue, 9 May 2017 17:40:06 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id y201so15747054qka.0 for ; Tue, 09 May 2017 17:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XUj/SFKixI5el8ZjS1zefJsECdNU0Ie667uXxZOxgFM=; b=I3NW92T2dDeu7NAicsjYCeAFLQ9n78vn/cMYY8Gyh1Avp1DuNInnRQoK4dZf9VaVEI RFwxoHX8T5KXAUx/t6W5djmK8rkl9D4G2NS6NKURxj0x+F76xsn4A8TDxWEont21Ni89 nqbgD4bUgC6ZhQ++tWhdUYdTvdLfz6Ff6PhH0JaKS9J3JgnzdMpk+I6k6ii8e8P4aDcW 8/3YyAOsZgzqZATh2bx817Y0msc5hTn42q86RydtV1JsRRKg9P+ly+oIYU0mN8D5SrWQ BCONJqGR/jMSXDljqOGE+SMjDKtYXTSxYleWOxwZYdDNQ9vwR2U1kMPgVKLDn/RGcYGz StAg== 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=XUj/SFKixI5el8ZjS1zefJsECdNU0Ie667uXxZOxgFM=; b=mVrGdUbjrN5KIRXHRfSQ3ZR3yRfDc3DImdIUMQ6mYor7CVOXXz0VbTLDGoh0tlA00K FVmvizH89cuvSXhasCcC63Wb+hTsxXusDxTYEJbUPdDi+NH4yGJZdMN0j9Bajvp2OwIR p5YRuNxgY6V1exPl+nQIUYztbhLU9QHz8P4SwXso8MttCQCv3UoXleIh8qe4Qq2eACtd +p7Nuy8/kw8zZSQgNRxNdtd2yjbv88WzpIRj5IUTjbT+Od14GxbwvRyXDDsKtcm8S3ZU 7c6y2K6WuA383WYdRDtu0TpIBu6HlrDFUw6sF+4y9HGIhgKKiFgvk/gBDbk6h99qOPtm KytQ== X-Gm-Message-State: AODbwcDIWNz/TLMtIYGd6GN4zU/Fro88v8l/PQkKl8gOxOnRkjgRfbjP lQjOTdFWMPH7z/zhcaoGW1UDsj2vTQ== X-Received: by 10.55.134.131 with SMTP id i125mr2893625qkd.17.1494376805931; Tue, 09 May 2017 17:40:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.120 with HTTP; Tue, 9 May 2017 17:39:45 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Tue, 9 May 2017 17:39:45 -0700 Message-ID: To: "dmarc@ietf.org" Cc: Brandon Long , "Murray S. Kucherawy" , Gene Shuman Content-Type: multipart/alternative; boundary=94eb2c07019aadb6e4054f20b6d8 Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 10 May 2017 00:40:10 -0000 --94eb2c07019aadb6e4054f20b6d8 Content-Type: text/plain; charset=UTF-8 I've got two follow ups from Gene's notes on the proposed draft: 1. I am also confused by section 5.2, specifically the penultimate sentence in the section. I think - but am not certain - that I understand what is meant. I've suggested new language below to clarify. Original: "Of particular importance is the recording of the "i=2" instance of this field, which is the first available opportunity in the handling chain of the message to evaluate its apparent validity since departing its originating ADMD." Suggested: "Of particular importance is the first AAR header after an ARC signed message leaves its originating ADMD, which is generally but not always the "i=1" instance of this field. This instance contains the authentication information of first receipt which the ARC chain is establishing custody of to a final receiver." 2. Also, in section 9.5, an IANA Consideration for "temperror" is defined but I think this was supposed to be for "invalid". Seth On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > I've taken a look at the proposed draft and have a few notes as well. > > 4. The currently specified limits on i= are not included MUST >10, SHOULD > > 50, etc > > 5.1 - In the current draft, it's mandated that AMS must use relaxed header > canonicalization, but that's missing from the proposed draft > > 5.2 - I'm a bit confused by the comment noting the importance of i=2. > What is it that you're intending there? > > 5.3.1 - typo: one of three possible values: -> one of *four* possible > values > > 7.2 - It may be worth elaborating more on the possible ways in which > cv=invalid can arise, if not here, maybe somewhere else > > 7.4 - In general I prefer this to the psuedo code in the current draft, > but I think it could still use a bit of work. In particular, sections C-H > are exactly describing how to validate a DKIM signature and seems somewhat > unnecessary. Is there any particular reason you decided to include this, as > opposed to just relying on the DKIM spec for this? > > 7.5 - typo: no -> all > > In general though, I agree with Brandon, the proposed draft definitely > makes some things clearer, which I think is a step in the right direction. > > =Gene > > > On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > >> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and >> AuthRes headers. In particular, AuthRes headers are expected to be removed >> by ADMDs, especially if the message transits the same ADMD multiple times. >> Also, the information in the AuthRes header is superseded by the ArcAuthRes >> header. Including it means an arbitrary AMS breakage for something pretty >> minor, so I would recommend to not include it. >> >> Our implementation explicitly blacklists that header. >> >> I know some mailing lists also strip the DKIM-Signature header, but since >> they are likely to break the AMS anyways, that's less important. I'm not >> sure what the benefit is to including it, but it seems harmless. In >> particular, if the DKIM-Signature still passes, then the ARC isn't adding >> that much, and removing the DKIM-Signature header doesn't mean all that >> much either since it's validity was already assessed and that assessment >> included in the AAR. We don't blacklist the DKIM-Signature method in our >> implementation, but I don't understand the advisement. >> >> You also talk about "responsibility". I'm not sure that's how I would >> describe it. An ARC hop is documenting that a message passed through it, >> and that it evaluated the authentication of the message. The only >> responsibility of a hop is to correctly validate the SPF/DKIM/ARC >> information, there is no ownership implied over the message itself. >> >> With AMS, you can answer the question: which ADMD is the last ADMD to >> have modified the message. I guess in that sense, the last modifier is >> "responsible" for the current state of the message... but that kind of >> means that the AMS of previous hops allows them to disown responsibility >> for the current state of the message... >> >> 5.2 - should we point out that there should be only one of these per >> hop? The openspf/dkim/dmarc implementations tend to add separate AuthRes >> headers for each evaluation, but ARC requires those to be a single instance. >> >> 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my >> understanding of those terms is slightly odd, but I would think that an MSA >> usually uses an MTA to actually send the message, and it isn't that >> "sending" MTA that's the first hop, it should be the first "receiving" >> MTA. I mean, that's usually the point at which the DKIM signature is >> applied, and the SPF would be "from" there, not based on the location of >> the MUA. >> >> There are some missing pieces here, corresponding to the current draft >> sections 5.4 (alternate signing algorithms), 6.4.3 (arc email >> authentication method for AuthRes), 6.4.5 for dmarc xml. I see that the >> arc is included in your IANA section, not sure if the call out outside of >> the definition is necessary or not. >> >> Overall, I think your draft makes some things clearer, and some things in >> the original are clearer. It's worth looking into either combining or >> choosing. >> >> >> Brandon >> >> On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy > > wrote: >> >>> Colleagues, >>> >>> As I progress (slowly, alas) toward completing my sample implementation >>> of OpenARC, I've found myself taking a lot of notes about the current >>> draft. This has helped me make progress; in some cases it became things I >>> posted to the list, and in others it was just to help or confirm my >>> understanding of the protocol. >>> >>> I have developed this enough to become a fairly comprehensive >>> alternative text to the current draft. I find the layout of this version >>> to flow better for my own purposes, and in a few places I've tried to >>> clarify some of the material by rewriting chunks of it. None of this is >>> meant to assert that the current draft is deficient; I've just found it to >>> be a helpful exercise for me. >>> >>> I offer it here to the WG as a contribution; the WG of course is free to >>> use some, all, or none of it as it wishes. >>> >>> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt >>> >>> If it would be more helpful to post this as an I-D, please let me know. >>> >>> -MSK >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c07019aadb6e4054f20b6d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've got two follow ups from Gene's notes on = the proposed draft:

1. I am also confused by section 5.= 2, specifically the penultimate sentence in the section. I think - but am n= ot certain - that I understand what is meant. I've suggested new langua= ge below to clarify.

Original:

"Of particular importance= is the recording of the "i=3D2" instance of this field, which is= the first available opportunity in the handling chain of the message to ev= aluate its apparent validity since departing its originating ADMD."
Suggested:

"Of particular importance is the first AAR head= er after an ARC signed message leaves its originating ADMD, which is genera= lly but not always the "i=3D1" instance of this field. This insta= nce contains the authentication information of first receipt which the ARC = chain is establishing custody of to a final receiver."

2. Also,= in section 9.5, an IANA Consideration for "temperror" is defined= but I think this was supposed to be for "invalid".

Seth
On Tue, May 9, 2017= at 3:56 PM, Gene Shuman <gene@valimail.com> wrote:
I've taken a look at the pro= posed draft and have a few notes as well.

4.=C2=A0 The c= urrently specified limits on i=3D are not included MUST >10, SHOULD >= 50, etc

5.1 - In the current draft, it's mand= ated that AMS must use relaxed header canonicalization, but that's miss= ing from the proposed draft

5.2 - I'm a bi= t confused by the comment noting the importance of i=3D2.=C2=A0 What is it = that you're intending there?

5.3.1 - typo: =C2= =A0one of three possible values: -> one of four possible values

7.2 - It may be worth elaborating more on the possi= ble ways in which cv=3Dinvalid can arise, if not here, maybe somewhere else=

7.4 - In general I prefer this to the psuedo code= in the current draft, but I think it could still use a bit of work.=C2=A0 = In particular, sections C-H are exactly describing how to validate a DKIM s= ignature and seems somewhat unnecessary. Is there any particular reason you= decided to include this, as opposed to just relying on the DKIM spec for t= his?

7.5 - typo: no -> all

=
In general though, I agree with Brandon, the proposed draft definitely= makes some things clearer, which I think is a step in the right direction.=

=3DGene

=

On= Tue, May 9, 2017 at 2:04 PM, Brandon Long <blong@google.com>= wrote:
In 5.1 defining = the AMS, you say that it should cover DKIM-Signature and AuthRes headers.= =C2=A0 In particular, AuthRes headers are expected to be removed by ADMDs, = especially if the message transits the same ADMD multiple times.=C2=A0 Also= , the information in the AuthRes header is superseded by the ArcAuthRes hea= der.=C2=A0 Including it means an arbitrary AMS breakage for something prett= y minor, so I would recommend to not include it.

Our imp= lementation explicitly blacklists that header.

I k= now some mailing lists also strip the DKIM-Signature header, but since they= are likely to break the AMS anyways, that's less important.=C2=A0 I= 9;m not sure what the benefit is to including it, but it seems harmless.=C2= =A0 In particular, if the DKIM-Signature still passes, then the ARC isn'= ;t adding that much, and removing the DKIM-Signature header doesn't mea= n all that much either since it's validity was already assessed and tha= t assessment included in the AAR.=C2=A0 We don't blacklist the DKIM-Sig= nature method in our implementation, but I don't understand the advisem= ent.

You also talk about "responsibility"= ;.=C2=A0 I'm not sure that's how I would describe it.=C2=A0 An ARC = hop is documenting that a message passed through it, and that it evaluated = the authentication of the message.=C2=A0 The only responsibility of a hop i= s to correctly validate the SPF/DKIM/ARC information, there is no ownership= implied over the message itself.

With AMS, you ca= n answer the question: which ADMD is the last ADMD to have modified the mes= sage.=C2=A0 I guess in that sense, the last modifier is "responsible&q= uot; for the current state of the message... but that kind of means that th= e AMS of previous hops allows them to disown responsibility for the current= state of the message...

5.2 - should we point out= that there should be only one of these per hop?=C2=A0 The openspf/dkim/dma= rc implementations tend to add separate AuthRes headers for each evaluation= , but ARC requires those to be a single instance.

= 5.3.1 - none as defined as "arrives at an MTA from an MSA", perha= ps my understanding of those terms is slightly odd, but I would think that = an MSA usually uses an MTA to actually send the message, and it isn't t= hat "sending" MTA that's the first hop, it should be the firs= t "receiving" MTA.=C2=A0 I mean, that's usually the point at = which the DKIM signature is applied, and the SPF would be "from" = there, not based on the location of the MUA.

There= are some missing pieces here, corresponding to the current draft sections = 5.4 (alternate signing algorithms), 6.4.3 (arc email authentication method = for AuthRes), 6.4.5 for dmarc xml.=C2=A0 I see that the arc is included in = your IANA section, not sure if the call out outside of the definition is ne= cessary or not.

Overall, I think your draft makes = some things clearer, and some things in the original are clearer.=C2=A0 It&= #39;s worth looking into either combining or choosing.

=

Brandon

On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy <supe= ruser@gmail.com> wrote:
Colleagues,

As I progress (sl= owly, alas) toward completing my sample implementation of OpenARC, I've= found myself taking a lot of notes about the current draft.=C2=A0 This has= helped me make progress; in some cases it became things I posted to the li= st, and in others it was just to help or confirm my understanding of the pr= otocol.

I have developed this enough to become a fairly compre= hensive alternative text to the current draft.=C2=A0 I find the layout of t= his version to flow better for my own purposes, and in a few places I'v= e tried to clarify some of the material by rewriting chunks of it.=C2=A0 No= ne of this is meant to assert that the current draft is deficient; I've= just found it to be a helpful exercise for me.

I offer it here to t= he WG as a contribution; the WG of course is free to use some, all, or none= of it as it wishes.

http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt

If it would be more = helpful to post this as an I-D, please let me know.

-MSK

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



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



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




--

3D"log=

Bringing Trust t= o Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valimail.com
+1-415-894-2724
--94eb2c07019aadb6e4054f20b6d8-- From nobody Wed May 10 00:34:20 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 E9B5E129789 for ; Wed, 10 May 2017 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cWZoNIXxgGq for ; Wed, 10 May 2017 00:34:16 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 BAC3E1242EA for ; Wed, 10 May 2017 00:34:16 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id l18so26467338oig.2 for ; Wed, 10 May 2017 00:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mxwx4Sa3Ytd/hkAT0IPV8v6VKWCvV94xesZJaD9YHK8=; b=h4z85kDGMFLzj6z5p+BcKxA16fDgr67GVVziwKZFP70cb2BqK9qzTIhyLWDCxehjKX aPhEaUD/vFPb5H95Q2/pQkNwbX+qHdd1/Z7Nw7MvYB7owDc+6Ur+QSFeIl6tJ9JmgOBo OXmuOibBHEM7MuoidVZ9t1aBnx9qS24zqm6cUJ7MSOAfXlQ1ggkGsbYAeBg9jqluKXSF DgCy9o5766lyzEWgt9X5TPg+Hme34DZFJtYmLlfUYBDk927HxQcHBPwIgXsN8fK/CWu/ 6PjYhn3cxADJC1ddUC2pwDzxnIhkNHFLTmka6UuzWmXrBKBOmpeCZErDvbFckbEZltHw 2q4Q== 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=Mxwx4Sa3Ytd/hkAT0IPV8v6VKWCvV94xesZJaD9YHK8=; b=ZZ7J7GAra41lqpWePQImPGA8ZyXrTmnjl8YlAGj28EH4daoYDTn8Jdc3tw04XXXn1G N0WzCe2nuVz0GQOvYLu6Gdcn8mTBvlPgJEUXD9+zLPWKfJ27ZRbkv2gjvIvAjY3Wi0TO Zdle0q0G5jADxQ7WYURxwYAyRzxRqbwVPsD9AlF/EaaIINA3dcIoa3g6ccw+gt/LbKQJ /1qaPlLGrTH0oSk4LjQJ8i4rCl+XKyhDwad0PYGyv9NrPZ9552dNewVuDkubRgM+j+QY XoeBsHPjrzWJsP+MwKB39HkgLrcvwhJreeG4i1l0LNODsFJiqbZzTBYqXF34ybq927mb UMeg== X-Gm-Message-State: AODbwcCi7G/mySahdgIcu42hjSFpHoYuJDZotO5f0I19Nr8Mdaakxz0o Kg6zsJrWUTPcq8JSrnOAkSyQKY6LWdikDCzhhg== X-Received: by 10.202.170.12 with SMTP id t12mr1898912oie.44.1494401655891; Wed, 10 May 2017 00:34:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 10 May 2017 00:34:15 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 10 May 2017 00:34:15 -0700 Message-ID: To: Gene Shuman Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113cdef4da72a5054f267fb7 Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 10 May 2017 07:34:19 -0000 --001a113cdef4da72a5054f267fb7 Content-Type: text/plain; charset=UTF-8 On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > I've taken a look at the proposed draft and have a few notes as well. > > 4. The currently specified limits on i= are not included MUST >10, SHOULD > > 50, etc > > 5.1 - In the current draft, it's mandated that AMS must use relaxed header > canonicalization, but that's missing from the proposed draft > I think that 5.1.2 in the current draft is wrong, it's overridden by 5.1.2.1.2. We started out only allowing relaxed, but then added back support for c= in a later draft. Brandon 5.2 - I'm a bit confused by the comment noting the importance of i=2. What > is it that you're intending there? > > 5.3.1 - typo: one of three possible values: -> one of *four* possible > values > > 7.2 - It may be worth elaborating more on the possible ways in which > cv=invalid can arise, if not here, maybe somewhere else > > 7.4 - In general I prefer this to the psuedo code in the current draft, > but I think it could still use a bit of work. In particular, sections C-H > are exactly describing how to validate a DKIM signature and seems somewhat > unnecessary. Is there any particular reason you decided to include this, as > opposed to just relying on the DKIM spec for this? > > 7.5 - typo: no -> all > > In general though, I agree with Brandon, the proposed draft definitely > makes some things clearer, which I think is a step in the right direction. > > =Gene > > > On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > >> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and >> AuthRes headers. In particular, AuthRes headers are expected to be removed >> by ADMDs, especially if the message transits the same ADMD multiple times. >> Also, the information in the AuthRes header is superseded by the ArcAuthRes >> header. Including it means an arbitrary AMS breakage for something pretty >> minor, so I would recommend to not include it. >> >> Our implementation explicitly blacklists that header. >> >> I know some mailing lists also strip the DKIM-Signature header, but since >> they are likely to break the AMS anyways, that's less important. I'm not >> sure what the benefit is to including it, but it seems harmless. In >> particular, if the DKIM-Signature still passes, then the ARC isn't adding >> that much, and removing the DKIM-Signature header doesn't mean all that >> much either since it's validity was already assessed and that assessment >> included in the AAR. We don't blacklist the DKIM-Signature method in our >> implementation, but I don't understand the advisement. >> >> You also talk about "responsibility". I'm not sure that's how I would >> describe it. An ARC hop is documenting that a message passed through it, >> and that it evaluated the authentication of the message. The only >> responsibility of a hop is to correctly validate the SPF/DKIM/ARC >> information, there is no ownership implied over the message itself. >> >> With AMS, you can answer the question: which ADMD is the last ADMD to >> have modified the message. I guess in that sense, the last modifier is >> "responsible" for the current state of the message... but that kind of >> means that the AMS of previous hops allows them to disown responsibility >> for the current state of the message... >> >> 5.2 - should we point out that there should be only one of these per >> hop? The openspf/dkim/dmarc implementations tend to add separate AuthRes >> headers for each evaluation, but ARC requires those to be a single instance. >> >> 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my >> understanding of those terms is slightly odd, but I would think that an MSA >> usually uses an MTA to actually send the message, and it isn't that >> "sending" MTA that's the first hop, it should be the first "receiving" >> MTA. I mean, that's usually the point at which the DKIM signature is >> applied, and the SPF would be "from" there, not based on the location of >> the MUA. >> >> There are some missing pieces here, corresponding to the current draft >> sections 5.4 (alternate signing algorithms), 6.4.3 (arc email >> authentication method for AuthRes), 6.4.5 for dmarc xml. I see that the >> arc is included in your IANA section, not sure if the call out outside of >> the definition is necessary or not. >> >> Overall, I think your draft makes some things clearer, and some things in >> the original are clearer. It's worth looking into either combining or >> choosing. >> >> >> Brandon >> >> On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy > > wrote: >> >>> Colleagues, >>> >>> As I progress (slowly, alas) toward completing my sample implementation >>> of OpenARC, I've found myself taking a lot of notes about the current >>> draft. This has helped me make progress; in some cases it became things I >>> posted to the list, and in others it was just to help or confirm my >>> understanding of the protocol. >>> >>> I have developed this enough to become a fairly comprehensive >>> alternative text to the current draft. I find the layout of this version >>> to flow better for my own purposes, and in a few places I've tried to >>> clarify some of the material by rewriting chunks of it. None of this is >>> meant to assert that the current draft is deficient; I've just found it to >>> be a helpful exercise for me. >>> >>> I offer it here to the WG as a contribution; the WG of course is free to >>> use some, all, or none of it as it wishes. >>> >>> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt >>> >>> If it would be more helpful to post this as an I-D, please let me know. >>> >>> -MSK >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > --001a113cdef4da72a5054f267fb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 3:56 PM, Gene Shuman <gene@valimail.com>= wrote:
I've taken a look at the proposed draft and have a few notes = as well.

4.=C2=A0 The currently specified limits on i=3D= are not included MUST >10, SHOULD > 50, etc

5.1 - In the current draft, it's mandated that AMS must use relaxed he= ader canonicalization, but that's missing from the proposed draft

I think that 5.1.2 in the curren= t draft is wrong, it's overridden by=C2=A05.1.2.1.2. We started out only allowing relaxed, = but then added back support for c=3D in a later draft.

Brandon

5.2 -= I'm a bit confused by the comment noting the importance of i=3D2.=C2= =A0 What is it that you're intending there?

5.= 3.1 - typo: =C2=A0one of three possible values: -> one of four po= ssible values

7.2 - It may be worth elaborating mo= re on the possible ways in which cv=3Dinvalid can arise, if not here, maybe= somewhere else

7.4 - In general I prefer this to = the psuedo code in the current draft, but I think it could still use a bit = of work.=C2=A0 In particular, sections C-H are exactly describing how to va= lidate a DKIM signature and seems somewhat unnecessary. Is there any partic= ular reason you decided to include this, as opposed to just relying on the = DKIM spec for this?

7.5 - typo: no -> all
=

In general though, I agree with Brandon, the proposed d= raft definitely makes some things clearer, which I think is a step in the r= ight direction.
=
=3DGene


On Tue, May 9, 2017 at 2:04 PM, Brandon Long <blon= g@google.com> wrote:
In 5.1 defining the AMS, you say that it shou= ld cover DKIM-Signature and AuthRes headers.=C2=A0 In particular, AuthRes h= eaders are expected to be removed by ADMDs, especially if the message trans= its the same ADMD multiple times.=C2=A0 Also, the information in the AuthRe= s header is superseded by the ArcAuthRes header.=C2=A0 Including it means a= n arbitrary AMS breakage for something pretty minor, so I would recommend t= o not include it.

Our implementation explicitly blacklis= ts that header.

I know some mailing lists also str= ip the DKIM-Signature header, but since they are likely to break the AMS an= yways, that's less important.=C2=A0 I'm not sure what the benefit i= s to including it, but it seems harmless.=C2=A0 In particular, if the DKIM-= Signature still passes, then the ARC isn't adding that much, and removi= ng the DKIM-Signature header doesn't mean all that much either since it= 's validity was already assessed and that assessment included in the AA= R.=C2=A0 We don't blacklist the DKIM-Signature method in our implementa= tion, but I don't understand the advisement.

Y= ou also talk about "responsibility".=C2=A0 I'm not sure that&= #39;s how I would describe it.=C2=A0 An ARC hop is documenting that a messa= ge passed through it, and that it evaluated the authentication of the messa= ge.=C2=A0 The only responsibility of a hop is to correctly validate the SPF= /DKIM/ARC information, there is no ownership implied over the message itsel= f.

With AMS, you can answer the question: which AD= MD is the last ADMD to have modified the message.=C2=A0 I guess in that sen= se, the last modifier is "responsible" for the current state of t= he message... but that kind of means that the AMS of previous hops allows t= hem to disown responsibility for the current state of the message...
<= div>
5.2 - should we point out that there should be only one = of these per hop?=C2=A0 The openspf/dkim/dmarc implementations tend to add = separate AuthRes headers for each evaluation, but ARC requires those to be = a single instance.

5.3.1 - none as defined as &quo= t;arrives at an MTA from an MSA", perhaps my understanding of those te= rms is slightly odd, but I would think that an MSA usually uses an MTA to a= ctually send the message, and it isn't that "sending" MTA tha= t's the first hop, it should be the first "receiving" MTA.=C2= =A0 I mean, that's usually the point at which the DKIM signature is app= lied, and the SPF would be "from" there, not based on the locatio= n of the MUA.

There are some missing pieces here, = corresponding to the current draft sections 5.4 (alternate signing algorith= ms), 6.4.3 (arc email authentication method for AuthRes), 6.4.5 for dmarc x= ml.=C2=A0 I see that the arc is included in your IANA section, not sure if = the call out outside of the definition is necessary or not.

<= /div>
Overall, I think your draft makes some things clearer, and some t= hings in the original are clearer.=C2=A0 It's worth looking into either= combining or choosing.


Brandon

On Thu, May 4, 2017 at 12:56 AM, = Murray S. Kucherawy <superuser@gmail.com> wrote:
=
Colleagues,=

As I progress (slowly, alas) toward completing my sample impl= ementation of OpenARC, I've found myself taking a lot of notes about th= e current draft.=C2=A0 This has helped me make progress; in some cases it b= ecame things I posted to the list, and in others it was just to help or con= firm my understanding of the protocol.

I have developed this e= nough to become a fairly comprehensive alternative text to the current draf= t.=C2=A0 I find the layout of this version to flow better for my own purpos= es, and in a few places I've tried to clarify some of the material by r= ewriting chunks of it.=C2=A0 None of this is meant to assert that the curre= nt draft is deficient; I've just found it to be a helpful exercise for = me.

I offer it here to the WG as a contribution; the WG of course is= free to use some, all, or none of it as it wishes.

h= ttp://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt

=
If it would be more helpful to post this as an I-D, please let m= e know.

-MSK

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



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



--001a113cdef4da72a5054f267fb7-- From nobody Wed May 10 00:50: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 85A4B120227 for ; Wed, 10 May 2017 00:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9AaKjUgxu3o for ; Wed, 10 May 2017 00:50:31 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B36129AE0 for ; Wed, 10 May 2017 00:50:29 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w10so26904140oif.0 for ; Wed, 10 May 2017 00:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=MAvNAQrIbnyqwZ3/OJLqm+iiHwgAqvdOLBDym3wx5wg=; b=P7KiVnS7WyoZYmXBvSZYI9IRauRG4EetWZaRPqsQPKqdrjY06m3qb2I1v7zpFfkQNa /Z/wbMRbL2wRhSvYWI7SUtPOZWusw0uAumZyiWSSf80/M9RozUormGcIOg82T7xJIaSS 3xgIXeuY/be/MfxoguuecDisrKJiJkYq7OmvU3r7tZ+J7ep9My3m6g/ScIejOk8YGEx5 wTqOTlvYYePVIcwFo2ZZXygnfvotI6Z6YyDxUkkt8cxjsCQnF+ltu4vhezfcKKZzrBcl UifItYgjt45uJtgR8QzVZfeAz1iBV4qKxNPzmVQw4C9uzoMNQ4FmK6a0a9+vj3gF5gr+ QvKg== 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:cc; bh=MAvNAQrIbnyqwZ3/OJLqm+iiHwgAqvdOLBDym3wx5wg=; b=YwrxnPGiYMG6bWAMnsZMjkGlOgNnFIZRH+8yUyVyrhEfp2w2oI1Z/dx8KGmXl7+XxD akz792ytiQU5WPQqfLAaY4t/FaAfOp69hVxOM6bqt+JEayAUXJcN1OuI9OAi0MHR3cPi 6f2qNqEre5eShscpPocnhyiPLP9fz4JtiVBMIbJNz/3dUszkeEuJlnzL/wDiJ+dFTiBM frk0oeJA5aawstwUWtVzlA/JRvMbxOEtZlFpqQBLX8KWY4Wk/uXKlS9p3+LaM2QtNT6d kLwKHZFnz+x5hYWG5fZ2dtQpGhiPAYB+xVexMAxGYDozL1x5R/GiIe0+wCn3iXIncEnN 6f3A== X-Gm-Message-State: AODbwcC6XuOcg3xuLW3CKotUReyCQo3lekfimarwNqBUawKGXoKqhgqR znj1pCVIMhhh6tZ5nl8YI5VBo2jSNLUW X-Received: by 10.202.178.193 with SMTP id b184mr1716203oif.51.1494402628471; Wed, 10 May 2017 00:50:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 10 May 2017 00:50:28 -0700 (PDT) From: Brandon Long Date: Wed, 10 May 2017 00:50:28 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Gene Shuman Content-Type: multipart/alternative; boundary=001a113b80c8d2d712054f26b990 Archived-At: Subject: [dmarc-ietf] Extracting AAR information 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, 10 May 2017 07:50:33 -0000 --001a113b80c8d2d712054f26b990 Content-Type: text/plain; charset=UTF-8 On Tue, May 9, 2017 at 5:39 PM, Seth Blank wrote: > I've got two follow ups from Gene's notes on the proposed draft: > > 1. I am also confused by section 5.2, specifically the penultimate > sentence in the section. I think - but am not certain - that I understand > what is meant. I've suggested new language below to clarify. > > Original: > > "Of particular importance is the recording of the "i=2" instance of this > field, which is the first available opportunity in the handling chain of > the message to evaluate its apparent validity since departing its > originating ADMD." > > Suggested: > > "Of particular importance is the first AAR header after an ARC signed > message leaves its originating ADMD, which is generally but not always the > "i=1" instance of this field. This instance contains the authentication > information of first receipt which the ARC chain is establishing custody of > to a final receiver." > This and other comments I've heard seems to put an undue benefit on the first receiver. I'm not sure that's warranted. Ie, if you're hoping through a group that right now rewrites the From header, the auth information in the first hop isn't the useful data for validating DMARC. Message from a REJECT domain -> mailing list which rewrites From and is a different REJECT domain -> anti-phishing vendor which rewrites all urls to bounce through them In this case, the final recipient doing a DMARC check would see the From of the mailing list and would need the i=2 (or maybe i=3, depending on whether the mailing list service adds one or two headers) AAR to validate that the auth for the mailing list domain. (in reality, the anti-phishing vendor should be an inbound gateway and dmarc shouldn't be evaluated, but it could be a hop through a second mailing list. An example recently had the anti-phishing get forwarded from the edu domain to a user's personal gmail, so more hops) The logic I'm looking at is more complicated. If you assume a whitelist model, where you are willing to use any information provided by a whitelisted domain, then you basically walk the hops backwards, taking any DKIM auth info given as long as the hop is whitelisted. SPF is a bit different, because you don't want a message "acquiring" SPF auth when it's relayed (I spoof a mail from a non-reject GSuite domain through any service hosted at Google and it'll acquire that domain's SPF auth, for example). So, as you walk backwards, you want an SPF fail/neutral to override a pass. (Theoretically, you could use ARC to override the current SPF evaluation as well. This also assume you wouldn't ARC sign during an initial MSA or RELAY hop, only when it hits a new ADMD). And if you reach a hop where the AMS doesn't verify any more, you have to stop evaluating at the next unwhitelisted hop, since the message could have been completely modified by an unwhitelisted hop and a replayed chain used. Now, most mail we'll see will be a single hop through a mailing list, and so any rewriting will be handled by the new dkim signature or spf, and any non-rewrites will be from the i=1 AAR. If that's all we cared about, that would just be the original XOAR spec as implemented by Google, it only ever handled one hop. Brandon --001a113b80c8d2d712054f26b990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 5:39 PM, Seth Blank <seth@valimail.com><= /span> wrote:
I'= ;ve got two follow ups from Gene's notes on the proposed draft:

1. I am also confused by section 5.2, specifically the penulti= mate sentence in the section. I think - but am not certain - that I underst= and what is meant. I've suggested new language below to clarify.
Original:

"Of particular importance is the recording of the &q= uot;i=3D2" instance of this field, which is the first available opport= unity in the handling chain of the message to evaluate its apparent validit= y since departing its originating ADMD."

Suggested:

&quo= t;Of particular importance is the first AAR header after an ARC signed mess= age leaves its originating ADMD, which is generally but not always the &quo= t;i=3D1" instance of this field. This instance contains the authentica= tion information of first receipt which the ARC chain is establishing custo= dy of to a final receiver."

= This and other comments I've heard seems to put an undue benefit on the= first receiver.=C2=A0 I'm not sure that's warranted.
Ie, if you're hoping through a group that right now rewrite= s the From header, the auth information in the first hop isn't the usef= ul data for validating DMARC.

Message from a REJEC= T domain -> mailing list which rewrites From and is a different REJECT d= omain -> anti-phishing vendor which rewrites all urls to bounce through = them

In this case, the final recipient doing a DMA= RC check would see the From of the mailing list and would need the i=3D2 (o= r maybe i=3D3, depending on whether the mailing list service adds one or tw= o headers) AAR to validate that the auth for the mailing list domain.
=

(in reality, the anti-phishing vendor should be an inbo= und gateway and dmarc shouldn't be evaluated, but it could be a hop thr= ough a second mailing list.=C2=A0 An example recently had the anti-phishing= get forwarded from the edu domain to a user's personal gmail, so more = hops)

The logic I'm looking at is more complic= ated.=C2=A0 If you assume a whitelist model, where you are willing to use a= ny information provided by a whitelisted domain, then you basically walk th= e hops backwards, taking any DKIM auth info given as long as the hop is whi= telisted.

SPF is a bit different, because you don't want a messa= ge "acquiring" SPF auth when it's relayed (I spoof a mail fro= m a non-reject GSuite domain through any service hosted at Google and it= 9;ll acquire that domain's SPF auth, for example). So, as you walk back= wards, you want an SPF fail/neutral to override a pass. (Theoretically, you= could use ARC to override the current SPF evaluation as well.=C2=A0 This a= lso assume you wouldn't ARC sign during an initial MSA or RELAY hop, on= ly when it hits a new ADMD).

And if you reach a hop where the AMS do= esn't verify any more, you have to stop evaluating at the next unwhitel= isted hop, since the message could have been completely modified by an unwh= itelisted hop and a replayed chain used.

Now, most= mail we'll see will be a single hop through a mailing list, and so any= rewriting will be handled by the new dkim signature or spf, and any non-re= writes will be from the i=3D1 AAR.=C2=A0 If that's all we cared about, = that would just be the original XOAR spec as implemented by Google, it only= ever handled one hop.

Brandon
--001a113b80c8d2d712054f26b990-- From nobody Thu May 11 16:12: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 600E7129C55 for ; Thu, 11 May 2017 16:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osFIEwy85pmd for ; Thu, 11 May 2017 16:12:51 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 50A7912F5DB for ; Thu, 11 May 2017 16:08:05 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id h4so47938697oib.3 for ; Thu, 11 May 2017 16:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZAvPEd5MUL7xii78Pf4hw/ikQ7cOGZBQtlL9bTgzMA4=; b=Pt2nMbHn20QEAh+YkN5HKcrOGt2h//DhxIMknase/aWJmC4z0KmC3sg1VdTHA6Y6TX THWXp5aNbED9I6NfCGIul5Ms2oiliyD7vFe6xotn6RArk4pz+XzZuZC+K5eF5WqKfmhK Cs0Cu9Cx5XZ+SMmfNYWkaezUV/pW1B+yI9eyTvU/XauZQvXsl8hjaUL/zyy6/TtcdY+X HdOxbNvTQP28KYyFOppJA7uurj0lGD7d/MHVhp7nndcj1hTq7070Tyly4fidFlTROaCV PquDqYBjmHn8vU3yFhHbfCXfojgDA5KXWi9VpLpuO+597Z9qY/7OTII4tYD+WjPmreO2 bvoQ== 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=ZAvPEd5MUL7xii78Pf4hw/ikQ7cOGZBQtlL9bTgzMA4=; b=CHzjeTS+I6HJHLst0Z33bnRFwmOnB51OeZ/4IMJ6H6NV+EWEqw8I8G/GZmJhQETbgD nHw2cWuIpfiLpQ3nwn2t1pYbYo3miKIBMiko/eXXppOu3CMqW/3vxWEGiiH/i1V05JUh vNrRqNrCla3rpWO/FCKnWBIbCkxFgram0/Ja+ckaz+egsWoEUs8Q+d2s+BlLPxFmW1cZ UKVE2S/s9rcsA7oxhpK5unMz0fKolFKeuX/SdWcwNUN2kGTN1/Vjy3rvwsG3UaWwuh5h XjdYBlOPdwNIXlSq0XYhZgrY3gMo6zEJZZ1hPGxiHXYTgDxWiyuTeBVxkmWO+LdgGXcz gHKg== X-Gm-Message-State: AODbwcDSV6v+9AP0qLd4uFwNkteN272iNKPU1L1bTSAFex6762mUtlfL 8SvF/bhO1Y0SuYH2RKa9OAR4aJB2dJKnJ4E= X-Received: by 10.157.40.238 with SMTP id s101mr598806ota.88.1494544084115; Thu, 11 May 2017 16:08:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Thu, 11 May 2017 16:08:03 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Thu, 11 May 2017 16:08:03 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113edb943c99a4054f47a9e3" Archived-At: Subject: Re: [dmarc-ietf] implementation update 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, 11 May 2017 23:12:53 -0000 --001a113edb943c99a4054f47a9e3 Content-Type: text/plain; charset="UTF-8" As an update, as of Monday our ARC signing has gone to 100% and now that's it's been live for 4 days, seems unlikely to be rolled back at this point. As someone else asked off list, yes, we're signing all incoming mail, and resigning any mail that goes back outbound and has been modified by a system where we expect modifications (Google Groups, GSuite mail policies, Gmail forwarding). Yes, with more effort, we could probably not sign everything on inbound, but given the number of ways our mail system can be used, it's easier to use the signing as a point of trust than some alternatives, what's an order of magnitude or so of extra signatures? Everything appears on our end to be working as expected. We're still a couple weeks away from using this information in dmarc evaluation. Brandon On Fri, Apr 28, 2017 at 11:26 AM, Brandon Long wrote: > Gmail/Google has deployed our implementation of ARC to our mail system. > > At this point, we aren't creating new ARC chains, yet, but any message > with an existing arc chain will be validated and signed. > > Let us know if you see any issues. > > We expect to start creating our own chains in the next couple weeks, > baring issues. > > Brandon > --001a113edb943c99a4054f47a9e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an update, as of Monday our ARC signing has gone to 100= % and now that's it's been live for 4 days, seems unlikely to be ro= lled back at this point.

As someone else asked off list,= yes, we're signing all incoming mail, and resigning any mail that goes= back outbound and has been modified by a system where we expect modificati= ons (Google Groups, GSuite mail policies, Gmail forwarding).=C2=A0 Yes, wit= h more effort, we could probably not sign everything on inbound, but given = the number of ways our mail system can be used, it's easier to use the = signing as a point of trust than some alternatives, what's an order of = magnitude or so of extra signatures?

Everything ap= pears on our end to be working as expected.

We'= ;re still a couple weeks away from using this information in dmarc evaluati= on.

Brandon
=
On Fri, Apr 28, 2017 at 11:26 AM, Brandon Lo= ng <blong@google.com> wrote:
Gmail/Google has deployed our implementation of ARC to o= ur mail system.

At this point, we aren't creating ne= w ARC chains, yet, but any message with an existing arc chain will be valid= ated and signed.

Let us know if you see any issues= .

We expect to start creating our own chains in the next coup= le weeks, baring issues.

Brandon

--001a113edb943c99a4054f47a9e3-- From nobody Tue May 23 08:27:18 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 D30941293EC for ; Tue, 23 May 2017 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=vKO1QnBO; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=GaDDcHvv 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 MzrGWOm5e_I3 for ; Tue, 23 May 2017 08:27:15 -0700 (PDT) Received: from catinthebox.net (mail.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 49E30129B6C for ; Tue, 23 May 2017 08:27:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1116; t=1495553226; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=d1eGmEA+/5YKm0hy4oTTrCWH+vc=; b=vKO1QnBOE+EhPfPDA2IeXjnNJUxW3dJ3f1xnGcMflJcizrXSeS8BfC+fWSnu2b 8hYyrjUTEC/ypPYKu85i/WyNglfO3SKfoTJO0MOX1MV8GpdYnXduqwyJiPiKI5La FNtF9pAe8K5jSSqVqwJl/0xvcosyFSCx44tXT6WsWokh0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Tue, 23 May 2017 11:27:06 -0400 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.5) with ESMTP id 4207101533.1.3920; Tue, 23 May 2017 11:27:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1116; t=1495553083; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DMm9fvb dxs5jEj6UIjVwhSa0kDVpLgoj00fTY783hkA=; b=GaDDcHvvLvK2VnE92ETzVRE otnIzzmFu9VYpt7/Y9jHrSqVncH70XoeOk08nv6stRKxf6YtHXC0qFnA4wVP2DYj V66CJihAFnHgaFv3Zvmgpp+OcLX7NtMpf3iIFmJEti0JT47nplyKvgKOVqUHsVhL sIMVAO/qsOUtnkWu2Bos= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Tue, 23 May 2017 11:24:43 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 454718439.9.427556; Tue, 23 May 2017 11:24:39 -0400 Message-ID: <592454C6.9020203@isdg.net> Date: Tue, 23 May 2017 11:27:02 -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: Brandon Long , "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] implementation update 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: Tue, 23 May 2017 15:27:17 -0000 On 5/11/2017 7:08 PM, Brandon Long wrote: > > We're still a couple weeks away from using this information in dmarc > evaluation. If my understanding is correct of the ARC work done, and thanks to Murray for his draft rewrite ("better" flow, mail tech read), ARC will allow an "indirect" message, i.e. list message, to survive the original author domain signature, provided the final receiver reads the ARC headers with a 3rd party ARC seal? If so, are we still missing a *deterministic* author domain 3rd party signature authorization procedure/protocol that links DMARC with ARC? When I last left this work, I called that a "Registration" scheme, process, I thought was inherently missing in all the DKIM "policy" proposed solutions. Before I begin to look at implementing ARC for our mail server, I am still hopeful for a "registration" DKIM/POLICY protocol. This is could be as simple as an extended DMARC "arc" tag, hopefully as an optional signal to augment something like ATPS (Authorized Third Party Signature). Maybe a ATPAS (Authorized Third Party Arc Seal)? Thanks -- HLS From nobody Tue May 23 08:51:44 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 B6274129B94 for ; Tue, 23 May 2017 08:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zr9EY3Ep00V for ; Tue, 23 May 2017 08:51:42 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E893129B81 for ; Tue, 23 May 2017 08:51:42 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id h4so206738116oib.3 for ; Tue, 23 May 2017 08:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOm9IrvwCpN6gIfWaS7qZri+I2V61bG9Zu3iNNs5tKk=; b=L4/eNSQhvvb6dJHvU9KEDkvJDH0geb5hhXE2KHz9m1hRCciOyPjjrMScKTLw/QBg+R AWHTRrlBDK6KIuwnMZh4cQWdLfojta0HGsSYSnpBGq4Mj7utY6SE4tr2d2F1HQAqqeAv BaCyxBPPSj0yCCsD3jeQXVZ6eAu4G58MucLAZfIxNu646iyYuw2f+qSUVNBz3VMWIT5t sFNBqkLg+iiKHTYY7NBi3/iSm4TSHmSAKx73xze59SyJPbU6wyWaxCc6HIXtiSmAdLXR k9AMUz74Js6Hf39aYL+oyKbJiPSGc4KV0hStQAdfoHBUjtTmz03J/nGX52OLgaTnZ3Q1 a20A== 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=jOm9IrvwCpN6gIfWaS7qZri+I2V61bG9Zu3iNNs5tKk=; b=VsiTtlRtaPBbbLQ+xABSNhfz2bErsUaMvRrM9Y7u5M89sAx+DlUOJoz7PyaOl1NdN9 ah1uPdyx3toj8RtVDbn0c4HFihS/o+1RwJVMQva1WZpFoJDQYbPgT7KWbM4AFnAAuMPW ZSBnio+1oeAGICVtQuRn/m9FKqkFr7U8uYgnXsSwlpgJiBHwHzcyA5BN4J1oRDXXqWt3 o4L+eclvl4xF4GIYgFgeS14AG2Fy8bJClvLhqTIiYxBTMfO9ZkdIaguCYu76raMPPu5k yQmsWjpTm9gylnSh9VpGtHaTc6uKDYtXhVUvkFjANi90dGMJegNzC+fKAOQh98uKo/nX eZ3Q== X-Gm-Message-State: AODbwcChoXwRPODyQkGU7v/cOqSN1H1W2ZnVhdBabHv8AU15Br8CHXZd ZTDucgV4LvPfGZzdC69DUm807zT13cB3sGs= X-Received: by 10.202.102.229 with SMTP id m98mr13150043oik.177.1495554701063; Tue, 23 May 2017 08:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 23 May 2017 08:51:40 -0700 (PDT) Received: by 10.182.8.34 with HTTP; Tue, 23 May 2017 08:51:40 -0700 (PDT) In-Reply-To: <592454C6.9020203@isdg.net> References: <592454C6.9020203@isdg.net> From: Brandon Long Date: Tue, 23 May 2017 08:51:40 -0700 Message-ID: To: Hector Santos Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1140b04ab35a92055032f67a" Archived-At: Subject: Re: [dmarc-ietf] implementation update 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: Tue, 23 May 2017 15:51:44 -0000 --001a1140b04ab35a92055032f67a Content-Type: text/plain; charset="UTF-8" Why should the sender be involved in determining which forwarding is allowed? The arc chain specifies each of the hops, and the receiving domain is in the best position to know about the intermediaries. I can imagine a whitelist style rbl allowing folks to know which intermediaries to trust, but I don't get having to have each sender know all intermediaries ahead of time. Brandon On May 23, 2017 8:27 AM, "Hector Santos" wrote: > On 5/11/2017 7:08 PM, Brandon Long wrote: > >> >> We're still a couple weeks away from using this information in dmarc >> evaluation. >> > > If my understanding is correct of the ARC work done, and thanks to Murray > for his draft rewrite ("better" flow, mail tech read), ARC will allow an > "indirect" message, i.e. list message, to survive the original author > domain signature, provided the final receiver reads the ARC headers with a > 3rd party ARC seal? > > If so, are we still missing a *deterministic* author domain 3rd party > signature authorization procedure/protocol that links DMARC with ARC? > > When I last left this work, I called that a "Registration" scheme, > process, I thought was inherently missing in all the DKIM "policy" proposed > solutions. > > Before I begin to look at implementing ARC for our mail server, I am > still hopeful for a "registration" DKIM/POLICY protocol. This is could be > as simple as an extended DMARC "arc" tag, hopefully as an optional signal > to augment something like ATPS (Authorized Third Party Signature). Maybe a > ATPAS (Authorized Third Party Arc Seal)? > > Thanks > > -- > HLS > > > --001a1140b04ab35a92055032f67a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why should the sender be involved in determining which fo= rwarding is allowed?

The arc c= hain specifies each of the hops, and the receiving domain is in the best po= sition to know about the intermediaries.

<= div dir=3D"auto">I can imagine a whitelist style rbl allowing folks to know= which intermediaries to trust, but I don't get having to have each sen= der know all intermediaries ahead of time.

Brandon

On May 23, 2017 8:27 AM, "Hector Santos" <= ;hsantos@isdg.net> wrote:
On 5/11/2017 7:08 PM, Bran= don Long wrote:

We're still a couple weeks away from using this information in dmarc evaluation.

If my understanding is correct of the ARC work done, and thanks to Murray f= or his draft rewrite ("better" flow, mail tech read),=C2=A0 ARC w= ill allow an "indirect" message, i.e. list message, to survive th= e original author domain signature, provided the final receiver reads the A= RC headers with a 3rd party ARC seal?

If so, are we still missing a *deterministic* author domain 3rd party signa= ture authorization procedure/protocol that links DMARC with ARC?

When I last left this work, I called that a "Registration" scheme= , process, I thought was inherently missing in all the DKIM "policy&qu= ot; proposed solutions.

Before I begin to look at implementing ARC for our mail server,=C2=A0 I am = still hopeful for a "registration" DKIM/POLICY protocol.=C2=A0 = =C2=A0This is could be as simple as an extended DMARC "arc" tag, = hopefully as an optional signal to augment something like ATPS (Authorized = Third Party Signature). Maybe a ATPAS (Authorized Third Party Arc Seal)?
Thanks

--
HLS


--001a1140b04ab35a92055032f67a-- From nobody Wed May 24 11:29: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 0B76212945A for ; Wed, 24 May 2017 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 (2048-bit key) header.d=valimail.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 2fMXnXSbKuAd for ; Wed, 24 May 2017 11:29:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7B2124281 for ; Wed, 24 May 2017 11:29:36 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id u75so160378750qka.3 for ; Wed, 24 May 2017 11:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=lmY5NKhycXtUBtXScVD8uheAEGtQCNrxnl+E+l1XHSk=; b=BvBeaCJ8J64YpbmzXwbycXoZv/ttT6pAL20TW6OgII1//rD4BmMakdtlOnA71n95GZ CSMhsv1S4zAXpDy5kjBOVMUTibmSPTP2fspun6qZtUWcMqZN5x+2lsOrgsf+2S970FDC kQkjwrlrbF4F4b7Ax5ny0fIlUR46JOKBkk91r13UgTAbp9LO0J4rokRGqHTrCF96q8cs kwUlOg4IFIMiPVVTE6i4fdCDGB6Ei2kER4eqj9NTlTbLnmDNB7rPzIk6pXDuy2McRPWT 37wT4w5cP8u2o8Td9dpA9EWeXPciszHg9SLNS7m7fn2/QAqOR1dSuHt0e05JoA/fbDxs tL+A== 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=lmY5NKhycXtUBtXScVD8uheAEGtQCNrxnl+E+l1XHSk=; b=FSQkW3zxck4i0fsi2Yh61IHKY7kKnI9Lf8oqpDsb+9tPVAWl3R/Pw/hJ6CErrSiwg9 ajVdTg7jeWDlreBehCbChAUL0gtivDNpwq24odVP7a/9XM6J9o9clkord1fh1ve8BRfk KB6fsnSGyQLpaDllYLTb/b+GnWny9mznymS0ym7eVXT9Qyhi5Hcc1lfhSFPTqUgc8Tl/ UBAAxRZoJvNeayGMw5zLybw1efKmpCtR0bgbzu2Z0B1C75SObmSBih4j4nxu1ClJuvJy c2q1Ufi4NmODS58+yg7bIeD6EIeqvBr3rMSObZ8PthbPQkwhmAb8djhviIDfjaVm8pb/ iF/w== X-Gm-Message-State: AODbwcBRgOgHf9wCdsylLaI6+HYHo4LxgmQ+h1eKy6NfqCdoe+FpAyPR 7Fq0EE00n9ARevaZ6kucj5AOAoDP3dRxvBmmrQ== X-Received: by 10.55.204.16 with SMTP id r16mr34459608qki.169.1495650575471; Wed, 24 May 2017 11:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 11:29:15 -0700 (PDT) From: Seth Blank Date: Wed, 24 May 2017 11:29:15 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1149ad64426d260550494951" Archived-At: Subject: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 24 May 2017 18:29:39 -0000 --001a1149ad64426d260550494951 Content-Type: text/plain; charset="UTF-8" Under both the current spec ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.3) and the proposed spec ( http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt section 5.2), an ARC Set [i] can have only a single AAR header. It is clear how to construct an AAR when there are 0 or 1 Authentication-Result headers from the current ADMD. Per spec it is ambiguous how to construct the AAR when there are multiple AR headers. Looking at random messages on this list, I've seen anywhere from two to five AR headers per message. Locally, with opendkim and opendmarc running, there are three locally generated AR headers that get passed to openarc. It looks like seeing multiple AR headers is going to be a common occurrence for ARC implementations to handle. When there are multiple headers, the current openarc implementation just uses the first AR header it sees and ignores the rest. Dkimpy leaves it to the user to pass in the appropriate AR header as a parameter. If the goal of the AAR is to provide a copy of ADMD authentication results so that the originating dmarc disposition of a message can be determined and trace information can be provided to the final receiver, then it seems like: 1) there needs to be a discussion on how to handle multiple AR headers 2) this guidance is needed in spec Is this a problem the group thinks needs discussion? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1149ad64426d260550494951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Under both the current spec (https://tools.iet= f.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.3) and the prop= osed spec (http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt sec= tion 5.2), an ARC Set [i] can have only a single AAR header.

=
It is clear how to construct an AAR when there are 0 or 1 Authenticati= on-Result headers from the current ADMD.

Per spec = it is ambiguous how to construct the AAR when there are multiple AR headers= .

Looking at random messages on this list, I'v= e seen anywhere from two to five AR headers per message. Locally, with open= dkim and opendmarc running, there are three locally generated AR headers th= at get passed to openarc. It looks like seeing multiple AR headers is going= to be a common occurrence for ARC implementations to handle.
When there are multiple headers, the current openarc implementa= tion just uses the first AR header it sees and ignores the rest. Dkimpy lea= ves it to the user to pass in the appropriate AR header as a parameter.

If the goal of the AAR is to provide a copy of ADMD a= uthentication results so that the originating dmarc disposition of a messag= e can be determined and trace information can be provided to the final rece= iver, then it seems like:
1) there needs to be a discussion on ho= w to handle multiple AR headers
2) this guidance is needed in spe= c

Is this a problem the group thinks needs di= scussion?

--

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@val= imail.com
+1-415-894-2724
--001a1149ad64426d260550494951-- From nobody Wed May 24 11:30:50 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 7C7B512949E for ; Wed, 24 May 2017 11:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, 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=valimail.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 RA6Z1IsFLIyH for ; Wed, 24 May 2017 11:30:47 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 788E3124281 for ; Wed, 24 May 2017 11:30:47 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id c13so162869579qtc.1 for ; Wed, 24 May 2017 11:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=tHqb3i3vq4HuyW0FNHPDJ7F92wtM5P8wxY5PlQt4IyM=; b=cVVYQOUo7O37I7u0O3Kth6ljL31ji2nkzzsU91M2RkUqlSSf2swN++58VCeePh7CCD toj9G/b6gIeTvIWRhizPd3hTR25c0nfwNQIbaiHW6aDCt0lJn6cAAg0W+l0wNzAyrYtA 6TIyGx3LKJhO5rzqfHbER07iWnjN2Nm5MhLs7HGsfXZk4FCOPtSPNqdHqAI6i56rmYTN UCXwd/jF+IyEdkr+iL6lP46mkrX5JDtkCz2YWm+vVJ0m+0nyRIHD2vZAxgBuNpgurYnX Em9aFMnKy8tRpT2iCMRqX9skvwH+QfIsmwaAzw8pl/RGUnuniIXHK/Kz/8EmyafS//Qp wwxA== 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=tHqb3i3vq4HuyW0FNHPDJ7F92wtM5P8wxY5PlQt4IyM=; b=NWUKI8L5e1bWEMT9KqQ1qIOmCEwACgNMnXg6+HHqjEIHLC20ZLJ3ucUIkif0rCtw4g 4D8d9FNAm0ksiLqJDTbY34LFS0lNajCwlBmEN6GwGAI9VpO3zec4VYYmfyBhb0l+rKvt ngJ4YC+1YKbqYuWYrdmQ2ZuCaaLJZhSemEkTrj0ZRUAHtjCSUVVHZCgdGdDIEeIO8dr+ 4KxrZGapKCDmCsTEKzQO2ogzKFeUxaseL7TK2I1FMZmbvMepgJmRZuxR23j7HbVi1kNb nBXhvYkA/FYV+0Ubk+XELyOxRr8tWvIMR2ersJ54q5nxLkMtFP16yAYn9n5ScMc10OxJ TZ0A== X-Gm-Message-State: AODbwcDOXdg4mDi4bYIt/uDwE1uAFzvpi3lbyOgz/ah/h3XL8/ZaYK17 pQKGHUzbmQn6pUHwIl052gZJ++9I0QqaziI= X-Received: by 10.200.34.98 with SMTP id p31mr37150648qtp.2.1495650646309; Wed, 24 May 2017 11:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 11:30:25 -0700 (PDT) From: Seth Blank Date: Wed, 24 May 2017 11:30:25 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11403b7a7b6d190550494dd4" Archived-At: Subject: [dmarc-ietf] Does the concept of an ARC tempfail make any sense? 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, 24 May 2017 18:30:49 -0000 --001a11403b7a7b6d190550494dd4 Content-Type: text/plain; charset="UTF-8" I couldn't find prior discussion about this, if I missed it somehow could someone cluestick me? We've been working with Murray on openarc, and there are some chain validation failure modes that closely resemble a dkim tempfail (for instance, DNS unresponsiveness when trying to query for a key). Right now, these create chain states of cv=fail. We believe this is the correct behavior, as a message in transit amongst multiple hops cannot cleanly have a temporary error retried, so the temporary failure effectively becomes a permanent error for the chain and cv=fail is justified because the chain is dead from this point forward. That said, is there any value (especially for final receivers), in transmitting that this failure was due to a temporary error and not necessarily a permanent one? And is so, where would this transmission live? Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a11403b7a7b6d190550494dd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I couldn't find prior discussion about this, if I miss= ed it somehow could someone cluestick me?

We've been= working with Murray on openarc, and there are some chain validation failur= e modes that closely resemble a dkim tempfail (for instance, DNS unresponsi= veness when trying to query for a key).

Right now,= these create chain states of cv=3Dfail.

We believe this is the correct behavior, as a message in transit amongst= multiple hops cannot cleanly have a temporary error retried, so the tempor= ary failure effectively becomes a permanent error for the chain and cv=3Dfa= il is justified because the chain is dead from this point forward.

That said, is there any value (especially for final receiv= ers), in transmitting that this failure was due to a temporary error and no= t necessarily a permanent one? And is so, where would this transmission liv= e?

Seth

--

3D"logo

Bringing Trust to Email

Set= h Blank | Head of Product for Open Source and Protocols

seth@valimail.com
+1-415-894-2724
--001a11403b7a7b6d190550494dd4-- From nobody Wed May 24 11:35:39 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 4E50C1201F2 for ; Wed, 24 May 2017 11:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 HnCzjeDZ2nGA for ; Wed, 24 May 2017 11:35:34 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 9BC69124281 for ; Wed, 24 May 2017 11:35:34 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id f55so162842580qta.3 for ; Wed, 24 May 2017 11:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SxbcEdzn7krB5RcmRGmoA7dYJOM8yg6BIO5Pgrb9N0U=; b=RyYksnDsaVoSHVySCgl18r0fJ0YVBUqlpyzX5JyPO6529UMmGKX4TfK/D3AyVepr9n ExEdfserJl96xaNwV4WLZRFPpL2gSTwal0TC9S5bSRrTqknfxKL3QE5APoDEfMEjpiqv LFbQFzw+seNZG3bvUUeVhXHMJfeSxe2SC83hoCV/rY5GCbkkQ5eG7Il6pYFbSjPk+6ZV gq1Pv/3RR0wvl7UYEotLBfWI/xAGouypIhuk3yodL5WeOOjUu4I7XK/OZ+lZhb232Ap+ Ng84qn7TPOzGOSLtwaHObl12RFNu659YpRCnStQDZvYpxmUZPvI3f1S8cvjbbWRvKiXG 5OKA== 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=SxbcEdzn7krB5RcmRGmoA7dYJOM8yg6BIO5Pgrb9N0U=; b=oaIQhWgLtHweDTJc/ZgW0QaBvZ7H3CDvbq4HAO8DaFZXRDv1/XCaj+/GbpVi2/HcHe dvKM5hqH4lUZnQmiclJjcnezMZtUW+vzMqBPOGexdTFaF8nMEYJPS1gyOj3fIQRG6FAg L6Ifg1ebO4EL+KLCNArCg+RHFfncrjDfJfmOoTz4jd/1B3ej05ZUaB6F47b8Q4UkTAzm zFwNUaX1sXUbUwugc4YyAr5tdC6yfB4p2tqryw+owfha+fHP8xh/62BBemUtgeJ59IhH tuz77VOvwJJlItyXuGB+I8qZgJLTOxiTpuDoD4flPU2BiVC6dkl7cmxuWsh+AOc1oHvs RC7A== X-Gm-Message-State: AODbwcB/XBbalYar3Lo+YfQysROXpvgLIB5XTl3nSapWhunEBrdYeHZE ev+rX7w3eoB1IRRx7kt3qRBJJ6yhRhiJ X-Received: by 10.200.43.203 with SMTP id n11mr34542825qtn.241.1495650933829; Wed, 24 May 2017 11:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 11:35:13 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 24 May 2017 11:35:13 -0700 Message-ID: To: "dmarc@ietf.org" Cc: Brandon Long , Kurt Andersen , Murray superuser Kucherawy Content-Type: multipart/alternative; boundary="001a1135a4469e827a0550495e78" Archived-At: Subject: Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature 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, 24 May 2017 18:35:37 -0000 --001a1135a4469e827a0550495e78 Content-Type: text/plain; charset="UTF-8" Does the group have any further thoughts here? I'm happy to suggest language for Gene's suggestion if there are no further comments. On Tue, May 9, 2017 at 4:02 PM, Gene Shuman wrote: > I definitely can't imagine any sensible case in which the d= tags should > be different. I do think the tag should still be specified in both the AS > & AMS though. While not strictly necessary technically, it does make the > language in the spec & implementation details a bit cleaner. So I would > suggest simply adding a line/section in the chain validation section of the > draft or somewhere else that says cv=fail(or invalid?) if the d= tags > aren't identical. I think this is an entirely reasonable restriction. > > =Gene > > On Thu, May 4, 2017 at 3:44 PM, Brandon Long wrote: > >> When thinking about how to extract information from an arc chain, I was >> wondering at the "owner" of a section of the chain. >> >> Theoretically, that's the ADMD. A single hop, however, has three >> separate domain ownerships, the srv_id from the AAR, and the d= field from >> the AS and AMS. >> >> Our current implementation uses google.com for the d= field, and we have >> three different srv_id's for different pools that serve different >> purposes. That said, the srv_id has no "validation" except for by the key >> signature, so d= seems like a stronger "owner". >> >> Except, the AMS and AS can have separate selectors and domains. I'm not >> sure if that's useful or desirable. I'm tempted to only consider a chain >> valid if the domains are the same, and I guess not care if the selectors >> are. >> >> Should we require them to be the same? If we do, should they only be >> specified once? >> >> For changing algorithms, I guess s would be different, along with a, >> though I would think you would need a separate set of headers for the hop >> for each a in transition... >> >> So: >> Should we require d= to be the same? Should we specify it only once? If >> not, why not? >> >> Brandon >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1135a4469e827a0550495e78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does the group have any further thoughts here?

I'm happy to suggest language for Gene's suggestion if ther= e are no further comments.

On Tue, May 9, 2017 at 4:02 PM, Gene Shuman <gene@valimai= l.com> wrote:
I definitely can't imagine any sensible case in which the d=3D tags= should be different.=C2=A0 I do think the tag should still be specified in= both the AS & AMS though.=C2=A0 While not strictly necessary technical= ly, it does make the language in the spec & implementation details a bi= t cleaner.=C2=A0 So I would suggest simply adding a line/section in the cha= in validation section of the draft or somewhere else that says cv=3Dfail(or= invalid?) if the d=3D tags aren't identical.=C2=A0 I think this is an = entirely reasonable restriction. =C2=A0

=3DGene

On Thu, May 4, 2017 at 3:44 PM, Brandon Long= <blong@google.com> wrote:
When thinking about how to extract information from an arc chain, I was wo= ndering at the "owner" of a section of the chain.

<= div>Theoretically, that's the ADMD.=C2=A0 A single hop, however, has th= ree separate domain ownerships, the srv_id from the AAR, and the d=3D field= from the AS and AMS.

Our current implementation u= ses google.com for the = d=3D field, and we have three different srv_id's for different pools th= at serve different purposes.=C2=A0 That said, the srv_id has no "valid= ation" except for by the key signature, so d=3D seems like a stronger = "owner".

Except, the AMS and AS can have= separate selectors and domains.=C2=A0 I'm not sure if that's usefu= l or desirable.=C2=A0 I'm tempted to only consider a chain valid if the= domains are the same, and I guess not care if the selectors are.

Should we require them to be the same?=C2=A0 If we do, shou= ld they only be specified once?

For changing algor= ithms, I guess s would be different, along with a, though I would think you= would need a separate set of headers for the hop for each a in transition.= ..

So:
Should we require d=3D to be the = same?=C2=A0 Should we specify it only once?=C2=A0 If not, why not?

Brandon

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



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




--

3D"log=

Bringing Trust t= o Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valimail.com
+1-415-894-2724
--001a1135a4469e827a0550495e78-- From nobody Wed May 24 12:26:45 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 095E8129AE8 for ; Wed, 24 May 2017 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMnXeG0JyasN for ; Wed, 24 May 2017 12:26:42 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7417F128CFF for ; Wed, 24 May 2017 12:26:42 -0700 (PDT) Received: (qmail 97388 invoked from network); 24 May 2017 19:26:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 May 2017 19:26:39 -0000 Date: 24 May 2017 19:26:17 -0000 Message-ID: <20170524192617.36732.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org Cc: seth@valimail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 24 May 2017 19:26:44 -0000 In article you write: >Looking at random messages on this list, I've seen anywhere from two to >five AR headers per message. Locally, with opendkim and opendmarc running, >there are three locally generated AR headers that get passed to openarc. It >looks like seeing multiple AR headers is going to be a common occurrence >for ARC implementations to handle. When I take a look, I only see one, from ietfa.amsl.com. If I were having the list mailed to me, I'd expect to see two, that one plus the one my system adds. It is rather peculiar to have multiple headers with the same service identifier, since section 5 of RFC 7601 says that you normally delete exsting A-R headers with the same authserv-id before you add a new one. On my system, the SMTP daemon calls the spf2, opendkim, and opendmarc libraries, and then puts all the results in a single A-R header. For example, when I look at mail from a list I forward to a gmail account, I see one A-R header from mx.google.com, one from my system, and maybe one from the original system. I think that's more typical. >Is this a problem the group thinks needs discussion? Only if there are a lot of MTAs that don't report their results in one header. R's, John From nobody Wed May 24 15:56:13 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 08988128B93 for ; Wed, 24 May 2017 15:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 JK-I3uTyNqAq for ; Wed, 24 May 2017 15:56:09 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA7C01288B8 for ; Wed, 24 May 2017 15:56:09 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id f55so167943912qta.3 for ; Wed, 24 May 2017 15:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dULWhGb53BJQ95uq2HA40iJ/nTsfpLCK5wS878aeVoc=; b=gI23Erec9cvzHwEPtTLxugo29zK9Tcd53dJTaFskcRx3OqDp4Ynh49QkF/tTYmqe9S hYBSnt3olHQIh+9Pbr/xzGQKoy37FeisfPCPTn1w8EkFdEkW/zJ/mVmcYvedLj4FiWit NnAy8genV5UnV1mH8pPIdDUSQOD46cZ+mqkmxZRZtG2fzdvcB63QudeEu0a63THrD4O+ CrLnlDvcYxRxyP4abyp14ayNtsIZQsxbIrJCq/Q7C1Xj+FwaZDjvSFdzTiALDTKWgm0x UD9nLi33y8M6Qhwo8z6cdCRx+zHacyhL/Uxq4NNJRlqQ5MF+XNVVmE7FLqOldLFuWB/s GEUA== 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=dULWhGb53BJQ95uq2HA40iJ/nTsfpLCK5wS878aeVoc=; b=VaRJbZQIMwhbb3pxJQrFZu4FnHfMMvyZOFaJMcgD8BuspS7k2lBvdAOvpbWG1SYPlg O8OKNc9VIb518jsJXNZ+30FcxhFUFbagzUv1n+klebSEKp+LOrXw8u7yl2um/VA2XRaX 3r0EXoA+Gpm4BMjufhohNLFcD+E54utQUVMY+RFWtT0EZQtZl4UeApKprIozUSHH0402 qT8JC/nSZ3zCrYa+aGV5tYgOFu51Wcyxqj8zpqo1J9XJezxrVp0j0B7myBPDzfCer/DS xn8IXd9sOU34Kb6fhPm2d0TK2Frby/fMbhpoy1frngMMDzfj+1viffiumk3OxcPCdP+X Rpdw== X-Gm-Message-State: AODbwcD6CAHxoVIyJpRT2YVi6CxFCqMXIGPPkasYZHsoK/DxaufwbzgF O+gVO8iDhSvakexxTXZf9TktwmGtC53A X-Received: by 10.237.37.154 with SMTP id x26mr39882068qtc.133.1495666568844; Wed, 24 May 2017 15:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 15:55:48 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 24 May 2017 15:55:48 -0700 Message-ID: To: "dmarc@ietf.org" Cc: Gene Shuman , "Murray S. Kucherawy" , Brandon Long , Kurt Andersen Content-Type: multipart/alternative; boundary="001a113bfc7289e8b205504d026c" Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 24 May 2017 22:56:13 -0000 --001a113bfc7289e8b205504d026c Content-Type: text/plain; charset="UTF-8" Looping back about this. Currently openarc only supports relaxed canonicalization for the ARC Message Signature. On closer inspection, https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-03#section-5.1.2 and https://tools.ietf.org/ html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.2 do *not* appear to be in direct contradiction of each other. 5.1.2 states that AMS header canonicalization must be relaxed, and 5.1.2.1.2 says that AMS body canonicalization must respect the c= value. Is this what was intended (AMS headers=relaxed, body=[c value]), and should be included in the proposed draft? Or should the entire AMS (headers and body) respect the c value and both specs be updated? Seth On Wed, May 10, 2017 at 12:34 AM, Brandon Long wrote: > > > On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > >> I've taken a look at the proposed draft and have a few notes as well. >> >> 4. The currently specified limits on i= are not included MUST >10, >> SHOULD > 50, etc >> >> 5.1 - In the current draft, it's mandated that AMS must use relaxed >> header canonicalization, but that's missing from the proposed draft >> > > I think that 5.1.2 in the current draft is wrong, it's overridden by 5.1.2.1.2. > We started out only allowing relaxed, but then added back support for c= in > a later draft. > > Brandon > > 5.2 - I'm a bit confused by the comment noting the importance of i=2. >> What is it that you're intending there? >> >> 5.3.1 - typo: one of three possible values: -> one of *four* possible >> values >> >> 7.2 - It may be worth elaborating more on the possible ways in which >> cv=invalid can arise, if not here, maybe somewhere else >> >> 7.4 - In general I prefer this to the psuedo code in the current draft, >> but I think it could still use a bit of work. In particular, sections C-H >> are exactly describing how to validate a DKIM signature and seems somewhat >> unnecessary. Is there any particular reason you decided to include this, as >> opposed to just relying on the DKIM spec for this? >> >> 7.5 - typo: no -> all >> >> In general though, I agree with Brandon, the proposed draft definitely >> makes some things clearer, which I think is a step in the right direction. >> >> =Gene >> >> >> On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: >> >>> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and >>> AuthRes headers. In particular, AuthRes headers are expected to be removed >>> by ADMDs, especially if the message transits the same ADMD multiple times. >>> Also, the information in the AuthRes header is superseded by the ArcAuthRes >>> header. Including it means an arbitrary AMS breakage for something pretty >>> minor, so I would recommend to not include it. >>> >>> Our implementation explicitly blacklists that header. >>> >>> I know some mailing lists also strip the DKIM-Signature header, but >>> since they are likely to break the AMS anyways, that's less important. I'm >>> not sure what the benefit is to including it, but it seems harmless. In >>> particular, if the DKIM-Signature still passes, then the ARC isn't adding >>> that much, and removing the DKIM-Signature header doesn't mean all that >>> much either since it's validity was already assessed and that assessment >>> included in the AAR. We don't blacklist the DKIM-Signature method in our >>> implementation, but I don't understand the advisement. >>> >>> You also talk about "responsibility". I'm not sure that's how I would >>> describe it. An ARC hop is documenting that a message passed through it, >>> and that it evaluated the authentication of the message. The only >>> responsibility of a hop is to correctly validate the SPF/DKIM/ARC >>> information, there is no ownership implied over the message itself. >>> >>> With AMS, you can answer the question: which ADMD is the last ADMD to >>> have modified the message. I guess in that sense, the last modifier is >>> "responsible" for the current state of the message... but that kind of >>> means that the AMS of previous hops allows them to disown responsibility >>> for the current state of the message... >>> >>> 5.2 - should we point out that there should be only one of these per >>> hop? The openspf/dkim/dmarc implementations tend to add separate AuthRes >>> headers for each evaluation, but ARC requires those to be a single instance. >>> >>> 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my >>> understanding of those terms is slightly odd, but I would think that an MSA >>> usually uses an MTA to actually send the message, and it isn't that >>> "sending" MTA that's the first hop, it should be the first "receiving" >>> MTA. I mean, that's usually the point at which the DKIM signature is >>> applied, and the SPF would be "from" there, not based on the location of >>> the MUA. >>> >>> There are some missing pieces here, corresponding to the current draft >>> sections 5.4 (alternate signing algorithms), 6.4.3 (arc email >>> authentication method for AuthRes), 6.4.5 for dmarc xml. I see that the >>> arc is included in your IANA section, not sure if the call out outside of >>> the definition is necessary or not. >>> >>> Overall, I think your draft makes some things clearer, and some things >>> in the original are clearer. It's worth looking into either combining or >>> choosing. >>> >>> >>> Brandon >>> >>> On Thu, May 4, 2017 at 12:56 AM, Murray S. Kucherawy < >>> superuser@gmail.com> wrote: >>> >>>> Colleagues, >>>> >>>> As I progress (slowly, alas) toward completing my sample implementation >>>> of OpenARC, I've found myself taking a lot of notes about the current >>>> draft. This has helped me make progress; in some cases it became things I >>>> posted to the list, and in others it was just to help or confirm my >>>> understanding of the protocol. >>>> >>>> I have developed this enough to become a fairly comprehensive >>>> alternative text to the current draft. I find the layout of this version >>>> to flow better for my own purposes, and in a few places I've tried to >>>> clarify some of the material by rewriting chunks of it. None of this is >>>> meant to assert that the current draft is deficient; I've just found it to >>>> be a helpful exercise for me. >>>> >>>> I offer it here to the WG as a contribution; the WG of course is free >>>> to use some, all, or none of it as it wishes. >>>> >>>> http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt >>>> >>>> If it would be more helpful to post this as an I-D, please let me know. >>>> >>>> -MSK >>>> >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>>> >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113bfc7289e8b205504d026c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looping back about this.

Currently open= arc only supports relaxed canonicalization for the ARC Message Signature.

5.1.2 states that AMS header canonicalization must be relaxed, = and 5.1.2.1.2 says that AMS body canonicalization must respect the c=3D val= ue.

Is this what was intended (AMS headers=3Drelax= ed, body=3D[c value]), and should be included in the proposed draft? Or sho= uld the entire AMS (headers and body) respect the c value and both specs be= updated?

Seth
On Wed, May 10, 2017 at 12:34 AM, Brandon Long = <blong@google.com> wrote:
<= div dir=3D"ltr">

On Tue, May 9, 2017 at 3:56 PM, Gene Shuman <= gene@valimail.com> wrote:
I've taken a look at the proposed draft and= have a few notes as well.

4.=C2=A0 The currently specif= ied limits on i=3D are not included MUST >10, SHOULD > 50, etc
<= div>
5.1 - In the current draft, it's mandated that AMS m= ust use relaxed header canonicalization, but that's missing from the pr= oposed draft


Brand= on

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
5.2 = - I'm a bit confused by the comment noting the importance of i=3D2.=C2= =A0 What is it that you're intending there?

5.= 3.1 - typo: =C2=A0one of three possible values: -> one of four po= ssible values

7.2 - It may be worth elaborating mo= re on the possible ways in which cv=3Dinvalid can arise, if not here, maybe= somewhere else

7.4 - In general I prefer this to = the psuedo code in the current draft, but I think it could still use a bit = of work.=C2=A0 In particular, sections C-H are exactly describing how to va= lidate a DKIM signature and seems somewhat unnecessary. Is there any partic= ular reason you decided to include this, as opposed to just relying on the = DKIM spec for this?

7.5 - typo: no -> all
=

In general though, I agree with Brandon, the proposed d= raft definitely makes some things clearer, which I think is a step in the r= ight direction.

=3DGene


On Tue, May 9, 2017 at 2:04 PM, Br= andon Long <blong@google.com> wrote:
In 5.1 defining the AMS, you = say that it should cover DKIM-Signature and AuthRes headers.=C2=A0 In parti= cular, AuthRes headers are expected to be removed by ADMDs, especially if t= he message transits the same ADMD multiple times.=C2=A0 Also, the informati= on in the AuthRes header is superseded by the ArcAuthRes header.=C2=A0 Incl= uding it means an arbitrary AMS breakage for something pretty minor, so I w= ould recommend to not include it.

Our implementation exp= licitly blacklists that header.

I know some mailin= g lists also strip the DKIM-Signature header, but since they are likely to = break the AMS anyways, that's less important.=C2=A0 I'm not sure wh= at the benefit is to including it, but it seems harmless.=C2=A0 In particul= ar, if the DKIM-Signature still passes, then the ARC isn't adding that = much, and removing the DKIM-Signature header doesn't mean all that much= either since it's validity was already assessed and that assessment in= cluded in the AAR.=C2=A0 We don't blacklist the DKIM-Signature method i= n our implementation, but I don't understand the advisement.
=
You also talk about "responsibility".=C2=A0 I'= m not sure that's how I would describe it.=C2=A0 An ARC hop is document= ing that a message passed through it, and that it evaluated the authenticat= ion of the message.=C2=A0 The only responsibility of a hop is to correctly = validate the SPF/DKIM/ARC information, there is no ownership implied over t= he message itself.

With AMS, you can answer the qu= estion: which ADMD is the last ADMD to have modified the message.=C2=A0 I g= uess in that sense, the last modifier is "responsible" for the cu= rrent state of the message... but that kind of means that the AMS of previo= us hops allows them to disown responsibility for the current state of the m= essage...

5.2 - should we point out that there sho= uld be only one of these per hop?=C2=A0 The openspf/dkim/dmarc implementati= ons tend to add separate AuthRes headers for each evaluation, but ARC requi= res those to be a single instance.

5.3.1 - none as= defined as "arrives at an MTA from an MSA", perhaps my understan= ding of those terms is slightly odd, but I would think that an MSA usually = uses an MTA to actually send the message, and it isn't that "sendi= ng" MTA that's the first hop, it should be the first "receivi= ng" MTA.=C2=A0 I mean, that's usually the point at which the DKIM = signature is applied, and the SPF would be "from" there, not base= d on the location of the MUA.

There are some missi= ng pieces here, corresponding to the current draft sections 5.4 (alternate = signing algorithms), 6.4.3 (arc email authentication method for AuthRes), 6= .4.5 for dmarc xml.=C2=A0 I see that the arc is included in your IANA secti= on, not sure if the call out outside of the definition is necessary or not.=

Overall, I think your draft makes some things cle= arer, and some things in the original are clearer.=C2=A0 It's worth loo= king into either combining or choosing.


=
Brandon

On Thu, May 4, 2017 at 12:56 AM, Murray S. Kuchera= wy <superuser@gmail.com> wrote:
<= div>
Colleagues,

As I progress (slowly, alas) toward = completing my sample implementation of OpenARC, I've found myself takin= g a lot of notes about the current draft.=C2=A0 This has helped me make pro= gress; in some cases it became things I posted to the list, and in others i= t was just to help or confirm my understanding of the protocol.

I have developed this enough to become a fairly comprehensive alternative= text to the current draft.=C2=A0 I find the layout of this version to flow= better for my own purposes, and in a few places I've tried to clarify = some of the material by rewriting chunks of it.=C2=A0 None of this is meant= to assert that the current draft is deficient; I've just found it to b= e a helpful exercise for me.

I offer it here to the WG as a contribu= tion; the WG of course is free to use some, all, or none of it as it wishes= .

http://blackops.org/~msk/draft-kucherawy-dmarc= -arc-base.txt

If it would be more helpful to post thi= s as an I-D, please let me know.

-MSK

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



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




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




--

Bringing Trust to E= mail

Seth Blank | Head of Product for Open Source and Protocols=

= seth@valimail.com
+1-415-894-2724
--001a113bfc7289e8b205504d026c-- From nobody Wed May 24 15:56:20 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 4E2F7129BA8 for ; Wed, 24 May 2017 15:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfJhzPBrarJP for ; Wed, 24 May 2017 15:56:17 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 6155C129B55 for ; Wed, 24 May 2017 15:56:17 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id b204so260818248oii.1 for ; Wed, 24 May 2017 15:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dBJIU1AuP5mr/9MjIOxni+mqy+6LV5h8yvZWRWm737w=; b=gJZ1jlV+5hqips6uvgWZatlT+Wd4U60N3ZOLnERP1NCWFwCe44crZSD/COqyip1XWq 5Q+Fs7mp9pWbTbdMpmCMEMvlTy6e3SSwhhe6JONfLhiknD/6G+GUkMxbOKZ0v1VHRwOa +xTIQ830MHINnnU5N0Q4ZG+DiWiofrH/CrjFOVV9jJnn5lSZrA5Uy6McOoZWAMqMbk+2 3HFbJC0ml5qydI0TwGznRpbOCmNsaKGmpJS8qqCPZuPXMOsYJQ5s6OdB4bysz3LIV7Yq 9lepT1XR1p8d1A5gDTzTklS/avBtDjG8nZNWDKX0KpDi6+wJfHrhUTuP/GpHSPfk1GXo +1Ug== 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=dBJIU1AuP5mr/9MjIOxni+mqy+6LV5h8yvZWRWm737w=; b=kHHHGxIoISS55WDUTa7mS65lKvBqlx1Rsn6bWPqbKcNJHB/YNQoIMT9Q2eE4XvGxhx yJkLysZSUjeU4F44m4+ODzh0S0LqrsW8bpryjVxi067k1zOlHSGWiGaelFR7tJUZgrTD 3odlqmTlIutBPj/vzvPDDrrnf1/ZBd/Ln6AaGbjkMxL5ftiRxePoWyp2REUTNzkT58yn wqVsC1W5dN+qFQ1OTDFMn1kbKqCoCcGDhnUgLwixErJgsgu+C04QC/DUzTJ0vb5gRr5k E2vYRErt4yOOvn/vPZ7EWeu6h6gUk9vAaqC88CPEOQYf3G1er+Hn7BRCDLcG3XZ72ZSQ /Q/w== X-Gm-Message-State: AODbwcDNg7feZI+8sBeYjjm4yVCCLPao8TnbTHfEB7CnhCVnCGRlY48o ZrS+/AaebDqn9FYe/KuGEmp6DCTkltGI X-Received: by 10.202.204.197 with SMTP id c188mr18678741oig.194.1495666576473; Wed, 24 May 2017 15:56:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 24 May 2017 15:56:16 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 24 May 2017 15:56:16 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11c17710febc9505504d02f1" Archived-At: Subject: Re: [dmarc-ietf] Does the concept of an ARC tempfail make any sense? 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, 24 May 2017 22:56:19 -0000 --001a11c17710febc9505504d02f1 Content-Type: text/plain; charset="UTF-8" So, last year I did add the concept of a dmarc tempfail to our code, but the main utility of that was to respond with a 4xx error on p=reject instead of a 5xx error. I could imagine having an arc temp fail that could have otherwise overridden a p=reject having the same utility. I could also imagine that an arc temp fail at a non-modifying hop shouldn't be any different than just not signing that hop. If if is a modifying hop, then the chain will break on the next hop that's able to successfully evaluate. If you encapsulate the failure in the chain, does that gain anything? Can a subsequent hop basically override the tempfail to a fail or pass? I guess a tempfail hop would still have valid spf/dkim data in the new AAR, just an inability to use any previous information. In that sense, it's like removing the existing chain and replacing it. Again, in that sense, a tempfail would be like not processing the arc chain at all, validity wise. Ie, you can sign an arc chain without validating it. If you did that with a cv=pass, you're taking "ownership" of a potentially invalid chain, but if we add cv=tempfail, maybe the ownership is voided. I think it makes the chain harder to reason about, and I'm not sure the added utility is useful. Brandon On Wed, May 24, 2017 at 11:30 AM, Seth Blank wrote: > I couldn't find prior discussion about this, if I missed it somehow could > someone cluestick me? > > We've been working with Murray on openarc, and there are some chain > validation failure modes that closely resemble a dkim tempfail (for > instance, DNS unresponsiveness when trying to query for a key). > > Right now, these create chain states of cv=fail. > > We believe this is the correct behavior, as a message in transit amongst > multiple hops cannot cleanly have a temporary error retried, so the > temporary failure effectively becomes a permanent error for the chain and > cv=fail is justified because the chain is dead from this point forward. > > That said, is there any value (especially for final receivers), in > transmitting that this failure was due to a temporary error and not > necessarily a permanent one? And is so, where would this transmission live? > > Seth > > -- > > [image: logo for sig file.png] > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > seth@valimail.com > +1-415-894-2724 <415-894-2724> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c17710febc9505504d02f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, last year I did add the concept of a dmarc tempfail to= our code, but the main utility of that was to respond with a 4xx error on = p=3Dreject instead of a 5xx error.

I could imagine having an arc te= mp fail that could have otherwise overridden a p=3Dreject having the same u= tility.

I could also imagine that an arc temp fail= at a non-modifying hop shouldn't be any different than just not signin= g that hop.=C2=A0 If if is a modifying hop, then the chain will break on th= e next hop that's able to successfully evaluate.

If you encapsulate the failure in the chain, does that gain anything?=C2= =A0 Can a subsequent hop basically override the tempfail to a fail or pass?=

I guess a tempfail hop would still have valid spf= /dkim data in the new AAR, just an inability to use any previous informatio= n.=C2=A0 In that sense, it's like removing the existing chain and repla= cing it.=C2=A0 Again, in that sense, a tempfail would be like not processin= g the arc chain at all, validity wise.=C2=A0 Ie, you can sign an arc chain = without validating it.=C2=A0 If you did that with a cv=3Dpass, you're t= aking "ownership" of a potentially invalid chain, but if we add c= v=3Dtempfail, maybe the ownership is voided.

I thi= nk it makes the chain harder to reason about, and I'm not sure the adde= d utility is useful.

Brandon

On Wed, May 24, 2017 at 11:= 30 AM, Seth Blank <seth@valimail.com> wrote:
I couldn't find prior discussion ab= out this, if I missed it somehow could someone cluestick me?

=
We've been working with Murray on openarc, and there are some chai= n validation failure modes that closely resemble a dkim tempfail (for insta= nce, DNS unresponsiveness when trying to query for a key).

Right now, these create chain states of cv=3Dfail.

We believe this is the correct behavior, as a message= in transit amongst multiple hops cannot cleanly have a temporary error ret= ried, so the temporary failure effectively becomes a permanent error for th= e chain and cv=3Dfail is justified because the chain is dead from this poin= t forward.

That said, is there any value (especial= ly for final receivers), in transmitting that this failure was due to a tem= porary error and not necessarily a permanent one? And is so, where would th= is transmission live?
<= div>
Seth

--

3D"logo

Bringing Trust to Email

<= p dir=3D"ltr" style=3D"font-size:12.8px;line-height:1.38;margin-top:0pt;mar= gin-bottom:0pt">Seth Blank | Head of Product for Open Source and Protocols

seth@valimail.c= om
<= font face=3D"arial, helvetica, sans-serif">+1-415-894-2724

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


--001a11c17710febc9505504d02f1-- From nobody Wed May 24 16:10:23 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 8092C1288B8 for ; Wed, 24 May 2017 16:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfRXue9wKp0W for ; Wed, 24 May 2017 16:10:20 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 870FC126D05 for ; Wed, 24 May 2017 16:10:20 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so260962713oib.3 for ; Wed, 24 May 2017 16:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hrqAY4AE07BBp77QkLDLQwhrQdyL0Dob3NTOmc6sqYI=; b=NBuzmIFvGcP8AQz+lH4mYgq+2PAUDRu5dca66Qzfqitou+ZLrohmYShDbuooNgWy5R o5+Z6wSLnuxvIAh9MYloAdiB5O8TFQNbqtoh85vnqvvVxJnrQ19Hkex7XFgy1hqljHBa x0jD0kX2UUl5q2yW6Dk4J1TgbwQ8a11uuZnqRt8Khy0nO5oQSv3kFIhzAUbCjcJ5IvKs I91N12k7cCzmxrn1B8lRoFYo5YiiH+H9+eAJj3HN+bfFL9YdUtiaBJpr5TQ0rZN18KB/ SW8NuwOD0X75p8ROsR+CmH6ZtiPO4oR+LMuJPr2R1i0KGR/wSMCkkRwoFhH6FE5lRSbt hNSA== 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=hrqAY4AE07BBp77QkLDLQwhrQdyL0Dob3NTOmc6sqYI=; b=rm/NIj4FSUbHI3Vmb3FyT2pxgK8IxLC2HV24tv8WrajrbkwYiGULgYjpIJla1hr4di hgxN9Om7/JD4Tgj96y/1SsicPtpDJ/WsPN3/5EgVJGC4WCBXBx6noD3wTO8WqchaZjJ1 SM9QS2gAs5Ili1aBHdGWZDVLLC8Ji8V4RgBk0nz3lBZu1e5wezknNQb/T/a6KIeLKQrd n+cIOTf4b8+m3O5fcthAvdOvDojGMFbsfzUQbRe1olQj4r76qMqk149o0NRMtTtF6BZ/ UFKDbsIzrhyYcEoC7uvil7Aqijr7kKRVmcsuuRykyogcNNqwajyWriOVCu6WBb1w4Yxc nNAg== X-Gm-Message-State: AODbwcDnVoYKkmCczFePCs5OwWTPVsQoce88NBeOAFvwkp4iSV9/+cVF JQ+YxH+pXu5uznO4VLeMqmPv0Qamtjrbc8g= X-Received: by 10.202.178.85 with SMTP id b82mr17013855oif.51.1495667419690; Wed, 24 May 2017 16:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 24 May 2017 16:10:19 -0700 (PDT) In-Reply-To: <20170524192617.36732.qmail@ary.lan> References: <20170524192617.36732.qmail@ary.lan> From: Brandon Long Date: Wed, 24 May 2017 16:10:19 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="001a1146ac5e41271c05504d3550" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 24 May 2017 23:10:22 -0000 --001a1146ac5e41271c05504d3550 Content-Type: text/plain; charset="UTF-8" On Wed, May 24, 2017 at 12:26 PM, John Levine wrote: > In article gmail.com> you write: > >Looking at random messages on this list, I've seen anywhere from two to > >five AR headers per message. Locally, with opendkim and opendmarc running, > >there are three locally generated AR headers that get passed to openarc. > It > >looks like seeing multiple AR headers is going to be a common occurrence > >for ARC implementations to handle. > > When I take a look, I only see one, from ietfa.amsl.com. If I were > having the list mailed to me, I'd expect to see two, that one plus the > one my system adds. It is rather peculiar to have multiple headers > with the same service identifier, since section 5 of RFC 7601 says > that you normally delete exsting A-R headers with the same > authserv-id before you add a new one. > Section 1.6 specifies that you would delete them on entrance to the ADMD, and 2.1 seems to specify that multiple are allowed, and example B.4 shows an example where multiple are used. On my system, the SMTP daemon calls the spf2, opendkim, and opendmarc > libraries, and then puts all the results in a single A-R header. For > example, when I look at mail from a list I forward to a gmail account, > I see one A-R header from mx.google.com, one from my system, and maybe > one from the original system. I think that's more typical. > > >Is this a problem the group thinks needs discussion? > > Only if there are a lot of MTAs that don't report their results in one > header. > I think the default using the open* libs is to do so, so probably. OTOH, how to do so seems fairly obvious, I'm not clear on why doing so needs to be specified. Being sure the spec specifies that only one is allowed, definitely. Brandon --001a1146ac5e41271c05504d3550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 24, 2017 at 12:26 PM, John Levine <johnl@taugh.com> wrote:
In article = <CAOZAAfOsRrQF2M3NzcB3h2Tc03mtFfG8mOJ0pqU+_cx=3DwhcBLQ@mail.gmail.com> you write: >Looking at random messages on this list, I've seen anywhere from tw= o to
>five AR headers per message. Locally, with opendkim and opendmarc runni= ng,
>there are three locally generated AR headers that get passed to openarc= . It
>looks like seeing multiple AR headers is going to be a common occurrenc= e
>for ARC implementations to handle.

When I take a look, I only see one, from ietfa.amsl.com.=C2=A0 If I = were
having the list mailed to me, I'd expect to see two, that one plus the<= br> one my system adds.=C2=A0 It is rather peculiar to have multiple headers with the same service identifier, since section 5 of RFC 7601 says
that you normally delete exsting A-R headers with the same
authserv-id before you add a new one.

S= ection 1.6 specifies that you would delete them on entrance to the ADMD, an= d 2.1 seems to specify that multiple are allowed, and example B.4 shows an = example where multiple are used.

On my system, the SMTP daemon calls the spf2, opendkim, and opendmarc
libraries, and then puts all the results in a single A-R header.=C2=A0 For<= br> example, when I look at mail from a list I forward to a gmail account,
I see one A-R header from mx.google.com, one from my system, and maybe
one from the original system.=C2=A0 I think that's more typical.

>Is this a problem the group thinks needs discussion?

Only if there are a lot of MTAs that don't report their results = in one
header.

I think the default using the o= pen* libs is to do so, so probably.=C2=A0 OTOH, how to do so seems fairly o= bvious, I'm not clear on why doing so needs to be specified.=C2=A0 Bein= g sure the spec specifies that only one is allowed, definitely.
<= br>
Brandon
--001a1146ac5e41271c05504d3550-- From nobody Wed May 24 16:34:30 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 B5F56128CDC for ; Wed, 24 May 2017 16:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 hotCqygeKMbr for ; Wed, 24 May 2017 16:34:26 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 3AEEA12751F for ; Wed, 24 May 2017 16:34:26 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f55so168447251qta.3 for ; Wed, 24 May 2017 16:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aki/+oChF5XCKSBveh82Dx56hEtH2o8TyCUp+bmd0j8=; b=YIGOWdu7g2XA3fJOEYU4cLdbeyfX7hjh8Z9fMiAaeiI+asiZ1N9+BqsOVBYrSWApB7 VVPteEFMitDmZSurG62KezA/y3nSAlxZrwnw/ydseG9UByKbbHcwE4tyfUIq2fyw1RXl xBr6SGPQCgMeadj8x44/wk7oVvzjvtwsmab+xsNYT1KWRvmMU0Cf8kmqngvL4bhuYNNI TUaDdw+KXjsR2whTJUazUQAyJHDdkiQ5AIDorxb8u4xgBH+/KddzT24YCQjxqqs35NTw RW3jYBnqsEboZmFeiiLUyhEwveLfw/oTSoGxcWw8+yPZXbQns/lP3KFRuJ1u67v4FSc/ zCbw== 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=Aki/+oChF5XCKSBveh82Dx56hEtH2o8TyCUp+bmd0j8=; b=XQIeIzkUcbVuW/fSZRPS1DivKPXo4LL7IPiK8Ib60eZPP2YVXvj98gCVdIWJCuRhut QwJFFWvHltRnDniYP+n7f6W9JqC46KfBjfH6yqLeMhYIZWfFj1e92Fn4s91elLFwgbC/ 2m7RHw7jdRtJ/L68v1++zVDiu+S441Y5rtn/1JwHkrfWBgP+6FH49Ln3ftNTwFfecXc/ wRtPQtsLlvnsYwjZPRkTRxjq5kJ9/N9vYEVYi8gk/S9kljwuqjdMu3Wtk0uDJ72hNwT0 odLWgNUmUBHXxIGWErYFs0KYlhbFyIipxu931OPJfQgKtmoGOenilVWDaML0CTqs61Ce +3Yw== X-Gm-Message-State: AODbwcCOqcJ3UAXyCGCn8jnbmpoPVRZQ92tYc+/yoe2Y18hkMQuwNJjm 7myxZGIj/wVr3uFxs06+HlG5DxbcAWED4cE= X-Received: by 10.200.47.161 with SMTP id l30mr39336728qta.153.1495668865258; Wed, 24 May 2017 16:34:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 24 May 2017 16:34:04 -0700 (PDT) In-Reply-To: References: <20170524192617.36732.qmail@ary.lan> From: Seth Blank Date: Wed, 24 May 2017 16:34:04 -0700 Message-ID: To: "dmarc@ietf.org" Cc: John Levine , Brandon Long , Kurt Andersen Content-Type: multipart/alternative; boundary="001a113789126a681605504d8bd0" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 24 May 2017 23:34:29 -0000 --001a113789126a681605504d8bd0 Content-Type: text/plain; charset="UTF-8" On Wed, May 24, 2017 at 4:10 PM, Brandon Long wrote: > I think the default using the open* libs is to do so, so probably. OTOH, > how to do so seems fairly obvious, I'm not clear on why doing so needs to > be specified. Being sure the spec specifies that only one is allowed, > definitely. > > Brandon > Yes, the open* libs create multiple AR headers, there are even various open source tools (like https://github.com/RunasSudo/combineAR) to combine them. While addressing multiple AR handling in openarc (which was immediately necessary when running it alongside opendkim and opendmarc), how to do so was not explicit in the spec, hence the question. Agreed that we're only talking about a single AAR per hop. Also agreed the solution appears as straightforward as just combining all AR results from your ADMD into a single one and then turning that into the AAR. But I'm uncertain if that's the method the group thinks is appropriate and if there's been any earlier conversation around this. Regardless, there are already implementations that do this in different ways, so I'd argue clarity in the spec is a good thing. Especially since just grabbing an existing AR header might prove lossy in a way that makes original message disposition impossible to determine for a final receiver. If we're in agreement, I would suggest adding the following sentence to the first paragraph of https://tools.ietf.org/html/dr aft-ietf-dmarc-arc-protocol-03#section-5.1.3 : "The AAR should contain all Authentication-Results results from within its ADMD, regardless of how many Authentication-Results headers are on the message." I think between that and the third paragraph of the section, the above "obvious" solution becomes the only possible solution allowed per spec. Thoughts? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113789126a681605504d8bd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 24, 2017 at 4:10 PM, Brandon Long <blong@google.com>= wrote:
I thin= k the default using the open* libs is to do so, so probably.=C2=A0 OTOH, ho= w to do so seems fairly obvious, I'm not clear on why doing so needs to= be specified.=C2=A0 Being sure the spec specifies that only one is allowed= , definitely.

Brandon


Yes, the open* libs create multiple AR headers, = there are even various open source tools (like https://github.com/RunasSudo/combineAR) to combine them.

<= div class=3D"gmail_extra">While addressing multiple AR handling in openarc = (which was immediately necessary when running it alongside opendkim and ope= ndmarc), how to do so was not explicit in the spec, hence the question.

Agreed th= at we're only talking about a single AAR per hop. Also agreed the solut= ion=C2=A0appears as straightforward as just combining all AR results from y= our ADMD into a single one and then turning that into the AAR. But I'm = uncertain if that's the method the group thinks is appropriate and if t= here's been any earlier conversation around this.

Regardless, there are alrea= dy implementations that do this in different ways, so I'd argue clarity= in the spec is a good thing. Especially since just grabbing an existing AR= header might prove lossy in a way that makes original message disposition = impossible to determine for a final receiver.

If we're in agreement, I would = suggest adding the following sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf-dmarc-arc-pr= otocol-03#section-5.1.3 :

"The AAR should contain all Authenticatio= n-Results results from within its ADMD, regardless of how many Authenticati= on-Results headers are on the message."

I think between that and the third paragraph of the s= ection, the above "obvious" solution becomes the only possible so= lution allowed per spec.

Thoughts?

<= /div>--

=3D"logo

Bringing Tr= ust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valimail.com
+1-415-894-2724
--001a113789126a681605504d8bd0-- From nobody Wed May 24 16:42: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 9926212704B for ; Wed, 24 May 2017 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=BwuvNRXr; dkim=pass (1536-bit key) header.d=taugh.com header.b=OCJmsUJK 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 VY28ZHUaysX5 for ; Wed, 24 May 2017 16:42:18 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09CAB129B55 for ; Wed, 24 May 2017 16:42:17 -0700 (PDT) Received: (qmail 23631 invoked from network); 24 May 2017 23:42:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5c4d.59261a58.k1705; bh=CmtgqDD3jqrDD7knNPCyQAZms998J3d9ADha2o4MqYs=; b=BwuvNRXrtWvHCzGthVkQ2fX/xw9lWvf6ciMei5apFH8CVGSXJQDmFsjKBuH3Zjxms2XttFdQfhD0/LbsqZXLbdsddy65cyD/Q8kJMNJ4IpI9TMk1XdSnTHhIdBpTkAewSzWOonSFmkHHjgfcaD+NDGkzB4eQJTNzp4nrkq27l+LLhvACWl4ik/JkfqfwUi1Cr9ESps+dDViWLmRF61ELU659a5pbSORGYrdgWJmTr+FHyudatrzkTk2cSVptAkkQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5c4d.59261a58.k1705; bh=CmtgqDD3jqrDD7knNPCyQAZms998J3d9ADha2o4MqYs=; b=OCJmsUJKIZVn8ieNCT4/pxRNLjJH2Nx+zNwuHGukUXOzt0x6XG/Y9GYsCKN887yfr4ozbyqFxlQIjpMXud1uwzRgss+zRAEbKpMjxOvEIh12EqhPpjC5tbVZRzfqSEtSkkZBe9OlEmhsCFbuwrVenMIlkvuMesFG5cGjqeajnckBOfl44EX9GWrl5zDkq45TleF7iojhvMG0jvehiy22etCcrJeGRb52aRO5Lt4xTtSKfLwjK5nPznDtGO5cnr73 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 24 May 2017 23:42:16 -0000 Date: 24 May 2017 19:42:16 -0400 Message-ID: From: "John R Levine" To: "Seth Blank" Cc: "dmarc@ietf.org" In-Reply-To: References: <20170524192617.36732.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 24 May 2017 23:42:20 -0000 On Wed, 24 May 2017, Seth Blank wrote: > aft-ietf-dmarc-arc-protocol-03#section-5.1.3 : > > "The AAR should contain all Authentication-Results results from within its > ADMD, regardless of how many Authentication-Results headers are on the > message." Seems reasonable, give or take a word or two to make it clear we're just talking about the ones for the current hop. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 24 17:06:56 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 A27F1129B44 for ; Wed, 24 May 2017 17:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRPWmtRgwLRp for ; Wed, 24 May 2017 17:06:54 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DE912940F for ; Wed, 24 May 2017 17:06:53 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b204so262270261oii.1 for ; Wed, 24 May 2017 17:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LR/a9lhS/lpQS2Sh1qvEK59/F3bPO65qvIBORJx87Hg=; b=YwiKPJ8njvZBOAHlYDTecrLBqNJoepCTxuP9mOzswfg2O9lUo3fZO9wflKNbhsklkw fUMAwEKi7m45IPcNP2arQMD89g5X3Zbprg/pRzaBiRPe5Qmmd0HlJQRnxbRbsH9mYO1j /7xmu5y/eiCvBlnB3HEw8BTJEwu0IWg5ysDUvI0rlperdyd/0d5Hbre9T40+eTxmwMY5 HfiITQd0fWBNzB3wQimIhlCy5cT91faTAViIKdXpocrlwx3F3E97CK+sFqXUujG2yRoH mmVgDd1IjxqWWbfZWLwfKO6OwgAf1OeC+APrV9hmAuDAJxaeWEBi0Hh0w53d1tAOEIpW fDow== 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=LR/a9lhS/lpQS2Sh1qvEK59/F3bPO65qvIBORJx87Hg=; b=It4lFgMPF1bXQ0dq8fqFP2YbAOyIEl0UoKJQuzUm3W6osMloeQ2lLmIKEFafqzrlsF pd+MvevJLuZkmp5Z5OL5+plCMWjQmEGHoW8P/uWV8wnt241j4XQsHfdL4FUw+SItLNao bJEeGO9xYeo9EHIB0ihaKPj0hz+PPb/al9IkMP1HgmzkmFSj+nke74JsTjO2rB/69OPX GlxECxfWe/QBEDpGPtlTiMZxVXa/GboT0v+5Oq+QkZURc/qc4tgTDe+ygH2ldZX837ts KrxEcBxJdcI3gNX42805BhyjH9dNJ1Xh5dIXayV2nXphdSQjU+0K3M0xOCBt5POeHxWA /noQ== X-Gm-Message-State: AODbwcCYvLCa/Qqj000+oQu4qJ21kpwuiYurjtN7z7IEt7B+CYz3MiaB q/p8rlqAmMMPQqw+no+6shnYY/50jJvS X-Received: by 10.202.170.12 with SMTP id t12mr19310662oie.44.1495670813149; Wed, 24 May 2017 17:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 24 May 2017 17:06:52 -0700 (PDT) In-Reply-To: References: <20170524192617.36732.qmail@ary.lan> From: Brandon Long Date: Wed, 24 May 2017 17:06:52 -0700 Message-ID: To: John R Levine Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cdef485554805504dffb2" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 25 May 2017 00:06:56 -0000 --001a113cdef485554805504dffb2 Content-Type: text/plain; charset="UTF-8" On Wed, May 24, 2017 at 4:42 PM, John R Levine wrote: > On Wed, 24 May 2017, Seth Blank wrote: > >> aft-ietf-dmarc-arc-protocol-03#section-5.1.3 : >> >> "The AAR should contain all Authentication-Results results from within its >> ADMD, regardless of how many Authentication-Results headers are on the >> message." >> > > Seems reasonable, give or take a word or two to make it clear we're just > talking about the ones for the current hop. There should only be the ones from the current hop if the admd is stripping previously existing ones prior to adding any new ones per the authres rfc. We can make that fact explicit here as well, though. Brandon --001a113cdef485554805504dffb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 24, 2017 at 4:42 PM, John R Levine <johnl@taugh.com><= /span> wrote:
On Wed, 24= May 2017, Seth Blank wrote:
aft-ietf-dmarc-arc-protocol-03#section-5.1.3 :

"The AAR should contain all Authentication-Results results from within= its
ADMD, regardless of how many Authentication-Results headers are on the
message."

 Seems reasonable, give or take a word or two to make it clear we're jus= t talking about the ones for the current hop.

There should only be the ones from the current hop if the admd is stripp= ing previously existing ones prior to adding any new ones per the authres r= fc.

We can make that fact explicit here as well, t= hough.

Brandon=C2=A0

--001a113cdef485554805504dffb2-- From nobody Wed May 24 17:27: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 22341129353 for ; Wed, 24 May 2017 17:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=f/LwLG+y; dkim=pass (1536-bit key) header.d=taugh.com header.b=wgqx4iY3 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 DWVEd9OXUG85 for ; Wed, 24 May 2017 17:27:11 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E2D120724 for ; Wed, 24 May 2017 17:27:11 -0700 (PDT) Received: (qmail 28136 invoked from network); 25 May 2017 00:27:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6de6.592624de.k1705; bh=KRlkyQ5ptzcVLht+ozUxZ31nKN91bBO1MEneg+Eqf7o=; b=f/LwLG+yDBjtkxckpssOPgxnaXilm35XLvE8v5L7b/QI0AnBjlDpcm0eotvzogLQws/j1t004zrdP35TZgC/BHp9ZeOFDndnKr5a4/xtLZ7KbOwmhETz/XPfVj4t39hVmteeed8cfFYNbhQgKHiZ2Y/dpye109OkzXzKcETMaREJgPN4qB9dRc64p6YqDCFLjVIax4nY32B3UCrP9VBx0sroE8S/kME7j4N/LzdhZ4G2oJ+Cd9Kxk4lfWgTslfvs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6de6.592624de.k1705; bh=KRlkyQ5ptzcVLht+ozUxZ31nKN91bBO1MEneg+Eqf7o=; b=wgqx4iY3h6lvsnru6N6V1WilfBGiyuJ/No8kueX6qKFglMLU3D6mWzWBGI8urnPsjSYRz+yjF/JQJdNl35sofsrdDjrfoBarUftOwA9rSuo5SMOut/wPvO9mNr1T114RYjNleHBy1QrrvS8ZZBBcKbWrw1vC16fzePt7Pd/EWP0Y4UuS99sInLQUlnmSLNO1PSX0aq1wrvlSG4XeVvQVgC+BBeRlebYLEnxLcWZbU45gITbb6K8JIx9PM8LoAgmx Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 25 May 2017 00:27:10 -0000 Date: 24 May 2017 20:27:09 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: "dmarc@ietf.org" In-Reply-To: References: <20170524192617.36732.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 25 May 2017 00:27:13 -0000 >> Seems reasonable, give or take a word or two to make it clear we're just >> talking about the ones for the current hop. > > There should only be the ones from the current hop if the admd is stripping > previously existing ones prior to adding any new ones per the authres rfc. I meant not to use a-r with different admds. Should be obvious, but you never know. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed May 24 17:34:45 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 48D05129494 for ; Wed, 24 May 2017 17:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gO4A5Rj51Kfd for ; Wed, 24 May 2017 17:34:42 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1519129427 for ; Wed, 24 May 2017 17:34:42 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w10so263374114oif.0 for ; Wed, 24 May 2017 17:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S+YI59HCdyCj+7SRIBDb+sY+F3jI4qYo+tbv7vAjlf4=; b=FdBcyLRsuOc4p7gU9UjmOJ6BqDrzUI4aa1dJLDF/eu4TOnAUqFiAUnfqPHYwJHVi7p oq3wKxvwhlkRDcctQAByQTp5SrBqJoiGYs2Cfcen6qumJA7HMg6Rf0L3uEe+dzBMBKYw nURpBcC7JiwAdV70aDl5ppb3Yv75AsBnNg+g4/zaAAcuvukwtUtLRM/GVCF8jX3NJ8tM zYSQ8UOFhdqaxk7b3UQGVNowkCGAD8c78Dc0YHyvFPulliPgBYHyjy7TKmXtjnWXhu2I F/y8xeiIdxWEf/9/jjDOIRGqK5BHF7FX5q6C4Vxw5bunOLOJuWqRxay4zYWuGTUhLrZD bDLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S+YI59HCdyCj+7SRIBDb+sY+F3jI4qYo+tbv7vAjlf4=; b=sJmCsO/iWdP1zxbkBTW1oHYpqrmdpYty4XGNQlbaO9cuYE6U8RbdN2knW36enBnrJv ha8CMEknk9mO3HfPIeBwYsxpWqufLlHu4R7UeDPVihOXnCXu86RRZIB8DBGG4wID3/uh bOLHTT+SbFf5RZReh6NtCKJlc4go1TwOTMWfZ10qcvu1tjbajTtaHiaZ65Ogvd76bKfc iohBj15auAxmBUu2sNwPuLRzMD2/7Pd7DaCsdR4B7+rI1zqR5+W5BITO6kaDplncxUz0 QeHcRrFl4JZuNaezbtsmJOQzu+C7UNtEomOComPnipI1Fami5bm8Hkyx9jFykdO0vBpJ 7qLg== X-Gm-Message-State: AODbwcDskjJ2N7fNNprwSx81XD6C8lAcGf2OQuFhS3qKEPzwblwVwR1D 1yk1F/lJWjDFg0Sdxuk= X-Received: by 10.202.84.86 with SMTP id i83mr19931421oib.69.1495672481907; Wed, 24 May 2017 17:34:41 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id 110sm2605530otj.30.2017.05.24.17.34.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 17:34:41 -0700 (PDT) To: John R Levine , Brandon Long Cc: "dmarc@ietf.org" References: <20170524192617.36732.qmail@ary.lan> From: Dave Crocker Message-ID: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> Date: Wed, 24 May 2017 17:34:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 25 May 2017 00:34:44 -0000 On 5/24/2017 5:27 PM, John R Levine wrote: >>> Seems reasonable, give or take a word or two to make it clear we're just >>> talking about the ones for the current hop. >> >> There should only be the ones from the current hop if the admd is >> stripping >> previously existing ones prior to adding any new ones per the authres >> rfc. > > I meant not to use a-r with different admds. Should be obvious, but you > never know. I'd expect a spec to declare that there must be only one A-R header field, and that it is applied within the current, integrated mail processing environment. (I'd say within the current ADMD, but I think there are valid scenarios where that characterization doesn't quite fit, although the language can probably be contorted to make that more-limited language sufficient.) Unless there is a very compelling need for multiple A-R header fields -- and I don't think I've seen that asserted -- then the simplest thing is to declare them illegal and any occurrence of them as invalidating the authentication mechanism(s). Really. The goal here needs to be to make this a simple as possible. It's the only way to get large scale support that interoperates well. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 24 18:38:04 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 10A32128796 for ; Wed, 24 May 2017 18:38:02 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=Od2p/HA6; dkim=pass (1536-bit key) header.d=taugh.com header.b=fjcd4Q/2 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 aSwzEeGTIHYf for ; Wed, 24 May 2017 18:38:00 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BA6129409 for ; Wed, 24 May 2017 18:37:59 -0700 (PDT) Received: (qmail 35427 invoked from network); 25 May 2017 01:37:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8a61.59263576.k1705; bh=V+cbuUSpNYiYbfN9joyNuoSesCVL98gulNm1QnwkPHI=; b=Od2p/HA6R5FlZIhfkQG8M9L9xes0OHYVnn/idDO+6wDwSuBBd91oGWQy9oRP0KcObeQN3qqLDskfLyHREcgY2ua7pHin7PVnVLrmzrFLIDC9krofF88/X4KQslvm5HmYRu3P/QSkW+CuP+H+IGVeFdhRuRfJgl2B6MY2czi2whLdCoiyTONAvfwz817rqQCWAGPjSw+6uw00Sdy1Qn90//WyoraqKXvshjfpjlTHdhkTwQzQ8ft+bN94J5n5R2pZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8a61.59263576.k1705; bh=V+cbuUSpNYiYbfN9joyNuoSesCVL98gulNm1QnwkPHI=; b=fjcd4Q/2klK1Ziu0VxcCFQfP42XecA2iT9ddHb6sVhZyljPEFFQ4l+nXyIp5vjHXQkvB2JkXXWzsE2oGt+yi1t1OZSlvaHb8oEXVgOfnOtTOagEXD+TEYe1ehU0JlIEhJiyRDS/7ZNSfce6cb5R3cobJQZnCPJ5RP+hJIZJHxC1pCPBY4n1gMWdojy2Y0Y2zbZxL65sP8lUmv8JreTICLyMBLnQEU8pAbUWqlcRT6IR18ZdgzWPS94xQi3GfQKSf Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 25 May 2017 01:37:58 -0000 Date: 24 May 2017 21:37:58 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: "dmarc@ietf.org" In-Reply-To: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> References: <20170524192617.36732.qmail@ary.lan> <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 25 May 2017 01:38:02 -0000 On Wed, 24 May 2017, Dave Crocker wrote: > Unless there is a very compelling need for multiple A-R header fields -- and > I don't think I've seen that asserted -- then the simplest thing is to > declare them illegal and any occurrence of them as invalidating the > authentication mechanism(s). There's two things going on here. One is the A-R headers added as an incoming message is recieved, the other is the ARC-Authentication-Results added by ARC. Personally, I agree with you that there's no reason to allow duplicates of either (it took me about a day to write the mailfront plugin that checks SPF, DKIM, and DMARC and adds one A-R header, and I'm not that good a programmer), but the horse seems to have left the barn for A-R and a lot of sloppy code adds multiple headers for the same message hop. On the other hand ARC-Authentication-Results is new, and we can certainly say there's only one of those. > Really. The goal here needs to be to make this a simple as possible. It's > the only way to get large scale support that interoperates well. Agreed. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu May 25 06:00:01 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 8B12C129535 for ; Thu, 25 May 2017 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=americangreetings.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 fHiNsNKYiecm for ; Thu, 25 May 2017 05:59:55 -0700 (PDT) Received: from mailer2.americangreetings.com (mailer2.americangreetings.com [66.119.43.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916D212944A for ; Thu, 25 May 2017 05:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1495717194; x=1527253194; h=From:Subject:Date:To:Cc:Reply-To:Message-ID:MIME-Version:Content-Type; bh=+L4I1svCxkaAC5YeNOctMZZjtHA05hjqxvw/Lu0y0XQ=; b=LWF6re6EIwSzerLnZeNzXS33CqQUrCmV88CA72opyeoc26acRwM1nNdmIrtmCs/q ZDExJON52c73PEwpNOB9zckdoIzGmcDcGC6Ni290DNM3K/fzGLoR+W2sODILpHSn MF5e78BGc5ekXKZosb9FeOv4rv6Nq8Yh9LO8QmeuZzg=; Received: from [66.119.43.83] ([66.119.43.83:31118] helo=dc3-mbox.ops.ag.com) by momentum7 (envelope-from ) (ecelerity 3.6.18.52357 r(Core:3.6.18.0)) with ESMTP id 2D/50-38523-A45D6295; Thu, 25 May 2017 08:59:54 -0400 Received: from [10.210.42.34] ([10.210.42.34]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with ESMTP id v4PCxrRH012406 for ; Thu, 25 May 2017 08:59:53 -0400 To: dmarc@ietf.org References: From: "mhammer@americangreetings.com" Message-ID: <4b8b3b8e-4c0a-1ea7-8328-bc2febd19db9@americangreetings.com> Date: Thu, 25 May 2017 08:59:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B18D2E2F7CC1834D5B2B1015" Archived-At: Subject: Re: [dmarc-ietf] Does the concept of an ARC tempfail make any sense? 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, 25 May 2017 12:59:58 -0000 This is a multi-part message in MIME format. --------------B18D2E2F7CC1834D5B2B1015 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I'm normally not a fan of reputation but this may be a case where reputation might be useful. I'd have to think on this some more. Mike On 5/24/2017 6:56 PM, Brandon Long wrote: > So, last year I did add the concept of a dmarc tempfail to our code, > but the main utility of that was to respond with a 4xx error on > p=reject instead of a 5xx error. > > I could imagine having an arc temp fail that could have otherwise > overridden a p=reject having the same utility. > > I could also imagine that an arc temp fail at a non-modifying hop > shouldn't be any different than just not signing that hop. If if is a > modifying hop, then the chain will break on the next hop that's able > to successfully evaluate. > > If you encapsulate the failure in the chain, does that gain anything? > Can a subsequent hop basically override the tempfail to a fail or pass? > > I guess a tempfail hop would still have valid spf/dkim data in the new > AAR, just an inability to use any previous information. In that > sense, it's like removing the existing chain and replacing it. Again, > in that sense, a tempfail would be like not processing the arc chain > at all, validity wise. Ie, you can sign an arc chain without > validating it. If you did that with a cv=pass, you're taking > "ownership" of a potentially invalid chain, but if we add cv=tempfail, > maybe the ownership is voided. > > I think it makes the chain harder to reason about, and I'm not sure > the added utility is useful. > > Brandon > > On Wed, May 24, 2017 at 11:30 AM, Seth Blank > wrote: > > I couldn't find prior discussion about this, if I missed it > somehow could someone cluestick me? > > We've been working with Murray on openarc, and there are some > chain validation failure modes that closely resemble a dkim > tempfail (for instance, DNS unresponsiveness when trying to query > for a key). > > Right now, these create chain states of cv=fail. > > We believe this is the correct behavior, as a message in transit > amongst multiple hops cannot cleanly have a temporary error > retried, so the temporary failure effectively becomes a permanent > error for the chain and cv=fail is justified because the chain is > dead from this point forward. > > That said, is there any value (especially for final receivers), in > transmitting that this failure was due to a temporary error and > not necessarily a permanent one? And is so, where would this > transmission live? > > Seth > > -- > > logo for sig file.png > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > > seth@valimail.com +1-415-894-2724 > > _______________________________________________ dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --------------B18D2E2F7CC1834D5B2B1015 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+SSdtIG5vcm1hbGx5IG5vdCBhIGZhbiBv ZiByZXB1dGF0aW9uDQogICAgICBidXQgdGhpcyBtYXkgYmUgYSBjYXNlIHdoZXJlIHJlcHV0 YXRpb24gbWlnaHQgYmUgdXNlZnVsLiBJJ2QgaGF2ZQ0KICAgICAgdG8gdGhpbmsgb24gdGhp cyBzb21lIG1vcmUuPGJyPg0KICAgICAgPGJyPg0KICAgICAgTWlrZTxicj4NCiAgICAgIDxi cj4NCiAgICAgIE9uIDUvMjQvMjAxNyA2OjU2IFBNLCBCcmFuZG9uIExvbmcgd3JvdGU6PGJy Pg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlDQpjaXRlPSJtaWQ6Q0FCYThSNnR5aEdm ZkhYRHBNc1JfVDMxQXlIeXlITmR3Nk5mazhVQ2tfS0RTT0ZmNDRRQG1haWwuZ21haWwuY29t Ig0KICAgICAgdHlwZT0iY2l0ZSI+DQogICAgICA8ZGl2IGRpcj0ibHRyIj5TbywgbGFzdCB5 ZWFyIEkgZGlkIGFkZCB0aGUgY29uY2VwdCBvZiBhIGRtYXJjDQogICAgICAgIHRlbXBmYWls IHRvIG91ciBjb2RlLCBidXQgdGhlIG1haW4gdXRpbGl0eSBvZiB0aGF0IHdhcyB0bw0KICAg ICAgICByZXNwb25kIHdpdGggYSA0eHggZXJyb3Igb24gcD1yZWplY3QgaW5zdGVhZCBvZiBh IDV4eCBlcnJvci4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgSSBjb3VsZCBpbWFn aW5lIGhhdmluZyBhbiBhcmMgdGVtcCBmYWlsIHRoYXQgY291bGQgaGF2ZQ0KICAgICAgICAg IG90aGVyd2lzZSBvdmVycmlkZGVuIGEgcD1yZWplY3QgaGF2aW5nIHRoZSBzYW1lIHV0aWxp dHkuPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGRpdj5JIGNvdWxkIGFsc28gaW1hZ2luZSB0aGF0IGFuIGFyYyB0ZW1wIGZhaWwgYXQgYQ0K ICAgICAgICAgIG5vbi1tb2RpZnlpbmcgaG9wIHNob3VsZG4ndCBiZSBhbnkgZGlmZmVyZW50 IHRoYW4ganVzdCBub3QNCiAgICAgICAgICBzaWduaW5nIHRoYXQgaG9wLqAgSWYgaWYgaXMg YSBtb2RpZnlpbmcgaG9wLCB0aGVuIHRoZSBjaGFpbg0KICAgICAgICAgIHdpbGwgYnJlYWsg b24gdGhlIG5leHQgaG9wIHRoYXQncyBhYmxlIHRvIHN1Y2Nlc3NmdWxseQ0KICAgICAgICAg IGV2YWx1YXRlLjwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgPC9kaXY+DQog ICAgICAgIDxkaXY+SWYgeW91IGVuY2Fwc3VsYXRlIHRoZSBmYWlsdXJlIGluIHRoZSBjaGFp biwgZG9lcyB0aGF0IGdhaW4NCiAgICAgICAgICBhbnl0aGluZz+gIENhbiBhIHN1YnNlcXVl bnQgaG9wIGJhc2ljYWxseSBvdmVycmlkZSB0aGUNCiAgICAgICAgICB0ZW1wZmFpbCB0byBh IGZhaWwgb3IgcGFzcz88L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2 Pg0KICAgICAgICA8ZGl2PkkgZ3Vlc3MgYSB0ZW1wZmFpbCBob3Agd291bGQgc3RpbGwgaGF2 ZSB2YWxpZCBzcGYvZGtpbSBkYXRhDQogICAgICAgICAgaW4gdGhlIG5ldyBBQVIsIGp1c3Qg YW4gaW5hYmlsaXR5IHRvIHVzZSBhbnkgcHJldmlvdXMNCiAgICAgICAgICBpbmZvcm1hdGlv bi6gIEluIHRoYXQgc2Vuc2UsIGl0J3MgbGlrZSByZW1vdmluZyB0aGUgZXhpc3RpbmcNCiAg ICAgICAgICBjaGFpbiBhbmQgcmVwbGFjaW5nIGl0LqAgQWdhaW4sIGluIHRoYXQgc2Vuc2Us IGEgdGVtcGZhaWwNCiAgICAgICAgICB3b3VsZCBiZSBsaWtlIG5vdCBwcm9jZXNzaW5nIHRo ZSBhcmMgY2hhaW4gYXQgYWxsLCB2YWxpZGl0eQ0KICAgICAgICAgIHdpc2UuoCBJZSwgeW91 IGNhbiBzaWduIGFuIGFyYyBjaGFpbiB3aXRob3V0IHZhbGlkYXRpbmcgaXQuoA0KICAgICAg ICAgIElmIHlvdSBkaWQgdGhhdCB3aXRoIGEgY3Y9cGFzcywgeW91J3JlIHRha2luZyAib3du ZXJzaGlwIiBvZiBhDQogICAgICAgICAgcG90ZW50aWFsbHkgaW52YWxpZCBjaGFpbiwgYnV0 IGlmIHdlIGFkZCBjdj10ZW1wZmFpbCwgbWF5YmUNCiAgICAgICAgICB0aGUgb3duZXJzaGlw IGlzIHZvaWRlZC48L2Rpdj4NCiAgICAgICAgPGRpdj48YnI+DQogICAgICAgIDwvZGl2Pg0K ICAgICAgICA8ZGl2PkkgdGhpbmsgaXQgbWFrZXMgdGhlIGNoYWluIGhhcmRlciB0byByZWFz b24gYWJvdXQsIGFuZCBJJ20NCiAgICAgICAgICBub3Qgc3VyZSB0aGUgYWRkZWQgdXRpbGl0 eSBpcyB1c2VmdWwuPC9kaXY+DQogICAgICAgIDxkaXY+PGJyPg0KICAgICAgICA8L2Rpdj4N CiAgICAgICAgPGRpdj5CcmFuZG9uPC9kaXY+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQogICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBXZWQsIE1heSAyNCwgMjAxNyBhdCAxMTozMCBBTSwgU2V0aA0KICAgICAgICAg IEJsYW5rIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0K ICAgICAgICAgICAgICBocmVmPSJtYWlsdG86c2V0aEB2YWxpbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5zZXRoQHZhbGltYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPg0KICAgICAgICAgIHdy b3RlOjxicj4NCiAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQogICAgICAgICAgICA8ZGl2IGRpcj0ibHRy Ij5JIGNvdWxkbid0IGZpbmQgcHJpb3IgZGlzY3Vzc2lvbiBhYm91dCB0aGlzLA0KICAgICAg ICAgICAgICBpZiBJIG1pc3NlZCBpdCBzb21laG93IGNvdWxkIHNvbWVvbmUgY2x1ZXN0aWNr IG1lPw0KICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgIDxkaXY+V2UndmUgYmVlbiB3b3JraW5nIHdpdGggTXVycmF5IG9uIG9w ZW5hcmMsIGFuZCB0aGVyZQ0KICAgICAgICAgICAgICAgIGFyZSBzb21lIGNoYWluIHZhbGlk YXRpb24gZmFpbHVyZSBtb2RlcyB0aGF0IGNsb3NlbHkNCiAgICAgICAgICAgICAgICByZXNl bWJsZSBhIGRraW0gdGVtcGZhaWwgKGZvciBpbnN0YW5jZSwgRE5TDQogICAgICAgICAgICAg ICAgdW5yZXNwb25zaXZlbmVzcyB3aGVuIHRyeWluZyB0byBxdWVyeSBmb3IgYSBrZXkpLjwv ZGl2Pg0KICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgIDxkaXY+UmlnaHQgbm93LCB0aGVzZSBjcmVhdGUgY2hhaW4gc3RhdGVz IG9mIGN2PWZhaWwuPGJyDQogICAgICAgICAgICAgICAgICBjbGVhcj0iYWxsIj4NCiAgICAg ICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICA8ZGl2PldlIGJlbGlldmUgdGhpcyBpcyB0aGUgY29ycmVjdCBiZWhhdmlvciwg YXMgYQ0KICAgICAgICAgICAgICAgICAgbWVzc2FnZSBpbiB0cmFuc2l0IGFtb25nc3QgbXVs dGlwbGUgaG9wcyBjYW5ub3QNCiAgICAgICAgICAgICAgICAgIGNsZWFubHkgaGF2ZSBhIHRl bXBvcmFyeSBlcnJvciByZXRyaWVkLCBzbyB0aGUNCiAgICAgICAgICAgICAgICAgIHRlbXBv cmFyeSBmYWlsdXJlIGVmZmVjdGl2ZWx5IGJlY29tZXMgYSBwZXJtYW5lbnQNCiAgICAgICAg ICAgICAgICAgIGVycm9yIGZvciB0aGUgY2hhaW4gYW5kIGN2PWZhaWwgaXMganVzdGlmaWVk IGJlY2F1c2UNCiAgICAgICAgICAgICAgICAgIHRoZSBjaGFpbiBpcyBkZWFkIGZyb20gdGhp cyBwb2ludCBmb3J3YXJkLjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXY+PGJyPg0KICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXY+VGhhdCBzYWlkLCBp cyB0aGVyZSBhbnkgdmFsdWUgKGVzcGVjaWFsbHkgZm9yIGZpbmFsDQogICAgICAgICAgICAg ICAgICByZWNlaXZlcnMpLCBpbiB0cmFuc21pdHRpbmcgdGhhdCB0aGlzIGZhaWx1cmUgd2Fz IGR1ZQ0KICAgICAgICAgICAgICAgICAgdG8gYSB0ZW1wb3JhcnkgZXJyb3IgYW5kIG5vdCBu ZWNlc3NhcmlseSBhIHBlcm1hbmVudA0KICAgICAgICAgICAgICAgICAgb25lPyBBbmQgaXMg c28sIHdoZXJlIHdvdWxkIHRoaXMgdHJhbnNtaXNzaW9uIGxpdmU/PC9kaXY+DQogICAgICAg ICAgICAgICAgPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPg0K ICAgICAgICAgICAgICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+U2V0aDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8ZGl2Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAg ICAgICAgICAgICAgIC0tIDxicj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i bV8xMzcyODg2Mjk4MTc1ODg0NTUwZ21haWxfc2lnbmF0dXJlIg0KICAgICAgICAgICAgICAg ICAgICAgIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPg0KICAgICAgICAgICAg ICAgICAgICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGRp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxkaXYgZGlyPSJsdHIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 cCBkaXI9Imx0ciINCnN0eWxlPSJmb250LXNpemU6MTIuOHB4O2xpbmUtaGVpZ2h0OjEuMzg7 bWFyZ2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTQuNjY2N3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigwLDAsMCk7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXA7YmFja2dyb3VuZC1jb2xv cjp0cmFuc3BhcmVudCI+PGltZyBtb3otZG8tbm90LXNlbmQ9InRydWUiIHNyYz0iaHR0cHM6 Ly9saDUuZ29vZ2xldXNlcmNvbnRlbnQuY29tLzJINW80SVVhV1RRZzBDeXJ3b0pjOW1GajBU Y2JKTU1DV2FJWldjNXRTSS0zWTdOdGFTWFdWWTVqeWF4YThlRXVYa2J4X2xpSDJfUVZfSWNR V05BczJuTjA3c1JORHZBNU9TZDA2WFdKaUljTUtXMjRjOGRSdlVoNHhyMzNpQ19DTWdIemdP RHIiIGFsdD0ibG9nbyBmb3Igc2lnIGZpbGUucG5nIiBzdHlsZT0iYm9yZGVyOm5vbmUiIGhl aWdodD0iNjEiIHdpZHRoPSIyMzkiPjwvc3Bhbj48L3A+PHAgZGlyPSJsdHIiIHN0eWxlPSJm b250LXNpemU6MTIuOHB4O2xpbmUtaGVpZ2h0OjEuMzg7bWFyZ2luLXRvcDowcHQ7bWFyZ2lu LWJvdHRvbTowcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJweDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOnJnYigxMzEsMTM3LDEyOCk7Zm9udC1zdHlsZTppdGFsaWM7dmVydGlj YWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPkJyaW5naW5nIFRydXN0 IHRvIEVtYWlsPC9zcGFuPjwvcD48cCBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMi44 cHg7bGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOnJnYigxMzEsMTM3LDEyOCk7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxmb250IGZhY2U9 ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPlNldGggQmxhbmsgfCBIZWFkIG9mIFBy b2R1Y3QgPC9mb250Pjwvc3Bhbj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5z LXNlcmlmIiBjb2xvcj0iIzgzODk4MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O3do aXRlLXNwYWNlOnByZS13cmFwIj5mb3IgT3BlbiBTb3VyY2UgYW5kIFByb3RvY29sczwvc3Bh bj48L2ZvbnQ+PC9wPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6MTRweDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGEgbW96 LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c2V0aEB2YWxpbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5zZXRoQHZhbGltYWlsLmNvbTwvYT48L3NwYW4+PGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMi44cHgiIGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYi IGNvbG9yPSIjODM4OTgwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHg7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPg0KPC9zcGFuPjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0 cHg7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0idGVsOjQxNS04 OTQtMjcyNCIgdGFyZ2V0PSJfYmxhbmsiPisxLTQxNS04OTQtMjcyNDwvYT48L2ZvbnQ+PC9z cGFuPg0KPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+DQo8L2ZvbnQ+PC9z cGFuPjwvZGl2PjwvZGl2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2Jy Pl9fX19fX19fX19fX19fX19fDQoNCmRtYXJjIG1haWxpbmcgbGlzdA0KDQo8YSBtb3otZG8t bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNAaWV0 Zi5vcmc8L2E+DQoNCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3Rp bmZvL2RtYXJjPC9hPg0KDQoNCjwvYmxvY2txdW90ZT48L2Rpdj4NCjwvZGl2PjwvYmxvY2tx dW90ZT4NCjwvYm9keT48L2h0bWw+ --------------B18D2E2F7CC1834D5B2B1015-- From nobody Thu May 25 15:47:56 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 7AEAC127B52 for ; Thu, 25 May 2017 15:47:54 -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_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 RmLj1_FServx for ; Thu, 25 May 2017 15:47:52 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 F32A0129BD4 for ; Thu, 25 May 2017 15:47:51 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id c13so192654065qtc.1 for ; Thu, 25 May 2017 15:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=ns0MckXN3UyQl66XpSIl82oHyde31LAda7lV2qXHUCY=; b=M0cy/6fCtxdJz9Ep1G1gvUpYhwZZhS87Xe32jhpYj/w4SyRqaOOcNKgO0antSghNvU VPpcfZRZ51qxMCoJDToN69kqX7aqXuJ8WZNSW9hhjTCOjr8UJ/umQvQIaBqaSwHGZgPd S9tl6W3CnO4LrNvUR85RdeN6iPyeJSquNQp7sG2Wf9BdC/MmSkHbKuFiENYxws28QmXd OQBXo9junHdIEh5NtbAOxvQZYUI7S9H29T7lsPrviGxnr5srC4TbyQhQMDsObtA/q7mC PIxpISUwPeLwKl1F/TtVx7CgiUvLYR2oDZeKavucNrGayfxgzUdxrPHFDMUNMYOp/gIR VsXA== 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=ns0MckXN3UyQl66XpSIl82oHyde31LAda7lV2qXHUCY=; b=XIluNpEz9DZ73NGZTcqTLAsdM+B5S85xokXgCzbWCbpQs3QlgVCS/aALfCQdJgA4ht 3DqdYrnAnIJkGAa3i7b/kzRol6dZPMK3o6DPD9ZlFEZY2twxVSupDcDsA57Dei19ZFtw h4DbGwn7ql3aukjOPdQSC9r2un09QQu0U6Lt4fQ52LH/glWoooRUyLfB9VPUcoDNpMcd 7qpj/cafE6Tgkwlz6BLIBoxZbloOq2c20tKb8ZOqfnkRNBEMWQ171dxTL532nXMLZ7Ue jdVVxw7Gea+ymZEHmxPy8VMOiHRD7+nLCVEwWi+bwHsbadRYTtuftWVsmaCNyGRH1nP8 PcVg== X-Gm-Message-State: AODbwcBlkOzTigviM4QDFLeRQblUeHLj5BupRHV/x4Sg59LJR7yHLmnH iGuiVdmyFvYwq2Cnz/4BysFAqY+d4ZyrVSqWwg== X-Received: by 10.200.55.184 with SMTP id d53mr43396179qtc.94.1495752470892; Thu, 25 May 2017 15:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Thu, 25 May 2017 15:47:30 -0700 (PDT) From: Seth Blank Date: Thu, 25 May 2017 15:47:30 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113b0390b4b175055061023b" Archived-At: Subject: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 25 May 2017 22:47:54 -0000 --001a113b0390b4b175055061023b Content-Type: text/plain; charset="UTF-8" This might be a non-issue, but we're asking this question specifically because we've run into an implementation issue within openarc that feels weird and seems like a matter the WG may want to weigh in on. Our expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n]. Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* AAR[n] because AAR[n] isn't created until substantially later in the flow. Technically, this behavior is within spec as defined in https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.1 : Participants may include any other header fields within the scope of the ARC-Message-Signature signature except that they MUST NOT include ARC-Seal headers fields. In particular, including all DKIM-Signature header fields and all ARC-Authentication-Results header fields is RECOMMENDED. Is it worth guaranteeing that, if signing AARs, AMS[n] must cover AAR[n]? Or is this irrelevant because AS[n] is required to cover AMS[n] and AAR[n]? But if so, why recommend the AAR be covered by the AMS at all in the first place? While the differences between these two assertions appear to be benign (AAR[n] is always signed by AS[n], so whether or not it is in AMS[n] shouldn't matter), the spec leaves room for confusion about the right thing to do. What was the original intention here and does this need clarification? -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113b0390b4b175055061023b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This might be a non-issue, but we're asking this = question specifically because we've run into an implementation issue wi= thin openarc that feels weird and seems like a matter the WG may want to we= igh in on.

Our expectation is that, for any g= iven ARC Set n, AMS[n] would cover AAR[n].

Current= ly in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* AAR[n] beca= use AAR[n] isn't created until substantially later in the flow.

Technically, this behavior is within spec as defined in <= a href=3D"https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#sect= ion-5.1.2.1.1">https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03= #section-5.1.2.1.1 :

=C2=A0 =C2=A0P= articipants may include any other header fields within the scope of
=C2=A0 =C2=A0the ARC-Message-Signature signature except that they MUST N= OT include
=C2=A0 =C2=A0ARC-Seal headers fields.=C2=A0 In particu= lar, including all DKIM-Signature
=C2=A0 =C2=A0header fields and = all ARC-Authentication-Results header fields is
=C2=A0 =C2=A0RECO= MMENDED.

Is it worth guaranteeing that, if s= igning AARs, AMS[n] must cover AAR[n]?

Or is this = irrelevant because AS[n] is required to cover AMS[n] and AAR[n]? But if so,= why recommend the AAR be covered by the AMS at all in the first place?

While the differences between these two assertions ap= pear to be benign (AAR[n] is always signed by AS[n], so whether or not it i= s in AMS[n] shouldn't matter), the spec leaves room for confusion about= the right thing to do.

What was the original inte= ntion here and does this need clarification?

--

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113b0390b4b175055061023b-- From nobody Sat May 27 20:28:47 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 002DE127866 for ; Sat, 27 May 2017 20:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 aUrWmfl3t6xT for ; Sat, 27 May 2017 20:28:44 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F671272E1 for ; Sat, 27 May 2017 20:28:44 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A0537C40643; Sat, 27 May 2017 22:28:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1495942121; bh=Y+XM0BAGcshhovFn0xwkFSaRvjWLEkpCSwDVjWy6fYA=; h=Date:In-Reply-To:References:Subject:To:From:From; b=vJ12H34Q75ehnmkJnLpLGtQmdVXmuwGtD48A5t5NwcmZOcfsTnlRiFDVRzSnQbzFx cI2AuNL3on7f8HJV352LccTrRIftX8z8cbRUiy4s2ZLiuTAx0PJEk65d7//QagVTBb q6P1uwIUT1nip2Af7ciME9s0raJRAkZIX3BrP4wQ= Date: Sun, 28 May 2017 03:28:40 +0000 In-Reply-To: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> References: <20170524192617.36732.qmail@ary.lan> <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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: Sun, 28 May 2017 03:28:46 -0000 On May 24, 2017 8:34:38 PM EDT, Dave Crocker wrote: >On 5/24/2017 5:27 PM, John R Levine wrote: >>>> Seems reasonable, give or take a word or two to make it clear we're >just >>>> talking about the ones for the current hop=2E >>> >>> There should only be the ones from the current hop if the admd is=20 >>> stripping >>> previously existing ones prior to adding any new ones per the >authres=20 >>> rfc=2E >>=20 >> I meant not to use a-r with different admds=2E Should be obvious, but >you=20 >> never know=2E > > >I'd expect a spec to declare that there must be only one A-R header=20 >field, and that it is applied within the current, integrated mail=20 >processing environment=2E (I'd say within the current ADMD, but I think= =20 >there are valid scenarios where that characterization doesn't quite >fit,=20 >although the language can probably be contorted to make that=20 >more-limited language sufficient=2E) > >Unless there is a very compelling need for multiple A-R header fields >--=20 >and I don't think I've seen that asserted -- then the simplest thing is > >to declare them illegal and any occurrence of them as invalidating the=20 >authentication mechanism(s)=2E > >Really=2E The goal here needs to be to make this a simple as possible=2E= =20 >It's the only way to get large scale support that interoperates well=2E Nothing other than potentially ARC requires multiple AR header fields for = different authentication types to be combined=2E These different verificat= ion operations (e=2Eg=2E SPF, DKIM, and DMARC) are generally performed be d= ifferent processes that add their own AR field=2E Requiring a single AR field will not make the system any less complicated,= it only changes where you put the complexity=2E It probably makes sense to stick the sender with the complexity of dealing= with multiple AR fields and combining then, but let's not pretend there's = an overall simplification here=2E Scott K From nobody Sun May 28 08:27:39 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 653DB1273E2 for ; Sun, 28 May 2017 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV3cDrAo0XLY for ; Sun, 28 May 2017 08:27:37 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7D9127241 for ; Sun, 28 May 2017 08:27:36 -0700 (PDT) Received: (qmail 82983 invoked by uid 100); 28 May 2017 15:27:36 -0000 Delivered-To: reroute list-iecc-lists-ietf-dmarc@johnlevine.com Date: 28 May 2017 15:27:35 +0000 Message-ID: From: "John Levine" To: dmarc@ietf.org Organization: Taughannock Networks, Trumansburg NY References: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@aryv.qy (John L) Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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: Sun, 28 May 2017 15:27:38 -0000 In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com>, >Nothing other than potentially ARC requires multiple AR header fields for different authentication types to be combined. These different >verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be different processes that add their own AR field. Since DMARC needs the results of SPF and DKIM, how does that work? Does DMARC look at the A-R that the other two created or is there a side channel? It occurs to me that a DMARC process has everything needed to make a header that combines all three. >It probably makes sense to stick the sender with the complexity of dealing with multiple AR fields and combining then, but let's not pretend there's an overall simplification here. In ARC, definitely. My setup already does a combined header, since I wrote one plugin that calls all three libraries. On my setup (mailfront) it was a lot easier than doing it separately. R's, John From nobody Sun May 28 08:54:07 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 C4A69126D74 for ; Sun, 28 May 2017 08:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=kitterman.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 bbRqCfUk6_DU for ; Sun, 28 May 2017 08:54:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80354124D68 for ; Sun, 28 May 2017 08:54:04 -0700 (PDT) Received: from [10.145.196.213] (mobile-166-171-56-218.mycingular.net [166.171.56.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 67A39C4010C; Sun, 28 May 2017 10:54:00 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1495986841; bh=VPuVq3kVTP0Z0NF+ApqjPx3zl1ejYbJ+RsDrBxQHRpQ=; h=Date:In-Reply-To:References:Subject:To:From:From; b=xdjesSmRPWs3DCFTXz0Q0DXS2st1Dubf6bPYPSu/R6NWrv+4FzZnYvl/Mudd9SHOg C4Ij5m9/IXxB27aykfqUEZdSGsj62S2EehWAZkZqG0eqoFBJNi2O/c2URZ630T9D9S qa1OUWkwtoec7pNt1SHKD+9izjxv2K22k/x1hGVE= Date: Sun, 28 May 2017 15:53:57 +0000 In-Reply-To: References: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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: Sun, 28 May 2017 15:54:06 -0000 On May 28, 2017 11:27:35 AM EDT, John Levine wrote: >In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman=2Ecom>, >>Nothing other than potentially ARC requires multiple AR header fields >for different authentication types to be combined=2E These different >>verification operations (e=2Eg=2E SPF, DKIM, and DMARC) are generally >performed be different processes that add their own AR field=2E > >Since DMARC needs the results of SPF and DKIM, how does that work? >Does DMARC look at the A-R that the other two created or is there a >side channel? It occurs to me that a DMARC process has everything >needed to make a header that combines all three=2E snip At least for OpenDMARC, if it's not doing it's own SPF check (which seems = odd to me because it's done after DATA, but it works), it will look at mult= iple AR fields for both SPF and DKIM results=2E =20 Scott K From nobody Mon May 29 09:49:19 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 674F3127333 for ; Mon, 29 May 2017 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 jiQASOVgVjPE for ; Mon, 29 May 2017 09:49:17 -0700 (PDT) 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 1D3F61200C5 for ; Mon, 29 May 2017 09:49:17 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d14so11593165qkb.1 for ; Mon, 29 May 2017 09:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Pw4Eijt6MABrSeeZF0UkA8LHqDES+ZofU7sl28iu7ec=; b=hlzpbYOYwlmUqruJTzhtmLHgkE+rnyFnDxHgepUH3eOoaLw8fLqzfULe5E8iC/QnfA /wt847LcVFJ4zorxpmT95ehoA5QTDASmxWfbePV9tEy8GVROavWFmaGpRHQKPdmlEEnu 2D/RK+IhjaH//beIZzo7qynRk5n1K7pKERnDuUvqi9fDCREg33aZ08bODXdBJLK/5NKA YktdWT58OP+5godCjewuU2aClZg3v2pOWAC7lCnAz8OVZvL5ThPpls8nggFhbZLetvX5 TQBfVQGPGpDc5Higw59Q/QMDLTkwwE85/cBqSt7l78r+bq577OSQNNtYmtdpJPjLOidR dJsA== 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:from:date:message-id:subject :to; bh=Pw4Eijt6MABrSeeZF0UkA8LHqDES+ZofU7sl28iu7ec=; b=UJ3mwbzCEgn8TIXLxy7KPJWeeOSePv7SORiTv3LIa0tB80IbaaFF0uBT1EWOW9XkfF EcRpWiN90sT97OGhsJiDgVmwoL5sSsUHW/KHhppue7LoGGJ5G+OndyOdPpfhcTuO62ee /9BFRbLixFQMfA/9FoKylZISrxV4foTCIgIKbYidkcDiOzQJcNzTkT1MEroEcRmam5KX s8tJMyrJdC78eT6FnUSFUqkh0BQ1u1hPjwvKsrOegzUKkIupT4yEMfmzyE+kAEsktWsU ZkRB1yP9t5UDmLPLlOVZcg+RVfj49uq7ms3cwTqOaEW4V9o4NK1bAPK+PFZMnXqK5ijy P6MQ== X-Gm-Message-State: AODbwcBUQwiVn7tGdhiV1pJZkPUA+kCQOJkUVxHf46E/9I5O84jBa3rv K5vNPgd/6uDQhPBYtUuQsdQnv4cIOg== X-Received: by 10.55.163.88 with SMTP id m85mr17069334qke.118.1496076556117; Mon, 29 May 2017 09:49:16 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Mon, 29 May 2017 09:49:15 -0700 (PDT) From: Barry Leiba Date: Tue, 30 May 2017 01:49:15 +0900 X-Google-Sender-Auth: 64mHNteDGszb0FSMEl6kdWZFmP0 Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 29 May 2017 16:49:18 -0000 We've had one request for a DMARC session in Prague, with no further response from the working group. We've had one suggestion for an interop test in Prague, with no further response from the working group. I would like to schedule a session -- at least a short one -- but I'm not going to do that unless I hear from some people that (1) you'll be there and (2) we have something useful to discuss face to face. We have to decide by Friday (so, hey, let's say Thursday to be sure we don't forget). Barry, as chair From nobody Mon May 29 18:41: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 67A87126CF6 for ; Mon, 29 May 2017 18:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YcZg1raRkAPG for ; Mon, 29 May 2017 18:41:37 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 3FB0E129B3C for ; Mon, 29 May 2017 18:41:37 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p85so38267689vkd.3 for ; Mon, 29 May 2017 18:41:37 -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=jOB/dornDe3d7FNstbIeNNFMNGVsQTUaDVB4AfMvzCA=; b=Mt+Rlv09ok4EbQ3VdPr6ngi9S89JMV0bLRWPZOYwxAIQ2q/Q/poAZVtU1h7HWPv9Lf jGIQ5hXSVoP8z9/EV6N1loF4BylfCkOubHFK141+NgY9L1AkNpUeXZtuanMyW8etEA51 owW/IR5hEsn1Xo66+Z86nkKakZYvxb1JceH+8= 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=jOB/dornDe3d7FNstbIeNNFMNGVsQTUaDVB4AfMvzCA=; b=B02tU+88+29Q1MI91xvhW9Sl/XOmUOzJHCB5cZJYl/5cUgGNX5SemzV+2SasbiVB+g Xnh6Nyuw2skZcGJvYn1xg3EHf5WCWaPhgVqQ6UCItRYkSaMOUtNhobzvp7Y3T2Y+p6tt qPWVDKXGkkf0LVBgGtm0TPsUK3Iq4n0AoYGqVAT2X0/MYPrEByXBgXmlLz0zepzL6PVG ufVevWQSSIuBXrF5UnxeIF/Th0qT4OLs+unu8qm1FnGOIcyEPDSN2/Snr4bOAaOnaLf7 sXGWGAyuKCTsQmSu1tz9WSTmOevfbeh20oeZCnlIvJUeBxnk2Q9LyNRDlxJ6TBMUy8ko nx2w== X-Gm-Message-State: AODbwcBdawHRCQcnfpqHTnL/x0M+Qm89MF203swnqbVTZeL8a59jN3pS gnHN0Dmqz1OQcoQygeAEtlJAs/LwLGU+ X-Received: by 10.31.61.7 with SMTP id k7mr8355942vka.82.1496108496201; Mon, 29 May 2017 18:41:36 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.77.149 with HTTP; Mon, 29 May 2017 18:41:35 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Tue, 30 May 2017 09:41:35 +0800 X-Google-Sender-Auth: ZeZu9Su9qoQBg21Aw_D0R-76qto Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114da1e27649480550b3e724" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 01:41:39 -0000 --001a114da1e27649480550b3e724 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 12:49 AM, Barry Leiba wrote: > We've had one request for a DMARC session in Prague, with no further > response from the working group. > > We've had one suggestion for an interop test in Prague, with no > further response from the working group. > Yes to both. AFAIK, Steve Jones has been in touch with the hackathon organizers to have ARC added to the slate. Both Steve and I will be coming to Prague and several others from the group are expected as well. We also want to meet with the IETF tools folks to arrange an assisted upgrade to the IETF listserv to enable ARC signing. >From my POV, the ARC spec is close to "done". There are a few details that are turning up from new sets of eyes looking at it as implementations are built but so far, nothing substantive. I'll have new versions after my flights at the end of the week (protocol & usage). To me, the biggest point of discussion has to do with the hypothetical next milestone for the group which is currently called out as "document[ing] operational practices..." (the _Draft Guide on DMARC Usage_). While I understand that was viewed as "something that we could do" when the group was chartered, I doubt the need for it as an IETF document as time has passed. I think that discussing the next steps of the group would be apropos in a F2F meeting. --Kurt --001a114da1e27649480550b3e724 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 30, 2017 at 12:49 AM, Barry Leiba <barryleiba@computer.org> wrote:
We've had one re= quest for a DMARC session in Prague, with no further
response from the working group.

We've had one suggestion for an interop test in Prague, with no
further response from the working group.

Yes to both. AFAIK, Steve Jones has been in touch with the hackathon orga= nizers to have ARC added to the slate. Both Steve and I will be coming to P= rague and several others from the group are expected as well. We also want = to meet with the IETF tools folks to arrange an assisted upgrade to the IET= F listserv to enable ARC signing.


<= div>To me, the biggest point of discussion has to do with the hypothetical = next milestone for the group which is currently called out as "documen= t[ing] operational practices..." (the _Draft Guide on DMARC Usage_). W= hile I understand that was viewed as "something that we could do"= when the group was chartered, I doubt the need for it as an IETF document = as time has passed. I think that discussing the next steps of the group wou= ld be apropos in a F2F meeting.

= --001a114da1e27649480550b3e724-- From nobody Tue May 30 08:00:04 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 A5E3C1293E3 for ; Tue, 30 May 2017 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andreasschulze.de 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 Vav1ajO9vN2i for ; Tue, 30 May 2017 08:00:00 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA114127B57 for ; Tue, 30 May 2017 07:59:59 -0700 (PDT) Received: from [IPv6:2001:470:77b3:50:4145:28f2:a5f0:2073] (unknown [IPv6:2001:470:77b3:50:4145:28f2:a5f0:2073]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3wccGN2q9LzDdv for ; Tue, 30 May 2017 16:59:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1496156396; bh=f25Ay3lpnX8x9/+dK25kG4OKcdgTRbygS49mZKP//PE=; h=Subject:To:References:From:Date:In-Reply-To; b=XBz+Fuz9sP9m1f2AYlheBt9bWRgiDU0es9e74TnRXomFyJCbGwu4wq4E21Il4NJHL oqKM97cBDwkWlYdhLCb/IL/WesncYDgrn/0tqSDYpJxfws2h1igO8jF250ron9NyM7 Vry4E8+CKt3VIKeHyyeMQpizJqtlQQKYgvgO1GjLr69AlhLpHyHQsCJ41rDUrBHS+J rTx3j/tHiKpZlpXyc1dmnMWqZsA0pU6c0AlgPBkz2ti9IahXM6ppBqURMgGb71kwvd vVBp+vh+3n0i9OD4dASWo2TomR0carVamNxxrKg+mDj6yU+EIeuXmzjzSajmVxD5FL ko+oto8yL8+uw== To: dmarc@ietf.org References: From: "A. Schulze" Message-ID: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> Date: Tue, 30 May 2017 16:57:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 15:00:03 -0000 Am 29.05.2017 um 18:49 schrieb Barry Leiba: > We've had one request for a DMARC session in Prague, with no further > response from the working group. I didn't follow all ARC discussion over the last months. An update is welcome. Also it would be helpful if Murray could give an update on his openarc project. I would welcome a F2F meeting is welcome could push ARC implementations aside the usual big player. If there would be a meeting on Monday/Tuesday a travel to Prague would be valuable to me, while I'm sure I'll see some of you soon in Lisbon :-) Andreas From nobody Tue May 30 08:03: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 EBA53128CDB for ; Tue, 30 May 2017 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 pK2iAVUll5dj for ; Tue, 30 May 2017 08:03:49 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 B281C127B57 for ; Tue, 30 May 2017 08:03:49 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l18so114630382oig.2 for ; Tue, 30 May 2017 08:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=o2GTIUazb84CbwLJxDagxrnj6B7K1vIXvqywrCR3Bhg=; b=ZeHsqboB+xVVB4u+RVfbw0sMO+9u33kJO6m8gL0kXrgzowAnVFIhijYuHo6/P5prWF UY3RelVm32CeQen6fw+kuPZrJnG/ZX+4V6iD5jv8wOpKTUChAGqwFk0G64AXNKPI1kjL 0KTbRl/ld8OwdTjK2nteMWr5QaO7L6VB05nsIy5+hNZtGC6gOeU/oMpgrNOQy7j8PYGE hEdf8XWMqbMDodPNbM7ctRAZru4FcwHnwiZr0xRq1E0UqqZ4AGaY+Lh8gy9ULbCJYoHj LHsLI1LV8Zo1HkucWxD03Q/80+/3ki0HzX/iTJdL3jn6uRhRylZqJVTGNLK/S3bEs1DP bBOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=o2GTIUazb84CbwLJxDagxrnj6B7K1vIXvqywrCR3Bhg=; b=Q0/PicNF1/z7o0tsrErrWJUncruPKQb77eaGhw22MitT1Vy221yaag3pQi7BbnwRBo n9x9uEkn/yskXoHzbEAoHc4j7YIcvlAQM0W5u/Tpz22XOoMZ1S7vlSQZM3Myzmi6fqQI SDyEec7dPMeCKoWTuV0NkPTx2qh7T+7t9CcJ6HxKuRMtIVUWnXyZe9M++lpQV2IJsPaR VlLE1fIU8AQNlBZeLXIeMujji1yLHszESJyapNca+0e4ZvUKCX0uLlgT08noMbOs/Qyu EZPkBgtL9+EGF3PkHpH94rMOg3of6f7h53Q4DydZbv+6iBvg5LIEDsCiLiqSPdH0AaTw TvMg== X-Gm-Message-State: AODbwcBmWWSpBxQ2T1PFGeGVA3ZTjMN6zfc6XizMlDcGRlHdpOUfKeNr eWiWyHJlhChwDgmrgyw= X-Received: by 10.157.29.235 with SMTP id w40mr10501899otw.128.1496156628937; Tue, 30 May 2017 08:03:48 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id y31sm5806635ota.47.2017.05.30.08.03.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:03:47 -0700 (PDT) To: dmarc@ietf.org References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> From: Dave Crocker Message-ID: <8f2ada89-1473-a044-8492-eb17316f7ae9@gmail.com> Date: Tue, 30 May 2017 08:03:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 15:03:51 -0000 > didn't follow all ARC discussion over the last months. An update > is welcome. Also it would be helpful if Murray could give an update on his openarc project. However IETF face-to-face meetings are not for reporting. They are for working to resolve outstanding issues. Reporting can be done on the mailing list, more easily, more completely, and far less expensively. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 30 08:10:45 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 C62E1128CDB for ; Tue, 30 May 2017 08:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=yitter.info header.b=PxzhKJtD; dkim=pass (1024-bit key) header.d=yitter.info header.b=TCJz+cVN 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 2UFpMv980WpT for ; Tue, 30 May 2017 08:10:42 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE44127B57 for ; Tue, 30 May 2017 08:10:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 77CEDBE229; Tue, 30 May 2017 15:10:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1496157011; bh=0AmPKavCztpfwpVOwYkMCplZ/iwNVY4jTqZNoU/PBu8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=PxzhKJtDzPVu778o064nECnwD5Jw2PneVdGhsrn0x+b1QOzAoXQrbw9tPQnL7CdBI wgHd35a3KH3xDFgeuA3q5GAUx6eId6xMwLIJU/XWSdFrgZfnl6hoTTddksZc5Fnc5j 4MiuuEf6nHUiqbGPtzcDlQ74XfZR3OHkBym9/ET8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYYyOI3HjHZ8; Tue, 30 May 2017 15:10:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1496157009; bh=0AmPKavCztpfwpVOwYkMCplZ/iwNVY4jTqZNoU/PBu8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=TCJz+cVNouYVt7xBPNp8T5sj6BM3tpZcFl76Qb0/BPMAuu+fLvzViAnB+3Rq+TE4u xI8JEbGdeXuHsa70DgCaVOPuXgDYZd5Gzn6PHFh3PC4OPGuND0EONM108GAWjnWcW8 FLgFrw/oPKU/jFplxLvy9SWSNkh6cBVWJwzuyA2o= Mime-Version: 1.0 (1.0) From: Andrew Sullivan In-Reply-To: <8f2ada89-1473-a044-8492-eb17316f7ae9@gmail.com> Date: Tue, 30 May 2017 11:10:08 -0400 Cc: dmarc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> <8f2ada89-1473-a044-8492-eb17316f7ae9@gmail.com> To: Dave Crocker Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 15:10:44 -0000 I strongly agree about the "not for reporting" part, but what probably would= be good is to get such reports now, so that one might tell whether there's a= previously-unnoticed issue with ARC as there turned out to be with DMARC. I= f there were such an issue, a meeting would be a good idea.=20 Best regards, Andrew (mostly watching from the cheap seats) --=20 Andrew Sullivan=20 Please excuse my clumbsy thums.=20 > On May 30, 2017, at 11:03, Dave Crocker wrote: >=20 >=20 >> didn't follow all ARC discussion over the last months. An update >> is welcome. Also it would be helpful if Murray could give an update on hi= s openarc project. >=20 >=20 > However IETF face-to-face meetings are not for reporting. They are for wo= rking to resolve outstanding issues. >=20 > Reporting can be done on the mailing list, more easily, more completely, a= nd far less expensively. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue May 30 09:35:15 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 722CE129A97 for ; Tue, 30 May 2017 09:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=valimail.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 cYF4QQ56nmES for ; Tue, 30 May 2017 09:35:11 -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 75E4B126CD6 for ; Tue, 30 May 2017 09:35:11 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d14so32918399qkb.1 for ; Tue, 30 May 2017 09:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yl3LMB5CPPXOCfXxtH4f5eOpHVH1B4nC6XXpWGqLtzE=; b=fWFZVxJxjnsOw0XAFDFGogDd6HJxHgecil0byMwk6fll2ALEAGDKiNaR5Lgtd7YFYu FMCmTispw+Ik3+6OI1Gi9426+eAivHVOfXXpyLLoxu4mZK5wmHwrlD95VJjYFoSaNLDc efi/ZGqaaMwi+AxoOv+ST6Etqp9CDfpBw2rNLck4RZW2Ue+Dmak8MXocwAiA8MbW7I2w CcY98niNcKDAS4THagYQzYv5EQd6J0Xt+5MOjPnzUYcFVisN0OBVx2smv0IXFIRoYqj1 V1W52gSIi8Oo4irhL6p0Od3snkz/PHcQch6krVkqAEfHpR6fmyafl1tVEeu9PXIECsWP 8UuA== 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=yl3LMB5CPPXOCfXxtH4f5eOpHVH1B4nC6XXpWGqLtzE=; b=GUrujELr9yzRy59DH/UZ1zEv29Medw+qpYgas4fkX37daG3DUDMmkF38B3bzBPaV3z 1TIC6WOIaPK48wtCWlmVpXE9SdSKQQNXbROF/rYfP0ZtZSnYiKx4gapGT0TTUX+j8cop kBGK7yGADJH/Cz1ZI0PFOuQPKhWwXkrh2sQ+j0N1hkElkp7a8zfT1BEJV6ha2bES2ATb bWgt7dAKYW/Vh9nOYUPlwftnRJSHm2hC5uqcVm0F9QaOZ7W84UuQ8gFgrDKljFT7tGpg q+DUrRUh+m0UVKFg5j/qHS8R7zckRND63JWWb0s1N0zdLvYE7/b0pAsV+iDPp8Y6/IK8 GeXg== X-Gm-Message-State: AODbwcBhXE7Mt8dVzp6f4mQCOVTaEzZucMW4pImISjWsTOgur6vqM8s5 f+7ztASkMqy7Una71iYU3v1K2l/WqMe+qI4= X-Received: by 10.55.27.97 with SMTP id b94mr9776486qkb.169.1496162110359; Tue, 30 May 2017 09:35:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 09:34:49 -0700 (PDT) In-Reply-To: References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> <8f2ada89-1473-a044-8492-eb17316f7ae9@gmail.com> From: Seth Blank Date: Tue, 30 May 2017 09:34:49 -0700 Message-ID: To: dmarc@ietf.org Cc: Andrew Sullivan , Dave Crocker Content-Type: multipart/alternative; boundary="001a1147f09e1d5a4d0550c063a2" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 16:35:14 -0000 --001a1147f09e1d5a4d0550c063a2 Content-Type: text/plain; charset="UTF-8" We've been working with Murray to get OpenARC to completion. As we near the finish line, a few nuances in the spec have raised concerns, everything has been brought to the working group. I don't think any of these fall into "unnoticed issues," just matters that still need resolution. Open items: - AMS header/body canonicalization (spec says header=relaxed, body=[c value] - should both respect c?) - Should d= and s= be in agreement between AS and AMS - Clarification of why AARs should be covered by the AMS, and if guidance is needed in spec Resolved items: - Handling of multiple incoming AR headers (resolved, but language not yet in spec) - Do we need an arc tempfail concept [rough consensus appears to be no] Beyond that, I'm bringing one more item to the list shortly regarding authentication-results stamps for ARC. For DMARC, I believe the critical issue is how to move the DMARC spec to standards track. Seth On Tue, May 30, 2017 at 8:10 AM, Andrew Sullivan wrote: > I strongly agree about the "not for reporting" part, but what probably > would be good is to get such reports now, so that one might tell whether > there's a previously-unnoticed issue with ARC as there turned out to be > with DMARC. If there were such an issue, a meeting would be a good idea. > > Best regards, > Andrew (mostly watching from the cheap seats) > > -- > Andrew Sullivan > Please excuse my clumbsy thums. > > > On May 30, 2017, at 11:03, Dave Crocker wrote: > > > > > >> didn't follow all ARC discussion over the last months. An update > >> is welcome. Also it would be helpful if Murray could give an update on > his openarc project. > > > > > > However IETF face-to-face meetings are not for reporting. They are for > working to resolve outstanding issues. > > > > Reporting can be done on the mailing list, more easily, more completely, > and far less expensively. > > > > d/ > > > > -- > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1147f09e1d5a4d0550c063a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've been working with Murray to get OpenARC to = completion. As we near the finish line, a few nuances in the spec have rais= ed concerns, everything has been brought to the working group. I don't = think any of these fall into "unnoticed issues," just matters tha= t still need resolution.

Open items:
- A= MS header/body canonicalization (spec says header=3Drelaxed, body=3D[c valu= e] - should both respect c?)
- Should d=3D and s=3D be in agreeme= nt between AS and AMS
- Clarification of why AARs should be cover= ed by the AMS, and if guidance is needed in spec

R= esolved items:
- Handling of multiple incoming AR headers (resolv= ed, but language not yet in spec)
- Do we need an arc tempfail co= ncept [rough consensus appears to be no]

Beyond th= at, I'm bringing one more item to the list shortly regarding authentica= tion-results stamps for ARC.

For DMARC, I believe = the critical issue is how to move the DMARC spec to standards track.
<= div>
Seth

On Tue, May 30, 2017 at 8:10 AM, Andrew Sullivan <a= js@anvilwalrusden.com> wrote:
I strongly agree about the "not for reporting" part, but what = probably would be good is to get such reports now, so that one might tell w= hether there's a previously-unnoticed issue with ARC as there turned ou= t to be with DMARC.=C2=A0 If there were such an issue, a meeting would be a= good idea.

Best regards,
Andrew (mostly watching from the cheap seats)

--
Andrew Sullivan
Please excuse my clumbsy thums.

> On May 30, 2017, at 11:03, Dave Crocker <dcrocker@gmail.com> wrote:
>
>
>>=C2=A0 didn't follow all ARC discussion over the last months. A= n update
>> is welcome. Also it would be helpful if Murray could give an updat= e on his openarc project.
>
>
> However IETF face-to-face meetings are not for reporting.=C2=A0 They a= re for working to resolve outstanding issues.
>
> Reporting can be done on the mailing list, more easily, more completel= y, and far less expensively.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.= net
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc=

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a1147f09e1d5a4d0550c063a2-- From nobody Tue May 30 09:39: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 D1FA5129687 for ; Tue, 30 May 2017 09:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 uOv84x5txN0W for ; Tue, 30 May 2017 09:39:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D95612954D for ; Tue, 30 May 2017 09:39:11 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 68269C4010C for ; Tue, 30 May 2017 11:39:10 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496162350; bh=8sBe1ZTcWei6g+TJskgBEHZhDgZnwPiKlhd+QkIXaXY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nBvzzxtLgF66L++7PJ4n50MpYP+eBqyN79s7NlSTMvs9StGDkK4zK3aT26Z62paPO Z1ydaOiwqa0etFYqW88MVpLxgGNt5xajAgjgvaXKWTHkcZr1thQZoWpTvsymzRyo6P y6tOIATmkg3iF0wwFvNw95EPW1OihQuxU7HJUcX8= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 30 May 2017 12:39 -0400 Message-ID: <1825403.c0G1ymGnF3@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 16:39:13 -0000 On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > Resolved items: > - Handling of multiple incoming AR headers (resolved, but language not yet > in spec) If this is resolved in favor of not handling multiple AR header fields (which IIRC is the plan), then something needs to specify the combination is required. I think that something needs to be a DMARC document, not ARC, because this is a requirement that's being imposed on all DMARC AR header field providers regardless of if they care about or participate explicitly in DMARC. Scott K From nobody Tue May 30 10:14: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 D4381127337 for ; Tue, 30 May 2017 10:14:32 -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 (2048-bit key) header.d=valimail.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 wlMmDUhXF58P for ; Tue, 30 May 2017 10:14:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 9FB621201FA for ; Tue, 30 May 2017 10:14:29 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y201so73945713qka.0 for ; Tue, 30 May 2017 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to:cc; bh=BgrQHmK/KLK8qacneX3SOc/RLxwmq5F65WAWXZOn/Dc=; b=TUJNWRdSzkIPFBhT+RxqxfjsOUB/D7HBU4jtk53PCWI+y41vv7X0QorNmsCqH/Vt4q qb8DvpDeCrTF/NJQPDU+3hlkQKNX40p8NBbtOrSXyuKEgJDz4hDu0JXuasoF/3sBuDhw jt1WHS2QTxP/mQixMxGbxeuICoSfyiXvvQjE1DuNvxenW5UVUYqy3Nq2ukvwD1T9flkL QNv8QIsmzCLjDjTyp9vj5r0fc6Reg6hJG76RugiJM/g2Sb7b0+CK8Kp6rKXpSBj854ek 66IQjVL8gjMOAnRJvbcPSawt8PvX4hx2RDcjVHqj2Lr01AFAUWjTzFwLnBPv58lWcA5C YDcA== 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:cc; bh=BgrQHmK/KLK8qacneX3SOc/RLxwmq5F65WAWXZOn/Dc=; b=WZCYS18Nox6Edn0x+ud2wbr6voJvh6MnQtSRQ4YEew9+yR4y0JFAsNaKOOHCmSANS9 Sg9UvQyVIlgQASH3unsk0AAxLv8Mr1h+tQsUDWzGIF3cIoHNxUoW+xf3gT7yh98iPW4s oRlJ6xXi/vtUK7VRT0aybuBJ49w77xQmF60d7SgDS5+v2g7rh6daXY81zHIR7QTCYeDp oX9nx2OeKxoxWBWi2WmQ4MUIchXaZrB7k5rGZu/r3sqJ+kpmqhNaxG9o4myrqeN+CNa/ fbqE8jWDbDp5wCpegDGFpRwGnKbJ9jcvGTjGIcHTTNZV66QNa7jt6OsvCYs6BGhK3w1T G1hA== X-Gm-Message-State: AODbwcCcJS2VIt5+ZdMCoHCTliaRut+bP4XJ+MrMOub/6lnCifAlp7cV s8nr/pVf5cmr2pCcOzifpjPoN5txib20yuZ0YQ== X-Received: by 10.55.25.41 with SMTP id k41mr22555492qkh.163.1496164468573; Tue, 30 May 2017 10:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 10:14:08 -0700 (PDT) From: Seth Blank Date: Tue, 30 May 2017 10:14:08 -0700 Message-ID: To: dmarc@ietf.org, dmarc-dev@dmarc.org Cc: Kurt Andersen , Murray superuser Kucherawy Content-Type: multipart/alternative; boundary="001a1147da42aced670550c0ef46" Archived-At: Subject: [dmarc-ietf] Authentication-Results stamp for ARC 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: Tue, 30 May 2017 17:14:33 -0000 --001a1147da42aced670550c0ef46 Content-Type: text/plain; charset="UTF-8" The current spec defines an arc authres method (https://tools.ietf.org/html/ draft-ietf-dmarc-arc-protocol-03#section-8.1). We believe there should also be registered ptypes and properties, that should be stamped (but are not required, as they won't always be available). As long as AR stamping happens at the end of chain validation, when an ARC set gets created this stamp will be included in the AAR, and AAR construction can be clean with no additional language or requirements necessary in the spec. What follows below is not sacred, we're just trying to start the conversation. Based upon previous threads (specifically, Brandon's reporting local_policy thread from May 4th PST) surrounding the AAR and data the WG thought would be valuable for final receivers and DMARC reports, it looks like stamping header.b for each dkim signature on the message and smtp.client-id for the ip address of the originating mail server (if available) would provide nearly everything asked for with minimal implementation overhead (and no change to spec except for the IANA registration, and an addition for RECOMMENDED stamping if warranted). To dig in to the reasoning behind these two properties: 1) header.b At the end of an ARC chain, there might be many DKIM signatures on the message, nearly all of which could be broken on receipt. Additionally, since there have been multiple hops, it is possible to have several broken DKIM signatures with the same header.d value that are representative of different services at different hops. If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of every dkim key on the message, then it becomes super clear which keys were added when, and which dkim pass/fail statuses correspond to which keys so it can be determined when any individual signature broke. This is extremely useful as a reporter to help identify broken services at any stage of DMARC enforcement, and is probably useful for final receivers reviewing the chain to determine final message disposition; without this information all the DKIM-Signatures on a message that do not validate and share the same header.d are indistinguishable. This stamp removes this ambiguity and adds reporting and trace value. 2) smtp.client-id The goal here is to track the originating source_ip for DMARC categorization and reporting. Otherwise, all ARC messages will have a DMARC report source_ip of the last forwarder, not the originating service. This will be exceptionally confusing to consumers of DMARC reports. We know that including an IP address in Authentication-Results has been persona-non-grata in the past, as authentication results are supposed to encapsulate the results of an authentication check, not information that could be used to re-run the authentication downstream. However, we believe that the client-id is vital trace information for ARC and DMARC, is useful for categorizing senders within a DMARC report, and is valuable at p=none, p=quarantine, and p=reject, and as such makes sense within and contained to the ARC stamp. Ultimately, if this stamp is wrong for the AR, the client-id could be added directly in the AAR. The AR stamp is cleaner because it leaves the AAR generation and spec untouched. We know there will be disagreement about what to stamp, and welcome discussion on what's best to track within an AR header as arc status. I'm happy to suggest language once there's rough consensus in the group. Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1147da42aced670550c0ef46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current spec defines an arc authres method (https://tools.ietf.org/html/draft-ietf-dmarc-ar= c-protocol-03#section-8.1).

We belie= ve there should also be registered ptypes and properties, that should be st= amped (but are not required, as they won't always be available).

As long as AR stamping happens at the end of c= hain validation, when an ARC set gets created this stamp will be included i= n the AAR, and AAR construction can be clean with no additional language or= requirements necessary in the spec.

What fol= lows below is not sacred, we're just trying to start the conversation.<= /div>

Based upon previous threads (specifically, B= randon's reporting local_policy thread from May 4th PST) surrounding th= e AAR and data the WG thought would be valuable for final receivers and DMA= RC reports, it looks like stamping header.b for each dkim signature on the = message and smtp.client-id for the ip address of the originating mail serve= r (if available) would provide nearly everything asked for with minimal imp= lementation overhead (and no change to spec except for the IANA registratio= n, and an addition for RECOMMENDED stamping if warranted).
<= br>
To dig in to the reasoning behind these two properties:
=

1) header.b

At the end o= f an ARC chain, there might be many DKIM signatures on the message, nearly = all of which could be broken on receipt. Additionally, since there have bee= n multiple hops, it is possible to have several broken DKIM signatures with= the same header.d value that are representative of different services at d= ifferent hops.

If each hop s= tamps the https://tools.iet= f.org/html/rfc6008 header.b of every dkim key on the message, then it b= ecomes super clear which keys were added when, and which dkim pass/fail sta= tuses correspond to which keys so it can be determined when any individual = signature broke.

This is ext= remely useful as a reporter to help identify broken services at any stage o= f DMARC enforcement, and is probably useful for final receivers reviewing t= he chain to determine final message disposition; without this information a= ll the DKIM-Signatures on a message that do not validate and share the same= header.d are indistinguishable.

=
This stamp removes this ambiguity and adds reporting and trace value.<= /div>

2) smtp.client-id

The goal here is to track the originating=C2=A0source_ip for DMARC categor= ization and reporting. Otherwise, all ARC messages will have a DMARC report= source_ip of the last forwarder, not the originating service. This will be= exceptionally confusing to consumers of DMARC reports.
<= div>

We know that including an IP address in Authentication-= Results has been persona-non-grata in the past, as authentication results a= re supposed to encapsulate the results of an authentication check, not info= rmation that could be used to re-run the authentication downstream.

However, we believe that the client= -id is vital trace information for ARC and DMARC, is useful for categorizin= g senders within a DMARC report, and is valuable at p=3Dnone, p=3Dquarantin= e, and p=3Dreject, and as such makes sense within and contained to the ARC = stamp.

Ultimately, if this stamp is wrong= for the AR, the client-id could be added directly in the AAR. The AR stamp= is cleaner because it leaves the AAR generation and spec untouched.

We know there will be disagreement about wha= t to stamp, and welcome discussion on what's best to track within an AR= header as arc status.

I'm happy to suggest la= nguage once there's rough consensus in the group.

<= div>Seth

--

3D"logo

Br= inging Trust to Email

Seth Blank | Head of Product for Open Source and Protoc= ols

seth@valimail.com
+1-415-894-2724=
--001a1147da42aced670550c0ef46-- From nobody Tue May 30 10:14:55 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 0732B12945E for ; Tue, 30 May 2017 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 7l4-idKYDNau for ; Tue, 30 May 2017 10:14:52 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559CA126C26 for ; Tue, 30 May 2017 10:14:50 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id t26so75415855qtg.0 for ; Tue, 30 May 2017 10:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uT1D4THIHypFnUnBgwwqH4bp5xrK5GyZV18IsoUx0OE=; b=Jd1sET0yI4igz3r58aIPzO2W6si8BTHTikVodL1vhMRG06HmblqFw58QopX7TDpAic mEPbVyzgxngkPMaZ3sen865jNEh8XN3edAHEAZEJYN2H1vQx3NYjMvBvf6H81Z6Dl1O5 RYd3H/0aRpnIXNiggJuNWLcLJ94F8oes8Xp6Drh6RdhzdmEgzwsj83TrIogVxSo1Kq9b SbA461aQJ3bvr058Nw82sKjOhSSTSkgcjZciXknQXl9dEInNFSiARYgvihoXHOqEEQRq LmKcmgYPYSsEj8CrASnKOybRE7TY5gNGE4qu4N0+ijJ1jA6RPIgIYvfParTcCBv7ZOLJ XXjg== 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=uT1D4THIHypFnUnBgwwqH4bp5xrK5GyZV18IsoUx0OE=; b=WmnPYHu3q9akC4O9zrA0iucSFzJ8Y7le7+OCZgW+E+6RKj6IJvvtMVOCy6BLJYBDEj di783q8TQKKDusqzaevHe5u+viOo0vZumKlBR5rllt947DKrhXwjNyqMfWoZeZzorxMp 3hz6PUWpu0Ujtp1AAQWU4mKABPnbjfL4FjyV4Nq/cGd13+WcXkcHwRXQgf0YQvEDbp44 lMF8SpCphOtXz7kqBoDLFFkY25yY3Am45mFOffHQA7C7AWA217A5isIbOSulDtHyFSQ7 SMvQXtjtcMHqaTRyjFSo3rt+VStSij/fG0pbZwb2IXOl5sdkFWpVhEJGkNbmrM9N0DZL eOLg== X-Gm-Message-State: AODbwcBrlMJbP6WqQ0e2MMOZbIXi6OXTeOatNZrxl+EFcrsNT8THB9ho tiuMNC0x3Hu7gLBKnWQ/IdYFVstqRa0raGY= X-Received: by 10.237.34.119 with SMTP id o52mr26950262qtc.217.1496164489484; Tue, 30 May 2017 10:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 10:14:29 -0700 (PDT) In-Reply-To: <1825403.c0G1ymGnF3@kitterma-e6430> References: <1825403.c0G1ymGnF3@kitterma-e6430> From: Seth Blank Date: Tue, 30 May 2017 10:14:29 -0700 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a113e83f2ebef4d0550c0f0b8" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 17:14:54 -0000 --001a113e83f2ebef4d0550c0f0b8 Content-Type: text/plain; charset="UTF-8" [Taking my reply to the initial thread so not to clog this one] On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > > Resolved items: > > - Handling of multiple incoming AR headers (resolved, but language not > yet > > in spec) > > If this is resolved in favor of not handling multiple AR header fields > (which > IIRC is the plan), then something needs to specify the combination is > required. I think that something needs to be a DMARC document, not ARC, > because this is a requirement that's being imposed on all DMARC AR header > field providers regardless of if they care about or participate explicitly > in > DMARC. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113e83f2ebef4d0550c0f0b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Taking my reply to the initial thread so not to clog this= one]

On Tue= , May 30, 2017 at 9:39 AM, Scott Kitterman <sklist@kitterman.com>= ; wrote:
On Tuesd= ay, May 30, 2017 09:34:49 AM Seth Blank wrote:
> Resolved items:
> - Handling of multiple incoming AR headers (resolved, but language not= yet
> in spec)

If this is resolved in favor of not handling multiple AR header fiel= ds (which
IIRC is the plan), then something needs to specify the combination is
required.=C2=A0 I think that something needs to be a DMARC document, not AR= C,
because this is a requirement that's being imposed on all DMARC AR head= er
field providers regardless of if they care about or participate explicitly = in
DMARC.

Scott K

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a113e83f2ebef4d0550c0f0b8-- From nobody Tue May 30 10:21:38 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 8C272128BBB for ; Tue, 30 May 2017 10:21:37 -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 (2048-bit key) header.d=valimail.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 jIibXpYAyYby for ; Tue, 30 May 2017 10:21:36 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33FE124BE8 for ; Tue, 30 May 2017 10:21:35 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id 19so8743044qke.2 for ; Tue, 30 May 2017 10:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MK6sMITXn0DRv/Xfgyl0uMfB6e853eLKLgsCx4QaE+s=; b=fnYhYthvq81mt35vYdflTPzdutYydROhy1trJ6a8PZ2h15SME3ZqThbRNDrEMq/StF zdTJdJnx98kAQFsqs0mNYj2FQbMXFA2t6NIRPDz+EPfr6GsQq3tpjnTSQaaf2WAV8EsA jCiCDVHm9gJW91JX8rN+WJSHpES2jK+DKuSb3KnfG2qFWUMZ3WbMLrjhYsJ5P3xE33cC 9cUgJ+FDHdnAuQtviFKCt5A9BCQVPY4m+owxrZ0JBhw6r7dDF3afW2wn4OEbl1XIjuDL UoQKQYPed+h7YaCdqGMRzgamB3kjTBAGl4dcQKqBTsDrGlMnL3BjiTLBFiasgTCRzg8r YuxQ== 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=MK6sMITXn0DRv/Xfgyl0uMfB6e853eLKLgsCx4QaE+s=; b=bs/MJW7AspkwaY5KHbX+aZnKycafFS2A10sXeIM0Jvx5shQVpvj4KhwV9q0RziDmzY GnuxQ/ITWHtJOL6bmaeAIDYoA29jKy7t1fAAsQk5WCAsYNkOphIOsHKmxgoWFnU/koVO DaqRZn/EoUZAqSzec16HV5meAfRleqSA9l9UqcEJBjNq52BvakwKycqtGQLnvagS42tn IHxBiQTfF1uhTS216WF8Ub/CA42RFakWlsk6rKEGSA8L1cZMINYxVdkGwt4mHTxM7wEj EoczptQXc89iBhDd/65iv2g6iydQB/rnUHImHAO0X+wvQIc+lyAJEnS7kkI/UwslwDE+ K++A== X-Gm-Message-State: AODbwcC95A1vczvgrZtkM9bLXjwrejQtQGKJ43ygv77e+yj+tWfkfo+R vM0pinfH1fu/NrB/Af1EYEfqDR1MSSZWnyFMtQ== X-Received: by 10.55.126.69 with SMTP id z66mr22327966qkc.137.1496164894735; Tue, 30 May 2017 10:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 10:21:14 -0700 (PDT) In-Reply-To: <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> References: <43d13efe-c0c4-62a6-490c-4e92eb265d65@gmail.com> <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com> <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> From: Seth Blank Date: Tue, 30 May 2017 10:21:14 -0700 Message-ID: To: dmarc@ietf.org Cc: Scott Kitterman Content-Type: multipart/alternative; boundary="94eb2c05a07c1391530550c10936" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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: Tue, 30 May 2017 17:21:37 -0000 --94eb2c05a07c1391530550c10936 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > > Resolved items: > > - Handling of multiple incoming AR headers (resolved, but language not yet > > in spec) > > If this is resolved in favor of not handling multiple AR header fields (which > IIRC is the plan), then something needs to specify the combination is > required. I think that something needs to be a DMARC document, not ARC, > because this is a requirement that's being imposed on all DMARC AR header > field providers regardless of if they care about or participate explicitly in > DMARC. I believe the consensus in this thread was about adding the following sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf- dmarc-arc-protocol-03#section-5.1.3 , with added clarification that we're only talking about the current AAR[n]: "The AAR should contain all Authentication-Results results from within its ADMD, regardless of how many Authentication-Results headers are on the message." I don't think this needs a separate document, as I think it is very ARC specific because it's only about construction of the AAR header and making sure the proper information gets into it (since multiple AR headers are a reality in the wild, we just need a sentence on how to deal with them). Or am I totally misunderstanding your point? Seth On Sun, May 28, 2017 at 8:53 AM, Scott Kitterman wrote: > > > On May 28, 2017 11:27:35 AM EDT, John Levine wrote: > >In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com>, > >>Nothing other than potentially ARC requires multiple AR header fields > >for different authentication types to be combined. These different > >>verification operations (e.g. SPF, DKIM, and DMARC) are generally > >performed be different processes that add their own AR field. > > > >Since DMARC needs the results of SPF and DKIM, how does that work? > >Does DMARC look at the A-R that the other two created or is there a > >side channel? It occurs to me that a DMARC process has everything > >needed to make a header that combines all three. > snip > > At least for OpenDMARC, if it's not doing it's own SPF check (which seems > odd to me because it's done after DATA, but it works), it will look at > multiple AR fields for both SPF and DKIM results. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c05a07c1391530550c10936 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <= sklist@kitterman.com> wrote:=
> On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote:
> > Resolved items:
> > - Handling of multiple = incoming AR headers (resolved, but language not yet
> > in = spec)
>=C2=A0
> If this is resolved in favor of n= ot handling multiple AR header fields (which
> IIRC is the pla= n), then something needs to specify the combination is
> requi= red.=C2=A0 I think that something needs to be a DMARC document, not ARC,
> because this is a requirement that's being imposed on all = DMARC AR header
> field providers regardless of if they care a= bout or participate explicitly in
> DMARC.

I believe the consensus in this thread was about=C2=A0adding the following sentence to the first paragraph of=C2=A0https://tools.iet= f.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.3=C2=A0, with added clarification that we're on= ly talking about the current AAR[n]= :

"The AAR shou= ld contain all Authentication-Results results from within its ADMD, regardl= ess of how many Authentication-Results=C2=A0header= s=C2=A0are=C2=A0on the message."= ;

I don't think this ne= eds a separate document, as I think it is very ARC specific because it'= s only about construction of the AAR header and making sure the proper info= rmation gets into it (since multiple AR headers are a reality in the wild, = we just need a sentence on how to deal with them).

Or am I totally misunderstanding your point?

Seth=

On Su= n, May 28, 2017 at 8:53 AM, Scott Kitterman <sklist@kitterman.com= > wrote:


On May 28, 2017 11:27:35 AM EDT, John Levine <johnl@taugh.com> wrote:
>In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com&g= t;,
>>Nothing other than potentially ARC requires multiple AR header fiel= ds
>for different authentication types to be combined.=C2=A0 These differen= t
>>verification operations (e.g. SPF, DKIM, and DMARC) are generally >performed be different processes that add their own AR field.
>
>Since DMARC needs the results of SPF and DKIM, how does that work?
>Does DMARC look at the A-R that the other two created or is there a
>side channel?=C2=A0 It occurs to me that a DMARC process has everything=
>needed to make a header that combines all three.
snip

At least for OpenDMARC, if it's not doing it's own SPF check (which= seems odd to me because it's done after DATA, but it works), it will l= ook at multiple AR fields for both SPF and DKIM results.

Scott K

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--94eb2c05a07c1391530550c10936-- From nobody Tue May 30 10:33:30 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 DD4C6129BD1 for ; Tue, 30 May 2017 10:33:29 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=kitterman.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 DiMsH0aI2ikk for ; Tue, 30 May 2017 10:33:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D844129ADA for ; Tue, 30 May 2017 10:33:28 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 14422C401F4 for ; Tue, 30 May 2017 12:33:27 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496165607; bh=iCHX7y3IG9cz0f3LFe0Y7LNkl5r4h9GnJI30EpXe4rI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CJIJl2OhNcA+M/ejzo8l5r0WomZe6nAphprrVocTUegPLdqkr83jna+NznButSgPj fccZ2wqX5kR9jMUzDTZjIEnT+TMW+y041mOHnshigXwDXtRzv1v5UQKlfmKA3piIs4 PV2JY8MaNSHzAWZsbgS/sje4QgDv3zpHzld7quuY= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 30 May 2017 13:33:26 -0400 Message-ID: <3073712.x93XL1H1LP@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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: Tue, 30 May 2017 17:33:30 -0000 On Tuesday, May 30, 2017 10:21:14 AM Seth Blank wrote: > On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman > > wrote: > > On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote: > > > Resolved items: > > > - Handling of multiple incoming AR headers (resolved, but language not > > > yet in spec) > > > > If this is resolved in favor of not handling multiple AR header fields > > (which > > > IIRC is the plan), then something needs to specify the combination is > > required. I think that something needs to be a DMARC document, not ARC, > > because this is a requirement that's being imposed on all DMARC AR header > > field providers regardless of if they care about or participate > > explicitly in DMARC. > > I believe the consensus in this thread was about adding the following > sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf-> dmarc-arc-protocol-03#section-5.1.3 , with added clarification that we're > only talking about the current AAR[n]: > > "The AAR should contain all Authentication-Results results from within its > ADMD, regardless of how many Authentication-Results headers are on the > message." > > I don't think this needs a separate document, as I think it is very ARC > specific because it's only about construction of the AAR header and making > sure the proper information gets into it (since multiple AR headers are a > reality in the wild, we just need a sentence on how to deal with them). > > Or am I totally misunderstanding your point? > > Seth It at least, probably more likely, I'm misunderstanding. At some point in the process, an AAR and ARC signature get created. Later, someone else has to validate them. My point was that when you are on the signing end of this, you have to grovel through all the relevant AR header fields since there's nothing telling another doing new authentication the should combine them into the same field. Seeing sequence of AR fields for SPF, DKIM, and DMARC is quite normal. I thought that what was being said was that the AAR contstruction process could assume a single AR field and that's not correct. Now that I see it explained again, I see I was thinking one step too far back in the process. So, I think it was my misunderstanding, although if you're doing to use the results of the AAR in the verification process and assume it's all in a single AAR header field, then I think that should be a MUST, not a SHOULD. Scott K > On Sun, May 28, 2017 at 8:53 AM, Scott Kitterman > > wrote: > > On May 28, 2017 11:27:35 AM EDT, John Levine wrote: > > >In article <8F87F9DE-C87E-406E-BA49-6AEA5DC17283@kitterman.com>, > > > > > >>Nothing other than potentially ARC requires multiple AR header fields > > > > > >for different authentication types to be combined. These different > > > > > >>verification operations (e.g. SPF, DKIM, and DMARC) are generally > > > > > >performed be different processes that add their own AR field. > > > > > >Since DMARC needs the results of SPF and DKIM, how does that work? > > >Does DMARC look at the A-R that the other two created or is there a > > >side channel? It occurs to me that a DMARC process has everything > > >needed to make a header that combines all three. > > > > snip > > > > At least for OpenDMARC, if it's not doing it's own SPF check (which seems > > odd to me because it's done after DATA, but it works), it will look at > > multiple AR fields for both SPF and DKIM results. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue May 30 11:11:29 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 DB72E129AF9 for ; Tue, 30 May 2017 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 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, 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 v0Qn0sL1JUQj for ; Tue, 30 May 2017 11:11:26 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 021B8129AE7 for ; Tue, 30 May 2017 11:11:26 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d14so35153344qkb.1 for ; Tue, 30 May 2017 11:11:25 -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=kLFDoqO6Hg2IOlQlVyf0LnXsrO08tD4KaRsf9QaIA4Y=; b=i5U+JLfELMgFNTRijwNuDwXhlpMajiLlFfxrRLjudfRSuYIgKy59Z1wBFhrSudZ7rV S+Baajarhkx4EsVCamMKfvAOUT23nHEkN/4saB58hLA+l1v7e1EHYpXZ/fC0AgBUphgI tkKldnDMrO6GGBT6cgPQ/oZ4fSyLlpjtYXf4FBRktMG01v8Npb1tSHPeC2JGpEGdDOvy pfs9iXuOW/K+A0K9CcIFs4Mxc//j2iVldbB/jpQAGPRIo6GVKU8PBN7BOg5uv5DZrJ0z kX+UNXpEYpGHB6fKWz2EDhidbHCW5+nnQ8/ZE27vTaTEdjFDm09DxD8pfUQfWfoQ0g7+ 2qqg== 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=kLFDoqO6Hg2IOlQlVyf0LnXsrO08tD4KaRsf9QaIA4Y=; b=JGnwKAKB57DaYLAv5/wPMh560pz/N6XKVzvX8t5ntIZ5OqXQltCbcAlXXXBawnHa6G olzy/dVVly8SNdcC6yaAzd2Crm4fP7PQ3aQWYDcMeejKBJMtO2Ubp6dIQpcLvQxLbrdv NRWgkttouudhPDFQWuPCi10YH827cP3sTfZ0Q6ST5V9361YsrxpSMg/s/JzeXdXijmT8 Hri5bTfIu8ZeC8CrsgGNrab/uretrPnqiHqE/9hXQxVntAeoVEZig784oPC06O3dKu+V WbknvGuKuf4WiIkepZnCBvvIvg8qiysu197kJGcauTTSFzV1tqKWmwvF2FFxuxROXcda JERQ== X-Gm-Message-State: AODbwcBsMMQaVxUkJt3hrTZI9Igbepgi6tOVtaJqd5fau/vnrzzycV6r bKvUjjTwMSuCBQzXP5oj6/lfMSSuqg== X-Received: by 10.55.163.88 with SMTP id m85mr23052333qke.118.1496167885186; Tue, 30 May 2017 11:11:25 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Tue, 30 May 2017 11:11:24 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Wed, 31 May 2017 03:11:24 +0900 X-Google-Sender-Auth: Rv1C2MZRk8hl_jXuQod1w8dGRb4 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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: Tue, 30 May 2017 18:11:28 -0000 (Putting Murray on explicit CC to alert him to the openarc points.) > AFAIK, Steve Jones has been in touch with the hackathon > organizers to have ARC added to the slate. Both Steve and I will be coming > to Prague and several others from the group are expected as well. There is an ARC project listed in the Hackathon wiki , with Steve listed as the project champion. But neither Steve nor Kurt are registered for the Hackathon, and neither is anyone else claiming "ARC" as a project they're interested in. Will openarc be part of the Hackathon ARC project? Anyone who wants to work on this at the Hackathon, please register (free) for the hackathon ... sooner is better, so we can track who's participating. > From my POV, the ARC spec is close to "done". There are a few details that > are turning up from new sets of eyes looking at it as implementations are > built but so far, nothing substantive. I'll have new versions after my > flights at the end of the week (protocol & usage). If there *are* substantive issues that need discussion, please collect them and post them here so we can make up an agenda. > To me, the biggest point of discussion has to do with the hypothetical next > milestone for the group which is currently called out as "document[ing] > operational practices..." (the _Draft Guide on DMARC Usage_). While I > understand that was viewed as "something that we could do" when the group > was chartered, I doubt the need for it as an IETF document as time has > passed. I think that discussing the next steps of the group would be apropos > in a F2F meeting. This seems like fodder for a short meeting -- 30 minutes, rather than even one hour. I'm happy to request only a 30-minute slot, but let's see what we really need. And keep in mind that even if we need to discuss the next steps, we haven't done that on the list yet, so we don't know that we need face time for it. For example, do we need time to bat around possible issues with ARC that could cause deployment concerns (will senders who want DMARC protection be willing to allow mailing lists to take that over with ARC?) or deployment problems that might be different from, but as severe as, the ones DMARC caused? Or are those issues settled to the point where there's not a need to discuss them? Is the openarc project in a state where it would be useful to discuss it? Peter Goldstein's note asking for a meeting in Prague brought up the "next steps" discussion and also noted that it would be useful to have contact between the DMARC people and the DCRUP people. I'll note that DCRUP will have a session in Prague whether or not we do, and the crypto issues are probably better discussed there than here for now. Fallout from it that affects ARC will have to be dealt with after that. Barry From nobody Tue May 30 11:43:50 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 1EC1912943C for ; Tue, 30 May 2017 11:43:49 -0700 (PDT) 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_HELO_PASS=-0.001, 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=kitterman.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 o05HuPhZA4LO for ; Tue, 30 May 2017 11:43:47 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6448512943B for ; Tue, 30 May 2017 11:43:47 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CCF41C401B1 for ; Tue, 30 May 2017 13:43:45 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496169825; bh=13ZXGOiUshAXyVUEnrEkfewrZWyjDhVXAPpuyk5u91k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=usXuI6M2PZGcuc4V8PjsbwFD6CESRnL1gmMsNCEM5sMK8eEQcDN0mHovS0WZQg5u7 iNHJflnaHz0osalF5hbIdVuMdyjbl1BYzrABjpjpLrH+7mJaS93Yx/M2QMlP4ABAS4 mw+AxT+nK3wfRqLhhCLZDF1WEjgM8nPKYnaD5ZWc= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 30 May 2017 14:43:45 -0400 Message-ID: <34808716.2nE2qoVfF5@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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: Tue, 30 May 2017 18:43:49 -0000 On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > The current spec defines an arc authres method (https://tools.ietf.org/html/ > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > We believe there should also be registered ptypes and properties, that > should be stamped (but are not required, as they won't always be available). > > As long as AR stamping happens at the end of chain validation, when an ARC > set gets created this stamp will be included in the AAR, and AAR > construction can be clean with no additional language or requirements > necessary in the spec. > > What follows below is not sacred, we're just trying to start the > conversation. > > Based upon previous threads (specifically, Brandon's reporting local_policy > thread from May 4th PST) surrounding the AAR and data the WG thought would > be valuable for final receivers and DMARC reports, it looks like stamping > header.b for each dkim signature on the message and smtp.client-id for the > ip address of the originating mail server (if available) would provide > nearly everything asked for with minimal implementation overhead (and no > change to spec except for the IANA registration, and an addition for > RECOMMENDED stamping if warranted). > > To dig in to the reasoning behind these two properties: > > 1) header.b > > At the end of an ARC chain, there might be many DKIM signatures on the > message, nearly all of which could be broken on receipt. Additionally, > since there have been multiple hops, it is possible to have several broken > DKIM signatures with the same header.d value that are representative of > different services at different hops. > > If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of > every dkim key on the message, then it becomes super clear which keys were > added when, and which dkim pass/fail statuses correspond to which keys so > it can be determined when any individual signature broke. > > This is extremely useful as a reporter to help identify broken services at > any stage of DMARC enforcement, and is probably useful for final receivers > reviewing the chain to determine final message disposition; without this > information all the DKIM-Signatures on a message that do not validate and > share the same header.d are indistinguishable. > > This stamp removes this ambiguity and adds reporting and trace value. > > > 2) smtp.client-id > > The goal here is to track the originating source_ip for DMARC > categorization and reporting. Otherwise, all ARC messages will have a DMARC > report source_ip of the last forwarder, not the originating service. This > will be exceptionally confusing to consumers of DMARC reports. > > We know that including an IP address in Authentication-Results has been > persona-non-grata in the past, as authentication results are supposed to > encapsulate the results of an authentication check, not information that > could be used to re-run the authentication downstream. > > However, we believe that the client-id is vital trace information for ARC > and DMARC, is useful for categorizing senders within a DMARC report, and is > valuable at p=none, p=quarantine, and p=reject, and as such makes sense > within and contained to the ARC stamp. > > Ultimately, if this stamp is wrong for the AR, the client-id could be added > directly in the AAR. The AR stamp is cleaner because it leaves the AAR > generation and spec untouched. > > > We know there will be disagreement about what to stamp, and welcome > discussion on what's best to track within an AR header as arc status. > > I'm happy to suggest language once there's rough consensus in the group. When msk initially defined the Authentication Results header field, I was a strong proponent of including trace elements, but was in the rough as it comes to the consensus. In retrospect, I think he was correct. AAR can't truly be a trace header (you'd have to include the entire unmodified message with the original DKIM signature to make the DMARC inputs traceable). I'm not sure it's worth doing it half-way. I'm particularly not convinced about source_ip. DMARC reports are organized by 5322.From and when I'm reviewing reports what I care about is where the reporting receiver got it from. That's already covered. I don't see anything that might support trace uses that has to be in the initial specification. It can be added later if there's a need. Scott K From nobody Tue May 30 13: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 6C06F1293E8 for ; Tue, 30 May 2017 13:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 0Qllh_s2q4G0 for ; Tue, 30 May 2017 13:35:12 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 A8225126CD8 for ; Tue, 30 May 2017 13:35:12 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f55so79854664qta.3 for ; Tue, 30 May 2017 13:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2WRBf6G59v4aH5LxnKBCvvhk48yfU4p+xBZ7SY1PaBQ=; b=P0QZRsVrHzMfP5ZOctQA+Jvc7YEDr0E6nE+mani46911OChE7Hwj6LiBbDToT4kBxL aUuOYUQUXWUQQUAJpMH0CzKE43L5dw5WPqT4sgzYNV0YxtCfXTZ9d1LIKUJVRuoLZSre AcscNEaRe2h4cAnO8nZx722fdwjfeZuvaKbiuLPmfJToGgnaIh4T5guzPyl76785JRZf cSag7Mqt3b4Vtjha9uANrPasUUNpruIKEi4bGY6BNz06ogQyyQt+vIIh3vzaCZxxTu2i sxbTTV6Fdbe762w1lnNrGJRep/b4GIRv/DyRI5RRvoq+VgJY9TSalJSfveX3tGfXN0Sj 7ewg== 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=2WRBf6G59v4aH5LxnKBCvvhk48yfU4p+xBZ7SY1PaBQ=; b=O28CzeAksiU9OpiPJu2SG6yHtl3U5XplMGTQcGn3VRpF959OkN/ZzgQzLvKPGc9wS0 +kGJ2RWU1lprKTWWKB+16dq5znqckyHM381xaMq2OMwJp/LWzl0UQPSi1rWiHKyI/3Wi pkd4GtjPQdIBCoCa0dcYFY3GM58jdVHrSAeEP8MY1OkhgGdW8eRORX2wKyX5nkDR+eTM RTm2uYmb9uBI0EdGfAD7+V7yk8qBoJzUR3ncQEo1Z4L5fJL1kjJM4fRZlEcQoryGTClS hA2RE0i97AC23qKCFPwVujFK50c0emOpVSfVEB/halF3wjeLjhh0pm6uXrYHPahSwPez 46sA== X-Gm-Message-State: AODbwcCyhJWKVf4KkyCNwkGiCH3WY/eodgsl/FKkTrbRVOPs8AGIAE9A IPKKnn/8n7XDD6IfIQaiEDjgEo92xWY5tMA= X-Received: by 10.200.34.98 with SMTP id p31mr29701895qtp.2.1496176511282; Tue, 30 May 2017 13:35:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 13:34:50 -0700 (PDT) In-Reply-To: <34808716.2nE2qoVfF5@kitterma-e6430> References: <34808716.2nE2qoVfF5@kitterma-e6430> From: Seth Blank Date: Tue, 30 May 2017 13:34:50 -0700 Message-ID: To: dmarc@ietf.org Cc: Scott Kitterman Content-Type: multipart/alternative; boundary="001a11403b7a7a239e0550c3bddc" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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: Tue, 30 May 2017 20:35:16 -0000 --001a11403b7a7a239e0550c3bddc Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > The current spec defines an arc authres method ( > https://tools.ietf.org/html/ > > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > > > We believe there should also be registered ptypes and properties, that > > should be stamped (but are not required, as they won't always be > available). > > > > As long as AR stamping happens at the end of chain validation, when an > ARC > > set gets created this stamp will be included in the AAR, and AAR > > construction can be clean with no additional language or requirements > > necessary in the spec. > > > > What follows below is not sacred, we're just trying to start the > > conversation. > > > > Based upon previous threads (specifically, Brandon's reporting > local_policy > > thread from May 4th PST) surrounding the AAR and data the WG thought > would > > be valuable for final receivers and DMARC reports, it looks like stamping > > header.b for each dkim signature on the message and smtp.client-id for > the > > ip address of the originating mail server (if available) would provide > > nearly everything asked for with minimal implementation overhead (and no > > change to spec except for the IANA registration, and an addition for > > RECOMMENDED stamping if warranted). > > > > To dig in to the reasoning behind these two properties: > > > > 1) header.b > > > > At the end of an ARC chain, there might be many DKIM signatures on the > > message, nearly all of which could be broken on receipt. Additionally, > > since there have been multiple hops, it is possible to have several > broken > > DKIM signatures with the same header.d value that are representative of > > different services at different hops. > > > > If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of > > every dkim key on the message, then it becomes super clear which keys > were > > added when, and which dkim pass/fail statuses correspond to which keys so > > it can be determined when any individual signature broke. > > > > This is extremely useful as a reporter to help identify broken services > at > > any stage of DMARC enforcement, and is probably useful for final > receivers > > reviewing the chain to determine final message disposition; without this > > information all the DKIM-Signatures on a message that do not validate and > > share the same header.d are indistinguishable. > > > > This stamp removes this ambiguity and adds reporting and trace value. > > > > > > 2) smtp.client-id > > > > The goal here is to track the originating source_ip for DMARC > > categorization and reporting. Otherwise, all ARC messages will have a > DMARC > > report source_ip of the last forwarder, not the originating service. This > > will be exceptionally confusing to consumers of DMARC reports. > > > > We know that including an IP address in Authentication-Results has been > > persona-non-grata in the past, as authentication results are supposed to > > encapsulate the results of an authentication check, not information that > > could be used to re-run the authentication downstream. > > > > However, we believe that the client-id is vital trace information for ARC > > and DMARC, is useful for categorizing senders within a DMARC report, and > is > > valuable at p=none, p=quarantine, and p=reject, and as such makes sense > > within and contained to the ARC stamp. > > > > Ultimately, if this stamp is wrong for the AR, the client-id could be > added > > directly in the AAR. The AR stamp is cleaner because it leaves the AAR > > generation and spec untouched. > > > > > > We know there will be disagreement about what to stamp, and welcome > > discussion on what's best to track within an AR header as arc status. > > > > I'm happy to suggest language once there's rough consensus in the group. > > When msk initially defined the Authentication Results header field, I was a > strong proponent of including trace elements, but was in the rough as it > comes > to the consensus. In retrospect, I think he was correct. > > AAR can't truly be a trace header (you'd have to include the entire > unmodified > message with the original DKIM signature to make the DMARC inputs > traceable). > I'm not sure it's worth doing it half-way. > I don't want the AR payload to be about trace information; I want to make sure it encapsulates the proper authentication results and statuses. So that a DMARC report after an ARC message has been processed has the appropriate information that's valuable to a report consumer. - At p=none this means understanding the originating sender and if any originating authentication mechanisms were broken. This means passing through an smtp.client_id and the header.b's. - At p=quarantine|reject, for a failing message that passes arc, I think the status quo works (although having header.b here to understand which keys signed the message when could be useful). - At p=quarantine|reject, for a failing message that fails arc, it's useful to know where/why the message failed. Again, header.b's shine light on this and can make the DMARC report useful for determining/fixing a broken originating sender or intermediary. Passing this information through (and to me it's not trace if it's there for a user to interact with in a DMARC report - although there's definitely additional trace value, that's not the primary purpose here) is extremely valuable for the report consumer. My concern is putting it anywhere other than the AR/AAR could creative feature/spec creep, and waiting to see what happens and writing a spec for stamping later just leaves room open for complaints that, even after ARC, DMARC is still broken with respect to reporting on mailing list and forwarders. > > I'm particularly not convinced about source_ip. DMARC reports are > organized > by 5322.From and when I'm reviewing reports what I care about is where the > reporting receiver got it from. That's already covered. > I'm not certain I'm sold either. Especially because many implementations won't even have access to the IP. For instance, Mailman3 does not have access to the source_ip of the smtp connection (that data doesn't come over LMTP), so no mailman software would ever be able to stamp this. I think the source_ip is valuable to provide, especially for a final consumer of a report, but 1) it's not always available, 2) it doesn't seem perfect to put into an AR header. Thoughts? > > I don't see anything that might support trace uses that has to be in the > initial specification. It can be added later if there's a need. > I think stamping header.b has real value as outlined above. I think smtp.client_id also has value, but definitely see the arguments from both sides. Seth > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a11403b7a7a239e0550c3bddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 30, 2017 at 11:43 AM, Scott Kitterman <sklist@kitterman.com= > wrote:
=
On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > The current spec defines an arc authres method (https://tools.ietf.= org/html/
> draft-ietf-dmarc-arc-protocol-03#section-8.1).
>
> We believe there should also be registered ptypes and properties, that=
> should be stamped (but are not required, as they won't always be a= vailable).
>
> As long as AR stamping happens at the end of chain validation, when an= ARC
> set gets created this stamp will be included in the AAR, and AAR
> construction can be clean with no additional language or requirements<= br> > necessary in the spec.
>
> What follows below is not sacred, we're just trying to start the > conversation.
>
> Based upon previous threads (specifically, Brandon's reporting loc= al_policy
> thread from May 4th PST) surrounding the AAR and data the WG thought w= ould
> be valuable for final receivers and DMARC reports, it looks like stamp= ing
> header.b for each dkim signature on the message and smtp.client-id for= the
> ip address of the originating mail server (if available) would provide=
> nearly everything asked for with minimal implementation overhead (and = no
> change to spec except for the IANA registration, and an addition for > RECOMMENDED stamping if warranted).
>
> To dig in to the reasoning behind these two properties:
>
> 1) header.b
>
> At the end of an ARC chain, there might be many DKIM signatures on the=
> message, nearly all of which could be broken on receipt. Additionally,=
> since there have been multiple hops, it is possible to have several br= oken
> DKIM signatures with the same header.d value that are representative o= f
> different services at different hops.
>
> If each hop stamps the https://tools.ietf.org/html/rfc6= 008 header.b of
> every dkim key on the message, then it becomes super clear which keys = were
> added when, and which dkim pass/fail statuses correspond to which keys= so
> it can be determined when any individual signature broke.
>
> This is extremely useful as a reporter to help identify broken service= s at
> any stage of DMARC enforcement, and is probably useful for final recei= vers
> reviewing the chain to determine final message disposition; without th= is
> information all the DKIM-Signatures on a message that do not validate = and
> share the same header.d are indistinguishable.
>
> This stamp removes this ambiguity and adds reporting and trace value.<= br> >
>
> 2) smtp.client-id
>
> The goal here is to track the originating source_ip for DMARC
> categorization and reporting. Otherwise, all ARC messages will have a = DMARC
> report source_ip of the last forwarder, not the originating service. T= his
> will be exceptionally confusing to consumers of DMARC reports.
>
> We know that including an IP address in Authentication-Results has bee= n
> persona-non-grata in the past, as authentication results are supposed = to
> encapsulate the results of an authentication check, not information th= at
> could be used to re-run the authentication downstream.
>
> However, we believe that the client-id is vital trace information for = ARC
> and DMARC, is useful for categorizing senders within a DMARC report, a= nd is
> valuable at p=3Dnone, p=3Dquarantine, and p=3Dreject, and as such make= s sense
> within and contained to the ARC stamp.
>
> Ultimately, if this stamp is wrong for the AR, the client-id could be = added
> directly in the AAR. The AR stamp is cleaner because it leaves the AAR=
> generation and spec untouched.
>
>
> We know there will be disagreement about what to stamp, and welcome > discussion on what's best to track within an AR header as arc stat= us.
>
> I'm happy to suggest language once there's rough consensus in = the group.

When msk initially defined the Authentication Results header fi= eld, I was a
strong proponent of including trace elements, but was in the rough as it co= mes
to the consensus.=C2=A0 In retrospect, I think he was correct.

AAR can't truly be a trace header (you'd have to include the entire= unmodified
message with the original DKIM signature to make the DMARC inputs traceable= ).
I'm not sure it's worth doing it half-way.
I don't want the AR payload to be about trace information; = I want to make sure it encapsulates the proper authentication results and s= tatuses. So that a DMARC report after an ARC message has been processed has= the appropriate information that's valuable to a report consumer.

- At p=3Dnone this means understanding the originating= sender and if any originating authentication mechanisms were broken. This = means passing through an smtp.client_id and the header.b's.
<= br>
- At p=3Dquarantine|reject, for a failing message that passes= arc, I think the status quo works (although having header.b here to unders= tand which keys signed the message when could be useful).

- At p=3Dquarantine|reject, for a failing message that fails arc, i= t's useful to know where/why the message failed. Again, header.b's = shine light on this and can make the DMARC report useful for determining/fi= xing a broken originating sender or intermediary.

= Passing this information through (and to me it's not trace if it's = there for a user to interact with in a DMARC report - although there's = definitely additional trace value, that's not the primary purpose here)= is extremely valuable for the report consumer.

My concern is putting it anywhere other than the AR/AAR could creative fe= ature/spec creep, and waiting to see what happens and writing a spec for st= amping later just leaves room open for complaints that, even after ARC, DMA= RC is still broken with respect to reporting on mailing list and forwarders= .
=C2=A0

I'm particularly not convinced about source_ip.=C2=A0 DMARC reports are= organized
by 5322.From and when I'm reviewing reports what I care about is where = the
reporting receiver got it from.=C2=A0 That's already covered.

I'm not certain I'm sold either. Especia= lly because many implementations won't even have access to the IP. For = instance, Mailman3 does not have access to the source_ip of the smtp connec= tion (that data doesn't come over LMTP), so no mailman software would e= ver be able to stamp this.

I think the source_ip i= s valuable to provide, especially for a final consumer of a report, but 1) = it's not always available, 2) it doesn't seem perfect to put into a= n AR header.

Thoughts?=C2=A0

<= div>=C2=A0

I don't see anything that might support trace uses that has to be in th= e
initial specification.=C2=A0 It can be added later if there's a need.

I think stamping header.b has real value= as outlined above.

I think smtp.client_id also ha= s value, but definitely see the arguments from both sides.
=C2=A0=
Seth


Scott K

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



--

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a11403b7a7a239e0550c3bddc-- From nobody Tue May 30 13:35:45 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 250C71293E8 for ; Tue, 30 May 2017 13:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 xFqM0747VqxA for ; Tue, 30 May 2017 13:35:40 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC60126CD8 for ; Tue, 30 May 2017 13:35:39 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 130so23338096ybl.3 for ; Tue, 30 May 2017 13:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GVM4TYPgOYL+aas8WMuBfe0KaFyo1BA8mIRr2c8pvrU=; b=QWPZv3Ut3Ug9js/5usibfG6yu1z+KeVz9YPMoQ2X3e3gSepADYQ4L4EOq/K0uOmWPe gvibkNs/BGLKrBfuCmYCsVOCH9oj4VYODGj13ECE1RoKQIu8PGSA9S8RqMXKeF9EsaML JBQfJEgPP7LgA/ovHSu+LmwVlGt7vm1tGqWZJSXS4JQmPxMmW1sYVRvSzzoXNlBYhRwb vdDPbX9NX71GcxPuNWdpF3Qw/ZD2uUSKbD1VVdhXvLrFPW5wJXrVWLc472KDBkZN2PXG przqUj3Nbjh266EYDs1MCmKG1V8q/pPKIMg/EfC400z8pM6MXuMWu3l9Qxe9F3whJmNv mxMw== 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=GVM4TYPgOYL+aas8WMuBfe0KaFyo1BA8mIRr2c8pvrU=; b=aZXrrnONh1IxbwXM2/OmfjMwF0uf73VBC0ELd7n0T0mX04sjdf+rliC7u9D1chfE1X X4qq4Krn0k6GxdmNSZYVA6nt4CRUXxH+H+NNisawRGvMDoOene82m1p/qWMcTEpJhGl/ FRSBHSMNEk/Qh3Hv1tUgtUDLub8jpUz+P41hIMzcHOH5yUxQFsUa4Y3+oA0FIrGlzQdv Lr8Ch3Q9WYJbZmbjGOtxy6HFLSbwVXjFeh6PjmIN3l5EEFWYMupyTCFMzALIpKAZbvRw PvIKJTKaQa02LEqzJVfD1j9SP5jOyuZk9jZnXpfCfBEFrNsZSFLLwWX93uvsSfpBRnff 3uOg== X-Gm-Message-State: AODbwcBdwm/A7dCmHtEtpG8s9nOzP+waXGcxgWQFHiIg+rF+g6vDoTLQ CptlZSfM1lCox+O6MmNhlYlAbcz3sg5+ X-Received: by 10.37.96.134 with SMTP id u128mr43134918ybb.86.1496176539005; Tue, 30 May 2017 13:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.143 with HTTP; Tue, 30 May 2017 13:35:38 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 30 May 2017 13:35:38 -0700 Message-ID: To: Seth Blank Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a1143ed42214ce30550c3bfce" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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: Tue, 30 May 2017 20:35:42 -0000 --001a1143ed42214ce30550c3bfce Content-Type: text/plain; charset="UTF-8" So I'm actively doing development on OpenARC right now, and this definitely something that is being a source of some non-trivial awkwardness. Can anybody recall why the aforementioned language of recommending including the AAR's in the AMS is in there? Afaik, it seems to make no sense, and is causing some implementation specific awkwardness wrt both OpenARC & the test suite. So one would expect that for an ARC implementation, we would want a simple configuration option that tells us which headers to sign. I believe OpenDKIM behaves in exactly this fashion. And it needs to be able to include duplicates, as that's a require feature of the rfc. But this recommendation to include AAR's in the list makes this awkward, as, as we can't configure this in a similar fashion, as we dont know how many AAR's are in messages a prior. So either an implementation will either need some AAR inclusion configuration option, independent of the other h= configuration list, or it needs to make some internal decision of whether to be signing these headers or not. The first option is awkward & seems just kind of needlessly complex. And I'm also not a fan of implementations making this kind of decision internally, as I think its important from a testing standpoint to have the output headers be predictable. So can anybody recall why this language is there? It seems kind of pointless in the best case, and slightly harmful in the worst. Unless somebody has a reason for it being there, I suggest we remove it. Or why not just actively forbid the inclusion of all ARC-Set header fields in the AMS while we're at it? That seems like a plausible idea. =Gene On Thu, May 25, 2017 at 3:47 PM, Seth Blank wrote: > This might be a non-issue, but we're asking this question specifically > because we've run into an implementation issue within openarc that feels > weird and seems like a matter the WG may want to weigh in on. > > Our expectation is that, for any given ARC Set n, AMS[n] would cover > AAR[n]. > > Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* > AAR[n] because AAR[n] isn't created until substantially later in the flow. > > Technically, this behavior is within spec as defined in > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol- > 03#section-5.1.2.1.1 : > > Participants may include any other header fields within the scope of > the ARC-Message-Signature signature except that they MUST NOT include > ARC-Seal headers fields. In particular, including all DKIM-Signature > header fields and all ARC-Authentication-Results header fields is > RECOMMENDED. > > Is it worth guaranteeing that, if signing AARs, AMS[n] must cover AAR[n]? > > Or is this irrelevant because AS[n] is required to cover AMS[n] and > AAR[n]? But if so, why recommend the AAR be covered by the AMS at all in > the first place? > > While the differences between these two assertions appear to be benign > (AAR[n] is always signed by AS[n], so whether or not it is in AMS[n] > shouldn't matter), the spec leaves room for confusion about the right thing > to do. > > What was the original intention here and does this need clarification? > > -- > > [image: logo for sig file.png] > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > seth@valimail.com > +1-415-894-2724 > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1143ed42214ce30550c3bfce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I'm actively doing development on OpenARC right now= , and this definitely something that is being a source of some non-trivial = awkwardness. =C2=A0

Can anybody recall why the aforement= ioned language of recommending including the AAR's in the AMS is in the= re?=C2=A0 Afaik, it seems to make no sense, and is causing some implementat= ion specific awkwardness wrt both OpenARC & the test suite. =C2=A0

So one would expect that for an ARC implementation, we= would want a simple configuration option that tells us which headers to si= gn.=C2=A0 I believe OpenDKIM behaves in exactly this fashion.=C2=A0 And it = needs to be able to include duplicates, as that's a require feature of = the rfc.=C2=A0 But this recommendation to include AAR's in the list mak= es this awkward, as, as we can't configure this in a similar fashion, a= s we dont know how many AAR's are in messages a prior. =C2=A0

So either an implementation will either need some AAR inclu= sion configuration option, independent of the other h=3D configuration list= , or it needs to make some internal decision of whether to be signing these= headers or not.=C2=A0 The first option is awkward & seems just kind of= needlessly complex.=C2=A0 And I'm also not a fan of implementations ma= king this kind of decision internally, as I think its important from a test= ing standpoint to have the output headers be predictable. =C2=A0
=
So can anybody recall why this language is there?=C2=A0 It s= eems kind of pointless in the best case, and slightly harmful in the worst.= =C2=A0 Unless somebody has a reason for it being there, I suggest we remove= it.=C2=A0 Or why not just actively forbid the inclusion of all ARC-Set hea= der fields in the AMS while we're at it?=C2=A0 That seems like a plausi= ble idea. =C2=A0

=3DGene

On Thu, May 25, 2017 at 3:47 PM= , Seth Blank <seth@valimail.com> wrote:
This might be a non-issue, but we'r= e asking this question specifically because we've run into an implement= ation issue within openarc that feels weird and seems like a matter the WG = may want to weigh in on.

Our expectation is t= hat, for any given ARC Set n, AMS[n] would cover AAR[n].

Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *no= t* AAR[n] because AAR[n] isn't created until substantially later in the= flow.

Technically, this behavior is within spec a= s defined in https://tools.ietf.org/html/draft-ietf-dmarc-arc-proto= col-03#section-5.1.2.1.1 :

=C2= =A0 =C2=A0Participants may include any other header fields within the scope= of
=C2=A0 =C2=A0the ARC-Message-Signature signature except that = they MUST NOT include
=C2=A0 =C2=A0ARC-Seal headers fields.=C2=A0= In particular, including all DKIM-Signature
=C2=A0 =C2=A0header = fields and all ARC-Authentication-Results header fields is
=C2=A0= =C2=A0RECOMMENDED.

Is it worth guaranteeing= that, if signing AARs, AMS[n] must cover AAR[n]?

= Or is this irrelevant because AS[n] is required to cover AMS[n] and AAR[n]?= But if so, why recommend the AAR be covered by the AMS at all in the first= place?

While the differences between these two as= sertions appear to be benign (AAR[n] is always signed by AS[n], so whether = or not it is in AMS[n] shouldn't matter), the spec leaves room for conf= usion about the right thing to do.

What was the or= iginal intention here and does this need clarification?

--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Prod= uct for Open Source an= d Protocols

seth@valimail.com
+1-415-894-2724

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


--001a1143ed42214ce30550c3bfce-- From nobody Tue May 30 14:15: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 9FD0A127869 for ; Tue, 30 May 2017 14:15:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=kitterman.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 YZiaxC7fU-Px for ; Tue, 30 May 2017 14:14:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAD5124D37 for ; Tue, 30 May 2017 14:14:59 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 59A3AC401B1 for ; Tue, 30 May 2017 16:14:57 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496178897; bh=vrEys1WJw/BAiXypLXCwGbj5dXBsFj1jtak9AVjjMzc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UCqLm0uKb7WpcTRKIMpY1ThU1o8J4j+k2QtimdDyQ9cCjYMHXcOZlcoNEPmF9JbB9 G6ncQDkS4W6s12wop+9uIRmHw1hwfG090Na3ALihzQRLJ1WeMHmNSVDo2ODTiUIb55 viUaFAhB4oteot0LY+7pH61VnrCzZT6/1T2g2f4g= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 30 May 2017 17:14:56 -0400 Message-ID: <1927341.Yq1D0kyESZ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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: Tue, 30 May 2017 21:15:01 -0000 On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman > > wrote: > > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > > The current spec defines an arc authres method ( > > > > https://tools.ietf.org/html/ > > > > > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > > > > > We believe there should also be registered ptypes and properties, that > > > should be stamped (but are not required, as they won't always be > > > > available). > > > > > As long as AR stamping happens at the end of chain validation, when an > > > > ARC > > > > > set gets created this stamp will be included in the AAR, and AAR > > > construction can be clean with no additional language or requirements > > > necessary in the spec. > > > > > > What follows below is not sacred, we're just trying to start the > > > conversation. > > > > > > Based upon previous threads (specifically, Brandon's reporting > > > > local_policy > > > > > thread from May 4th PST) surrounding the AAR and data the WG thought > > > > would > > > > > be valuable for final receivers and DMARC reports, it looks like > > > stamping > > > header.b for each dkim signature on the message and smtp.client-id for > > > > the > > > > > ip address of the originating mail server (if available) would provide > > > nearly everything asked for with minimal implementation overhead (and no > > > change to spec except for the IANA registration, and an addition for > > > RECOMMENDED stamping if warranted). > > > > > > To dig in to the reasoning behind these two properties: > > > > > > 1) header.b > > > > > > At the end of an ARC chain, there might be many DKIM signatures on the > > > message, nearly all of which could be broken on receipt. Additionally, > > > since there have been multiple hops, it is possible to have several > > > > broken > > > > > DKIM signatures with the same header.d value that are representative of > > > different services at different hops. > > > > > > If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of > > > every dkim key on the message, then it becomes super clear which keys > > > > were > > > > > added when, and which dkim pass/fail statuses correspond to which keys > > > so > > > it can be determined when any individual signature broke. > > > > > > This is extremely useful as a reporter to help identify broken services > > > > at > > > > > any stage of DMARC enforcement, and is probably useful for final > > > > receivers > > > > > reviewing the chain to determine final message disposition; without this > > > information all the DKIM-Signatures on a message that do not validate > > > and > > > share the same header.d are indistinguishable. > > > > > > This stamp removes this ambiguity and adds reporting and trace value. > > > > > > > > > 2) smtp.client-id > > > > > > The goal here is to track the originating source_ip for DMARC > > > categorization and reporting. Otherwise, all ARC messages will have a > > > > DMARC > > > > > report source_ip of the last forwarder, not the originating service. > > > This > > > will be exceptionally confusing to consumers of DMARC reports. > > > > > > We know that including an IP address in Authentication-Results has been > > > persona-non-grata in the past, as authentication results are supposed to > > > encapsulate the results of an authentication check, not information that > > > could be used to re-run the authentication downstream. > > > > > > However, we believe that the client-id is vital trace information for > > > ARC > > > and DMARC, is useful for categorizing senders within a DMARC report, and > > > > is > > > > > valuable at p=none, p=quarantine, and p=reject, and as such makes sense > > > within and contained to the ARC stamp. > > > > > > Ultimately, if this stamp is wrong for the AR, the client-id could be > > > > added > > > > > directly in the AAR. The AR stamp is cleaner because it leaves the AAR > > > generation and spec untouched. > > > > > > > > > We know there will be disagreement about what to stamp, and welcome > > > discussion on what's best to track within an AR header as arc status. > > > > > > I'm happy to suggest language once there's rough consensus in the group. > > > > When msk initially defined the Authentication Results header field, I was > > a > > strong proponent of including trace elements, but was in the rough as it > > comes > > to the consensus. In retrospect, I think he was correct. > > > > AAR can't truly be a trace header (you'd have to include the entire > > unmodified > > message with the original DKIM signature to make the DMARC inputs > > traceable). > > I'm not sure it's worth doing it half-way. > > I don't want the AR payload to be about trace information; I want to make > sure it encapsulates the proper authentication results and statuses. So > that a DMARC report after an ARC message has been processed has the > appropriate information that's valuable to a report consumer. > > - At p=none this means understanding the originating sender and if any > originating authentication mechanisms were broken. This means passing > through an smtp.client_id and the header.b's. > > - At p=quarantine|reject, for a failing message that passes arc, I think > the status quo works (although having header.b here to understand which > keys signed the message when could be useful). > > - At p=quarantine|reject, for a failing message that fails arc, it's useful > to know where/why the message failed. Again, header.b's shine light on this > and can make the DMARC report useful for determining/fixing a broken > originating sender or intermediary. > > Passing this information through (and to me it's not trace if it's there > for a user to interact with in a DMARC report - although there's definitely > additional trace value, that's not the primary purpose here) is extremely > valuable for the report consumer. > > My concern is putting it anywhere other than the AR/AAR could creative > feature/spec creep, and waiting to see what happens and writing a spec for > stamping later just leaves room open for complaints that, even after ARC, > DMARC is still broken with respect to reporting on mailing list and > forwarders. > > > I'm particularly not convinced about source_ip. DMARC reports are > > organized > > by 5322.From and when I'm reviewing reports what I care about is where the > > reporting receiver got it from. That's already covered. > > I'm not certain I'm sold either. Especially because many implementations > won't even have access to the IP. For instance, Mailman3 does not have > access to the source_ip of the smtp connection (that data doesn't come over > LMTP), so no mailman software would ever be able to stamp this. > > I think the source_ip is valuable to provide, especially for a final > consumer of a report, but 1) it's not always available, 2) it doesn't seem > perfect to put into an AR header. > > Thoughts? > > > I don't see anything that might support trace uses that has to be in the > > initial specification. It can be added later if there's a need. > > I think stamping header.b has real value as outlined above. > > I think smtp.client_id also has value, but definitely see the arguments > from both sides. So header.b only gives an explicit way to link an (A)AR header field with a signature, so there's no need to guess what's related within the message. Now that I've read your rationale and gone and read RFC 6008 again, I agree that makes sense to include in AAR. It might even be a good idea to make it mandatory since there is (for the purposes of IETF standardization) no installed base to worry about. Source IP, I still this is only for trace purposes and should be out of scope (I have a hard time justifying why it would be out of scope for SPF (which is what the working group and later IETF consensus was) and in scope here. Scott K From nobody Tue May 30 14:48:42 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 99D09127869 for ; Tue, 30 May 2017 14:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3mQHT_-_Ctt for ; Tue, 30 May 2017 14:48:40 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBF8124D37 for ; Tue, 30 May 2017 14:48:40 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w10so128868294oif.0 for ; Tue, 30 May 2017 14:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=I0KZ2padyFpofVsihwDfWxZilVWQTcyhqtULhLPFaFo=; b=cGWZXLa3nQNaIEJCpuRqvfDejEWI/kcfz7eIj4ZGkjxw/do/55tPJK1feetNydK3dz whzwEgp7vboP3Q8LQNAhQlSktQ/WCxuFOhdyV8jUpwQLdTpbmCPdJIJcg3IFpRdFpaHB D3cDDSVZMdOdXMsHFZLJOvqL0H+pjiapnD/CsA+JLXFPXysRYGfHv0BoQgmUikWbgyYN PoxW2J7znsyqYLPXNmZ6aewsOMDf3BYcDaPo1JDVRa5lhuaQoXceOXjcCvE2bK6ooB9F vUw4nsvbut0R8agGryNSgd335+z2BxCkS3kTvjDJdhbAaYOi9fo8jY6yTj8v6v+3uK0l +JNQ== 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=I0KZ2padyFpofVsihwDfWxZilVWQTcyhqtULhLPFaFo=; b=fp4cLQ4dUvp/3rpN1iFzhn9WaE17ee0w51jlI0J0mlQaN8g2DZzD6DXPHtZnPJkE4x qYmUyoHReQnDy8xu832jo9q0SVllbcFO4SJBbym4BBYNwPoDPpywX7h8h8P9Vlil/Irx FNNKLkzpkfl0+C7DObxRxsfRwudEC6plWsMSbnWaBWYhIAWD+ScuJBP+Jy0LnHCez1WE 1/HqYGNedR+CFMLZftQ4CFtXd+3vH8z9Kzt5AoXZqtBP6bwQ62EBTZrkV70U7EmgYxbY iMTvk0ChaVaZ+Hm2tTrA4W1V9mczYfkxHtcsQ2sY37a/3/0oeXjwVWT6iyyC4WY9+Zvw kYRw== X-Gm-Message-State: AODbwcCVm077T2hbW+j0ptfRpRkPQ3/V7+cGwJC8yFibIzemnwUsKbJj KgDIYbobYvJiXcgcVxvCvissa+0d/17pjdxQ0Q== X-Received: by 10.202.178.85 with SMTP id b82mr9399674oif.51.1496180919300; Tue, 30 May 2017 14:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 14:48:38 -0700 (PDT) From: Brandon Long Date: Tue, 30 May 2017 14:48:38 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1146ac5e3788f40550c4c406" Archived-At: Subject: [dmarc-ietf] dmarc reporting changes from Google 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: Tue, 30 May 2017 21:48:41 -0000 --001a1146ac5e3788f40550c4c406 Content-Type: text/plain; charset="UTF-8" Rolling out this week, we've updated how we handle our own XOAR results in preparation for handling ARC in the same way. Previously, any time we used XOAR to override a DMARC result, we didn't report that transaction at all in our aggregate reports. Now, we'll report those with a PolicyOverrideType of local_policy and a comment of xoar=pass. Around the end of the week, I expect to replace most of those with using ARC instead, same override type (local_policy) but the comment will be arc=pass. Brandon --001a1146ac5e3788f40550c4c406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rolling out this week, we've updated how we handle our= own XOAR results in preparation for handling ARC in the same way.

=
Previously, any time we used XOAR to override a DMARC result, we= didn't report that transaction at all in our aggregate reports.
<= div>
Now, we'll report those with a=C2=A0PolicyOverrideType of local_policy and= a comment of xoar=3Dpass.

Around the end of the week, I expect to replace most = of those with using ARC instead, same override type (local_policy) but the = comment will be arc=3Dpass.

Brandon
--001a1146ac5e3788f40550c4c406-- From nobody Tue May 30 15:01:00 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 6C9E1129462 for ; Tue, 30 May 2017 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiywgOZdbaKQ for ; Tue, 30 May 2017 15:00:42 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8918B129436 for ; Tue, 30 May 2017 15:00:42 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id w10so129181972oif.0 for ; Tue, 30 May 2017 15:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tSPMZX+UFq0wzv+32AYMDbMjD/FS2D7ffzMDHAWlq08=; b=GduZ0jKI4U+Cic4Tb0JHE6dAExGHKHSHtRFjGksLyQS7srt3pelguD7ykY/8VtGkfY +0RxpmjJG/7F5S7w9EXyaMtK/POweq/RFBWlZhKrVFW8YHUQL/ZppZ2E/cdl9qQ61dXN fANftvRrrF7KqAflP9jyErYIrzmCja+Gqs1UoftCgAee0cSy9deGxn3vSY75qTXE7wiP m+t0unnkoBr/iXvCELN3jjeul/XXcSLfrxLZOc469/qYxPYRqQHRZmYXGkA0Ki/e++dx fUKhkhvOpnSIx0XiH3gWRZn2Mm9lwPY3UpToMu+fnzU0Ytx7DH94GYUYV8tsin6Y7BDB gxTw== 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=tSPMZX+UFq0wzv+32AYMDbMjD/FS2D7ffzMDHAWlq08=; b=CjrbBRFzQDKf4VwMLZ8YAI3TlQyKlgvWxwaQ6mkuFHXHst/vMSEUi/6iD3bAYrYa7d nYFWnU8v8Rh2f5yDAmhdN2p/LW4b4Awwe2ddW1XXu1lU3cXEIjDaPY0dRW7aDPtwnAJ8 jqY4YXVTHiDsRlx/41+qkdoC1GjC9HUHavLaFlBV4uW8ALiQccBjvgvB75SXw3GycMPK 7hyVmM2tyELSw/PlcVwcAqIQmXr/9o0jfCkoL5MAuQJeerdFpDFm3ARfyCdKDxQrrXd9 0Ae+sWx4X7112USvmYS0TYa1HP23+3C5t3irQIfEDNhXjaQOkx62ow1jum3cYqMO2f8D Z7lg== X-Gm-Message-State: AODbwcAODTr83jN7XfByyiQWjU7fvMDRvqIFC+As+HpYYtys/RJhFHvq ig8HzlSwS51XIsvRhKjxEKY5FyKNH+pxdUs= X-Received: by 10.202.52.214 with SMTP id b205mr12005423oia.133.1496181640870; Tue, 30 May 2017 15:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 15:00:40 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 30 May 2017 15:00:40 -0700 Message-ID: To: Gene Shuman Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cbd3a39e18d0550c4ef6f" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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: Tue, 30 May 2017 22:00:44 -0000 --001a113cbd3a39e18d0550c4ef6f Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 1:35 PM, Gene Shuman wrote: > So I'm actively doing development on OpenARC right now, and this > definitely something that is being a source of some non-trivial > awkwardness. > > Can anybody recall why the aforementioned language of recommending > including the AAR's in the AMS is in there? Afaik, it seems to make no > sense, and is causing some implementation specific awkwardness wrt both > OpenARC & the test suite. > > So one would expect that for an ARC implementation, we would want a simple > configuration option that tells us which headers to sign. I believe > OpenDKIM behaves in exactly this fashion. And it needs to be able to > include duplicates, as that's a require feature of the rfc. But this > recommendation to include AAR's in the list makes this awkward, as, as we > can't configure this in a similar fashion, as we dont know how many AAR's > are in messages a prior. > I think this is broken. Why would you ever configure "only sign two copies of this header, but not three"? I'd expect two lists, one of which headers to sign, and one of which headers to add as empty to prevent extra copies of the header to be added. Ie, in dkimpy, that's the SHOULD and FROZEN lists. > So either an implementation will either need some AAR inclusion > configuration option, independent of the other h= configuration list, or it > needs to make some internal decision of whether to be signing these headers > or not. The first option is awkward & seems just kind of needlessly > complex. And I'm also not a fan of implementations making this kind of > decision internally, as I think its important from a testing standpoint to > have the output headers be predictable. > > So can anybody recall why this language is there? It seems kind of > pointless in the best case, and slightly harmful in the worst. Unless > somebody has a reason for it being there, I suggest we remove it. Or why > not just actively forbid the inclusion of all ARC-Set header fields in the > AMS while we're at it? That seems like a plausible idea. > The AMS was arrived at incrementally, as was the AAR (originally there was just one AAR, not a full chain). I guess it's not required, though I'm not sure about the harmful part. Brandon --001a113cbd3a39e18d0550c4ef6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <gene@valimail.com>= ; wrote:
So I'= ;m actively doing development on OpenARC right now, and this definitely som= ething that is being a source of some non-trivial awkwardness. =C2=A0
<= br>
Can anybody recall why the aforementioned language of recomme= nding including the AAR's in the AMS is in there?=C2=A0 Afaik, it seems= to make no sense, and is causing some implementation specific awkwardness = wrt both OpenARC & the test suite. =C2=A0

So o= ne would expect that for an ARC implementation, we would want a simple conf= iguration option that tells us which headers to sign.=C2=A0 I believe OpenD= KIM behaves in exactly this fashion.=C2=A0 And it needs to be able to inclu= de duplicates, as that's a require feature of the rfc.=C2=A0 But this r= ecommendation to include AAR's in the list makes this awkward, as, as w= e can't configure this in a similar fashion, as we dont know how many A= AR's are in messages a prior.

I think this is broken.=C2=A0 Why would you ever configure "only si= gn two copies of this header, but not three"?=C2=A0 I'd expect two= lists, one of which headers to sign, and one of which headers to add as em= pty to prevent extra copies of the header to be added.=C2=A0 Ie, in dkimpy,= that's the SHOULD and FROZEN lists.
=C2=A0
So either an implementation will e= ither need some AAR inclusion configuration option, independent of the othe= r h=3D configuration list, or it needs to make some internal decision of wh= ether to be signing these headers or not.=C2=A0 The first option is awkward= & seems just kind of needlessly complex.=C2=A0 And I'm also not a = fan of implementations making this kind of decision internally, as I think = its important from a testing standpoint to have the output headers be predi= ctable. =C2=A0

So can anybody recall why this lang= uage is there?=C2=A0 It seems kind of pointless in the best case, and sligh= tly harmful in the worst.=C2=A0 Unless somebody has a reason for it being t= here, I suggest we remove it.=C2=A0 Or why not just actively forbid the inc= lusion of all ARC-Set header fields in the AMS while we're at it?=C2=A0= That seems like a plausible idea. =C2=A0

=
The AMS was arrived at incrementally, as was the AAR (originally= there was just one AAR, not a full chain).=C2=A0 I guess it's not requ= ired, though I'm not sure about the harmful part.

<= div>Brandon
--001a113cbd3a39e18d0550c4ef6f-- From nobody Tue May 30 15:11:23 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 07711129462 for ; Tue, 30 May 2017 15:11:22 -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 (2048-bit key) header.d=valimail.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 Cjbc4isBFgx8 for ; Tue, 30 May 2017 15:11:20 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 C4CC7129467 for ; Tue, 30 May 2017 15:11:18 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id b68so46345857ywe.3 for ; Tue, 30 May 2017 15:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cFvxV/d6Ij3VgJb+vkPyuQj5UxSktoFxMRQCmDNV9+o=; b=bxEl/Zi3xgpdyqkAhyYJZNPQ5oRZwr8S2UUeORbxqQgwIri7kOihuiJAh9Cn2oFggp bFyOUmFR7UWsxHkvCtxOHJ37juBhokHQ6saiM9WQ2FXTQY4SieQ7wPPOtzIX2Y6hvJvt jaSa2LMS770XXGKASgSwsxkc2uvf3wJbS50qtC+BtD1X+YiYrXNd1ITymUnvMtcl0Izx 8lwuPR+Hpyg25fQ8LIddNmE/M2Xnjmuzrwh+r7gvwaJ5gZGKV3+J0LwLUnRmSAmbENpw 2520Mf71LgCl6gv2Oi/5nORBJqVlPcMxWlvSwXaqOT0xZqrcryK01+AWFgq5WcTCK7J5 gMjg== 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=cFvxV/d6Ij3VgJb+vkPyuQj5UxSktoFxMRQCmDNV9+o=; b=eLM4RHAstfkjzFugUpMtt0ltohXFvAQyudg6PxKwvlm1e8HrixYEa7Ntcewfbbb/O/ mfhhoRiHw+0ZyVSuSVG++GTP8SjuC1cFCl8OkB2lf9wgTfcL2/iwGHghINkWrHhwYgDK wrM1EKuT4j6HG8tt1OhaTnsQlXvg0yorqkWf9EGyKzYPL9N/XWPelFixYIEYmSBddz47 pRQ5UJ7vnquoQVL6GlFLu85KkzNzTzUiA+T18F/qP53Z1jH1HXA8SOK2r3VthBuywgGV tKHzyLwxsx06EKA7//tzArfeCxMrr25pB2JEKcfQticHk7D7Mb0KxMZJQB6UNG/iRBkU npJA== X-Gm-Message-State: AODbwcC2hd8koQ+1DfbegXBEIG6XEpOZ7nBs0Bp0C3QiDvqEY/l1kERj qN23qlQ4Dymv/Be0wep5iaEeuIkRS51G X-Received: by 10.129.113.3 with SMTP id m3mr17676254ywc.100.1496182277970; Tue, 30 May 2017 15:11:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.208.143 with HTTP; Tue, 30 May 2017 15:11:17 -0700 (PDT) In-Reply-To: References: From: Gene Shuman Date: Tue, 30 May 2017 15:11:17 -0700 Message-ID: To: Brandon Long Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114739ac32ea3c0550c51579" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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: Tue, 30 May 2017 22:11:22 -0000 --001a114739ac32ea3c0550c51579 Content-Type: text/plain; charset="UTF-8" The two list approach to configuration actually seems sensible in general, I'll discuss this with msk. However, if the recommended AAR inclusion language accomplishes nothing, shouldn't we remove it, regardless? On Tue, May 30, 2017 at 3:00 PM, Brandon Long wrote: > > > On Tue, May 30, 2017 at 1:35 PM, Gene Shuman wrote: > >> So I'm actively doing development on OpenARC right now, and this >> definitely something that is being a source of some non-trivial >> awkwardness. >> >> Can anybody recall why the aforementioned language of recommending >> including the AAR's in the AMS is in there? Afaik, it seems to make no >> sense, and is causing some implementation specific awkwardness wrt both >> OpenARC & the test suite. >> >> So one would expect that for an ARC implementation, we would want a >> simple configuration option that tells us which headers to sign. I believe >> OpenDKIM behaves in exactly this fashion. And it needs to be able to >> include duplicates, as that's a require feature of the rfc. But this >> recommendation to include AAR's in the list makes this awkward, as, as we >> can't configure this in a similar fashion, as we dont know how many AAR's >> are in messages a prior. >> > > I think this is broken. Why would you ever configure "only sign two > copies of this header, but not three"? I'd expect two lists, one of which > headers to sign, and one of which headers to add as empty to prevent extra > copies of the header to be added. Ie, in dkimpy, that's the SHOULD and > FROZEN lists. > > >> So either an implementation will either need some AAR inclusion >> configuration option, independent of the other h= configuration list, or it >> needs to make some internal decision of whether to be signing these headers >> or not. The first option is awkward & seems just kind of needlessly >> complex. And I'm also not a fan of implementations making this kind of >> decision internally, as I think its important from a testing standpoint to >> have the output headers be predictable. >> >> So can anybody recall why this language is there? It seems kind of >> pointless in the best case, and slightly harmful in the worst. Unless >> somebody has a reason for it being there, I suggest we remove it. Or why >> not just actively forbid the inclusion of all ARC-Set header fields in the >> AMS while we're at it? That seems like a plausible idea. >> > > The AMS was arrived at incrementally, as was the AAR (originally there was > just one AAR, not a full chain). I guess it's not required, though I'm not > sure about the harmful part. > > Brandon > --001a114739ac32ea3c0550c51579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The two list approach to configuration actually seems sens= ible in general, I'll discuss this with msk. =C2=A0

= However, if the recommended AAR inclusion language accomplishes nothing, sh= ouldn't we remove it, regardless?

On Tue, May 30, 2017 at 3:00 PM, Brandon Lo= ng <blong@google.com> wrote:


On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <gene@valimail.com&= gt; wrote:
So I&#= 39;m actively doing development on OpenARC right now, and this definitely s= omething that is being a source of some non-trivial awkwardness. =C2=A0
Can anybody recall why the aforementioned language of recom= mending including the AAR's in the AMS is in there?=C2=A0 Afaik, it see= ms to make no sense, and is causing some implementation specific awkwardnes= s wrt both OpenARC & the test suite. =C2=A0

So= one would expect that for an ARC implementation, we would want a simple co= nfiguration option that tells us which headers to sign.=C2=A0 I believe Ope= nDKIM behaves in exactly this fashion.=C2=A0 And it needs to be able to inc= lude duplicates, as that's a require feature of the rfc.=C2=A0 But this= recommendation to include AAR's in the list makes this awkward, as, as= we can't configure this in a similar fashion, as we dont know how many= AAR's are in messages a prior.

=
I think this is broken.=C2=A0 Why would you ever configure "only = sign two copies of this header, but not three"?=C2=A0 I'd expect t= wo lists, one of which headers to sign, and one of which headers to add as = empty to prevent extra copies of the header to be added.=C2=A0 Ie, in dkimp= y, that's the SHOULD and FROZEN lists.
=C2=A0
So either an implementation will= either need some AAR inclusion configuration option, independent of the ot= her h=3D configuration list, or it needs to make some internal decision of = whether to be signing these headers or not.=C2=A0 The first option is awkwa= rd & seems just kind of needlessly complex.=C2=A0 And I'm also not = a fan of implementations making this kind of decision internally, as I thin= k its important from a testing standpoint to have the output headers be pre= dictable. =C2=A0

So can anybody recall why this la= nguage is there?=C2=A0 It seems kind of pointless in the best case, and sli= ghtly harmful in the worst.=C2=A0 Unless somebody has a reason for it being= there, I suggest we remove it.=C2=A0 Or why not just actively forbid the i= nclusion of all ARC-Set header fields in the AMS while we're at it?=C2= =A0 That seems like a plausible idea. =C2=A0
<= br>
The AMS was arrived at incrementally, as was the AAR (origina= lly there was just one AAR, not a full chain).=C2=A0 I guess it's not r= equired, though I'm not sure about the harmful part.

Brandon

--001a114739ac32ea3c0550c51579-- From nobody Tue May 30 16:17:25 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 7CCFA1294A4 for ; Tue, 30 May 2017 16:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j46nLpVMaGH for ; Tue, 30 May 2017 16:17:22 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003: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 8E8351201F8 for ; Tue, 30 May 2017 16:17:22 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h4so509358oib.3 for ; Tue, 30 May 2017 16:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oS6LBWJi1yFo6W0WVuua0R5QOTarNyD6V/QfxXe6wg8=; b=LVlaIUlEU3nlu1YpKc4IM5JE8D5qhAvVkcn4kUbf62FyiFKeh4oMXrHLKMqky14mXS Fimh9PgykI0eDOEB5SkxOAzsJ55dHmkgJZFJ5qJr53P0f9CJYGaBT1FQobpNuYKWARw0 gB0wywC7e6JvliZJ6eFIxFJnn6T1HuHkPR3HMaXhM4HsW+zbLTmjzyUkEZ5CXYf+gvUp ywk0oPZb/evauUrqY50yP9f/IDxVgAXw6f8SgoK9HMR1tEzv2XO97UcpebM+XH11siWg xBxpnMi+IHPhKUHDhbMozOVTWiCINfgZcPZHlpeo5hlVrXIATN+bS5EOV65A+U6krMkG iGPg== 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=oS6LBWJi1yFo6W0WVuua0R5QOTarNyD6V/QfxXe6wg8=; b=Q7xYus5lFLWi1XoHTCkXsPAnrg5B0yzxhcLA8OYDDOhDP6ibCqbJ0XNQUJslHVPI8K grMhBHJEzf3S17tgjUfcAJZTiEgToBrWGmuV/NKcRJ109p7vbYvQ/3IIR/yA/neQEY8L 5uNpUhVaNME/NOaHQVeMnLekZWDpMyly7y/w1FWDSWzWy60sBjHaccawmsblrCIUQueQ lLYIgb+IBuk61T2FV4JftI3mIxNMjcow6A2Y6uWEaXuW7C2zWR3W+0y63bYCG7kOpb8U LduUaZ/oPE2Q/BEJb8oNFU5fABKeg0mN6K/0qbJO1wBYZaFr7d2sL8DVcbYeUT1ikDBz LAaQ== X-Gm-Message-State: AODbwcDJhSqvugXFixmxgxoaSSlwmHzgVABeuz8cd7wW1hO8y9fij1/C 4atEHZBxgpICkKYPeL34wJW92KRrNdiZ X-Received: by 10.157.62.15 with SMTP id a15mr1594780otd.60.1496186241542; Tue, 30 May 2017 16:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 16:17:21 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Tue, 30 May 2017 16:17:21 -0700 Message-ID: To: Gene Shuman Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045e5c487295150550c60166" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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: Tue, 30 May 2017 23:17:24 -0000 --f403045e5c487295150550c60166 Content-Type: text/plain; charset="UTF-8" So, history, the concepts of ARC come from the XOAR as implemented by Google. There, there is the XOAR header and it's covered by the X-Google-DKIM-Signature header. This translated to the AAR covered by AMS. ARC obviously has the second layer with the AS, which seems likely to provide the same level of protection. I don't really see the implementation challenge with requiring this, but I'm open to removal if there is no utility to it. I'm trying to think through scenarios to see if there's anything stronger that this gives us, but I haven't seen any yet. AMS covering AAR means that you could "trust" the AAR even if the chain itself is compromised, but we've typically said "a broken chain should be ignored", and I think that statement should still hold. There is the oddness that the AS and AMR don't have any requirements to be the same. With AAR not covered by AMS, you could replace the AAR/AS for a hop, and sign the AS with a different key. That means the AAR's trust vector is just the AS and not both (AS/AMS). Brandon On Tue, May 30, 2017 at 3:11 PM, Gene Shuman wrote: > The two list approach to configuration actually seems sensible in general, > I'll discuss this with msk. > > However, if the recommended AAR inclusion language accomplishes nothing, > shouldn't we remove it, regardless? > > On Tue, May 30, 2017 at 3:00 PM, Brandon Long wrote: > >> >> >> On Tue, May 30, 2017 at 1:35 PM, Gene Shuman wrote: >> >>> So I'm actively doing development on OpenARC right now, and this >>> definitely something that is being a source of some non-trivial >>> awkwardness. >>> >>> Can anybody recall why the aforementioned language of recommending >>> including the AAR's in the AMS is in there? Afaik, it seems to make no >>> sense, and is causing some implementation specific awkwardness wrt both >>> OpenARC & the test suite. >>> >>> So one would expect that for an ARC implementation, we would want a >>> simple configuration option that tells us which headers to sign. I believe >>> OpenDKIM behaves in exactly this fashion. And it needs to be able to >>> include duplicates, as that's a require feature of the rfc. But this >>> recommendation to include AAR's in the list makes this awkward, as, as we >>> can't configure this in a similar fashion, as we dont know how many AAR's >>> are in messages a prior. >>> >> >> I think this is broken. Why would you ever configure "only sign two >> copies of this header, but not three"? I'd expect two lists, one of which >> headers to sign, and one of which headers to add as empty to prevent extra >> copies of the header to be added. Ie, in dkimpy, that's the SHOULD and >> FROZEN lists. >> >> >>> So either an implementation will either need some AAR inclusion >>> configuration option, independent of the other h= configuration list, or it >>> needs to make some internal decision of whether to be signing these headers >>> or not. The first option is awkward & seems just kind of needlessly >>> complex. And I'm also not a fan of implementations making this kind of >>> decision internally, as I think its important from a testing standpoint to >>> have the output headers be predictable. >>> >>> So can anybody recall why this language is there? It seems kind of >>> pointless in the best case, and slightly harmful in the worst. Unless >>> somebody has a reason for it being there, I suggest we remove it. Or why >>> not just actively forbid the inclusion of all ARC-Set header fields in the >>> AMS while we're at it? That seems like a plausible idea. >>> >> >> The AMS was arrived at incrementally, as was the AAR (originally there >> was just one AAR, not a full chain). I guess it's not required, though I'm >> not sure about the harmful part. >> >> Brandon >> > > --f403045e5c487295150550c60166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, history, the concepts of ARC come from the XOAR as imp= lemented by Google.

There, there is the XOAR header and = it's covered by the X-Google-DKIM-Signature header.=C2=A0 This translat= ed to the AAR covered by AMS.=C2=A0 ARC obviously has the second layer with= the AS, which seems likely to provide the same level of protection.
<= div>
I don't really see the implementation challenge with= requiring this, but I'm open to removal if there is no utility to it.<= /div>

I'm trying to think through scenarios to see i= f there's anything stronger that this gives us, but I haven't seen = any yet.

AMS covering AAR means that you could &qu= ot;trust" the AAR even if the chain itself is compromised, but we'= ve typically said "a broken chain should be ignored", and I think= that
statement should still hold.

There= is the oddness that the AS and AMR don't have any requirements to be t= he same.=C2=A0 With AAR not covered by AMS, you could replace the AAR/AS fo= r a hop, and sign the AS with a different key.=C2=A0 That means the AAR'= ;s trust vector is just the AS and not both (AS/AMS).

<= div>Brandon

On Tue, May 30, 2017 at 3:11 PM, Gene Shuman <gene@valimail.com&= gt; wrote:
The tw= o list approach to configuration actually seems sensible in general, I'= ll discuss this with msk. =C2=A0

However, if the recomme= nded AAR inclusion language accomplishes nothing, shouldn't we remove i= t, regardless?

On Tue, May 30, 2017 at 3:= 00 PM, Brandon Long <blong@google.com> wrote:


On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <gene@= valimail.com> wrote:
So I'm actively doing development on OpenARC right now, and = this definitely something that is being a source of some non-trivial awkwar= dness. =C2=A0

Can anybody recall why the aforementioned = language of recommending including the AAR's in the AMS is in there?=C2= =A0 Afaik, it seems to make no sense, and is causing some implementation sp= ecific awkwardness wrt both OpenARC & the test suite. =C2=A0
=
So one would expect that for an ARC implementation, we would= want a simple configuration option that tells us which headers to sign.=C2= =A0 I believe OpenDKIM behaves in exactly this fashion.=C2=A0 And it needs = to be able to include duplicates, as that's a require feature of the rf= c.=C2=A0 But this recommendation to include AAR's in the list makes thi= s awkward, as, as we can't configure this in a similar fashion, as we d= ont know how many AAR's are in messages a prior.

I think this is broken.=C2=A0 Why would you ever conf= igure "only sign two copies of this header, but not three"?=C2=A0= I'd expect two lists, one of which headers to sign, and one of which h= eaders to add as empty to prevent extra copies of the header to be added.= =C2=A0 Ie, in dkimpy, that's the SHOULD and FROZEN lists.
=C2= =A0
So either an = implementation will either need some AAR inclusion configuration option, in= dependent of the other h=3D configuration list, or it needs to make some in= ternal decision of whether to be signing these headers or not.=C2=A0 The fi= rst option is awkward & seems just kind of needlessly complex.=C2=A0 An= d I'm also not a fan of implementations making this kind of decision in= ternally, as I think its important from a testing standpoint to have the ou= tput headers be predictable. =C2=A0

So can anybody= recall why this language is there?=C2=A0 It seems kind of pointless in the= best case, and slightly harmful in the worst.=C2=A0 Unless somebody has a = reason for it being there, I suggest we remove it.=C2=A0 Or why not just ac= tively forbid the inclusion of all ARC-Set header fields in the AMS while w= e're at it?=C2=A0 That seems like a plausible idea. =C2=A0
<= /blockquote>

The AMS was arrived at incrementally, as wa= s the AAR (originally there was just one AAR, not a full chain).=C2=A0 I gu= ess it's not required, though I'm not sure about the harmful part.<= /div>
Brandon


--f403045e5c487295150550c60166-- From nobody Tue May 30 16:43: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 B558912945A for ; Tue, 30 May 2017 16:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh8cJpjw8joJ for ; Tue, 30 May 2017 16:43:26 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B733120046 for ; Tue, 30 May 2017 16:43:26 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id b204so1096416oii.1 for ; Tue, 30 May 2017 16:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ESSbgPR0dLnMLVRqs4+pqGvVHMH2TKUHqR3GeQsMcsA=; b=o+jZKtVxPv1yMx36Mi2daxG57IuZvahPEEpIqlGd3UGMKcSd+hDmUujcrKZ12Zupr0 TiF6/srmvWIBkJ1z9BjKJVaOIqUVSAfPYbbBL3CVnbkaLkvHClgIrKJkKzYrhFAN1x1/ kdJRNPhfjfD6qcXOdSyvVswxpdxTl4cdYXj/JfLyUX337fqHXQxsBk1p+RRe0eRx7KSb 8JPeYv2sfVJwsybRqKf+JAPmGhSDZ9qUtsbzRXR9vF0EtFYmkiyY8YXdlXoLeDxOwCe9 iO/BWPgkskV6K+OnK/WIoiyrzEAsetfWlUk42t3DLhK1Q/Yy/KOqU20fIAKE4SJ2KMmH s5iQ== 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=ESSbgPR0dLnMLVRqs4+pqGvVHMH2TKUHqR3GeQsMcsA=; b=KACrj1T/4b1an+zgwHV71fLfyDvusNKDtjOc/ANlPX2XA3HsU2Oy7l51+NwJHChUvp 4C0NN5D/tSmWwBCbXzM9zcBX2VOG3lYTMj2Fq4FWGMtI3n1PAvoCgvuG6gKCfo9qr6nB EGCbqwwX6sUT1B3LyUnKVCVsOElWvVjZIulpwImZXKJ21AdZfr5RzpASeCpVVO4EfI7E xvar+j2gYzOgDAXyKK2NrXXl6+IiOaiEYemjVfFdoussKEH4IGWA5U1DIMqbly2yjVTc WAnilUTBPLvLf5IgmjchkdRRaXNPpd5oefnnpfsSXxh4a3N9cqHYItGuu0y+eQ4Ftwem BWCQ== X-Gm-Message-State: AODbwcCOPX4QqY/nOg7nDD4Et05EaY2mm6oOyfCKZGx8mQh2jw0bt2BO FX1VH0/ecoIzgi8TSThOzbPak+iEM7AybLQ= X-Received: by 10.157.47.195 with SMTP id b3mr5488548otd.78.1496187805244; Tue, 30 May 2017 16:43:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 16:43:24 -0700 (PDT) In-Reply-To: <1927341.Yq1D0kyESZ@kitterma-e6430> References: <34808716.2nE2qoVfF5@kitterma-e6430> <1927341.Yq1D0kyESZ@kitterma-e6430> From: Brandon Long Date: Tue, 30 May 2017 16:43:24 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113db9e4a67c940550c65e29" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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: Tue, 30 May 2017 23:43:29 -0000 --001a113db9e4a67c940550c65e29 Content-Type: text/plain; charset="UTF-8" I'm not clear, are you saying requiring the header.b for every dkim resinfo in the AAR, or requiring it for the arc=result resinfo? It has always seemed odd to me that the spf one didn't include the IP as well, since it's certainly input, I guess I should go archive spelunking again. Brandon On Tue, May 30, 2017 at 2:14 PM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: > > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman > > > > wrote: > > > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > > > The current spec defines an arc authres method ( > > > > > > https://tools.ietf.org/html/ > > > > > > > draft-ietf-dmarc-arc-protocol-03#section-8.1). > > > > > > > > We believe there should also be registered ptypes and properties, > that > > > > should be stamped (but are not required, as they won't always be > > > > > > available). > > > > > > > As long as AR stamping happens at the end of chain validation, when > an > > > > > > ARC > > > > > > > set gets created this stamp will be included in the AAR, and AAR > > > > construction can be clean with no additional language or requirements > > > > necessary in the spec. > > > > > > > > What follows below is not sacred, we're just trying to start the > > > > conversation. > > > > > > > > Based upon previous threads (specifically, Brandon's reporting > > > > > > local_policy > > > > > > > thread from May 4th PST) surrounding the AAR and data the WG thought > > > > > > would > > > > > > > be valuable for final receivers and DMARC reports, it looks like > > > > stamping > > > > header.b for each dkim signature on the message and smtp.client-id > for > > > > > > the > > > > > > > ip address of the originating mail server (if available) would > provide > > > > nearly everything asked for with minimal implementation overhead > (and no > > > > change to spec except for the IANA registration, and an addition for > > > > RECOMMENDED stamping if warranted). > > > > > > > > To dig in to the reasoning behind these two properties: > > > > > > > > 1) header.b > > > > > > > > At the end of an ARC chain, there might be many DKIM signatures on > the > > > > message, nearly all of which could be broken on receipt. > Additionally, > > > > since there have been multiple hops, it is possible to have several > > > > > > broken > > > > > > > DKIM signatures with the same header.d value that are representative > of > > > > different services at different hops. > > > > > > > > If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b > of > > > > every dkim key on the message, then it becomes super clear which keys > > > > > > were > > > > > > > added when, and which dkim pass/fail statuses correspond to which > keys > > > > so > > > > it can be determined when any individual signature broke. > > > > > > > > This is extremely useful as a reporter to help identify broken > services > > > > > > at > > > > > > > any stage of DMARC enforcement, and is probably useful for final > > > > > > receivers > > > > > > > reviewing the chain to determine final message disposition; without > this > > > > information all the DKIM-Signatures on a message that do not validate > > > > and > > > > share the same header.d are indistinguishable. > > > > > > > > This stamp removes this ambiguity and adds reporting and trace value. > > > > > > > > > > > > 2) smtp.client-id > > > > > > > > The goal here is to track the originating source_ip for DMARC > > > > categorization and reporting. Otherwise, all ARC messages will have a > > > > > > DMARC > > > > > > > report source_ip of the last forwarder, not the originating service. > > > > This > > > > will be exceptionally confusing to consumers of DMARC reports. > > > > > > > > We know that including an IP address in Authentication-Results has > been > > > > persona-non-grata in the past, as authentication results are > supposed to > > > > encapsulate the results of an authentication check, not information > that > > > > could be used to re-run the authentication downstream. > > > > > > > > However, we believe that the client-id is vital trace information for > > > > ARC > > > > and DMARC, is useful for categorizing senders within a DMARC report, > and > > > > > > is > > > > > > > valuable at p=none, p=quarantine, and p=reject, and as such makes > sense > > > > within and contained to the ARC stamp. > > > > > > > > Ultimately, if this stamp is wrong for the AR, the client-id could be > > > > > > added > > > > > > > directly in the AAR. The AR stamp is cleaner because it leaves the > AAR > > > > generation and spec untouched. > > > > > > > > > > > > We know there will be disagreement about what to stamp, and welcome > > > > discussion on what's best to track within an AR header as arc status. > > > > > > > > I'm happy to suggest language once there's rough consensus in the > group. > > > > > > When msk initially defined the Authentication Results header field, I > was > > > a > > > strong proponent of including trace elements, but was in the rough as > it > > > comes > > > to the consensus. In retrospect, I think he was correct. > > > > > > AAR can't truly be a trace header (you'd have to include the entire > > > unmodified > > > message with the original DKIM signature to make the DMARC inputs > > > traceable). > > > I'm not sure it's worth doing it half-way. > > > > I don't want the AR payload to be about trace information; I want to make > > sure it encapsulates the proper authentication results and statuses. So > > that a DMARC report after an ARC message has been processed has the > > appropriate information that's valuable to a report consumer. > > > > - At p=none this means understanding the originating sender and if any > > originating authentication mechanisms were broken. This means passing > > through an smtp.client_id and the header.b's. > > > > - At p=quarantine|reject, for a failing message that passes arc, I think > > the status quo works (although having header.b here to understand which > > keys signed the message when could be useful). > > > > - At p=quarantine|reject, for a failing message that fails arc, it's > useful > > to know where/why the message failed. Again, header.b's shine light on > this > > and can make the DMARC report useful for determining/fixing a broken > > originating sender or intermediary. > > > > Passing this information through (and to me it's not trace if it's there > > for a user to interact with in a DMARC report - although there's > definitely > > additional trace value, that's not the primary purpose here) is extremely > > valuable for the report consumer. > > > > My concern is putting it anywhere other than the AR/AAR could creative > > feature/spec creep, and waiting to see what happens and writing a spec > for > > stamping later just leaves room open for complaints that, even after ARC, > > DMARC is still broken with respect to reporting on mailing list and > > forwarders. > > > > > I'm particularly not convinced about source_ip. DMARC reports are > > > organized > > > by 5322.From and when I'm reviewing reports what I care about is where > the > > > reporting receiver got it from. That's already covered. > > > > I'm not certain I'm sold either. Especially because many implementations > > won't even have access to the IP. For instance, Mailman3 does not have > > access to the source_ip of the smtp connection (that data doesn't come > over > > LMTP), so no mailman software would ever be able to stamp this. > > > > I think the source_ip is valuable to provide, especially for a final > > consumer of a report, but 1) it's not always available, 2) it doesn't > seem > > perfect to put into an AR header. > > > > Thoughts? > > > > > I don't see anything that might support trace uses that has to be in > the > > > initial specification. It can be added later if there's a need. > > > > I think stamping header.b has real value as outlined above. > > > > I think smtp.client_id also has value, but definitely see the arguments > > from both sides. > > So header.b only gives an explicit way to link an (A)AR header field with a > signature, so there's no need to guess what's related within the message. > Now > that I've read your rationale and gone and read RFC 6008 again, I agree > that > makes sense to include in AAR. It might even be a good idea to make it > mandatory since there is (for the purposes of IETF standardization) no > installed base to worry about. > > Source IP, I still this is only for trace purposes and should be out of > scope > (I have a hard time justifying why it would be out of scope for SPF (which > is > what the working group and later IETF consensus was) and in scope here. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a113db9e4a67c940550c65e29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not clear, are you saying requiring the header.b f= or every dkim resinfo in the AAR, or requiring it for the arc=3Dresult resi= nfo?

It has always seemed odd to me that the spf on= e didn't include the IP as well, since it's certainly input, I gues= s I should go archive spelunking again.

Brandon

On= Tue, May 30, 2017 at 2:14 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote:
> > > The current spec defines an arc authres method (
> >
> > https://tools.ietf.org/html/
> >
> > > draft-ietf-dmarc-arc-protocol-03#section-8.1).
> > >
> > > We believe there should also be registered ptypes and proper= ties, that
> > > should be stamped (but are not required, as they won't a= lways be
> >
> > available).
> >
> > > As long as AR stamping happens at the end of chain validatio= n, when an
> >
> > ARC
> >
> > > set gets created this stamp will be included in the AAR, and= AAR
> > > construction can be clean with no additional language or req= uirements
> > > necessary in the spec.
> > >
> > > What follows below is not sacred, we're just trying to s= tart the
> > > conversation.
> > >
> > > Based upon previous threads (specifically, Brandon's rep= orting
> >
> > local_policy
> >
> > > thread from May 4th PST) surrounding the AAR and data the WG= thought
> >
> > would
> >
> > > be valuable for final receivers and DMARC reports, it looks = like
> > > stamping
> > > header.b for each dkim signature on the message and smtp.cli= ent-id for
> >
> > the
> >
> > > ip address of the originating mail server (if available) wou= ld provide
> > > nearly everything asked for with minimal implementation over= head (and no
> > > change to spec except for the IANA registration, and an addi= tion for
> > > RECOMMENDED stamping if warranted).
> > >
> > > To dig in to the reasoning behind these two properties:
> > >
> > > 1) header.b
> > >
> > > At the end of an ARC chain, there might be many DKIM signatu= res on the
> > > message, nearly all of which could be broken on receipt. Add= itionally,
> > > since there have been multiple hops, it is possible to have = several
> >
> > broken
> >
> > > DKIM signatures with the same header.d value that are repres= entative of
> > > different services at different hops.
> > >
> > > If each hop stamps the https://tools.ietf.org/html= /rfc6008 header.b of
> > > every dkim key on the message, then it becomes super clear w= hich keys
> >
> > were
> >
> > > added when, and which dkim pass/fail statuses correspond to = which keys
> > > so
> > > it can be determined when any individual signature broke. > > >
> > > This is extremely useful as a reporter to help identify brok= en services
> >
> > at
> >
> > > any stage of DMARC enforcement, and is probably useful for f= inal
> >
> > receivers
> >
> > > reviewing the chain to determine final message disposition; = without this
> > > information all the DKIM-Signatures on a message that do not= validate
> > > and
> > > share the same header.d are indistinguishable.
> > >
> > > This stamp removes this ambiguity and adds reporting and tra= ce value.
> > >
> > >
> > > 2) smtp.client-id
> > >
> > > The goal here is to track the originating source_ip for DMAR= C
> > > categorization and reporting. Otherwise, all ARC messages wi= ll have a
> >
> > DMARC
> >
> > > report source_ip of the last forwarder, not the originating = service.
> > > This
> > > will be exceptionally confusing to consumers of DMARC report= s.
> > >
> > > We know that including an IP address in Authentication-Resul= ts has been
> > > persona-non-grata in the past, as authentication results are= supposed to
> > > encapsulate the results of an authentication check, not info= rmation that
> > > could be used to re-run the authentication downstream.
> > >
> > > However, we believe that the client-id is vital trace inform= ation for
> > > ARC
> > > and DMARC, is useful for categorizing senders within a DMARC= report, and
> >
> > is
> >
> > > valuable at p=3Dnone, p=3Dquarantine, and p=3Dreject, and as= such makes sense
> > > within and contained to the ARC stamp.
> > >
> > > Ultimately, if this stamp is wrong for the AR, the client-id= could be
> >
> > added
> >
> > > directly in the AAR. The AR stamp is cleaner because it leav= es the AAR
> > > generation and spec untouched.
> > >
> > >
> > > We know there will be disagreement about what to stamp, and = welcome
> > > discussion on what's best to track within an AR header a= s arc status.
> > >
> > > I'm happy to suggest language once there's rough con= sensus in the group.
> >
> > When msk initially defined the Authentication Results header fiel= d, I was
> > a
> > strong proponent of including trace elements, but was in the roug= h as it
> > comes
> > to the consensus.=C2=A0 In retrospect, I think he was correct. > >
> > AAR can't truly be a trace header (you'd have to include = the entire
> > unmodified
> > message with the original DKIM signature to make the DMARC inputs=
> > traceable).
> > I'm not sure it's worth doing it half-way.
>
> I don't want the AR payload to be about trace information; I want = to make
> sure it encapsulates the proper authentication results and statuses. S= o
> that a DMARC report after an ARC message has been processed has the > appropriate information that's valuable to a report consumer.
>
> - At p=3Dnone this means understanding the originating sender and if a= ny
> originating authentication mechanisms were broken. This means passing<= br> > through an smtp.client_id and the header.b's.
>
> - At p=3Dquarantine|reject, for a failing message that passes arc, I t= hink
> the status quo works (although having header.b here to understand whic= h
> keys signed the message when could be useful).
>
> - At p=3Dquarantine|reject, for a failing message that fails arc, it&#= 39;s useful
> to know where/why the message failed. Again, header.b's shine ligh= t on this
> and can make the DMARC report useful for determining/fixing a broken > originating sender or intermediary.
>
> Passing this information through (and to me it's not trace if it&#= 39;s there
> for a user to interact with in a DMARC report - although there's d= efinitely
> additional trace value, that's not the primary purpose here) is ex= tremely
> valuable for the report consumer.
>
> My concern is putting it anywhere other than the AR/AAR could creative=
> feature/spec creep, and waiting to see what happens and writing a spec= for
> stamping later just leaves room open for complaints that, even after A= RC,
> DMARC is still broken with respect to reporting on mailing list and > forwarders.
>
> > I'm particularly not convinced about source_ip.=C2=A0 DMARC r= eports are
> > organized
> > by 5322.From and when I'm reviewing reports what I care about= is where the
> > reporting receiver got it from.=C2=A0 That's already covered.=
>
> I'm not certain I'm sold either. Especially because many imple= mentations
> won't even have access to the IP. For instance, Mailman3 does not = have
> access to the source_ip of the smtp connection (that data doesn't = come over
> LMTP), so no mailman software would ever be able to stamp this.
>
> I think the source_ip is valuable to provide, especially for a final > consumer of a report, but 1) it's not always available, 2) it does= n't seem
> perfect to put into an AR header.
>
> Thoughts?
>
> > I don't see anything that might support trace uses that has t= o be in the
> > initial specification.=C2=A0 It can be added later if there's= a need.
>
> I think stamping header.b has real value as outlined above.
>
> I think smtp.client_id also has value, but definitely see the argument= s
> from both sides.

So header.b only gives an explicit way to link an (A)AR header = field with a
signature, so there's no need to guess what's related within the me= ssage.=C2=A0 Now
that I've read your rationale and gone and read RFC 6008 again, I agree= that
makes sense to include in AAR.=C2=A0 It might even be a good idea to make i= t
mandatory since there is (for the purposes of IETF standardization) no
installed base to worry about.

Source IP, I still this is only for trace purposes and should be out of sco= pe
(I have a hard time justifying why it would be out of scope for SPF (which = is
what the working group and later IETF consensus was) and in scope here.

Scott K

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

--001a113db9e4a67c940550c65e29-- From nobody Tue May 30 17:06:55 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 08549129493 for ; Tue, 30 May 2017 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 WCSJLR5KsuYv for ; Tue, 30 May 2017 17:06:51 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 62D8012943E for ; Tue, 30 May 2017 17:06:51 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f55so889523qta.3 for ; Tue, 30 May 2017 17:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ALOaLejg6tDJ1C+mjXWS2nDIpJTGffeK8Z2xwLF4T54=; b=dBVS71Mn8dnkFjqvOntvhyT6kNZ18TbG02subSQHNFAu/4qiqOhhR/lYToKfFbjL+l or35ieele7VNhX/8xazr0skkRgMqi2Oe1cH6X2TqrSfmM34OF21Ccc6JZbpeSMtUEm06 lnVYVhlMdaAxy7xaZV1d09+jj+CKEC1u3Qahmnq5SF9eh6264EUV9ZTIuDnpOzj0ZsmP YbWkMJ2PuglN95Twq7Jz8fsdyTzqBWJ5Lgmg2WDjP+L86R3zMV1gO0MmOfAQTXyi/pPJ 1RdumXKtQV+VoV3SiJMES+RQQcCf33WrAHovPUYBiaU6Ss57P4vYMwxD9lDubABtExFE vrzQ== 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=ALOaLejg6tDJ1C+mjXWS2nDIpJTGffeK8Z2xwLF4T54=; b=Hh2DJb/hzxJU27j66ihIbn3tnhOeS3jJs7EF0Clb5xjhTGhUX0jGZh0jGOx09oSaJZ noHboKXA7km5B7F13ieIPPCGxyxxiNwC4s23YO+rKVNjy6TmlPEVboHPUqPvJRPpAG5I JtSGSufnY+5WNgE5XBB8Sb9VQMxzwNZrR+8pLbbqdq+oKVyEAlwzUO2s5ahgSok6uTRk C2faSYHniwRwJyMgaTywGQJTm45t9Tp5HQ9Ov7S/rVMXh/v+Ak47anwiFryC7JeiPvh0 TD7JdkJTKbYEanzhkmWZC+XTFLssLR703XVtw5xjLYBrnfCy4kdCfbB0MjJcGPixZNmY uBsA== X-Gm-Message-State: AODbwcAL+BMid380UGRHIwXdfsk5G50WXw2NX/pNRPLkShGZP07sTZAJ y6HplAIRqVm1C91Y1z5EZUa9uCXivsyzshM= X-Received: by 10.237.34.119 with SMTP id o52mr29070022qtc.217.1496189210289; Tue, 30 May 2017 17:06:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Tue, 30 May 2017 17:06:29 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> <1927341.Yq1D0kyESZ@kitterma-e6430> From: Seth Blank Date: Tue, 30 May 2017 17:06:29 -0700 Message-ID: To: Brandon Long Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113e83f2657bd90550c6b218" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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, 31 May 2017 00:06:54 -0000 --001a113e83f2657bd90550c6b218 Content-Type: text/plain; charset="UTF-8" I mean in the AR arc=result header.b=... header.b=... And then this gets captured in the AAR when a message is signed. Seth On Tue, May 30, 2017 at 4:43 PM, Brandon Long wrote: > I'm not clear, are you saying requiring the header.b for every dkim > resinfo in the AAR, or requiring it for the arc=result resinfo? > > It has always seemed odd to me that the spf one didn't include the IP as > well, since it's certainly input, I guess I should go archive spelunking > again. > > Brandon > > On Tue, May 30, 2017 at 2:14 PM, Scott Kitterman > wrote: > >> On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote: >> > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman > > >> > >> > wrote: >> > > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: >> > > > The current spec defines an arc authres method ( >> > > >> > > https://tools.ietf.org/html/ >> > > >> > > > draft-ietf-dmarc-arc-protocol-03#section-8.1). >> > > > >> > > > We believe there should also be registered ptypes and properties, >> that >> > > > should be stamped (but are not required, as they won't always be >> > > >> > > available). >> > > >> > > > As long as AR stamping happens at the end of chain validation, when >> an >> > > >> > > ARC >> > > >> > > > set gets created this stamp will be included in the AAR, and AAR >> > > > construction can be clean with no additional language or >> requirements >> > > > necessary in the spec. >> > > > >> > > > What follows below is not sacred, we're just trying to start the >> > > > conversation. >> > > > >> > > > Based upon previous threads (specifically, Brandon's reporting >> > > >> > > local_policy >> > > >> > > > thread from May 4th PST) surrounding the AAR and data the WG thought >> > > >> > > would >> > > >> > > > be valuable for final receivers and DMARC reports, it looks like >> > > > stamping >> > > > header.b for each dkim signature on the message and smtp.client-id >> for >> > > >> > > the >> > > >> > > > ip address of the originating mail server (if available) would >> provide >> > > > nearly everything asked for with minimal implementation overhead >> (and no >> > > > change to spec except for the IANA registration, and an addition for >> > > > RECOMMENDED stamping if warranted). >> > > > >> > > > To dig in to the reasoning behind these two properties: >> > > > >> > > > 1) header.b >> > > > >> > > > At the end of an ARC chain, there might be many DKIM signatures on >> the >> > > > message, nearly all of which could be broken on receipt. >> Additionally, >> > > > since there have been multiple hops, it is possible to have several >> > > >> > > broken >> > > >> > > > DKIM signatures with the same header.d value that are >> representative of >> > > > different services at different hops. >> > > > >> > > > If each hop stamps the https://tools.ietf.org/html/rfc6008 >> header.b of >> > > > every dkim key on the message, then it becomes super clear which >> keys >> > > >> > > were >> > > >> > > > added when, and which dkim pass/fail statuses correspond to which >> keys >> > > > so >> > > > it can be determined when any individual signature broke. >> > > > >> > > > This is extremely useful as a reporter to help identify broken >> services >> > > >> > > at >> > > >> > > > any stage of DMARC enforcement, and is probably useful for final >> > > >> > > receivers >> > > >> > > > reviewing the chain to determine final message disposition; without >> this >> > > > information all the DKIM-Signatures on a message that do not >> validate >> > > > and >> > > > share the same header.d are indistinguishable. >> > > > >> > > > This stamp removes this ambiguity and adds reporting and trace >> value. >> > > > >> > > > >> > > > 2) smtp.client-id >> > > > >> > > > The goal here is to track the originating source_ip for DMARC >> > > > categorization and reporting. Otherwise, all ARC messages will have >> a >> > > >> > > DMARC >> > > >> > > > report source_ip of the last forwarder, not the originating service. >> > > > This >> > > > will be exceptionally confusing to consumers of DMARC reports. >> > > > >> > > > We know that including an IP address in Authentication-Results has >> been >> > > > persona-non-grata in the past, as authentication results are >> supposed to >> > > > encapsulate the results of an authentication check, not information >> that >> > > > could be used to re-run the authentication downstream. >> > > > >> > > > However, we believe that the client-id is vital trace information >> for >> > > > ARC >> > > > and DMARC, is useful for categorizing senders within a DMARC >> report, and >> > > >> > > is >> > > >> > > > valuable at p=none, p=quarantine, and p=reject, and as such makes >> sense >> > > > within and contained to the ARC stamp. >> > > > >> > > > Ultimately, if this stamp is wrong for the AR, the client-id could >> be >> > > >> > > added >> > > >> > > > directly in the AAR. The AR stamp is cleaner because it leaves the >> AAR >> > > > generation and spec untouched. >> > > > >> > > > >> > > > We know there will be disagreement about what to stamp, and welcome >> > > > discussion on what's best to track within an AR header as arc >> status. >> > > > >> > > > I'm happy to suggest language once there's rough consensus in the >> group. >> > > >> > > When msk initially defined the Authentication Results header field, I >> was >> > > a >> > > strong proponent of including trace elements, but was in the rough as >> it >> > > comes >> > > to the consensus. In retrospect, I think he was correct. >> > > >> > > AAR can't truly be a trace header (you'd have to include the entire >> > > unmodified >> > > message with the original DKIM signature to make the DMARC inputs >> > > traceable). >> > > I'm not sure it's worth doing it half-way. >> > >> > I don't want the AR payload to be about trace information; I want to >> make >> > sure it encapsulates the proper authentication results and statuses. So >> > that a DMARC report after an ARC message has been processed has the >> > appropriate information that's valuable to a report consumer. >> > >> > - At p=none this means understanding the originating sender and if any >> > originating authentication mechanisms were broken. This means passing >> > through an smtp.client_id and the header.b's. >> > >> > - At p=quarantine|reject, for a failing message that passes arc, I think >> > the status quo works (although having header.b here to understand which >> > keys signed the message when could be useful). >> > >> > - At p=quarantine|reject, for a failing message that fails arc, it's >> useful >> > to know where/why the message failed. Again, header.b's shine light on >> this >> > and can make the DMARC report useful for determining/fixing a broken >> > originating sender or intermediary. >> > >> > Passing this information through (and to me it's not trace if it's there >> > for a user to interact with in a DMARC report - although there's >> definitely >> > additional trace value, that's not the primary purpose here) is >> extremely >> > valuable for the report consumer. >> > >> > My concern is putting it anywhere other than the AR/AAR could creative >> > feature/spec creep, and waiting to see what happens and writing a spec >> for >> > stamping later just leaves room open for complaints that, even after >> ARC, >> > DMARC is still broken with respect to reporting on mailing list and >> > forwarders. >> > >> > > I'm particularly not convinced about source_ip. DMARC reports are >> > > organized >> > > by 5322.From and when I'm reviewing reports what I care about is >> where the >> > > reporting receiver got it from. That's already covered. >> > >> > I'm not certain I'm sold either. Especially because many implementations >> > won't even have access to the IP. For instance, Mailman3 does not have >> > access to the source_ip of the smtp connection (that data doesn't come >> over >> > LMTP), so no mailman software would ever be able to stamp this. >> > >> > I think the source_ip is valuable to provide, especially for a final >> > consumer of a report, but 1) it's not always available, 2) it doesn't >> seem >> > perfect to put into an AR header. >> > >> > Thoughts? >> > >> > > I don't see anything that might support trace uses that has to be in >> the >> > > initial specification. It can be added later if there's a need. >> > >> > I think stamping header.b has real value as outlined above. >> > >> > I think smtp.client_id also has value, but definitely see the arguments >> > from both sides. >> >> So header.b only gives an explicit way to link an (A)AR header field with >> a >> signature, so there's no need to guess what's related within the >> message. Now >> that I've read your rationale and gone and read RFC 6008 again, I agree >> that >> makes sense to include in AAR. It might even be a good idea to make it >> mandatory since there is (for the purposes of IETF standardization) no >> installed base to worry about. >> >> Source IP, I still this is only for trace purposes and should be out of >> scope >> (I have a hard time justifying why it would be out of scope for SPF >> (which is >> what the working group and later IETF consensus was) and in scope here. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113e83f2657bd90550c6b218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mean in the AR arc=3Dresult header.b=3D... header.b=3D..= .

And then this gets captured in the AAR when a message = is signed.

Seth

On Tue, May 30, 2017 at 4:43 PM, Brandon= Long <blong@google.com> wrote:
I'm not clear, are you saying requiring the heade= r.b for every dkim resinfo in the AAR, or requiring it for the arc=3Dresult= resinfo?

It has always seemed odd to me that the s= pf one didn't include the IP as well, since it's certainly input, I= guess I should go archive spelunking again.

Brandon
=
On Tue, May 30, 2017 at 2:14 PM, Scott Kitterm= an <sklist@kitterman.com> wrote:
On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote:
> On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote:
> > > The current spec defines an arc authres method (
> >
> > https://tools.ietf.org/html/
> >
> > > draft-ietf-dmarc-arc-protocol-03#section-8.1).
> > >
> > > We believe there should also be registered ptypes and proper= ties, that
> > > should be stamped (but are not required, as they won't a= lways be
> >
> > available).
> >
> > > As long as AR stamping happens at the end of chain validatio= n, when an
> >
> > ARC
> >
> > > set gets created this stamp will be included in the AAR, and= AAR
> > > construction can be clean with no additional language or req= uirements
> > > necessary in the spec.
> > >
> > > What follows below is not sacred, we're just trying to s= tart the
> > > conversation.
> > >
> > > Based upon previous threads (specifically, Brandon's rep= orting
> >
> > local_policy
> >
> > > thread from May 4th PST) surrounding the AAR and data the WG= thought
> >
> > would
> >
> > > be valuable for final receivers and DMARC reports, it looks = like
> > > stamping
> > > header.b for each dkim signature on the message and smtp.cli= ent-id for
> >
> > the
> >
> > > ip address of the originating mail server (if available) wou= ld provide
> > > nearly everything asked for with minimal implementation over= head (and no
> > > change to spec except for the IANA registration, and an addi= tion for
> > > RECOMMENDED stamping if warranted).
> > >
> > > To dig in to the reasoning behind these two properties:
> > >
> > > 1) header.b
> > >
> > > At the end of an ARC chain, there might be many DKIM signatu= res on the
> > > message, nearly all of which could be broken on receipt. Add= itionally,
> > > since there have been multiple hops, it is possible to have = several
> >
> > broken
> >
> > > DKIM signatures with the same header.d value that are repres= entative of
> > > different services at different hops.
> > >
> > > If each hop stamps the https://tools.ietf.org/html= /rfc6008 header.b of
> > > every dkim key on the message, then it becomes super clear w= hich keys
> >
> > were
> >
> > > added when, and which dkim pass/fail statuses correspond to = which keys
> > > so
> > > it can be determined when any individual signature broke. > > >
> > > This is extremely useful as a reporter to help identify brok= en services
> >
> > at
> >
> > > any stage of DMARC enforcement, and is probably useful for f= inal
> >
> > receivers
> >
> > > reviewing the chain to determine final message disposition; = without this
> > > information all the DKIM-Signatures on a message that do not= validate
> > > and
> > > share the same header.d are indistinguishable.
> > >
> > > This stamp removes this ambiguity and adds reporting and tra= ce value.
> > >
> > >
> > > 2) smtp.client-id
> > >
> > > The goal here is to track the originating source_ip for DMAR= C
> > > categorization and reporting. Otherwise, all ARC messages wi= ll have a
> >
> > DMARC
> >
> > > report source_ip of the last forwarder, not the originating = service.
> > > This
> > > will be exceptionally confusing to consumers of DMARC report= s.
> > >
> > > We know that including an IP address in Authentication-Resul= ts has been
> > > persona-non-grata in the past, as authentication results are= supposed to
> > > encapsulate the results of an authentication check, not info= rmation that
> > > could be used to re-run the authentication downstream.
> > >
> > > However, we believe that the client-id is vital trace inform= ation for
> > > ARC
> > > and DMARC, is useful for categorizing senders within a DMARC= report, and
> >
> > is
> >
> > > valuable at p=3Dnone, p=3Dquarantine, and p=3Dreject, and as= such makes sense
> > > within and contained to the ARC stamp.
> > >
> > > Ultimately, if this stamp is wrong for the AR, the client-id= could be
> >
> > added
> >
> > > directly in the AAR. The AR stamp is cleaner because it leav= es the AAR
> > > generation and spec untouched.
> > >
> > >
> > > We know there will be disagreement about what to stamp, and = welcome
> > > discussion on what's best to track within an AR header a= s arc status.
> > >
> > > I'm happy to suggest language once there's rough con= sensus in the group.
> >
> > When msk initially defined the Authentication Results header fiel= d, I was
> > a
> > strong proponent of including trace elements, but was in the roug= h as it
> > comes
> > to the consensus.=C2=A0 In retrospect, I think he was correct. > >
> > AAR can't truly be a trace header (you'd have to include = the entire
> > unmodified
> > message with the original DKIM signature to make the DMARC inputs=
> > traceable).
> > I'm not sure it's worth doing it half-way.
>
> I don't want the AR payload to be about trace information; I want = to make
> sure it encapsulates the proper authentication results and statuses. S= o
> that a DMARC report after an ARC message has been processed has the > appropriate information that's valuable to a report consumer.
>
> - At p=3Dnone this means understanding the originating sender and if a= ny
> originating authentication mechanisms were broken. This means passing<= br> > through an smtp.client_id and the header.b's.
>
> - At p=3Dquarantine|reject, for a failing message that passes arc, I t= hink
> the status quo works (although having header.b here to understand whic= h
> keys signed the message when could be useful).
>
> - At p=3Dquarantine|reject, for a failing message that fails arc, it&#= 39;s useful
> to know where/why the message failed. Again, header.b's shine ligh= t on this
> and can make the DMARC report useful for determining/fixing a broken > originating sender or intermediary.
>
> Passing this information through (and to me it's not trace if it&#= 39;s there
> for a user to interact with in a DMARC report - although there's d= efinitely
> additional trace value, that's not the primary purpose here) is ex= tremely
> valuable for the report consumer.
>
> My concern is putting it anywhere other than the AR/AAR could creative=
> feature/spec creep, and waiting to see what happens and writing a spec= for
> stamping later just leaves room open for complaints that, even after A= RC,
> DMARC is still broken with respect to reporting on mailing list and > forwarders.
>
> > I'm particularly not convinced about source_ip.=C2=A0 DMARC r= eports are
> > organized
> > by 5322.From and when I'm reviewing reports what I care about= is where the
> > reporting receiver got it from.=C2=A0 That's already covered.=
>
> I'm not certain I'm sold either. Especially because many imple= mentations
> won't even have access to the IP. For instance, Mailman3 does not = have
> access to the source_ip of the smtp connection (that data doesn't = come over
> LMTP), so no mailman software would ever be able to stamp this.
>
> I think the source_ip is valuable to provide, especially for a final > consumer of a report, but 1) it's not always available, 2) it does= n't seem
> perfect to put into an AR header.
>
> Thoughts?
>
> > I don't see anything that might support trace uses that has t= o be in the
> > initial specification.=C2=A0 It can be added later if there's= a need.
>
> I think stamping header.b has real value as outlined above.
>
> I think smtp.client_id also has value, but definitely see the argument= s
> from both sides.

So header.b only gives an explicit way to link an (A)AR header = field with a
signature, so there's no need to guess what's related within the me= ssage.=C2=A0 Now
that I've read your rationale and gone and read RFC 6008 again, I agree= that
makes sense to include in AAR.=C2=A0 It might even be a good idea to make i= t
mandatory since there is (for the purposes of IETF standardization) no
installed base to worry about.

Source IP, I still this is only for trace purposes and should be out of sco= pe
(I have a hard time justifying why it would be out of scope for SPF (which = is
what the working group and later IETF consensus was) and in scope here.

Scott K

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


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




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113e83f2657bd90550c6b218-- From nobody Tue May 30 17:36:49 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 E2066129B1D for ; Tue, 30 May 2017 17:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 jDBOQ2ODQm_L for ; Tue, 30 May 2017 17:36:46 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 BEEAF129B13 for ; Tue, 30 May 2017 17:36:46 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id f102so449329ioi.3 for ; Tue, 30 May 2017 17:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version; bh=xFMeMx4I/IpeIU42mdGWgESEOEK9tUOK1SWNXlxWg/E=; b=eVzC0HQBmBGPKhHNSMuDsEHHfSv7aMRd2+ni5GKzmasCqIzzL7rIQcmzwflQ5eXlFw ecED6F+AKt9SwgXHGFjsiaEoGb+sH/y1Ffkjk+H4zA7R7ydJ2duswXMe6963CjJ9GDdQ RJrvzqRZp00+dBPbsI7i2I4eOkRmA0mxiEC6t+wZlZ5PYsLVZkqlvqt9UKMUCALioWju Sagf7qOJ7GQSTvLOhl3GqDR51OfmUpxRTarB/mfB0UgNM8x+xzqjlLkHW3d9sn2Ay3b+ ChI9ZLHkVSG9vqc4QsW79CucXDmHR+Xy5fUBbgOLaIN4Ph0SPjq0jACUmEdVRHT3DXMG /z3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version; bh=xFMeMx4I/IpeIU42mdGWgESEOEK9tUOK1SWNXlxWg/E=; b=Sd48unJ6OXCSsk1VHwmquwBOpkMNC+JNCzptuRXA6Jthq6ZnAnA5z9DqGzeh7+wlO2 E692yfhAafdvBE1DdyVVcM9i5G/Vf6Yz4HlKyqTcoSfZ8F9Dcjl2x12JW93ravCVfvWm tG28bkw43TJGbKa+RB3aXASt9j8khD4xtmkWIkexk6jt3TIgyJFND16OKsUmTmdQMUC2 FX/2ztITa+Y+1sR7NO652FXGVPEEnjaMzfaR/Dk695puK2i2D1QBR+APGBWVc2t34tGY T6s/EPS4e5+uMmdKLYDKl+CinDRKh02G6XOabcwBFVE5o0OYXw+tKoN4IE/Suo2OUyN0 6ATA== X-Gm-Message-State: AODbwcDBWrP78VqU2wiMK6MQs0qTw3N97k579asDv0OSMU2DwoPdI1c4 te2uyTe5F0UnGIezAWA= X-Received: by 10.202.197.85 with SMTP id v82mr10301769oif.151.1496191005842; Tue, 30 May 2017 17:36:45 -0700 (PDT) Received: from ?IPv6:2602:4b:ae01:6400::2? ([2602:4b:ae01:6400::2]) by smtp.googlemail.com with ESMTPSA id 3sm963956ott.35.2017.05.30.17.36.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 17:36:44 -0700 (PDT) To: dmarc@ietf.org From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <827ef8ad-f014-d792-8d8a-1ea8d1197190@gmail.com> Date: Tue, 30 May 2017 18:36:43 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030700090006030600080500" Archived-At: Subject: [dmarc-ietf] 100% of the false positives in my gmail spam filter are from ietf-dmarc 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, 31 May 2017 00:36:48 -0000 This is a cryptographically signed message in MIME format. --------------ms030700090006030600080500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable I do not know why, for for at least the last month, 100% of the false=20 positive, marked spam, in my gmail inbox, are all from=20 ietf-dmarc@ietf.com mailing list. About 5-10% of the DMARC mailing list gets marked spam. --=20 Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135 --------------ms030700090006030600080500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfowggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVDMIIEK6ADAgECAhA5Slmr+9YRiiUNE3uNg5OMMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA0MDAwMDAwWhcNMTgwNDA0MjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkB FhZkb3VnbGFzcm95ZXJAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwL60WA/naGMhGT7VQ3tTq3MSyKJJnSkRD0YCwdk9QzqOtBwsrT6i9a61OINNe2/F8NiL U2+Xy3EzUu5J0cbfXywJT/vFoq9g4Si1phQEcOKOWVwgPcRvycwLZlYDRM7OqwcoG9vuRhXo 2vGaYwBbzBiHKkIhEgN6CN06YzT3wjU4d69B0kIgAr6/vBW/flGzPZUPOe8NSnlVRHZ0QMCf 3NtwGLV6SHls3Q5ZCBhYzn9abCIkNvedB49LqDcUXy3BYQMldpVhW615+vBhChLb1Xpyc2rq dqXRVc8qzGzHRkV3WzW5+lf+jFZy/CEcD0q4gDXvWP2YK/flZ86LiaeSmQIDAQABo4IB9DCC AfAwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFKflWc164g9V NKG3f5bKDo/motKvMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5l dC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYB BQUHAQEEgYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95 ZXJAZ21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBcDZbduvqneBO0ELaqDgN3AR+UPubC gDyH4zyYUH4L5UesegPZTEY9/a9AfvK7Jh/Wy13KVjH2BPYNlnnkGs/2QJAhB3uYcR975Na5 /WHKFcGkC6fDU1UQcRj3nAwCPOOKC32u0oWI8nyHnNmnB/oEL+yqZJWJuj6/WhZT1ps1O4HU TVRsFcGOW49xE88KuHHc6nRdALkzbpUSaebUnrTEG1d3iqhWk3fO9D5qRUXs+Vkg860VblVB Q/44kMXkxZ5xvD9Meg1wMrmrdRSZnJVJXkBHpmnf1tuyCr8LnoJwdcYEDpS1gUqd30w3AflU 6eRLxXy7FS0FR2RmsRaQ0TymMYIEQTCCBD0CAQEwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQOUpZq/vWEYolDRN7jYOTjDANBglghkgB ZQMEAgEFAKCCAmEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTcwNTMxMDAzNjQzWjAvBgkqhkiG9w0BCQQxIgQgRhzUM0DIJXL0L0SgdvH5d8wKdI7xvIv/ VWnwZjmLNXIwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDlKWav71hGKJQ0Te42Dk4wwgcMGCyqGSIb3 DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8G A1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDlKWav71hGKJQ0Te42Dk4wwDQYJKoZIhvcNAQEBBQAEggEAF8HXQSj5h6z2 BuIAtc7sFn84yumjal58S87JoeVLtZDps5DzxBFANQ7UhwIxiu295psKnbSA5QZoM+9HRiGw PplaBzZGw3ZMpWZix9y7vOEV9tUSBxW84SCVAZgo0AJZ0Uq2W9PzUsWKyT0UfKQbV/wEmxL9 xuC0F7n7x0EEAFmZi9pSiNv93en2HPGQIjqqWyQzLGaUUa3j0FWCUkcsxPnhoggh8CIGO7MI m5pdN+U9Dd7kQLrb1dCOyfcyFPis6bjCutQo6KHwXoelElzEBs+WMcfHFcblpbS3I5zJLoGa cqRTuMED4QiUi5UQ6Z/lpfrFnRxaIxAq/zOSxi0iGAAAAAAAAA== --------------ms030700090006030600080500-- From nobody Tue May 30 17:55:00 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 D1847129B21 for ; Tue, 30 May 2017 17:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu 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 Mg8dP0XBFJEi for ; Tue, 30 May 2017 17:54:58 -0700 (PDT) Received: from linode.junc.eu (linode.junc.eu [IPv6:2a01:7e00:e000:146::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C70128D8B for ; Tue, 30 May 2017 17:54:58 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by localhost.junc.eu (Postfix) with ESMTP id 2B1171BE13E for ; Wed, 31 May 2017 01:54:55 +0100 (BST) X-Spam-ASN: X-Spam-dcc_result: X-Spam-Uri-Domains: ietf.org Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by linode.junc.eu (Postfix) with ESMTPSA id 04F881BE06F for ; Wed, 31 May 2017 01:54:55 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=junc.eu; s=default; t=1496192095; x=1496624095; bh=GAQxBJOZVdbIY08nS9rfwgtUMNypbsKQyC6sTZvrtXc=; h=Date:From:To:Subject:In-Reply-To:References; b=MW1rWv1I/kJFGAHVoOEPr4zsPQ7fmjwLrh9Q2/ZWsq2CMUGazgnmI9Sekwls84JWF XXVZAYlYrcHzpD4h3/9IBQnmsskOH1jaW2Y0oQ5zRm9Izcku589+YPqGbHwfqHEZlL FJpXp7tXtp/0eJOyfyTKHrYTt03tmldw6TeLPs2g= X-Virus-Status: Clean MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 31 May 2017 02:54:54 +0200 From: Benny Pedersen To: dmarc@ietf.org Organization: Jersore Underground Network Center In-Reply-To: <827ef8ad-f014-d792-8d8a-1ea8d1197190@gmail.com> References: <827ef8ad-f014-d792-8d8a-1ea8d1197190@gmail.com> Message-ID: X-Sender: me@junc.eu User-Agent: Roundcube Webmail/1.2.4 Archived-At: Subject: Re: [dmarc-ietf] 100% of the false positives in my gmail spam filter are from ietf-dmarc 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, 31 May 2017 00:55:00 -0000 Doug Royer skrev den 2017-05-31 02:36: > About 5-10% of the DMARC mailing list gets marked spam. Authentication-Results: linode.junc.eu; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key) header.d=ietf.org header.i=@ietf.org header.b=GhOLk1IT; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=eVzC0HQB; dkim-atps=neutral seems maillists breaks dkim :/ From nobody Tue May 30 18:16:37 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 6B058129B17 for ; Tue, 30 May 2017 18:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr_i-SuSM_hL for ; Tue, 30 May 2017 18:16:34 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B0AD9126BF7 for ; Tue, 30 May 2017 18:16:34 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id o12so4134201iod.3 for ; Tue, 30 May 2017 18:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xuM6m0FPQYymZ0Wq5FfJIttdFgFiK4xHGEVJrye42/g=; b=vf+ERsir7QzdoGWwyFlHaKPzgiG2ZzwQcCtnaEVjAm3DROIZGztnvPmbCsqGEY4gij SqbqgsUifIF5rw1dBmFe3g9ZRuDMrRIgqugA/OzWR21lv3OMDo7tHJzJu8V+mLiGlOvk jFIxmidj1WYSAUgCrTeJis702ySxDsNDSFf8tOAU/I3I8cWyY4N+mxQHM3SirA2hQga3 W71zKTjHx/wnsndtQSzMQisGXtbxoKEw3qOKV0OjCaJLqB2i63ABFgv0TrgdHJ8myxm9 pll3awX1vRpT/AOG+Q+zE3crLuSMSs3WAJAaZM+FB8Qq7jNHaLaap6Gptq4FQkEZKG+I viFQ== 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=xuM6m0FPQYymZ0Wq5FfJIttdFgFiK4xHGEVJrye42/g=; b=UeO/CN/zSd0aaZmUnmm/hXCv5TBjmo5+Mx+gMYemecJxjw6YZuAcBDfsGw/gglZKNR DNvX/nvOFPBpPDci11Cmj+Uhnz4DSD9Fc9sndq1j6JsBfNHLF9UmdRTQJ1opbo9ntl1b lYQZOGcHN4O/ICvqIa1pmHi0gmXw2M8q/TbKopSxeEu9MgKxKz+Tn6LCgoDxalSHm9wN vQS5z5XHREdaCEBBK6Rio6IePa82FcQny4UMOs/CTHAwWKx75pfcvSmjOrEMzk648paZ Jv37sE4rQ3rdCMEhljAPNWX8OiCjTdbf91eFkBiuCXmvukx89HO44DkPcV8q9NziE2YY 5vmQ== X-Gm-Message-State: AODbwcBlXoAT0VuKd1hf76s5dsuHPFDJTtE4PWxXsVsFgVFCuVCKlJfa iLTsOq5pjhU0u+HmvnpO0YESfP8J8ZQDG3o= X-Received: by 10.202.204.197 with SMTP id c188mr11051979oig.194.1496193393658; Tue, 30 May 2017 18:16:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 18:16:32 -0700 (PDT) Received: by 10.182.8.34 with HTTP; Tue, 30 May 2017 18:16:32 -0700 (PDT) In-Reply-To: References: <827ef8ad-f014-d792-8d8a-1ea8d1197190@gmail.com> From: Brandon Long Date: Tue, 30 May 2017 18:16:32 -0700 Message-ID: To: Benny Pedersen Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="001a11c17710bf095b0550c7ab5d" Archived-At: Subject: Re: [dmarc-ietf] 100% of the false positives in my gmail spam filter are from ietf-dmarc 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, 31 May 2017 01:16:36 -0000 --001a11c17710bf095b0550c7ab5d Content-Type: text/plain; charset="UTF-8" Some of us posting to the list are from dmarc p=reject domains (like me), and although Gmail will detect the mailing list and not reject, it just downgrades to quarantine. Unfortunately, the unmark as spam won't correct for this, either. This is the problem arc is trying to solve. You can add a filter for list:ietf.org never mark as spam, just realize there is a small number of spam messages that go to ietf mailing lists. Brandon On May 30, 2017 5:55 PM, "Benny Pedersen" wrote: > Doug Royer skrev den 2017-05-31 02:36: > > About 5-10% of the DMARC mailing list gets marked spam. >> > > Authentication-Results: linode.junc.eu; dmarc=fail (p=none dis=none) > header.from=gmail.com > Authentication-Results: linode.junc.eu; > dkim=pass (1024-bit key) header.d=ietf.org header.i=@ietf.org > header.b=GhOLk1IT; > dkim=fail reason="signature verification failed" (2048-bit key) > header.d=gmail.com header.i=@gmail.com header.b=eVzC0HQB; > dkim-atps=neutral > > seems maillists breaks dkim :/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a11c17710bf095b0550c7ab5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some of us posting to the list are from dmarc p=3Dreject = domains (like me), and although Gmail will detect the mailing list and not = reject, it just downgrades to quarantine.

Unfortunately, the unmark as spam won't correct for this, e= ither.

This is the probl= em arc is trying to solve.

You can add a filter for list:ietf.org n= ever mark as spam, just realize there is a small number of spam messages th= at go to ietf mailing lists.

Brandon

On May 30, 2017 5:55 PM, "Benny Pedersen" <me@junc.eu> wrote:
Doug Royer skrev den 2017-05-31 02:36:

About 5-10% of the DMARC mailing list gets marked spam.

Authentication-Results: linode.junc.eu; dmarc=3Dfail (p=3Dnone dis=3Dnone) = header.from=3Dgmail.com
Authentication-Results: linode.junc.eu;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dkim=3Dpass (1024-bit key) header.d=3Dietf.org head= er.i=3D@ie= tf.org header.b=3DGhOLk1IT;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dkim=3Dfail reason=3D"signature verificati= on failed" (2048-bit key) header.d=3Dgmail.com header.i=3D@gmail.com header.b= =3DeVzC0HQB;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dkim-atps=3Dneutral

seems maillists breaks dkim :/

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--001a11c17710bf095b0550c7ab5d-- From nobody Tue May 30 18:38:13 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 32C43129BBE for ; Tue, 30 May 2017 18:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b8ESbaFo-_3 for ; Tue, 30 May 2017 18:38:10 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 5F990129B36 for ; Tue, 30 May 2017 18:38:10 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id x47so1499884uab.0 for ; Tue, 30 May 2017 18:38:10 -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=e/2xWqIRW9mFAjM+yW+uX6UZzv803Zq/gAtEI3cef+w=; b=Op+ShW5IgRvZo6K7wADeKJShBCmIlQT8G0xBnPM5vCW1XzHIGkTviKrfLvXX5f0zGi JHNJRQGaI6C/JnRn63KkpwBayVVZ3VqQ5m4Aj+nLlmR4p79seXd7I23DJDRZnV4N+AVC 67h3PBalEz8xjjd9dGIOplKA8rpi0XwhOjpB4= 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=e/2xWqIRW9mFAjM+yW+uX6UZzv803Zq/gAtEI3cef+w=; b=EVEz0Ez6eDLGIxNrJblUVIVE987xhPiRPNthgivV0gJfHD+HsTpvU3IM/Ppk61B1FK TL4jD5pZghfS/7l1241hf2UsTTLDB+OkecQm2/YmeffvPNH+cWbE3/t50cL5bFPXJzRp huj7iCXMiSoC1soGgjrGOLGI8jhYtID2RIr8c0tw2fpaoRnyqLK2hte3IkYy7bSVsg1T bAbwiCfsWzoQOIMWR1TcOiOP2LW5/JyYJU0CGxEQbE3CsBghFUVCxwkTb5KfCjFO28mp YU2go+qwOh5dQdQ7FX5fy5heMF0uhHLamtAh6ecthOOwuDfvya1HyD9RwOEF4Ab9NPsV yZyw== X-Gm-Message-State: AODbwcAiygYOth+0p2t6SR02lA7E4R01zQq/2wcPBHUvlC5l6XmGvMK6 Lhnt3s5u9zGjHAH2x8u5YW7XO+5wyduv X-Received: by 10.176.65.99 with SMTP id j90mr12565270uad.1.1496194689359; Tue, 30 May 2017 18:38:09 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Tue, 30 May 2017 18:38:08 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 09:38:08 +0800 X-Google-Sender-Auth: 3Vpu3aM6wYLY4uwcP424nR-C-DM Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12309af97f990550c7f854" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 31 May 2017 01:38:12 -0000 --94eb2c12309af97f990550c7f854 Content-Type: text/plain; charset="UTF-8" On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote: > This might be a non-issue, but we're asking this question specifically > because we've run into an implementation issue within openarc that feels > weird and seems like a matter the WG may want to weigh in on. > > Our expectation is that, for any given ARC Set n, AMS[n] would cover > AAR[n]. > Yes, that is the intent. The set[n] is intended as a progressively built comprehensive package: 1) evaluate DMARC for the message, if it fails and you are ARC-capable, evaluate any preceding ARC[1..n-1] chain --> post your results into the message as AR (expected to disappear if there are later hops) and AAR[n] (subject to whatever protections you need within your ADMD/MTA chain until the ARC-set is completed; 2) create and affix the AMS which covers the message, including AAR[n]; 3) create and affix the AS which covers the ARC-set[n]. Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* > AAR[n] because AAR[n] isn't created until substantially later in the flow. > That seems like an implementation flaw. AMS should be built in two phases, both of which follow the creation of AAR[n]: a) blank "b=", b) calculate the signature, c) append the signature to the end of the AMS header field value. I'll look at how to make this more clear in the I-D. --Kurt --94eb2c12309af97f990550c7f854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, May 26, 2017 at 6:47 AM, Seth Blank <seth@valimail.com> = wrote:
This might b= e a non-issue, but we're asking this question specifically because we&#= 39;ve run into an implementation issue within openarc that feels weird and = seems like a matter the WG may want to weigh in on.

Our expectation is that, for any given ARC Set n, AMS[n] would cover= AAR[n].
=C2=A0
Yes, that is t= he intent. The set[n] is intended as a progressively built comprehensive pa= ckage:=C2=A0
1) evaluate DMARC for the message, if it fails and y= ou are ARC-capable, evaluate any preceding ARC[1..n-1] chain --> post yo= ur results into the message as AR (expected to disappear if there are later= hops) and AAR[n] (subject to whatever protections you need within your ADM= D/MTA chain until the ARC-set is completed;
2) create and affix t= he AMS which covers the message, including AAR[n];
3) create and = affix the AS which covers the ARC-set[n].

Currently in openarc, AMS[n] covers= all previous AAR[1..n-1] but *not* AAR[n] because AAR[n] isn't created= until substantially later in the flow.
That seems like an implementation flaw. AMS should be built in= two phases, both of which follow the creation of AAR[n]: a) blank "b= =3D", b) calculate the signature, c) append the signature to the end o= f the AMS header field value.

I'll look at how= to make this more clear in the I-D.

--Kurt=C2=A0<= /div>
--94eb2c12309af97f990550c7f854-- From nobody Tue May 30 18:46:52 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 C19ED129C37 for ; Tue, 30 May 2017 18:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Vo0hG83UBkhC for ; Tue, 30 May 2017 18:46:49 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1072A129B36 for ; Tue, 30 May 2017 18:46:49 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id w1so1370605vkd.2 for ; Tue, 30 May 2017 18:46:48 -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; bh=iMeMNWc98ZTivuXXFlm9DlUgPk+n/4WyRqs5tQbKvS4=; b=EkwXa5d6T+OgHC75hn95M55udd8X4StCKV5c2ydA8mT2lRJaGqvWdh73BPfd9fzIuq ZoAqHa7YifXLKH2yJpsTO8+t1hDKvAH/QmNQkgUiw89611VD8NsnXpS0bNhbXyySRbtl lbfzPoOtj2/zpbfCPJqOg804eMp0IiLNGKH18= 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; bh=iMeMNWc98ZTivuXXFlm9DlUgPk+n/4WyRqs5tQbKvS4=; b=W38SrjSW8Z+lB7NBQbfFS+PxUYCUzl26mu++7e/iMuvK35SrkSb5o3Fi0+yC+VbW6B moYqPrtZpdJSqwKh58/qaMhkPM/u9+jLUkYuj0xVWFSB2ZIRG9sry0uMe2k1LgmdOyT/ G2lEpbpesW5la5FPWSLXQ+VZncIjcps8qPRZ6SrfwwtPOcAIsLr7Pg9ZjhfDrugKi52Q PQ5gf1dulUrFnAg7UHhrBIWlVJIYy0wPfOrny1wX+I7BIkz406uUj9FLDZW3nQjQrS3x c9bGRl6yl72ksE3S6q0YELbGBtDgph8gBXplDOx3pL9m9I0o95tO4ipowN5WOJtsL2Ea 0bFA== X-Gm-Message-State: AODbwcA71PxgU5qHvnp0HycQyX5gufRNH9wFwgpiMkDeyb2IFThSPcGI yxYb5tLEvdx7Xm4oqylluIE0yj/1n51tbDdSD+ar X-Received: by 10.31.84.4 with SMTP id i4mr10741561vkb.142.1496195207870; Tue, 30 May 2017 18:46:47 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Tue, 30 May 2017 18:46:47 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 09:46:47 +0800 X-Google-Sender-Auth: 5ZIV_uG-cVGzYFxU4fWnuMS5oYc Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114e549ae177f50550c817fe" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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, 31 May 2017 01:46:51 -0000 --001a114e549ae177f50550c817fe Content-Type: text/plain; charset="UTF-8" Barry et al, On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: > The current spec defines an arc authres method ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1). > > We believe there should also be registered ptypes and properties, that > should be stamped (but are not required, as they won't always be available). > > As long as AR stamping happens at the end of chain validation, when an ARC > set gets created this stamp will be included in the AAR, and AAR > construction can be clean with no additional language or requirements > necessary in the spec. > This area seems like something that would be productively explored in a F2F since it is pretty undefined right now and there are some divergent opinions kicking around... (see the thread with Brandon and Scott so far) --Kurt --001a114e549ae177f50550c817fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barry et al,

On Wed, May 31, 2017 at = 1:14 AM, Seth Blank <seth@valimail.com> wrote:
The current spec defines an = arc authres method (https://tools.ietf.org/html= /draft-ietf-dmarc-arc-protocol-03#section-8.1).
We believe there should also be registered ptypes and prop= erties, that should be stamped (but are not required, as they won't alw= ays be available).

As long as AR stampin= g happens at the end of chain validation, when an ARC set gets created this= stamp will be included in the AAR, and AAR construction can be clean with = no additional language or requirements necessary in the spec.

This area seems like s= omething that would be productively explored in a F2F since it is pretty un= defined right now and there are some divergent opinions kicking around... (= see the thread with Brandon and Scott so far)

--Kurt=C2=A0
--001a114e549ae177f50550c817fe-- From nobody Tue May 30 22:49:09 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 43983127866 for ; Tue, 30 May 2017 22:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_cUoXMMG9I2 for ; Tue, 30 May 2017 22:49:04 -0700 (PDT) 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 43A611205D3 for ; Tue, 30 May 2017 22:49:04 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id x47so3507933uab.0 for ; Tue, 30 May 2017 22:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=+alGhHGV4V2W32WIiPZQItrxSWi1kMvzwk4iS24zPXo=; b=BQ6qiK5WYMiBCf6A9BB5wRvQzBjQJGkS2iS5JpnCnZbUudimehHBwv4HvKfMbkgjoJ uGpgof95117iqjnqQpU8fBXThxd0+7FKzSZnsM5ZiockPd6bfBbjkj3Q7FurWbko8DDX cG0xy7YxWYKa2L9ZxVy1GA2ZJvTV9IWX+vTGo= 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:from:date:message-id:subject :to:cc; bh=+alGhHGV4V2W32WIiPZQItrxSWi1kMvzwk4iS24zPXo=; b=fuTP2wZ1+JwseIUHuBW5tONLzlb6dUFQmBAZ5Y8PfJT5sa2nLsqml/dAbkfELNF/B+ BzYB9peU1n6j81qvk2hnVTi+BcZSARZnzVy/HU3vIuCo4+rz+LSGGHuJGxsxP9mkOnJd BS6BbozuNdnrVkljcS/BXgM8CYL5w4I5vvojPUkeRay3mAXEXUqKKlnMrE3WPUWTn86I w9b9zk0f4Mc+qCIu1vDZ0A8AlQ2zAOHUbH+WzMTb4lpCIn0R7o4ZgDto/LAhsrJ0Uk0n QHBkHWNhvER+ISbgeJiwppm8kKVydzMe2rx9Nly26JSHOYSjhTUIxyZsjIimaEDUJ/XM Di0g== X-Gm-Message-State: AODbwcCCp8mWS4o1ZnG7FGb1oMOQCwZh7TvEmT7A2ImpMwCebSUwpYnR ljDpO7p2yCcGGrr8EDXEa/YC1ezhIHrR X-Received: by 10.176.65.99 with SMTP id j90mr12956238uad.1.1496209743334; Tue, 30 May 2017 22:49:03 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Tue, 30 May 2017 22:49:02 -0700 (PDT) From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 13:49:02 +0800 X-Google-Sender-Auth: LByvwoNz9VQkqDB89bcDfU61Dz8 Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="94eb2c12309a42e3ab0550cb7a7d" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 05:49:06 -0000 --94eb2c12309a42e3ab0550cb7a7d Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 2:11 AM, Barry Leiba wrote: > > Anyone who wants to work on this at the Hackathon, please register > (free) for the hackathon > ... > sooner is better, so we can track who's participating. > Done - I had not realized that the hackathon registration was separate. > > To me, the biggest point of discussion has to do with the hypothetical > next > > milestone for the group which is currently called out as "document[ing] > > operational practices..." (the _Draft Guide on DMARC Usage_). While I > > understand that was viewed as "something that we could do" when the group > > was chartered, I doubt the need for it as an IETF document as time has > > passed. I think that discussing the next steps of the group would be > apropos > > in a F2F meeting. > > This seems like fodder for a short meeting -- 30 minutes That seems reasonable. > even if we need to discuss the next steps, we haven't done that on the > list yet, so we > don't know that we need face time for it. > Most of the effort has been focused on getting ARC deployed in to production so there has been relatively little attention to the "what's next" question. Peter had started a thread a few months ago but it did not get much (or any) traction. How sacrosanct is the "deliverable" list in the charter? I know that we are constrained from going beyond the charter, but do we have to write documents that may not be of value just because they are listed in the charter? Is the openarc project in a state where it would be useful to discuss it? > It's usable, has been deployed in test instances and interoperates with various other implementations (see https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-9). I'm not sure what would need to be discussed though. There will be a training session at the impending M3AAWG meeting on how enterprise mail admins can implement ARC using OpenARC. > I'll note that DCRUP will have a session in Prague > Glad to hear that - I've still been fighting with getting onto that list and having mail be receivable. --Kurt --94eb2c12309a42e3ab0550cb7a7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 31, 2017 at 2:11 AM, Barry Leiba <barryleiba@computer.org> wrote:
Anyone who wants to work on this at the Hackathon, please register
(free) for the hackathon
<https://www.ietf.org/regis= tration/ietf99/hackathonregistration.py>...
sooner is better, so we can track who's participating.
=

Done - I had not realized that the hackathon registrati= on was separate.
=C2=A0
> To me, the biggest point of discussion has to do with the hypothetical= next
> milestone for the group which is currently called out as "documen= t[ing]
> operational practices..." (the _Draft Guide on DMARC Usage_). Whi= le I
> understand that was viewed as "something that we could do" w= hen the group
> was chartered, I doubt the need for it as an IETF document as time has=
> passed. I think that discussing the next steps of the group would be a= propos
> in a F2F meeting.

This seems like fodder for a short meeting -- 30 minutes

That seems reasonable. =C2=A0
=C2=A0
even if we need to discuss = the next steps, we haven't done that on the list yet, so we
don't know that we need face time for it.

Most of the effort has been focused on getting ARC deployed in to pr= oduction so there has been relatively little attention to the "what= 9;s next" question. Peter had started a thread a few months ago but it= did not get much (or any) traction. How sacrosanct is the "deliverabl= e" list in the charter? I know that we are constrained from going beyo= nd the charter, but do we have to write documents that may not be of value = just because they are listed in the charter?

Is the openarc project in a state w= here it would be useful to discuss it?

= It's usable, has been deployed in test instances and interoperates with= various other implementations (see https://tools.ietf.org/html/dra= ft-ietf-dmarc-arc-protocol-03#section-9). I'm not sure what would n= eed to be discussed though. There will be a training session at the impendi= ng M3AAWG meeting on how enterprise mail admins can implement ARC using Ope= nARC.
=C2=A0
I'll note that DCRUP will have a session in Prague
Glad to hear that - I've still been fighting with getting o= nto that list and having mail be receivable.

--Kur= t=C2=A0
--94eb2c12309a42e3ab0550cb7a7d-- From nobody Tue May 30 22:50:43 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 B35D512E03E for ; Tue, 30 May 2017 22:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk45O1dPyD-Z for ; Tue, 30 May 2017 22:50:40 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 2A6781294F0 for ; Tue, 30 May 2017 22:50:40 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id y4so3483089uay.2 for ; Tue, 30 May 2017 22:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=p1nb+lseEW/op6M6pYFYVC1CZmTtqaCjcOaxAgToSA8=; b=CHRO4G8imMzVelNx4aaBgvkDOdXCC4cKdKLhJjn9ui1FdFx7XdgLsoiQDF1S+puczP qDn8VzPP0MgRSe+5kFQUOHP07PpIAaT6/U5K+kUYOGfxp/ho/ILJvfouomywbRMQKQ6v dlgmgnbS+K9JbnRrcFYBWXTwl+LbYS/yCBI54= 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:from:date:message-id:subject :to; bh=p1nb+lseEW/op6M6pYFYVC1CZmTtqaCjcOaxAgToSA8=; b=Le2tCR4NiJb7XciDi9yC78Iyr9t+zw6VA78XJ1+YhXZrvY+cODhjsDIbkZa2HI62bI IIzW1S0Jby+n340m1mwJb8QWb3y99PD8z80NjSVWn9JQ39uPP6/PdjIy5IrIRg+lWLel K2G02mWzUlTfpUigo2JZ9HhoFHG1yuWXzXjHxgyn7dIZMp9eRuazyJeZgc8Q8SoT2AKn fIfW1+8//XPARDfDp/Mt+RmWJQTRPS/ZnPEx0nkiNuNCsJJChDJ3AEM0ahqkT+QMiSnR jIRQAtc3Rt2SjmHwIEJHoCyArTgfpQ05a/qib86OyttSiSSfOAuTPSVa7P7IaeSNspgE CWPQ== X-Gm-Message-State: AODbwcD2Mb1gp0oP1SJ+qFh/q7gRdN7DierY23fHLmidYv0+mx+ig7rH QGi61A8vCe1s92OPct/q1wPL7/LspBIL7GJiiw== X-Received: by 10.176.2.178 with SMTP id 47mr12971522uah.36.1496209839129; Tue, 30 May 2017 22:50:39 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Tue, 30 May 2017 22:50:38 -0700 (PDT) From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 13:50:38 +0800 X-Google-Sender-Auth: 4afae8_9DEQdCH92vaphPB2qpBw Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a113cd3caf89e510550cb7f7d" Archived-At: Subject: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC) 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, 31 May 2017 05:50:42 -0000 --001a113cd3caf89e510550cb7f7d Content-Type: text/plain; charset="UTF-8" (Reposting with adjusted subject) On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) wrote: > Barry et al, > > On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: > >> The current spec defines an arc authres method ( >> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1 >> ). >> >> We believe there should also be registered ptypes and properties, that >> should be stamped (but are not required, as they won't always be available). >> >> As long as AR stamping happens at the end of chain validation, when an >> ARC set gets created this stamp will be included in the AAR, and AAR >> construction can be clean with no additional language or requirements >> necessary in the spec. >> > > This area seems like something that would be productively explored in a > F2F since it is pretty undefined right now and there are some divergent > opinions kicking around... (see the thread with Brandon and Scott so far) > > --Kurt > --001a113cd3caf89e510550cb7f7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Reposting with adjusted subjec= t)

On Wed, May 31, 2017 at 9:46 AM, Kurt = Andersen (b) <kboth@drkurt.com> wrote:
Barry et al,

On Wed, May 31, 2017 at 1:14 AM, Seth Blank <seth@valimail.com&= gt; wrote:
The current spec defines an arc authres method (= https://tools.ietf.org/html/draft-ietf-dma= rc-arc-protocol-03#section-8.1).

We = believe there should also be registered ptypes and properties, that should = be stamped (but are not required, as they won't always be available).

As long as AR stamping happens at the end= of chain validation, when an ARC set gets created this stamp will be inclu= ded in the AAR, and AAR construction can be clean with no additional langua= ge or requirements necessary in the spec.

=
This area seems like something that= would be productively explored in a F2F since it is pretty undefined right= now and there are some divergent opinions kicking around... (see the threa= d with Brandon and Scott so far)

--Kurt=C2=A0

--001a113cd3caf89e510550cb7f7d-- From nobody Wed May 31 02:08: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 AEE4312957F for ; Wed, 31 May 2017 02:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Svbo4fgg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z/2TuwOd 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 J0U2VKcGy7sD for ; Wed, 31 May 2017 02:08:29 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D245D1293EC for ; Wed, 31 May 2017 02:08:28 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 406FC208E7; Wed, 31 May 2017 05:08:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 31 May 2017 05:08:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=zTOKA804Ukfy2SjoKI yQ1OE4PFMcow4t8kxjzxC5Qv8=; b=Svbo4fgg/oQGzTEVo6DNQU6vGKK506BSwn xdZNm3kIorS48sAiY8IKgo84UJ0sO0EpZbsWocJ150CZTTUOcJHpMieLFKFNDxnm CQRhVz+ToRDrNDBspIVm1xy6eaGwK6boXbWktCMKtyAFWnDepVwahIcE0177kWOx J/Ciblj7aDcZCkVqOEXt4bE21AQH1RgYtrJ4RVfQe/yk4amH6k0lHSSmL6Brnw/E WKLBnmghuJaMvaYdG4gN9vnVgSlBrBBipaQEQPskCq8ZqXOfYpNKDQlTlD7KWuD1 OPR/1qthipLHjyFd/XODBXZJ2EPhwjxffAAYkB7UBEs7yJVQjJZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=zTOKA804Ukfy2SjoKIyQ1OE4PFMcow4t8kxjzxC5Qv8=; b=Z/2TuwOd Eg95jwLXJ9Ew0jd7eWHyWg1r5fhs1ut49tDAGcmb8NRWHO1UI4TPNuu32JbMPVIl dNF1OYwalAD8jhNGJZ9HcYsdEZm+q51SqYNXNKSdB7i7NQ3kgfIlefJUDquf8hTG PiSEuEkJbtojTmhe99kJ+TxBcTjvJuxLUdyZ8F4mm5+fTKckK8fZbnk2uUJoUb3y +Ziq1fzIC81X4Mj4qfeQD2OLbGgmvXge/q09b87k/JuqlFXmU73yb0BTb5QbXpj/ odNGUgpZjD1yZdKrAZqyyOZaZdtu2vFFw4PnjNExC6UY4TM/APVxcR8SzZxlRsax 5Yd4wNsvfVy74g== X-ME-Sender: X-Sasl-enc: +0xG4aDsNJ9q1BGJf6O9ogVfZn9g98OJGxq5lxt/qdNm 1496221707 Received: from [10.228.217.143] (unknown [185.69.144.211]) by mail.messagingengine.com (Postfix) with ESMTPA id A3AC67E7AA; Wed, 31 May 2017 05:08:27 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A4B0FF3F-B2AD-424D-B03E-3FF9FE645303 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Wed, 31 May 2017 10:26:12 +0100 Cc: Barry Leiba , "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Transfer-Encoding: 7bit Message-Id: <372C2E53-FC76-4A82-912C-BD296746DEEE@fastmail.fm> References: To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 09:08:31 -0000 --Apple-Mail-A4B0FF3F-B2AD-424D-B03E-3FF9FE645303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Kurt, On 31 May 2017, at 06:49, Kurt Andersen (b) wrote: >> even if we need to discuss the next steps, we haven't done that on the li= st yet, so we >> don't know that we need face time for it. >=20 > Most of the effort has been focused on getting ARC deployed in to producti= on so there has been relatively little attention to the "what's next" questi= on. Peter had started a thread a few months ago but it did not get much (or a= ny) traction. How sacrosanct is the "deliverable" list in the charter? I kno= w that we are constrained from going beyond the charter, but do we have to w= rite documents that may not be of value just because they are listed in the c= harter? The WG can recharter, but you will need to convince me (as the Area Director= responsible for this WG) and the rest of IESG that the new work/charter is b= etter than the old one. Rechartering is not hard, if there is enough WG supp= ort for it. Best Regards, Alexey --Apple-Mail-A4B0FF3F-B2AD-424D-B03E-3FF9FE645303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Kurt,

On 31 May 2017, at 06:49, Kurt Andersen (b) <kboth@drkurt.com> wrote:

even if we need to discuss the next steps, we haven't done that on the list yet, so we
don't know that we need face time for it.


Most of the effort has been focused on getting ARC deployed in to production so there has been relatively little attention to the "what's next" question. Peter had started a thread a few months ago but it did not get much (or any) traction. How sacrosanct is the "deliverable" list in the charter? I know that we are constrained from going beyond the charter, but do we have to write documents that may not be of value just because they are listed in the charter?

The WG can recharter, but you will need to convince me (as the Area Director responsible for this WG) and the rest of IESG that the new work/charter is better than the old one. Rechartering is not hard, if there is enough WG support for it.

Best Regards,
Alexey

--Apple-Mail-A4B0FF3F-B2AD-424D-B03E-3FF9FE645303-- From nobody Wed May 31 04:58: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 1418F1289B0 for ; Wed, 31 May 2017 04:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 WMA1G4CQjM8v for ; Wed, 31 May 2017 04:57:59 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CAF126CC7 for ; Wed, 31 May 2017 04:57:59 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y190so6997962vkc.1 for ; Wed, 31 May 2017 04:57:59 -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=eVokmb32/4bo6mHtRPI2MB2Nr32AZnlmPVngQWvWwjM=; b=cnGp3CEIZKpizWnQE8vLrRqGTYx+OYFXhTxqPEaRcMZlol16sDaTUDMv4crLUxBOhU 0IF7tI63ymrv4GHt3Q2z1CfFbLo0rimCuK3HoMlzrGtp8MnRtTx9Zau3Vw8JGlupZc77 2+k1CalhOgboY4StEB54J57A5W2py8aNRHcw8= 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=eVokmb32/4bo6mHtRPI2MB2Nr32AZnlmPVngQWvWwjM=; b=qVUsR4CFhYWnn0SvM6pL9mAIhgUVydEwqT2FusCFFUOFY4QF/prpgV++z8iv6xZe2g Nq0QAHeBe9xVZW+Zmz8lXzOOBL1HHanXtR13wiwTF+XybzXznWLNL0vKv04OSq9WpJZo McFvTj8IuKA/wusATKkM4qLXJ2HN3MjjS2P/zi99tib8XpKWg7t5lkFARp4F9gy6XzEi oDzoCD2IY0e35ZNdhZ/g3/4+QgGX4j/DwyaqKs1dsEBosbm39dLPevz5v+sEDcL8BZkn GIS7rnQqCKvJRiHKw65+dT3ezQIeXcssauXdBwehjo0/DHABvXyr7an+RGthqyJMllg3 AbTg== X-Gm-Message-State: AODbwcDdm/7UJN+eK52PPFaWT8Tg4CJ67fLGzr7H/B5oMfrw6u9Rlw5u KDgRbtMbwSMbqEpNjSZdjpEyVoLur4zD X-Received: by 10.31.61.7 with SMTP id k7mr11955248vka.82.1496231878459; Wed, 31 May 2017 04:57:58 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Wed, 31 May 2017 04:57:57 -0700 (PDT) In-Reply-To: <372C2E53-FC76-4A82-912C-BD296746DEEE@fastmail.fm> References: <372C2E53-FC76-4A82-912C-BD296746DEEE@fastmail.fm> From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 19:57:57 +0800 X-Google-Sender-Auth: RbPHKZsAWNayDDIVDfSwKfCbq-k Message-ID: To: Alexey Melnikov Cc: Barry Leiba , "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="001a114da1e29e1a560550d0a11f" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 11:58:01 -0000 --001a114da1e29e1a560550d0a11f Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 5:26 PM, Alexey Melnikov wrote: > Hi Kurt, > > On 31 May 2017, at 06:49, Kurt Andersen (b) wrote: > > even if we need to discuss the next steps, we haven't done that on the >> list yet, so we >> don't know that we need face time for it. >> >> > Most of the effort has been focused on getting ARC deployed in to > production so there has been relatively little attention to the "what's > next" question. Peter had started a thread a few months ago but it did not > get much (or any) traction. How sacrosanct is the "deliverable" list in the > charter? I know that we are constrained from going beyond the charter, but > do we have to write documents that may not be of value just because they > are listed in the charter? > > > The WG can recharter, but you will need to convince me (as the Area > Director responsible for this WG) and the rest of IESG that the new > work/charter is better than the old one. Rechartering is not hard, if there > is enough WG support for it. > Does deciding that a proposed work item/deliverable is not really beneficial require rechartering? --Kurt --001a114da1e29e1a560550d0a11f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 31, 2017 at 5:26 PM, Alexey Melnikov <aamelnikov@fastmail.fm= > wrote:
=
Hi Kurt,

On 31 May 2017, at 06:49, Kurt= Andersen (b) <kbo= th@drkurt.com> wrote:

even if we need to discuss the n= ext steps, we haven't done that on the list yet, so we
don't know that we need face time for it.

Most of the effort has been focuse= d on getting ARC deployed in to production so there has been relatively lit= tle attention to the "what's next" question. Peter had starte= d a thread a few months ago but it did not get much (or any) traction. How = sacrosanct is the "deliverable" list in the charter? I know that = we are constrained from going beyond the charter, but do we have to write d= ocuments that may not be of value just because they are listed in the chart= er?

The WG can recharter, but you will ne= ed to convince me (as the Area Director responsible for this WG) and the re= st of IESG that the new work/charter is better than the old one. Recharteri= ng is not hard, if there is enough WG support for it.

Does deciding that= a proposed work item/deliverable is not really beneficial require recharte= ring?

= --Kurt
--001a114da1e29e1a560550d0a11f-- From nobody Wed May 31 05:21: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 8DA1C129BCD for ; Wed, 31 May 2017 05:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HlAIZBYE-lCN for ; Wed, 31 May 2017 05:21:46 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 2C5D9120454 for ; Wed, 31 May 2017 05:21:46 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m47so12534340iti.1 for ; Wed, 31 May 2017 05:21:46 -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=sj6GIoeXtMor0x9xDKHCN93kv9PVuiFSFNgXO3AdPoU=; b=r997fSHcSKx/MDQXl4leXcuRNS/cRnn1pTmcR92gcipaX9+OWGeefGiwesOFOMDvu+ XQrI2HrS7Ot220Sp1W0ikcMkUftaqNGlGgZBpu3lnnM00jjt+mG8sHSfa5EPLiT0Te2K EIG95I/Sqf6iBsqjtyWoYpHcRJt20O3et2d58Q6/L/EGkbjoAECSD64OdOXE6N25p3e7 lDOAlCWesnzqPpEfgpR3q+62eZ6w8N78betyI3z8IVEr7sc/HlQZWOhpF39j7lOGHVOB dDVCNiOx3nbJ3kkOyOb0lYj4Ivddzhm9ce1EGhsbQE5a1avCRU6/6/2tyUo0AimOxfTv tpiQ== 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=sj6GIoeXtMor0x9xDKHCN93kv9PVuiFSFNgXO3AdPoU=; b=Q2yAN40niQ+M7GbA/aZTVisu1JRq0guaCVzjY5nxZtwVBzvAYS/s08Gwe01NMlynSM ICjx7QqzKbi6jbQnqSUkd1hp1ojUUS+H0N+Ywd7K0r/+050gH7VEn4CUTS9G+j2p5Y38 S8tngrJ2ClO4bIK7ZaspX2LcstaD8Mf7kAUjDkJmOJIzCGXU6Erz7xkyk4lUKAd+De8U q/IVne2r76uRbs0dIgadlCvwWgrJbJO+R6c909o5YBKJ/1ghAjp+aml+n5Y4e4RxkcNs JAmqDQKno8pzAOT9vkG1YxVEVqBsCsHRXy1lqkMwwekSN4sZejt3e/RH/EC/pRqZ4tYh NASQ== X-Gm-Message-State: AODbwcCEa6aJL9rVLL3xJ+E6LF9rTs4DlSwUPAFQuNcbBFFH+k2hFPI8 jQpvmPfESpSN7R+EXhMQU/rVDmmNoA== X-Received: by 10.36.44.212 with SMTP id i203mr6292731iti.76.1496233305450; Wed, 31 May 2017 05:21:45 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.11.229 with HTTP; Wed, 31 May 2017 05:21:45 -0700 (PDT) In-Reply-To: References: <372C2E53-FC76-4A82-912C-BD296746DEEE@fastmail.fm> From: Barry Leiba Date: Wed, 31 May 2017 08:21:45 -0400 X-Google-Sender-Auth: 2jrf67PWgrFKBr-uHka8Fk55dE0 Message-ID: To: "Kurt Andersen (b)" Cc: Alexey Melnikov , "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 12:21:49 -0000 >>> Most of the effort has been focused on getting ARC deployed in to >>> production so there has been relatively little attention to the "what's >>> next" question. Peter had started a thread a few months ago but it did not >>> get much (or any) traction. How sacrosanct is the "deliverable" list in the >>> charter? I know that we are constrained from going beyond the charter, but >>> do we have to write documents that may not be of value just because they are >>> listed in the charter? >> >> The WG can recharter, but you will need to convince me (as the Area >> Director responsible for this WG) and the rest of IESG that the new >> work/charter is better than the old one. Rechartering is not hard, if there >> is enough WG support for it. > > > Does deciding that a proposed work item/deliverable is not really beneficial > require rechartering? No. Adding things will likely require rechartering, but eliminating things doesn't. Of course, if we recharter for some other reason, we'd remove the unnecessary item as well. Barry From nobody Wed May 31 05:32: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 DC1B7129BEF for ; Wed, 31 May 2017 05:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 bOnyVxAsKDQM for ; Wed, 31 May 2017 05:32:46 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5143B129BD7 for ; Wed, 31 May 2017 05:32:46 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id y190so7463231vkc.1 for ; Wed, 31 May 2017 05:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:from:date:message-id:subject:to; bh=Ggl2nTb3TwJTVBWXSauFa4qodZCo9FUuWntXC9Gg/Fc=; b=eqs8ZupzJD+E6525PmCjr1vlprVLr4/tg+mfMsaStd9QzphUpF9TpokOD6YSUVB1TG 4YG7r8DhYRPWGAOhbjZbjgCrzC8iuEXU+/cpf5HisHWfODg9G8WOGj40Fc88T0TY7Y8P Wgq8oh4HdqmzQHFX4F+6znWLqFUcgIvxm+2wA= 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:from:date:message-id:subject :to; bh=Ggl2nTb3TwJTVBWXSauFa4qodZCo9FUuWntXC9Gg/Fc=; b=ZRoTjjJH33jkQxKY66BvHMRU0z+XMlBkFK/j/gZOAz6nHpeLlu+d1NJfR9qhLvxw2w J1PDsOorAFy0uL6VW6wdaXXbW36QhHTdsevjlnNrPVvxG+r4WBgxXze//g29nkYd5fLk sXxRO8OgAuHeWZPbnk7PS9yHbwzBDUDGinIQbL6GIms3hugFGZaLiC7jPm3PtPijFzvH sKKVLawmUDRzJ13z1VV5o9EDz/s6ib3MWdGRnPUB6SdlJRdhmJ5O0Dpx8Da7ebkyceA0 kYc4aX+EQIj5EYvxPflx2yxft7mN54zugL5fSg/7qIz5NDGBxXVjb2mvC/ZT4y3n7LHY JJZQ== X-Gm-Message-State: AODbwcA35Lei5w5a4fqRb9fk/qHjDvtOxaMHYR7MU7iW/64EIn0AUYaF MGikMuPtCNAi17tuhGicXCTwoY5f8EGv03yjsg== X-Received: by 10.31.178.140 with SMTP id b134mr3669627vkf.79.1496233965052; Wed, 31 May 2017 05:32:45 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Wed, 31 May 2017 05:32:44 -0700 (PDT) From: "Kurt Andersen (b)" Date: Wed, 31 May 2017 20:32:44 +0800 X-Google-Sender-Auth: uaO-178Jd1fDyeV0Mtiy8n8kfco Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11440250fd00880550d11dc9" Archived-At: Subject: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG 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, 31 May 2017 12:32:48 -0000 --001a11440250fd00880550d11dc9 Content-Type: text/plain; charset="UTF-8" For the sake of discussion: I'd like to suggest that writing a DMARC usage guide under a BCP sort of moniker is not a useful activity for this WG. There are lots of white papers and other "how to use DMARC" guides available on the internet. What value would it add to have something preserved in the perpetuity of IETF archives that repeats what is already available? We've written the interoperability review, we've seen the development of the ARC spec to address a large portion of those interoperability problems and we're on the verge of having ARC available for wide deployment and implementation. I'm not sure that we can make useful conclusions about how the state of email usage will be affected until there has been some time for the protocol to bake in. --Kurt --001a11440250fd00880550d11dc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the sake of discussion:

I'd lik= e to suggest that writing a DMARC usage guide under a BCP sort of moniker i= s not a useful activity for this WG. There are lots of white papers and oth= er "how to use DMARC" guides available on the internet. What valu= e would it add to have something preserved in the perpetuity of IETF archiv= es that repeats what is already available?

We've wri= tten the interoperability review, we've seen the development of the ARC= spec to address a large portion of those interoperability problems and we&= #39;re on the verge of having ARC available for wide deployment and impleme= ntation. I'm not sure that we can make useful conclusions about how the= state of email usage will be affected until there has been some time for t= he protocol to bake in.

--Kurt
--001a11440250fd00880550d11dc9-- From nobody Wed May 31 05:38:20 2017 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C12128D64; Wed, 31 May 2017 05:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, dmarc@ietf.org, barryleiba@gmail.com, dmarc-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149623429790.19771.5029015108353285078.idtracker@ietfa.amsl.com> Date: Wed, 31 May 2017 05:38:17 -0700 Archived-At: Subject: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 99 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:38:18 -0000 A new meeting session request has just been submitted by Barry Leiba, a Chair of the dmarc working group. --------------------------------------------------------- Working Group Name: Domain-based Message Authentication, Reporting & Conformance Area Name: Applications and Real-Time Area Session Requester: Barry Leiba Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 30 Conflicts to Avoid: First Priority: jmap dcrup uta dispatch People who must be present: Ned Freed Barry Leiba Alexey Melnikov Tim Draegen Kurt Andersen Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Wed May 31 05:41:45 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 4AAA3128D3E for ; Wed, 31 May 2017 05:41:44 -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 KCLMMViUWvnY for ; Wed, 31 May 2017 05:41:42 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD2412946D for ; Wed, 31 May 2017 05:41:42 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id y201so10364247qka.0 for ; Wed, 31 May 2017 05:41:42 -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=QXiMYVXxPw6iMxw2UKnL0TXxRyB3NdSUEON3n45nbU0=; b=KNUQixLm3hmCrBv3WjBc4eEDhUXRutrLTPHyA+dgTwk3tS+U50zvER+AaFTVDFBjtn qZPHOQafKawYSQbM9liYELgYi38xyWYJJNA0zaWK2jarCjFC/QESohxPI8Ol9o5OCjxJ i2/Paf6b3g1G5n22Ejp62n1L2fd8lVeLV/eYWPXLQDWiYHWq0gNgCEM0eXc36Ltuiyx1 e9nEO0YbRxsN+he/k7qT2dlB/sH6MDqb1acQoTNUjH8g1X2yK5aBeeBMTan5P3kN48m5 Oa4Hc8VbJL2uVo1mesyZDRl3eJIBDGcFtfgtlep3RVWrVyTpPuBUrxBguM7CkA96MSxZ M3pA== 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=QXiMYVXxPw6iMxw2UKnL0TXxRyB3NdSUEON3n45nbU0=; b=F1P430Fa27rUFir9ga5qbLyqs1W+TlqpbWS/f29PtE3cm+f/51OKz48DTSwUR8a6lC 7iP32yg7uDN+BMhVjDoEO32KhZ5BySJL1G5u+MK5qMKvtAyfaBhnTTwGxY7t72lJiviw AveIDDw3SIlVSpZN/VrtXO4XCA9jDI/hAoKlSejP+/udtgL0WYkFnDCDXNbsKQwGDtx1 Qcj2ncm1oQLAl4M0F9thrav7pkrBgbZwzQzBTBDmqZOaGc746Rsu9ix+LoDZHPVRw2Uf PHBPBCc+LiTzyoSGhTqOayIrwbQu0C67ZOmEQCCF+KGEgvXkHs25QmanoVS7k3ePq6zM NEiQ== X-Gm-Message-State: AODbwcCzQXIpVBdZKrlQi2pK7cLu96VnaBRjCE0CMujDMSvi5cP7dqyX +dTUXDTgOnIGSipI5j2SW34QOm4a1w== X-Received: by 10.55.97.212 with SMTP id v203mr7743448qkb.129.1496234501535; Wed, 31 May 2017 05:41:41 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Wed, 31 May 2017 05:41:41 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Wed, 31 May 2017 21:41:41 +0900 X-Google-Sender-Auth: ZsnL9AAxALqd3CMkP4PT5TYIaE8 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 12:41:44 -0000 I have requested a 30-minute slot (in a U-shaped room arrangement). I can change this to 60 minutes if we decide by Friday that we'd like more time. I'd rather err on the side of keeping us tight and not booking people's time unnecessarily. Barry On Wed, May 31, 2017 at 2:49 PM, Kurt Andersen (b) wrote: > On Wed, May 31, 2017 at 2:11 AM, Barry Leiba > wrote: >> >> >> Anyone who wants to work on this at the Hackathon, please register >> (free) for the hackathon >> ... >> sooner is better, so we can track who's participating. > > > Done - I had not realized that the hackathon registration was separate. > >> >> > To me, the biggest point of discussion has to do with the hypothetical >> > next >> > milestone for the group which is currently called out as "document[ing] >> > operational practices..." (the _Draft Guide on DMARC Usage_). While I >> > understand that was viewed as "something that we could do" when the >> > group >> > was chartered, I doubt the need for it as an IETF document as time has >> > passed. I think that discussing the next steps of the group would be >> > apropos >> > in a F2F meeting. >> >> This seems like fodder for a short meeting -- 30 minutes > > > That seems reasonable. > >> >> even if we need to discuss the next steps, we haven't done that on the >> list yet, so we >> don't know that we need face time for it. > > > Most of the effort has been focused on getting ARC deployed in to production > so there has been relatively little attention to the "what's next" question. > Peter had started a thread a few months ago but it did not get much (or any) > traction. How sacrosanct is the "deliverable" list in the charter? I know > that we are constrained from going beyond the charter, but do we have to > write documents that may not be of value just because they are listed in the > charter? > >> Is the openarc project in a state where it would be useful to discuss it? > > > It's usable, has been deployed in test instances and interoperates with > various other implementations (see > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-9). I'm > not sure what would need to be discussed though. There will be a training > session at the impending M3AAWG meeting on how enterprise mail admins can > implement ARC using OpenARC. > >> >> I'll note that DCRUP will have a session in Prague > > > Glad to hear that - I've still been fighting with getting onto that list and > having mail be receivable. > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed May 31 05:42:45 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 B1A9912946D for ; Wed, 31 May 2017 05:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9IRmsclODyQ for ; Wed, 31 May 2017 05:42:42 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 45978128D3E for ; Wed, 31 May 2017 05:42:42 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id t26so10732513qtg.0 for ; Wed, 31 May 2017 05:42:42 -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=jtFacNiGhgRqD7xetirNK99fsmj8R9gksUP3pFfcjes=; b=k/jn0tL/0mD+7uZecJ5WgXJWhAYjHgwA0f/GP9EuCdcIN7UYg0Vg4DNLrnAyUVHeX8 XalhO5eGGrrCVNUbzV55c+qaSupkX7jx22yasRYCeYceyU/i9Md8iRhxwEHVRmGsKO5P y5oP48CzAS1V38L/Fr9kSNPtYA7suw8HiIhKE7ZyDrPFEmi1OIGwV6seU0nIh3on6IBw /n+KiwOMizoOs9ehQBUzZERY8ENld1JCG7omP2Ew6f3IIj+2E0NssTMcSsZwiU152Z2r dTupNSTvJ+o8L5TrAmICrxss7w44qfXT8jpPKJPG0Eyy/OxkxFH/nC3aidzuMm0tWzK/ 31ug== 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=jtFacNiGhgRqD7xetirNK99fsmj8R9gksUP3pFfcjes=; b=cogRm7IwF2JUMc2q8uXaRtbBgwOqPgRRJY7NMey75PTN8zXTGjEaNC4zZRAYEFnDIB Apu5PRdtFe4tHcuLHxY0++A+mcOeWon5obczFdDELPVK/ZStrf55HW0TDAdbiL/0o5mw GZcFIKDxxFpj5eQpaVe5+LipDHRuVERF4mrTRh/mvAWmPEiLBEc7nLeP+IqbMPP6dIl/ ifZ0zzWpYkPIcJHzQyX/V+bugnHA0aCCUzCsww2mjdBGIUayPlF5gC55JfduaGoAgkOl Z7BTCQIm7M23v9KCcqalQ497u0ZW+m7NfbQd8fTvhxqFO/hOYG9ikp7ZlzE7dGpJlXJk LidQ== X-Gm-Message-State: AODbwcBSQgY/RMuXZVO03GkDTSeKMn3Y6X65lNXkvWJYZDpWy8W99vRH mZivWYVv1Zc2IsvKrI1pv35Is0wPhw== X-Received: by 10.200.34.35 with SMTP id o32mr30153740qto.67.1496234561446; Wed, 31 May 2017 05:42:41 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Wed, 31 May 2017 05:42:40 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Wed, 31 May 2017 21:42:40 +0900 X-Google-Sender-Auth: TFiehbExqa209E-UXLBO6FjQD0o Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC) 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, 31 May 2017 12:42:44 -0000 How long do we think we need for this discussion? b On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) wrote: > (Reposting with adjusted subject) > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) wrote: >> >> Barry et al, >> >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: >>> >>> The current spec defines an arc authres method >>> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1). >>> >>> We believe there should also be registered ptypes and properties, that >>> should be stamped (but are not required, as they won't always be available). >>> >>> As long as AR stamping happens at the end of chain validation, when an >>> ARC set gets created this stamp will be included in the AAR, and AAR >>> construction can be clean with no additional language or requirements >>> necessary in the spec. >> >> >> This area seems like something that would be productively explored in a >> F2F since it is pretty undefined right now and there are some divergent >> opinions kicking around... (see the thread with Brandon and Scott so far) >> >> --Kurt > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed May 31 05:47:19 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 A9353129BE6 for ; Wed, 31 May 2017 05:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba1ECZFRAEcs for ; Wed, 31 May 2017 05:47:15 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51149129BDD for ; Wed, 31 May 2017 05:47:15 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f55so10790162qta.3 for ; Wed, 31 May 2017 05:47:15 -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=Ixgs9GdW5+VYbXuPb9UA5STcGnownwEC2ggsS4kyT8c=; b=F1m59gswxhK9ClmVbk1+NCDI41UaOMCDCsx4GHuePHuqUWSlsthWhRMZOFIhl7C4N+ EmYRUUYxF5VE1R+MEpDLSwhVpyOoURDfQn4uSMJMZA9KY/PSn1i83sVs4a0IAgpB9CUz WaJwbQFV8/Iu5CuasJR10ejDK6bDfcsfNuEBVoYnri5meg/ioTpT++/5DMCyr9alCwvB iEwlt/wiMib83JxxDQmYRKvzLCC4SxTIXLQ7IH/evrUSYhN/I/qmvAVwy+ha7nOe+VxK Zl0888TKBSK+GSfhXX+bf/StK03M7u96u+SOIZlHS2oIkEpCzRxRlGgVXz3VZyvKmUcO ypKg== 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=Ixgs9GdW5+VYbXuPb9UA5STcGnownwEC2ggsS4kyT8c=; b=HXJvJBVkZcVyyHo3He3XNW7WfnpCOcE0OHVBjzzFmUsSZayXZYBFXoVuGd/vq7NjLE buu/fxBVBJJVSVdW1jSZB/5S+WUvbX7s4vLHoWihf5tQqXtfSa4O7NnmWUIE1sEWnaw8 43Sr2PMuFA0ta9/Gj7j3xSdb2r/cTgC41xvF4GPggh6sNIIR8/7Vk+4pruH/u5dlac++ PvtuAJD/GOB10zWqsfyV8xJIjo0cyc3aSldDBt7p9VbGaBcd0/IVtcgMgC7peIGsgpYl VhbT3nDAyCsT9gFev567sDZHyAskdJmzEUuIusdh6xeSRxfr8GTcuPCJJHV5fliFKDX0 3jag== X-Gm-Message-State: AODbwcBn8qPrVWGjMOD1s8lmWI6LLhgzvewCZXx5vitgeg6k6HBJV8+v 51joDuvJlIiCVACRM6Sn2D/QQM30tw== X-Received: by 10.200.53.187 with SMTP id k56mr32086318qtb.104.1496234834532; Wed, 31 May 2017 05:47:14 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.36.20 with HTTP; Wed, 31 May 2017 05:47:14 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Wed, 31 May 2017 21:47:14 +0900 X-Google-Sender-Auth: 3T2iHnLyW9Hwc5-pQjEqKz7yxr4 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG 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, 31 May 2017 12:47:17 -0000 I agree with this. If there's stable documentation on DMARC usage that we can cite, there's little value in adding our own, which is likely to end up diverging from the others. Does anyone think we *should* proceed with writing this? Barry On Wed, May 31, 2017 at 9:32 PM, Kurt Andersen (b) wrote: > For the sake of discussion: > > I'd like to suggest that writing a DMARC usage guide under a BCP sort of > moniker is not a useful activity for this WG. There are lots of white papers > and other "how to use DMARC" guides available on the internet. What value > would it add to have something preserved in the perpetuity of IETF archives > that repeats what is already available? > > We've written the interoperability review, we've seen the development of the > ARC spec to address a large portion of those interoperability problems and > we're on the verge of having ARC available for wide deployment and > implementation. I'm not sure that we can make useful conclusions about how > the state of email usage will be affected until there has been some time for > the protocol to bake in. > > --Kurt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Wed May 31 08:13: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 1905D12EA98 for ; Wed, 31 May 2017 08:13:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eudaemon.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 NxOUVzFe8Uqe for ; Wed, 31 May 2017 08:13:37 -0700 (PDT) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (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 A193C12896F for ; Wed, 31 May 2017 08:13:37 -0700 (PDT) Received: by mail-yb0-x241.google.com with SMTP id 202so573571ybd.0 for ; Wed, 31 May 2017 08:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudaemon.net; s=dkey; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wK5CXwihJO3i+NSX6QbS1LGJ1BFrC+hj8jdglgRDRas=; b=dXTHfWpdVjtkvy86ZQyhXcwGK4C1xQchTdICkcyeKkKRLW3XdW+Zkm6WI5Z9SqpkiY 5REgKxhVuOhLVuaX+NI3/h8rOqSyC00lxrKRpc+QdwfmBUjcedrwUY2J1RjFFhTTNqiz tCl7oh7K3tBkDoYEchgVuwP0VP0/hixc5GSoo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wK5CXwihJO3i+NSX6QbS1LGJ1BFrC+hj8jdglgRDRas=; b=YwupmX9rGWtVaIzPyLs0uh1tYcqWhX7oAHTPoQWBMpTpoPoatFcrQG8/ULHgb7xFwf pwSx/piTpst88xiS/25VdqJqw6y+bsLlF0nCbxs77u61z/WjhPl34k/brHVRR2VRa9T1 vinIq1kW/Cx2PXbmiuAFjyZAfhRgpnIULXhmFSbYBGpMlEEAxRCaOGlZlwV9ux09MLMe KlB9CjGZOAZ/nuFtoRYzN/x8gjrMeygY5p3oOS/ovQ+8OlqmFbu//eH3PUZPrx3iVGSI wcAcXAtKgh1Fp8jXSz579ienOnpR6AF0lDtbTUaAsGrrzbhh0CUg/hZ7/iDIqboxiTo5 CkJA== X-Gm-Message-State: AODbwcBVR1/XemUYaaOYJKa4gjfMVqwJnvzaI9hyvbouX4X78AznCoxa jvstlaGJX/7BkUVxIFUnkg== X-Received: by 10.37.122.129 with SMTP id v123mr55475554ybc.157.1496243616675; Wed, 31 May 2017 08:13:36 -0700 (PDT) Received: from [192.168.100.232] ([162.255.170.6]) by smtp.gmail.com with ESMTPSA id u3sm7955856ywu.10.2017.05.31.08.13.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 May 2017 08:13:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Tim Draegen In-Reply-To: Date: Wed, 31 May 2017 11:13:55 -0400 Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <72234A24-E93F-4C92-9092-3C26568789C5@eudaemon.net> References: To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG 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, 31 May 2017 15:13:39 -0000 > On May 31, 2017, at 8:47 AM, Barry Leiba = wrote: >=20 > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. >=20 > Does anyone think we *should* proceed with writing this? A draft has been started on this, with slow progress. The draft aims to = fill documentation gaps based on how domain-level policies can impact = organizations (across the whole email food chain) and how to best manage = impact/interoperability. The original intent of the document was to share operational experience = from the PoV of Domain Owners, third party senders, and email = receivers/processors. For example, if a third party sender wants to = start sending on behalf of Domain Owners, the document would describe = how to do this in a ~normal way. The production of the document was = supposed to get people to share experience, especially in areas outside = of commercial activity. That said, given the WG's history of thin participation, I'm OK with = dropping the Usage Guide. The existing gaps in documentation will be = filled outside of the IETF. On the one hand I'm a believer that an = IETF-produced Usage Guide is better for interoperability than a = collection of to-be-published documents spread throughout the Internet. = On the other hand, forcing a bunch of people to work on a draft isn't = how I like to spend my Internet time. From nobody Wed May 31 13:35:20 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 D6920127873 for ; Wed, 31 May 2017 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFCEqBPJuPfp for ; Wed, 31 May 2017 13:35:17 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587301241FC for ; Wed, 31 May 2017 13:35:17 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id x71so14856158vkd.0 for ; Wed, 31 May 2017 13:35:17 -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=F8WrJfzVKc/+fRslNBjlH2cVAFnvPbg5BOnWfy7aMIg=; b=at2dz4RNo6dFsoDV6u4N6frOiLY8+Nj8YwjTr5NQdDCfWuWA5ANiMRtzqdSbYu/7VB g7wCLyJYNiGt1dwX4IlJi7yeYn2RWzJbFph+TwGzWDYwEErao/Vi6YvfLBx9DNV5FWOh NCyUhWvtxiIWir1QEnetG7ii3XztbrB9kxDq3LpdG9yJGnhDOlwUQ8aZ+aDYc9gbIlcc ntxV07E7MBQ5Dl5YLEmW6XsYE4DXik5524BMSr/G3cw/01KwIxMTpBMDW2kRshcObFnN S/T6FAjirD0lgPvsYzeHU6xywgaIMUx6LN+iATNE4qa+wKnmmi7A6deO3OljhsMshMA6 v2fA== 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=F8WrJfzVKc/+fRslNBjlH2cVAFnvPbg5BOnWfy7aMIg=; b=GiuJhdC/dvvynlv5RG6KAA31bO1WwyuCU99Kjfa8sf7BKwf3RtuiZGbexZlqK4tzKg YA18p/Bj2MxcbhVZyrv4aM0I2qY2heGa7GiPnxPJoNqk+Hj4K9DiShsIsPu1rxf3fRzF nBxyYgpfxgkdbpfaqD66MYBKQ33JMHSwhukEzINXbrYd9PB//J8BDj+R2jJ2k1gg2HhN MnjaSTxZJsfEPGO1ZUJC25AFujoSlnCwQuS5F5WVg5KAFtgF+P/Mmd1jO3RPSQtVVXt9 6Y9bRVRk+HGCiLvKi08ZyhQtyNl2im/bwwEPQIsJlff7NgHAOqNcEAvRqLdJmJVzMxKg qXHA== X-Gm-Message-State: AODbwcCqeqMq51VCWoGUclv8vWk/uHZrlKAAgH3hukYZQuWX2QeqtImf KLXx25X4o1ZJ+HzPPyfxugE5rsNl2Q== X-Received: by 10.31.78.133 with SMTP id c127mr12594000vkb.121.1496262916519; Wed, 31 May 2017 13:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 13:35:16 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 13:35:16 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11485262a13e890550d7db4c" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 31 May 2017 20:35:19 -0000 --001a11485262a13e890550d7db4c Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 6:38 PM, Kurt Andersen (b) wrote: > On Fri, May 26, 2017 at 6:47 AM, Seth Blank wrote: > >> This might be a non-issue, but we're asking this question specifically >> because we've run into an implementation issue within openarc that feels >> weird and seems like a matter the WG may want to weigh in on. >> >> Our expectation is that, for any given ARC Set n, AMS[n] would cover >> AAR[n]. >> > > Yes, that is the intent. The set[n] is intended as a progressively built > comprehensive package: > 1) evaluate DMARC for the message, if it fails and you are ARC-capable, > evaluate any preceding ARC[1..n-1] chain --> post your results into the > message as AR (expected to disappear if there are later hops) and AAR[n] > (subject to whatever protections you need within your ADMD/MTA chain until > the ARC-set is completed; > 2) create and affix the AMS which covers the message, including AAR[n]; > 3) create and affix the AS which covers the ARC-set[n]. > > Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not* >> AAR[n] because AAR[n] isn't created until substantially later in the flow. >> > > That seems like an implementation flaw. AMS should be built in two phases, > both of which follow the creation of AAR[n]: a) blank "b=", b) calculate > the signature, c) append the signature to the end of the AMS header field > value. > What's the added value in covering AAR[n] twice, once with its b= and once without? -MSK --001a11485262a13e890550d7db4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 6:38 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
On Fri, May 26= , 2017 at 6:47 AM, Seth Blank <seth@valimail.com> wrote:
=
This might be a non-is= sue, but we're asking this question specifically because we've run = into an implementation issue within openarc that feels weird and seems like= a matter the WG may want to weigh in on.

Our= expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n].
=C2=A0
Yes, that is the = intent. The set[n] is intended as a progressively built comprehensive packa= ge:=C2=A0
1) evaluate DMARC for the message, if it fails and you = are ARC-capable, evaluate any preceding ARC[1..n-1] chain --> post your = results into the message as AR (expected to disappear if there are later ho= ps) and AAR[n] (subject to whatever protections you need within your ADMD/M= TA chain until the ARC-set is completed;
2) create and affix the = AMS which covers the message, including AAR[n];
3) create and aff= ix the AS which covers the ARC-set[n].

Currently in openarc,= AMS[n] covers all previous AAR[1..n-1] but *not* AAR[n] because AAR[n] isn= 't created until substantially later in the flow.

That seems like an implementation flaw. A= MS should be built in two phases, both of which follow the creation of AAR[= n]: a) blank "b=3D", b) calculate the signature, c) append the si= gnature to the end of the AMS header field value.
=C2=A0
What's the added value in covering AAR= [n] twice, once with its b=3D and once without?

-MSK
<= /div>
--001a11485262a13e890550d7db4c-- From nobody Wed May 31 13:42:20 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 83D5E129BA4 for ; Wed, 31 May 2017 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 cmVO1aYFqqlM for ; Wed, 31 May 2017 13:42:17 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA661292CE for ; Wed, 31 May 2017 13:42:17 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y190so15022547vkc.1 for ; Wed, 31 May 2017 13:42:17 -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=SOmyE+4ouKbJPEwx2PL3/Tcx7Gg36GwnYp9b/y88O9c=; b=ityr0iGOEueNIowbdIdIdA8qhr9L9gKEe5dfk2hM3FjduDxg6DB4AuMkjPdC+Tj/mq wFT4v++7rNC7Oy6e/CU4kBo2GdFldcph/WDwYj8HeHzW+aS0jVIF1eNpdcGo5YlGXN/Z NBuiqNOCPM5X0+g7Y4tE3iyIgJMrMrG+CM6WGeVixDhowOCNAACA/6BvVeZN3p/xO/uV ALelNHWnKxnlRpeWrMkb9PFXXMwst6aX9gHUZdm0tLcbE7719YmuRduqSlbUutSuMmsc ubnt4TyGPaJC56Ya2wqr/Z3PlLxRcJ03DBo75Elu01oyJkiyWXW4YckWTCRmljZQDp3W Pi8w== 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=SOmyE+4ouKbJPEwx2PL3/Tcx7Gg36GwnYp9b/y88O9c=; b=qBWbJ5G4/etr9JBjfaBU667KJpiIVkCiJC7nvSN84wkSDxleUR3+xh6dO5WKI4UWk1 PFESsBmPXPV7Tbsk3xEfUCmQp8VaWpPCsPu/zSTnNx5wj2rBGJbppUVQXAQRIqcTHJ47 gQrDGwcSQneSSXmFROyPDj+ubddfAjVpT1xAlVe+xJpTeix0DBpaxdRZQPwrMjPVdud0 ysrlWmiiYbpxRPDLqvSuxFl24fAC/5cKwbavs+gKma/2TFf4W09wNAAwr5jJ+QSzOwNy 9KzgPkSE95MafISF7D5VcT/LQx9O2bymqOgKu2WJmYDm/EgX3bGi2BfCKvsrqSpcqe98 i5kQ== X-Gm-Message-State: AODbwcAXCWx4j7WR+oG4SQgyhwYcuW0H+QYendAac4wqQtNZsbOXzzL8 QRe7ftLNbSJfjMRdtOaoAXq3Y3fJYg== X-Received: by 10.31.98.196 with SMTP id w187mr12646174vkb.96.1496263336404; Wed, 31 May 2017 13:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 13:42:15 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 13:42:15 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07b57aa82b5f0550d7f432" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 31 May 2017 20:42:18 -0000 --94eb2c07b57aa82b5f0550d7f432 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy wrote: > > What's the added value in covering AAR[n] twice, once with its b= and once > without? > > Sorry, that got out before my thought was fully formed. What benefit is there to covering AAR with both the AMS and the AS? It seems to me the AMS is much cleaner (in the sense of ARC being a layer atop DKIM) if it is purely a renamed DKIM signature with an instance number. Put another way, the apparent intent here is to require that things be generated in a specific order (AAR, then AMS, then AS) but it seems to me there's no obvious benefit to imposing that constraint given that AS is supposed to cover everything anyway. -MSK --94eb2c07b57aa82b5f0550d7f432 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:

=
What's the added value in covering AAR[n] twice, once with its b= =3D and once without?

Sorry, th= at got out before my thought was fully formed.

What benef= it is there to covering AAR with both the AMS and the AS?=C2=A0 It seems to= me the AMS is much cleaner (in the sense of ARC being a layer atop DKIM) i= f it is purely a renamed DKIM signature with an instance number.

Put= another way, the apparent intent here is to require that things be generat= ed in a specific order (AAR, then AMS, then AS) but it seems to me there= 9;s no obvious benefit to imposing that constraint given that AS is suppose= d to cover everything anyway.

-MSK
=
--94eb2c07b57aa82b5f0550d7f432-- From nobody Wed May 31 14:32:29 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 D1BA4124D6C for ; Wed, 31 May 2017 14:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 yLS1HcAABf10 for ; Wed, 31 May 2017 14:32:26 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 7B696124234 for ; Wed, 31 May 2017 14:32:26 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id y4so17205103uay.2 for ; Wed, 31 May 2017 14:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q6H3ABsJ4l/+fx97B2FUBozqTRfz7WLHxU0jIwioaDM=; b=N9YYdZgSushQS7IdnUqCf+N5Bd1S5VB4MCUSPmUImwAylLeOnPx7DMcVh9jySAzMc6 qZJ/rs2NmkQ62DY53wcVs2AfGOtSN/T75NyAGVmDG8QeqDA8N4sbczIpIrKVtByPuI4q TzPSPv2Iw5v0xjcih+AvIMD6kVt9V2svvkE0vu0Ivn2YLVk3B1fDmmed3WR+N2lFXcPw qxQ2TOcaHfig5H1/VwV1/+fOwY+ZRP1WBGOjER0OML+9g641II98EYQmWg+kmSsxyAEY GaYBaI0zM1dB9NJkC25Coae5cI5zdrLxQqX1OLh3F0y3Hrpw0QUTQSP5PrvqHczwT2/G Jucw== 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=Q6H3ABsJ4l/+fx97B2FUBozqTRfz7WLHxU0jIwioaDM=; b=ryMqeb6bqS5yvnWmchxPVOcqbv0hq0bYO6QTqh7hShOcRv5mBAU80arUVXqfSi0Cty WYsqbWNeK8NK95A2aMZ2MwDfvLxTBZhyGa7PVTZO9HfwzKGcKeqwApnW1nX3sfMC4lvF FZHjqcYLqY4d5ABQvu8Eh166Mb0hUZjm6oLLWk2V6OcAndqxllyrFksR1s0874H8/AY5 gOtFKsZIuITv19QbZpjGMBEJJS+YbLXseyeOSMdQLeu3ElGL9yCYW1sjezj2EvFs5Cgb 6PAsLgv7BcVhWZTPaxhGtSkWAghqNaY+rlX5Td7hcw32nyqhfmZbK8FlnOL7Wb4oiuwn 4b3Q== X-Gm-Message-State: AODbwcBPPXF/GSQL5X0vFNABHWAbc5tWMRB4Telg3lshoIfIsh0toYeY WAVubC+EDMojQ5tZDah+WUxZxwIMbwPK X-Received: by 10.176.75.142 with SMTP id v14mr14872058uaf.14.1496266345500; Wed, 31 May 2017 14:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 14:32:25 -0700 (PDT) From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 14:32:25 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043626540356ef0550d8a861" Archived-At: Subject: [dmarc-ietf] cv=invalid 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, 31 May 2017 21:32:28 -0000 --f403043626540356ef0550d8a861 Content-Type: text/plain; charset="UTF-8" I think this was discussed before, but perhaps it didn't reach a logical conclusion: If a verifier decides an ARC is invalid, it's supposed to set "cv=invalid", when generating its own ARC-Seal. This seems odd; we're cryptographically signing a chain that is known to be broken, meaning the next handler might not even be able to get as far as consuming the "cv=" value we're putting there because the chain can't be validated in the first place. Perhaps a better approach would be to use the regular A-R to indicate the chain is bad, and stop. Any other ideas? -MSK --f403043626540356ef0550d8a861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this was discussed before, but perh= aps it didn't reach a logical conclusion:

If a verifi= er decides an ARC is invalid, it's supposed to set "cv=3Dinvalid&q= uot;, when generating its own ARC-Seal.=C2=A0 This seems odd; we're cry= ptographically signing a chain that is known to be broken, meaning the next= handler might not even be able to get as far as consuming the "cv=3D&= quot; value we're putting there because the chain can't be validate= d in the first place.

Perhaps a better approach would be to us= e the regular A-R to indicate the chain is bad, and stop.

Any = other ideas?

-MSK
--f403043626540356ef0550d8a861-- From nobody Wed May 31 14:47:24 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 D53191293F4 for ; Wed, 31 May 2017 14:47:23 -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_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=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 4XDL4-1bE577 for ; Wed, 31 May 2017 14:47:22 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 99BE9126D85 for ; Wed, 31 May 2017 14:47:22 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e193so18667276pfh.0 for ; Wed, 31 May 2017 14:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=i6AGwkmPcCfIZwzDP9PJK4h9gPnFdh7NKHcFBsYEg7g=; b=QTu0feeSwvN6UbOTM9fd5BVzIABxCKpZ+U2l+cpscIAhyoXgXrf24zM5Fx9MGSNM8X 4k4BM1metRJ/Ai5CN76v7d7bjMjOHVop3O/bfWYQS30FUpI/x9oC4r6wgULzqIR3oZ/p 1qXK1ZM6IRfpqsS2dAmBm2Msw/L4S04NuhPj1EzLUmMC6A/K62aZSqqRoHh0CRTVxSSf j8UnDXuy32TR7rdRh93INqRJzpcxLjhq0xs4ActPcGhkJ495Nyh4u5z4lXTX8VSaRKOz iw/m7PPVROH1UcqHcLxij0I9xrkBZ2t2B+JuC74+5yekrG5NHvOOCOGjZcMlzIgnuLF3 uS4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i6AGwkmPcCfIZwzDP9PJK4h9gPnFdh7NKHcFBsYEg7g=; b=nQJ71t0C4XED+Dpv4Jvf6M0AbeW6YgXoUVQ7FvHvf730/b9O4chhsRegvzq4IVPvOc OhLUx5kdrLMdrNWu5vX7w11sIAwNKK+e4ttmVhbUdoAE8whgjHGoL17vXjferGNFDQYw qfmT5FPS0eGDGmeCN+5x0sOC5PrBPfLIaqkVl/FdiVxz/9agr0q7RwQIHS1q9S3FNvj9 D4M03P6IY8g6HsjxoHJbr/k6BE+LroGClKx46wLDBr3hGBUcLrZfP/3lC1qFcMdyBQyb uYsvxy9YKqIUpoUqYlG5EBVIjWx6Q025PReBXknCheZbC8ijOYKNycSNzMKswVMiMvbu Tvpw== X-Gm-Message-State: AODbwcBhN3nmjLSd9xZBmpcCVL6W1fboTJTjLqZ3or8VIqKyoh/Gz8Pw lX5Cl0pAY/sOPcd6YMc= X-Received: by 10.99.150.2 with SMTP id c2mr24470646pge.27.1496267242040; Wed, 31 May 2017 14:47:22 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d17e:7fe3:9cb7:7c98? ([2602:304:cda0:8800:d17e:7fe3:9cb7:7c98]) by smtp.gmail.com with ESMTPSA id w67sm30927753pfi.2.2017.05.31.14.47.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 14:47:21 -0700 (PDT) To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: From: Dave Crocker Message-ID: <7a3cd57d-c631-f27a-67dc-7936b7b522b6@gmail.com> Date: Wed, 31 May 2017 14:47:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] cv=invalid 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, 31 May 2017 21:47:24 -0000 On 5/31/2017 2:32 PM, Murray S. Kucherawy wrote: > If a verifier decides an ARC is invalid, it's supposed to set > "cv=invalid", when generating its own ARC-Seal. This seems odd; we're > cryptographically signing a chain that is known to be broken, meaning > the next handler might not even be able to get as far as consuming the > "cv=" value we're putting there because the chain can't be validated in > the first place. > > Perhaps a better approach would be to use the regular A-R to indicate > the chain is bad, and stop. +1, except I think not 'perhaps' but rather 'definitely'. If it's broken, it's broken. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 31 15:07:30 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 5B357129445 for ; Wed, 31 May 2017 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 rk5eSvQxMksx for ; Wed, 31 May 2017 15:07:28 -0700 (PDT) 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 DB6E91271DF for ; Wed, 31 May 2017 15:07:27 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id j17so17662812uag.3 for ; Wed, 31 May 2017 15:07:27 -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=1azA4lv0tEzGu1G1JBR7nY1vVwcr8P0eMuHr0josJFI=; b=okp7VxovUq89YbFJY+QxSHJgrDz42nHb0Jo9Q+Jrs1koSEcEtoKsAlT/j+cokS55v4 CTUygUHq4Xx1gl/ZKhN9n2VD7YokKsN2OGHV9D/D47/rNpM5f/CnTa1pcbcvpEvvkgmk 9ZMBQ//UQXot55KJp6KDwvGDz6TTf/GA8u9IWPIit0RyL5vNoy6FXbH+cr3xJpmhyGLY 1FmdBSNEMQZQLyJ5qQr80du8rgSied82f+PJpGFH6dg/dR550n3MCytpVI3W1Po01dMr 0Y9VWCD+9fdpQBN///59geR2zhs8NrCHT1KS+F6IqX4iVjqafjXFHhl/A12GivSHqZU4 yfBA== 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=1azA4lv0tEzGu1G1JBR7nY1vVwcr8P0eMuHr0josJFI=; b=KgTIoDK44viJawOLi0LwNm0+jxCPiBHdWJ8XQ318bpZOPKK0rTcIBcKIIhzdSTeUDU cbkTN/ygJwaRLFSepdAbKM/Mx887g44YNdSb3s53TgJqWTE3cSCHD1QxsUBcjSaIQLAj 54r24r7pbeDMRiIesEsFNgHMPaDx3O5D3vhHDDvB7gykhrVzFiSxLogUcOiUQDzVY4iE tGF8dWmaYn+/bic1w8RdCekSyZF2De6NFNFCzumq4se9dpBgoiPcctPNQWrSgWIFCO7I ez3eChP/k3Q4gQmDY3QdYJdbiZxUEo91rtaF1CMpUeuxkWCX46p4OPCU6E5AHViXnah9 OgQQ== X-Gm-Message-State: AODbwcBFESRHJ1Ewg4GetHQpny4efRHXg/YJBgpT+2Kgh+Fhu211ks1T b+dhIgzkxFU+NpddvfQsM+qKyjpnZQ== X-Received: by 10.176.94.133 with SMTP id y5mr15400463uag.150.1496268447032; Wed, 31 May 2017 15:07:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:07:26 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:07:26 -0700 Message-ID: To: Barry Leiba Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c5684462b620550d92516" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 22:07:29 -0000 --f403043c5684462b620550d92516 Content-Type: text/plain; charset="UTF-8" On Mon, May 29, 2017 at 9:49 AM, Barry Leiba wrote: > We've had one request for a DMARC session in Prague, with no further > response from the working group. > > We've had one suggestion for an interop test in Prague, with no > further response from the working group. > > I would like to schedule a session -- at least a short one -- but I'm > not going to do that unless I hear from some people that (1) you'll be > there and (2) we have something useful to discuss face to face. > I will be in Prague, and I think there's lots of stuff to discuss, but we only have a small number of people active so I'm fence-sitting on whether it's worth convening formally. -MSK --f403043c5684462b620550d92516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 29, 2017 at 9:49 AM, Barry Leiba <barry= leiba@computer.org> wrote:
We've had one req= uest for a DMARC session in Prague, with no further
response from the working group.

We've had one suggestion for an interop test in Prague, with no
further response from the working group.

I would like to schedule a session -- at least a short one -- but I'm not going to do that unless I hear from some people that (1) you'll be<= br> there and (2) we have something useful to discuss face to face.

I will be in Prague, and I think there's lots = of stuff to discuss, but we only have a small number of people active so I&= #39;m fence-sitting on whether it's worth convening formally.

-MSK
--f403043c5684462b620550d92516-- From nobody Wed May 31 15:08:06 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 DFCA612EA55 for ; Wed, 31 May 2017 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JzmR6SkIXRa for ; Wed, 31 May 2017 15:08:03 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 8D2DD1271DF for ; Wed, 31 May 2017 15:08:03 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id h4so33107876oib.3 for ; Wed, 31 May 2017 15:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mR7ZNw0pGNwc6fo2RSpFZ11tm8FAlHux6SI54j+tPXY=; b=FRZr2oBjuYTYtuOEHJBp6ijF+aEjRsEPbwQHfQ8HvCgv1ycabbOh0BkYShFxgftpKn PJcFg5SYBbc59N7wyGv0qA+8DJcFt/q9vMJLyC4uzdgGFK+HUPe0kqKI2moKEYVtnIpm /nS7WmwIGkezj2NyR44oC7eXSwD8nIJrG6IhlOU5lvOpFZ7VH3BjlmsIebfL6G79rMlP EjAP52YZxSW990wZezDpeRSSD4PPJ4v+6izDOmfeGWp4kOlB4AMJzJ3Rb04rn5eSigC3 7Hv7XFmp7eL5F7l6RCObGTs48PJsfV1ptCMeJ9kdlSMCR24Hd19nWwDrV65bGuaCbiPm bCmg== 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=mR7ZNw0pGNwc6fo2RSpFZ11tm8FAlHux6SI54j+tPXY=; b=fQRWMU0PMA7+2jgHEDpBGhy79hwQSPlttKFk46GhJ7OYw5gfmf0GVhS+ZBCEPJKsyh CvZjZRcPpm2vSa6rN09ghllQHQEncpa7OWc8b+gwFgm7n9TwL2CadHRSx/sygTV35zcZ /RDVnaKpy2Lr/1ZISk7AK6yJPxc07aG4/ndQZdefveAVD2wvrKc9ESx8ddLqB1EY4iED epqAUfAq53THNk9tarNDt4CWqAFVI+s20MFeIkxER+jD6mPMpBSwUjYmeGlSdYXIeYf3 GtQKD6p8roY1arKj8qba6L+Az5vK1Qblad1K2JhYr9OI/wRMll24vE1TdgsXuzLGrXQf c6YA== X-Gm-Message-State: AODbwcCFMQT+0CGeeaFI+0CD+u/GJ2Uoi1p1bYF/uakUn7oW3wHaCJaB CuOhoIQeuq0n2OuN/mqrYnT723acaZYy X-Received: by 10.202.170.12 with SMTP id t12mr13580498oie.44.1496268482549; Wed, 31 May 2017 15:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.8.34 with HTTP; Wed, 31 May 2017 15:08:01 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Wed, 31 May 2017 15:08:01 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="001a113cdef464afe50550d92733" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 31 May 2017 22:08:05 -0000 --001a113cdef464afe50550d92733 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy wrote: > On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > wrote: > >> >> What's the added value in covering AAR[n] twice, once with its b= and >> once without? >> >> > Sorry, that got out before my thought was fully formed. > > What benefit is there to covering AAR with both the AMS and the AS? It > seems to me the AMS is much cleaner (in the sense of ARC being a layer atop > DKIM) if it is purely a renamed DKIM signature with an instance number. > > Put another way, the apparent intent here is to require that things be > generated in a specific order (AAR, then AMS, then AS) but it seems to me > there's no obvious benefit to imposing that constraint given that AS is > supposed to cover everything anyway. > Ignoring your DKIM bit, I can also see how this could be extended to think about the oddness that having two signatures and whether the keys need to match between AS/AMS. One could imagine that the AMS was just a hash, and it would be a single signature in the AS which covers it. That's obviously more different than DKIM, but reduces the size of the headers and makes a single point of ownership. Brandon --001a113cdef464afe50550d92733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy <= span dir=3D"ltr"><superuser@gmail.com> wrote:

<= /span>
What's the added value in covering AAR[n] twice, once with i= ts b=3D and once without?


Sorry, that got out before my thought was fully for= med.

What benefit is there to covering AAR with both the = AMS and the AS?=C2=A0 It seems to me the AMS is much cleaner (in the sense = of ARC being a layer atop DKIM) if it is purely a renamed DKIM signature wi= th an instance number.

Put another way, the apparent intent here is = to require that things be generated in a specific order (AAR, then AMS, the= n AS) but it seems to me there's no obvious benefit to imposing that co= nstraint given that AS is supposed to cover everything anyway.
<= /div>

Ignoring your DKIM bit, I can a= lso see how this could be extended to think about the oddness that having t= wo signatures and whether the keys need to match between AS/AMS.
=
One could imagine that the AMS was just a hash, and it would= be a single signature in the AS which covers it.=C2=A0 That's obviousl= y more different than DKIM, but reduces the size of the headers and makes a= single point of ownership.

Brandon
--001a113cdef464afe50550d92733-- From nobody Wed May 31 15:11:18 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 3E88A129445 for ; Wed, 31 May 2017 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt1YcQSzbnKe for ; Wed, 31 May 2017 15:11:15 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 B2C451271DF for ; Wed, 31 May 2017 15:11:14 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id y190so16063495vkc.1 for ; Wed, 31 May 2017 15:11:14 -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=NPI+PxxRXGEfgmn3Bzp3aI6GfvshtKtMjpQZW20RNKM=; b=cArh4mfcT6+Int7FKiB86PlmryzrQM3OPgPmGMx5OatQPnXSYlP8C8cyXmZxtXJdKc /ho2YCeMulbQnYdZNUgWzhHgxx2J3+iN0qj8fKcDqXdt05DBoeLA7VY0cT1BSMrrNlBg TJeeeP19XWQCSalsUPMWQlNdOm5ntymZPH4rk8inMNxKjOuRs9Wxc9u7jghaOO0kd1W/ nhn373vOzsTYFoEKyYE8VAXvCOYipqote1dQ78sBlKLzoTFH7/8pEDAzGnr8Hkvuu0FJ GiIWN6rcXtLhMcRMp+Lm4qkvCTF+Lr6gPdgmIDelOzSf84LW7hbJOEDkuosTExMFhcHn GrJQ== 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=NPI+PxxRXGEfgmn3Bzp3aI6GfvshtKtMjpQZW20RNKM=; b=RxlY8Ee7fhQr3/4XSPgyyB1ob81UltCbBYpGdKuz7BJAOz8AfBkRJjEmWTKhYt85KK EOnaAtefv6DxI7SJKb2RXdbJfHwG4fO4R/dnRXqEyfTAJ8Ct8jPiDG+/pE/GtZ6keL9M 0YCsbDCwqjAhD3M/fiR5tm//9KzX3T7GoaKaR8Nds9QJAKTgQGr7yoWQBGR0az6uIn8R 5ghhqHFxv/AW9SQjRkHcjX/E2b8jjRwkbXGSlx//K0VX5pcfHf+tq/X5woeJuinfm+uH jNQR7t8X71O4/N6QNF/2DVGtHnzImiN/63+3OYRe5rzwq5RqUkxyoUDxnR6/EQcjNxJE ZDLw== X-Gm-Message-State: AODbwcAxRrN1fR1beYAF9152tsvXj7EbGldfaW2eL9huMmQJnkHLgOTF xd+WCrxHDHOTD2FFkvIQ2xmk4lfaCdvB X-Received: by 10.31.78.133 with SMTP id c127mr12781720vkb.121.1496268673829; Wed, 31 May 2017 15:11:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:11:13 -0700 (PDT) In-Reply-To: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:11:13 -0700 Message-ID: To: "A. Schulze" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11485262cad0820550d93216" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 22:11:16 -0000 --001a11485262cad0820550d93216 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 7:57 AM, A. Schulze wrote: > Am 29.05.2017 um 18:49 schrieb Barry Leiba: > > We've had one request for a DMARC session in Prague, with no further > > response from the working group. > > I didn't follow all ARC discussion over the last months. An update > is welcome. Also it would be helpful if Murray could give an update on his > openarc project. > I can give an update on the list. Status reports aren't a good reason to hold a F2F meeting; meeting time is for discussion. -MSK --001a11485262cad0820550d93216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 7:57 AM, A. Schulze <sca@andr= easschulze.de> wrote:
Am 29.05.= 2017 um 18:49 schrieb Barry Leiba:
> We've had one request for a DMARC session in Prague, with no furth= er
> response from the working group.

I didn't follow all ARC discussion over the last months. An upda= te
is welcome. Also it would be helpful if Murray could give an update on his = openarc project.

I can give an update o= n the list.=C2=A0 Status reports aren't a good reason to hold a F2F mee= ting; meeting time is for discussion.
=C2=A0
-MSK
--001a11485262cad0820550d93216-- From nobody Wed May 31 15:17: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 38D7212EB0E for ; Wed, 31 May 2017 15:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 bivmHKtCALrB for ; Wed, 31 May 2017 15:17:25 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B063E129C31 for ; Wed, 31 May 2017 15:17:25 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id 19so23533168qke.2 for ; Wed, 31 May 2017 15:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=byrjjYV0pjLZItafgPnTkc0DFiV8/pf4JvtFE9TQ8Vo=; b=bLNHDTCBS1vJKpuqE1a3xYY/3tCWUVlUNikgPWqGyr64Sges6s5lz9y5C+KLARS+BX MvXE6E5dtIpnDgFxGEgM2GsSezhPESrJMKH0qS2A/3oPv8q2IjXUZkihiuyp0iCylbjD ZB1YS6PcmUZACayACIrtZgR6MSEZiOKZnE3e4trVB4YZtBefw8q7AaDQUECFgAmZdNdh iPUrPWevH9gPIOwqeHxSlIPRADwNatPm7f4sSgKXOhtf/NKzs78kBXVvRSXxUlobIS2q z4TBR6ECnYc2pMJ45jaarrIqxPbl0eNqV96DE4u8VQModBcFKYVIEfuMuErrHyLsiBem U3kw== 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=byrjjYV0pjLZItafgPnTkc0DFiV8/pf4JvtFE9TQ8Vo=; b=t7OSsXGhTXfzj2yZ4rHMjh3YMLKDrFCguOmqW2z2iX6dcuZWEVWC9RaTH25Ufi7e8+ xQbZ8H32cEFS+4fzQPMomPeaOgL0UuGBrw2lpF5vs4y6LuLCgATJO4wB1qmAb8QkXvyr tc5XTe2av5oOR1lLPVnYn1IbzuaQG2xLpK21hxqRuf4eUVO5JizIBG4UrsmuJnWfPOvW fYJ9t/DLeXmjJGAF0Cy23xZ0C6GF3UhuD/jGUXofbEfMsSuYO4vnh2lFmqdpD5ikIX37 ALMzXHYMaxcEtBCY5kHuibclI2RfYXyHXfs0duA5NUpVDIqEuYbTZaydzfILVmjv0RwW e7lQ== X-Gm-Message-State: AODbwcB18qLXR163wq/IfRCSaUTl48y6TcTO/dwCld7GTGPqOMKio4ai Eimy0b54mWpz044G0VSe6ljL9BT+Ynsi X-Received: by 10.233.216.194 with SMTP id u185mr30063545qkf.105.1496269044877; Wed, 31 May 2017 15:17:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 31 May 2017 15:17:04 -0700 (PDT) In-Reply-To: References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> From: Seth Blank Date: Wed, 31 May 2017 15:17:04 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: "A. Schulze" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c043d72e89b840550d948f6" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 22:17:30 -0000 --94eb2c043d72e89b840550d948f6 Content-Type: text/plain; charset="UTF-8" I'll also be in Prague, but will unfortunately not be able to make the hackathon. I think there are four items for the WG to discuss that most likely will not be resolved by mid July: - The ARC specs (the current spec and the proposed spec, and how to merge if this is what the group wants) - The AR stamp for ARC - DMARC reporting of ARC results - And moving DMARC to standards track / any required rechartering therein Seth On Wed, May 31, 2017 at 3:11 PM, Murray S. Kucherawy wrote: > On Tue, May 30, 2017 at 7:57 AM, A. Schulze wrote: > >> Am 29.05.2017 um 18:49 schrieb Barry Leiba: >> > We've had one request for a DMARC session in Prague, with no further >> > response from the working group. >> >> I didn't follow all ARC discussion over the last months. An update >> is welcome. Also it would be helpful if Murray could give an update on >> his openarc project. >> > > I can give an update on the list. Status reports aren't a good reason to > hold a F2F meeting; meeting time is for discussion. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --94eb2c043d72e89b840550d948f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll also be in Prague, but will unfortunately not be = able to make the hackathon.

I think there are four items= for the WG to discuss that most likely will not be resolved by mid July:
- The ARC specs (the current spec and the proposed spec, and how t= o merge if this is what the group wants)
- The AR stamp for ARC
- DMARC reporting of ARC results
- And moving DMARC to s= tandards track / any required rechartering therein

Seth

= On Wed, May 31, 2017 at 3:11 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
= On Tue, May 30, 2017 at 7:57 AM, A. Schulze <sca@andr= easschulze.de> wrote:
Am 29.05.2017 um 18:49 schrieb Barry Leiba:
> We've had one request for a DMARC session in Prague, with no furth= er
> response from the working group.

I didn't follow all ARC discussion over the last months. An upda= te
is welcome. Also it would be helpful if Murray could give an update on his = openarc project.

I can give an u= pdate on the list.=C2=A0 Status reports aren't a good reason to hold a = F2F meeting; meeting time is for discussion.
=C2=A0
-MSK

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




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--94eb2c043d72e89b840550d948f6-- From nobody Wed May 31 15:22:06 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 35DB712944E for ; Wed, 31 May 2017 15:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPTjgHU9oJ_g for ; Wed, 31 May 2017 15:22:02 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D4212783A for ; Wed, 31 May 2017 15:22:02 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y190so16171285vkc.1 for ; Wed, 31 May 2017 15:22:02 -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=3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7iVPPBvW59s=; b=jNIH1nyxoMh3rV9rX36sIijSAzfrItD7Rnvr8MzPDnPF1CirS5jqQcY+ZtOd+KoE6N synPIINX776FWBGXCAA5PLJoFdnR2yojpa6IJZnC2LNCC41lbk90xUyQQfy9Uv1daGm2 mP8cG/9deygD080dRQHjCxLOVsy8ZzRKE9dzO9aOMgEwXc9FCdOaU69LeupXdL/zF6n5 Aqubem4s7LpS2Mf5x6h444IytLf3jSfx9giLKXqpE2JsZbDKOOZyNLBZsd2D3C7RHX0O obIpKbRfDySLlBs/P0Sx38+qe3T+ePKu8jqxDcLDX16cXQ8ycp/ku3cKg3hcqDaL7g8W WYhg== 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=3Yg5aVXobpP5fEP6VLnpuEPddr3SuybR7iVPPBvW59s=; b=QBqK/fDpaHk7fXlz5dqa8/va4UsMFZ1B8OShSAcXq20IEdAQg2DTrae5GVhlDiNEiB fJV6vffR+iySM8qjAYpEeobj9jXVMThUj2JMzvZqqZP8koL9f0zPxxdBN72erOQtzL1h IBStsFcsTBqASH1nD2oRhgt7pdYrcd+j6L4LtsCGNWWvLLFIT6qOAk/inpdXhT7Q03hv 6j+qB/cyLmtaXXEM6WFkWkU1WFVKH/iY63bSs/NR5PoxLtLxOadUX506vk+wxcuAyVGZ ai3EWbkTTHr4jcBaDMSjY1vOtDJzsdEvSRLKIMP/DGsXOHn2lQvPUHebse7+uA5B9q9t YOGA== X-Gm-Message-State: AODbwcDeZ4P9FVDmRJK3MCU0USRpNnBrqQV3Hx/rF2bXS7YUNMGx+rjC 7+YmFiakitqj3iA5FbUi6FsNAlxZ9Q== X-Received: by 10.31.98.196 with SMTP id w187mr12839914vkb.96.1496269321837; Wed, 31 May 2017 15:22:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:22:01 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:22:01 -0700 Message-ID: To: Brandon Long Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Seth Blank Content-Type: multipart/alternative; boundary="94eb2c07b57a6aa3910550d95970" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 31 May 2017 22:22:04 -0000 --94eb2c07b57a6aa3910550d95970 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 3:08 PM, Brandon Long wrote: > On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy > wrote: > >> On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > > wrote: >> >>> What benefit is there to covering AAR with both the AMS and the AS? It >>> seems to me the AMS is much cleaner (in the sense of ARC being a layer atop >>> DKIM) if it is purely a renamed DKIM signature with an instance number. >>> >>> Put another way, the apparent intent here is to require that things be >>> generated in a specific order (AAR, then AMS, then AS) but it seems to me >>> there's no obvious benefit to imposing that constraint given that AS is >>> supposed to cover everything anyway. >>> >> > Ignoring your DKIM bit, I can also see how this could be extended to think > about the oddness that having two signatures and whether the keys need to > match between AS/AMS. > > One could imagine that the AMS was just a hash, and it would be a single > signature in the AS which covers it. That's obviously more different than > DKIM, but reduces the size of the headers and makes a single point of > ownership. > Indeed, AS could sign (a) a locally-generated DKIM signature, with an instance tag (since DKIM validators ignore tags they don't know), plus (b) the current and all previous AAR/AS fields. -MSK --94eb2c07b57a6aa3910550d95970 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 3:08 PM, Brandon Long <blong@googl= e.com> wrote:
= On Wed, May 31, 2017 at 1:42 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
On Wed, May 31, 2017 at 1:35 PM, Murray S.= Kucherawy <superuser@gmail.com> wrote:
What benefit is there to covering AAR with both the AMS and th= e AS?=C2=A0 It seems to me the AMS is much cleaner (in the sense of ARC bei= ng a layer atop DKIM) if it is purely a renamed DKIM signature with an inst= ance number.

Put another way, the apparent intent here is to require= that things be generated in a specific order (AAR, then AMS, then AS) but = it seems to me there's no obvious benefit to imposing that constraint g= iven that AS is supposed to cover everything anyway.

Ignoring your = DKIM bit, I can also see how this could be extended to think about the oddn= ess that having two signatures and whether the keys need to match between A= S/AMS.

One could imagine that the AMS was just a h= ash, and it would be a single signature in the AS which covers it.=C2=A0 Th= at's obviously more different than DKIM, but reduces the size of the he= aders and makes a single point of ownership.

Indeed, AS could sign (a) a locally-generated DKI= M signature, with an instance tag (since DKIM validators ignore tags they d= on't know), plus (b) the current and all previous AAR/AS fields.
-MSK
--94eb2c07b57a6aa3910550d95970-- From nobody Wed May 31 15:24:48 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 D752C12783A for ; Wed, 31 May 2017 15:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, 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 (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 EW90OXpUuDGb for ; Wed, 31 May 2017 15:24:45 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 62683126D45 for ; Wed, 31 May 2017 15:24:45 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id p85so16055609vkd.3 for ; Wed, 31 May 2017 15:24:45 -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=dwjM5NQiVc0eFSeBXivIlg4PUgt/gbe7sMBA8y/hKTE=; b=ZhHFXyLqafdjjOqWii41dgNm1/cZRmpiWgsK0xSJtIpZqFTQTLe03mrR320QZI56DP k/5mcIWj76+TP0/fx1Z4vnsnBesKkaMAr+cHvxKpAQwVBgAZO7kSWUJVFqhy31eDgYI+ DhqkQfPlQSwqcqQ5hgpBzXo7loz/41GpNaEaepRaf0e0NLDe7bUQ4oJSzJBClYibUL0w I/U435uh1YE9AEVlouPH2TLnfNdJX2/plS2B9YaNtWL7tXif3GxXDdrG3wJWU1sa7NQN uIfKxNoXn+2vM6kuwqyFFZarIA6FWt8VMRR/Ia/6Aua2EJHGBzRg00SPEAw7VF0a4/bt R/RQ== 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=dwjM5NQiVc0eFSeBXivIlg4PUgt/gbe7sMBA8y/hKTE=; b=nc+3hlJmnqYUjZ27m367r7ttisf0bq98ZKUcz0JBFfqTfFw8Uzf2ezvdhO8+gcjGaT mU5cl90T1s6bo4p/JzBjhMDsWOG3nHkIZPTZeMhzNAnMHVIAm4JClShJohlo5Do/dz+g jvlfm9OHJHZ8NYimDCS1T2d0g0vlZbgyvcDtXn/gWzbZqCHPLeHBDIxcQ9iJsdn3rD+w JZCCncgGx00APIxxtL9fq6M6y9PinIJndAcghQwo0VLdWn4G4D1kIo/Ifsdcb1i8do60 Mc38FSkx1Ec1nFSGh9lHC/+xJcAklzBkrUXNsaTvdQyHr1HLwGmdcb0qNNVzAXQ6mM4l XO/Q== X-Gm-Message-State: AODbwcCc6uFaFSyk95C5ChHJ5D+nOAW8lbajZ3+FgjHeQ52LT8RheCNJ sfIIj23juOmFH1OMw1he3miifRtr4jp6 X-Received: by 10.31.170.2 with SMTP id t2mr13667584vke.100.1496269484581; Wed, 31 May 2017 15:24:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:24:44 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:24:44 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" , Gene Shuman , Brandon Long , Kurt Andersen Content-Type: multipart/alternative; boundary="001a11430a721de80b0550d963b5" Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 31 May 2017 22:24:47 -0000 --001a11430a721de80b0550d963b5 Content-Type: text/plain; charset="UTF-8" On Wed, May 24, 2017 at 3:55 PM, Seth Blank wrote: > Looping back about this. > > Currently openarc only supports relaxed canonicalization for the ARC > Message Signature. > > On closer inspection, https://tools.ietf.org/html/dr > aft-ietf-dmarc-arc-protocol-03#section-5.1.2 and > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protoco > l-03#section-5.1.2.1.2 do *not* appear to be in direct contradiction of > each other. > > 5.1.2 states that AMS header canonicalization must be relaxed, and > 5.1.2.1.2 says that AMS body canonicalization must respect the c= value. > > Is this what was intended (AMS headers=relaxed, body=[c value]), and > should be included in the proposed draft? Or should the entire AMS (headers > and body) respect the c value and both specs be updated? > For that matter, why is "c=" required, and why are we constrained to "relaxed" for headers? -MSK --001a11430a721de80b0550d963b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 24, 2017 at 3:55 PM, Seth Blank <seth@valimai= l.com> wrote:
Looping back abou= t this.

Currently openarc only supports relaxed canonica= lization for the ARC Message Signature.


5.1.2 states that AMS = header canonicalization must be relaxed, and 5.1.2.1.2 says that AMS body c= anonicalization must respect the c=3D value.

Is th= is what was intended (AMS headers=3Drelaxed, body=3D[c value]), and should = be included in the proposed draft? Or should the entire AMS (headers and bo= dy) respect the c value and both specs be updated?
=

For that matter, why is "c=3D" re= quired, and why are we constrained to "relaxed" for headers?
<= br>
-MSK
--001a11430a721de80b0550d963b5-- From nobody Wed May 31 15:26: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 97E23126D45 for ; Wed, 31 May 2017 15:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 jqZ5ueh2XMNr for ; Wed, 31 May 2017 15:26:31 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 71396126D85 for ; Wed, 31 May 2017 15:26:31 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j17so17879328uag.3 for ; Wed, 31 May 2017 15:26:31 -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=BJF87zGKLy8hjB743aSFDooOrX6tkUFVY7w+pQmPI0M=; b=XZ4960/4Jr5CCid6cPyvREHRGH6NzPUcTLGZb4SfloiwcxyCdRZstM6aWCkIsvHy2G C6LyJBo5gr0ZbrsNoLypyXutndHCG3V76Mn47VFlG49Rg1QGN2PtLlcXc9IUojxplgfH N98tsCRoW3W+VZtTF+3sOq9A573QEdmZVrL+6U4dV634crYlPiTRRXSDLWtcuRpWbumO S/km8VZL+9mdgbSvdxS7Ylzw0fyKOevq+WLroYDQ0Kjv1iXltglh0qIbtiwQIudHIEzz 4N+3mxtd+R8+AaOagmvw5A+hEnNqch2S6PYniQMEQ/UwO4M3IjXi1NQu5IphiaqYoptH 5Ang== 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=BJF87zGKLy8hjB743aSFDooOrX6tkUFVY7w+pQmPI0M=; b=MZ7qwmwk74B00IdjyGHOn7EVXhdfUbI6mExXr3GXsqw2wXeXN3pA6tdbLGY+a1absI V/TzjcifZxrdAIUj7J6wgb71jEA7TclZzz8SVIElOcW8peWGv+X+44rTaLRZi7xO23rZ gNz7AGczrSh0oHJfKEUgJQ55a/1NDAi3yStQNjirV0nLt/BkEC3ygDSUdi1t/gBo2EOs FjzDg/xkrNoOw7iVEcR3GsEbsBaMNQVgi6Qg8zfrzB5o6lmKs7a4NXtv2ZOb0pA9tVWA TjmDdmwZI6pS0O3fvQsLFlVRiueb+alGYQ2qzT99hSAFgKse2MFv/rF3RKYMfa7yc+FW tZYg== X-Gm-Message-State: AODbwcDVLuH/oZOttHVfRDK9IjpyFZxTwtngOFb/d/9m0eqtO3Sp2TXZ pL4Ps1CT7z9dXWxJOApnrwxTg2mn9WZDRjg= X-Received: by 10.176.3.231 with SMTP id 94mr15085732uau.124.1496269590612; Wed, 31 May 2017 15:26:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:26:30 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:26:30 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0568026fd18d0550d96969" Archived-At: Subject: Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC) 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, 31 May 2017 22:26:33 -0000 --94eb2c0568026fd18d0550d96969 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 10:50 PM, Kurt Andersen (b) wrote: > (Reposting with adjusted subject) > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) > wrote: > >> Barry et al, >> >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: >> >>> The current spec defines an arc authres method ( >>> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1 >>> ). >>> >>> We believe there should also be registered ptypes and properties, that >>> should be stamped (but are not required, as they won't always be available). >>> >>> As long as AR stamping happens at the end of chain validation, when an >>> ARC set gets created this stamp will be included in the AAR, and AAR >>> construction can be clean with no additional language or requirements >>> necessary in the spec. >>> >> >> This area seems like something that would be productively explored in a >> F2F since it is pretty undefined right now and there are some divergent >> opinions kicking around... (see the thread with Brandon and Scott so far) >> > Section 9 of this draft should be a pretty good starting point: http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt Maybe I should submit to the datatracker this just to make it more easy to reference bits of it, even if we don't use it? -MSK --94eb2c0568026fd18d0550d96969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 10:50 PM, Kurt Andersen (b) <kboth= @drkurt.com> wrote:
(Reposting with adjusted subject)
On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen= (b) <kboth@drkurt.com> wrote:
Barry et= al,

On Wed, May 31, 2017 at 1:14 AM, Seth Blank <seth@valimail.com>= ; wrote:
The current spec defines an arc authres method (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protoc= ol-03#section-8.1).

We believe there= should also be registered ptypes and properties, that should be stamped (b= ut are not required, as they won't always be available).

As long as AR stamping happens at the end of chain val= idation, when an ARC set gets created this stamp will be included in the AA= R, and AAR construction can be clean with no additional language or require= ments necessary in the spec.

=
This area seems like something that would be pro= ductively explored in a F2F since it is pretty undefined right now and ther= e are some divergent opinions kicking around... (see the thread with Brando= n and Scott so far)
<= /blockquote>

Section 9 of this draft should be a pretty = good starting point:
http://blackops.org/~msk/draft-kucherawy-dmarc-arc-bas= e.txt

Maybe I should submit to the datatracker this j= ust to make it more easy to reference bits of it, even if we don't use = it?

-MSK
--94eb2c0568026fd18d0550d96969-- From nobody Wed May 31 15:28:25 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 30CCD12420B for ; Wed, 31 May 2017 15:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andreasschulze.de 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 q39PCWd9Oy0I for ; Wed, 31 May 2017 15:28:21 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49511124D37 for ; Wed, 31 May 2017 15:28:21 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1496269667; bh=fv23coqM9c1JG6XdY5XqLzheIlQrhLesEZSL8Ggte3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FtCHpa/mX8qzgm2rfTG5Y1pNaQ4+CgqOdCPxmnjPaGFTgy04xIzMgQYcs2WDR0LK+ yGT3jZBLK4hGWor3JkvwA+zELW3p3QSav8BLUm3JK2zuG8/XX8lpCOVYSpsWHPx8tO MzkTFyOkyPk4JVLx7PJQMisE4LZvlcPVE9Ac97dA4+QWA0j1NiLi+aIyhr0cgdh9hd O9CGvWW5PCzJ8D1BpPzYVn/+994rU3J16dSSgGKEiYSDz2FDVSUnPoUQ3C6ueq8pOM Z7HOIt4eb6O3L+qaKhtDJ0sYAe2zZtgbzUzpwNK+7FK9sUZhzWCW8UMQ6/hBYSFuYc WRg4rmb1jD1WQ== To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> From: "A. Schulze" Message-ID: <96c16823-54cf-e86c-a15a-c810209244d6@andreasschulze.de> Date: Thu, 1 Jun 2017 00:25:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 22:28:23 -0000 Am 01.06.2017 um 00:11 schrieb Murray S. Kucherawy: > I can give an update on the list. please :-) > Status reports aren't a good reason to hold a F2F meeting; meeting time is for discussion. yes, there whare long disscussion thread on this list, that make it (to me) hard to follow. But I understand and respect "meeting is not for status update" Andreas From nobody Wed May 31 15:40:39 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 28B0C1267BB for ; Wed, 31 May 2017 15:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 0OBOLtwYis-Q for ; Wed, 31 May 2017 15:40:36 -0700 (PDT) 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 014E7124D37 for ; Wed, 31 May 2017 15:40:35 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id u10so18061356uaf.1 for ; Wed, 31 May 2017 15:40:35 -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=0i1aQ/c2zzT2tgGH/mYrDL7mN8wzS0WkVuKjq9sO/j4=; b=sx7OEgCk4DUFG3m6jbwEOBDZ8x10lHVRArE/zJRQjOz017RMxw01mab4PATFGafw94 ydk7z2vZB2YZ80MaLNSApLKoC4j2K1Y+iIh9Cuvrh9mHHxK5m7fJZx26H99Az3wCcyJe ZIZaFbBthyJ4HqQz5k3sHGwWPvJcgbZaXckY7peYW+PwEQ4ikUw6D3HyP3Us9YTbsRjB TqWKERbAqKsmPWx9/jTyOOoMwMKm7wS4/zV+yYBTIIrKpB6yFG+TRBP6SZnBGCP4V5eR V1OxRnpmdcMEdMeA6IliVZ/PZbsmWFiq1sBCdGKDwR5Dp/h4wF3spDEAJY7DciufM67Q YCJA== 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=0i1aQ/c2zzT2tgGH/mYrDL7mN8wzS0WkVuKjq9sO/j4=; b=YMxmOOhzYOgfKvLVCE21dDeJ55saW30/rJy0RQhyWQl8B6PpTQsZufanee8RhzDfD9 icD3a/Xh0xcVeMmZlKJCCwXBzrW6tgVx3S/bdqDIrHsz5N9PonfLCOzkm1xRNFHQ4+q7 3MmS7Wm0cX3usuYmCRTJNAnHzuiRhM3IF6L6DqfE/C1PPbBT5QA3I65ilhlefPnc5qRR oywtNGXylW07rVAqG3240xHv00OtjCvl9/0Jel7b7dhgh9dACUDmmXqBMzTm1QgVdO2b KSBWck3XG+KLe81cMSRnuFRKhl4LPeHzoiIzQSyyUPs2ZBc6dNnrnTNRdEiVymhuKYFW 3F9w== X-Gm-Message-State: AODbwcAEU+QIJrDStH+LKZWk2FL48CqnOhOzY+Xk7bAF9u5i2NHdCKpL HNMKTyNV94OoC7e5XOhzsvkAdD1Iow== X-Received: by 10.176.81.4 with SMTP id e4mr5241086uaa.33.1496270435086; Wed, 31 May 2017 15:40:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:40:34 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:40:34 -0700 Message-ID: To: Brandon Long Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c191490c574b80550d99b51" Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 31 May 2017 22:40:38 -0000 --94eb2c191490c574b80550d99b51 Content-Type: text/plain; charset="UTF-8" On Tue, May 9, 2017 at 2:04 PM, Brandon Long wrote: > In 5.1 defining the AMS, you say that it should cover DKIM-Signature and > AuthRes headers. In particular, AuthRes headers are expected to be removed > by ADMDs, especially if the message transits the same ADMD multiple times. > Also, the information in the AuthRes header is superseded by the ArcAuthRes > header. Including it means an arbitrary AMS breakage for something pretty > minor, so I would recommend to not include it. > Section 5.1.2.1.1.... of the current draft says the same thing. I just copied it. > You also talk about "responsibility". I'm not sure that's how I would > describe it. An ARC hop is documenting that a message passed through it, > and that it evaluated the authentication of the message. The only > responsibility of a hop is to correctly validate the SPF/DKIM/ARC > information, there is no ownership implied over the message itself. > That's well-vetted language that's used to describe a valid DKIM signature and its relationship (or more specifically, the relationship of the signer) to the message content. Indeed, if you affix an ARC seal to a message, aren't you at least somewhat responsibility for its continued presence in the ecosystem? The language deliberately says "some responsibility" because we don't want to make any specific judgements about culpability, but the value of that metric is clearly not zero. > With AMS, you can answer the question: which ADMD is the last ADMD to have > modified the message. I guess in that sense, the last modifier is > "responsible" for the current state of the message... but that kind of > means that the AMS of previous hops allows them to disown responsibility > for the current state of the message... > Sure; in this sense ARC is different from DKIM in that you can make some statements about various parts of the chain, rather than just the bits whose signatures still validate. > 5.2 - should we point out that there should be only one of these per hop? > The openspf/dkim/dmarc implementations tend to add separate AuthRes headers > for each evaluation, but ARC requires those to be a single instance. > Yes, there should be text about collapsing multiple values if they're available when the seal is generated. I think this was discussed elsewhere. > 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my > understanding of those terms is slightly odd, but I would think that an MSA > usually uses an MTA to actually send the message, and it isn't that > "sending" MTA that's the first hop, it should be the first "receiving" > MTA. I mean, that's usually the point at which the DKIM signature is > applied, and the SPF would be "from" there, not based on the location of > the MUA. > I'm using the definitions from RFC5598. In many cases, a single component serves as both the MTA and MSA. But sure, clarifying text can't hurt. > There are some missing pieces here, corresponding to the current draft > sections 5.4 (alternate signing algorithms), > Sure, that could be added, though I think we should discuss why the time ranges stated there are appropriate. (This seems to me to be something that might already have been addressed elsewhere in some other document from the Security Area.) If not (or even if so), this is perhaps work best handled by DCRUP. > 6.4.3 (arc email authentication method for AuthRes) > There should be text connecting this to the IANA Considerations, sure. > 6.4.5 for dmarc xml. I see that the arc is included in your IANA section, > not sure if the call out outside of the definition is necessary or not. > What's the "call outside of the definition"? -MSK --94eb2c191490c574b80550d99b51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 9, 2017 at 2:04 PM, Brandon Long <blong@google= .com> wrote:
In 5.1 defining th= e AMS, you say that it should cover DKIM-Signature and AuthRes headers.=C2= =A0 In particular, AuthRes headers are expected to be removed by ADMDs, esp= ecially if the message transits the same ADMD multiple times.=C2=A0 Also, t= he information in the AuthRes header is superseded by the ArcAuthRes header= .=C2=A0 Including it means an arbitrary AMS breakage for something pretty m= inor, so I would recommend to not include it.
Section 5.1.2.1.1.... of the current draft says the same thing= .=C2=A0 I just copied it.
=C2=A0
You also talk about "responsibility".=C2=A0 I&#= 39;m not sure that's how I would describe it.=C2=A0 An ARC hop is docum= enting that a message passed through it, and that it evaluated the authenti= cation of the message.=C2=A0 The only responsibility of a hop is to correct= ly validate the SPF/DKIM/ARC information, there is no ownership implied ove= r the message itself.

That's well= -vetted language that's used to describe a valid DKIM signature and its= relationship (or more specifically, the relationship of the signer) to the= message content.=C2=A0 Indeed, if you affix an ARC seal to a message, aren= 't you at least somewhat responsibility for its continued presence in t= he ecosystem?=C2=A0 The language deliberately says "some responsibilit= y" because we don't want to make any specific judgements about cul= pability, but the value of that metric is clearly not zero.
=C2=A0
With AMS, you can = answer the question: which ADMD is the last ADMD to have modified the messa= ge.=C2=A0 I guess in that sense, the last modifier is "responsible&quo= t; for the current state of the message... but that kind of means that the = AMS of previous hops allows them to disown responsibility for the current s= tate of the message...

Sure; in= this sense ARC is different from DKIM in that you can make some statements= about various parts of the chain, rather than just the bits whose signatur= es still validate.
=C2=A0
5.2 - should we point out that there should be only one of = these per hop?=C2=A0 The openspf/dkim/dmarc implementations tend to add sep= arate AuthRes headers for each evaluation, but ARC requires those to be a s= ingle instance.

Yes, there shou= ld be text about collapsing multiple values if they're available when t= he seal is generated.=C2=A0 I think this was discussed elsewhere.
=C2=A0=
5.3.1 - none= as defined as "arrives at an MTA from an MSA", perhaps my unders= tanding of those terms is slightly odd, but I would think that an MSA usual= ly uses an MTA to actually send the message, and it isn't that "se= nding" MTA that's the first hop, it should be the first "rece= iving" MTA.=C2=A0 I mean, that's usually the point at which the DK= IM signature is applied, and the SPF would be "from" there, not b= ased on the location of the MUA.

I'm using the definitions from RFC5598.=C2=A0 In many cases, a single= component serves as both the MTA and MSA.=C2=A0 But sure, clarifying text = can't hurt.
=C2=A0
There are some missing pieces here, corresponding to the curr= ent draft sections 5.4 (alternate signing algorithms),

Sure, that could be added, though I think we sh= ould discuss why the time ranges stated there are appropriate.=C2=A0 (This = seems to me to be something that might already have been addressed elsewher= e in some other document from the Security Area.)=C2=A0 If not (or even if = so), this is perhaps work best handled by DCRUP.
=C2=A0
6.4.3 (arc email authenticati= on method for AuthRes)

There sh= ould be text connecting this to the IANA Considerations, sure.
=C2=A0
6.4.5 for dmarc= xml.=C2=A0 I see that the arc is included in your IANA section, not sure i= f the call out outside of the definition is necessary or not.

What's the "call outside of the definiti= on"?

-MSK
--94eb2c191490c574b80550d99b51-- From nobody Wed May 31 15:46:26 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 233EC12945C for ; Wed, 31 May 2017 15:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwHHGxJ9KJCZ for ; Wed, 31 May 2017 15:46:09 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311D41267BB for ; Wed, 31 May 2017 15:46:09 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id p85so16249655vkd.3 for ; Wed, 31 May 2017 15:46:09 -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=I1+MTJ58uiA8/J2odRqh97CBOzcTHWx/Jynm7eRb7hM=; b=M7ETNXWKxYRnhd8BdiIYpakR9HzmX2y7JKZ7hfohuS9gu8Go6o9/pSABENaqmbSHm5 AOJATddg9E99zXW0EVWsk0EdI1uDVUb1lfwoH6mPe4ty48+6FBIXwzPPZFICeHuqy0WM ZKG3GrU8hxtS+F4Lbr/dyaKFIzbhHTY2XfI43gwp6RLndhBXUR3FHzGmXy+l3Jymak9E jRAePZZ4OynuiVnJkq4qC7il68ZhEh5WttW0IVIt/cXxiHT2JS+btWW3yftYwXFV/icA YVD556Cn5UY6kivFjfXvE3fnA34MeGfYeftDPnWi7tDBdDrG2xGo6J+MZDLwUr65c7Ju MbKw== 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=I1+MTJ58uiA8/J2odRqh97CBOzcTHWx/Jynm7eRb7hM=; b=V3Qpj8m/pP6hP74Asb43UNe7sPapKlbs+6HX5e28OCti7+K+e7q8izhAinBZOK7ajx PtOj6cch1DYFHdb3FImI8BHMXDfPQfusJ+fIf2XgsDxDej35j09tNomerxlL7unvZY12 V6DdCWzoe1UeLVLc45pnquqHiK55/Nqm4CSCEfKY2+iTLh14ndoa2BMpCBuL4B7HXoYO XCQv0G714q5XTBYvCRHBGF2beniQBUCCiumV9AhRnEuvjoOhP/ZH/XzDVUU9ewHzXdnJ dOkBEJDGIG7yZccuxhwWbJq6Nd+vDkd84WmtyDRzq9HgpSKZ5ZFi8G8+YGINaKMfNb5t ddBg== X-Gm-Message-State: AODbwcDaOPnSMdWvQVLrqDPod0MvmE86D4B8qTa/o4c1nqeS3j/ywxXY 3kcLDv+mK1M/P6XvI//cHmeFp4XLsA== X-Received: by 10.31.78.133 with SMTP id c127mr12841395vkb.121.1496270768278; Wed, 31 May 2017 15:46:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:46:07 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:46:07 -0700 Message-ID: To: Gene Shuman Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11485262a1929e0550d9afc3" Archived-At: Subject: Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol 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, 31 May 2017 22:46:24 -0000 --001a11485262a1929e0550d9afc3 Content-Type: text/plain; charset="UTF-8" On Tue, May 9, 2017 at 3:56 PM, Gene Shuman wrote: > I've taken a look at the proposed draft and have a few notes as well. > > 4. The currently specified limits on i= are not included MUST >10, SHOULD > > 50, etc > 50 seems oddly high. I think sendmail out-of-the-box limits you to 20 Received fields, for example. > 5.1 - In the current draft, it's mandated that AMS must use relaxed header > canonicalization, but that's missing from the proposed draft > Deliberately. What's the purpose of that limit? > 5.2 - I'm a bit confused by the comment noting the importance of i=2. > What is it that you're intending there? > Ask Seth. :-) > 5.3.1 - typo: one of three possible values: -> one of *four* possible > values > Fixed in source. > 7.2 - It may be worth elaborating more on the possible ways in which > cv=invalid can arise, if not here, maybe somewhere else > Sure. > 7.4 - In general I prefer this to the psuedo code in the current draft, > but I think it could still use a bit of work. In particular, sections C-H > are exactly describing how to validate a DKIM signature and seems somewhat > unnecessary. Is there any particular reason you decided to include this, as > opposed to just relying on the DKIM spec for this? > Mainly because of the fact that there are considerations around the "cv" before and after that set of steps. I'm not partial to a list of steps part of which live in some other document. > 7.5 - typo: no -> all > Fixed in source. -MSK --001a11485262a1929e0550d9afc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 9, 2017 at 3:56 PM, Gene Shuman <gene@valimai= l.com> wrote:
I've taken a = look at the proposed draft and have a few notes as well.

4.=C2=A0 The currently specified limits on i=3D are not included MUST >= 10, SHOULD > 50, etc

50 seem= s oddly high.=C2=A0 I think sendmail out-of-the-box limits you to 20 Receiv= ed fields, for example.
=C2=A0
<= div dir=3D"ltr">
5.1 - In the current draft, it's mandated that AMS= must use relaxed header canonicalization, but that's missing from the = proposed draft

Deliberately= .=C2=A0 What's the purpose of that limit?
=C2=A0
5.2 - I'm a bit c= onfused by the comment noting the importance of i=3D2.=C2=A0 What is it tha= t you're intending there?

A= sk Seth.=C2=A0 :-)
=C2=A0
5.3.1 - typo: =C2=A0one of three possible values: -> one= of four possible values

Fixed in source.
=C2=A0
7.2 - It may be worth elaborating more on the possible ways = in which cv=3Dinvalid can arise, if not here, maybe somewhere else

Sure.
=C2=A0
7.4 - In general I prefer this to th= e psuedo code in the current draft, but I think it could still use a bit of= work.=C2=A0 In particular, sections C-H are exactly describing how to vali= date a DKIM signature and seems somewhat unnecessary. Is there any particul= ar reason you decided to include this, as opposed to just relying on the DK= IM spec for this?

Mainly becaus= e of the fact that there are considerations around the "cv" befor= e and after that set of steps.=C2=A0 I'm not partial to a list of steps= part of which live in some other document.
=C2=A0
7.5 - typo: no -> all

Fixed in source.

-MSK<= br>
--001a11485262a1929e0550d9afc3-- From nobody Wed May 31 15:54:55 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 4384F1270A3 for ; Wed, 31 May 2017 15:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 VOs4ymztAs8k for ; Wed, 31 May 2017 15:54:51 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 9C3FD124D37 for ; Wed, 31 May 2017 15:54:51 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id j17so18170565uag.3 for ; Wed, 31 May 2017 15:54:51 -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=qTHdGZIUq7/tt8DfUziguxReg4l3nh48HKaYCozoMtk=; b=gLp1TEpqc8qJUW+UtjJRcprCI19Eyolg9yNQ11USp+JSBktgDrS/y4jZ/5XIRFX4qM zjlAVSPy1qAuCS5rxtM1ZP5CUNrNvTPryDsUy6Al4nyJhJCQB8c5jpa/xRbal7+Zg5cB yiHh4fdB5QwohJHd8TbCVdKt6u/OhlO9BrrOPeaqQ9lssTx2bNISVKqd3LeX6v3qQAxE aZ91lSzDEBwGHlXDQYjQB8MSDCx0CAFkyFL7kw11qdya2XMnQfLaaefdWXo2DZ5H3kSk qUS9gHAECx2y15cgl8EVPrUaZwAz64XaJA5Q4V4CNUBXvPNvlDH2ORPWq7kQ53sPk9ZA Kp/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:cc; bh=qTHdGZIUq7/tt8DfUziguxReg4l3nh48HKaYCozoMtk=; b=nrjFUzf+ugTTytoeIZYSNv3E/CFCexf9vepnGVEKKho3IVs7CF4bJqbqiIKgTaS2im wxpOiFmPGvovwO2mpMseIY8RSpe87tfYLdjNSXC2rYLwAAumr7Oni5Ac8cLE3U1s+Zd7 fgz232kI03FeVHSf/li+KHeZ6MeytLDErHlYaoGQAHG6jqpNeejf+JzkaETV+gVDJ6aB ccV9nRmQ9QIXaBbwP8yVqwKQq+HEszPCoiJ91duHmvz6MXdM0rQo4soJkcZJlbZXuc8K vG4BdhNW2hzJoH+drOTPz1HIv85IWHq5vPu+JVXLFg9aIWve2PQHG6Yf/vpcEZXQm7xr MAWw== X-Gm-Message-State: AODbwcCKZjYvLSUdbVolPK/bfzIVQpp0byc76nXvoocfj41FNbjT1ICl BVVrF/+mzQ/QrMOr0zKMNFeKSN+nJDMA X-Received: by 10.176.94.133 with SMTP id y5mr15498366uag.150.1496271290681; Wed, 31 May 2017 15:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:54:50 -0700 (PDT) In-Reply-To: <96c16823-54cf-e86c-a15a-c810209244d6@andreasschulze.de> References: <238bac83-78c5-808e-f5c7-85ddedc09fe2@andreasschulze.de> <96c16823-54cf-e86c-a15a-c810209244d6@andreasschulze.de> From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:54:50 -0700 Message-ID: To: "A. Schulze" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c5684c4cf020550d9ceab" Archived-At: Subject: Re: [dmarc-ietf] Meeting in Prague (IETF 99) 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, 31 May 2017 22:54:53 -0000 --f403043c5684c4cf020550d9ceab Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 3:25 PM, A. Schulze wrote: > > I can give an update on the list. > please :-) OpenARC is effectively in an Alpha state, implementing the -03 draft. The code is available via github. It is correctly validating and generating seals and signatures and generating ARC-Authentication-Results. By the time of the M3AAWG meeting in Lisbon, it will be able to select signing vs. verifying mode (needed for milter installations) and will be compatible with ValiMail's testing environment. It may have indirect integration with OpenDMARC as well. There's some work to do in terms of documentation of the APIs and some README type stuff, the usual things you'd expect from a more mature open source project. There are a few bugs but they're more in corner cases and should be ironed out before Lisbon, certainly before Prague. It's modeled largely after OpenDKIM, so the structure and style should be familiar to those of you familiar with OpenDKIM. I expect to be doing formal releases before Prague. We have found a number of spec-related issues, some simple and some fundamental. I'm pretty sure all of them have been aired by now on the list, some resolved, some not. If there are any specific details you'd like to hear about, please feel free to ask. -MSK --f403043c5684c4cf020550d9ceab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 3:25 PM, A. Schulze <sca@andr= easschulze.de> wrote:
> I ca= n give an update on the list.
please :-)

OpenARC is effectively in= an Alpha state, implementing the -03 draft.=C2=A0 The code is available vi= a github.

It is correctly validating and generating seals and signat= ures and generating ARC-Authentication-Results.=C2=A0 By the time of the M3= AAWG meeting in Lisbon, it will be able to select signing vs. verifying mod= e (needed for milter installations) and will be compatible with ValiMail= 9;s testing environment.=C2=A0 It may have indirect integration with OpenDM= ARC as well.=C2=A0 There's some work to do in terms of documentation of= the APIs and some README type stuff, the usual things you'd expect fro= m a more mature open source project.=C2=A0 There are a few bugs but they= 9;re more in corner cases and should be ironed out before Lisbon, certainly= before Prague.

It's modeled largely after OpenDKIM, = so the structure and style should be familiar to those of you familiar with= OpenDKIM.=C2=A0 I expect to be doing formal releases before Prague.

We have found a number of spec-related issues, some = simple and some fundamental.=C2=A0 I'm pretty sure all of them have bee= n aired by now on the list, some resolved, some not.

If t= here are any specific details you'd like to hear about, please feel fre= e to ask.

-MSK
--f403043c5684c4cf020550d9ceab-- From nobody Wed May 31 15:56:59 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 7A7961270A3 for ; Wed, 31 May 2017 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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_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=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 bsYWWx_ir89P for ; Wed, 31 May 2017 15:56:56 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 7770B124D37 for ; Wed, 31 May 2017 15:56:56 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id x47so18247889uab.0 for ; Wed, 31 May 2017 15:56:56 -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=7WYN4qyRNR01UvTqKdwO0AsXv50hn0Ae1EsFnSPMNBc=; b=tLn9br0SaUTE6/0CALks6rUBEyj0dlbsezo/wbph9J/SYu9vPsOvActW5PDMQT2Mz2 TN1mwDT4PMU81ve+ZCml92ezhawmWOS6xc7kLONzy59u1+k45slhrx0A1tBnb/DSIMLd srMFDmNhcQu+SEOwVwU264fSXVFq1dtUJE9NbkZmqhWoMpAPVqhd/l4/lnryr5WZodpy haDpkyhk6dOEJAcHmwh9/2zTzRtfxef/bCY+V+akHVKW2Z2qzteQUY2FnzSNxZUPn2F9 ITiCPvoF8XOFlq86xap+4jsYHu4dPgZnPb/TDTODDvaqmjaHnF2Y1OmdJqe8IHU2XNvM glXQ== 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=7WYN4qyRNR01UvTqKdwO0AsXv50hn0Ae1EsFnSPMNBc=; b=MwdV4/hOxr6GEc5SftCJRjSpa+VVuYlcRjaJb0SJlaBmsEoT+WKr9okhCecGXmVMJu O9t0OxZ6oHIfaZeGcYH0SX2bPUMyfIiHofvPnK8P9Gyyvhy+3nM4dk+fOvXxabgrqiks /XfHxvV4jJXCnRSXXCTGk0/9In72U58jSWhd/KiRa3txahoFZJyRPghjPXSmxhCh9dTT htL4YXL+tx/ILJYNq1OVfqb+DHNAQKWZqHHcNbWbVgC1LOndi3LhahQXv3MOXNcOyrnq wvYa3NULMrjCTdhNoOZrrbisA2PCVygWYzoJxL4nEOLp+IVbfxlVwgNMS74Fvw9Gen8z DRdA== X-Gm-Message-State: AODbwcA0VXOHLzPA8csqJcnse4qGquh2rQZ15jvFlT3OONiIU18DTFdr +0J+7yE6L/p4c46juPP0SmPq9PNO/EJf X-Received: by 10.176.69.65 with SMTP id r59mr15253942uar.80.1496271415597; Wed, 31 May 2017 15:56:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 15:56:55 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 15:56:55 -0700 Message-ID: To: Seth Blank Cc: "dmarc@ietf.org" , Brandon Long , Kurt Andersen Content-Type: multipart/alternative; boundary="94eb2c0b989836f7c50550d9d680" Archived-At: Subject: Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature 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, 31 May 2017 22:56:58 -0000 --94eb2c0b989836f7c50550d9d680 Content-Type: text/plain; charset="UTF-8" SHOULD be the same? I can't think of a good thing to say here, or a solid justification for any choice. I can't imagine why they would ever differ, but I can't come up with a solid technical reason to demand it either. As a verifier I might be skeptical if they're wildly different names, but that's hard to write in a standards document. -MSK On Wed, May 24, 2017 at 11:35 AM, Seth Blank wrote: > Does the group have any further thoughts here? > > I'm happy to suggest language for Gene's suggestion if there are no > further comments. > > On Tue, May 9, 2017 at 4:02 PM, Gene Shuman wrote: > >> I definitely can't imagine any sensible case in which the d= tags should >> be different. I do think the tag should still be specified in both the AS >> & AMS though. While not strictly necessary technically, it does make the >> language in the spec & implementation details a bit cleaner. So I would >> suggest simply adding a line/section in the chain validation section of the >> draft or somewhere else that says cv=fail(or invalid?) if the d= tags >> aren't identical. I think this is an entirely reasonable restriction. >> >> =Gene >> >> On Thu, May 4, 2017 at 3:44 PM, Brandon Long wrote: >> >>> When thinking about how to extract information from an arc chain, I was >>> wondering at the "owner" of a section of the chain. >>> >>> Theoretically, that's the ADMD. A single hop, however, has three >>> separate domain ownerships, the srv_id from the AAR, and the d= field from >>> the AS and AMS. >>> >>> Our current implementation uses google.com for the d= field, and we >>> have three different srv_id's for different pools that serve different >>> purposes. That said, the srv_id has no "validation" except for by the key >>> signature, so d= seems like a stronger "owner". >>> >>> Except, the AMS and AS can have separate selectors and domains. I'm not >>> sure if that's useful or desirable. I'm tempted to only consider a chain >>> valid if the domains are the same, and I guess not care if the selectors >>> are. >>> >>> Should we require them to be the same? If we do, should they only be >>> specified once? >>> >>> For changing algorithms, I guess s would be different, along with a, >>> though I would think you would need a separate set of headers for the hop >>> for each a in transition... >>> >>> So: >>> Should we require d= to be the same? Should we specify it only once? >>> If not, why not? >>> >>> Brandon >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >>> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > > -- > > [image: logo for sig file.png] > > Bringing Trust to Email > > Seth Blank | Head of Product for Open Source and Protocols > seth@valimail.com > +1-415-894-2724 <415-894-2724> > --94eb2c0b989836f7c50550d9d680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SHOULD be the same?

I can'= t think of a good thing to say here, or a solid justification for any choic= e.=C2=A0 I can't imagine why they would ever differ, but I can't co= me up with a solid technical reason to demand it either.

As a = verifier I might be skeptical if they're wildly different names, but th= at's hard to write in a standards document.

-MSK


On Wed, May 2= 4, 2017 at 11:35 AM, Seth Blank <seth@valimail.com> wrote:
Does the group have any f= urther thoughts here?

I'm happy to suggest language = for Gene's suggestion if there are no further comments.

On T= ue, May 9, 2017 at 4:02 PM, Gene Shuman <gene@valimail.com> = wrote:
I definitely can&= #39;t imagine any sensible case in which the d=3D tags should be different.= =C2=A0 I do think the tag should still be specified in both the AS & AM= S though.=C2=A0 While not strictly necessary technically, it does make the = language in the spec & implementation details a bit cleaner.=C2=A0 So I= would suggest simply adding a line/section in the chain validation section= of the draft or somewhere else that says cv=3Dfail(or invalid?) if the d= =3D tags aren't identical.=C2=A0 I think this is an entirely reasonable= restriction. =C2=A0

=3DGene

On Thu, May 4, 2017 at 3:44 PM, Brandon Lo= ng <blong@google.com> wrote:
When thinking about how to extract information from a= n arc chain, I was wondering at the "owner" of a section of the c= hain.

Theoretically, that's the ADMD.=C2=A0 A single= hop, however, has three separate domain ownerships, the srv_id from the AA= R, and the d=3D field from the AS and AMS.

Our cur= rent implementation uses go= ogle.com for the d=3D field, and we have three different srv_id's f= or different pools that serve different purposes.=C2=A0 That said, the srv_= id has no "validation" except for by the key signature, so d=3D s= eems like a stronger "owner".

Except, th= e AMS and AS can have separate selectors and domains.=C2=A0 I'm not sur= e if that's useful or desirable.=C2=A0 I'm tempted to only consider= a chain valid if the domains are the same, and I guess not care if the sel= ectors are.

Should we require them to be the same?= =C2=A0 If we do, should they only be specified once?

For changing algorithms, I guess s would be different, along with a, tho= ugh I would think you would need a separate set of headers for the hop for = each a in transition...

So:
Should we re= quire d=3D to be the same?=C2=A0 Should we specify it only once?=C2=A0 If n= ot, why not?

B= randon

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



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




--

3D"logo

= Bringing Trus= t to Email

Seth Blank | Head of Product <= font face=3D"arial, helvetica, sans-serif" color=3D"#838980">for Open Source and Protocols<= /font>

seth@valimail.com
+1-415-894-2724

--94eb2c0b989836f7c50550d9d680-- From nobody Wed May 31 16:01:30 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 679E2128B8E for ; Wed, 31 May 2017 16:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 nFBkqQ__rfcS for ; Wed, 31 May 2017 16:01:27 -0700 (PDT) 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 CD32E129459 for ; Wed, 31 May 2017 16:01:26 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id u10so18271666uaf.1 for ; Wed, 31 May 2017 16:01:26 -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=JrjJon4FpEyKNojgQmphqpGpkBU9jEnu0T1U8gd1n8Y=; b=UvVw1aDs5LZ5R1u99a6aP/0nTLS0A6IsdWg4wOIaQ6Dv7ZY4Ewf+Q+ePcqeckfJNxL WB4R7LoH4JiTsmTOb+EAGjBGgVOHgowM7Yfv6NR3JUiTmJcVeBfWTkBnRDgVUdQ2NUs8 1N+sCdTI5WXf8okLc48nMmCqIBXSXmUi4mx0r5SneSuOGPJB+lTGBRKnMQvaXF/JTwoB veiSdkX+t8fTIpx0JPdYongJ0WNwjjmBzYuyDVA4hntJEp4FXBWfrLmS0Oi+z95W2NYr MylN0SYKW2Y0b/Pg07NWXCGvsthVPgZdLFe9rz+PoLM7LcU+UoZg2N/TjMhoSg8/OOMI B9yA== 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=JrjJon4FpEyKNojgQmphqpGpkBU9jEnu0T1U8gd1n8Y=; b=kfrKLKBxvmQvfMWI2HF+HoAbn70/B+5MxWAG+jNTbtYwtf4hx6g1tqZ2dMWayXNi8z JV1gh5H4grG20TqNnwBLRhkJXu7dP+oC3CYelr8PfdPPgksz1Wsz1Gvm5yECjwAgxtXn V/+Z+4x5Kx16WyAfRhquLJgrHJ+O8Mx1YDxB1m6wNdj6K/91Z9WdgCGKTmboTempn77k X/9hCqIB1/d1fTLFXHzudl5pM5/oVrX0vnx4CGZoTMJpogRKcIW0i4gkeiSvVrJ8CR48 XwLxgQhgqavZdX+OfA4lp/sqm63SFdeeZ/FsToBCDOFhNFLXDFD+jSnMcFnoKa4GVx+S dCuw== X-Gm-Message-State: AODbwcBdAFbmYYXrlmur5GDAJG4dxZt/Dro/SFmR+FM7naL7cvsXNmdU 5AFEhK1+D/j0kOwhuUxjUAEhDThAr1KW X-Received: by 10.176.69.65 with SMTP id r59mr15265047uar.80.1496271685942; Wed, 31 May 2017 16:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 16:01:25 -0700 (PDT) In-Reply-To: <3073712.x93XL1H1LP@kitterma-e6430> References: <4BC08AA6-02AE-4186-B0DB-ED773A35809C@kitterman.com> <3073712.x93XL1H1LP@kitterma-e6430> From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 16:01:25 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b98985402a00550d9e6e6" Archived-At: Subject: Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present? 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, 31 May 2017 23:01:28 -0000 --94eb2c0b98985402a00550d9e6e6 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 10:33 AM, Scott Kitterman wrote: > > At some point in the process, an AAR and ARC signature get created. Later, > someone else has to validate them. > > My point was that when you are on the signing end of this, you have to > grovel > through all the relevant AR header fields since there's nothing telling > another doing new authentication the should combine them into the same > field. > Seeing sequence of AR fields for SPF, DKIM, and DMARC is quite normal. > > I thought that what was being said was that the AAR contstruction process > could assume a single AR field and that's not correct. Now that I see it > explained again, I see I was thinking one step too far back in the process. > > So, I think it was my misunderstanding, although if you're doing to use the > results of the AAR in the verification process and assume it's all in a > single > AAR header field, then I think that should be a MUST, not a SHOULD. > I'm leaning toward MUST using Seth's language. It seems to me SHOULD leaves an interoperability hole, plus you'd have to come up with some sityations where not doing so makes sense that are stronger than "I didn't want to." -MSK --94eb2c0b98985402a00550d9e6e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 10:33 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:

At some point in the process, an AAR and ARC signature get created. Later,<= br> someone else has to validate them.

My point was that when you are on the signing end of this, you have to grov= el
through all the relevant AR header fields since there's nothing telling=
another doing new authentication the should combine them into the same fiel= d.
Seeing sequence of AR fields for SPF, DKIM, and DMARC is quite normal.

I thought that what was being said was that the AAR contstruction process could assume a single AR field and that's not correct.=C2=A0 Now that I= see it
explained again, I see I was thinking one step too far back in the process.=

So, I think it was my misunderstanding, although if you're doing to use= the
results of the AAR in the verification process and assume it's all in a= single
AAR header field, then I think that should be a MUST, not a SHOULD.

I'm leaning toward MUST using Seth's l= anguage.=C2=A0 It seems to me SHOULD leaves an interoperability hole, plus = you'd have to come up with some sityations where not doing so makes sen= se that are stronger than "I didn't want to."

-MSK
--94eb2c0b98985402a00550d9e6e6-- From nobody Wed May 31 16:42:48 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 B3FFF129478 for ; Wed, 31 May 2017 16:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 QPxCHk9zN7SS for ; Wed, 31 May 2017 16:42:44 -0700 (PDT) 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 04D99129476 for ; Wed, 31 May 2017 16:42:42 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id y201so24646593qka.0 for ; Wed, 31 May 2017 16:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2iLMRBtT2TQ6+ZlzxuSDj/gF6EmLLE7AaiTRmYOKYvs=; b=JCC2Ssl5xWZbA/ZODj6fXQMljhdaGFPy0RkqTykUcgiNmJe/+RVg6q5LAkodkVvM3Z FxXuwRFBeVDUQesSn60k7UR8VIC5o+SrPwrsGfhOcxva6dxtr+cz2lH9LIfUWg16e53p 4+iNLL3SunMBXNuUQ2jjsW6swWHjMPr6Ddl3h9VTGczsGmqZ0uO2OotNmbU2214VdYc3 YW7wV1IRgjagLivz27Igv9Uovgtl9333ajL0jytNTHDcn3Qy0LEE79/aB5wBXNQQCUwk EwYguXgpL/m4APCcDfFnpieJPcMg1cMyJkU4N3HeWdW4xv3tKV5zH1Q+DzAJ6pzniNSm zo/g== 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=2iLMRBtT2TQ6+ZlzxuSDj/gF6EmLLE7AaiTRmYOKYvs=; b=EfiT1MVZ5Qh2s7dU6xgIzF4e8viADia8uj7VlaNvNwCI7vBQ919JPrK87iiGGfaQas sV5Pp5rJPl8C0oeSfixPU4v5qa+WhYC5bWXPcRLdJrne62pMlTi4QsEulytj37LjpvDO XHxa+K/9JvyqKoQhR+FCWmNg236HC1DkznjVFzkQiekAK43WzWtOr1essKoFoMCcQLnx Km7N44AVHGioF22F6mKr173/iFc4uZg8Mn4icU1pXobqHPxG3OvlVDvRb04Wn/ABalff gA5wKS/s958hDIlAuojSkX1tEie9F9cR+J0zFyzibSWSTwF+a4TCMh4NrHQsB8Loy3Xz VkUA== X-Gm-Message-State: AODbwcDzzBuUUM8jKh7t9fUlk3VrxHq01fxx3PaHlD2bUef5lo3UmG82 WSBq3dZVhr/rd4zXMpY2+aZ5K+wqdJb6 X-Received: by 10.55.4.135 with SMTP id 129mr4902054qke.10.1496274161189; Wed, 31 May 2017 16:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 31 May 2017 16:42:20 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Wed, 31 May 2017 16:42:20 -0700 Message-ID: To: Barry Leiba Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a114c6e9edd57250550da799b" Archived-At: Subject: Re: [dmarc-ietf] For fodder for F2F at IETF99 (was: Authentication-Results stamp for ARC) 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, 31 May 2017 23:42:47 -0000 --001a114c6e9edd57250550da799b Content-Type: text/plain; charset="UTF-8" AR might be 10-15 minutes. What to do to transport the source_ip, which is valuable to report consumers but doesn't appear to belong in the AR/AAR, could be a contentious and therefore longer discussion. On Wed, May 31, 2017 at 5:42 AM, Barry Leiba wrote: > How long do we think we need for this discussion? > > b > > On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) > wrote: > > (Reposting with adjusted subject) > > > > On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) > wrote: > >> > >> Barry et al, > >> > >> On Wed, May 31, 2017 at 1:14 AM, Seth Blank wrote: > >>> > >>> The current spec defines an arc authres method > >>> (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol- > 03#section-8.1). > >>> > >>> We believe there should also be registered ptypes and properties, that > >>> should be stamped (but are not required, as they won't always be > available). > >>> > >>> As long as AR stamping happens at the end of chain validation, when an > >>> ARC set gets created this stamp will be included in the AAR, and AAR > >>> construction can be clean with no additional language or requirements > >>> necessary in the spec. > >> > >> > >> This area seems like something that would be productively explored in a > >> F2F since it is pretty undefined right now and there are some divergent > >> opinions kicking around... (see the thread with Brandon and Scott so > far) > >> > >> --Kurt > > > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a114c6e9edd57250550da799b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
AR might be 10-15 minutes.

What to do t= o transport the source_ip, which is valuable to report consumers but doesn&= #39;t appear to belong in the AR/AAR, could be a contentious and therefore = longer discussion.

On Wed, May 31, 2017 at 5:42 AM, Barry Leiba <barryleib= a@computer.org> wrote:
How = long do we think we need for this discussion?

b

On Wed, May 31, 2017 at 2:50 PM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
> (Reposting with adjusted subject)
>
> On Wed, May 31, 2017 at 9:46 AM, Kurt Andersen (b) <kboth@drkurt.com> wrote:
>>
>> Barry et al,
>>
>> On Wed, May 31, 2017 at 1:14 AM, Seth Blank <seth@valimail.com> wrote:
>>>
>>> The current spec defines an arc authres method
>>> (https://tools.= ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1).<= br> >>>
>>> We believe there should also be registered ptypes and properti= es, that
>>> should be stamped (but are not required, as they won't alw= ays be available).
>>>
>>> As long as AR stamping happens at the end of chain validation,= when an
>>> ARC set gets created this stamp will be included in the AAR, a= nd AAR
>>> construction can be clean with no additional language or requi= rements
>>> necessary in the spec.
>>
>>
>> This area seems like something that would be productively explored= in a
>> F2F since it is pretty undefined right now and there are some dive= rgent
>> opinions kicking around... (see the thread with Brandon and Scott = so far)
>>
>> --Kurt
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc=
>

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



--

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a114c6e9edd57250550da799b-- From nobody Wed May 31 18:23:09 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 AC8BD129ABE for ; Wed, 31 May 2017 18:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFm-8SYb0RBg for ; Wed, 31 May 2017 18:23:06 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 1A8381294A2 for ; Wed, 31 May 2017 18:23:06 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id y4so19496681uay.2 for ; Wed, 31 May 2017 18:23:06 -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=49x2ddBAwuXdZJuJWLeAuWSOVUZ4ekQ93KB/VrDu0mA=; b=emnYKZmg05V56tRGG/nSC6hpME1ffsb63mvqIatUqgjtYgIzUWrc7/7kTLLzkromF5 runBrXuL27+tVTtc9XyUQB58cWOj5ISuA8fumSGkE/8FECRzDG3xbM6hb41hNWBCxY4J 3DQImoJn/QW6C+GCcdoUu0eSf+0J8ZMTbrLFc= 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=49x2ddBAwuXdZJuJWLeAuWSOVUZ4ekQ93KB/VrDu0mA=; b=X0cVZ5KfhvOIRkHx4hASNL2HoVsUdS9UanNAhfQ16AkuECzP/DBAj0fBpzHMX89fNw 3Hczg3zfa9pqIoYQr6Kp4V7I6nTb2iepTfvVALd6SIUiAE/YkIxucRdd47rYaifC7HMr stzfTOSN1zygUVww6yg6e3iuDvhPPEig59A6pAD4+HttHF/zgn3EKrX1neVRNWbMZ1o6 l78B+akhSjB5zzIANctISiuBFz2+dAS5Qni+krXKNqQVB8eSdDZLaGpcTKjJxOhyo2ch 5dJSa8gJ8ZX7OsdSAzlQF+CLqyJippp3h65/gZuN+WEmU1+M0zgd0y3792Wx+JZlvDxx Q5SQ== X-Gm-Message-State: AODbwcBtIhr/WA/KK2FD1GA27eWGO8rmBufxOgFkJLTq/MSBn9B4jhTw fulX0Ij/BVizS78i5tr0CpUtgOwPCSru X-Received: by 10.176.8.65 with SMTP id b1mr15574242uaf.82.1496280185199; Wed, 31 May 2017 18:23:05 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Wed, 31 May 2017 18:23:04 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 1 Jun 2017 09:23:04 +0800 X-Google-Sender-Auth: hRldpLN3lMi8Fz_Rx6KQ9Ecds1Q Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403045f89caec823e0550dbe02f" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 01 Jun 2017 01:23:08 -0000 --f403045f89caec823e0550dbe02f Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 4:42 AM, Murray S. Kucherawy wrote: > On Wed, May 31, 2017 at 1:35 PM, Murray S. Kucherawy > wrote: > >> >> What's the added value in covering AAR[n] twice, once with its b= and >> once without? >> >> > What benefit is there to covering AAR with both the AMS and the AS? It > seems to me the AMS is much cleaner (in the sense of ARC being a layer atop > DKIM) if it is purely a renamed DKIM signature with an instance number. > > Put another way, the apparent intent here is to require that things be > generated in a specific order (AAR, then AMS, then AS) but it seems to me > there's no obvious benefit to imposing that constraint given that AS is > supposed to cover everything anyway. > > -MSK > I need to go back to the notes as we were evolving the chain to see if we discussed this particular piece and the logic for the sequencing. Regarding: Thu, Jun 1, 2017 at 6:08 AM, Brandon Long wrote: > > . . .I can also see how this could be extended to think about the oddness > that having two signatures and whether the keys need to match between > AS/AMS. > There's another question that had been raised by Seth about whether d= needs to match within an ARC set. The answer is yes, but we very explicitly did not want to constrain ARC-writers to have to use the same keys (either as their DKIM usage or within the ARC set) so the selectors may differ. I'll be updating the language in the spec as I travel back to the US this weekend and have a new draft early next week. --Kurt --f403045f89caec823e0550dbe02f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 4:42 AM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Wed, May 31, 2017 at 1:35 PM, Murra= y S. Kucherawy <superuser@gmail.com> wrote:

What's the added va= lue in covering AAR[n] twice, once with its b=3D and once without?


What = benefit is there to covering AAR with both the AMS and the AS?=C2=A0 It see= ms to me the AMS is much cleaner (in the sense of ARC being a layer atop DK= IM) if it is purely a renamed DKIM signature with an instance number.

Put another way, the apparent intent here is to require that t= hings be generated in a specific order (AAR, then AMS, then AS) but it seem= s to me there's no obvious benefit to imposing that constraint given th= at AS is supposed to cover everything anyway.<= font color=3D"#888888">

-MSK
=

I need to go back t= o the notes as we were evolving the chain to see if we discussed this parti= cular piece and the logic for the sequencing.

Regarding: Thu, Jun 1, 2017 at 6:08 AM, B= randon Long=C2=A0<blong@google.com>=C2=A0wrote:

<= /span>
. . .I can also see how this could be extended to think about th= e oddness that having two signatures and whether the keys need to match bet= ween AS/AMS.

There&= #39;s another question that had been raised by Seth about whether d=3D need= s to match within an ARC set. The answer is yes, but we very explicitly did= not want to constrain ARC-writers to have to use the same keys (either as = their DKIM usage or within the ARC set) so the selectors may differ. I'= ll be updating the language in the spec as I travel back to the US this wee= kend and have a new draft early next week.

--Kurt= =C2=A0
--f403045f89caec823e0550dbe02f-- From nobody Wed May 31 18:40:45 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 7EAB91270A3 for ; Wed, 31 May 2017 18:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHUdnwN2ONxT for ; Wed, 31 May 2017 18:40:41 -0700 (PDT) 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 F315A129ADD for ; Wed, 31 May 2017 18:40:40 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id y4so19646077uay.2 for ; Wed, 31 May 2017 18:40:40 -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=r9LKOkrSRHsNv2nBLZ1eP9HsRO27w8/QBMk89cn1sOA=; b=KHNWe+kA6vEID1tmsSEER7wwfAkXmFVkI7qgO6ZINN4urewAtVb0BaMudgz+EoZVrT OTFJUJBumwvfbgxtvn3t7+vDzrr9iA+2kDnvHe/AbUmPT7DNJZh3NprD9qzI2CS9pfMQ yUXnD4Bb5q0Y9C6UsHJFUiucxhtdaNJYD5SfU= 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=r9LKOkrSRHsNv2nBLZ1eP9HsRO27w8/QBMk89cn1sOA=; b=bJcmjETsbkacydycFXEhg2Aw87zhv3suiHM1Lj0oRoeUzu8ogSoPq8oBuBb66xS6rc v6BlN5DiDeMbZ1iHHG0oeb6WT3zM0gbXLDGrBJ/Sv1IIDnKpvpUKxPGYI6dafO6WQM8N aNHcxztINk6aQ7lzP//FjdLYRYmLw4Fr5rAbjg4WFgpnVBPxBWzu4lkRjpqVEoktskSQ FXKxm4bnBkoRFfofmPFU8MODt8Mrual8QgwK1k35XtP6yi5rDzwhrecI9X1eRkebFDEB qcF60J6lell9gLBb2b6aLHHzRtZAgVeXvmE3RXmrfQYWom77I73+S+yMkC8FDjZW88/D dCEQ== X-Gm-Message-State: AODbwcC5BZnvE8xw8mHqBI45YoqHTjC2xJwSiD0vg1drxEwUQd/WuAdb 6Rqz3J/GkNm9+gbO4ptJBl7kX1LIuzTp X-Received: by 10.159.52.84 with SMTP id s20mr12751926uab.8.1496281240038; Wed, 31 May 2017 18:40:40 -0700 (PDT) MIME-Version: 1.0 Sender: kurta@drkurt.com Received: by 10.176.83.111 with HTTP; Wed, 31 May 2017 18:40:39 -0700 (PDT) In-Reply-To: References: From: "Kurt Andersen (b)" Date: Thu, 1 Jun 2017 09:40:39 +0800 X-Google-Sender-Auth: NDl60it2ziE1mBZHsDOrDoWXIwk Message-ID: To: "Murray S. Kucherawy" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043ec0cccc0b3d0550dc1fb5" Archived-At: Subject: Re: [dmarc-ietf] cv=invalid 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, 01 Jun 2017 01:40:42 -0000 --f403043ec0cccc0b3d0550dc1fb5 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 5:32 AM, Murray S. Kucherawy wrote: > > If a verifier decides an ARC is invalid, it's supposed to set > "cv=invalid", when generating its own ARC-Seal. This seems odd; we're > cryptographically signing a chain that is known to be broken, meaning the > next handler might not even be able to get as far as consuming the "cv=" > value we're putting there because the chain can't be validated in the first > place. > Since looking at the ARC-Seal is the very first step in evaluating the chain, I'm not sure why a handler would have a problem unless the ARC-Seal is subsequently mangled beyond recognition (a situation which is covered elsewhere). Signing the chain documents its state at the time of processing and the AAR that is covered by the AS tells the next recipient where that broken chain came from. --Kurt --f403043ec0cccc0b3d0550dc1fb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 5:32 AM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
=

If a verifier decides an ARC is invalid, it's = supposed to set "cv=3Dinvalid", when generating its own ARC-Seal.= =C2=A0 This seems odd; we're cryptographically signing a chain that is = known to be broken, meaning the next handler might not even be able to get = as far as consuming the "cv=3D" value we're putting there bec= ause the chain can't be validated in the first place.

Since looking at the ARC-Seal is= the very first step in evaluating the chain, I'm not sure why a handle= r would have a problem unless the ARC-Seal is subsequently mangled beyond r= ecognition (a situation which is covered elsewhere). Signing the chain docu= ments its state at the time of processing and the AAR that is covered by th= e AS tells the next recipient where that broken chain came from.
=
--Kurt=C2=A0
--f403043ec0cccc0b3d0550dc1fb5-- From nobody Wed May 31 21:09:42 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 1E0B7127775 for ; Wed, 31 May 2017 21:09:41 -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 BzyF2QvGirMv for ; Wed, 31 May 2017 21:09:39 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 8578D1267BB for ; Wed, 31 May 2017 21:09:39 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id p85so18676690vkd.3 for ; Wed, 31 May 2017 21:09:39 -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=oXkFCx2VTsK6twO6iAag6lg4tyhj/7K9Wv3+ivn/3vQ=; b=iqj4UxpWBfEVXocIePHVju515fmS9NGzo/jwJ7mj6mz/IEWf4avaQ/5jQyg04/QJqj A2BzEwfeVU/UEtfj+9ZRciDwAyy4VmujrWdrz5ETVHaw4DpUBshIJy3z4xQm3WswYPKM Y/dTU1VYVPLy0ZuJs0gffLpYzzDl6oLmuzJY5XDMksQyq7f2YeaAqBEQvR7GmBRkY44J 8S55dLwG6w6DPMZuH1NDZsHBxfhmEHzSnDN3ZzSI6i/nnaxlMXyjPn8rllCGNrSQfMT+ c+4aFGNgnQbiQJd7TWXENQmj+osPMF+Gt17yoHqasD6/rqu3rrJnUUD9du1/x0TeRwh3 aJxA== 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=oXkFCx2VTsK6twO6iAag6lg4tyhj/7K9Wv3+ivn/3vQ=; b=mnWCYrr8lRzTgHHfGjXBDoZRVv9nwG2v94WkKYSd80JFhlgI0hK76oBcZ2lkpjdbYS WpnEn5lx8tUyo/vMgr1R9AuReggxnDW+bes+28cP+WGB4q1QZfruJLOdfW5tQ56k7XFC JzGO5qpR5Pf6vWmI1Og2Zh7dpiB2SChlV3eEyXan0jyn0sHqks1blR7oKf+b7NVsf6aj j/9P3xU3zFv3twBPubdHi4IeUMl5W3X2Q0EBhTftuP4NKkqCn7jdMzMUIuvPjd73+aa3 5Oc+lKoDDrpNeyiVyCjjP3b31tPMDBNdW+1Y5f6tdzVKgjkJogUVMWb1Ni6YHsb2iAs8 CsSA== X-Gm-Message-State: AODbwcD0HuAzZcdldzlVSTrUI+XJTmCTjjvaXjNd/lXWPXoBRL0MP7SJ B9oncqm0ta7VZ9xnDvp8nxN+0S8EsQ9D X-Received: by 10.31.55.9 with SMTP id e9mr11549230vka.127.1496290178644; Wed, 31 May 2017 21:09:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 21:09:38 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 21:09:38 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1144159c9440090550de3431" Archived-At: Subject: Re: [dmarc-ietf] cv=invalid 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, 01 Jun 2017 04:09:41 -0000 --001a1144159c9440090550de3431 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 6:40 PM, Kurt Andersen (b) wrote: > If a verifier decides an ARC is invalid, it's supposed to set >> "cv=invalid", when generating its own ARC-Seal. This seems odd; we're >> cryptographically signing a chain that is known to be broken, meaning the >> next handler might not even be able to get as far as consuming the "cv=" >> value we're putting there because the chain can't be validated in the first >> place. >> > > Since looking at the ARC-Seal is the very first step in evaluating the > chain, I'm not sure why a handler would have a problem unless the ARC-Seal > is subsequently mangled beyond recognition (a situation which is covered > elsewhere). Signing the chain documents its state at the time of processing > and the AAR that is covered by the AS tells the next recipient where that > broken chain came from. > So if on doing that very first step and evaluating the chain, I determine that it's mangled and unparseable, I'm now supposed to add my own seal including "cv=invalid" and somehow canonicalize the mangled thing that's there already. I don't think I understand how that's possible; the canonicalized form that is hashed and encrypted to become the AS signature has to include something deterministic. -MSK --001a1144159c9440090550de3431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 6:40 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
If a verifier decides an A= RC is invalid, it's supposed to set "cv=3Dinvalid", when gene= rating its own ARC-Seal.=C2=A0 This seems odd; we're cryptographically = signing a chain that is known to be broken, meaning the next handler might = not even be able to get as far as consuming the "cv=3D" value we&= #39;re putting there because the chain can't be validated in the first = place.

S= ince looking at the ARC-Seal is the very first step in evaluating the chain= , I'm not sure why a handler would have a problem unless the ARC-Seal i= s subsequently mangled beyond recognition (a situation which is covered els= ewhere). Signing the chain documents its state at the time of processing an= d the AAR that is covered by the AS tells the next recipient where that bro= ken chain came from.

So = if on doing that very first step and evaluating the chain, I determine that= it's mangled and unparseable, I'm now supposed to add my own seal = including "cv=3Dinvalid" and somehow canonicalize the mangled thi= ng that's there already.=C2=A0 I don't think I understand how that&= #39;s possible; the canonicalized form that is hashed and encrypted to beco= me the AS signature has to include something deterministic.

-MSK
--001a1144159c9440090550de3431-- From nobody Wed May 31 21:10:48 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 5CFD3127775 for ; Wed, 31 May 2017 21:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=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 Nhx0Ov1MYwvA for ; Wed, 31 May 2017 21:10:45 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 E80721267BB for ; Wed, 31 May 2017 21:10:44 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id y4so20861482uay.2 for ; Wed, 31 May 2017 21:10:44 -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=/OHUNets3l31KP+jbcFbVBafpxEdjl8sT6ujp1w19so=; b=f2uehtztqR+7TWCjAVSYQYPkEPENWRzxUhGawqfJilQ/iqdilrAbLyuhsEi1/Av3EH s5EbcbpWdTN5Ns/m/qJamVfwqMh6OzbN8yyQHrjTUAgy+fI1e9MVzdzR8bw9xrhwazik Xv6+BgjOezhQuBemCYclUmIBOa/8VcZCOFxY0YhYmpZdbJOXY4T1TIMVFd1fcpfRRoOs i42GdU9IFe6W2ngrb8X0/OoXaBd2kwHwZu5FZCcZV8Jn+Fu0z8djN0vO7diSDl2x+M1w NlCk/0JDx+FTyVeqIH1Tc/QcWIFhArHt4Yihbf60B7CAgqIhok9Qtc/EORL+mS0owPWv o1Rg== 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=/OHUNets3l31KP+jbcFbVBafpxEdjl8sT6ujp1w19so=; b=CG3VU3NEZMY5I+B3lXY0T8X/GTSlTZ4K7qayn3KWcAsihoXqAR4Tf3fseqK0K9SHms 4yuKqZCAJTgq7ue3iUgHDiNGq1NOQY6l6bCvl1TwKJtJpm0PcdY52307et+RjWrLzFUh RQXMpjgz5/cWnae7BHkLinCLeQI+stMOQq9HfRb/PrrQtV++cPU6y9a01rM68NC35z5o J4PqM+ODlVA2/sB1Qg6vjJa8P9qfCRBvUQMf7QwI1xxQ86ngg0DP4TXJ4dziaeqCgOOp i8LpnLSgYDuGlVISyJBIDwBUTWZMo5kni4Y6gbf9kYTtKohphXZDuS++Il5lUaxTyqj7 LuPQ== X-Gm-Message-State: AODbwcDdsPcwcSwWY9hmDzVYAJp0gnV+oirLO1CJ63yu5LsA7dgv0DXk PGO03Bki7JiLdpjR7jpLBGyy7lYBlw== X-Received: by 10.176.81.4 with SMTP id e4mr5789037uaa.33.1496290244118; Wed, 31 May 2017 21:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 21:10:43 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 21:10:43 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Seth Blank , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1914907b4b050550de386c" Archived-At: Subject: Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS 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, 01 Jun 2017 04:10:46 -0000 --94eb2c1914907b4b050550de386c Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) wrote: > There's another question that had been raised by Seth about whether d= > needs to match within an ARC set. The answer is yes, [...] > Why? -MSK --94eb2c1914907b4b050550de386c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 6:23 PM, Kurt Andersen (b) <kboth@= drkurt.com> wrote:
There'= s another question that had been raised by Seth about whether d=3D needs to= match within an ARC set. The answer is yes, [...]
<= br>
Why?

-MSK
--94eb2c1914907b4b050550de386c-- From nobody Wed May 31 21:20:49 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 7A30D1274D0 for ; Wed, 31 May 2017 21:20:48 -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 HY0fJwJZWnvj for ; Wed, 31 May 2017 21:20:46 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 A5C40127078 for ; Wed, 31 May 2017 21:20:46 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id w1so18768931vkd.2 for ; Wed, 31 May 2017 21:20:46 -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=9eG2F3QZmIhfi3Fe4CV7GQ5Ae0LPZpRH6HeTfIyeOZw=; b=OVmFau7poBUUUyBBWsAvFkuzjLzgGL1Uqxw9T+ZJMPEf11xxfQzUqMgyBjJRw9lIzF rdS6iNvZIjNzKHevLgPldbtxo7rBMZeaE6aCms4TsjK0tJWiu75IgqjI04kqYri5ssSN ZE2P70VZHeB6gRNCj/sW1S2mk1TeRmSllGNLCwCailZEmb/KH6UZpL6pF6esj3ohsJmt s4bPiME68MZhLY0tbsEcwwRGnGXO0/K1AoDzQ5WCzVcJ5AK4PEZl0HIXazO56sf4PxSh FVhe3kzR2ow89zk0X3rtD7VtnI8jF8IkJq0Aro98/rSICIjnUQWEWPgcaKM44meRYNIs D51A== 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=9eG2F3QZmIhfi3Fe4CV7GQ5Ae0LPZpRH6HeTfIyeOZw=; b=fm13cHrNmLGU/tvPxa6tinlWQ1hApz+bd9IhemzdmXxf26muj9KUYe8Fo7w5dBUCbk EJTELKSGdwYBGxRF/HSvYXyv+83raW+i8RkZ+an+fZRLWtPxQF3DpuKXzOguAjBkzMVE 2VOF64jMtzpwjKEld7tgq/UXWk75WE82Nz+5KKnDPaYXaWHqUx0lFmNbQv2VJC2ln6cB WSAetJyUxk4y57qHHokSbtktFIYH1VFj6BySjbJRbIHv6ju53vHlSe3eCEuRrbw/NMea wnLaqrSRrrvCVnG+wCe+/S/tF0TTbmdkAohRKrneMas5geqSLyaTPsHK9k5MvnCDzZS5 WTYA== X-Gm-Message-State: AODbwcB5sfLNPvbMmPG3dY6LJNescvtYSnruIi6aHirjb7w5CHmEKU8W +2H5gx8y1k0WsM+rW/lVHKNTs3m9M9B9 X-Received: by 10.31.158.195 with SMTP id h186mr13974416vke.30.1496290845795; Wed, 31 May 2017 21:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 21:20:45 -0700 (PDT) In-Reply-To: <34808716.2nE2qoVfF5@kitterma-e6430> References: <34808716.2nE2qoVfF5@kitterma-e6430> From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 21:20:45 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a11425dfe5832df0550de5c55" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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, 01 Jun 2017 04:20:48 -0000 --001a11425dfe5832df0550de5c55 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman wrote: > On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote: > > 2) smtp.client-id > > > > The goal here is to track the originating source_ip for DMARC > > categorization and reporting. Otherwise, all ARC messages will have a > DMARC > > report source_ip of the last forwarder, not the originating service. This > > will be exceptionally confusing to consumers of DMARC reports. > When A-R came to be in RFC5451 there was a protracted debate (leading all the way to an IESG appeal, and ultimately the text of Appendix C in that document and in RFC7601) about this very thing. The tl;dr is that we left it out on purpose, for two reasons: 1) A-R is meant to relay properties of the message that were authenticated/validated/whatever, and the IP address is not part of the message or its envelope; and 2) A-R is meant to relay information about what authentication/validation/whatever was done in a way that's meaningful to users, and the IP address (especially now in a v6 world) is pretty much never meaningful to users. Another way to look at it: A-R is meant to be a channel to record what authentication was done and what thing in the visible message got authenticated so, say, an MUA could show the domain name in green next to a spinning gold key or whatnot to show that it was safe, based on . It was not meant to provide enough information that an MUA or internal MTA could re-perform authentication, say, when the message was opened by a user. What we're seeking to do here is add it to A-R as a way to get that information through to a place where DMARC can get it to include in reports. If we want to redefine what A-R is to meet that requirement, then that's something consensus could certainly do, but if not, I'd prefer not to use it as a substrate against its stated purpose. We could also, however, standardize "X-Source-IP" (without the "X-", of course) and use that, as it already has numerous consumers and other applications well beyond ARC and DMARC. -MSK --001a11425dfe5832df0550de5c55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:
=
On Tuesday, May 30, 2017 10:14:08 AM Seth Blank wrote:> 2) smtp.client-id
>
> The goal here is to track the originating source_ip for DMARC
> categorization and reporting. Otherwise, all ARC messages will have a = DMARC
> report source_ip of the last forwarder, not the originating service. T= his
> will be exceptionally confusing to consumers of DMARC reports.

When A-R came to be in RFC5451 the= re was a protracted debate (leading all the way to an IESG appeal, and ulti= mately the text of Appendix C in that document and in RFC7601) about this v= ery thing.=C2=A0 The tl;dr is that we left it out on purpose, for two reaso= ns:

1) A-R is meant to relay properties of the message th= at were authenticated/validated/whatever, and the IP address is not part of= the message or its envelope; and

2) A-R is meant to rela= y information about what authentication/validation/whatever was done in a w= ay that's meaningful to users, and the IP address (especially now in a = v6 world) is pretty much never meaningful to users.

Anoth= er way to look at it: A-R is meant to be a channel to record what authentic= ation was done and what thing in the visible message got authenticated so, = say, an MUA could show the domain name in green next to a spinning gold key= or whatnot to show that it was safe, based on <method-of-choice>.=C2= =A0 It was not meant to provide enough information that an MUA or internal = MTA could re-perform authentication, say, when the message was opened by a = user.

What we're seeking to do here is add it to A-R = as a way to get that information through to a place where DMARC can get it = to include in reports.=C2=A0 If we want to redefine what A-R is to meet tha= t requirement, then that's something consensus could certainly do, but = if not, I'd prefer not to use it as a substrate against its stated purp= ose.

We could also, however, standardize "X-Source-IP" (wi= thout the "X-", of course) and use that, as it already has numero= us consumers and other applications well beyond ARC and DMARC.

-MSK
--001a11425dfe5832df0550de5c55-- From nobody Wed May 31 21:23:30 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 CD06E12773A for ; Wed, 31 May 2017 21:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=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 tRBsCl7WTiFw for ; Wed, 31 May 2017 21:23:28 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 52D84127078 for ; Wed, 31 May 2017 21:23:28 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u10so21011333uaf.1 for ; Wed, 31 May 2017 21:23:28 -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=sHcV5ACsK8PitLmZ+RtBd38xy5MNPVRWRIIUJZJed0k=; b=MZgQ0PxOw0VV9Wqhpel0wn0jFp/CvtvIPRq7lgrX0l5MH6mDGZC+5K4DoX5wPj+GSu 2rOxJYHq2MrAojQdIVfz7vCQ3T3xhPVTC4HUFimZAE8kZXzkM6SvbyOay3/MNndH7dTW LOtwSdC84XBFedoWwBxKppfVrm/ENdN7sQmmyWxd/LLdkSf/sZpsm5kZw88JZoSZbk4Z +LNo5h58ikFYYxsIwch7I0SyCueqdZFRjpRf05LoLIOwmtEoFa/8pU2/0sEHLQDEtM2q pbWZaxbfBU/EFSfy6KvNNN6ZBVALKL07px4NHyOZwRm+x6ZlNh7JQs2+RwQwhUZFcN/b aV6g== 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=sHcV5ACsK8PitLmZ+RtBd38xy5MNPVRWRIIUJZJed0k=; b=LAv97jQvvJrD4ycPT+PypIKjXssTE3JLrQS1DlskUPJ8Ke4qu+7prhf9KEgwFB/cwd PxtYQKRJTxS71O1/2nOcMTabqf+792EGS7rtrydrBGelDCIv0dwkW/HtJxtWW5A5rVrT +tdKcf3N3bVgr1XdbLlOjwSSNneJ8QpWcBWSTnuHOkUcZMp9J73gLAhJ8IUJx4dZyJZ/ /IUsWW3XSLH9o9JGvJ35PdZ6euM2dyLuoG36hlZ1AQJ6LaJG2ZrzEtw5Kh5FjZHFd69N N/UNf2QGDvbTGZlVCABRxxOBNBukwSijfN8g53GjeLx62ppFEVrGeSyrZd3dSLCaWi3P U1lQ== X-Gm-Message-State: AODbwcB2p2l3jGXX/PW8VcdSBO04FYcDS2QqiYAYldZC3OR9JUbtH2pD 0nVLFQXZs5exISclEZzAoEAhclev3w== X-Received: by 10.176.77.173 with SMTP id s45mr3443178uag.29.1496291007507; Wed, 31 May 2017 21:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 21:23:26 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 21:23:26 -0700 Message-ID: To: Barry Leiba Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f4030437a070fbb2f20550de65da" Archived-At: Subject: Re: [dmarc-ietf] Proposal: Writing a DMARC usage guide is not a good task for this WG 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, 01 Jun 2017 04:23:30 -0000 --f4030437a070fbb2f20550de65da Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 5:47 AM, Barry Leiba wrote: > I agree with this. If there's stable documentation on DMARC usage > that we can cite, there's little value in adding our own, which is > likely to end up diverging from the others. > > Does anyone think we *should* proceed with writing this? > Hard to say. Maybe, with development of a DMARC on the standards track. But I'd like to see some momentum first in general, and secondly a good reason why this has to come from the IETF. Otherwise, some informative text in appendices in either ARC or DMARCbis should suffice, rather than a separate document. -MSK --f4030437a070fbb2f20550de65da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 5:47 AM, Barry Leiba <barry= leiba@computer.org> wrote:
I agree with this.=C2= =A0 If there's stable documentation on DMARC usage
that we can cite, there's little value in adding our own, which is
likely to end up diverging from the others.

Does anyone think we *should* proceed with writing this?

Hard to say.=C2=A0 Maybe, with development of a DMARC on = the standards track.=C2=A0 But I'd like to see some momentum first in g= eneral, and secondly a good reason why this has to come from the IETF.=C2= =A0 Otherwise, some informative text in appendices in either ARC or DMARCbi= s should suffice, rather than a separate document.

-MSK
--f4030437a070fbb2f20550de65da-- From nobody Wed May 31 22:07:50 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 CA8BD12949B for ; Wed, 31 May 2017 22:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 zgAuhwm_nhcE for ; Wed, 31 May 2017 22:07:47 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 59AC9126DFF for ; Wed, 31 May 2017 22:07:47 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id x71so19107171vkd.0 for ; Wed, 31 May 2017 22:07:47 -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=owsldUqfopkAk2COqdDOIlfgv9NRABFhLWajhqbJjfA=; b=oNDpky2SNnZNSlMW1dXkmQtP7D+PkCNKb3p+rBF+bbf0rAS8n6GLQ8Qk0qS/Joss7F IZ0BhhYiAtZg1zLPVtlS9YdFfE1dNBUUGJ869f3V+CBx8qRGLiMaW2eBxHCGgFDnSDxN ua6C+YJRiTsED2Q6FrMJiKdAhmHdBJ0oGI/6jgv/+tJR0IMG3mC6H0vnuQqVz2Jh+gxQ eEfq5ya+h1mDFcgsD5XRP1uCCeqlI9jzCoBICtTsPF6A2OqtuZRXBYCM9uPzOS+vdyvL XmCflTaS27VFLaHGgOFQtPxBs060aV8IIGhLxOEvL1P53zRbHk1JJGtijpY7sLa/H2+M zJ7g== 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=owsldUqfopkAk2COqdDOIlfgv9NRABFhLWajhqbJjfA=; b=bDVsvMqLrQVzrV4eLLe4i6UZz0eiYLQ2x+GPLSDe2rtzQb/m3/vp7VPl7kJX8X98LK gpNcs+heZRNzp4RNE6N1AhoLCv+KmCszpm8Zeohrh12MMJA3MRvfhFrNjTvXjfojYL32 bjJvMn9NDCRxvWbYn8vl998w65N6D+JpF0aWZtvrsCfroCS9Y6PQeUqKeVI9eH6eTZJF ikYJtJMvELhQ1GEinUARqwnEmPg2opKY0Yl+5snn+Swrj2yMggc0jC3NweWiESA77J9I bOvuIl0mbsawROyQ0tSpxbwq1ui1kkcnPP5VyQvyrjwkReqaqI2VD7ssjjBeavUY198u dcbQ== X-Gm-Message-State: AODbwcD3P3kaOvv7/RHsfI0JsRjZbAakakwOznJOw13ldzF+77ZgpNOb LEQ4L0ViivGA3iRAkIypuMhaslLZ9A== X-Received: by 10.31.98.196 with SMTP id w187mr13407570vkb.96.1496293666448; Wed, 31 May 2017 22:07:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 22:07:46 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 22:07:46 -0700 Message-ID: To: Peter Goldstein Cc: Brandon Long , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07b57a77e9fd0550df04f3" Archived-At: Subject: Re: [dmarc-ietf] reporting arc local_policy to dmarc rua 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, 01 Jun 2017 05:07:49 -0000 --94eb2c07b57a77e9fd0550df04f3 Content-Type: text/plain; charset="UTF-8" On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein wrote: > So as a consumer of these reports I'd definitely like to see a structured > value with as much information as possible. > > The ideal would be to get as much information as we'd get if the final > receiver had seen the original email directly at i=0. So that would mean: > > - SPF Result and SPF domain > - For each DKIM signature on the i=0 email, the result and the > domain. This should show all signatures from the original message, > regardless of status > > Aren't those in the DMARC report already? > > - > - DKIM Selectors - Unfortunately we probably can't get the DKIM > signature selectors (because they aren't generally recorded in the > Authentication-Results, and so won't be available to downstream hops), but > if we can get them, that would be very helpful. > > They could be added to A-R, in theory, but they're not really user-consumable which is why they were originally omitted. > The above will aid in classification and tracking down problems with > authentication. > > In addition, we probably want to record the # of hops (i.e. i=2) > That could be added as a message-level property. > The proposal above is a good start, but I don't think it handles the > multi-DKIM signature case well. Do you have thoughts on how you'd record > and propagate information on multiple signatures in the report? > Doesn't the XML schema for DMARC reports permit multiple signatures to be reported? -MSK --94eb2c07b57a77e9fd0550df04f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <<= a href=3D"mailto:peter@valimail.com" target=3D"_blank">peter@valimail.com> wrote:
So = as a consumer of these reports I'd definitely like to see a structured = value with as much information as possible.

The ideal wo= uld be to get as much information as we'd get if the final receiver had= seen the original email directly at i=3D0.=C2=A0 So that would mean:
=
  • SPF Result and SPF domain
  • For each DKIM signature = on the i=3D0 email, the result and the domain.=C2=A0 This should show all s= ignatures from the original message, regardless of status

Aren't those in the DMARC repo= rt already?
=
  • DKIM Selectors - Unfortunately we probably can't get t= he DKIM signature selectors (because they aren't generally recorded in = the Authentication-Results, and so won't be available to downstream hop= s), but if we can get them, that would be very helpful.

They could be added to A-R, in theory, b= ut they're not really user-consumable which is why they were originally= omitted.
=C2=A0
The above will aid in classification and tracking down problems= with authentication.

In addition, we probably wan= t to record the # of hops (i.e. i=3D2)
<= br>
That could be added as a message-level property.
=C2=A0
The proposal ab= ove is a good start, but I don't think it handles the multi-DKIM signat= ure case well.=C2=A0 Do you have thoughts on how you'd record and propa= gate information on multiple signatures in the report?

Doesn't the XML schema for DMARC reports permit= multiple signatures to be reported?

-MSK
=
--94eb2c07b57a77e9fd0550df04f3-- From nobody Wed May 31 22:30:27 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 9350A129B4D for ; Wed, 31 May 2017 22:30:25 -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 (2048-bit key) header.d=valimail.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 vHEPmFUX2Lbp for ; Wed, 31 May 2017 22:30:23 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF11128CF0 for ; Wed, 31 May 2017 22:30:23 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d14so28459679qkb.1 for ; Wed, 31 May 2017 22:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S1tdloXSs3MIVNEeWUFZrQHYc5wZDyT+zmP2/ByU6co=; b=MspzMZiEYsNao1ligewRadRZIWvhCmQn4PUvnaWd4baE7JaGv8YgiLWzQJY+xzJ52v c38SvwYJ5LySLU4FOx5b6crbxQsee0Ei+USFUmReFcNQUiYEBMBKtfQdOzAv4vqSd2lQ sS+hDwduzeVprs5vQmAEYWydrq7e9ZOOvy2hLChdjwkPoN0+ytY50vE3dkXry9JuxHSo mjEkQyQrtpsyUc3pAI/58jFaLWh9C2vlF9cbPwuUxKSwLJJN1kWFDj6m16XERi93/+iN IgxZBnaHv6nE6flphWXepDOVnzdL9Qnu9rPEx4xtmHn1uR8w+NmsvU/N2dYz6zjXX0Eq 4iEQ== 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=S1tdloXSs3MIVNEeWUFZrQHYc5wZDyT+zmP2/ByU6co=; b=XupJj2x4quEWjIZtic2ZXLdL4xVGJF71SEwWTmbJPxV6QyUwAZhkTsnhwrJQC/R5ap QpX2hePNAg+snZXeaSYAjGV+9RzAsJEWTbbu9HSvPbdedmdK/BbkJO6ewfSX+BpszKGJ GUQxAxPVqYx6MQwOF7D+Im7Y9NwZGOWBmkKcRjZQEVfTQC4mqwxPYnS/lEBGfMFQMcNU 67Or99Chawqsj7QntpZ0E/dUfvrSpWFaclC8lpeDlKASAY6vHUq2KT5klB6dAs+y/yZM 4HhtkogjmRTiQJ4B1pfiFqbO0AEEf4r3QW0Ojr3DcXl8dHXIgAhavpjgO6eF1rKh1VOD grhA== X-Gm-Message-State: AODbwcCwRQA+T6BkQRKnHqiFs2RaWRqeO/J+iEkGe8diUhTb3olvmzrV 06v85fSv03F5zmdJiUAeSBZQk9OfSHMmgVM= X-Received: by 10.55.25.41 with SMTP id k41mr31353889qkh.163.1496295022132; Wed, 31 May 2017 22:30:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Wed, 31 May 2017 22:30:01 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> From: Seth Blank Date: Wed, 31 May 2017 22:30:01 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="001a1147da424622a90550df55ca" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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, 01 Jun 2017 05:30:25 -0000 --001a1147da424622a90550df55ca Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 9:20 PM, Murray S. Kucherawy wrote: > What we're seeking to do here is add it to A-R as a way to get that > information through to a place where DMARC can get it to include in > reports. If we want to redefine what A-R is to meet that requirement, then > that's something consensus could certainly do, but if not, I'd prefer not > to use it as a substrate against its stated purpose. > Absolutely understood, and agreed. > We could also, however, standardize "X-Source-IP" (without the "X-", of > course) and use that, as it already has numerous consumers and other > applications well beyond ARC and DMARC. > > Okay. My original point for smtp.client-id was simply to transfer the source_ip for a DMARC report, because it is valuable for a final report consumer. I suggested the AR because it seemed like the cleanest way without needing to modify the spec. Clearly transmission via the AR/AAR is the wrong way to do this based on the purpose of the AR. So I guess returning to the original thread, there are two matters: 1) Should we stamp header.b in the A-R? (consensus seems to be yes) 2) How should we transmit the source_ip for the DMARC report? Murray, does your suggestion mean a separate doc regarding a signed Source-IP header that would then be referenced in ARC and covered by... what, the AS? Or is there a cleaner way? Thanks for the context and suggestion! Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1147da424622a90550df55ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Okay.

My original point for smtp.client-id was simply to tran= sfer the source_ip for a DMARC report, because it is valuable for a final r= eport consumer. I suggested the AR because it seemed like the cleanest way = without needing to modify the spec. Clearly transmission via the AR/AAR is = the wrong way to do this based on the purpose of the AR.

So I guess returning to = the original thread, there are two matters:

1) Should we stamp header.b in the A-= R? (consensus seems to be yes)

2) How should we transmit the source_ip for the DM= ARC report?

Murray, does your suggestion mean a separate doc regarding a signed S= ource-IP header that would then be referenced in ARC and covered by... what= , the AS? Or is there a cleaner way?

Thanks for the context and suggestion!
=

Seth

--
--001a1147da424622a90550df55ca-- From nobody Wed May 31 23:08:48 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 05645128AFE for ; Wed, 31 May 2017 23:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=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 75BFbRzh89tK for ; Wed, 31 May 2017 23:08:45 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0B9120724 for ; Wed, 31 May 2017 23:08:45 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id y4so21841305uay.2 for ; Wed, 31 May 2017 23:08:45 -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=y4oxtkc+UTlSBpKcWbyJbDGtYgu9g78ZMM3zYlJLAYA=; b=Nj3IePC7YPkWmj7/+ATbMGj/KkB92pCpk1xdG+3l0apIlpxAh0mRszFOuKNNJ0Mibz AKoj5lM771pPrJQcDKZmOGfZWzl7w7d7z8+MNHpOhyJMRG4StX86TYwofb4GHDv47HEV sOrUNQNXlryoniqVGeRVhD0Rc/CKllW89OAwiMP4Ot2ZWhIrXk+0yo4src+q+qWcg1n7 R46dpsczRLXWZcnnsFBMjvhA4ge5/9FlHWEG+Dgnh54T/Enx2UnmNZP8RtmXd8PVOoHY pUp13hVMhIZNlgg10erUrJ9/tJbxeXp4m5pU1kwmaUjCLBGrFnPsHuy48U+xLOqYAtT6 drlQ== 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=y4oxtkc+UTlSBpKcWbyJbDGtYgu9g78ZMM3zYlJLAYA=; b=Qrr9GpUb+syfO9qgZY0WDJQKNUUPN8dSg0equ/XFbw8icSrcJNJIevaA3mP5Zuvpy8 sKF87sBJ+7169RyDEc9P+BlSMAnwAAf1TJ/7ZLEccc6PRvslCA0VAnXu2qaTTgh2iZIQ Ha5cJQBpRsQ1ALkeE8zwUOOBWwwY6oUayz6pw3z98POcsa8g9dYZBgY13Yl8f83iF0jT wT3CZrwXczayKoqpqUNYSYMVEtwY0ghNdxbkNTtHFltsdfvwaf7W56Bu/gpPCNudmpcH 1HF3bJs8Poht7nCv8HafV4GOcCS3ymp4Kw5pz4wIF5knhCTbZwNYEdKJJt7OMJkiznhA IMXQ== X-Gm-Message-State: AODbwcD/4b0dNX6f1B3h7sD0ocdIyy/HjOiVZPNUZjArOLcz/Ua99lMv ZPv8eKvXsmBerCBjYM4CAiUsvagC4A== X-Received: by 10.176.94.133 with SMTP id y5mr16224019uag.150.1496297324446; Wed, 31 May 2017 23:08:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Wed, 31 May 2017 23:08:43 -0700 (PDT) In-Reply-To: References: <34808716.2nE2qoVfF5@kitterma-e6430> From: "Murray S. Kucherawy" Date: Wed, 31 May 2017 23:08:43 -0700 Message-ID: To: Seth Blank Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="f403043c56848087b20550dfde1f" Archived-At: Subject: Re: [dmarc-ietf] Authentication-Results stamp for ARC 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, 01 Jun 2017 06:08:47 -0000 --f403043c56848087b20550dfde1f Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 10:30 PM, Seth Blank wrote: > > So I guess returning to the original thread, there are two matters: > > 1) Should we stamp header.b in the A-R? (consensus seems to be yes) > It's defined, may as well use it. > 2) How should we transmit the source_ip for the DMARC report? > > Murray, does your suggestion mean a separate doc regarding a signed > Source-IP header that would then be referenced in ARC and covered by... > what, the AS? Or is there a cleaner way? > Source-IP was just one suggestion. If we do decide to do that, I would do it in a separate document, and then the ARC work can just recommend its use and require covering it in the AMS or AS if it's present. We could also risk some wormy can opening and discuss the idea of expanding the scope of A-R to include this use case rather than strictly supporting MUAs, thereby enabling your original idea. Both of those ideas are valid, and there may be others. -MSK --f403043c56848087b20550dfde1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 31, 2017 at 10:30 PM, Seth Blank <seth@valima= il.com> wrote:

So I guess returning to the original thread, there are two= matters:

1) Should we stamp header.b in the A-R? (consensus seems to be yes)

It's defined, may as well use = it.
=C2=A0
2) How should we tran= smit the source_ip for the DMARC report?
Murray, does your suggestion mean a separ= ate doc regarding a signed Source-IP header that would then be referenced i= n ARC and covered by... what, the AS? Or is there a cleaner way?=C2=A0
<= /div>

Source-IP was just one suggesti= on.=C2=A0 If we do decide to do that, I would do it in a separate document,= and then the ARC work can just recommend its use and require covering it i= n the AMS or AS if it's present.

We could also risk s= ome wormy can opening and discuss the idea of expanding the scope of A-R to= include this use case rather than strictly supporting MUAs, thereby enabli= ng your original idea.

Both of those ideas are valid, and= there may be others.

-MSK
--f403043c56848087b20550dfde1f--