From nobody Thu Oct 1 02:29:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9A1A03A1 for ; Thu, 1 Oct 2015 02:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 b4-auNO-yhyb for ; Thu, 1 Oct 2015 02:29:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13021A039D for ; Thu, 1 Oct 2015 02:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1443691746; bh=iIP894ukWyLLDEcPEVB+upV5hhyfbuFq6ac8G7eNtUE=; l=1495; h=Date:From:To:References:In-Reply-To; b=YD//GbEvXLqMO8ntHwPr7ylQRwFvr3fTiaILfNSpcoqwAgx9dwR7EYtuFh1mHMxaM rndvXVrLb3lw1GXMKGuiROwlW2kugBoZ3eDNzcbKTgEQf2Mb88Q4WyPHzz0iTzqDaQ nIsDbA5Uhjz3ziAPtnDYQ1xkGlKUcwkvvLwIt6Hg= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 01 Oct 2015 11:29:06 +0200 id 00000000005DC044.00000000560CFCE2.000034C8 Message-ID: <560CFCE2.9080109@tana.it> Date: Thu, 01 Oct 2015 11:29:06 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150930144219.17690.qmail@ary.lan> In-Reply-To: <20150930144219.17690.qmail@ary.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Oct 2015 09:29:14 -0000 On Wed 30/Sep/2015 16:42:19 +0200 John Levine wrote: >> >> [R]equire conventional, full DKIM signatures. Why? It seems to me that any >> DMARC authentication method could suffice. That is, the author domain >> (!fs signer) could be SPF authenticated by the MLM; and the MLM could be >> SPF authenticated by list recipients. No? > > You're mixing levels here. dkim-conditional describes a new way to create a > valid DKIM signature. I wouldn't want to try to describe how a DKIM > validator is supposed to stop and take a detour through an SPF validator to > decide what to do next. At DKIM level, validators had better just describe their results. For example, a MLM may want to know if the !fs-signature of an incoming message is good, although its required DKIM signature is obviously still missing at that stage. At DMARC level, it is straightforward to describe how a verifier retrieves conditionals, and state that one or more of the Authenticated Identifiers must be aligned with at least one of the !fs= domains in that case. Please note that such statement would modify RFC 7489, as expected of a DMARC fix. Anyway, the advantage of operating at DMARC level is the ability to receive feedback on missing !fs conditionals, not just to enable SPF. Feedback would be based on fo= rather than on p=. Therefore, semantics and maintenance of the internal lists of domains which trigger weak signing would be improved, both at large and at small mail sites. Ale From nobody Thu Oct 1 09:37:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435821A8724 for ; Thu, 1 Oct 2015 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 KCXTNjtOg84e for ; Thu, 1 Oct 2015 09:37:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B281A8737 for ; Thu, 1 Oct 2015 09:37:24 -0700 (PDT) Received: (qmail 80366 invoked from network); 1 Oct 2015 16:37:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Oct 2015 16:37:24 -0000 Date: 1 Oct 2015 16:37:01 -0000 Message-ID: <20151001163701.5510.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: steve@wordtothewise.com Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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 Oct 2015 16:37:26 -0000 >> Quite correct. I would expect conditional signatures to be applied by >> large mail systems, using their private list of domains that look like >> mailing lists to decide who gets them. > >How much of a barrier to entry to new or small mailing list providers >(or new domains being used there) does this cause? Beats me. Depends on how the large providers manage their provider lists. In an optimistic scenario, they see the welcome message from the list and use that to add the list's domain to the resigner list. On the other hand, compared to the current situation, ... R's, John From nobody Fri Oct 2 05:25:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8971B2B0B for ; Fri, 2 Oct 2015 05:25:51 -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, SPF_PASS=-0.001] autolearn=ham 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 Q9Wf1Y3bBsqP for ; Fri, 2 Oct 2015 05:25:50 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 27D791B2B09 for ; Fri, 2 Oct 2015 05:25:50 -0700 (PDT) Received: by qkcf65 with SMTP id f65so41738719qkc.3 for ; Fri, 02 Oct 2015 05:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KgxZgu4j9gphwYk0NAB67jrtm2VS2M3fweSiZ1Nka6k=; b=s25gYHYeGNFsSBD0biZeaOG1QP3Dn7R8hHWbSxW68u7RuUto+seEfID9h4soTNDjlH oKkCIP0wdcKtXDM6MbXitFhyjuFuOsggLAyeBEFu4MzgoU0s1kUD4pqtu1DbOq3hsMRh pRM8inU9JdZCT4nRgKa9GmoJFlfKaz9uUJKaJfKLt+rmHfQy1/GVyaFwjwPHiHmNBQZF qS8IMGGCgkbGHMEjR4QX29vquucCkZolAK9j9BMOPjILIhO+oL2pamQUIkBJcYo9HiRr LRKCVk/Vt/3+95mI3Uda2hObVmuviMAcGHJnSoVtnHbytKa5sdCrIHGHd1/7lwjHtl+j bQfg== MIME-Version: 1.0 X-Received: by 10.55.198.201 with SMTP id s70mr19376837qkl.85.1443788749320; Fri, 02 Oct 2015 05:25:49 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Fri, 2 Oct 2015 05:25:49 -0700 (PDT) In-Reply-To: <20150929170849.13962.qmail@ary.lan> References: <20150929170849.13962.qmail@ary.lan> Date: Fri, 2 Oct 2015 05:25:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a1147828488b99705211e433d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Oct 2015 12:25:51 -0000 --001a1147828488b99705211e433d Content-Type: text/plain; charset=UTF-8 This has been implemented in an experimental branch of OpenDKIM, since about May. I haven't released it yet, but it's probably time to do that. I made a post some time back about changes I made in my implementation versus the spec. I'll dig that up too. For one thing, I apparently decided I didn't like the term "forward signature" and preferred "conditional domain", so the new tag is "!cd". We can argue about that and the other stuff when I find that post. If there's generally support for serious consideration of this approach, I suggest the chairs do a Call For Adoption. -MSK On Tue, Sep 29, 2015 at 10:08 AM, John Levine wrote: > I refreshed this draft so it wouldn't expire. Not very different, > mostly changed the @fs= to !fs= per Murray's suggestion. > > I still think this is the least broken way I've seen to let > mailing lists coexist with DMARC. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a1147828488b99705211e433d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This has been implemented in an experimenta= l branch of OpenDKIM, since about May.=C2=A0 I haven't released it yet,= but it's probably time to do that.

I made a post some tim= e back about changes I made in my implementation versus the spec.=C2=A0 I&#= 39;ll dig that up too.=C2=A0 For one thing, I apparently decided I didn'= ;t like the term "forward signature" and preferred "conditio= nal domain", so the new tag is "!cd".=C2=A0 We can argue abo= ut that and the other stuff when I find that post.

If there= 9;s generally support for serious consideration of this approach, I suggest= the chairs do a Call For Adoption.

-MSK


On Tue, Sep 29, 2015 at 1= 0:08 AM, John Levine <johnl@taugh.com> wrote:
I refreshed this draft so it wouldn't expire.=C2=A0 N= ot very different,
mostly changed the @fs=3D to !fs=3D per Murray's suggestion.

I still think this is the least broken way I've seen to let
mailing lists coexist with DMARC.

R's,
John

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

--001a1147828488b99705211e433d-- From nobody Fri Oct 2 07:42:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C961B2BC6 for ; Fri, 2 Oct 2015 07:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 SCDJXDt_yG3v for ; Fri, 2 Oct 2015 07:42:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8261B2BC1 for ; Fri, 2 Oct 2015 07:42:02 -0700 (PDT) Received: (qmail 74512 invoked from network); 2 Oct 2015 14:42:02 -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=1230f.560e97ba.k1510; bh=eAQRDQUlJnu2B6lkxQJ2aIPuhCiSCVDjBBpdgBBAsFs=; b=stRKlq/vOm8c2jEbuYRwHbzBH7NWEA9hzYu51YjnmIEzwhKsQWjayGvYY8iu+pbIbwbwxP1YYNyTQGh+ZoBvQ8E54OILPGZR848N5vjdQur0zJovOirNhmoAd3BPtf0pyhuFcWSVRYS49lgKXnKzf8mnxMVNJibaxZlKePi9Qg029BeCL3wrzkfRF53NMZCJ3hJf+L3UVqMnvpfn/qmr6K/7RvjFrT7R9a/lvq7Kbd0qncjjD1tzkrG0zI2DTcfq 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=1230f.560e97ba.k1510; bh=eAQRDQUlJnu2B6lkxQJ2aIPuhCiSCVDjBBpdgBBAsFs=; b=QJ/maTwAOdR7Vgpg+cnH6vUZbVcIdMzNsaibZp4m6zl2szsupPZmXNKWAxltS6Wg5gNptfZyPDuhccKoakV2YlufHtqQ7fWHYESv0X17oahunoOftSNyBSckai2zdXSlF5L1AylgVaT+No6M0sCdYkPu0cB42DNDnMWz1RwYLoQ3qieFdAfP5VRDx0dNeISIn/c8fcvKSdOIUlZXhmnRtZpQJN70b/ykthqT3wHHMn8aBy0LKiF6mL4TjCsQGk1c 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.0/X.509/SHA1) via TCP6; 02 Oct 2015 14:42:02 -0000 Date: 2 Oct 2015 10:42:00 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 Oct 2015 14:42:03 -0000 > I made a post some time back about changes I made in my implementation > versus the spec. I'll dig that up too. For one thing, I apparently > decided I didn't like the term "forward signature" and preferred > "conditional domain", so the new tag is "!cd". We can argue about that and > the other stuff when I find that post. Any tag syntax that's OK with you is OK with me so long as it does the job. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Oct 2 20:13:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A221B336A for ; Fri, 2 Oct 2015 20:13: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 wFFS2NTfr-uh for ; Fri, 2 Oct 2015 20:13:36 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 10E741AC3BF for ; Fri, 2 Oct 2015 20:13:36 -0700 (PDT) Received: by qgt47 with SMTP id 47so110504661qgt.2 for ; Fri, 02 Oct 2015 20:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wvnEiocFIW3v0gAv5aXmNjoWxJqt8G22yBPv+Fjm/A=; b=l2QIqql1cQ3grjBrTUH6GFwWBlbkaIOW6xoMNhIX8aLh3EpP2PTTcJrxso+tOQejDy zGVZ+pKlLFDRUI5N1r/v2C35gnAaaBBmHeJsPMm8latfbXTiX/SPmfLrkfxCLaT7EEW1 e48ZvAeE29T/3GebdxoHlcZF7KOEphzhuhcIfwL0lDXuAiDnVDN7tZYBVeDko7VF6Tjq sK9SRoyLGC5pAxMxgKXa2ajlLYfrEFfz5sK1W15MKJT91e6hdEvBNP3ArcFpGjtmaR1Z 7wf0UfPVWd7FvUMgYUoVOKswhPO9PQQ5CX3IzMAE4HSzY0hNTTDgoWXpj3l1JxpSqHuF y28g== MIME-Version: 1.0 X-Received: by 10.140.233.130 with SMTP id e124mr25499701qhc.79.1443842015232; Fri, 02 Oct 2015 20:13:35 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Fri, 2 Oct 2015 20:13:35 -0700 (PDT) In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> Date: Fri, 2 Oct 2015 20:13:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=001a1136f45a6e1d3a05212aaa93 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 Oct 2015 03:13:37 -0000 --001a1136f45a6e1d3a05212aaa93 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 2, 2015 at 7:42 AM, John R Levine wrote: > I made a post some time back about changes I made in my implementation >> versus the spec. I'll dig that up too. For one thing, I apparently >> decided I didn't like the term "forward signature" and preferred >> "conditional domain", so the new tag is "!cd". We can argue about that >> and >> the other stuff when I find that post. >> > > Any tag syntax that's OK with you is OK with me so long as it does the job. > I think "!cd" is the only thing I changed. Here's my old comment about it with some open issues mentioned, like "v=2" to which Dave objected: https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJSO8 -MSK --001a1136f45a6e1d3a05212aaa93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 2, 2015 at 7:42 AM, John R Levine <johnl@taugh.= com> wrote:
=
I made a post some time back about changes I made in my implementation
versus the spec.=C2=A0 I'll dig that up too.=C2=A0 For one thing, I app= arently
decided I didn't like the term "forward signature" and prefer= red
"conditional domain", so the new tag is "!cd".=C2=A0 We= can argue about that and
the other stuff when I find that post.

 Any tag syntax that's OK with you is OK with me so long as it does the = job.

I think "!cd" is the onl= y thing I changed.=C2=A0 Here's my old comment about it with some open = issues mentioned, like "v=3D2" to which Dave objected:

https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJS= O8

-MSK
--001a1136f45a6e1d3a05212aaa93-- From nobody Sat Oct 3 10:09:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4E1B36EE for ; Sat, 3 Oct 2015 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 MO6agFKQDvzJ for ; Sat, 3 Oct 2015 10:09:01 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1D51B36E9 for ; Sat, 3 Oct 2015 10:09:01 -0700 (PDT) Received: (qmail 60242 invoked from network); 3 Oct 2015 17:09:00 -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=eb51.56100bac.k1510; bh=UVsQ36FTURA9gUA2LvueM+9//iBfugbFEI+jDPfmMYA=; b=0l61nCUNeeB9n+VBnKAKj0PjSiEsBdl5Yw/D1UXZVpGVLN5WEgF6RqygyXp+YISAAT9V/cgQiQRuvh4quvL38SIc081lLfg2RD9LekU0YH7wYe63F37YUHA1u6dfvBXblcwGeMZnCrq5SoNjJiHhM5Tn/CRmwmgwqahnFez8H5pUoJZV2ZbGTaV5QtQTDcxLVmICkFmK5xDVb2UxoOpQ7zjDKBr40W9uQXMT7L/DNWgc+xOsIlqQJtH45b0G11HG 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=eb51.56100bac.k1510; bh=UVsQ36FTURA9gUA2LvueM+9//iBfugbFEI+jDPfmMYA=; b=maw2e4VLDtaMnOcS9Pk2BeOG1c2la+8JX1mQlpVBJR/n8CAcOsY0DQ/0uiTQdfC6nzk1lMwyzFZMHI5sU59BDB8ClZS/9o6x4odSMmlVmybX9m4sqR0y7DAnxSCXHj5o24Y0VlVJDWHN37ag2bKQBg52Q2kGdmhnc7G4GziQriXIPdi3wbKqY6JjZjhKXrIwQtaJeRnGRXePsoSzE5Gd+EPH5y8fibdOz/EtfQeA8Ficknb/N1+axUCnSy+KGk3I 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.0/X.509/SHA1) via TCP6; 03 Oct 2015 17:09:00 -0000 Date: 3 Oct 2015 13:08:58 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 Oct 2015 17:09:03 -0000 > I think "!cd" is the only thing I changed. Here's my old comment about it > with some open issues mentioned, like "v=2" to which Dave objected: > > https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJSO8 I suppose the version bump to v=2 is an open issue, but I don't really see what the problem is. Since the current spec says that unknown tags are ignored, there's no way to add mandatory tags without a version bump. I believe when this came up before, people looked at common DKIM libraries including yours, the perl and python ones, and found that the current code would all fail a v=2 signature, so the version bump should do what we want it to. There was a further rather theological argument about whether one can do a version bump by publishing a short document that describes the changes, or if it requires republishing the entire spec. I don't understand the motivation for the latter, but some people seemed to think it was important. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Oct 3 14:41:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DB1B386D for ; Sat, 3 Oct 2015 14:41:30 -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, SPF_PASS=-0.001] autolearn=ham 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 DX2lH-Hh9uLz for ; Sat, 3 Oct 2015 14:41:28 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 B02561B386B for ; Sat, 3 Oct 2015 14:41:28 -0700 (PDT) Received: by qgez77 with SMTP id z77so122013616qge.1 for ; Sat, 03 Oct 2015 14:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=acBXATeA/oxrvGtg+toMF0g8E96uOFG+owzaK1sgQ4o=; b=gVqh56YgLe4ILlgjfYPdJL7+h2+4s0c5u8T58TjkHqvBjVX+48ceu3EfvzaOWnDB6t 8NNwie5yTTrz5BMjm8+/2n70cXgdk6FxEdmY099i1vOWNVt4R745QdHgaFTR7DHCtB/E 17ZRYhP/1fhaOB5+892HYNR7YRFptIzc52bOoSAoFlrL9rOe7doCVkpRNIEPZmW9Al7M 5wyw7iGsp0BUWxE5XBBWjM2tUB8kMG9zSjltQ85k/vDCLRHOM2Nh1qYw7+S8tgMyQVyH gvR6DprvMmuUkL4wd5krIFtwkZf55kjWc5CWpkfcfTrWStTuS4L+wIUKxBwx8xzFPz3y C8Zw== X-Received: by 10.140.38.82 with SMTP id s76mr29205002qgs.18.1443908487785; Sat, 03 Oct 2015 14:41:27 -0700 (PDT) MIME-Version: 1.0 References: <20150929170849.13962.qmail@ary.lan> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 03 Oct 2015 21:41:18 +0000 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11c137ee80b3f305213a24a3 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 Oct 2015 21:41:30 -0000 --001a11c137ee80b3f305213a24a3 Content-Type: text/plain; charset=UTF-8 I think at least the latter is a minor point since the XML source for RFC6376 is readily available. I'm happy to pick up the editor pen again if needed. -MSK On Sat, Oct 3, 2015, 10:09 John R Levine wrote: > I think "!cd" is the only thing I changed. Here's my old comment about it > with some open issues mentioned, like "v=2" to which Dave objected: > > https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJSO8 I suppose the version bump to v=2 is an open issue, but I don't really see what the problem is. Since the current spec says that unknown tags are ignored, there's no way to add mandatory tags without a version bump. I believe when this came up before, people looked at common DKIM libraries including yours, the perl and python ones, and found that the current code would all fail a v=2 signature, so the version bump should do what we want it to. There was a further rather theological argument about whether one can do a version bump by publishing a short document that describes the changes, or if it requires republishing the entire spec. I don't understand the motivation for the latter, but some people seemed to think it was important. --001a11c137ee80b3f305213a24a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think at least the latter is a minor point since the XML s= ource for RFC6376 is readily available.=C2=A0 I'm happy to pick up the = editor pen again if needed.

-MSK

On Sat, Oct 3, 2015, 10:09=C2=A0John R Levine <johnl@taugh.com> wrote:

> I think "!cd" is the only thing I= changed.=C2=A0 Here's my old comment about it
> with some open issues mentioned, like "v=3D2" to which Dave = objected:
>
> https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BW= zENx8aJSO8

I suppose the version bump to v=3D2 is an open issue, but I = don't really see
what the problem is.=C2=A0 Since the current spec says that unknown tags ar= e
ignored, there's no way to add mandatory tags without a version bump.= =C2=A0 I
believe when this came up before, people looked at common DKIM libraries including yours, the perl and python ones, and found that the current code<= br> would all fail a v=3D2 signature, so the version bump should do what we wan= t
it to.

There was a further rather theological argument about whethe= r one can do a
version bump by publishing a short document that describes the changes, or<= br> if it requires republishing the entire spec.=C2=A0 I don't understand t= he
motivation for the latter, but some people seemed to think it was
important.


--001a11c137ee80b3f305213a24a3-- From nobody Sat Oct 3 15:21:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5A21A872C for ; Sat, 3 Oct 2015 15:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 H2BulmMB-piE for ; Sat, 3 Oct 2015 15:21:04 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853581A8728 for ; Sat, 3 Oct 2015 15:21:04 -0700 (PDT) Received: (qmail 97372 invoked from network); 3 Oct 2015 22:21:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17c5b.561054d0.k1510; bh=fidmR8yLRwXL5K403kTcyVDpk4fQl+DnIV/k9QFLRls=; b=UFoBvvkPuzBjCPaPnbhytXqX2nIkzIAndkZ/plEX9R5EVmXn+fJQ46gPgo0lXg1POWYg67L3ELMM2Qy7kqBoylfOVRafN9kY6OKXm1jVEBBEmMqv/H0X7oYx4qj8UYuQ1NDAk4jP0ATiTS6lAFVVyKqlWx45W3CFHDp3Ocl3ffC76LLq2hjmr6gTS53VBORoq+DveCd3jazONLRCRQ6ar0Ka1UT4/jVzzYIa2LeA/t1VHw/LFfMuIHoULuuESI5e 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=17c5b.561054d0.k1510; bh=fidmR8yLRwXL5K403kTcyVDpk4fQl+DnIV/k9QFLRls=; b=WMhVflZYl6+kafet1TUUTlJh0ui1vHSi43iTSUyeME3ztJDzHN2x3xa+7l83oedkXrD8V9B8SK2MSpf3w1odXdl02vTj/Yz8J4CVGbSzW9m4EbiUxtmmh4RXqEEkscLIoH7AIGtsMey48EIrXfSs1TI+WqaflTWt3ZS8ABn2upZe5VX1a5H1bTAyo54P8DT4QxxGv7jKd7ezinAxNp+89CEuFdEywICsg/wXa8/wA117VmppSwS4V5qii9DRW2nN 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.0/X.509/SHA1) via TCP6; 03 Oct 2015 22:21:03 -0000 Date: 3 Oct 2015 18:21:02 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 Oct 2015 22:21:05 -0000 > I think at least the latter is a minor point since the XML source for > RFC6376 is readily available. I'm happy to pick up the editor pen again if > needed. My concern is that once the can is opened, it's hard to keep some of the worms from escaping. > There was a further rather theological argument about whether one can do a > version bump by publishing a short document that describes the changes, or > if it requires republishing the entire spec. I don't understand the > motivation for the latter, but some people seemed to think it was > important. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Oct 3 16:46:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F431A895D for ; Sat, 3 Oct 2015 16:46:49 -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, SPF_PASS=-0.001] autolearn=ham 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 3bHBsFavjS6g for ; Sat, 3 Oct 2015 16:46:48 -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 C9C301A895B for ; Sat, 3 Oct 2015 16:46:47 -0700 (PDT) Received: by qkap81 with SMTP id p81so57136536qka.2 for ; Sat, 03 Oct 2015 16:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ntnul/1EEV4FtRx0k+fzhanDCHyaR8rMZmid9EeEZOg=; b=bMcGv5oQbUuOaS3ASQTtxL0vYnmkieZbMW5vtF1AqUkqW5nZGVisTJX7Gk7fFW6oG6 F9Kc8QlxSVpLgLqhNccmseli58eZ3NvgEnMkAHdjhG+5wO2xp8TKkeUhyIxvSb0UTwPG i9zQCZUs9xgXNtGa5mtDnh1MYzPwnICUxgjoh6rViFdV16PsHB8KMBOTI04XvnIg7FIm 4FsQDCAsbc98T4G+Ax9F9A1Wbq/KHG9dj9cmY1QKoyhdL83MdlBWf5dssMKQRIKJ8Bli An070A9piT5SnXr1KPeG/qNFzxcEOgKFNbrI0SIWVHFGknzY9dKnZuNfBQiLuEBQteTN 5ncA== MIME-Version: 1.0 X-Received: by 10.55.198.147 with SMTP id s19mr29236496qkl.42.1443916006945; Sat, 03 Oct 2015 16:46:46 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Sat, 3 Oct 2015 16:46:46 -0700 (PDT) In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> Date: Sat, 3 Oct 2015 16:46:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=001a1143ecb0adfaa005213be448 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 Oct 2015 23:46:49 -0000 --001a1143ecb0adfaa005213be448 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 3:21 PM, John R Levine wrote: I think at least the latter is a minor point since the XML source for >> RFC6376 is readily available. I'm happy to pick up the editor pen again >> if >> needed. >> > > My concern is that once the can is opened, it's hard to keep some of the > worms from escaping. Can't the charter help us keep the worms in check? Changes have to be within scope, for example; some of the old worms are off-topic here. -MSK --001a1143ecb0adfaa005213be448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 3, 2015 at 3:21 PM, John R Levine <johnl@taugh.= com> wrote:

I think at least the latter is a minor point since the XML source for
RFC6376 is readily available.=C2=A0 I'm happy to pick up the editor pen= again if
needed.

 My concern is that once the can is opened, it's hard to keep some of th= e worms from escaping.

Can't the charte= r help us keep the worms in check?=C2=A0 Changes have to be within scope, f= or example; some of the old worms are off-topic here.

-MS= K
--001a1143ecb0adfaa005213be448-- From nobody Sat Oct 3 16:49:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F571A896A for ; Sat, 3 Oct 2015 16:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 goDGqen7zP-q for ; Sat, 3 Oct 2015 16:49:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085551A8969 for ; Sat, 3 Oct 2015 16:49:13 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t93NnANV024368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 3 Oct 2015 16:49:11 -0700 References: <20150929170849.13962.qmail@ary.lan> To: John R Levine From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <56106972.4090707@dcrocker.net> Date: Sat, 3 Oct 2015 16:49:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Oct 2015 16:49:11 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 23:49:14 -0000 On 10/3/2015 10:08 AM, John R Levine wrote: > I suppose the version bump to v=2 is an open issue, but I don't really > see what the problem is. Since the current spec says that unknown tags > are ignored, there's no way to add mandatory tags without a version > bump. I believe when this came up before, people looked at common DKIM > libraries including yours, the perl and python ones, and found that the > current code would all fail a v=2 signature, so the version bump should > do what we want it to. Claiming that something is mandatory, as part of a version bump, is meaningless, when the installed base will be using the older version and ignoring the supposedly-mandatory new feature. If the installed base can legally ignore a new feature, then it is not mandatory. The only way to make a feature mandatory in a new version is to provide it in a fashion that makes it only available to folks adhering to the new set of mandatory features.[*] FWIW, this is equivalent to saying that adding new mandatory features is equivalent to creating a new protocol. So if you want to modify DKIM to change the set of mandatory features, then specify that the signature use a /different header field name/, such as DKIM-Signature2. Only adherents to the new scheme will see this. If the signer wants legacy folk who only understand older DKIM to also be able to evaluate a signature, then the signer needs to create two signatures. Things get easier if you make the new feature optional, in which case you don't need a version number... d/ [*] There's an exception that takes a long time, which being starting by making the feature initially optional, then waiting for it to gain massively widespread adoption, then issuing a declaration that it is now mandatory. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Oct 3 17:07:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C6A1A89FC for ; Sat, 3 Oct 2015 17:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 tDFP8aKmBkmX for ; Sat, 3 Oct 2015 17:07:13 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FFA1A89F6 for ; Sat, 3 Oct 2015 17:07:12 -0700 (PDT) Received: (qmail 8976 invoked from network); 4 Oct 2015 00:07:12 -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=230f.56106db0.k1510; bh=i4mFst7Qrz/Q3KAPcX7wAADvK4HpCWGUywqfXimRDII=; b=X2JrYYovntR6e2MqJ34kPEv5xRPzCg3AV1AASnkHHLdhinXw1LQyDZo2EYixvs7QT+MsuNUCo5X2fQqK86AJoVjaP24a5cAwUIgR9QOopgen6fgHq4GJH4qvjM7KVpnnCELu5sUdztXCU7usTOjRbSAWkl7HOk47a1mDMjGaLY1OGVu3I/yHnzE2MduA+sj2gnGn+81G0zkZp3A3Vqupi+Lb2ZNQJDkFt+lBFO9UnxigOiSHx6NU8bzr7KF3rMak 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=230f.56106db0.k1510; bh=i4mFst7Qrz/Q3KAPcX7wAADvK4HpCWGUywqfXimRDII=; b=ZLJ8o+hxlB74TrNrYkpL7ysTGvUES5W+y8etZrqIJ15nJzFpKLTWdx7sdbi3n0o8D0n5EcI+cwDPlprdaT/aRmVsbNAdw660+GLPtlSCfkahCMdBcO9y14yn83dgT4Q/V00bLR+z6dHvyzvrhSPxwMs1oVgnbkWnmlqkwuSKPUvKlOCKmQvYr/piW5RmJ5u0wjajguInkrGONbhVZ55jddkXe+TPswDErQvC//wq1JMOYzrc2w4rJHcmYRwPPBOk 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.0/X.509/SHA1) via TCP6; 04 Oct 2015 00:07:12 -0000 Date: 3 Oct 2015 20:07:11 -0400 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <56106972.4090707@dcrocker.net> References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 00:07:14 -0000 > Things get easier if you make the new feature optional, in which case > you don't need a version number... If you can figure out how to make signature conditional on another with without a version bump, that would be swell. I've been thinking about it for over a year and so far this trick eludes me. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Oct 3 17:22:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE451B2A1B for ; Sat, 3 Oct 2015 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 DKDbqxTak91V for ; Sat, 3 Oct 2015 17:22:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF76D1B2A0C for ; Sat, 3 Oct 2015 17:22:55 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t940MscV024739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 3 Oct 2015 17:22:54 -0700 References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> To: John R Levine , dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56107159.8040404@dcrocker.net> Date: Sat, 3 Oct 2015 17:22:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Oct 2015 17:22:54 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 00:22:56 -0000 On 10/3/2015 5:07 PM, John R Levine wrote: >> Things get easier if you make the new feature optional, in which case >> you don't need a version number... > > If you can figure out how to make signature conditional on another with > without a version bump, that would be swell. 1. I wasn't recommending making the new feature optional. Merely noting the considerable benefit that accrues if you can live with it being optional. 2. I don't really understand your comment. I'm probably missing the implications of the larger context you meant to be replying to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Oct 3 17:23:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51E11A8A66 for ; Sat, 3 Oct 2015 17:23:27 -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, SPF_PASS=-0.001] autolearn=ham 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 kgS2gDStvBtZ for ; Sat, 3 Oct 2015 17:23:26 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 2FA521B2A6D for ; Sat, 3 Oct 2015 17:23:25 -0700 (PDT) Received: by qgx61 with SMTP id 61so123474718qgx.3 for ; Sat, 03 Oct 2015 17:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BWNTJCtLi9vtU6ByXbQaXTTi2f3MsL783gVFAUyfkdY=; b=BSWa3t9Se0a8mayM17d+SJwzbs17DOjuoucYvXfqd2RZLwWw3E9g/XYdwkHt9D+4ay 1YCu9ToHnzaUcWkfFIkUwKvOM4A8KC7zTQRbenDNHhkVzuLLtIyx9lZA2i+wfNG+rV2c +SIOW0tqPXO5c4pHCbVowSwK+R5YAFjk3Z5ROfPjoYqafIPQ7saKTDQj+PPBNUpj68AJ 4V7Wp41BGvNJFSAqTVhXlKjzFYELK7QZ0OQ3gYsoraS89u4/01xOR8uN7z8w8NY8OKrA SOv9C5YxgVKmEq6U8qw5G6UxRtCS7pEDVtfnziBJoLw6zqfwTzFO1M/xBRuMSgvZ2piO Kz4Q== MIME-Version: 1.0 X-Received: by 10.140.237.209 with SMTP id i200mr30483842qhc.92.1443918204302; Sat, 03 Oct 2015 17:23:24 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Sat, 3 Oct 2015 17:23:24 -0700 (PDT) In-Reply-To: <56106972.4090707@dcrocker.net> References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> Date: Sat, 3 Oct 2015 17:23:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113589e4a71de505213c6751 Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 00:23:28 -0000 --001a113589e4a71de505213c6751 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 4:49 PM, Dave Crocker wrote: > Claiming that something is mandatory, as part of a version bump, is > meaningless, when the installed base will be using the older version and > ignoring the supposedly-mandatory new feature. > > If the installed base can legally ignore a new feature, then it is not > mandatory. > I think there's possibly an issue with terminology here. In DKIM v1, a verifier that sees a tag it doesn't understand simply ignores the tag and continues processing the signature. There are no "mandatory" tags other than the few without which a signature can't be evaluated at all (h, b, bh, d, s, c, and a come to mind). Something using, for example, the ones defined in RFC6541 or RFC6651, won't prevent verification by a verifier that doesn't implement those. In the proposed DKIM v2, a verifier that sees a tag prefixed with "!" that it doesn't understand has to fail the signature without further processing. It's not mandatory that the tag be present, but it is mandatory that the verifier has to do something with it or fail. The "mandatory" describes the handling of the tag, not its presence. A v1 verifier would also ignore a v2 signature. > The only way to make a feature mandatory in a new version is to provide > it in a fashion that makes it only available to folks adhering to the > new set of mandatory features.[*] > Doesn't this do that? > FWIW, this is equivalent to saying that adding new > mandatory features is equivalent to creating a new > protocol. > > So if you want to modify DKIM to change the set of mandatory features, > then specify that the signature use a /different header field name/, > such as DKIM-Signature2. Only adherents to the new scheme will see this. > Isn't it true that we've found all current DKIM implementations would ignore a "v=2" signature? If so, I'm not understanding the distinction between "DKIM-Signature: v=2; ..." and a wholly different field name. If the signer wants legacy folk who only understand older DKIM to also > be able to evaluate a signature, then the signer needs to create two > signatures. > It could do a v=1 and a v=2, certainly. In fact in the instant proposal, that's actually necessary. -MSK --001a113589e4a71de505213c6751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 3, 2015 at 4:49 PM, Dave Crocker <dhc@dcrocker= .net> wrote:
Claiming that something is mandator= y, as part of a version bump, is
meaningless, when the installed base will be using the older version and ignoring the supposedly-mandatory new feature.

If the installed base can legally ignore a new feature, then it is not
mandatory.

I think there's possibly= an issue with terminology here.

In DKIM v1, a verifier t= hat sees a tag it doesn't understand simply ignores the tag and continu= es processing the signature.=C2=A0 There are no "mandatory" tags = other than the few without which a signature can't be evaluated at all = (h, b, bh, d, s, c, and a come to mind).=C2=A0 Something using, for example= , the ones defined in RFC6541 or RFC6651, won't prevent verification by= a verifier that doesn't implement those.

In the prop= osed DKIM v2, a verifier that sees a tag prefixed with "!" that i= t doesn't understand has to fail the signature without further processi= ng.=C2=A0 It's not mandatory that the tag be present, but it is mandato= ry that the verifier has to do something with it or fail.=C2=A0 The "m= andatory" describes the handling of the tag, not its presence.

=
A v1 verifier would also ignore a v2 signature.
=C2=A0
The only way to make a feature mandatory in a new version is to provide
it in a fashion that makes it only available to folks adhering to the
new set of mandatory features.[*]

Doesn= 't this do that?
=C2=A0
=C2=A0 =C2=A0=C2=A0 FWIW, this is equivalent to saying that adding new
=C2=A0 =C2=A0 =C2=A0mandatory features is equivalent to creating a new
=C2=A0 =C2=A0 =C2=A0protocol.

So if you want to modify DKIM to change the set of mandatory features,
then specify that the signature use a /different header field name/,
such as DKIM-Signature2.=C2=A0 Only adherents to the new scheme will see th= is.

Isn't it true that we've fo= und all current DKIM implementations would ignore a "v=3D2" signa= ture?=C2=A0 If so, I'm not understanding the distinction between "= DKIM-Signature: v=3D2; ..." and a wholly different field name.

=
If the signer wants legacy folk who only understand older DKIM to also
be able to evaluate a signature, then the signer needs to create two
signatures.

It could do a v=3D1 and a v= =3D2, certainly.=C2=A0 In fact in the instant proposal, that's actually= necessary.

-MSK
--001a113589e4a71de505213c6751-- From nobody Sat Oct 3 18:03:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD721B2D59 for ; Sat, 3 Oct 2015 18:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 hKMzELm9_xQj for ; Sat, 3 Oct 2015 18:03:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFC01B2D58 for ; Sat, 3 Oct 2015 18:03:07 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t941364M026527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 3 Oct 2015 18:03:06 -0700 References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> To: "Murray S. Kucherawy" From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <56107AC6.4020007@dcrocker.net> Date: Sat, 3 Oct 2015 18:03:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Oct 2015 18:03:06 -0700 (PDT) Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 01:03:09 -0000 On 10/3/2015 5:23 PM, Murray S. Kucherawy wrote: > On Sat, Oct 3, 2015 at 4:49 PM, Dave Crocker > wrote: > > Claiming that something is mandatory, as part of a version bump, is > meaningless, when the installed base will be using the older version and > ignoring the supposedly-mandatory new feature. > > If the installed base can legally ignore a new feature, then it is not > mandatory. > > > I think there's possibly an issue with terminology here. > > In DKIM v1, a verifier that sees a tag it doesn't understand simply > ignores the tag and continues processing the signature. There are no > "mandatory" tags other than the few without which a signature can't be > evaluated at all (h, b, bh, d, s, c, and a come to mind). Right. > Something > using, for example, the ones defined in RFC6541 or RFC6651, won't > prevent verification by a verifier that doesn't implement those. > > In the proposed DKIM v2, a verifier that sees a tag prefixed with "!" > that it doesn't understand has to fail the signature without further > processing. It's not mandatory that the tag be present, but it is > mandatory that the verifier has to do something with it or fail. The > "mandatory" describes the handling of the tag, not its presence. Understood. However this does not change my point at all. The language you are using dictates mandatory behavior by the signature validation engine. But it is not really mandatory, since no legacy engine will understand it. Rather, they will ignore it. Being allowed to ignore a parameter means that the parameter is optional, not mandatory. Or it means that you folk are using the term 'mandatory' in a way I've never encountered before and really don't understand. > A v1 verifier would also ignore a v2 signature. I had not noticed -- and still don't quite understand -- what it is about the new stuff that will cause a legacy engine to fail the signature validation. Yes, I see that it will ignore all the !* new stuff, but that doesn't mean it will fail the evaluation. However to the extent that v1 engine evaluation failure is a target outcome, that merely further underscores my point that you are creating a new and incompatible protocol. The way to signal that is at the entry point to the evaluation engine, not buried amidst the parameters given to it. The entry point is the header-field name. At base, the spec defines a meta-syntax that appears to entirely miss the point of creating signer/validator (or any producer/consumer) compatibility. The challenge in getting a consumer to process new, mandatory fields is not syntax. It's semantics. And once you get the consumer to understand the semantics, you don't need the meta-syntax. > The only way to make a feature mandatory in a new version is to provide > it in a fashion that makes it only available to folks adhering to the > new set of mandatory features.[*] > > > Doesn't this do that? No. Legacy engines will see it ignore it. That does not match the 'mandatory' semantic being asserted in this spec. > > FWIW, this is equivalent to saying that adding new > mandatory features is equivalent to creating a new > protocol. > > So if you want to modify DKIM to change the set of mandatory features, > then specify that the signature use a /different header field name/, > such as DKIM-Signature2. Only adherents to the new scheme will see > this. > > > Isn't it true that we've found all current DKIM implementations would > ignore a "v=2" signature? If so, I'm not understanding the distinction > between "DKIM-Signature: v=2; ..." and a wholly different field name. Ignoring v=2 is not the issue. Ignoring the other, new and supposedly mandatory parameters is the issue. > If the signer wants legacy folk who only understand older DKIM to also > be able to evaluate a signature, then the signer needs to create two > signatures. > > > It could do a v=1 and a v=2, certainly. In fact in the instant > proposal, that's actually necessary. Which DKIM engine should I apply? v1 or v2? That gets answered at dispatch time with header field name. It gets answered after that with the version number model. And a legacy engine will incorrectly process the v=2 signature as if it were v=1. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Oct 3 18:26:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636DC1B2DE2 for ; Sat, 3 Oct 2015 18:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 jdMutdvRv_pa for ; Sat, 3 Oct 2015 18:26:17 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D46A1B2DE1 for ; Sat, 3 Oct 2015 18:26:17 -0700 (PDT) Received: (qmail 20144 invoked from network); 4 Oct 2015 01:26:16 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Oct 2015 01:26:16 -0000 Date: 4 Oct 2015 01:25:53 -0000 Message-ID: <20151004012553.15478.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <56107159.8040404@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] versioning in draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 01:26:18 -0000 >1. I wasn't recommending making the new feature optional. Merely >noting the considerable benefit that accrues if you can live with it >being optional. You might want to reread my draft, because this discussion has no relationship I can see to anything it says. The DKIM spec says a signature is valid if a list of things are true, e.g, the hash of the message's body matches the bh= value. But since the spec says that unknown tags are ignored, there's no way that you can add a new tag that adds a new condition to the existing ones. All you can add are tags that are comments. You could hypothetically add a tag that would make an otherwise invalid signature good, e.g., here's another place to look for the key, but that seems to me like a bad idea and nobody I know has done it. What I want to do is add new optional conditions, this signature is only good if all of the normal things are true, and these other things are true, too. Someone (not me) had the bright idea to use an indicator, currently an exclamation point, to say that a tag adds a new condition, so the verifier fails if it can't check all the tags with that indicator, and we can add more condition tags later without another version bump. But now the syntax has changed, so if a signature uses the new kind of tag, it has to be a v=2 signature. If a signature doesn't, it's still v=1, so everything that used to work still works. If an old verifier sees a v=2 tag it'll fail, so this fails closed. This is about this simplest version of upward compatibility I can imagine. You could do a hack to put this in an otherwise invalid v=1 signature, e.g., put the body hash in a bh2= field and omit the bh= so only a verifier that knows about bh2 will succeed, but why bother? It's ugly and would work in exactly the same places that v=2 does. R's, John From nobody Sat Oct 3 18:36:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3A1B2DEC for ; Sat, 3 Oct 2015 18:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 5-JgH5kd3rKf for ; Sat, 3 Oct 2015 18:36:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1801B2DEB for ; Sat, 3 Oct 2015 18:35:59 -0700 (PDT) Received: (qmail 21259 invoked from network); 4 Oct 2015 01:35:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Oct 2015 01:35:59 -0000 Date: 4 Oct 2015 01:35:36 -0000 Message-ID: <20151004013536.15543.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <56107AC6.4020007@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 01:36:01 -0000 >I had not noticed -- and still don't quite understand -- what it is >about the new stuff that will cause a legacy engine to fail the >signature validation. It's in section 3.5 of RFC 6376, the part about the DKIM-Signature header, where it says: v= Version (plain-text; REQUIRED). This tag defines the version of this specification that applies to the signature record. It MUST have the value "1" for implementations compliant with this version of DKIM. ABNF: sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT INFORMATIVE NOTE: DKIM-Signature version numbers may increase arithmetically as new versions of this specification are released. People have looked at the code in most existing DKIM verifiers to see whether the code matches the spec, and the current code does indeed reject signatures that don't start with v=1. R's, John From nobody Sat Oct 3 18:59:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81C81B2E49 for ; Sat, 3 Oct 2015 18:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 vP8dIwfxD3hd for ; Sat, 3 Oct 2015 18:59:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46FD1B2E48 for ; Sat, 3 Oct 2015 18:59:28 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t941xS18027399 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 3 Oct 2015 18:59:28 -0700 References: <20151004013536.15543.qmail@ary.lan> To: John Levine From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <561087FC.2060308@dcrocker.net> Date: Sat, 3 Oct 2015 18:59:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151004013536.15543.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 03 Oct 2015 18:59:28 -0700 (PDT) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 01:59:30 -0000 On 10/3/2015 6:35 PM, John Levine wrote: > People have looked at the code in most existing DKIM verifiers to see > whether the code matches the spec, and the current code does indeed > reject signatures that don't start with v=1. Yeah, and what's interesting about that is that the spec does not explicitly specify that signatures without a v=1 need to be failed. And you said 'most', not 'all'. Anyhow this wasn't the primary focus of my comments and you haven't responded to those. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Oct 3 19:36:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1B1B2EAA for ; Sat, 3 Oct 2015 19:36:08 -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, SPF_PASS=-0.001] autolearn=ham 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 M0SMfCN9AQj5 for ; Sat, 3 Oct 2015 19:36:06 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B361A070E for ; Sat, 3 Oct 2015 19:36:06 -0700 (PDT) Received: by qkbi190 with SMTP id i190so37417317qkb.1 for ; Sat, 03 Oct 2015 19:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+/RDPPzNTyWzV/CImYJJwnKXxxo+hWWoTwSSQ+u6Mls=; b=WIB/hQxL26tnzmR6nt5j1YI0+mMBgzGq5YA4zl2r7/pETrl/+JLU4G1l8HEnEBV+S5 oxIOpS1bqiXvliKhMWTasT96NgLPa92IZjNl3r8NV1WAbcBiQdh7zFCjAme0PvnYFUBd 1jKEX3QxeJDfr3x22uXKSuBgcAhQY3xtxaEJadsH4okao4kyhDDc0iZ22hqofEpLrXZ8 zQ+ZPnkd6wkj5sc0r8+HYuNEaPLhmAZQGoRCIM3bwPBgi6bNFp7WVkOmpP3C780Uql8E aYxJxhbFy/xcAfAlEp3GobG0lnwBF/6qIj+nioy+RFCdKq9Ik29QzLz+eiuj8vUy+Zd6 gcUQ== MIME-Version: 1.0 X-Received: by 10.55.26.14 with SMTP id a14mr21409637qka.99.1443926165191; Sat, 03 Oct 2015 19:36:05 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Sat, 3 Oct 2015 19:36:05 -0700 (PDT) In-Reply-To: <56107AC6.4020007@dcrocker.net> References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> <56107AC6.4020007@dcrocker.net> Date: Sat, 3 Oct 2015 19:36:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11471d9028809705213e42da Archived-At: Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 02:36:08 -0000 --001a11471d9028809705213e42da Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 6:03 PM, Dave Crocker wrote: > > Something > > using, for example, the ones defined in RFC6541 or RFC6651, won't > > prevent verification by a verifier that doesn't implement those. > > > > In the proposed DKIM v2, a verifier that sees a tag prefixed with "!" > > that it doesn't understand has to fail the signature without further > > processing. It's not mandatory that the tag be present, but it is > > mandatory that the verifier has to do something with it or fail. The > > "mandatory" describes the handling of the tag, not its presence. > > Understood. However this does not change my point at all. The language > you are using dictates mandatory behavior by the signature validation > engine. > Specifically, by a signature validation engine that understands v=2 signatures. A v=1-only engine (i.e., the deployed base) is not expected to change. > But it is not really mandatory, since no legacy engine will understand > it. Rather, they will ignore it. Specifically, they ignore the entire signature, not just the new tag. Being allowed to ignore a parameter > means that the parameter is optional, not mandatory. Or it means that > you folk are using the term 'mandatory' in a way I've never encountered > before and really don't understand. > I think "mandatory" applies only to new implementations that support the new "v=2". > > A v1 verifier would also ignore a v2 signature. > > I had not noticed -- and still don't quite understand -- what it is > about the new stuff that will cause a legacy engine to fail the > signature validation. Yes, I see that it will ignore all the !* new > stuff, but that doesn't mean it will fail the evaluation. > As John pointed out, RFC6376 requires that the signature not pass for any "v=" value other than 1. It won't even get as far as considering the "!" tags. He said "most" implementations he checked will conform to that. I thought it was "all"; perhaps he'd care to elaborate. > The only way to make a feature mandatory in a new version is to > provide > > it in a fashion that makes it only available to folks adhering to the > > new set of mandatory features.[*] > > > > Doesn't this do that? > > No. Legacy engines will see it ignore it. That does not match the > 'mandatory' semantic being asserted in this spec. > "Mandatory" in this context has nothing to do with legacy engines. The only "mandatory" that applies to them is that they will not pass a "v=2" signature. > Isn't it true that we've found all current DKIM implementations would > > ignore a "v=2" signature? If so, I'm not understanding the distinction > > between "DKIM-Signature: v=2; ..." and a wholly different field name. > > Ignoring v=2 is not the issue. Ignoring the other, new and supposedly > mandatory parameters is the issue. > I think it's a core part of the issue. If a legacy engine ignores "v=2" signatures, semantics of the mandatory tags are moot to them. > > It could do a v=1 and a v=2, certainly. In fact in the instant > > proposal, that's actually necessary. > > Which DKIM engine should I apply? v1 or v2? > > That gets answered at dispatch time with header field name. It gets > answered after that with the version number model. And a legacy engine > will incorrectly process the v=2 signature as if it were v=1. If it doesn't conform to RFC6376 Section 3.5, yes. So does this reduce to the problem of accommodating deployed non-compliant verifiers? -MSK --001a11471d9028809705213e42da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 3, 2015 at 6:03 PM, Dave Crocker <dhc@dcrocker= .net> wrote:
> Something
> using, for example, the ones defined in RFC6541 or RFC6651, won't<= br> > prevent verification by a verifier that doesn't implement those. >
> In the proposed DKIM v2, a verifier that sees a tag prefixed with &quo= t;!"
> that it doesn't understand has to fail the signature without furth= er
> processing.=C2=A0 It's not mandatory that the tag be present, but = it is
> mandatory that the verifier has to do something with it or fail.=C2=A0= The
> "mandatory" describes the handling of the tag, not its prese= nce.

Understood.=C2=A0 However this does not change my point at all.=C2= =A0 The language
you are using dictates mandatory behavior by the signature validation
engine.

Specifically, by a signature va= lidation engine that understands v=3D2 signatures.=C2=A0 A v=3D1-only engin= e (i.e., the deployed base) is not expected to change.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> But it is not really mandatory, since no legacy engine will understand
it.=C2=A0 Rather, they will ignore it.

Spec= ifically, they ignore the entire signature, not just the new tag.

=C2=A0 Being allowed to ignore a paramet= er
means that the parameter is optional, not mandatory.=C2=A0 Or it means that=
you folk are using the term 'mandatory' in a way I've never enc= ountered
before and really don't understand.

I think "mandatory" applies only to new implementations that sup= port the new "v=3D2".
=C2=A0
> A v1 verifier would also ignore a v2 signature.

I had not noticed -- and still don't quite understand -- what it= is
about the new stuff that will cause a legacy engine to fail the
signature validation.=C2=A0 Yes, I see that it will ignore all the !* new stuff, but that doesn't mean it will fail the evaluation.

As John pointed out, RFC6376 requires that the signa= ture not pass for any "v=3D" value other than 1.=C2=A0 It won'= ;t even get as far as considering the "!" tags.

He said "most" implementations he checked will conform to that.= =C2=A0 I thought it was "all"; perhaps he'd care to elaborate= .

>=C2=A0 =C2=A0 =C2=A0The only way to make a feature man= datory in a new version is to provide
>=C2=A0 =C2=A0 =C2=A0it in a fashion that makes it only available to fol= ks adhering to the
>=C2=A0 =C2=A0 =C2=A0new set of mandatory features.[*]
>
> Doesn't this do that?

No.=C2=A0 Legacy engines will see it ignore it.=C2=A0 That does not = match the
'mandatory' semantic being asserted in this spec.
<= div>
"Mandatory" in this context has nothing to do = with legacy engines.=C2=A0 The only "mandatory" that applies to t= hem is that they will not pass a "v=3D2" signature.

=
> Isn't it true that we've found all current DK= IM implementations would
> ignore a "v=3D2" signature?=C2=A0 If so, I'm not underst= anding the distinction
> between "DKIM-Signature: v=3D2; ..." and a wholly different = field name.

Ignoring v=3D2 is not the issue.=C2=A0 Ignoring the other, new and s= upposedly
mandatory parameters is the issue.

I th= ink it's a core part of the issue.=C2=A0 If a legacy engine ignores &qu= ot;v=3D2" signatures, semantics of the mandatory tags are moot to them= .
=C2=A0
> It could do a v=3D1 and a v=3D2, certainly.=C2=A0 In = fact in the instant
> proposal, that's actually necessary.

Which DKIM engine should I apply?=C2=A0 v1 or v2?

That gets answered at dispatch time with header field name.=C2=A0 It gets answered after that with the version number model.=C2=A0 And a legacy engin= e
will incorrectly process the v=3D2 signature as if it were v=3D1.

If it doesn't conform to RFC6376 Section 3.5, yes.=C2= =A0 So does this reduce to the problem of accommodating deployed non-compli= ant verifiers?

-MSK
--001a11471d9028809705213e42da-- From nobody Sat Oct 3 19:39:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3D1B2EB5 for ; Sat, 3 Oct 2015 19:38:59 -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, SPF_PASS=-0.001] autolearn=ham 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 e6t79uFu5B0Y for ; Sat, 3 Oct 2015 19:38:58 -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 3BA381A6FC4 for ; Sat, 3 Oct 2015 19:38:58 -0700 (PDT) Received: by qkas79 with SMTP id s79so57646416qka.0 for ; Sat, 03 Oct 2015 19:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yypvBEsLWcJ/UokwMBhz9wToQ6ULPolxhcXTlMppWRU=; b=dD19FMoIEjX9NXz8eAfmSA3lyFL7m90R9Z23lE8jkZS7/L1dopdT/92jvh81zjVX56 8x3bbFKJSt8VkZF8D7eU/29iV6YjI+JPgRmDzfbQDMan0pacN10BFBmYBZ9YgPcx/8C2 cyqdw+A3axQpR163nnbN3H07c9dhfiiCo0EMQdftNsFtmNQC4GHTZGcFh1cDTFBz2hHS reJu66lLahgws98ihJYDbm9lz8vgSzqCyz7ZrNkmrOV3a/zn9DkTDEGFFeNOU/ZVGLHD dgbNjIi+bpYasqXZkXred5hHO8JJ5HQOoIAfbOg+y9J4FMdypCroMfZ0zrxatZPSixgE Gpyw== MIME-Version: 1.0 X-Received: by 10.55.42.141 with SMTP id q13mr29906690qkq.48.1443926337423; Sat, 03 Oct 2015 19:38:57 -0700 (PDT) Received: by 10.55.198.11 with HTTP; Sat, 3 Oct 2015 19:38:57 -0700 (PDT) In-Reply-To: <561087FC.2060308@dcrocker.net> References: <20151004013536.15543.qmail@ary.lan> <561087FC.2060308@dcrocker.net> Date: Sat, 3 Oct 2015 19:38:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11493ef66c8fe705213e4c53 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 02:38:59 -0000 --001a11493ef66c8fe705213e4c53 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 6:59 PM, Dave Crocker wrote: > Yeah, and what's interesting about that is that the spec does not > explicitly specify that signatures without a v=1 need to be failed. > I believe Section 6.1.1, first paragraph, has that covered. -MSK --001a11493ef66c8fe705213e4c53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 3, 2015 at 6:59 PM, Dave Crocker <dhc@dcrocker= .net> wrote:
Yeah, and what's interesting ab= out that is that the spec does not
explicitly specify that signatures without a v=3D1 need to be failed.

I believe Section 6.1.1, first paragraph, ha= s that covered.

-MSK
--001a11493ef66c8fe705213e4c53-- From nobody Sun Oct 4 08:35:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5898E1B29B8 for ; Sun, 4 Oct 2015 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 QWbstHdFkWnk for ; Sun, 4 Oct 2015 08:35:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325761B29B5 for ; Sun, 4 Oct 2015 08:35:19 -0700 (PDT) Received: (qmail 27979 invoked from network); 4 Oct 2015 15:35:19 -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=6d4a.56114737.k1510; bh=Sy35+5glu1tt6oIH6AvFIgACUZRni+6DrGSw3Qmpbzw=; b=u7UbCcPle3KqKLgCf+xRURZcAQ00/pMspch57Xj9Y2fq7LsbUptMpysF340JUjfqHObI83fA33eThRp/AXcdPF82amroVF/euTnb/Tt/ZRJaGdGiojO0WSwJ7crumAxYkZhhMihEXMb6iQQmledCNsP1yKHoEP4cB9CqNpZIxXs/iLLP9P1jYMlMHWpcjkNMxDOxeK4LwUx8Jmo2Au8Cwit5onY0OygkNqrxQ9UPOq2CE4c8jq7+YvgJNtMxUZ7k 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=6d4a.56114737.k1510; bh=Sy35+5glu1tt6oIH6AvFIgACUZRni+6DrGSw3Qmpbzw=; b=jVWi/dfjBIrL3JWsbtnxB8X2/ZkMnhIbnz7tlwYDCC2cJ8dW1noX7rMtOJCXGIClchgwzx7pww5bhdERFhj9lDMWgSESJoG+FIhfttsYCGk21B1mf2CRxN8EDR91mK5Z+ZWeIShdTdYdrGsY72yoGQvFtgHPM0UGgaKpjquFr1GIEyv2il8Ehp+PXKaLEI4YTwia2426lZZ18ZeP6H2P1LXkJpyn3G7DbJ1Q7MuUVfYB0C8r0gA5JjDsl6mF/ykX 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.0/X.509/SHA1) via TCP6; 04 Oct 2015 15:35:19 -0000 Date: 4 Oct 2015 11:35:18 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> <56107AC6.4020007@dcrocker.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 04 Oct 2015 15:35:21 -0000 > As John pointed out, RFC6376 requires that the signature not pass for any > "v=" value other than 1. It won't even get as far as considering the "!" > tags. > > He said "most" implementations he checked will conform to that. I thought > it was "all"; perhaps he'd care to elaborate. All the ones that anyone has checked. Since the code for places like Hotmail isn't available, you'd have to send them some v=2 signatures and see what happens. I haven't done that, although I'd be pretty surprised if they interpreted the spec differently from everyone else. R's, John From nobody Thu Oct 8 13:29:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F31ACD5E for ; Thu, 8 Oct 2015 13:29:49 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rvMw28-igaO4 for ; Thu, 8 Oct 2015 13:29:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D681ACD5D for ; Thu, 8 Oct 2015 13:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x9NKZIWZnFu5Q7m+rmRYbMBFGnhTYRTNkdFGjQieApc=; b=RSeicvEAWMgJLvEM970EYvf4pc84Ujs9MMUofiKOFLohsSg/noziz4bdzH4ZbnkX0ETnGcqRUjxxO+jM9xqsn4sI8Wq+ZOM0yzYmVYkbRDbqj1n5wuXLhY1ONYLL4O0I5c3OBZRbLwWIpzeC8c4nWtNFDasHOZfld2EWbpNzpOU= Received: from DM2PR03CA0048.namprd03.prod.outlook.com (10.141.96.47) by BY2PR0301MB0744.namprd03.prod.outlook.com (10.160.63.22) with Microsoft SMTP Server (TLS) id 15.1.280.20; Thu, 8 Oct 2015 20:29:24 +0000 Received: from BY2FFO11FD021.protection.gbl (2a01:111:f400:7c0c::185) by DM2PR03CA0048.outlook.office365.com (2a01:111:e400:2428::47) with Microsoft SMTP Server (TLS) id 15.1.293.16 via Frontend Transport; Thu, 8 Oct 2015 20:29:23 +0000 Authentication-Results: spf=softfail (sender IP is 23.103.249.52) smtp.mailfrom=exchange.microsoft.com; taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=fail action=none header.from=exchange.microsoft.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning exchange.microsoft.com discourages use of 23.103.249.52 as permitted sender) Received: from dedicated.microsoft.com (23.103.249.52) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.1.293.9 via Frontend Transport; Thu, 8 Oct 2015 20:29:22 +0000 Received: from CH1SR9901MB0060.001d.mgd.msft.net (141.251.196.216) by CH1SR9901MB0058.001d.mgd.msft.net (141.251.196.214) with Microsoft SMTP Server (TLS) id 15.1.306.1; Thu, 8 Oct 2015 20:29:21 +0000 Received: from CH1SR9901MB0060.001d.mgd.msft.net ([141.251.196.216]) by CH1SR9901MB0060.001d.mgd.msft.net ([141.251.196.216]) with mapi id 15.01.0306.003; Thu, 8 Oct 2015 20:29:21 +0000 From: Terry Zink To: John R Levine , "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] draft-levine-dkim-conditional-02 Thread-Index: AQHQ+tmnQoncwV1Q6EebPjlbzRaVbZ5YJT2AgAAmDQCAANH9gIAA6WcAgABvzACAAAmVAIAACxMAgAAaAICAANm2AIAGmxDw Date: Thu, 8 Oct 2015 20:29:20 +0000 Message-ID: <5a216ac4f2f5422db104d6d862bbcba4@CH1SR9901MB0060.001d.mgd.msft.net> References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> <56107AC6.4020007@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.18.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1SR9901MB0058.001d.mgd.msft.net X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD021; 1:hBUIjNPP7+IyRwA8+o04gFe5a6o3nsk54JkrYDilOFBCIOfk//P9FlIaCeXnboEsoQNmKh9vKNsIaFB6H5Xn4WKAqwsfmPbF2vzhw74KoJM03YWS1kKKH82/rbwjWozAVElFUaKNIyYfuKqOUGc6Hqv/V6SA/SW0Owmyo5WegkjBxSkfhmJA0zipzqYvnEFd+aSsdK99ux+PaxDak6z6pE0lFqtynQZC6bGzaCyExIaUCOeXuybl1gfFFF6G06a7bB9L+/hfsX0Gcm1QunbHBLtv8EshAaXi1aBmNu1pKpGilukw0jUeya6OH+8kY48Y3+ZXSndqRcyn9Vx+a5u2Jg== X-Forefront-Antispam-Report: CIP:23.103.249.52; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(377454003)(189002)(13464003)(199003)(93886004)(108616004)(102836002)(15975445007)(19580405001)(19580395003)(86146001)(87936001)(5005710100001)(230783001)(10090500001)(33646002)(10290500002)(10400500002)(50466002)(69596002)(97736004)(97756001)(5001770100001)(16796002)(86362001)(106466001)(81156007)(54356999)(50986999)(106116001)(76176999)(46102003)(46406003)(5007970100001)(2900100001)(5004730100002)(92566002)(11100500001)(6806005)(2950100001)(23726002)(66066001)(105596002)(64706001)(24736003)(5008740100001)(5003600100002)(5001920100001)(5001960100002)(189998001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0744; H:dedicated.microsoft.com; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-CrossPremisesHeadersPromoted: BY2FFO11FD021.protection.gbl X-CrossPremisesHeadersFiltered: BY2FFO11FD021.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 2:Vqx0wFF/dtqqUpZhQWk08fox+5rfMg4LAVTwMCumAhFQM/rA2cjGvODYS2Ax3ZYMm/MxWfe/VGVYyVODePyuTiADRd6HWUBIj4+aqtj9DMYjYJtEWgEmZfA4bXZ9WRfqhOruHil36vPocuYewk/uzoAZUKtJOPPMLalvUW+aSDg=; 3:7yj0KLyQ7CRE1wEgEM/hSZNG0Q98voBNcteUgFrioW6yftaX31DQfkIJvj4DMLVJfwT0Hu1cU9/JLmYs+zS+bFt/JhblR4umZBSUAIJJygHHOpUiDcdcwf6jFQA05d6h4dohLlnOHy0LsBl7ZjHQZMWTgf5kTD7vpeg1mNd+RGSyR+kV99Rfl3Lf4l6h1IHkan6Af1Tq5uOVKsLCSmhtfHTMqGpFllxXVoY0QhHm59k=; 25:CPakyGxiY26pVT9V8mtb3y3Pbao3jCompih14P2BqkQDUFLH7+a0eWEDl4AUE61Y2H8qQ0WM/S+b8z/ViBnquW0excTxPc3q6wIH4DORMdqnrVn75ldszF1QQxWnkNNRV2bD1nazqU7ah0U1uMRqYclcnxG3qbZwkMGB13ZPgAXGMYdkn/x9k+YDIsxFKSlsrCr9vWvQtw3ruOPwLrwrrqZadtwng/CodF7uTnyWS7dbDQzaXlmuM0uG70fjwXOH6QpAz6bLwoP7iQAPDGri/Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0744; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 20:N2FqAtoARoKGlIdyOWD6cKAg9zLzUxs/6kYr7kT/YuTs5km0BHh2Rzp3XrUyymBnGg8KEdysfi9hAe0hE1rzKUvp7vgsXPhOA0CpS9NiTsrFgf06Xg0ekF1aY6vLzuptOuDdmUO370+Rs6VZRF+4hKcAxfIJS8D+elWjAeJbI94ZS9Xrry7sivFZ0eWaCrtfhL7zSM9u7ZS6OaNKVfDymcvs/n8mrToje8BuDnhU5Ch+ia8Q2zRPTjDNBnvK2oAl8S6oxGJTjAjr5NAoXEopEgnBqSbMdRRPbABH0SrEq0BMh191/z1ZejVVxLtXHPWUbhga4uVL3usZyxYR0zVeT9NHaZ1vHw2N7s8Imz8obUgym2q9euDfHO6G0cCsZk//0vteE4yZHFZ3VwxPrr7DaI+LmgPukcANew3viHt+KX4/nxst8mbIyhmuapxwe2tg9f2OiMIuq+sBwRhaI9uAMyl9IByed90JVDCyvPjSVu/FnSIhDWERv9ED7Z9Kg1gD; 4:+GNIKDIYllIfHLcsX8r7CVzuF7dG8wGBIEbSA8LDtF3AH9TMEG7hr+wcQu+DIIqwv7U1hBFDoarOgX3YtUW9q4JampyFMxEnrrKT8p17M3VC7AsS8BJtRLb2y7HCH5qzlcFi+ZzZYqSRrhT5ORBxXQfSGjux2s/u1QzIhZVxSbMudHhjMgwmVtToQqb5oUQSuzbnZ6z2Z+xy+2E9mv5H+RjbB54h5II72qj65+6gs5A1QDTSbOXFyhcpjTelq/xKzVVXDb1FD6BfGlfjCp0GXvEnVXIaKAgjus/KpwjMwArqb9pCnay1o4d1iNwnBCFXkdssKv2MWVMCkchLVH1cLO+whdIphARYOCslV+67BKGw385piP9XdJRHhWv7biJ1+cScF5Y1CxCOOfA/63XiGz/jh0ZVeuaUxh6RO5azabw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(61426024)(61427024); SRVR:BY2PR0301MB0744; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0744; X-Forefront-PRVS: 0723A02764 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0301MB0744; 23:BWhLgWnZltnEn7Hlc3q4ZlExfYMltqTnkbJ7vTU?= =?us-ascii?Q?4dTG9FQkV6yAdzVHYbsgcP4mlQKTtyYZYKaMjhUiwDEWJGLTKVRyFOiu7hDz?= =?us-ascii?Q?24TiSzeN6XM4opQyZQ7q2+uNFghViJd+BuFcSkRO5hHLYgMUU0Q3s7zLu/cr?= =?us-ascii?Q?n7mfxWIIzUjDovCmlYHiZ3A4jNZ3KvC4VEJdSxPm46pdr8TaPavvcN0eXgec?= =?us-ascii?Q?8szDwPVQqJpQ8q6MebdGl3A3hgvOSlAyQBVQLZWquooDvggOZIwY8MuSjLt8?= =?us-ascii?Q?igBtQX63HhnpBz7STqGLnMkC6nRpxN3tpRg1sKjB3/+m5JlOVxHDe9GomrL1?= =?us-ascii?Q?bzAHuzBRzmXdJakZN8XVKrr526sLJfp4tUVHlNFQqTFNizbNbx64lT7oXoS0?= =?us-ascii?Q?cMIT5BokcM1gSg6OS12MoSDx9Np6DTvm0SvQX+maSL8mfVT37PjB8hn/4oRG?= =?us-ascii?Q?I85EGWFPgiYJXYusMRT9D7xxLtWy9MSwkywXUMJbg3Niey8dxKmwgiHgADk3?= =?us-ascii?Q?2SbkrC/S1c4XaQpEQ7JeVFfIjgfEnQKRNrd9gKYg/JlssT735FLkIgt0L6rT?= =?us-ascii?Q?8cANFv4VDeecjXLyRax+G/E3HiqxVFWOz5xlzQA+Z4g1lkvQz/majm68Od9j?= =?us-ascii?Q?WW/oAqOJcITql5bO+QkehUV7DoL8EUPQVasxA1afqtpBW5w00GN/VZ6dAkc+?= =?us-ascii?Q?fWpa5xp13U0PaO0FaaVvJEvX4fQRDFjj1/odmQdakJRa5Jq94CvEsHIr+jqi?= =?us-ascii?Q?umHbnMcYiRCPYAo6Ixs9PciMH+MkjH0Tp2ZqNazImnz+oha5+jKiJGw5iYeW?= =?us-ascii?Q?WflMGylcunXtyGZ3NiCvDDJq39xV3LqoUBCFWp0DEEDENtQNt0y9YurgGmex?= =?us-ascii?Q?j6u2HNd7yArJr3JphyHu1qlXPZKzeX2z13f3MqeMCU0kheC15aD0uj8fVgPH?= =?us-ascii?Q?dx6XdNzRz+XB4VGSw2Nyie8aLBq1RpJ7w4AGCA6edKaCYVPo9UcqNtjn3JrO?= =?us-ascii?Q?T30rg6OrOcbEcDXAA47/5J6j/aaushvTdX6RxcCiBHgUp2TgNQbJTq2lPbub?= =?us-ascii?Q?xxbU0EXsrIslcXineSC/zgK2y7P8HQExmOxXwHP2xtt2kinOadcah1rsasB7?= =?us-ascii?Q?+wWABjW4ltFyGk0FZQIrW1hz1TuvuL5A3QNPnlUn4rxAOCwjk35Zc8Q8AhDh?= =?us-ascii?Q?LiG6y5Mwi+QkY0cccYeQYp8kiD9IpLv6IdTplgPs1alGlZt73hnr/bhJ6Nlz?= =?us-ascii?Q?L2TaOU/L9tHBUGCDXHcBCa+lcZBq4exaFsBBJeKiRuMHfTKpH4luv6RfqJvz?= =?us-ascii?Q?tWSmVn38UH8R6T5PvXZ3hskI8BQqEvjAt07ztlxU38Pk6/c8IJQxZtv0Kf01?= =?us-ascii?Q?tG1xvLTQ1U+9Jx4KtsBAVq0AcyDND8TExIrHEFNyyX5AAy6gLRHevhA4kn4+?= =?us-ascii?Q?exVaH/aUND3lO0ch4Odc5HPHdx2IZgKQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0744; 5:A/69+K3cWlUshYaSrXpqc6BR8DQKOzXzhRn38WUd1n9WpK01jsGIBUkgE5vXCIZooMA2rYj8mtiupTshsb8grHppVzqz7ycW6TYQLmbUzw2MrgH8ULWTDRi6zuFXmw6Cc2s33FyYbVQHGGT/3YAYYw==; 24:4S2tueEGnyF7EiZUrSkgoKek1Tp4G7stDwRQkDVoG0WhxCkrmYoe2uy8XPxJvJ9i/z/tdciTMfrgVqFlzImXV+qH7dPVrlqctUWESwRu4go= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2015 20:29:22.5862 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[23.103.249.52]; Helo=[dedicated.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0744 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 08 Oct 2015 20:29:49 -0000 I'm not sure what Hotmail does currently, but it won't matter in the long r= un because the email infrastructure is moving over to Office 365. The DKIM = code there will interpret a v=3D2 as an invalid signature. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John R Levine Sent: Sunday, October 4, 2015 8:35 AM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 > As John pointed out, RFC6376 requires that the signature not pass for any > "v=3D" value other than 1. It won't even get as far as considering the "= !" > tags. > > He said "most" implementations he checked will conform to that. I though= t > it was "all"; perhaps he'd care to elaborate. All the ones that anyone has checked. Since the code for places like=20 Hotmail isn't available, you'd have to send them some v=3D2 signatures and= =20 see what happens. I haven't done that, although I'd be pretty surprised=20 if they interpreted the spec differently from everyone else. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Oct 14 14:22:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D581A8983 for ; Wed, 14 Oct 2015 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 10yNtE2D0ooP for ; Wed, 14 Oct 2015 14:21:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0341A8992 for ; Wed, 14 Oct 2015 14:21:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PRWKUD4E00015OVJ@mauve.mrochek.com> for dmarc@ietf.org; Wed, 14 Oct 2015 14:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1444857406; bh=GGy8hZzuBk6+ChDaHZZNJqsiVslGtdJKKMd4RZwpjOE=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=jVQo3J3vbD4+FfFQrefGxFgx3MdNPOaErGb9ICWdGGpJjakN/EKn1PAwe3zUzvul4 ppKdIL417MlKlthDzNl9kwoExXkm0rq+TPgnPEIUM7PWxMr0NULAhd/W6VLoHJm5Al I6KFgQXj1mTC906VhH0gSArL1HyaTvz/7gkqXXgI= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PRWF2HJBWW01729W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 14 Oct 2015 14:16:43 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PRWKUBNAZQ01729W@mauve.mrochek.com> Date: Wed, 14 Oct 2015 14:04:36 -0700 (PDT) In-reply-to: "Your message dated Sat, 03 Oct 2015 16:49:06 -0700" <56106972.4090707@dcrocker.net> References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> To: Dave Crocker Archived-At: Cc: "Murray S. Kucherawy" , "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 14 Oct 2015 21:21:57 -0000 Responding to this late, but I think there are some important points not previously covered. > On 10/3/2015 10:08 AM, John R Levine wrote: > > I suppose the version bump to v=2 is an open issue, but I don't really > > see what the problem is. Since the current spec says that unknown tags > > are ignored, there's no way to add mandatory tags without a version > > bump. I believe when this came up before, people looked at common DKIM > > libraries including yours, the perl and python ones, and found that the > > current code would all fail a v=2 signature, so the version bump should > > do what we want it to. > Claiming that something is mandatory, as part of a version bump, is > meaningless, when the installed base will be using the older version and > ignoring the supposedly-mandatory new feature. There's always a context to terms like "mandatory". In this case the context is that of v2 signatures. The term is hardly meaningless in that context. > If the installed base can legally ignore a new feature, then it is not > mandatory. The nature of DKIM is such that many signatures end up getting ignored as part of normal operation. That doesn't make any aspect of the various mandatory aspects of processing those signatures any less mandatory. > The only way to make a feature mandatory in a new version is to provide > it in a fashion that makes it only available to folks adhering to the > new set of mandatory features.[*] > FWIW, this is equivalent to saying that adding new > mandatory features is equivalent to creating a new > protocol. I suppose you can define it that way if you like, but doing so ignores the substantive overlap both in terms of syntax, processing semantics, and most important of call, usage. > So if you want to modify DKIM to change the set of mandatory features, > then specify that the signature use a /different header field name/, > such as DKIM-Signature2. Only adherents to the new scheme will see this. This approach has the significant downside that it's more costly in terms of code. Not a lot more costly, and if John's proposal had significant associated cost I'd say it's a wash. But John's proposal isn't costly at all. As a result I'd say that of using a different header versus building off existing version suport just about doubles the complexity. Given this, I need significant to see significant justification - such as reports that existing implementations don't properly handle DKIM versions - before I will support a proposal to use a different field. Such reports have not appeared AFAIK. > If the signer wants legacy folk who only understand older DKIM to also > be able to evaluate a signature, then the signer needs to create two > signatures. That's not an argument for using a different field. Ned From nobody Thu Oct 15 10:16:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4A1ACD68 for ; Thu, 15 Oct 2015 10:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.379 X-Spam-Level: X-Spam-Status: No, score=-98.379 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 zp9mpKGbgxhu for ; Thu, 15 Oct 2015 10:16:37 -0700 (PDT) Received: from ftp.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CC8911ACD5F for ; Thu, 15 Oct 2015 10:16:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2336; t=1444929388; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=pEmAVZsX7ufLKAquhCaEaW59ooQ=; b=auGxwQhQnqeiNhcGKJ6PPm196RTzo/Rx/hHEBGk3ColB5B4urT9dX6d0uHofEh +CjiNHGAVUD3q4AhuvBlgPbFWKjJuG4aAH1bK+w/JPN1pR5y+YdBo+ysVjm2MJGC RKsO8dPaB/o0I+r4CUT2NzG695WsQ8gL3roUTaWXl+cEY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 15 Oct 2015 13:16:28 -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; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1112597492.51046.1092; Thu, 15 Oct 2015 13:16:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2336; t=1444929362; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9DAp5ZD CPF5QoTRhOVN/Px+fG/GobksGbYu82ubau9c=; b=T0jlFmm8DGxdsoc8E7BbOwE iIWM+c6A7QWMmgA5+i06PIYsLOfHz4ReEHg0Gp0cfPKhv1UDTExw6kJIJd0y2Bmk SY8lzimfto8kmH3BrdojIRET2QGSXvkbk29Uj6y21lBzCvDJlAACEKnX+p6E1fCY D+y1YGvVEinv3a2jy5Ts= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 15 Oct 2015 13:16:02 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 51495226.9.35412; Thu, 15 Oct 2015 13:16:01 -0400 Message-ID: <561FDF63.4080603@isdg.net> Date: Thu, 15 Oct 2015 13:16:19 -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: dmarc@ietf.org References: <20150929170849.13962.qmail@ary.lan> <56106972.4090707@dcrocker.net> <01PRWKUBNAZQ01729W@mauve.mrochek.com> In-Reply-To: <01PRWKUBNAZQ01729W@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 15 Oct 2015 17:16:39 -0000 On 10/14/2015 5:04 PM, ned+dmarc@mrochek.com wrote: >> If the installed base can legally ignore a new feature, then it is not >> mandatory. > > The nature of DKIM is such that many signatures end up getting ignored as > part of normal operation. That doesn't make any aspect of the various > mandatory aspects of processing those signatures any less mandatory. Its the same old theory since the original conception -- Only the ones with a policy will have any payoff, the more stronger, the higher the payoff will be. The more relaxed policies are still exploitable making it a high waste and overhead in processing. > >> The only way to make a feature mandatory in a new version is to provide >> it in a fashion that makes it only available to folks adhering to the >> new set of mandatory features.[*] > >> FWIW, this is equivalent to saying that adding new >> mandatory features is equivalent to creating a new >> protocol. > > I suppose you can define it that way if you like, but doing so ignores > the substantive overlap both in terms of syntax, processing semantics, and > most important of call, usage. For my package, we have to modify the C/C++ signing engine. If ALT-N does not make the change, we have to do it ourselves. In any case, any change requirement will allow the opportunity for the drastic changes to be done. So just get it defined correctly. Right now, v2 signatures will fail. Any we also have to change our C/C++ List server code and also our current official release DKIM+ASDP+ATPS based package to a DKIM+DMARC+ATPS. We are not even covering the ATPS part. So I have to clean that mess up too perhaps and somehow tie it into this !FS= v2 thing. I don't understand why if we have to make so many changes, we can just easily get it right with straight policy logic. Look up the 3rd party authorization. We should be allowed the opportunity to open that door now and allow people to explore it. Allowed = 3rdPartyFunction(domain) and that 3rd party function can anything, including !FS and/or a policy lookup. Whatever. If the IETF is going to ask people to change their stuff, lets make it work this time around. Levine proposed ADSP before and it failed. Now he has this !FS= thing. I'm willing to give it one more shot. Thanks. -- HLS From nobody Fri Oct 16 07:41:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D571B2CA9 for ; Fri, 16 Oct 2015 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 j4cWYNqhncvA for ; Fri, 16 Oct 2015 07:41:25 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 0B45E1B2CA3 for ; Fri, 16 Oct 2015 07:41:24 -0700 (PDT) Received: by qgad10 with SMTP id d10so8336706qga.3 for ; Fri, 16 Oct 2015 07:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:date:message-id:subject:from:to:content-type; bh=ULZunXIM/umqtchsLwmcCKABAfoPHg+y6ZKWRpDrg7k=; b=dGszDePRH+dV6JNFjBlCcEL6PO5YozNzJiLBCUZGhKzNAGvLOu518dkmcoxyjK2Z0L lpGiWE8fXFy6Ah5bhoBvntx7dwi/8lVd3bvjgUPMmq/0YVQ9qbThyU174f2SnO6yiiPX nilqX8QUhWrouBhIUH81r5gwHOuBLjOu5hNls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ULZunXIM/umqtchsLwmcCKABAfoPHg+y6ZKWRpDrg7k=; b=Z7Gl9Uym2A/80oO2+WYmj2UDAl0HyyzXHZFL9W7OHJb/XPNmM3ZTqZlHcJ0VRSxgI3 6SOFqdW7hiLfq+2uIBAHLPa4DSMucnokFjaHT1XrijPFLYjFz3RqCi0UKYdCuClydOLK 00TaHIUn3kLzch80GaX/3UrhY5pEAcuVACSBgI1fg5LuVWtUye9wCoNHBiQ1Wuun8oGe e4ytZInYhlcGdf1aXVQ+mYudZro5eT1e1AT7Rra2ExqYtS8xI0MqCcODZx8Z4+LbrA9h dmUkaHR57EjDY0kJIpyxoah+sJvlqTbzKX2DO3Fn1ZmJlhE9yVNhJOQobojs0OT3G7vp 8bPg== X-Gm-Message-State: ALoCoQlhPlMYj9Wl/OORlcB9+XOpYJIdmBzPtR4hvGDC6Tp2Dc3sj4RJB6b9ml/gMOkKCTEWfx0X MIME-Version: 1.0 X-Received: by 10.140.216.211 with SMTP id m202mr20537895qhb.80.1445006484173; Fri, 16 Oct 2015 07:41:24 -0700 (PDT) Received: by 10.55.98.207 with HTTP; Fri, 16 Oct 2015 07:41:24 -0700 (PDT) Date: Fri, 16 Oct 2015 07:41:24 -0700 Message-ID: From: Kurt Andersen To: "dmarc@ietf.org" , arc-discuss@dmarc.org Content-Type: multipart/alternative; boundary=001a1135cf243011ad052239ca8c Archived-At: Subject: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 16 Oct 2015 14:41:26 -0000 --001a1135cf243011ad052239ca8c Content-Type: text/plain; charset=UTF-8 Although not directly submitted to the WG, please take a look at these drafts and send any comments or feedback to arc-discuss@dmarc.org or this list. Name: draft-andersen-arc > Revision: 00 > Title: Authenticated Received Chain (ARC) > Document date: 2015-10-16 > Group: Individual Submission > Pages: 32 > URL: > https://www.ietf.org/internet-drafts/draft-andersen-arc-00.txt > Status: https://datatracker.ietf.org/doc/draft-andersen-arc/ > Htmlized: https://tools.ietf.org/html/draft-andersen-arc-00 > > > Abstract: > Authenticated Received Chain (ARC) permits an organization which is > creating or handling email to indicate their involvement with the > handling process by adding a cryptographicly signed header (or > headers) in a manner analagous to that of DomainKeys Identified Mail > (DKIM). Assertion of responsibility is validated through a > cryptographic signature and by querying the Signer's domain directly > to retrieve the appropriate public key. Changes in the message which > may break DKIM, may be tracked through the ARC set of headers. > and, its accompanying usage recommendations: Name: draft-jones-arc-usage > Revision: 00 > Title: Recommended Usage of the Authenticated Received Chain (ARC) > Document date: 2015-10-16 > Group: Individual Submission > Pages: 15 > URL: > https://www.ietf.org/internet-drafts/draft-jones-arc-usage-00.txt > Status: https://datatracker.ietf.org/doc/draft-jones-arc-usage/ > Htmlized: https://tools.ietf.org/html/draft-jones-arc-usage-00 > > > Abstract: > The Authentication Results Chain (ARC) provides a means to preserve > email authentication results and verify the identity of email message > handlers, each of which participates by inserting certain headers > before passing the message on. But the specification does not > indicate how intermediaries and receivers should interpret or utilize > ARC. This document will provide guidance in these areas. > Will look forward to feedback from any interested parties. --Kurt Andersen --001a1135cf243011ad052239ca8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although not directly submitted to the WG, please take a l= ook at these drafts and send any comments or feedback to arc-discuss@dmarc.org or this list.


Name:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-andersen-arc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticated Received Chain (ARC)=
Document date:=C2=A0 2015-= 10-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-andersen-arc-00.txt<= br> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-andersen-arc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.i= etf.org/html/draft-andersen-arc-00


Abstract:
=C2=A0 =C2=A0Authenticated Received Chain (ARC) permits an organization whi= ch is
=C2=A0 =C2=A0creating or handling email to indicate their involvement with = the
=C2=A0 =C2=A0handling process by adding a cryptographicly signed header (or=
=C2=A0 =C2=A0headers) in a manner analagous to that of DomainKeys Identifie= d Mail
=C2=A0 =C2=A0(DKIM).=C2=A0 Assertion of responsibility is validated through= a
=C2=A0 =C2=A0cryptographic signature and by querying the Signer's domai= n directly
=C2=A0 =C2=A0to retrieve the appropriate public key.=C2=A0 Changes in the m= essage which
=C2=A0 =C2=A0may break DKIM, may be tracked through the ARC set of headers.=

and, its accompanying usage recommendations:

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dr= aft-jones-arc-usage
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Recommended Usage of the Authentic= ated Received Chain (ARC)
Document date:=C2=A0 2015-= 10-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-jones-arc-usage-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-jones-arc-usage/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-jones-arc-usage-00


Abstract:
=C2=A0 =C2=A0The Authentication Results Chain (ARC) provides a means to pre= serve
=C2=A0 =C2=A0email authentication results and verify the identity of email = message
=C2=A0 =C2=A0handlers, each of which participates by inserting certain head= ers
=C2=A0 =C2=A0before passing the message on.=C2=A0 But the specification doe= s not
=C2=A0 =C2=A0indicate how intermediaries and receivers should interpret or = utilize
=C2=A0 =C2=A0ARC.=C2=A0 This document will provide guidance in these areas.=

Will look forward to feedback from any interested parties.

--Kurt Andersen
--001a1135cf243011ad052239ca8c-- From nobody Sat Oct 17 06:07:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335121B2ACB for ; Sat, 17 Oct 2015 06:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E6uXk28lg61g for ; Sat, 17 Oct 2015 06:07:18 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C63AE1AC3CD for ; Sat, 17 Oct 2015 06:07:18 -0700 (PDT) Received: from [192.168.1.13] (unknown [67.58.115.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id BC53ACB46; Sat, 17 Oct 2015 09:06:37 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_577ED149-B5F4-4B22-8BF7-3FB55BDB4D79" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Draegen In-Reply-To: Date: Sat, 17 Oct 2015 09:07:17 -0400 Message-Id: References: To: Kurt Andersen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 17 Oct 2015 13:07:20 -0000 --Apple-Mail=_577ED149-B5F4-4B22-8BF7-3FB55BDB4D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 16, 2015, at 10:41 AM, Kurt Andersen wrote: >=20 > Will look forward to feedback from any interested parties. Hi Kurt, Can you and the editors of these documents review the interoperability = issues doc (now in WG last call): https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 = ? Once that's done, maybe the editors of the A.R.C. document can share = where it fits into the issues outlined in the interoperability issues = doc. Mainly, though, I'm keening on getting reviews in of the WG doc ASAP. -=3D Tim --Apple-Mail=_577ED149-B5F4-4B22-8BF7-3FB55BDB4D79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Oct 16, 2015, at 10:41 AM, Kurt Andersen <kurta@drkurt.com> = wrote:

Will look forward to feedback from any = interested parties.

Hi = Kurt,

Can you = and the editors of these documents review the interoperability issues = doc (now in WG last call):

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-0= 7

?

Once that's done, maybe the editors of the A.R.C. document = can share where it fits into the issues outlined in the interoperability = issues doc.

Mainly, though, I'm keening on getting reviews in of the WG = doc ASAP.

-=3D = Tim

= --Apple-Mail=_577ED149-B5F4-4B22-8BF7-3FB55BDB4D79-- From nobody Sat Oct 17 06:11:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041CD1B2B1E for ; Sat, 17 Oct 2015 06:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 buxTCEn7VyBU for ; Sat, 17 Oct 2015 06:11:28 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 3C66F1B2B19 for ; Sat, 17 Oct 2015 06:11:28 -0700 (PDT) Received: by qgeo38 with SMTP id o38so78579953qge.0 for ; Sat, 17 Oct 2015 06:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G4aCb7+I24gHL0Tbs06DY5BgAK5tlW7l7Y+82vC+sdc=; b=XI1MmplLaTDGx/GH9+opomtWPofHe8Ah80nmvRvexjPN7ybt1NVR9PV4JlsyCs5Znq KoEMdX0w36B2YFQrh/bf4ZipH97wUOZeD5UQlxeIq/BaFcyghKeWa6Uk6Gjm+h5apz7P oW2Txq2Wp+noQYtwNJ2vebBYGwuKnnxr7ziz8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G4aCb7+I24gHL0Tbs06DY5BgAK5tlW7l7Y+82vC+sdc=; b=H1OHERUxzLaoAxbc7U6BDEdrXo/0lZUaolmonpEMZHEcrmF7UKpNivJbjZJ6RM/doD /8S89zl9NTz8ndqbvSNN8QFF2kktwxXmSpXlhQgTbSHWVrto60e2o9u+sOmZexwdET32 UcwnxFHf6m0gUTDKA5DXTWKUqbfqmquU/0uXxIGEaaIgLH5TAKsxftk5cyF1pmw3U48q wvkTHSYsIgji37zJJqdGo/Wbf8q5Wc4hkTpT8SZb/hrZwOFe3YdnnSikRCQEn+hGS0oj 0uW7JJVjBzHBDzyYzhyJctVjeQM+DH5MZ7GV7DK+DbQbUiy/JBsuGonnKloZYe3xea7g 9a4w== X-Gm-Message-State: ALoCoQlUP/EqdJHNroj42jv3Xj7ewB5MGucUXaQBDskOHI0GOYgBbH7Z6+60rcqJc85TbHWX33KT MIME-Version: 1.0 X-Received: by 10.140.16.225 with SMTP id 88mr25247688qgb.12.1445087487300; Sat, 17 Oct 2015 06:11:27 -0700 (PDT) Received: by 10.55.98.207 with HTTP; Sat, 17 Oct 2015 06:11:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Oct 2015 06:11:27 -0700 Message-ID: From: Kurt Andersen To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c0b3b459b31605224ca68a Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 17 Oct 2015 13:11:30 -0000 --001a11c0b3b459b31605224ca68a Content-Type: text/plain; charset=UTF-8 As one of the editors for the interop document, I have already reviewed it :-) The ARC spec is explicitly designed to help preserve authentication results across multi-hop mail transfers in all of the cases where the intermediaries participate. I would like to add a section to the interop document talking about it, but thought that might be presumptuous. If not, I'll prep an update. --Kurt On Sat, Oct 17, 2015 at 6:07 AM, Tim Draegen wrote: > On Oct 16, 2015, at 10:41 AM, Kurt Andersen wrote: > > Will look forward to feedback from any interested parties. > > > Hi Kurt, > > Can you and the editors of these documents review the interoperability > issues doc (now in WG last call): > > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 > > ? > > Once that's done, maybe the editors of the A.R.C. document can share where > it fits into the issues outlined in the interoperability issues doc. > > Mainly, though, I'm keening on getting reviews in of the WG doc ASAP. > > -= Tim > > --001a11c0b3b459b31605224ca68a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As one of the editors for the interop document, = I have already reviewed it :-)

The ARC spec is explicitly des= igned to help preserve authentication results across multi-hop mail transfe= rs in all of the cases where the intermediaries participate. I would like t= o add a section to the interop document talking about it, but thought that = might be presumptuous. If not, I'll prep an update.

--Kurt=

On Sat,= Oct 17, 2015 at 6:07 AM, Tim Draegen <tim@eudaemon.net> wrot= e:
On Oct 16, 2015, at 10:4= 1 AM, Kurt Andersen <kurta@drkurt.com> wrote:

Will look forward to feedback from any interested p= arties.

Hi Kurt,=

Can you and the editors of these documents review= the interoperability issues doc (now in WG last call):


?

Once that's done, maybe the editors of the A.R.C. document can= share where it fits into the issues outlined in the interoperability issue= s doc.

Mainly, though, I'm keening on getting = reviews in of the WG doc ASAP.

-=3D Tim


--001a11c0b3b459b31605224ca68a-- From nobody Sat Oct 17 10:00:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB331A6F3C for ; Sat, 17 Oct 2015 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SuvZhRhYdBmI for ; Sat, 17 Oct 2015 10:00:02 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 51E041A6F32 for ; Sat, 17 Oct 2015 10:00:02 -0700 (PDT) Received: from [192.168.1.13] (unknown [67.58.115.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 47428CB46; Sat, 17 Oct 2015 12:59:21 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_70E892F9-A220-4163-9310-A4160D324D03" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Draegen In-Reply-To: Date: Sat, 17 Oct 2015 13:00:00 -0400 Message-Id: References: To: Kurt Andersen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 17 Oct 2015 17:00:04 -0000 --Apple-Mail=_70E892F9-A220-4163-9310-A4160D324D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 17, 2015, at 9:11 AM, Kurt Andersen wrote: >=20 > As one of the editors for the interop document, I have already = reviewed it :-)=20 Yes! I'm hoping your A.R.C. colleagues will chime in, too. >=20 > The ARC spec is explicitly designed to help preserve authentication = results across multi-hop mail transfers in all of the cases where the = intermediaries participate. I would like to add a section to the interop = document talking about it, but thought that might be presumptuous. If = not, I'll prep an update. The word "intermediary" doesn't exist in the current interop issues = draft, so if the A.R.C draft is a response to a sub-set of the issues = discussed in the interop document, it would be great to explicitly = mention which issues are addressed. This will make it a lot easier to = go through once the WG finishes its current task. Getting the other A.R.C. editors (and perhaps other A.R.C. = participants?) to review and comment on the 07 interoperability draft: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 = ..would help this WG finish its current task. Without review and = comment of the documented issues, it will be hard to take seriously any = efforts to address said issues. -=3D Tim --Apple-Mail=_70E892F9-A220-4163-9310-A4160D324D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Oct 17, 2015, at 9:11 AM, Kurt Andersen <kurta@drkurt.com> = wrote:

As one of the editors = for the interop document, I have already reviewed it :-) 

Yes! =  I'm hoping your A.R.C. colleagues will chime in, too.


The ARC spec is explicitly = designed to help preserve authentication results across multi-hop mail = transfers in all of the cases where the intermediaries participate. I = would like to add a section to the interop document talking about it, = but thought that might be presumptuous. If not, I'll prep an = update.


The word "intermediary" doesn't exist = in the current interop issues draft, so if the A.R.C draft is a response = to a sub-set of the issues discussed in the interop document, it would = be great to explicitly mention which issues are addressed.  This = will make it a lot easier to go through once the WG finishes its current = task.

Getting = the other A.R.C. editors (and perhaps other A.R.C. participants?) to = review and comment on the 07 interoperability draft:

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-0= 7

..would = help this WG finish its current task.  Without review and comment = of the documented issues, it will be hard to take seriously any efforts = to address said issues.

-=3D Tim


= --Apple-Mail=_70E892F9-A220-4163-9310-A4160D324D03-- From nobody Sat Oct 17 10:25:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312521B2B40 for ; Sat, 17 Oct 2015 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PXH75YApmPiG for ; Sat, 17 Oct 2015 10:25:31 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 B3FCE1B2B41 for ; Sat, 17 Oct 2015 10:25:31 -0700 (PDT) Received: by qgeo38 with SMTP id o38so81772290qge.0 for ; Sat, 17 Oct 2015 10:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9aVeM6yO/StqmMNmMR4fcKNAKEZIA/N4TNYS8hBYy+c=; b=XWDQFGiJw1domfzLf51JUJF12k5n0fEo2bb11lp9U9uSwb3r+zEbetxm3z9fxLNHWF YVkkKEgByMZg3CcJDSBftu67YjkyqHoe6D6OPy1iPEXTfNE61E9d2yZweYhz5ucMCaf7 yJ+XJPOLXAfiGNoPd+8cGiS1Vf1iSS9+m0MN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9aVeM6yO/StqmMNmMR4fcKNAKEZIA/N4TNYS8hBYy+c=; b=icbSJjEkWlTgl95zLszoKim7R+8UWDNVqCN7C1HQtEJq+Xs5bFSVh9cuS1u7ca6qIy V6DUEPxX2WYbYafez02toJGsoAUDNee1TI1GM6GuouBxfF3bWWZ98P7FpuWgMxgQYvRG tfAw10iVQCGTJ6wPnlun3pXSlm+bvnRDMOwKH4NfjtE5s7gpJ+n+Ik5gsyTEZl/twNnb b3YogYDE2QLKc+RE4yokHECfZrepavFf2LL0zhLb5Y1uMI9OfnkUg0gz3ALisySp/PYF eJnO2OROMZv0H/mNgyM8oFoM/5C0FWYSrwICtOYPEPcTYd24ROPYERbCgwmR/IpkPNxn a0oA== X-Gm-Message-State: ALoCoQmVf8IFkyP/B5T1kMyRmgNsuQqhq4kLYI/BWfNEs9VxLI+AytPw/tErivXkZbr1MEI7NlP2 MIME-Version: 1.0 X-Received: by 10.140.16.225 with SMTP id 88mr26462738qgb.12.1445102730883; Sat, 17 Oct 2015 10:25:30 -0700 (PDT) Received: by 10.55.98.207 with HTTP; Sat, 17 Oct 2015 10:25:30 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Oct 2015 10:25:30 -0700 Message-ID: From: Kurt Andersen To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c0b3b4f0479f0522503211 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 17 Oct 2015 17:25:33 -0000 --001a11c0b3b4f0479f0522503211 Content-Type: text/plain; charset=UTF-8 I'll go through (now that the ARC draft is released) and comment on how if relates to the interop topology. --Kurt On Sat, Oct 17, 2015 at 10:00 AM, Tim Draegen wrote: > On Oct 17, 2015, at 9:11 AM, Kurt Andersen wrote: > > As one of the editors for the interop document, I have already reviewed it > :-) > > > Yes! I'm hoping your A.R.C. colleagues will chime in, too. > > > The ARC spec is explicitly designed to help preserve authentication > results across multi-hop mail transfers in all of the cases where the > intermediaries participate. I would like to add a section to the interop > document talking about it, but thought that might be presumptuous. If not, > I'll prep an update. > > > > The word "intermediary" doesn't exist in the current interop issues draft, > so if the A.R.C draft is a response to a sub-set of the issues discussed in > the interop document, it would be great to explicitly mention which issues > are addressed. This will make it a lot easier to go through once the WG > finishes its current task. > > Getting the other A.R.C. editors (and perhaps other A.R.C. participants?) > to review and comment on the 07 interoperability draft: > > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 > > ..would help this WG finish its current task. Without review and comment > of the documented issues, it will be hard to take seriously any efforts to > address said issues. > > -= Tim > > > --001a11c0b3b4f0479f0522503211 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll go through (now that the ARC draft is releas= ed) and comment on how if relates to the interop topology.

--= Kurt

On = Sat, Oct 17, 2015 at 10:00 AM, Tim Draegen <tim@eudaemon.net>= wrote:
On Oct 17, 2015, at= 9:11 AM, Kurt Andersen <kurta@drkurt.com> wrote:

As one of= the editors for the interop document, I have already reviewed it :-)= =C2=A0

Yes!= =C2=A0 I'm hoping your A.R.C. colleagues will chime in, too.


The ARC spec is explicitly des= igned to help preserve authentication results across multi-hop mail transfe= rs in all of the cases where the intermediaries participate. I would like t= o add a section to the interop document talking about it, but thought that = might be presumptuous. If not, I'll prep an update.
<= /div>


The word "inter= mediary" doesn't exist in the current interop issues draft, so if = the A.R.C draft is a response to a sub-set of the issues discussed in the i= nterop document, it would be great to explicitly mention which issues are a= ddressed.=C2=A0 This will make it a lot easier to go through once the WG fi= nishes its current task.

Getting the other A.R.C. = editors (and perhaps other A.R.C. participants?) to review and comment on t= he 07 interoperability draft:


..would help this WG finish its current tas= k.=C2=A0 Without review and comment of the documented issues, it will be ha= rd to take seriously any efforts to address said issues.

-=3D Tim
=


--001a11c0b3b4f0479f0522503211-- From nobody Sat Oct 17 22:45:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65D1B2D1D for ; Sat, 17 Oct 2015 22:45:12 -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 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 8WGcPu90tLbs for ; Sat, 17 Oct 2015 22:45:10 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id A78921B2D1C for ; Sat, 17 Oct 2015 22:45:10 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 297A056405E; Sun, 18 Oct 2015 00:45:10 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0C87BA043F; Sun, 18 Oct 2015 00:45:10 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eNAhvcaMGIE; Sun, 18 Oct 2015 00:45:09 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A28A8A0434; Sun, 18 Oct 2015 00:45:09 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com A28A8A0434 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1445147109; bh=WLrREljmvIG8JHYSTOKBNNty8S3gL1WRXbuNhuC5eOI=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=p+aspFN5OQYCsJT3/Z/l3A0l00OM8pzGf2EkZnHIJuLR9pqQ5K5FmD6pjA2JJZByY 49ylO/EBYkO2mrmeQuVUEBzQHZbkjD/5bklJm+8ayC3oV3zxP2eWx+3y+Ek6T7R945 GkDH0YUZaRaSmfWSeEcNgoCEqOqwlkcNsCCggrqQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 85C34A043F; Sun, 18 Oct 2015 00:45:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jcvnvgKKQ7NS; Sun, 18 Oct 2015 00:45:09 -0500 (CDT) Received: from [10.0.0.2] (c-67-180-100-98.hsd1.ca.comcast.net [67.180.100.98]) by smtp-out-1.01.com (Postfix) with ESMTPSA id EAA6EA0434; Sun, 18 Oct 2015 00:45:08 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_19791C00-CC11-431F-9486-EBCD2675F862" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Franck Martin In-Reply-To: Date: Sat, 17 Oct 2015 22:45:07 -0700 Message-Id: <83E3C03D-7893-4E89-A9FD-DA76C8DBB66A@peachymango.org> References: To: Tim Draegen X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "dmarc@ietf.org" , Kurt Andersen Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Oct 2015 05:45:12 -0000 --Apple-Mail=_19791C00-CC11-431F-9486-EBCD2675F862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 17, 2015, at 6:07 AM, Tim Draegen wrote: >=20 >> On Oct 16, 2015, at 10:41 AM, Kurt Andersen > wrote: >>=20 >> Will look forward to feedback from any interested parties. >=20 > Hi Kurt, >=20 > Can you and the editors of these documents review the interoperability = issues doc (now in WG last call): >=20 > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 = >=20 If an update is needed before next IETF meeting, this has to happen = before this Monday 2015-10-19 UTC 23:59.=20 --Apple-Mail=_19791C00-CC11-431F-9486-EBCD2675F862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 17, 2015, at 6:07 AM, Tim Draegen <tim@eudaemon.net> = wrote:

On Oct = 16, 2015, at 10:41 AM, Kurt Andersen <kurta@drkurt.com> = wrote:

Will look forward to feedback from any = interested parties.

Hi = Kurt,

Can you = and the editors of these documents review the interoperability issues = doc (now in WG last call):

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-0= 7


If = an update is needed before next IETF meeting, this has to happen before = this Monday 2015-10-19 UTC 23:59. 

= --Apple-Mail=_19791C00-CC11-431F-9486-EBCD2675F862-- From nobody Sun Oct 18 20:28:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED12D1A0252 for ; Sun, 18 Oct 2015 20:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wWEF1PUQzRib for ; Sun, 18 Oct 2015 20:28:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A321A0250 for ; Sun, 18 Oct 2015 20:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K3zxiKTrXqmKUiAARSGimYswxOX3IJg7vjCv0ZTaDqI=; b=GwnIFkaXxof6G46HpCOtjDdBEdQrhNRGNKQtixAvNMJcPWho5b2ws4WN4CP2bMTB22ZWkYfCi4SCoYNf2Gyp0hH/GRQT+o5n6uzvoT/SG0+fBFxE8ceuTTHJ6qPUV04nx29RNqpBsej37E/W+FfLl59n1ZBJ7nkH18cQj750X8U= Received: from BLUPR03CA002.namprd03.prod.outlook.com (10.255.124.19) by BN1PR0301MB0738.namprd03.prod.outlook.com (10.160.78.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 03:28:24 +0000 Received: from BY2FFO11OLC010.protection.gbl (10.255.124.4) by BLUPR03CA002.outlook.office365.com (10.255.124.19) with Microsoft SMTP Server (TLS) id 15.1.300.14 via Frontend Transport; Mon, 19 Oct 2015 03:28:24 +0000 Authentication-Results: spf=softfail (sender IP is 23.103.249.52) smtp.mailfrom=exchange.microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=exchange.microsoft.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning exchange.microsoft.com discourages use of 23.103.249.52 as permitted sender) Received: from dedicated.microsoft.com (23.103.249.52) by BY2FFO11OLC010.mail.protection.outlook.com (10.1.15.21) with Microsoft SMTP Server (TLS) id 15.1.300.4 via Frontend Transport; Mon, 19 Oct 2015 03:28:23 +0000 Received: from CH1SR9901MB0060.001d.mgd.msft.net (141.251.196.216) by CH1SR9901MB0058.001d.mgd.msft.net (141.251.196.214) with Microsoft SMTP Server (TLS) id 15.1.312.3; Mon, 19 Oct 2015 03:28:14 +0000 Received: from CH1SR9901MB0060.001d.mgd.msft.net ([141.251.196.216]) by CH1SR9901MB0060.001d.mgd.msft.net ([141.251.196.216]) with mapi id 15.01.0312.006; Mon, 19 Oct 2015 03:28:14 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Two new internet-drafts related to forwarded email Thread-Index: AQHRCCDFk6sedzTqFEe9loDVRHMc4Z5vqT2AgAABKoCAAD/bAIACQDow Date: Mon, 19 Oct 2015 03:28:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.201.157.130] Content-Type: multipart/alternative; boundary="_000_f3b811d4bdb945e8bbdfd4d2634be710CH1SR9901MB0060001dmgdm_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1SR9901MB0058.001d.mgd.msft.net X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC010; 1:rsfNLUNesJIC8+JLtpKo0I8dRN0Ugb8RdjvfFI+6ar1Hf+nqz8QnhqiOnfxrZSvqdemMw4s80tSfLtbOJfLCJB4FaIYshwNRDPRC0QrIOmXn9zd/2c77Isvx2cmmwxy+wS3bqXy2Xo9yISM4Lbduk3DoYUozCy8wDY2yJ5Hj9hpy6ZuKCIc0gKIvDCXGVzCq9U1mCmL42Iojgf6xn3PPCcA+1gefr1R2hg3GfzBd9tH1E/pMkEdQmELAGXdeAdXw2bIG7hYilG8XX3qzyRPWy+2T/xOzIlNCWlpd4QRqnAU6YhDQp6a3MNPpgveW+r2StZ2UDYZMg97ixrlsKdibIg== X-Forefront-Antispam-Report: CIP:23.103.249.52; CTRY:; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(199003)(377454003)(24454002)(189002)(10290500002)(54356999)(108616004)(81156007)(5001960100002)(5005710100001)(5003600100002)(66066001)(16236675004)(110136002)(64706001)(10400500002)(76176999)(107886002)(189998001)(2950100001)(11100500001)(6806005)(93886004)(24736003)(450100001)(92566002)(2501003)(5004730100002)(19300405004)(10090500001)(5007970100001)(19625215002)(512954002)(97736004)(69596002)(16796002)(2351001)(84326002)(46102003)(105596002)(86146001)(15975445007)(106116001)(50986999)(87936001)(33646002)(102836002)(19617315012)(86362001)(2900100001)(106466001)(5008740100001)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0738; H:dedicated.microsoft.com; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-CrossPremisesHeadersPromoted: BY2FFO11OLC010.protection.gbl X-CrossPremisesHeadersFiltered: BY2FFO11OLC010.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0738; 2:QTQUgMqGVgKgzVb8v9YrnFa6OGuG4F+0osi2TGUDnZaAcRXazyr1lIOi+SkdPUP2pe/ArGSnUURKnXzzrkMTPEPXO/M6GKhoXumueZPDpzeDskmQF8AuJm5SC9QVvCkASEuB7BRfvlpsRYdloEcdDzHJweRWOfAdghvzxGS6GEU=; 3:fCamZK6d6jmDUlBfQdVLIoCzerBxMUEnZKEeGAsfwbHOc8NHakB2JyExpduXC6ZTsEOWHdZjZsUACWi35vQB8H0DiJ7FQprbl7BSSfIVKx1PZlO4dgzUzDVWqHakDkFZJ6kK0qU4I9Hd9sgpzL4gCESJB4XMjxKVGaFACh46MM1EZBHW4UTPONKRCf8/h0eWVvr1zDz/HSZFUGYNvjgZxyBlM0YnwiQd4u1zAcvvtwM=; 25:IQSiugLMaEKmWx4jJ2BZJzhndKtAnvElbBurQDJ+c8ndS7mUrMtGldB6N3UxrFN0gOYRq85jq+0BBSRtVL+93TjX01zEmnoYx2zQRUyVrNglJKbS+vHz8EGBy7yjEPsz3+GF2rxcLs70b4Hms6GIdHFECRpmw/n7Dr9Ifhyaxq93PhYjvvJeCePAnrV4dDCmi2SrIlWe806F9/Nku9Cyl6TfXbiIJL3qLOvB4D7oi5DtRG/BoHw1ISI3dbJd+uNRY7E4h4BBzj5P3jsY3uyE9w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0738; X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0738; 20:WCj0K+gZZSExxacZqG9ftu0AhKta1XABA1PMgEy/tWrt9ZAjEEeLbmDP2/IKB8LQMvyH0LQDlzSWgA5+R9cbrVhlP9GK1d+NuvtcYZLqaTutZeNJspY84jyAEDRFSX44gI4DZ6E/LiyfOfPmJn/koyNU/ep/H6/i/on8P+pCo9lWOb4XhJLypDRnn7PVBz4U/tp5vthf8d8uqP458YIBEkcEnWDOofDTBtbiEnT8uv+inLxfpo/5VU4OeLLlUXW3+wbZ/6+jZg8qyO54xXpGRdROM8fS8iN1y4g74htpl28LmsYC7DdQXThA4wC8v4YkgjcvnygTVPhIg1EDYbxsq5bzS1SAzfYzkbQfqMEbaT3UimIdD1eoaKUxMlS0Pz2ffYsDpTmzbQ2LAMJiZ7MpSmeOsPDab9vQQfAEaBGs1crnFlMykl/DEXMvLSPTLBRngbCq8TbuzIcmjQtEhI43kZaRn+K2mt6/lqmx8U0reo7otLV7cDTx2ISG53sFLuV+; 4:4hc9bdCYbPQD2ithqQNYIY4z/yYru55ERneUw7JTWUDp5+re+1utJg4NVaUiMchcMdei7wCwoW1x1oJgo7eaEJV27sdsi+zz+L1QexaecVPFJ3ezYkttwAooBeI6LvdihWXaBSwTl8LASOoatk8irMeRfz5hQ2PFwMiV50BGaeoGmVUfrQeZo90svJaOQMffMCewpKJ6/fJm1jrB4r9T9TfLJX6dS41l8QpGV05+5wdBqUh7sYblURJzKCFSp9gq7TC4YdmUlTHk+7xwlnIE4iHieGV/uwDdyrDBUVEnH5fHqlNcdXnY3oIZDsB/VAZKIy0I1NXFb1ellTKYNTyShln5aXqhhCKQJxqUxm2mYTOa3jvbXBq3J7hu1dcFCSEJnb5eLWgaie80I+IMCIBTmdejR8u/lwGd1/U4G9woi1g= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(42673675456677)(108003899814671)(83020558694031); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(61426024)(61427024); SRVR:BN1PR0301MB0738; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0738; X-Forefront-PRVS: 07349BFAD2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR0301MB0738; 23:kQCOVl5pUqJdWe9INbnZd0JSmNmQcVB4FrQDDed?= =?us-ascii?Q?SFiQ2NYLoFcl7FMEpufDSeVEL8FBruLQJGyTMBT78ZASKKDOUWMpE5N2Ydl8?= =?us-ascii?Q?apStlAXkwcyBSY0uxSei3ASQ7hlnShgRK+JyJDiXAf650FlGwbGnCh1jzD1j?= =?us-ascii?Q?2ER91pRFd8Vy0wkIomGwjNcUPq+IDPZAJUPvTG8+eF/AWYKw6IYy+RmYKuX7?= =?us-ascii?Q?7QCqNuMbFhXhURMW4LNMRN3/nHJX9zjPB6v7DDQU3CvX++SH1pMOx+ulVJ0B?= =?us-ascii?Q?hyg671siKwbuuzBGTQxdi+FVKIqk6C4p302+Xrx0Gx4cA9YlbTnGKNjPlbVK?= =?us-ascii?Q?NbpnX159G5b8yMOcJWjjwsMLr9hCle1X7+slqsDTFzm90DkAxGK1LP16OGAf?= =?us-ascii?Q?or8ZHKUwcKPnPUAH24MomHhhWo56oljoJPIg6TDJYHiq6vSipT3MBQtzvyLy?= =?us-ascii?Q?HrtF/nXXFRQ2LN22wp+5BVOyaUhqR1SOTa+JPRNXAKB3mkyVJOjUz2JOSBC4?= =?us-ascii?Q?c2apFCx+UNUBYp6d2RIXpde2KsoJhOQT7bLOaaSLNyyQZw24Nt6BbPHXuZxy?= =?us-ascii?Q?ix26WPft3Jhz+XFQVKe3AwPvdFuFiBnKAtZaQWIZvfrn1XxyA54HhW5fBxHz?= =?us-ascii?Q?AAT+PEwJKuQWAdIIpCwJvsY2/Hg9sfTmQaZkJn51ZHXakH4ekqxwz8zdqJwp?= =?us-ascii?Q?QMtIFqhGd1qr9BN7xp3NpzWGw3Rx+Dtyh4bqLeK5Q5lYrI1BzU5FPAan6U25?= =?us-ascii?Q?nbB1Ys6DBKhX4RGZcYyTwtwhr59yJwQyqcHycbYYKfHR4uCnm35LI01/MQ+1?= =?us-ascii?Q?Rbsh4+mxZfXgz+QU8lBJKSrwPBaC+RP9SYB7D45EG3e9Hoa0v9FBAw8kjqbW?= =?us-ascii?Q?k+9SpAtv+rpBOOS628nUJKnyoDgci5xJLh41YrXhAbliGfrufrD5p62CRQTQ?= =?us-ascii?Q?5yzdfVxcOAqVVVFy05OGEj16RrasiWBRFucKzvgY50gEybMRxust5RC0rlJV?= =?us-ascii?Q?pSWjJ9lxAY7WrSCZzDtqoImt+XoHwe+OvSRH8c5iVO4zTZFvPu4MO9EaFOPZ?= =?us-ascii?Q?WWisbmalgsD3Z4Ti8+ftJPtNmypgN89Y6maUpmwRuyhFba/4gdUhOr4M3Nu0?= =?us-ascii?Q?b//PNvLiAv1v75To5cMK/QE3urZNpfe2YkNeqFrE2+CkOWiPRxZKkzDPbXd+?= =?us-ascii?Q?+2JwHCczpRt122/IunTmi/WgfflH/xZ6hdaMFbAk3BJO1kDPdf1vpm3RoNQx?= =?us-ascii?Q?4lg7iiOlCSIXqC7fh8OcVzZn5Izx6gWCtV8Ctx3Ldlsqcy/qjOC0WzWTJ/pK?= =?us-ascii?Q?iCZbRZHsNUtxfjbeLEG5YJveHxcDaYaoLGXoV+HPpqjerja+kyaCSJKf19Q0?= =?us-ascii?Q?C6OtVIWsDkgniQPApBlJCsNklBvYPN/+fbIjTgFGnUKCwNQbNhO8DHcDrf0h?= =?us-ascii?Q?26JhHKPZPS/X3o8c01fIzE58VYt85/oKwPjQaoB/Ng1SieLtFXb8HBzQ5L0B?= =?us-ascii?Q?cWXWUzLONja2pCw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0738; 5:3ogrxWlEEOxUXzu/1yiXtDofuMnZPXyn/ADSFH6RKHHoAWQeqFgWFYDWUJbScWL2H7lDsyP1Xx3LQBOzc5HoUxWXhBCuxe7Nw6Cb5Z3SiUumY9a1Ao44XO7dzqSbsGg60bP/HEgtfHKZvvqHG+0vrg==; 24:FLoLbLpkX4j3ct70jepcsCOGfIPC5E9OYzj+k1OkPT4I0m8sZybofGwrrpUGjLckTu4n11DAWDLADPeLYLI2npm1dE621bR92qD207ycX70= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2015 03:28:23.8538 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[23.103.249.52]; Helo=[dedicated.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0738 Archived-At: Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 19 Oct 2015 03:28:30 -0000 --_000_f3b811d4bdb945e8bbdfd4d2634be710CH1SR9901MB0060001dmgdm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The idea behind ARC is similar to the idea behind John Levine's Conditional= DKIM but it does it in a different way. Suppose the path is like this: A --> B --> C C sees that the message comes "from" A originally but can't verify either A= 's SPF or DKIM. However, B (who sent the message to C) says "I verified A's= SPF and DKIM and it was fine." C then accepts what B said. That's it in a nutshell (removing the finer points of reputation, how C can= trust B, etc.). -- Terry From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Draegen Sent: Saturday, October 17, 2015 10:00 AM To: Kurt Andersen Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded emai= l On Oct 17, 2015, at 9:11 AM, Kurt Andersen > wrote: As one of the editors for the interop document, I have already reviewed it = :-) Yes! I'm hoping your A.R.C. colleagues will chime in, too. The ARC spec is explicitly designed to help preserve authentication results= across multi-hop mail transfers in all of the cases where the intermediari= es participate. I would like to add a section to the interop document talki= ng about it, but thought that might be presumptuous. If not, I'll prep an u= pdate. The word "intermediary" doesn't exist in the current interop issues draft, = so if the A.R.C draft is a response to a sub-set of the issues discussed in= the interop document, it would be great to explicitly mention which issues= are addressed. This will make it a lot easier to go through once the WG f= inishes its current task. Getting the other A.R.C. editors (and perhaps other A.R.C. participants?) t= o review and comment on the 07 interoperability draft: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 ..would help this WG finish its current task. Without review and comment o= f the documented issues, it will be hard to take seriously any efforts to a= ddress said issues. -=3D Tim --_000_f3b811d4bdb945e8bbdfd4d2634be710CH1SR9901MB0060001dmgdm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The idea behind ARC is similar to the idea behind John Levine’s Cond= itional DKIM but it does it in a different way. Suppose the path is like this:

 

A &= agrave; B &= agrave; C

 

C sees that the message com= es “from” A originally but can’t verify either A’s = SPF or DKIM. However, B (who sent the message to C) says “I verified = A’s SPF and DKIM and it was fine.” C then accepts what B said.=

 

That’s it in a nutshe= ll (removing the finer points of reputation, how C can trust B, etc.).=

 

-- Terry<= /p>

 

From: dmarc = [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Draegen
Sent: Saturday, October 17, 2015 10:00 AM
To: Kurt Andersen
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Two new internet-drafts related to forward= ed email

 

On Oct 17, 2015, at 9:11 AM, Kurt Andersen <kurta@drkurt.com> wrote:

 

As one of the editors for the interop docume= nt, I have already reviewed it :-)&nb= sp;

 

Yes!  I'm hoping your A.R.C. colleagues will ch= ime in, too.



 

The ARC spec is explicitly designed to help = preserve authentication results across multi-hop mail transfers in all of t= he cases where the intermediaries participate. I would like to add a section to the interop document talking about it, but thought tha= t might be presumptuous. If not, I'll prep an update.

 

 

The word "intermediary" doesn't exist in t= he current interop issues draft, so if the A.R.C draft is a response to a s= ub-set of the issues discussed in the interop document, it would be great t= o explicitly mention which issues are addressed.  This will make it a lot easier to go through once the WG finishes it= s current task.

 

Getting the other A.R.C. editors (and perhaps other = A.R.C. participants?) to review and comment on the 07 interoperability draf= t:

 

 

..would help this WG finish its current task.  = Without review and comment of the documented issues, it will be hard to tak= e seriously any efforts to address said issues.

 

-=3D Tim

 

 

--_000_f3b811d4bdb945e8bbdfd4d2634be710CH1SR9901MB0060001dmgdm_-- From nobody Sat Oct 31 04:56:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210451A89A9 for ; Sat, 31 Oct 2015 04:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, J_CHICKENPOX_14=0.6, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=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 zfc_C1xUcQol for ; Sat, 31 Oct 2015 04:56:52 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E2C1A8971 for ; Sat, 31 Oct 2015 04:56:52 -0700 (PDT) Received: by wmff134 with SMTP id f134so28781987wmf.0 for ; Sat, 31 Oct 2015 04:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=skC1noL+JXqFTmmsNa2rHdTNy0n/AFpcETvcVWO50vQ=; b=b8J+ajBVvxfBuChOpdmuxH9BoSMWVMg0nhuBu4hSGPo5TD6GTmOCyuMm4RCE3G8/38 R1bJW29TEJ+NSxwCqcC3lYA0bCfmqtCeLPiKoMYumJKMBLHPEV5odM0ZmF1NjEYEsgHD y4Fk53VU5zTTCPHuZO9j436q54wdS8X7iekB5rhJpsfULwD/Ioo2phE/zWSMF8ysuZf1 JaGAsA302p0ePm8F0Vyk0+fReKq4ArtZk9FuYrdNwbWyEVUlwbm6dBQkiJ5S7mZv2gRW GH3Onq/ujXyM19/Dpz6puT7r2MR/02vfjIY+ElcdS+Nc/dJ9ffzwKbfuTWfVGvExyvSg 1nkA== MIME-Version: 1.0 X-Received: by 10.28.18.194 with SMTP id 185mr3081984wms.44.1446292610973; Sat, 31 Oct 2015 04:56:50 -0700 (PDT) Received: by 10.27.175.104 with HTTP; Sat, 31 Oct 2015 04:56:50 -0700 (PDT) In-Reply-To: <20151019200150.15068.51622.idtracker@ietfa.amsl.com> References: <20151019200150.15068.51622.idtracker@ietfa.amsl.com> Date: Sat, 31 Oct 2015 20:56:50 +0900 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11469f6a5187970523653d68 Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-08.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Oct 2015 11:56:55 -0000 --001a11469f6a5187970523653d68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2015 at 5:01 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance Working Group of the IETF. > > Title : Interoperability Issues Between DMARC and > Indirect Email Flows > Authors : Franck Martin > Eliot Lear > Tim Draegen > Elizabeth Zwicky > Kurt Andersen > Filename : draft-ietf-dmarc-interoperability-08.txt > Pages : 23 > Date : 2015-10-19 > > Abstract: > DMARC introduces a mechanism for expressing domain-level policies and > preferences for email message validation, disposition, and reporting. > The DMARC mechanism can encounter interoperability issues when > messages do not flow directly from the author's administrative domain > to the final recipients. Collectively these email flows are referred > to as indirect email flows. This document describes interoperability > issues between DMARC and indirect email flows. Possible methods for > addressing interoperability issues are presented. > > Sorry it took me so long to get to this, but here's the review I managed to crank out on my flight to Tokyo today. It's largely editorial. Section 2: - I think p=3Dnone should be quoted. Section 2.1: - s/domain the SPF analysis/domain that the SPF analysis/ ...or better yet: "domain checked by SPF" - s/Also note that/Also note that the/ - s/different from/different from the/ Section 2.2: I can't parse the last bullet in the list. Should it be "...will likely be in a different organizational domain than the..." ? Section 2.3: - s/here mentionned/mentioned here/ - s/headers and body/header and body/ (either both singular or both plural= ) - s/whitespace folding/whitespace and folding/ (we also deal with consecutive unfolded whitespace) - "While the prevalence is unknown" -- Do we not have stats on this by now? - s/checkers which/verifiers that/ Section 3.1.1: - s/domains which publish/domains that publish/ Section 3.1.2.1: - s/domain might also/domain could also/ (just for contrast with the previous bullet) Section 3.1.2.2: - s/headers to bring headers/headers to bring them/ Section 3.2: - s/Mail From/RFC5321.MailFrom/ Section 3.2.1: - s/freemail/free email ("freemail")/ (define on first use) Section 3.2.3: - The bullet list has an odd format in terms of punctuation. Suggest: o thing1; o thing2; and o thing3. - The final bullet could reference RFC6377, which talks about that very problem in more detail. Section 4: - s/still used and/still used, although/ - s/Ezmlm/ezmlm/ (2x) - s/still deployed and has not/still deployed but has not/ Section 4.1.1.1: - define "bounces" on first use; I think RFC5321 or RFC5322 has a more formal definition - s/risks which should/risks that should/ - "carefully managed" -- doesn't RFC6376 discuss this? If so, a reference would be prudent here. Section 4.1.1.2: - end of first bullet: doesn't RFC6376 talk about this as well? Section 4.1.3.3: - s/policy which/policy that/ - Is that fist bullet talking about things like "On behalf of"? Also, what sort of collision is the concern here? - second bullet: s/Another mitigation policy is to configure/Configuring/ (for consistency with the second bullet) - third bullet: s/Another mitigation policy, is to configure/Configuring/ - fourth bullet: s/Another mitigation policy, is to reject/Reject/ - s/understood and adjusted to/understood and accommodated/ Section 4.2: I'm generally unsure about this section. It will eventually (sooner than later) refer to a number of expired documents. It might be more helpful to the reader to just summarize the idea behind each approach in a paragraph rather than forcing the reader to chase down specific expired I-Ds. The description of conditional signatures is over-reaching; there's no requirement that the forwarder's signature "fully" sign the message. A better description for dkim-list-canon: "record a canonical list posting format for signing, so that typical MLM changes do not invalidate signatures=E2=80=9D or something. - s/provides a proposed mechanism to provide/proposes a mechanism to provide/ Section 6: Suggested simplifications: Section 4.1.1.1 discusses appropriate DKIM key management with third party email senders. Section 4.1.3.3 warns that rewriting of the RFC5322.From header field and changing the domain name should not be done with any domain. --001a11469f6a5187970523653d68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 20, 2015 at 5:01 AM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Domain-based Message Authentication,= Reporting & Conformance Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Interoperability Issues Between DMARC and Indirect Email Flows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Fran= ck Martin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eliot Lear
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tim Draegen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Elizabeth Zwicky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kurt Andersen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-interoperability-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 23
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-19

Abstract:
=C2=A0 =C2=A0DMARC introduces a mechanism for expressing domain-level polic= ies and
=C2=A0 =C2=A0preferences for email message validation, disposition, and rep= orting.
=C2=A0 =C2=A0The DMARC mechanism can encounter interoperability issues when=
=C2=A0 =C2=A0messages do not flow directly from the author's administra= tive domain
=C2=A0 =C2=A0to the final recipients.=C2=A0 Collectively these email flows = are referred
=C2=A0 =C2=A0to as indirect email flows.=C2=A0 This document describes inte= roperability
=C2=A0 =C2=A0issues between DMARC and indirect email flows.=C2=A0 Possible = methods for
=C2=A0 =C2=A0addressing interoperability issues are presented.


Sorry it took me so long to get to this, but he= re's the review I managed to crank out on my flight to Tokyo today.=C2= =A0 It's largely editorial.

Section 2:

<= div>- I think p=3Dnone should be quoted.

Section 2.1:
=
- s/domain the SPF analysis/domain that the SPF analysis/
...or better yet:
"domain checked by SPF&quo= t;

- s/Also note that/Also note that the/

- s/different from/different from the/

Section 2.2:
I can't parse the last bullet in the list.=C2=A0 Should= it be "...will likely be in a different organizational domain than th= e..." ?

Section 2.3:

- s/here ment= ionned/mentioned here/

- s/headers and body/header and bo= dy/=C2=A0 (either both singular or both plural)

- s/white= space folding/whitespace and folding/=C2=A0 (we also deal with consecutive = unfolded whitespace)

- "While the prevalence is unkn= own" -- Do we not have stats on this by now?

- s/che= ckers which/verifiers that/

Section 3.1.1:

<= div>- s/domains which publish/domains that publish/

Secti= on 3.1.2.1:

- s/domain mig= ht also/domain could also/ (just for contrast with the previous bullet)
=
Section 3.1.2.2:

- s/headers to bring headers/headers to bring them/

Section 3.2:

- s/Mail From/RFC5321.MailFrom/

Section 3.2.1:

- s/freemail/free email ("free= mail")/=C2=A0 (define on first use)

Section 3.2.3:
- The bullet list has an odd format in terms of punctuatio= n.=C2=A0 Suggest:

o thing1;
o thing2; and
o thing3.

- The final bullet could reference= RFC6377, which talks about that very problem in more detail.

=
Section 4:

- s/still used and/still used, although/<= br>
- s/Ezmlm/ezmlm/ (2x)

- s/still deploye= d and has not/still deployed but has not/

Section 4.1.1.1:

- define "bounces&q= uot; on first use; I think RFC5321 or RFC5322 has a more formal definition<= br>
- s/risks which should/risks that should/

- "carefully managed" -- doesn't RFC6376 discuss this?=C2= =A0 If so, a reference would be prudent here.

Section 4.1.1.2:

- end of first bulle= t: doesn't RFC6376 talk about this as well?

Section <= a href=3D"http://4.1.3.3">4.1.3.3:

- s/policy which/p= olicy that/

- Is that fist bullet talking about things like "On= behalf of"?=C2=A0 Also, what sort of collision is the concern here?
- second bullet: s/Another mitigation policy is to configu= re/Configuring/=C2=A0 (for consistency with the second bullet)

- third bullet: s/Another mitigation policy, is to configure/Configur= ing/

- fourth bullet: s/Another mitigation policy, is to = reject/Reject/

- s/understood and adjusted to/understood = and accommodated/

Section 4.2:

I'm = generally unsure about this section.=C2=A0 It will eventually (sooner than = later) refer to a number of expired documents.=C2=A0 It might be more helpf= ul to the reader to just summarize the idea behind each approach in a parag= raph rather than forcing the reader to chase down specific expired I-Ds.
The description of conditional signatures is over-reaching;= there's no requirement that the forwarder's signature "fully&= quot; sign the message.

A better description for dkim-lis= t-canon: "record a canonical list posting format for signing, so that typical MLM changes do not invalidate signatures=E2=80=9D = or something.

- s/provides a proposed mechanism t= o provide/proposes a mechanism to provide/

= Sec= tion 6:

Suggested simplifications:
<= /span>

Section 4.1.1.1 discusses appropria= te DKIM key management with third party email senders.

Section 4.1.3.3 warns that rewr= iting of the RFC5322.From header field and changing the domain name should not be done with any domain.
--001a11469f6a5187970523653d68-- From nobody Sat Oct 31 09:28:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0E1A88A1 for ; Sat, 31 Oct 2015 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jGbIkVPlsaWV for ; Sat, 31 Oct 2015 09:28:16 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 94ED61A88A0 for ; Sat, 31 Oct 2015 09:28:16 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id EACEC805F7 for ; Sat, 31 Oct 2015 09:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1446308895; bh=kcZz00bYEIHrLBvUOlMpiWdQBLvZVZuoGJ4m8IfkYwI=; h=Subject:From:In-Reply-To:Date:References:To:From; b=iBfV8meYFtaA2BIMSPKrN/xdBK+v3k4ZwxSYnSNF5zWHrYIczipc5z8IStISZqorF MSuzZmBI2aWFWJT4pvig6fit3MJQU47McpjOJUaXY2W6/+kEJauB17r/K67ytX8PM4 fpb644NFocV/l2yrBpoqakXQIKSjtkykt0ao0Ahg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Steve Atkins In-Reply-To: Date: Sat, 31 Oct 2015 09:28:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Oct 2015 16:28:18 -0000 > On Oct 18, 2015, at 8:28 PM, Terry Zink = wrote: >=20 > The idea behind ARC is similar to the idea behind John Levine=E2=80=99s = Conditional DKIM but it does it in a different way. Suppose the path is = like this: > =20 I've seen this explanation a couple of times now. It only just occurred = to me that the reason it's hard to make sense of is because it's using = wingdings as a font, so people on Windows systems (might) see arrows = where I see an a-grave. You might want to fall back to ascii art, Terry. = :) > A =C3=A0 B =C3=A0 C > =20 > C sees that the message comes =E2=80=9Cfrom=E2=80=9D A originally but = can=E2=80=99t verify either A=E2=80=99s SPF or DKIM. However, B (who = sent the message to C) says =E2=80=9CI verified A=E2=80=99s SPF and DKIM = and it was fine.=E2=80=9D C then accepts what B said. > =20 > That=E2=80=99s it in a nutshell (removing the finer points of = reputation, how C can trust B, etc.). > =20 Cheers, Steve From nobody Sat Oct 31 09:39:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCA41B2B13 for ; Sat, 31 Oct 2015 09:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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, USER_IN_WHITELIST=-100] autolearn=ham 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 n3njRFgI6TY8 for ; Sat, 31 Oct 2015 09:39:17 -0700 (PDT) Received: from mail.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAE1B2B0B for ; Sat, 31 Oct 2015 09:39:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=807; t=1446309547; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=t+4lViXDWn261DjF71/PKelTF8o=; b=KmPkfzdxHrb54LPA/P7fBz1Erz+mp/TZaYG0l+i2NsKHjCVlr2zBo2pjAqPly1 sKSSOZCJ6I/EcATY2Bizs4jKEQcsheH1iVdbnt3zxB+4TAbBcPzhen8AkKMvOXEL 73G/KxvU2UPGQaZTtDJ6+CUt+saUcHKDMxNMEQrNEhTOw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 31 Oct 2015 11:39:07 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2492741052.8029.2644; Sat, 31 Oct 2015 11:39:06 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=807; t=1446309492; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=siA6Ml+ fAqqVuacKrtydTOBR5KfGP3tnbgjXbjJpBSA=; b=HoYNZ7dVnP/BPJXgz1jdSvh YAzeM/IstNwr2NzT5QhnHzU52BllAUzRrlH2vay5ShQjfWRAi5+4eAjYhegYec4T Ds4gIRc7ZkahwGLgJqApafVErW06TyaGB4wIcDMTcKPA2qBbWVw9hJHP03FTIW7F pEI9Zr8nyOjSopy3IQtU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 31 Oct 2015 12:38:12 -0400 Received: from [192.168.1.2] ([99.121.4.202]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1431625367.9.52256; Sat, 31 Oct 2015 12:38:11 -0400 Message-ID: <5634EEAC.20508@isdg.net> Date: Sat, 31 Oct 2015 12:39:08 -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: Steve Atkins , "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Oct 2015 16:39:19 -0000 On 10/31/2015 12:28 PM, Steve Atkins wrote: > >> On Oct 18, 2015, at 8:28 PM, Terry Zink wrote: >> >> The idea behind ARC is similar to the idea behind John Levine’s Conditional DKIM but it does it in a different way. Suppose the path is like this: >> > > I've seen this explanation a couple of times now. It only just occurred to me that the reason it's hard to make sense of is because it's using wingdings as a font, so people on Windows systems (might) see arrows where I see an a-grave. You might want to fall back to ascii art, Terry. :) > >> A à B à C >> LOL, there is more of this going on. I keep blaming myself for not taking the time to correct/update/reprogram my mail readers. It seems no one has got WYSIWYG straight these days! -- HLS From nobody Sat Oct 31 11:50:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169371A90C2 for ; Sat, 31 Oct 2015 11:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Soe3aNPRLFCX for ; Sat, 31 Oct 2015 11:50:12 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 4F58F1A90BE for ; Sat, 31 Oct 2015 11:50:12 -0700 (PDT) Received: by qgem9 with SMTP id m9so86952202qge.1 for ; Sat, 31 Oct 2015 11:50:11 -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:date:message-id:subject :from:to:cc:content-type; bh=uXCtXbUAFn9kfW8jQjnLxesXeTbfplva6XeApu1B4t0=; b=C5+efACCE0MYXz97QhQ7nc+k0WIGO1UusE64V9Bg0TKpFQy2d6TCa6/MDGJQYSU5PA 8a0ZOIVzMNheBQPiN3Ffzi8rEZqk76QJa0NSZRPJdROrQ3JVPNHNXPDI5uMzcrRT/bl2 Fx09dt5Q0ayS83aYacMWU48RxYOVkZUdsjsQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uXCtXbUAFn9kfW8jQjnLxesXeTbfplva6XeApu1B4t0=; b=hSrFOTfUfKdU07EiLHbYrQaSbgQZ/QZO/eKhS7SW+d1cqG9cIMCDTXcaP3OP4737cq rxgeZnE/+P/sV5pJUjReA4G3kCG4aDHPJo6LP7KLGxUyilv/6CFJy/TBZxK0qNxVJBEB KVhTou1t/w/Elee/e6ztgDYi5qkiiTtDYDj4sAArp7lbQdM0dqKmHDHpJUn1ApF//H+J Szxhme2cHf4sRRBEXhBR2uAvk3RmpNIqSXlp2BRLG2S9fgXRkf/nrv8BqAOTOIRVmYLi V+6gYWHHlKS4AsgYvO63WqhruyEnB37DP5uv9+uCSHKy5fIozedORV8efpjx/lNaXLCN q4bw== X-Gm-Message-State: ALoCoQmLPfsKUHDEO+zIs+9TDF2NAgGUcRYB5XJncCFpMiS8Wsmn2E5XiO+7quT7PSN5npmyqBmh MIME-Version: 1.0 X-Received: by 10.140.238.139 with SMTP id j133mr19876067qhc.78.1446317411515; Sat, 31 Oct 2015 11:50:11 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.55.98.207 with HTTP; Sat, 31 Oct 2015 11:50:11 -0700 (PDT) In-Reply-To: References: <20151019200150.15068.51622.idtracker@ietfa.amsl.com> Date: Sat, 31 Oct 2015 11:50:11 -0700 X-Google-Sender-Auth: fizIaiyy27LOucYdwpcVXHNycWo Message-ID: From: "Kurt Andersen (b)" To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1135c8e08bd7bc05236b03ef Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-08.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 Oct 2015 18:50:15 -0000 --001a1135c8e08bd7bc05236b03ef Content-Type: text/plain; charset=UTF-8 On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy wrote: > Sorry it took me so long to get to this, but here's the review I managed > to crank out on my flight to Tokyo today. It's largely editorial. > Thanks for the notes - I've started folding them into the source XML for a -09. --Kurt --001a1135c8e08bd7bc05236b03ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 31, 2015 at 4:56 AM= , Murray S. Kucherawy <superuser@gmail.com> wrote:
Sorry it took me= so long to get to this, but here's the review I managed to crank out o= n my flight to Tokyo today.=C2=A0 It's largely editorial.

Thanks for the notes - = I've started folding them into the source XML for a -09.

<= div class=3D"gmail_extra">--Kurt
--001a1135c8e08bd7bc05236b03ef--