From nobody Thu Nov 1 16:56:27 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E14129C6A for ; Thu, 1 Nov 2018 16:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=YBPrk3CV; dkim=pass (1536-bit key) header.d=taugh.com header.b=JsLpL8mD 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 4xCXpnYigWIj for ; Thu, 1 Nov 2018 16:56:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0F41271FF for ; Thu, 1 Nov 2018 16:56:23 -0700 (PDT) Received: (qmail 72719 invoked from network); 1 Nov 2018 23:56:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c0c.5bdb92a6.k1811; bh=lm8TfoYqxUiYZrVm4v0F0F8R1auiX6TahO5/o0ZY8ZY=; b=YBPrk3CVeB5Lj1L8cKb4r0Uo1w+8/5O1ej8UEoaT9fSuJNHeENPqGsQ4uYhOFP0KA7Vdy6en5s4/nd7P3N21i9S4tWyzNJB0lTMBjPEWjsJFBb9ZXYkTdSczZBSX37I0C3EjZLoNXvmc1rI/PgE/qnvPMSvkmZ6jo8oSWUtIhzj9aNWDLPdFUXIcaJ9oSFhpZ76P49kG+yDb3DLENNy4ErL84cx5vqHXiYeYfWmi0Qn6holUdXyNwmZ/S2JvSHny DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c0c.5bdb92a6.k1811; bh=lm8TfoYqxUiYZrVm4v0F0F8R1auiX6TahO5/o0ZY8ZY=; b=JsLpL8mDhFjaf3MTb/H5J9xWCT19k+kcL/+bNZfJqDtpmu7/9TX8REdJ+gJkt+zM7ObCT6J6LXsAgNNL2G7xM3syie9j4KL7qed+6/qVbpQTjnbltwT8ymYo/1aiT8k7CFl43MZWXR3/UWVAz+PT2WMerx7r7qi6oc1kp/rzWEe8uJBFqLfqRZnmc2zpPR6NwLyF8km6CJyR8ZNGjuswvIxmSN5hvxuj+cWx+33GAWY8X9GI4mzoyPQGeLedGPlz Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Nov 2018 23:56:22 -0000 Received: by ary.local (Postfix, from userid 501) id AF0B52007DFEBA; Fri, 2 Nov 2018 07:56:21 +0800 (CST) Date: 2 Nov 2018 07:56:21 +0800 Message-Id: <20181101235621.AF0B52007DFEBA@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <9957335.dUWMaE32Bo@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 23:56:26 -0000 In article <9957335.dUWMaE32Bo@kitterma-e6430> you write: >Does it have to be any harder than that? I hope not but it's still not backward compatible so it's not really any better. With the current spec, if you have two AMS or AS with the same i= that's invalid, so if you start putting both rsa and ed25519 seals, old verifiers will probably fail. It'd be interesting to mock up dual seals, send them to Gmail et al, and see what they think. I suppose we could invent new headers EAMS and EAS and EAAR for the second and later version of seals, but ugh. R's, John From nobody Thu Nov 1 21:35:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C312D4EB for ; Thu, 1 Nov 2018 21:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=j00wLS4G; dkim=pass (2048-bit key) header.d=kitterman.com header.b=iqIvBiuh 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 jq0Qr2ZdP6l0 for ; Thu, 1 Nov 2018 21:35:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE2D127133 for ; Thu, 1 Nov 2018 21:35:11 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541133309; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=0sHgn0ZWvWrM6PDZMnZTNNRHJtKt7eIbKnYvRfqXl14=; b=j00wLS4GRPQlinYi/mT802X/ii09jD5s6NP2YP0+FVIsm5qQmEPNkYLZ sWd5hKKDHcAMCzjMnsywXQheOjuiCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541133309; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=0sHgn0ZWvWrM6PDZMnZTNNRHJtKt7eIbKnYvRfqXl14=; b=iqIvBiuhRypsX9bl4bjJuL1thCoUL5+LN1EcPw08SLut0tfcjoeJZAOw FRCHhGGXYwvtSKZebtS7Sz+1ouq6whm1+tqRyOKhLvyYzpcgaVOa3wsgz7 ahCbcBRtRAq62rNFNyMxnST67UzrnLSQ7VP35JAWXkc/H4y8Duc9HE8GsH VvGyU5aqX8Q1YUWjYyt43e9v7SIJ3ntepaxWz05jVOkRUiXfyXr6fPN+6Y 4ucPaZXIoHuNNj204Z3hSTjFQwnXlahEBeGjl3otqxPAcra/ZV8kuKzzk1 vu/pzdLdtmjqU5rzqnCKqmdFOOQAusZ87o3cNaM/waOvNBRQri+Ylg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8AD07C401DD for ; Thu, 1 Nov 2018 23:35:09 -0500 (CDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 02 Nov 2018 00:35:08 -0400 Message-ID: <3936520.49DHB8P1Kr@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20181101235621.AF0B52007DFEBA@ary.local> References: <20181101235621.AF0B52007DFEBA@ary.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 04:35:13 -0000 On Friday, November 02, 2018 07:56:21 AM John Levine wrote: > In article <9957335.dUWMaE32Bo@kitterma-e6430> you write: > >Does it have to be any harder than that? > > I hope not but it's still not backward compatible so it's not really any > better. > > With the current spec, if you have two AMS or AS with the same i= > that's invalid, so if you start putting both rsa and ed25519 seals, > old verifiers will probably fail. It'd be interesting to mock up > dual seals, send them to Gmail et al, and see what they think. > > I suppose we could invent new headers EAMS and EAS and EAAR for the second > and later version of seals, but ugh. I agree having data would help a lot here. We're starting from different assumptions and there's no way to know which is better without data. I am assuming that ARC implementations have the DKIM like property of ignoring signatures signed using algorithms they don't implement. I don't know if that's a correct assumption or not. Scott K From nobody Fri Nov 2 01:27:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D9012008A for ; Fri, 2 Nov 2018 01:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNRnh6JK2p9f for ; Fri, 2 Nov 2018 01:27:21 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 747F412F18C for ; Fri, 2 Nov 2018 01:27:21 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id c16so753198lfj.8 for ; Fri, 02 Nov 2018 01:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fL4x/xmbdmTUGO6zpRQtcZfSlawQlTpLCt41Uq9Tw+I=; b=IB84uS1UECctbmV9zEHrsab1/q0jeFC4Pxt0nuGkUKbhg3g4+iGB9taOYFRWvcIB1C +LSZS9j1g9uaPDMvT3bQ8up7PbMbBi21Ww5o57FZ32dPMFa/3yWDRmCVQRcIjhj3HQuW xhITPPC5jAxzVem/ZRpJ1h1gg9k5zz16awO1U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fL4x/xmbdmTUGO6zpRQtcZfSlawQlTpLCt41Uq9Tw+I=; b=VpdwylPDjgeIpJho53akCUoKtadnL8ZUvQLVkbiku+4GSHmfrFkgRG+PiRlOz44Pb4 n5sUZQztk6kmxaSdplWXo1c47vv7D0yV39G6NhQk3g7l88uj11SCcAF6VkQKzuAkRcOY OQ9vYslcc6/MYH51rKMxmXgwNq+nXeACfBS+k0u/uozYmRgzsbYCehs/Ga6/JXJ1k+8M 7O88Tayl1OCG5zbRxJZQj8bjUmgMM+9QKKT+lDSXpmCRULViglNxQ8dFDlF+18fR6+9X k2cIAY5fCIOAf01iX+QUSrtiliJH2KMzQuu/d7vwl3Okvf3mBkSJTCRKJazVh6+l3g3w TnkA== X-Gm-Message-State: AGRZ1gIWp50D0Yq/FYJp9/oDQTuZFzWUDpIMkDPwinRtt8Lp0PfH4HeM 8S2FtmbacNd5SSY3anufe8OkjhW/TnX46qMJImifqHLpC38= X-Google-Smtp-Source: AJdET5dnWCE27NY3bsllUBDTiGpudAoAeSJ8buY5l6QyoNGMzVFvxwmF34FUffftgyCQdpESgSCsIuJS4kgLnVlWkGk= X-Received: by 2002:a19:df41:: with SMTP id q1mr6521784lfj.25.1541147239246; Fri, 02 Nov 2018 01:27:19 -0700 (PDT) MIME-Version: 1.0 References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> In-Reply-To: <20181101235621.AF0B52007DFEBA@ary.local> From: "Kurt Andersen (b)" Date: Fri, 2 Nov 2018 17:26:51 +0900 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000be02620579aa4d5e" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 08:27:23 -0000 --000000000000be02620579aa4d5e Content-Type: text/plain; charset="UTF-8" On Fri, Nov 2, 2018 at 8:56 AM John Levine wrote: > In article <9957335.dUWMaE32Bo@kitterma-e6430> you write: > >Does it have to be any harder than that? > > I hope not but it's still not backward compatible so it's not really any > better. > > With the current spec, if you have two AMS or AS with the same i= > that's invalid, > No, it is not invalid. We did try to downplay the details a bit in the spec, but if you use a different signing algorithm, you can have as many ARC sets with the same instance as you have legal algorithms. --Kurt --000000000000be02620579aa4d5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 2,= 2018 at 8:56 AM John Levine <johnl@t= augh.com> wrote:
In article = <9957335.dUWMaE32Bo@kitterma-e6430> you write:
>Does it have to be any harder than that?

I hope not but it's still not backward compatible so it's not reall= y any better.

With the current spec, if you have two AMS or AS with the same i=3D
that's invalid,

No, it is not inva= lid. We did try to downplay the details a bit in the spec, but if you use a= different signing algorithm, you can have as many ARC sets with the same i= nstance as you have legal algorithms.

--Kurt
=
=C2=A0
--000000000000be02620579aa4d5e-- From nobody Fri Nov 2 01:51:41 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013412F18C for ; Fri, 2 Nov 2018 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dTLAl+ux; dkim=pass (1536-bit key) header.d=taugh.com header.b=jX3m6PdJ 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 C1a9logKqU70 for ; Fri, 2 Nov 2018 01:51:38 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB4912D7F8 for ; Fri, 2 Nov 2018 01:51:37 -0700 (PDT) Received: (qmail 9026 invoked from network); 2 Nov 2018 08:51:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=2340.5bdc1018.k1811; bh=rhPfc0w0mCfCvx6j/8BjsXMSznuON4PzCbiu5BbsoGo=; b=dTLAl+ux2ShmaDLJ+nK4zvggSB7vORwEQjIMCq9fVmcseqAv4vwcvKGQ+CTdxAyi2ALaE1mQ4TpebT7vjRWlneGxFzVsvj87Vf0zo/hIq/GhsMCf0cghsmmZYdwMZyvzryZHaa8vqBIT4Tnf+vCvrliUbpmV2V8y/27yy3AACtn1q+QzusicBncoWw/NCj3Scg+27BsiJH8Lts/65V7B0QrSfUPo3hMQbtf0Xv5BOWPe4DExFO2YpawSKu6RpaTA 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=2340.5bdc1018.k1811; bh=rhPfc0w0mCfCvx6j/8BjsXMSznuON4PzCbiu5BbsoGo=; b=jX3m6PdJPwQqxzCzyg64swOPkHqMT5yu7zxPQtDgRKV3pK6Ydz/DAx1Oq7KgcFMIwRAtVrwWvTsFyHuuv6CzqdAayxehL0pV6j5tP39BaZ91Laqu9reSDlrjp+W7Kvsw/ZcFp0RG0pN9fQX+SNfwTD/udxBgEx5J5L6bQW4er1btOaI5rxuqAR0TQHSb9LyxG+KAUx/jdrZHR18OphS+TpXTq/i7r1iHAib5lcHq4WxgPVsFKT5ozuCbOX6ewXWN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 02 Nov 2018 08:51:35 -0000 Date: 2 Nov 2018 15:51:30 +0700 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Scott Kitterman" In-Reply-To: References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 08:51:40 -0000 On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: >> With the current spec, if you have two AMS or AS with the same i= >> that's invalid, > > No, it is not invalid. I mean ARC as it's implemented now, not in our multi-signing draft. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Nov 2 01:56:41 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515E12D4F2 for ; Fri, 2 Nov 2018 01:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9xF3cHNP2uy for ; Fri, 2 Nov 2018 01:56:37 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 301FD12F1A5 for ; Fri, 2 Nov 2018 01:56:36 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id d7-v6so827040lfi.2 for ; Fri, 02 Nov 2018 01:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=okNsrUfmFw8iocUv2jEBlkNus4zmtYTv+mxrkW0CVR0=; b=GQscTTJHd3I8DcMnPSxVg4ck8hMYUF1VDGRHLRRzD2puattbQKf1v4YTKXvpjD3Ghc UPNS7kONmcMDbLQKhV8Co9MscVWBhU4S4CFqg20gwzWdvt6dDfuFlC0qGaLk1xLQdTij yigMyMURqm18eS55JJWkbg+iyJXf8Tjv6Aurw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=okNsrUfmFw8iocUv2jEBlkNus4zmtYTv+mxrkW0CVR0=; b=POyv5xzscV5EckHxBUPKJ08yFSThB5hpC8Jn/ds4IrKawRyNITM/tkTtYcw65Lhon8 zef3CTih/GifHvbj4u01ZzT+SiUaudwpjXTkZmgyvk8865Ud8H/cItIiiRop2+z+7vvd 0LXqc72ZfeuyFWLlyBjvx0hMtmDL8fnS4+2JivsrbNMo93+Oht5YVFdPHJQHs8IqfJiy BbW/gxmPQ6gYppQz2F+tbuLEiad8NUHoymIJm9ZFYq1LXQKrYsMacAVs8KL/EfCAJu02 9PnkTaWVlpDD+kiIIx4YquphWiDtcLfEkzrhukHUkxtxxyaUd1MjfwxsWg6PCRu3N2q2 GuFA== X-Gm-Message-State: AGRZ1gJ2UM4jn/HmHZ+tpATBzafbyDkFjhduXurhIo5wZaUvC+jDVqKS ModNuQYDbEPa+6I65de/My1B34kQcKPCHO34+PRnwg== X-Google-Smtp-Source: AJdET5dzISn7RsFI5PT2Yuq68PRQw92vhLCxmUeeKmniaik5B5QbVZmQU46Uqid3K7gp1eHw9nXH9NPrKUv9yyHTXsM= X-Received: by 2002:a19:cec8:: with SMTP id e191mr6239648lfg.13.1541148994079; Fri, 02 Nov 2018 01:56:34 -0700 (PDT) MIME-Version: 1.0 References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 2 Nov 2018 17:56:06 +0900 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="00000000000056a6680579aab643" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 08:56:40 -0000 --00000000000056a6680579aab643 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 2, 2018 at 5:51 PM John R Levine wrote: > On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> With the current spec, if you have two AMS or AS with the same i= > >> that's invalid, > > > > No, it is not invalid. > > I mean ARC as it's implemented now, not in our multi-signing draft. > It seems like a poor implementation choice to be enforcing something which is not part of the spec :-), especially when there are parenthetical comments and references to things like ARC-MULTI to warn you against leaping to foot-shooting enforcement choices. --Kurt --00000000000056a6680579aab643 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 2,= 2018 at 5:51 PM John R Levine <johnl= @taugh.com> wrote:
On Fri, = 2 Nov 2018, Kurt Andersen (b) wrote:
>> With the current spec, if you have two AMS or AS with the same i= =3D
>> that's invalid,
>
> No, it is not invalid.

I mean ARC as it's implemented now, not in our multi-signing draft.
=

It seems like a poor implementation choice= to be enforcing something which is not part of the spec :-), especially wh= en there are parenthetical comments and references to things like ARC-MULTI= to warn you against leaping to foot-shooting enforcement choices.

--Kurt=C2=A0
--00000000000056a6680579aab643-- From nobody Fri Nov 2 02:07:14 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D712D4F2 for ; Fri, 2 Nov 2018 02:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=dXaoaDNv; dkim=pass (1536-bit key) header.d=taugh.com header.b=N+rhxTJt 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 J8Vp9H4xWNA0 for ; Fri, 2 Nov 2018 02:07:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA82C1277CC for ; Fri, 2 Nov 2018 02:07:10 -0700 (PDT) Received: (qmail 13721 invoked from network); 2 Nov 2018 09:07:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3594.5bdc13bd.k1811; bh=MbQyZjN0ypRfcafAJY5qe0pXS+qPV1El63QSPRckafQ=; b=dXaoaDNv2ltXH+9ryFAvVhglPd0ZgjX3asWO5Ao2WQkiyMBLjO2grrhQbXommam19OX7+AnNL2IvFDAbm6JtTRpVg4a/lFJ95lJvTLCImeSNa85opF6pXy7bnT4Y7Wsg/MOVO3NHqRdBXOEzBSV/JoFT9XTxZ9DqnP0aOI0WDWgodYbak7WUVk542iSX/0qU18NKKGGXLz/rH5GF1KJgeDcadbdDfUi5eoWJ4H4ODf+x/MOykOopCBlyE3bC6Hqo 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=3594.5bdc13bd.k1811; bh=MbQyZjN0ypRfcafAJY5qe0pXS+qPV1El63QSPRckafQ=; b=N+rhxTJtxJ1LGFqGc4HZ7eO+kPkyEGsupzvTBwyLpiZrw89EPPh/mh2uQIQewM/tWHsThXpbmbQKzIq4dNEkYaDcgKXZQpiJu8mIO4E+wdx+DK8wYft+332H731TS2W4yls06FNPFSm6/YBIjLpf9H0MJ48/eZMFkZS2IAnFiYGcOfyu7s8B7q73+N8gR5Sr+V8n6hPcn0q/EoLyjhjsKgFKI0cQwGkMXoTSmBhdLBVaQxn2xB0hbnjqGrY6i7g2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 02 Nov 2018 09:07:07 -0000 Date: 2 Nov 2018 16:07:03 +0700 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Scott Kitterman" In-Reply-To: References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 09:07:13 -0000 > It seems like a poor implementation choice to be enforcing something which > is not part of the spec :-), especially when there are parenthetical > comments and references to things like ARC-MULTI to warn you against > leaping to foot-shooting enforcement choices. Here's what the spec says: 3. Validate the structure of the Authenticated Received Chain. A valid ARC has the following conditions: 1. Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS). I don't see where it says "except you can ignore the ones that don't validate particularly if they have funky algorithms." The perl ARC module checks for dup headers and I don't think that's unusual. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Nov 2 02:09:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA93412DD85 for ; Fri, 2 Nov 2018 02:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=AH6+cqUc; dkim=pass (1536-bit key) header.d=taugh.com header.b=aeb0JmCX 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 oUZRfTJTQkPp for ; Fri, 2 Nov 2018 02:09:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F5E1277CC for ; Fri, 2 Nov 2018 02:09:04 -0700 (PDT) Received: (qmail 14237 invoked from network); 2 Nov 2018 09:09: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=379b.5bdc1430.k1811; bh=AIINM81D+NiD9+FOA4shT/CV/vixiPiPVyqkNHE1lcc=; b=AH6+cqUccyWrGr+fnt+ylbNmOVFKEc9cnmt8jwFShS4GjGz8TcwyTzsnPwrK3ktW2s9df0PRFMd+S6MWXHTnkc9L+2gI7p2zCoi+uKb4PXZTgKzgo3YbPYfXejzS6Owy8Y+KVE2a+A7gFsEXUl8ljxjITMavIn4PQS+pjS7snIyldnCnT7y4v/YPyQ3yrskxqann7Ed6HtzhMTChyd0cbm1unb+Y59lg4oJVbOfLnlTwEtW0DjChlXIM1iWA/aV1 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=379b.5bdc1430.k1811; bh=AIINM81D+NiD9+FOA4shT/CV/vixiPiPVyqkNHE1lcc=; b=aeb0JmCX+B6DBVvawGSJlJcegl2FYPK0DC/hPYzTk74GvqFTjCvmpjJJY3usLPTfrBbs8DsxCclJu9wrjNvy7RRg9mtmgv0REnMnEHi0Ije4MmWIfy/ap9SgrFdKoyL3KRfByBtveny4zdfJqo0bKCysKdBdGkSVSrgFHj0NfE3RjlC8ssltPNdI7t0+cC1lP8d67gm2s6yBFOxqc/4SNBrUgxalTqwcfp86fApXRSKINj1OzUX2tZZ9jRbKdiGP Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 02 Nov 2018 09:09:03 -0000 Date: 2 Nov 2018 16:08:58 +0700 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Scott Kitterman" In-Reply-To: References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 09:09:07 -0000 On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: >> I mean ARC as it's implemented now, not in our multi-signing draft. > It seems like a poor implementation choice to be enforcing something which > is not part of the spec :-), especially when there are parenthetical > comments and references to things like ARC-MULTI to warn you against > leaping to foot-shooting enforcement choices. I see it also says: Valid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm. I'm reasonably sure that doesn't match a lot of running code. I'm particularly thinking of gmail here. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Nov 2 02:13:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D927B12F1A5 for ; Fri, 2 Nov 2018 02:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mKq7bree_Pg for ; Fri, 2 Nov 2018 02:13:39 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 DB7081277CC for ; Fri, 2 Nov 2018 02:13:38 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id q186-v6so1118132ljb.5 for ; Fri, 02 Nov 2018 02:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0uC60tzFsZRjheiOdYQyRT9qmVYG36xji/nRlP9rZVM=; b=Hk2kcyNWIHZH9Nd0mlcssTH+FSZBRqf5gt7+cODGkijalvTo93KJE5BEBaYAQbd3Cd tu+sd1I10ItJkA1HpMU3Jm7BMeWJkUWQqlfLXSV64HebKzkDV46yjDPefJ59LZa4wF5d pd5xPj8sX+LryUwj4JD85K4H0/0rvD/hPvXRU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0uC60tzFsZRjheiOdYQyRT9qmVYG36xji/nRlP9rZVM=; b=sP/OtvlJAToXd3Af6BvuPhvnJ+JkD8H+qevZF2ZRia3auP6+sgnHQFX6y1zhfOCT9j naF11J7Q0uJ715nJyjbcJcovktEpIM6L6BIKYBtYSMuw8GX2dDsFo004ITfRa3wSE+SO IDOFH88rJE+9EIyvQBg9D12FrDc4pqaSs5LFpFSMPNkp4xfSdEnBeErxBHLowlSVeKp7 CouNTvKK9oKdyqe/VzTV9Ue/7RhvMxF2ayU9ARzOSgywcP7YO1fwKACvCBOUcFn67tgG aCdxvoVfsAXY8ayQLYUU1MTOv1xJF4bTRTdbz1aGmweThVuBrr110dnOL+j3wg8pElLu fnSA== X-Gm-Message-State: AGRZ1gJ4QsLnYciZM8cpql86FIYK3s9XQramj/KpjMARvGzOCRl2mki6 B7gGNx5Vo71wc8vFIZF8s1aGRBwuRj773q9ds5Z/MQ== X-Google-Smtp-Source: AJdET5c7pTNOCoE/E4Zf0eYSqfUL9fhDwRWuB36PsebPA/piFybH25ob/yP4oGh8VcTneDKWoBJj3QKkr9WoI5v6/4o= X-Received: by 2002:a2e:5b1d:: with SMTP id p29-v6mr7036516ljb.176.1541150016715; Fri, 02 Nov 2018 02:13:36 -0700 (PDT) MIME-Version: 1.0 References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 2 Nov 2018 05:13:21 -0400 Message-ID: To: John Levine Cc: dmarc@ietf.org, Scott Kitterman Content-Type: multipart/alternative; boundary="0000000000004aceec0579aaf37c" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 09:13:41 -0000 --0000000000004aceec0579aaf37c Content-Type: text/plain; charset="UTF-8" On Fri, Nov 2, 2018, 18:09 John R Levine On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> I mean ARC as it's implemented now, not in our multi-signing draft. > > It seems like a poor implementation choice to be enforcing something > which > > is not part of the spec :-), especially when there are parenthetical > > comments and references to things like ARC-MULTI to warn you against > > leaping to foot-shooting enforcement choices. > > I see it also says: > > Valid ARC Sets MUST have exactly one instance of each ARC header > field (AAR, AMS, and AS) for a given instance value and signing > algorithm. > > I'm reasonably sure that doesn't match a lot of running code. I'm > particularly thinking of gmail here. > That should be easy to test but not with a tiny keyboard as I board my flight from ICN --> BKK. --Kurt > --0000000000004aceec0579aaf37c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, = Nov 2, 2018, 18:09 John R Levine <joh= nl@taugh.com wrote:
On Fri, 2 N= ov 2018, Kurt Andersen (b) wrote:
>> I mean ARC as it's implemented now, not in our multi-signing d= raft.
> It seems like a poor implementation choice to be enforcing something w= hich
> is not part of the spec :-), especially when there are parenthetical > comments and references to things like ARC-MULTI to warn you against > leaping to foot-shooting enforcement choices.

I see it also says:

=C2=A0 =C2=A0 Valid ARC Sets MUST have exactly one instance of each ARC hea= der
=C2=A0 =C2=A0 field (AAR, AMS, and AS) for a given instance value and signi= ng
=C2=A0 =C2=A0 algorithm.

I'm reasonably sure that doesn't match a lot of running code.=C2=A0= I'm
particularly thinking of gmail here.

That should be easy to test but not w= ith a tiny keyboard as I board my flight from ICN --> BKK.

--Kurt
--0000000000004aceec0579aaf37c-- From nobody Fri Nov 2 20:25:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07486130E13 for ; Fri, 2 Nov 2018 20:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GFHU1j2qNGu for ; Fri, 2 Nov 2018 20:25:29 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 2E10D1277C8 for ; Fri, 2 Nov 2018 20:25:29 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id n26-v6so2619682lfl.1 for ; Fri, 02 Nov 2018 20:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bALgdSaGaj+iAbhb2EFyh83C14b3sitnj55tqU7yl+c=; b=Hgn5skJYXpCzjqEA6CxWnAp8LY0rnDes5tcv0SfSy0IeKk/bmalcz9CB1IP9iGhigi FUlnKGiQ/s3bactNvuU9EO3d5fafqP9bQlL8FX78dwUHIbroKV0HlzV44B2feNQmsn4o Dc45tcC0txt8luCTasb+VOIv9v7eJl67zb0eCAb5MuRDJKKvke0LzN6CEKedu0S7CB9I 7id0qc9aMaNxA0a66nEaPwYfZEan8E1G/mpeWZEvPPg+W/ejzv45rVPacH6nIdrTYwFV Ltc8ZGntk7cFtQBGzsfuxjG8KWedBzq3F8AWzsplyq6gREcmjA4AVAAxZM6nYEfnqjeA OHig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bALgdSaGaj+iAbhb2EFyh83C14b3sitnj55tqU7yl+c=; b=swE6/NS9uKPOwH6n84zJezWSF1RrGVgmIqlQWw8HCrJtFQJxSbBkGo/FJuenBLIv3c AAqQKc0At2PHaTzttmbJ2ZvDQxzx+2MeZnB3Wz+qmWLwBSidLLKly+B2tJ5FREakiUv7 Vejw8EdRhsJlB0rJmCDYUJYTPWiMIZRVq2EXrcYkjoThGFHxfq+cxXh/DmqykxIKqpWQ ldG52GGBdsoiJPN3WKVpp5EdAKWaHdslM2mmKL+nAiS/YNaQc/QopL434EfTnXKW/uNp +b5Vrxrbon/FB/qNorCcKWvX30B1SlPeYwHGpAuLhYzPhdrs9sJkr/8wT//yMpxxYmQ7 T21w== X-Gm-Message-State: AGRZ1gIjkqN1ifNPGNOjvYXYOWz3EzxaS8ZrO41GRAt27Rm5q646SFQ3 U/bG9WXohsoIKDGGXh4G1QR/RYgyr2AKTwZOsaH8WL7F X-Google-Smtp-Source: AJdET5fVs0UGVSVJlIFxPgITwLdcHTKzpLVRoWyFk0ObbWOVdHQa7LU6BY/4ZDPdR8ebVOmU9KHqUn4o6oWYU9vvs3g= X-Received: by 2002:a19:6f0a:: with SMTP id k10mr7866885lfc.119.1541215527270; Fri, 02 Nov 2018 20:25:27 -0700 (PDT) MIME-Version: 1.0 References: <3eea2f77-8aea-4f49-80f3-d96b639c378a@isode.com> In-Reply-To: <3eea2f77-8aea-4f49-80f3-d96b639c378a@isode.com> From: "Murray S. Kucherawy" Date: Sat, 3 Nov 2018 12:25:15 +0900 Message-ID: To: Alexey Melnikov Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000067fc90579ba34ad" Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 03:25:31 -0000 --000000000000067fc90579ba34ad Content-Type: text/plain; charset="UTF-8" On Thu, Oct 25, 2018 at 8:03 PM Alexey Melnikov wrote: > 1) I am not sure that deleted IANA registry descriptions (when compared > to RFC 7601) is the best way, considering that this document obsoletes > RFC 7601. I think it would be better to just keep the text and add a > sentence saying that it is unchanged from RFC 7601. But I am happy to > hear what IESG has to say about this. > Sorry, what's being deleted? RFC7601bis doesn't (shouldn't!) be deleting anything; it adds a couple of entries and makes itself authoritative for the registration of the header field, but otherwise nothing is changing. I thought that was pretty explicit. 2) The following took really long time to verify for correctness: > > [...] > > NEW: > > "value" is as defined in Section 5.1 of [MIME], with "quoted-string" > updated as specified in RFC 6532. > Fixed, though I won't post a new one until after LC (unless you think it would be useful). -MSK --000000000000067fc90579ba34ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 25, 2018 at 8:03 PM Alexey Melnikov <alexey.melnikov@isode.com> wr= ote:
1) I am = not sure that deleted IANA registry descriptions (when compared
to RFC 7601) is the best way, considering that this document obsoletes
RFC 7601. I think it would be better to just keep the text and add a
sentence saying that it is unchanged from RFC 7601. But I am happy to
hear what IESG has to say about this.

S= orry, what's being deleted?=C2=A0 RFC7601bis doesn't (shouldn't= !) be deleting anything; it adds a couple of entries and makes itself autho= ritative for the registration of the header field, but otherwise nothing is= changing.=C2=A0 I thought that was pretty explicit.

2) The following took really long time to verify for correctness:

[...]

NEW:

"value" is as defined in Section 5.1 of [MIME], with "quoted= -string"
updated as specified in RFC 6532.

Fixed= , though I won't post a new one until after LC (unless you think it wou= ld be useful).

-MSK
--000000000000067fc90579ba34ad-- From nobody Fri Nov 2 20:44:18 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D408F130E1D for ; Fri, 2 Nov 2018 20:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=jcaS9J5/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=WHifSnzt 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 EM1o-HlV58c2 for ; Fri, 2 Nov 2018 20:44:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B99128A6E for ; Fri, 2 Nov 2018 20:44:14 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541216653; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=9O5tQTZrCXrSSMYItQ8K9mr1YhC3gbPQ5vaejHRwsgk=; b=jcaS9J5/vB0qkl9q+HHfE5xgqImvujh7Ab5EWRwptVNT5DyKdxrBKEm+ pj+xiqtL+Km91/H8Wltz7zw/BTxFCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541216653; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=9O5tQTZrCXrSSMYItQ8K9mr1YhC3gbPQ5vaejHRwsgk=; b=WHifSnzt+x5MIBMeT6IJkRIEFF0syejAtHGDhdvGx5/jNSArMxcr5CUf tZlTkujfhJAXMHkHHsRy3tS8b/UM+av/0IBALWk2eaRLkatNurSs0IS1kf R9Xa8CE9YYoIy3yLbUaoS9E7V1DPmED4zQdAc57N2k166nxIomJ+AbMnjQ 36H1gaXPlbvbSvx5rfN9FNXsVctz0y2qOwbZxt9JDVnN0Y7f7TcguI7WOL IW9OnA45ZR9b27I72++vhPt1CwVLrQ3fnFwXrDry0ULfWYMn+Cndah+Xud g3WKOmEqAZxpx5jKDkxe97R+10oR4+TTHUdjStcAnxRg0JR9N2wEfg== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6AF4CC400ED; Fri, 2 Nov 2018 22:44:13 -0500 (CDT) Date: Sat, 03 Nov 2018 03:44:07 +0000 In-Reply-To: References: <3eea2f77-8aea-4f49-80f3-d96b639c378a@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <4E1476B7-C994-43C4-9449-55B9771E5C84@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 03:44:17 -0000 On November 3, 2018 3:25:15 AM UTC, "Murray S=2E Kucherawy" wrote: >On Thu, Oct 25, 2018 at 8:03 PM Alexey Melnikov > >wrote: > >> 1) I am not sure that deleted IANA registry descriptions (when >compared >> to RFC 7601) is the best way, considering that this document >obsoletes >> RFC 7601=2E I think it would be better to just keep the text and add a >> sentence saying that it is unchanged from RFC 7601=2E But I am happy to >> hear what IESG has to say about this=2E >> > >Sorry, what's being deleted? RFC7601bis doesn't (shouldn't!) be >deleting >anything; it adds a couple of entries and makes itself authoritative >for >the registration of the header field, but otherwise nothing is >changing=2E I >thought that was pretty explicit=2E What should the reference be in the registry for the existing entries? RF= C7601 will be historic, so that hardly seems right and they aren't listed i= n 7601bis so that doesn't work either=2E Scott K From nobody Fri Nov 2 21:00:56 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02351130E2A; Fri, 2 Nov 2018 21:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mjiZrhAfcFL; Fri, 2 Nov 2018 21:00:51 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 D44AB130E4E; Fri, 2 Nov 2018 21:00:41 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u6-v6so3429296ljd.1; Fri, 02 Nov 2018 21:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=PqAcz76qpb9iW8LpzkonpHmjs7IvN8oD6ztaFT97BJzL3RsY4H5nSFLjMcfsDMIuJn Bjbr66usOuPx3/5ZCBl20J4cNW26fsM2HaTL4SEMmyypfqXpCDML0eVx65zslBG7Gp1f QTuJg9qhJYLrt95aro0hyVLLjGCNMtkgZXUjr9HatA6zGnSsRgvJV49aUmUU7AjNfgQu nQbbYVEvUtLD+ZP7TJ//ZsZZXDAyGn530umdkHlddAOQ/NUkn2xPTZtedn8NHPO5DrHK as+OhL30sDwEftTOuzIGb+q1xZnqpQKMOGfBoEnDmpQX3YhHEgZVB43YQYpmvtSBgf0S 1DMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=GuNz5wLB2oVBD754uu+5c2yOjGO8koF4jN2wk/grD1PYjKCA8kjZTcQi0dOlMkerJ6 LQr4zY7Brt0JO7feIqD1684ArYzU+h4V3cjPEiVZHvVjxnjo4BTYlV6dDRsIaif5zM+p 9lw1MGROTTxb0BZMf8h+vspcTQu6uCaXojBhbeRO5z/SI6btaw4b3t8vCDsgqy3ZSFfH bQR7yRTACf7GAXgvaHpLB2prXwKsNabdjKD65vP9TYK0+XQJ/ljd6LzeGIgdBhZtvFTW mR0w27DTQr/UXoEuuhklD/E0LYKUuXUKxon0fdigNPju/03fz/p0Pqx8ERsxcGtJbl8+ EAvQ== X-Gm-Message-State: AGRZ1gJaMKA1XlZK7NJ6mWtfmbLv869zb68RE+XHi3C8TBBvk2C/uUUw rWGIoMU82q3UAVNT3RLzew9yFZwNWcmeLDrXE2Y= X-Google-Smtp-Source: AJdET5faygPzBYA21nG7Q678YA6C+lVW60rX7ESr/lGwb/dIW32ZsCHHm7Nl1aRVN5ukV+xU3vBdS1HMWiclHf2CMFU= X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr9054104ljc.141.1541217639751; Fri, 02 Nov 2018 21:00:39 -0700 (PDT) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: <154100859354.5360.795312478907721541@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sat, 3 Nov 2018 13:00:27 +0900 Message-ID: To: rifaat.ietf@gmail.com Cc: secdir@ietf.org, IETF DMARC WG , draft-ietf-dmarc-rfc7601bis.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="000000000000f066ad0579bab1da" Archived-At: Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 04:00:54 -0000 --000000000000f066ad0579bab1da Content-Type: text/plain; charset="UTF-8" On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef wrote: > Section 7.1. Forged Header Fields > > In addition to a recommended solution, this section has list a potential > alternative solutions which the document then states that it is not > appropriate > for this document to specify which mechanism should be used. > > Since an implementer is not expected to do anything with this information, > it > might be more appropriate for this to be moved to an appendix at the end > of > document. > Implementers need to be aware of these things in order to make informed handling decisions, but we also acknowledge that we can't propose a single solution that will work for all operational environments. That's what this text means to convey. By my read of RFC3552, that's what this section is for, rather than an appendix. Section 7.2. Misleading Results, First paragraph, last sentence > > "In particular, this issue is not resolved by forged header field > removal > discussed above." > > which seems to be in conflict with the following statement from section 5: > > "For simplicity and maximum security, a border MTA could remove all > instances of this header field on mail crossing into its trust > boundary." > They're not in conflict. Even if I remove all instances of this header field at ingress and then evaluate DKIM (for example), I have no idea if a valid signature from "example.com" should be interpreted such that I trust that message more (or less). The two paragraphs you're talking about solve different problems. > Section 7.2. Misleading Results, Second paragraph > > "Hence, MUAs and downstream filters must take some care with use of > this header even after possibly malicious headers are scrubbed." > > How do you expect an MUA or downstream filter to act on "take some care"? > Can you elaborate on that? > If you are a spammer or malware distributor, you can elicit a DKIM "pass" by simply creating your own domain and signing your bad email with that domain. The fact that you got a "pass" doesn't tell you anything about which domain's signature succeeded, nor does it confirm the message content is safe or trustworthy in any way. "take some care" means "keep this in mind while deciding how to render a message to end users, who might not know to even look at this". 7.3. Header Field Position > > This section explains that headers fields are *not* guaranteed to be in a > specific order. The section then states that "there will be *some* > indication..." > > Since the order is not guaranteed, what do you expect an implementer to > take > away from this? > "in the general case" and "but most do not". So: Most of the time, you can rely on header field ordering to determine the sequence of handling. You are at least certain about whether you can trust the tail end of that, because you know your own environment from the ingress point. 7.8. Intentionally Malformed Header Fields > > This is a general issue with any header. Is there anything specific to > this > header that an implementer should pay attention to? > No, not really, but at the time this text was originally written (see RFC5451; this is about the fourth version of this material), it was felt this was worth adding. -MSK --000000000000f066ad0579bab1da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 1, 2018 at 2:56 AM Rifaat She= kh-Yusef <rifaat.ietf@gmail.com= > wrote:
Section 7.1.=C2=A0 Forged Header Fields

In addition to a recommended solution, this section has list a potential alternative solutions which the document then states that it is not appropr= iate
for this document to specify which mechanism should be used.

Since an implementer is not expected to do anything with this information, = it
might be more appropriate for this to be moved to an appendix at the end of=
document.

Implementers need to be aware= of these things in order to make informed handling decisions, but we also = acknowledge that we can't propose a single solution that will work for = all operational environments.=C2=A0 That's what this text means to conv= ey.

By my read of RFC3552, that's what this section is for, rath= er than an appendix.

Section 7.2.=C2=A0 Misleading Results, First paragraph, last sentence

=C2=A0 =C2=A0"In particular, this issue is not resolved by forged head= er field removal
=C2=A0 =C2=A0discussed above."

which seems to be in conflict with the following statement from section 5:<= br>
=C2=A0 =C2=A0"For simplicity and maximum security, a border MTA could = remove all
=C2=A0 =C2=A0instances of this header field on mail crossing into its trust=
=C2=A0 =C2=A0boundary."

They'r= e not in conflict.=C2=A0 Even if I remove all instances of this header fiel= d at ingress and then evaluate DKIM (for example), I have no idea if a vali= d signature from "example.com"= should be interpreted such that I trust that message more (or less).
The two paragraphs you're talking about solve different pr= oblems.
=C2=A0
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.

-MSK
--000000000000f066ad0579bab1da-- From nobody Fri Nov 2 21:24:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE50130E06 for ; Fri, 2 Nov 2018 21:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xGYKH48Kaaq for ; Fri, 2 Nov 2018 21:24:45 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FFF12958B for ; Fri, 2 Nov 2018 21:24:45 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id z80-v6so3419734ljb.8 for ; Fri, 02 Nov 2018 21:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jjbgndV/N2CQHd0EC5mXlxmuwCILR1IZwTUqJIYodUw=; b=Sdpat5oBmCUHt+VG1tbORjON1ToWtbO7L0j/CXMfD451M27KdTd26ZDeOPB4Nv8E03 mLCc1XuGMUsIoQKMiZeT8bz25mTNrEVFaqEU8PTFyxeCj+be+5qP2aFYlMG5uROBZt2T +qCtPf6IDoECPzs2tg9SkLhkFgSZHr0y/V5oqWuy6lnfjHGpffo5qFbB8/wWJXVGBnuL ABRIll9Nz7UiJpiFNLizWL0XKi+Ltfw6BUfGwQkDxBVy756SSP1HZFcfThuVVGaAxjmt k5AgLx1LpdajGAAqnzSvI+7VXVtB1a/lpoOYdzOLU7t2HFm0GyFJcW+x0Ubiui7nRf/l EqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jjbgndV/N2CQHd0EC5mXlxmuwCILR1IZwTUqJIYodUw=; b=ezPIdLVrPeNZmq/1DyJG7EGZb1LK6EOAaJM4oCZmDz9YpdZ1vOGWdeLjrfP2us2WeC 1fIDy8P8Nb0SZTsw3fegjr8OrNTnK2sofXbK61NqiTpMFnw2LW9F0gw3SaX7PxkGxZd/ vR0taRouum/K/zviJTXkakQ3mKnJKerwlYuFNFqPik9IPt5I3DY4IxaK7+UokVz/4ZGz aBwZt7Uan7fU3HZQonkJnc37EJFEHAC24zewB7ZJ8Voe/FcI9AaK7RKEdSLvCRk/W7GV /jZR4WNkZ5WX9blsWU/54ZOWdAfADYaSoPNJOK4qBoMiDTrUl/DjRX2IcN1prAUl+fUS AL6Q== X-Gm-Message-State: AGRZ1gJNuB3ibcVjSsJIVwmuznlzaQPVFbfr2ImcLWsCCIJ0ZpMwUlos tAy0DIHSz9OxEWWZczrOIVoxQZaQIv+KLURKXQfiRFHX X-Google-Smtp-Source: AJdET5eabG00ZZgE2cV8x//A976FS/mekGS8PbXxHdFPtmERY54g1s4GYfn/RUT81mzNg50tp+C4c9NW4WXG0Bl+qJw= X-Received: by 2002:a2e:9e53:: with SMTP id g19-v6mr10134506ljk.39.1541219083304; Fri, 02 Nov 2018 21:24:43 -0700 (PDT) MIME-Version: 1.0 References: <3eea2f77-8aea-4f49-80f3-d96b639c378a@isode.com> <4E1476B7-C994-43C4-9449-55B9771E5C84@kitterman.com> In-Reply-To: <4E1476B7-C994-43C4-9449-55B9771E5C84@kitterman.com> From: "Murray S. Kucherawy" Date: Sat, 3 Nov 2018 13:24:31 +0900 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fb45720579bb07fb" Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 04:24:47 -0000 --000000000000fb45720579bb07fb Content-Type: text/plain; charset="UTF-8" On Sat, Nov 3, 2018 at 12:44 PM Scott Kitterman wrote: > >Sorry, what's being deleted? RFC7601bis doesn't (shouldn't!) be > >deleting > >anything; it adds a couple of entries and makes itself authoritative > >for > >the registration of the header field, but otherwise nothing is > >changing. I > >thought that was pretty explicit. > > What should the reference be in the registry for the existing entries? > RFC7601 will be historic, so that hardly seems right and they aren't listed > in 7601bis so that doesn't work either. > I think your questions (to which I haven't replied just yet) are quite different than Alexey's statement that something has been "deleted". I was trying to resolve that. -MSK --000000000000fb45720579bb07fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 3, 2018 at 12:44 PM Scott Kitterman <sklist@kitterman.com> wrote:
>Sorry, what'= ;s being deleted?=C2=A0 RFC7601bis doesn't (shouldn't!) be
>deleting
>anything; it adds a couple of entries and makes itself authoritative >for
>the registration of the header field, but otherwise nothing is
>changing.=C2=A0 I
>thought that was pretty explicit.

What should the reference be in the registry for the existing entries?=C2= =A0 RFC7601 will be historic, so that hardly seems right and they aren'= t listed in 7601bis so that doesn't work either.
<= br>
I think your questions (to which I haven't replied just y= et) are quite different than Alexey's statement that something has been= "deleted".=C2=A0 I was trying to resolve that.

-MSK
--000000000000fb45720579bb07fb-- From nobody Fri Nov 2 21:44:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F69130E0E for ; Fri, 2 Nov 2018 21:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=6BnNw5Sn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=pFSoIZ4I 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 QTRQUO2Xmj2e for ; Fri, 2 Nov 2018 21:44:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2D8130E06 for ; Fri, 2 Nov 2018 21:44:33 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541220270; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=56m0J7Ypg3/O/qk/40ijLGbgEZ6qev/Lsd4LxB91B0I=; b=6BnNw5Snkrcn27pCS77lsSRSG/8Ny1uKQsuhqxJWyNzHtwG4QZWJ19Cs KhbMpq7Ug1zofOmZd4yc3o1CIWEsCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541220270; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=56m0J7Ypg3/O/qk/40ijLGbgEZ6qev/Lsd4LxB91B0I=; b=pFSoIZ4Il7OAM3wfztyUuPZkd8Fq4Jk/umljbYMawRNEsv2ZVz1bAY8t ZDiRjStSWJSWKsxUitPVqYOGTjSEasmr3MI9m7WM3x0p9Lqf0Ggz7JcxKA 9stiYHPo8KhpFPscQd/uRzueepLXM1lKif1l7SoMIpfU+j4fZC84qGvyup +ckDR+PeqaAZgeph0dsWrUbp+9Hy5FcRYlDispn3wLfTLstD0+8044lbXq /xyXwSevHKylfChs9596A4NEmbx/diWTczSvGj9MeWq+hwXfU8RYztVErC AGr16oEwShczuAxPzmo9zB6JFU6tNEBjLhvVYzeaDW3UPFaxD7Mo5g== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0BAEAC40229; Fri, 2 Nov 2018 23:44:30 -0500 (CDT) Date: Sat, 03 Nov 2018 04:44:22 +0000 In-Reply-To: References: <3eea2f77-8aea-4f49-80f3-d96b639c378a@isode.com> <4E1476B7-C994-43C4-9449-55B9771E5C84@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <86668460-6C5A-4641-88ED-2CDC815FA9DE@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 04:44:36 -0000 On November 3, 2018 4:24:31 AM UTC, "Murray S=2E Kucherawy" wrote: >On Sat, Nov 3, 2018 at 12:44 PM Scott Kitterman >wrote: > >> >Sorry, what's being deleted? RFC7601bis doesn't (shouldn't!) be >> >deleting >> >anything; it adds a couple of entries and makes itself authoritative >> >for >> >the registration of the header field, but otherwise nothing is >> >changing=2E I >> >thought that was pretty explicit=2E >> >> What should the reference be in the registry for the existing >entries? >> RFC7601 will be historic, so that hardly seems right and they aren't >listed >> in 7601bis so that doesn't work either=2E >> > >I think your questions (to which I haven't replied just yet) are quite >different than Alexey's statement that something has been "deleted"=2E I >was >trying to resolve that=2E Okay=2E I had a different interpretation of his comments=2E Scott K From nobody Sat Nov 3 03:49:24 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 251DC12D4EE; Sat, 3 Nov 2018 03:49:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ines Robles To: Cc: dmarc@ietf.org, ietf@ietf.org, draft-ietf-dmarc-arc-protocol.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154124216209.10246.15168950605174657081@ietfa.amsl.com> Date: Sat, 03 Nov 2018 03:49:22 -0700 Archived-At: Subject: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Nov 2018 10:49:22 -0000 Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dmarc-arc-protocol-18 Reviewer: Ines Robles Review Date: 11-03-2018 IETF LC End Date: 11-06-2018 IESG Telechat date: (if known) Summary: I believe the draft is technically good. This document is well written and clear to understand. This document describes the Authenticated Received Chain (ARC) protocol, which provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. I like that the document mentions the available implementations. Major issues: Not found Minor issues: There is a TODO in Appendix B, so I suppose further information will be added to the draft later. Nits/editorial comments: Page 18: “ptypes” →types Page 22: “concocted” → connected? Thank you for this draft. Ines From nobody Sun Nov 4 13:59:16 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985A128CB7; Sun, 4 Nov 2018 13:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QflhxqCHAnWi; Sun, 4 Nov 2018 13:59:12 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 DD66E12872C; Sun, 4 Nov 2018 13:59:11 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id t81-v6so5111634iod.10; Sun, 04 Nov 2018 13:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=KDz1euOk8M0blDuE8gOgfrsuBxLPazMim59EUkkyYIHM59xWBplHjHu6n60FDQmfHp cvH8JEQJOlJL1jX6KGt1k1XyyGwoBGLYMu7T8a9W89XvlqgQ/zgs9F/ZWjViNxpTBlIA 6cZ6gYsSaNwRYquZsXtHlZGqlmHnL6DKZCqSqAdIVx0at9AQ5WIwnmP3nwLdoGAXqk1w GBmtAt7fv7wd9N8xKLXG27nVXqZ8nrlgxFmBLNT9+lnavNzL0UY6Im+2cTnW7cbGuEkU WfqQD6ablT9zgaE3im/qg/Mzrv/Y+iRmceAwzDzl7bmfNoYyoMqaRsJ0K3rHlLZG5AH0 ooQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=swrizmZtrj5hbAWRRne08HLp3TC5ETHD8ARwcpEx0rHkgnVhXtjmrfuzr3l2s9qgrS bxyYQBbtPUjY6OgOqFr5roJ6Zub1+kFS947UzqMfvL0bHVt2I2sGDXeEiLZchDzfNZKX HiVTQw7DnTGp1mmys+iHZ5+PikFj/AkT+rwRo7ijjjvXGjjDwVrv2Dicj/bcDBLeRUiz sGHWDg6IfAz8hNoVW3AlTSljhJJZuKn1PVeLhBtk/GGJHKllzCgCt/5E6DrVHQ7wGDgg /Mg03bF7LBSd5EWWytZdf54rqnO/gIGSnf1qr/6nUBwcV8WgWA2fOzrT7QuFpPXWdJAK ilQg== X-Gm-Message-State: AGRZ1gLTkzlu3eRIkGfvuknpxCPUqa/opDpwAgIBmswBCrHav0oMFIuw 51yMNWxBlXQqichxWNcuxeGLtrWf11n95raFYYA= X-Google-Smtp-Source: AJdET5fLp9HD5ATnPratuMl/Ee9W1PC4QWfQhfm9jY0myZ1d785jnqo1LU38FWfLIGNte9q/H8+uDoeA/JcUvsghhfg= X-Received: by 2002:a6b:105:: with SMTP id 5-v6mr16961739iob.0.1541368751163; Sun, 04 Nov 2018 13:59:11 -0800 (PST) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 4 Nov 2018 16:59:01 -0500 Message-ID: To: superuser@gmail.com Cc: secdir@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-rfc7601bis.all@ietf.org, IETF-Discussion list Content-Type: multipart/alternative; boundary="000000000000e18fdb0579dde0ec" Archived-At: Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 21:59:15 -0000 --000000000000e18fdb0579dde0ec Content-Type: text/plain; charset="UTF-8" On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy wrote: > On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef > wrote: > >> Section 7.1. Forged Header Fields >> >> In addition to a recommended solution, this section has list a potential >> alternative solutions which the document then states that it is not >> appropriate >> for this document to specify which mechanism should be used. >> >> Since an implementer is not expected to do anything with this >> information, it >> might be more appropriate for this to be moved to an appendix at the end >> of >> document. >> > > Implementers need to be aware of these things in order to make informed > handling decisions, but we also acknowledge that we can't propose a single > solution that will work for all operational environments. That's what this > text means to convey. > > By my read of RFC3552, that's what this section is for, rather than an > appendix. > > Section 7.2. Misleading Results, First paragraph, last sentence >> >> "In particular, this issue is not resolved by forged header field >> removal >> discussed above." >> >> which seems to be in conflict with the following statement from section 5: >> >> "For simplicity and maximum security, a border MTA could remove all >> instances of this header field on mail crossing into its trust >> boundary." >> > > They're not in conflict. Even if I remove all instances of this header > field at ingress and then evaluate DKIM (for example), I have no idea if a > valid signature from "example.com" should be interpreted such that I > trust that message more (or less). > > The two paragraphs you're talking about solve different problems. > I thought the DKIM signature is part of this header, but I now understand that it is a separate header. > > >> Section 7.2. Misleading Results, Second paragraph >> >> "Hence, MUAs and downstream filters must take some care with use of >> this header even after possibly malicious headers are scrubbed." >> >> How do you expect an MUA or downstream filter to act on "take some care"? >> Can you elaborate on that? >> > > If you are a spammer or malware distributor, you can elicit a DKIM "pass" > by simply creating your own domain and signing your bad email with that > domain. The fact that you got a "pass" doesn't tell you anything about > which domain's signature succeeded, nor does it confirm the message content > is safe or trustworthy in any way. > > "take some care" means "keep this in mind while deciding how to render a > message to end users, who might not know to even look at this". > > I guess what I am looking for is a statement about the best case scenario for an MUA to be able to display a message with some confidence given the current state of affair. For example, if there is a valid DKIM, an Authentication-Results header with dkim pass,and the header was provided by a trusted entity? > 7.3. Header Field Position >> >> This section explains that headers fields are *not* guaranteed to be in a >> specific order. The section then states that "there will be *some* >> indication..." >> >> Since the order is not guaranteed, what do you expect an implementer to >> take >> away from this? >> > > "in the general case" and "but most do not". > > So: Most of the time, you can rely on header field ordering to determine > the sequence of handling. You are at least certain about whether you can > trust the tail end of that, because you know your own environment from the > ingress point. > > Fair enough; I think it is worth adding this sentence to make it clear. > 7.8. Intentionally Malformed Header Fields >> >> This is a general issue with any header. Is there anything specific to >> this >> header that an implementer should pay attention to? >> > > No, not really, but at the time this text was originally written (see > RFC5451; this is about the fourth version of this material), it was felt > this was worth adding. > > I guess it does hurt to remind implementer to pay attention to this issue, but I think it might be useful to state that there is nothing special about this header to avoid possible question like this in the future. Regards, Rifaat > -MSK > --000000000000e18fdb0579dde0ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, N= ov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Sect= ion 7.1.=C2=A0 Forged Header Fields

In addition to a recommended solution, this section has list a potential alternative solutions which the document then states that it is not appropr= iate
for this document to specify which mechanism should be used.

Since an implementer is not expected to do anything with this information, = it
might be more appropriate for this to be moved to an appendix at the end of=
document.

Implementers need to be aware= of these things in order to make informed handling decisions, but we also = acknowledge that we can't propose a single solution that will work for = all operational environments.=C2=A0 That's what this text means to conv= ey.

By my read of RFC3552, that's what this section is for, rath= er than an appendix.

Section 7.2.=C2=A0 Misleading Results, First paragraph, last sentence

=C2=A0 =C2=A0"In particular, this issue is not resolved by forged head= er field removal
=C2=A0 =C2=A0discussed above."

which seems to be in conflict with the following statement from section 5:<= br>
=C2=A0 =C2=A0"For simplicity and maximum security, a border MTA could = remove all
=C2=A0 =C2=A0instances of this header field on mail crossing into its trust=
=C2=A0 =C2=A0boundary."

They'r= e not in conflict.=C2=A0 Even if I remove all instances of this header fiel= d at ingress and then evaluate DKIM (for example), I have no idea if a vali= d signature from "exa= mple.com" should be interpreted such that I trust that message mor= e (or less).

The two paragraphs you're talking about = solve different problems.

I thought the DKIM signature is part of this header, = but I now understand that it is a separate header.

=C2=A0
=C2=A0
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

I guess what= I am looking for is a statement about the best case scenario for an MUA to= be able to display a message with some confidence given the current state = of affair.
For example, if there is a valid DKIM, an Authenticati= on-Results header with dkim pass,and the header was provided by a trusted e= ntity?

=C2=A0
=
7.3.=C2=A0 Header Field Position

This section explains that headers fields are *not* guaranteed to be in a <= br> specific order. The section then states that "there will be *some* indication..."

Since the order is not guaranteed, what do you expect an implementer to tak= e
away from this?

"in the general ca= se" and "but most do not".

So: Most of the= time, you can rely on header field ordering to determine the sequence of h= andling.=C2=A0 You are at least certain about whether you can trust the tai= l end of that, because you know your own environment from the ingress point= .

Fair enough; = I think it is worth adding this sentence to make it clear.

=C2=A0
7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.


I guess it does hurt to remind implementer to= pay attention to this issue, but I think it might be useful to state that = there is nothing special about this header to avoid possible question like = this in the future.

Regards,
=C2=A0Rifaa= t

=C2=A0
-MS= K
--000000000000e18fdb0579dde0ec-- From nobody Sun Nov 4 19:01:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9DA129C6B for ; Sun, 4 Nov 2018 19:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1WoNzhsxXdi for ; Sun, 4 Nov 2018 19:01:36 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 A3E2F129619 for ; Sun, 4 Nov 2018 19:01:35 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q186-v6so6625407ljb.5 for ; Sun, 04 Nov 2018 19:01:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=yxlGH8G7Aew5iu19UpjFUWOlykS4dZe9vIqE+a/4i8M=; b=YpprLNI3t6Uw391fCAqEOWkLRuasrdDTu2pPoRtYd7FlY8BggKEoE6csjExIPM/IVO mW+J7iTjtuXnXCNPmTi3bmxM9IhC2mW3JxvxoM9xgys2KYfxQFKwuPyFTVtZ//XJSN/w YEmeaF47K8dxpXwD2Lyr0C1CEPNuGRsxk+cE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yxlGH8G7Aew5iu19UpjFUWOlykS4dZe9vIqE+a/4i8M=; b=shzS6fdeOz+XN9y+6YXhHkOXf6GVzEX3JGxny0TyuIAZOgTdEDCKlDpOVyL94D3B55 mNjWz63bJRd4hjFUFaTopjh7MX3ji22+tWIHQS+zqaUzb72XbuxpnxpCGgi+bBQLRsYn /qZiq6nfDY6H0FA1EYfEQnaRnPGRUljD5jncAyq8bhs+9Q2xIsqa1W4twnLSFmXvlRMz ijPPRxWIxE3Gp9tikUE9lgGD9Tzit5+5RGtenoN7dv0GC+SsAjxer4hRoqBC2stdt+gW PHaFMuOnIbAZZ/cCebrPjJYEkvooF6yvT/kG1K/puoPdM4w3vDJfU5Y91nOfVJ5gfpce D5IQ== X-Gm-Message-State: AGRZ1gJlOuuRI+6gWJj//SjV0Eq5/3uRg9B5LIjNw5iLo6DxsByXkh6q H9YaiOffsW9KlBZdCZ7MqG+P+v4MFfOx7HD92OpJN+UvhbHyhA== X-Google-Smtp-Source: AJdET5eGtNCipuWlBCU3jaCuB9qmrBsuNADfUd4jWqOnHSk1ODm8WODwA1edkswsB9LO0RYV0Xj4XXTk80kV1bZoDVM= X-Received: by 2002:a2e:50d:: with SMTP id 13-v6mr12900276ljf.85.1541386893709; Sun, 04 Nov 2018 19:01:33 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Mon, 5 Nov 2018 10:01:03 +0700 Message-ID: To: Alexey Melnikov , "Murray S. Kucherawy" , "dmarc@ietf.org" , Barry Leiba , John Levine Content-Type: multipart/alternative; boundary="0000000000004307300579e21afb" Archived-At: Subject: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 03:01:38 -0000 --0000000000004307300579e21afb Content-Type: text/plain; charset="UTF-8" I think that we could possibly already read this into the existing charter, but the following one sentence patch makes it explicit: diff --git a/dmarc-wg-charter b/dmarc-wg-charter index a1d0fac..c8ac6bc 100644 --- a/dmarc-wg-charter +++ b/dmarc-wg-charter @@ -81,6 +81,9 @@ the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. +Clarifying the handling of internationalized email addresses (EAI) +throughout the authentication stack of SPF, DKIM, and DMARC. + Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: --Kurt --0000000000004307300579e21afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that we could possibly already re= ad this into the existing charter, but the following one sentence patch mak= es it explicit:

diff --git a/dmarc-wg-charter b/dma= rc-wg-charter
index a1d0fac..c8ac6bc 100644
--- a/dmarc= -wg-charter
+++ b/dmarc-wg-charter
@@ -81,6 +81,9 @@ th= e working group can consider extending the base DMARC specification
=C2=A0to accommodate such a standard, should it be developed during the<= /div>
=C2=A0life of this working group.

+Clari= fying the handling of internationalized email addresses (EAI)
+th= roughout the authentication stack of SPF, DKIM, and DMARC.
+
=C2=A0Improvements in DMARC features (identifier alignment, reporting= ,
=C2=A0policy preferences) will be considered, such as:

--Kurt
--0000000000004307300579e21afb-- From nobody Sun Nov 4 19:11:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41F7129619 for ; Sun, 4 Nov 2018 19:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=3OxIiFxg; dkim=pass (2048-bit key) header.d=kitterman.com header.b=hj3YHTNb 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 RlBYvTWOFyVc for ; Sun, 4 Nov 2018 19:11:26 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED2B128BCC for ; Sun, 4 Nov 2018 19:11:26 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541387484; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=dQJ2oYSNAEIYTp5IMSphhb2ZK+514DoERtoibxIl8u0=; b=3OxIiFxgbuaDqEJTZYy/GkMwMVu/yzIE9qN20mOct2cAgOxw2gYGMxit r8MLliUiDGHHMrFBiyJRF51BUEG1CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541387484; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=dQJ2oYSNAEIYTp5IMSphhb2ZK+514DoERtoibxIl8u0=; b=hj3YHTNbK0Er7+HUF9fCX1rNGoek80i7SWCMCdxJm+mkMHLwCCuOEH7z sFEAcFOKdHH+05YBHu7AM7xqJrPrIEx3tr4lkdSRQZv5nKvESTw/DsTvE8 HjtldgHY1AQSrCUgHj6Bw/wuwGHhUoVVwPVWJPhiU5QWaT2af4mqI5ISW9 08AZ53AWexPG9wlrU7oc1cmtTHFfWbZ8HRqFczXx08D5jpx5uVQlEUdUjO qcB+ggjb+geeOjj3+NgCmgJOqsJySSx/sB94jXhy2Vd22wcrjCZxX5ZH8V UeZqhUDwu6kwNFeMuaUJtzJVsT672TSPqkn8Shf8XXlksMgCULrr3g== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 45C91C400ED for ; Sun, 4 Nov 2018 21:11:24 -0600 (CST) From: Scott Kitterman To: "dmarc@ietf.org" Date: Sun, 04 Nov 2018 22:11:23 -0500 Message-ID: <2393746.3XrAvFVKfY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 03:11:29 -0000 On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: > I think that we could possibly already read this into the existing charter, > but the following one sentence patch makes it explicit: > > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > index a1d0fac..c8ac6bc 100644 > --- a/dmarc-wg-charter > +++ b/dmarc-wg-charter > @@ -81,6 +81,9 @@ the working group can consider extending the base DMARC > specification > to accommodate such a standard, should it be developed during the > life of this working group. > > +Clarifying the handling of internationalized email addresses (EAI) > +throughout the authentication stack of SPF, DKIM, and DMARC. > + > Improvements in DMARC features (identifier alignment, reporting, > policy preferences) will be considered, such as: > > --Kurt I don't see anything about changes to SPF or DKIM being within the current charter, so if we are going to do this, then I think it definitely needs a charter change. What needs changing in SPF/DKIM that we need to take this on? Scott K From nobody Sun Nov 4 19:21:54 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549B1128CF2 for ; Sun, 4 Nov 2018 19:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mSx041Z7YHg for ; Sun, 4 Nov 2018 19:21:48 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 C6946128BCC for ; Sun, 4 Nov 2018 19:21:47 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id n26-v6so5081016lfl.1 for ; Sun, 04 Nov 2018 19:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m/p0Uqr64XKpo78tLaZ0YbcFt/PJDMfGEF9euBgRdtw=; b=OCp7Ul3CFWfWV5SFY+kcXE8+oBgFB8KBlCS3XzOPDC8A/LJKVG3ps3owF9Z8elFfU7 ojqdBV0rjgwKjs2cwuKxacZKyOxWLGx52hdKdIBtI71572H4CmeI/n1gNPUjffu0/ohf 6W+C7sNNYNhFyO92KP6JGiS5WQTETC0uVTLWE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m/p0Uqr64XKpo78tLaZ0YbcFt/PJDMfGEF9euBgRdtw=; b=o49k5PMqzCI/GrfK8Wg1OQqyNsmpjTuPivaoadfoawtn0bi8aDQVQnnFOipIIvxCFn 7CpXl+y7Ujl60bauFxiaM8WbqClYpq+32RQBy/AtoZ6N7anEWKrgzOkmevmB/qbt4rDZ s1B+O8CcH9vct7gz/G4rHKTgMgr2YjTOx0M6JLYnknq6XTzkAZ/ix80Ca1TEzzDJYFs1 y4/DoV+40rZDAgadEk+QW+Wf0ViLSgFoT42EbhlpgQK4Ggq7SYRCnnGE47gAyWoz4meu UKwgnN5zxTqBU1QhHmLwRtzcizb3hiLfFgIHHvAGV69WIh+MJoGWzzUy7HzTzBXHaPZ8 df9g== X-Gm-Message-State: AGRZ1gIX5IjN9wvrxAtEyrMQhOYrHW8xEybtoX4Fyg0tnh4H9G/qLdT8 BaiVDCVYHW7XRuhORlJi56UJ9L7DMihVD+fROO1PGhFzJ68Itw== X-Google-Smtp-Source: AJdET5d11vt2XIrBpPdHl3hfquYgRTgJXCsW6xNTjNrDh/qyOR1hBPMMT2krfTtck3VRjgLuY43mTBbcDSu7+aWfJEc= X-Received: by 2002:a19:e01e:: with SMTP id x30mr11014299lfg.89.1541388105794; Sun, 04 Nov 2018 19:21:45 -0800 (PST) MIME-Version: 1.0 References: <2393746.3XrAvFVKfY@kitterma-e6430> In-Reply-To: <2393746.3XrAvFVKfY@kitterma-e6430> From: "Kurt Andersen (b)" Date: Mon, 5 Nov 2018 10:21:15 +0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000081e29e0579e26299" Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 03:21:51 -0000 --00000000000081e29e0579e26299 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman wrote: > On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: > > I think that we could possibly already read this into the existing > charter, > > but the following one sentence patch makes it explicit: > > > > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > > index a1d0fac..c8ac6bc 100644 > > --- a/dmarc-wg-charter > > +++ b/dmarc-wg-charter > > @@ -81,6 +81,9 @@ the working group can consider extending the base DMARC > > specification > > to accommodate such a standard, should it be developed during the > > life of this working group. > > > > +Clarifying the handling of internationalized email addresses (EAI) > > +throughout the authentication stack of SPF, DKIM, and DMARC. > > + > > Improvements in DMARC features (identifier alignment, reporting, > > policy preferences) will be considered, such as: > > > > --Kurt > > I don't see anything about changes to SPF or DKIM being within the current > charter, so if we are going to do this, then I think it definitely needs a > charter change. > > What needs changing in SPF/DKIM that we need to take this on? > This came out of this morning's DISPATCH meeting at IETF103 ( https://tools.ietf.org/wg/dispatch/agenda) to be able to accept http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the WG for advancing it to an RFC (probably informational). --Kurt --00000000000081e29e0579e26299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <sklist@kitterman.com> wrote:
On Monday, Novembe= r 05, 2018 10:01:03 AM Kurt Andersen wrote:
> I think that we could possibly already read this into the existing cha= rter,
> but the following one sentence patch makes it explicit:
>
> diff --git a/dmarc-wg-charter b/dmarc-wg-charter
> index a1d0fac..c8ac6bc 100644
> --- a/dmarc-wg-charter
> +++ b/dmarc-wg-charter
> @@ -81,6 +81,9 @@ the working group can consider extending the base DM= ARC
> specification
>=C2=A0 to accommodate such a standard, should it be developed during th= e
>=C2=A0 life of this working group.
>
> +Clarifying the handling of internationalized email addresses (EAI) > +throughout the authentication stack of SPF, DKIM, and DMARC.
> +
>=C2=A0 Improvements in DMARC features (identifier alignment, reporting,=
>=C2=A0 policy preferences) will be considered, such as:
>
> --Kurt

I don't see anything about changes to SPF or DKIM being within the curr= ent
charter, so if we are going to do this, then I think it definitely needs a =
charter change.

What needs changing in SPF/DKIM that we need to take this on?

This came out of this morning's DISPATCH meeting= at IETF103 (https://= tools.ietf.org/wg/dispatch/agenda) to be able to accept=C2=A0http://t= ools.ietf.org/html?draft=3Ddraft-levine-appsarea-eaiauth into the WG fo= r advancing it to an RFC (probably informational).

--Kurt
--00000000000081e29e0579e26299-- From nobody Sun Nov 4 19:35:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C358B128CF2 for ; Sun, 4 Nov 2018 19:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLj1rBjiGr8r for ; Sun, 4 Nov 2018 19:35:55 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 9EF04126BED for ; Sun, 4 Nov 2018 19:35:55 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id g26-v6so6658534lja.10 for ; Sun, 04 Nov 2018 19:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=njE83QnCJLmK0jsUGGVZJA+8dB9oe+KkMSpPzAV6LhI=; b=Y8nUs2v9691RQCy473DLStsPMOto098o+CmAzUZBw3hC3+WJqMeT1zLZOdJZSgHDU1 ioNSyQH30Yct3Hr0U5bIpi6o5ZDoMtEGwWzvUxras3lhQeFGsBN0ZbkhTbOCBLzvutzr rv8+bpuipIU7PHv6rpFyxp6cVXDo+GwyA9sVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=njE83QnCJLmK0jsUGGVZJA+8dB9oe+KkMSpPzAV6LhI=; b=OBuzF4JIIC4pqzaBDaHVx0cnvn4rg/Bt3oQBS5eFDRdGTUrCz8qGQ/2OLtd1702pos EUS2/4/w+V3uOlcxSsz/7LlRmUpmCgVznAg7THU0R9NR5exrEhG6l5kJmubd+vwxNVek 6Vne+sO6SAI6U7OTMCkwXo7UtGP/d1lDMTfdO91KV00HROoBOWKK4vfj8TSf+45PFAUy utOqpMnB4Bsu5qsZrRcrRQq7jLqTVwWnHHM+y5GIgIzRU72duP2L5mXHOqjJJ5KcYtIC Rfz6bVp+bmK4JCf/1IDC/9eyX2KGYmUX6yMqGM8bjhnEk3kBgjY2zgpA6+eUqYAyNYOK JFsQ== X-Gm-Message-State: AGRZ1gIUsx/zGVp+zhvcD/3Hq19roh1kAWd1TpeZfStZKo4O9SjCle5W BkPVB972q+BvznGalNZUpJdE99SiBv58gqQ5wewey/qaamjcew== X-Google-Smtp-Source: AJdET5eB6xn/fbEIlrGCJsqVs6UNsTVDTkJxxEDXS2T6JfyRRMDC8fL4KXTr8+rxMfHB/MEJlATv/os0zUoQ9o4QcHc= X-Received: by 2002:a2e:9e81:: with SMTP id f1-v6mr14215836ljk.100.1541388953536; Sun, 04 Nov 2018 19:35:53 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <5E1058DF-99CE-4D64-A204-B7710914CFBC@kitterman.com> In-Reply-To: <5E1058DF-99CE-4D64-A204-B7710914CFBC@kitterman.com> From: Kurt Andersen Date: Mon, 5 Nov 2018 10:35:23 +0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000009602e0579e295df" Archived-At: Subject: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 03:35:58 -0000 --00000000000009602e0579e295df Content-Type: text/plain; charset="UTF-8" Taking this back to the dmarc list instead of the IETF-wide one: On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman wrote: > . . . I understand the desire to just ship it at this point so more > operational experience can be gained before another update. With one > exception, I agree with that approach. > > In Section 5.2. Validator Actions, I think it's highly unlikely that Step > 5, AMS (ARC Message Structure) validation of AMS header fields beyond the > one immediately prior in the chain is useful. > > Failure doesn't change the ARC result, so there are no interoperability > implications for removing it from the draft. The only reason to specify > anything is the notion of 'oldest-pass'. This looks like a dubious and > premature optimization to me. > > I didn't and don't plan to implement it. > > Later, after there is more experience with ARC, if it's established that > validation of AMS beyond the immediately prior step in the chain has > utility and there is sufficient efficiency associated with 'oldest-pass', > it can be added then. 'Oldest-pass' seems like an easy way to get around > having downstream validators do AMS validation up the chain (by always > adding arc.oldest-pass=1 to all messages). > > ARC is complicated enough without this and it seems like any easy win for > simplicity in design to take this out for now (and we'll see about the > future). Deleting it also reduces the IANA considerations. > I'm not by any means arguing with your analysis and plans to skip this component, but I did want to point you, for informational purposes to the WG thread which was the genesis of this concept. It was originally proposed as "closest-fail" but then inverted to be "oldest-pass". You can find the thread from January 2018 at https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI which references an older discussion circa August 2017. --Kurt --00000000000009602e0579e295df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Taking th= is back to the dmarc list instead of the IETF-wide one:

On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <scott@kitterman.com> wrote:
. . .=C2=A0 I understa= nd the desire to just ship it at this point so more operational experience = can be gained before another update.=C2=A0 With one exception, I agree with= that approach.

In Section 5.2.=C2=A0 Validator Actions, I think it's highly unlikely t= hat Step 5, AMS (ARC Message Structure) validation of AMS header fields bey= ond the one immediately prior in the chain is useful.

Failure doesn't change the ARC result, so there are no interoperability= implications for removing it from the draft.=C2=A0 The only reason to spec= ify anything is the notion of 'oldest-pass'.=C2=A0 This looks like = a dubious and premature optimization to me.

I didn't and don't plan to implement it.

Later, after there is more experience with ARC, if it's established tha= t validation of AMS beyond the immediately prior step in the chain has util= ity and there is sufficient efficiency associated with 'oldest-pass'= ;, it can be added then.=C2=A0 'Oldest-pass' seems like an easy way= to get around having downstream validators do AMS validation up the chain = (by always adding arc.oldest-pass=3D1 to all messages).

ARC is complicated enough without this and it seems like any easy win for s= implicity in design to take this out for now (and we'll see about the f= uture).=C2=A0 Deleting it also reduces the IANA considerations.

I'm not by any means arguing with your analysi= s and plans to skip this component, but I did want to point you, for inform= ational purposes to the WG thread which was the genesis of this concept. It= was originally proposed as "closest-fail" but then inverted to b= e "oldest-pass". You can find the thread from January 2018 at=C2= =A0https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDT= hzcGPHGI which references an older discussion circa August 2017.=C2=A0<= /div>

--Kurt
--00000000000009602e0579e295df-- From nobody Sun Nov 4 20:03:36 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1678412D4E9 for ; Sun, 4 Nov 2018 20:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd-Z_2ATr9Da for ; Sun, 4 Nov 2018 20:03:33 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 5EE9A128CF2 for ; Sun, 4 Nov 2018 20:03:33 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id c6-v6so5493195iob.11 for ; Sun, 04 Nov 2018 20:03:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F4nFOjnfYxFBygLsekA45tq6V3+l0wkz+hylcKDl5uc=; b=Ylg+Y6MC+1viAqpFBYEMwH/r7Z/dMkAym4AHCBLQdxeIo33PxGD4GLks1FxYLj+3cU wky1P8hrQHIwxgLBt6OHaOD0qfbLmAngN3//163XaHMODMtFZM12LUxwE89sH2sQARjc Ngt+GMFzEaWFLGxrwcPUYCRNC2q+anaMXx9h70l4VrZjwq8Y0kAYTYwHRr7Uz8degkXg SONWxC5S/V4z+zbappSmMDqat78MzFn1bfzyJjsRSJkiyxB9JVjTFxfBQGrEObBbhNCP N02oOOv0n1tM+EsClVGQ5augxHSOnOYqTS5Gahjow0kfM+u2bBA/BM8SbKySVSeN/eab upRg== X-Gm-Message-State: AGRZ1gKd7npB9HdkdHEQJsiaQv0f6H5DnoXbFA676i/PIKH4/wWAT8FM FAbQwdDHlIhykQ8WBcQRJWG70lJJzpj4jvR7IzI= X-Google-Smtp-Source: AJdET5dme6kvIEcEchFtxAMJSsQyAqc8VI+2A2+BSinvhsbOZqQZ4+8PZhSgDd2ti0KHdDfIsf4nU1esTZZ0mFHLmtA= X-Received: by 2002:a6b:620d:: with SMTP id f13-v6mr7769511iog.11.1541390612082; Sun, 04 Nov 2018 20:03:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 5 Nov 2018 11:03:46 +0700 Message-ID: To: "Kurt Andersen (b)" Cc: Alexey Melnikov , Murray Kucherawy , dmarc@ietf.org, John Levine Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:03:35 -0000 I was about to propose something very similar, so I'm happy to go with Kurt's text. Alexey, do you think this will work? DMARC working group, are you OK with that addition to the charter? Any objections? Barry On Mon, Nov 5, 2018 at 10:01 AM Kurt Andersen (b) wrote: > > I think that we could possibly already read this into the existing charter, but the following one sentence patch makes it explicit: > > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > index a1d0fac..c8ac6bc 100644 > --- a/dmarc-wg-charter > +++ b/dmarc-wg-charter > @@ -81,6 +81,9 @@ the working group can consider extending the base DMARC specification > to accommodate such a standard, should it be developed during the > life of this working group. > > +Clarifying the handling of internationalized email addresses (EAI) > +throughout the authentication stack of SPF, DKIM, and DMARC. > + > Improvements in DMARC features (identifier alignment, reporting, > policy preferences) will be considered, such as: > > --Kurt -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Sun Nov 4 20:04:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E0A12D4E9; Sun, 4 Nov 2018 20:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE0T0v9knHxi; Sun, 4 Nov 2018 20:04:20 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 0E6E9128CF2; Sun, 4 Nov 2018 20:04:20 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m18-v6so5091210lfl.11; Sun, 04 Nov 2018 20:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=n4rzJKPnjZafdxiBYPprQosuuzQccyGIAbMWuOt30asaF3qIR7c/K8bcSIfXG/NUCn 2q0Va4KJSKd8skA/K2Q0T85vn4VbPJXUnucEEhSBOqu9kchL2Glx00zk2vuBdV7Fl/Fv 9Gg+GJnz9d8jRlLqaH2liIhuWJCh9c7NAIemS2p40xU5s38GkDipf/480ElWycirbQeo R6m3escXeTH4jHdJTq0UpvLLlnTVMWW2VjAuzE1PT1p/7nfKYUr3IJ/PD2+zyvWbTZlt fuzB0UnE2p2I6229GNvoVg6/B31KSD6K6IjeRzBJy02sBiKwBxhVlDDy080W03idM/Bk Y5iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=TwJfB8djK1lWAgVlsCeUVrkfA2yi1dQVM/m1oPN98PC+l8wC3d7UzoJ6LqTn4Dq3t4 JOx53wT8YNzcdcwk+I2gm8lLOKRsRuyexHilZ7sZhMt7kvPJXehyXnNLHoc6IpkIB9Xg sIxST9z7nlH8ldfNVdfkajKLSRLPVPGp4j5E+uNkAF9sNICY5D/rbDsQNSUOlWKszjej 5OXAls0hJioib1GXODzyHWdt6WjB3zhGRwaf525EYjj4mp5ZBPECWD9ZvNMx2nAFSTwT Hc9o5KGMZVuag10tB4mehAcmWgShWp/Hrl3N4c2t/zcHKILlSWBQoAxWlHDYpMaNBllH 51OA== X-Gm-Message-State: AGRZ1gJ6vYEvaSnmGgoRvzENeHTI6minbZMZSnFaURdC8wWn3w03WTYL ml8ofjnrRjJzZYZlZ50BLrcmxYW3AV7oxfs3Rno= X-Google-Smtp-Source: AJdET5evdvNHfYRumq8IYIaT12bk7fswQ20Kb7sp+vyJhxBA8lAr2eRYYCtNUgPwLnsdWCf7+UOC7+vxyPD2w3giECA= X-Received: by 2002:a19:4948:: with SMTP id l8-v6mr10851228lfj.16.1541390658077; Sun, 04 Nov 2018 20:04:18 -0800 (PST) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 13:04:04 +0900 Message-ID: To: Rifaat Shekh-Yusef Cc: secdir@ietf.org, IETF DMARC WG , draft-ietf-dmarc-rfc7601bis.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="000000000000a289020579e2fa72" Archived-At: Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:04:23 -0000 --000000000000a289020579e2fa72 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef wrote: > Section 7.2. Misleading Results, Second paragraph >>> >>> "Hence, MUAs and downstream filters must take some care with use of >>> this header even after possibly malicious headers are scrubbed." >>> >>> How do you expect an MUA or downstream filter to act on "take some care"? >>> Can you elaborate on that? >>> >> >> If you are a spammer or malware distributor, you can elicit a DKIM "pass" >> by simply creating your own domain and signing your bad email with that >> domain. The fact that you got a "pass" doesn't tell you anything about >> which domain's signature succeeded, nor does it confirm the message content >> is safe or trustworthy in any way. >> >> "take some care" means "keep this in mind while deciding how to render a >> message to end users, who might not know to even look at this". >> > > I guess what I am looking for is a statement about the best case scenario > for an MUA to be able to display a message with some confidence given the > current state of affair. > For example, if there is a valid DKIM, an Authentication-Results header > with dkim pass,and the header was provided by a trusted entity? > I would argue that the text that's there does give the best case scenario: Absent a reputation system (which doesn't exist publicly, so the lowest common denominator doesn't have this), it's dangerous for any component of a mail system to trust a message just because some authentication system passed. The "value" of the attesting domain is what matters, and for the most part you don't know what that value is. Really large operators (e.g., Gmail) do have reputation systems, but your typical home open source installation does not. > 7.3. Header Field Position >>> >>> This section explains that headers fields are *not* guaranteed to be in >>> a >>> specific order. The section then states that "there will be *some* >>> indication..." >>> >>> Since the order is not guaranteed, what do you expect an implementer to >>> take >>> away from this? >>> >> >> "in the general case" and "but most do not". >> >> So: Most of the time, you can rely on header field ordering to determine >> the sequence of handling. You are at least certain about whether you can >> trust the tail end of that, because you know your own environment from the >> ingress point. >> >> > Fair enough; I think it is worth adding this sentence to make it clear. > Doesn't the last sentence of that paragraph already say exactly that? > >> 7.8. Intentionally Malformed Header Fields >>> >>> This is a general issue with any header. Is there anything specific to >>> this >>> header that an implementer should pay attention to? >>> >> >> No, not really, but at the time this text was originally written (see >> RFC5451; this is about the fourth version of this material), it was felt >> this was worth adding. >> >> > I guess it does hurt to remind implementer to pay attention to this issue, > but I think it might be useful to state that there is nothing special about > this header to avoid possible question like this in the future. > Adjusted the text accordingly. -MSK --000000000000a289020579e2fa72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote: <= br>
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

I guess what I am looki= ng for is a statement about the best case scenario for an MUA to be able to= display a message with some confidence given the current state of affair.<= /div>
For example, if there is a valid DKIM, an Authentication-Results = header with dkim pass,and the header was provided by a trusted entity?

I would argue that the text t= hat's there does give the best case scenario: Absent a reputation syste= m (which doesn't exist publicly, so the lowest common denominator doesn= 't have this), it's dangerous for any component of a mail system to= trust a message just because some authentication system passed.=C2=A0 The = "value" of the attesting domain is what matters, and for the most= part you don't know what that value is.=C2=A0 Really large operators (= e.g., Gmail) do have reputation systems, but your typical home open source = installation does not.


7.3.=C2=A0 Header Field Position

This section explains that headers fields are *not* guaranteed to be in a <= br> specific order. The section then states that "there will be *some* indication..."

Since the order is not guaranteed, what do you expect an implementer to tak= e
away from this?

"in the general ca= se" and "but most do not".

So: Most of the= time, you can rely on header field ordering to determine the sequence of h= andling.=C2=A0 You are at least certain about whether you can trust the tai= l end of that, because you know your own environment from the ingress point= .


Fair enou= gh; I think it is worth adding this sentence to make it clear.

Doesn't the last sentence of = that paragraph already say exactly that?

=C2=A0
7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.


I guess it does hurt to remind implementer to= pay attention to this issue, but I think it might be useful to state that = there is nothing special about this header to avoid possible question like = this in the future.

Adjus= ted the text accordingly.

-MSK
--000000000000a289020579e2fa72-- From nobody Sun Nov 4 20:04:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B82128CF2 for ; Sun, 4 Nov 2018 20:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=J2n0qWDq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fmcsXTdj 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 7wxcO7lfi43c for ; Sun, 4 Nov 2018 20:04:38 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC13130EBB for ; Sun, 4 Nov 2018 20:04:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A1F9F2234A for ; Sun, 4 Nov 2018 23:04:37 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute7.internal (MEProxy); Sun, 04 Nov 2018 23:04:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject; s=fm1; bh=JsOXmRvNE8gfIwkw1F3lawGkPP 6pEiZjpe4rdopUixc=; b=J2n0qWDqZ5vw+Avse9FWzJdbxvnVJzId6Lgo93CjCx uiYhH5nDvUeFia26b21x3bDpEshSg87i2lso5JB5jQJ/0NwE8FMbKdXTZhXI9B/y b7GrO2Q1WVCSnENC705CEcnVJrKZeTXhOUfuhCPaBNaJLKpbEuSDoK5am5bWTOhc REjtMV9qul4gso8Jr6kUxRDOE8P7ZyBB0b/rZIBIO35lsrgPRWAu9Kvem2N+W5Va lrYSHnOmYNVl0OIMkBHQWj7AvkvdjchDQwBzjXxdtCX/mE3kVy89IN1kw5JiPM23 Sls33O5dWQI/DNrAebCoJDbfbzIygzqL18DYt+3q6pfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JsOXmR vNE8gfIwkw1F3lawGkPP6pEiZjpe4rdopUixc=; b=fmcsXTdjWd4cS/I2wWR3Ok +MsDUxCM0Tf5nS0LU458x0SC3JZALVhokGRi0wfY5DWP5nHtXT6vzxuDMvkZq4ED a7m6x16RLZT6oc3Db16kdlb+nCmg+YJFD/Telg08kptiUOdn/BwijGccEdyvFLZO Kp/HGKm5vNKn1tHM4Tn4pcRjy7n/3YPdLbLl7PNZgkjwcstD7VoxwkVvQLDId8CG 0uRTXXYz89qnubieSuOLIKDKytzJgt+K9c6iHS+QgF6+g4or7LhKkIkucQ8kEXMz Yudt2BdDrzAXixOyK4wQa13b+HdWbH9U2Hj4yomkmAirxrMXMtpWLEXkkajZAduQ == X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6E84641D6; Sun, 4 Nov 2018 23:04:37 -0500 (EST) Message-Id: <1541390677.2427237.1565599224.30AD2676@webmail.messagingengine.com> From: Alexey Melnikov To: dmarc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-21384fa2 Date: Mon, 05 Nov 2018 04:04:37 +0000 Archived-At: Subject: [dmarc-ietf] Looking for new chairs for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:04:47 -0000 Dear DMARC WG participants, As we reached a major milestone of completing ARC, I am now looking for volunteers to be DMARC WG co-chairs going forward. If you would like to co-chair DMARC WG or can think of another person who you think should, please send me a direct reply. Thank you, Alexey, as AD From nobody Sun Nov 4 20:05:44 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FEB1298C5 for ; Sun, 4 Nov 2018 20:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y20-vmI1UFBp for ; Sun, 4 Nov 2018 20:05:40 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 53B4F128CF2 for ; Sun, 4 Nov 2018 20:05:40 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id t22-v6so6698604lji.7 for ; Sun, 04 Nov 2018 20:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wABzwUCbH6eQzqloT0EOEMv+wuxWKKSAObLS+LTDMds=; b=MIMGCY5qvLjBfl79IfOm2Uauuc3QKVVHuMuvzcZIicZMiyeInWZOAlSngT9HhkP4Yh 4uxtpda6fYuIa3m5lE9qvIKARBFmPvpvljUScjsHGWXLgIRRkTJZIV5fLi6G68HRTEN9 VRTwfceLAHJqXGMWGYgV9RZgkTuVvzPSwin6/jA9M5oiAAGnpIKIS9Jx1i8gC4wi/Hr4 MHakjSFTmqbLRGZAc6a5HoD2tkbdMt3rJfmnVq9dPRo8wmB2tPnuiBQv2IOByvDzTWi/ 5FpuvinRgYG6SsM0gqQg7TofWSy0OiDhCkqpfMGpKQfI12FCPhHpTE4xKDDJz51XcEss CXrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wABzwUCbH6eQzqloT0EOEMv+wuxWKKSAObLS+LTDMds=; b=Vld2D3VmMRqlzbc/WtkpV4tsYIb13IQ4CCXmE+KDLGlQ1kL8ofWyuuv/neTWqXyfpE iUl8b48cTYgVbR9JS+bpEK4GLZ1673URGyjtItHhsYNAWY4qdby61RVgaGhFfFIBDNHI cEE7sTEL/xQIqcUUz6t+i2UuCaBitc3CqglqAB/QyrLrwNG9gn98qSfihkQAdn8IkiiG jv6CkW0bbO+Qe6tWzIorKp6lTBViH9PfpONL2S5GtKvLuXnG2GFQZ9ILU1VTWbyHA7HP fgwNxhmlc48c3s+8rSDqKOCEnUX3Ys2881x72dIC5+Fn37MTTz9EVFiJu7BvVzn0ccuK T+IA== X-Gm-Message-State: AGRZ1gL7gj/FItZKNClPiV8CNYNdBSXgzeC+XQJbsVWmqDnIJp+lc7cr NB/LP+DqUVQK42GgMGNO1d9YKOZYZAi7ztSVL8jpr0qGaX4= X-Google-Smtp-Source: AJdET5dLN8BxiDBYMP5S3S3gGH035QzLEAuA6kseF9bFEtj8UmVDAQnxPGkjg8Xi5RzHESzzjQBd2XU/8qEgtAdSuW4= X-Received: by 2002:a2e:9e53:: with SMTP id g19-v6mr14505780ljk.39.1541390738375; Sun, 04 Nov 2018 20:05:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 13:05:25 +0900 Message-ID: To: Barry Leiba Cc: "" , Alexey Melnikov , IETF DMARC WG , John Levine Content-Type: multipart/alternative; boundary="0000000000006bcbcd0579e2ff60" Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:05:42 -0000 --0000000000006bcbcd0579e2ff60 Content-Type: text/plain; charset="UTF-8" I proposed adding this right above "Work Items" (it accomplishes the same thing): 4. Incidental related work Any issues related to the email authentication space that are large enough to mandate working group review but do not already fit under the charter of an existing working group can be considered for adoption by DMARC. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. On Mon, Nov 5, 2018 at 1:03 PM Barry Leiba wrote: > I was about to propose something very similar, so I'm happy to go with > Kurt's text. Alexey, do you think this will work? > > DMARC working group, are you OK with that addition to the charter? > Any objections? > > Barry > On Mon, Nov 5, 2018 at 10:01 AM Kurt Andersen (b) > wrote: > > > > I think that we could possibly already read this into the existing > charter, but the following one sentence patch makes it explicit: > > > > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > > index a1d0fac..c8ac6bc 100644 > > --- a/dmarc-wg-charter > > +++ b/dmarc-wg-charter > > @@ -81,6 +81,9 @@ the working group can consider extending the base > DMARC specification > > to accommodate such a standard, should it be developed during the > > life of this working group. > > > > +Clarifying the handling of internationalized email addresses (EAI) > > +throughout the authentication stack of SPF, DKIM, and DMARC. > > + > > Improvements in DMARC features (identifier alignment, reporting, > > policy preferences) will be considered, such as: > > > > --Kurt > > > > -- > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ > --0000000000006bcbcd0579e2ff60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I proposed adding this right above "= Work Items" (it accomplishes the same thing):

4. Incidental rel= ated work

Any issues related to the email authentication space that = are large enough
to mandate working group review but do not already fit = under the charter of
an existing working group can be considered for ado= ption by DMARC.=C2=A0 A
prime example is draft-levine-appsarea-eaiauth, = which provides EAI-related
updates to DMARC and the protocols upon which= it depends.


On Mon, Nov 5, 2018 at 1:03 PM Barry Leiba <barryleiba@computer.org> wrote:
I was about to propose something very similar, so I= 'm happy to go with
Kurt's text.=C2=A0 Alexey, do you think this will work?

DMARC working group, are you OK with that addition to the charter?
Any objections?

Barry
On Mon, Nov 5, 2018 at 10:01 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
>
> I think that we could possibly already read this into the existing cha= rter, but the following one sentence patch makes it explicit:
>
> diff --git a/dmarc-wg-charter b/dmarc-wg-charter
> index a1d0fac..c8ac6bc 100644
> --- a/dmarc-wg-charter
> +++ b/dmarc-wg-charter
> @@ -81,6 +81,9 @@ the working group can consider extending the base DM= ARC specification
>=C2=A0 to accommodate such a standard, should it be developed during th= e
>=C2=A0 life of this working group.
>
> +Clarifying the handling of internationalized email addresses (EAI) > +throughout the authentication stack of SPF, DKIM, and DMARC.
> +
>=C2=A0 Improvements in DMARC features (identifier alignment, reporting,=
>=C2=A0 policy preferences) will be considered, such as:
>
> --Kurt



--
Barry
--
Barry Leiba=C2=A0 (barryleiba@computer.org)
http://internetmessagingtechnology.org/
--0000000000006bcbcd0579e2ff60-- From nobody Sun Nov 4 20:13:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA957130E8B for ; Sun, 4 Nov 2018 20:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Fu5uk/d0; dkim=pass (2048-bit key) header.d=kitterman.com header.b=MVz8k3GU 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 8k0lfwpgbBQp for ; Sun, 4 Nov 2018 20:12:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285FD130E61 for ; Sun, 4 Nov 2018 20:12:59 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541391177; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=ol9McF9IhLfnJzvP6fUe0GjCpPPiKZoc8GgEp9FGYMc=; b=Fu5uk/d0O2+qW444a1IfYD3Er03qjAMmD2QpPVfP/3a9CGfuCEOEiWS0 HEsoVt/CWIASRVg+n+BTIt1yYWEbCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541391177; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=ol9McF9IhLfnJzvP6fUe0GjCpPPiKZoc8GgEp9FGYMc=; b=MVz8k3GUHdN2Rpm6oIlyWMn8ntx7JxICBi0EzmLgX2958uc9BEALhXw3 DJqcN6Hu5UTk5DrrpPsxCeN3vEo9RkHx//XaA3EUERQClxa9fLOIuaMhGT uZs6Bg1oIP0dfM1Q4JsWzGZLYqy3C8a5tiOEsz6HSy5AGIA6T2yOSHTq/D ag9nrNDIJDI0frXW8at8Tvx00ZHuUkKpmFA7fDSXj6iBHZ4RMvD1bocTId py3Q5g8bAOEQMVX4bYINwWnCMJX/49GoGxQAznDY57cj78IANnlszNS7D/ lyt7LwJ49VQTUAMcevNV/UGOwoZUI7WacXeUdaujAV/6WpuHKuFMCA== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B78FDC400D3; Sun, 4 Nov 2018 22:12:57 -0600 (CST) Date: Mon, 05 Nov 2018 04:12:55 +0000 In-Reply-To: References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <5E1058DF-99CE-4D64-A204-B7710914CFBC@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Kurt Andersen CC: "dmarc@ietf.org" From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:13:06 -0000 On November 5, 2018 3:35:23 AM UTC, Kurt Andersen wro= te: >Taking this back to the dmarc list instead of the IETF-wide one: > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman >wrote: > >> =2E =2E =2E I understand the desire to just ship it at this point so m= ore >> operational experience can be gained before another update=2E With one >> exception, I agree with that approach=2E >> >> In Section 5=2E2=2E Validator Actions, I think it's highly unlikely th= at >Step >> 5, AMS (ARC Message Structure) validation of AMS header fields beyond >the >> one immediately prior in the chain is useful=2E >> >> Failure doesn't change the ARC result, so there are no >interoperability >> implications for removing it from the draft=2E The only reason to >specify >> anything is the notion of 'oldest-pass'=2E This looks like a dubious >and >> premature optimization to me=2E >> >> I didn't and don't plan to implement it=2E >> >> Later, after there is more experience with ARC, if it's established >that >> validation of AMS beyond the immediately prior step in the chain has >> utility and there is sufficient efficiency associated with >'oldest-pass', >> it can be added then=2E 'Oldest-pass' seems like an easy way to get >around >> having downstream validators do AMS validation up the chain (by >always >> adding arc=2Eoldest-pass=3D1 to all messages)=2E >> >> ARC is complicated enough without this and it seems like any easy win >for >> simplicity in design to take this out for now (and we'll see about >the >> future)=2E Deleting it also reduces the IANA considerations=2E >> > >I'm not by any means arguing with your analysis and plans to skip this >component, but I did want to point you, for informational purposes to >the >WG thread which was the genesis of this concept=2E It was originally >proposed >as "closest-fail" but then inverted to be "oldest-pass"=2E You can find >the >thread from January 2018 at >https://mailarchive=2Eietf=2Eorg/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPH= GI >which references an older discussion circa August 2017=2E Thanks=2E I've reviewed it and my opinion is reinforced=2E It ought to b= e removed=2E Nothing other than the immediate prior AMS matters for evalua= tion of the ARC result=2E Everything about prior hops is purely for receiv= er edification, not needed for the protocol=2E Scott K From nobody Sun Nov 4 20:33:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC81298C5; Sun, 4 Nov 2018 20:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g2nkShKbFov; Sun, 4 Nov 2018 20:33:45 -0800 (PST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 E9378128B14; Sun, 4 Nov 2018 20:33:41 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id f8-v6so6291765edt.13; Sun, 04 Nov 2018 20:33:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K0y9czQbJ6rXdV8CxoZTO3GKNQ0qvEXDCB3m2uMD6uU=; b=KKqHq2Gg2I8K/pMx6elT5RC7UblTXFLxs5uBb38ts6BeEM+0VHUmPg5Vp02rMqPOtY JtSnGL1pxnFE1NtuFNeH6V0PUxCzOLJaZEPzyHsGO5PVODU0HbyynKlMIDEXKYxMgxkC WmlF1wmU8vaG7kx/PhCzdYKK5sTU7/EvU8tOa65I3STDqOqhw/TRG4Dq7wTV6nP1lweW M5KSrBZP8w5zqjPZxVtRIU2kiEnF5JCwmrMgRQpVg+2cwDziauQ9nASYXxIYecEU1mj2 NxBsn6/Sr7cPsxdH+uy4LXSKCpM9Udmbg6RGPHuZ5I7LrDaPlc26IkivOUuxSqyC4CzW xGAA== X-Gm-Message-State: AGRZ1gJiCcsjYJTyij+MJI4aqEU6pcS9khw218olUVlLYpJo0stvrgPU DAi6VimaA+sJfzB9VnxczfHOJBtn5Qn1fD2v0LIW7zaH X-Google-Smtp-Source: AJdET5fNUDslDpy3r0SheBNLkiz5YZq9mvlasEtyrfwOV4mtg3ITzwAr50jfOGo6WtX/WvC8dJFCPzmArEXODTNbjmo= X-Received: by 2002:a50:b7d6:: with SMTP id i22-v6mr900287ede.123.1541392420222; Sun, 04 Nov 2018 20:33:40 -0800 (PST) MIME-Version: 1.0 References: <154124216209.10246.15168950605174657081@ietfa.amsl.com> In-Reply-To: <154124216209.10246.15168950605174657081@ietfa.amsl.com> From: Barry Leiba Date: Mon, 5 Nov 2018 11:33:28 +0700 Message-ID: To: mariainesrobles=40googlemail.com@dmarc.ietf.org Cc: General Area Review Team , dmarc@ietf.org, IETF discussion list , draft-ietf-dmarc-arc-protocol.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:33:46 -0000 > Nits/editorial comments: > > Page 18: =E2=80=9Cptypes=E2=80=9D =E2=86=92types > Page 22: =E2=80=9Cconcocted=E2=80=9D =E2=86=92 connected? As Scott K says, "ptypes" is correct as written. "Concocted" is also correct as written. Barry From nobody Sun Nov 4 20:39:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269FC1298C5 for ; Sun, 4 Nov 2018 20:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMpu75V76VGZ for ; Sun, 4 Nov 2018 20:39:12 -0800 (PST) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (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 2DD35128B14 for ; Sun, 4 Nov 2018 20:39:12 -0800 (PST) Received: by mail-ed1-f50.google.com with SMTP id d15-v6so3315057edr.0 for ; Sun, 04 Nov 2018 20:39:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dK9LbyQ66B4/XhTQ7/P0eQWSuFLXLnHmT3f5SnqPwsQ=; b=miSu43ISlb9bBCqhZkvWpz0dwBpxrJBPARsN0ep/2dE055v+U03nrdKiisDp7UrITn JtlbxffP+tX1mXBWlbaNtkuBjxY/+Hr/Q+9K1kO761JUQ3JEHfgJuc38Cwc99YPttL2L 4SC8bxpeVPT0zlEx8GnSjxjrZhLoBTnaZXva0dGvat3/zUZGCMq1aawDipH7W2GmklIW dt0x2hbYe6qssRS6OZmF3GsyXHAJbW2Dmb2uJYPT5u6/Z5Jq6+txgVxkkk44WGD+l+A7 VNsu4ViOqf5LyLoZRsvASKw1i2G0BNgPxPnyxWI2gaBgz6fRLQ7kVjiauy826xJxSIaA chqg== X-Gm-Message-State: AGRZ1gLA80oYaYMqx3ok3tcXeg53FPiQwyh4manHkPHt+yxYrI2v1W2Q 1ttp27OigyXV1f8PY96Of0bYTBfNL88M0wPfTjE= X-Google-Smtp-Source: AJdET5fIAc7xc6HoL+6/+h3kfu+sVZN6+rTdpE2VPpWNyDe3NMG9DnD8GHfS2kmVgCe5jYrQoKBW59SRTfryZDeHN3A= X-Received: by 2002:a50:b7d6:: with SMTP id i22-v6mr912756ede.123.1541392750635; Sun, 04 Nov 2018 20:39:10 -0800 (PST) MIME-Version: 1.0 References: <0c273037-69c0-a37f-7cf6-6c9a90ad3291@isode.com> In-Reply-To: From: Barry Leiba Date: Mon, 5 Nov 2018 11:38:59 +0700 Message-ID: To: Kurt Andersen Cc: Alexey Melnikov , dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:39:14 -0000 > Both of these are indeed normative in usage, but I was under the impression that one could not > refer to I-Ds as normative. One can't, so that means that this document will be held by the RFC Editor in a "MISSREF" (missing reference) state until both of the I-D are also in the RFC Editor queue. Then this document will move ahead. Barry From nobody Sun Nov 4 20:54:52 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D250129C6B for ; Sun, 4 Nov 2018 20:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvsB_zR_FAcV for ; Sun, 4 Nov 2018 20:54:48 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 00D8F128B14 for ; Sun, 4 Nov 2018 20:54:47 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id n18so5156373lfh.6 for ; Sun, 04 Nov 2018 20:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0O/ONt6dJhsXNXpHu2phfhXv8KGqe4yoAZKXrY/LZMo=; b=aomBbYooIsAHHcn8qw8khZndrVMLik6RSOmWjqmCeAI2yMIY4kskDiQF3G8Rpd3J23 CwCMDX/T0R3265gtBlZ+YO8yriOC1u2OH8Xj8BA5raEmvFVVWHIyex9umrWf/zx9+5ON MBwDeuSgODt+iDHa3498xC+/oxaSnB2VGUz5Q3WZj37gcdjoaBGOkFoInGZpHIpYv8oX k5Ed+i/1GemJJlEYBV9wLeQfmQaZXxiih4rlJam7J5n+z46xTzNkAh9SCMjgBuljuSGH Th3h0GkIXO6CFSdtENzrYoi7VTNsjJ262mUF/fEOcRW23+oKkOTdhSdZ0BDIUDvm+VKv /IOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0O/ONt6dJhsXNXpHu2phfhXv8KGqe4yoAZKXrY/LZMo=; b=Big7+zKjBBtH6sSVbAwVJK8fdP+R/ZVOl48hs68zPWU6yDkVNFG27bYDXRPGu8fe8F M/Hdw/jYlMpFWRWSjXgDsHgNLRy84oMVgMBOL7GHQFY8q/MWbdMF2ZdePXAd02EniDZY QmQLwChm55GDW/7//vo+IbZh5AYm+2mRWR6YHuV9waeaDxd8Z9pvKSaoKlVu5yZNP/7L I4vuBco6eOVkihLpS5pBrhXbzEjjeaTEkO3S1bWoR8wu/U20Wgdj9XvMcFuV7DWCZP4H 805IWrvA+W95r287FYPx5AbNwLCRzabbsX7CA5NJoaa+IlLpUirfX4LbcUOBXZ5bmcTt Z/5A== X-Gm-Message-State: AGRZ1gId3UREjynVMREAVxrpi/+uiNRXOwj3wkp4lp1I02ERXy3+Lx2D /ZdsUNiUIe5kMnUZXdMloEvo78mwtJzb/xuEXuc= X-Google-Smtp-Source: AJdET5eudKi40oEqhVYTMLTPSwnH2ikqok/jlR539AFiWE5Qzqm0heBYeh8gYcpzJbthuzjzK1htdFMSqMuMh/wAnEw= X-Received: by 2002:a19:6f0a:: with SMTP id k10mr11154721lfc.119.1541393685963; Sun, 04 Nov 2018 20:54:45 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <5E1058DF-99CE-4D64-A204-B7710914CFBC@kitterman.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 13:54:33 +0900 Message-ID: To: Scott Kitterman Cc: "" , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001c69640579e3af71" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 04:54:51 -0000 --0000000000001c69640579e3af71 Content-Type: text/plain; charset="UTF-8" Given the intended status is Experimental, is this something that's a showstopper? We have the debate about "fail" versus "invalid" that I believe we consider to be a showstopper for Proposed Standard, but we're willing to let slide for Experimental. Is this the same? -MSK On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman wrote: > > > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen > wrote: > >Taking this back to the dmarc list instead of the IETF-wide one: > > > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman > >wrote: > > > >> . . . I understand the desire to just ship it at this point so more > >> operational experience can be gained before another update. With one > >> exception, I agree with that approach. > >> > >> In Section 5.2. Validator Actions, I think it's highly unlikely that > >Step > >> 5, AMS (ARC Message Structure) validation of AMS header fields beyond > >the > >> one immediately prior in the chain is useful. > >> > >> Failure doesn't change the ARC result, so there are no > >interoperability > >> implications for removing it from the draft. The only reason to > >specify > >> anything is the notion of 'oldest-pass'. This looks like a dubious > >and > >> premature optimization to me. > >> > >> I didn't and don't plan to implement it. > >> > >> Later, after there is more experience with ARC, if it's established > >that > >> validation of AMS beyond the immediately prior step in the chain has > >> utility and there is sufficient efficiency associated with > >'oldest-pass', > >> it can be added then. 'Oldest-pass' seems like an easy way to get > >around > >> having downstream validators do AMS validation up the chain (by > >always > >> adding arc.oldest-pass=1 to all messages). > >> > >> ARC is complicated enough without this and it seems like any easy win > >for > >> simplicity in design to take this out for now (and we'll see about > >the > >> future). Deleting it also reduces the IANA considerations. > >> > > > >I'm not by any means arguing with your analysis and plans to skip this > >component, but I did want to point you, for informational purposes to > >the > >WG thread which was the genesis of this concept. It was originally > >proposed > >as "closest-fail" but then inverted to be "oldest-pass". You can find > >the > >thread from January 2018 at > >https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI > >which references an older discussion circa August 2017. > > Thanks. I've reviewed it and my opinion is reinforced. It ought to be > removed. Nothing other than the immediate prior AMS matters for evaluation > of the ARC result. Everything about prior hops is purely for receiver > edification, not needed for the protocol. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000001c69640579e3af71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given the intended status is Experimental, is this so= mething that's a showstopper?

We have the debate abou= t "fail" versus "invalid" that I believe we consider to= be a showstopper for Proposed Standard, but we're willing to let slide= for Experimental.=C2=A0 Is this the same?

-MSK

On Mon, Nov 5,= 2018 at 1:13 PM Scott Kitterman <sklist@kitterman.com> wrote:


On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <kurta@drkurt.com> wrote:
>Taking this back to the dmarc list instead of the IETF-wide one:
>
>On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <scott@kitterman.com>
>wrote:
>
>> . . .=C2=A0 I understand the desire to just ship it at this point = so more
>> operational experience can be gained before another update.=C2=A0 = With one
>> exception, I agree with that approach.
>>
>> In Section 5.2.=C2=A0 Validator Actions, I think it's highly u= nlikely that
>Step
>> 5, AMS (ARC Message Structure) validation of AMS header fields bey= ond
>the
>> one immediately prior in the chain is useful.
>>
>> Failure doesn't change the ARC result, so there are no
>interoperability
>> implications for removing it from the draft.=C2=A0 The only reason= to
>specify
>> anything is the notion of 'oldest-pass'.=C2=A0 This looks = like a dubious
>and
>> premature optimization to me.
>>
>> I didn't and don't plan to implement it.
>>
>> Later, after there is more experience with ARC, if it's establ= ished
>that
>> validation of AMS beyond the immediately prior step in the chain h= as
>> utility and there is sufficient efficiency associated with
>'oldest-pass',
>> it can be added then.=C2=A0 'Oldest-pass' seems like an ea= sy way to get
>around
>> having downstream validators do AMS validation up the chain (by >always
>> adding arc.oldest-pass=3D1 to all messages).
>>
>> ARC is complicated enough without this and it seems like any easy = win
>for
>> simplicity in design to take this out for now (and we'll see a= bout
>the
>> future).=C2=A0 Deleting it also reduces the IANA considerations. >>
>
>I'm not by any means arguing with your analysis and plans to skip t= his
>component, but I did want to point you, for informational purposes to >the
>WG thread which was the genesis of this concept. It was originally
>proposed
>as "closest-fail" but then inverted to be "oldest-pass&q= uot;. You can find
>the
>thread from January 2018 at
>https://mailarchive.ietf.= org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI
>which references an older discussion circa August 2017.

Thanks.=C2=A0 I've reviewed it and my opinion is reinforced.=C2=A0 It o= ught to be removed.=C2=A0 Nothing other than the immediate prior AMS matter= s for evaluation of the ARC result.=C2=A0 Everything about prior hops is pu= rely for receiver edification, not needed for the protocol.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000001c69640579e3af71-- From nobody Sun Nov 4 21:11:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96248129C6B; Sun, 4 Nov 2018 21:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pSj-0uTiqOh; Sun, 4 Nov 2018 21:11:05 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 5E8D9128CF2; Sun, 4 Nov 2018 21:11:05 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id y22-v6so5553506ioj.13; Sun, 04 Nov 2018 21:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7aFi68yNGcorTXtM84Vsw1A60av+iOqpbHndkFrSO3w=; b=eUWl0xrvrypEQgUed4Nph7gMpgI03qcSD2Wl18pvKWs5uZXge1ZYkpGwfJRbxj8Hvz +FovfuvIcwXM1EnKKPc/3SAfL+m2/rImA41qpgXUCys1z6K67EofjDzR2WFsR9zr67nR 1NCuWQCESFtVBfm6V377t3XEJV49kYN52NwOA8QfGq1QTmSFyq9lLvIEN1Eqiu9H2uTo dCISCY0alFRL5EBiAqDv6v5x9YBn0zJm04pZJmzLND9ZBdeVsY9ogz8NOcMCFeySdkPI j/roJcqM6pbOemfxoXAXy183fZmnmjIt6wqsKwWXQlIoz604cOow2leXgaR7ckaLNnaf McAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7aFi68yNGcorTXtM84Vsw1A60av+iOqpbHndkFrSO3w=; b=tYQViwpAjvq90RzHg5sSOEar6JZAfSAOyPDGqGippZ/NRx+ZI8OuwPhMjSjcEoo8I8 171QVnfGw2UPNCpOxv39DBWQBg4ySkTD+S6sKsmFMPi9OETUDHXGsbIarmef2MAq+wIc 93U60u3kqxV9HN6xIHPFSv5FzsYFC224Jt4ArZwQmE+HcdlUaOUiJpC7hgOojA9WF83H /yBQ11BuF3jjBNIM0E84rQxQAGwjnbIRCl8sB8ntk+Ac2T5v45O+J6OPy9gMVmWrwY+3 CuktKIOsDAf+kZovjEBZKoFMLFpKTqwcbixfAcrkOWIT2aLFTXCePn44LmhJkZN9nPNF EPcA== X-Gm-Message-State: AGRZ1gIbFdQHg+WLGbT6na/tXoEB2rKL4JDsZZ5OD3VSVvPeK7TnXBMc KdXh3Uept1Cu0jK7dcTLEP2S+DKQALtg55qbLlA= X-Google-Smtp-Source: AJdET5cfUBnVmWcYqTqtFVVmdNeLH4kbMT0Muf8qLXWdfJ+F9ummYr2rWlO/f+iC5ZXvC1F9pUB6Z6gN/sZz7OygJwg= X-Received: by 2002:a6b:f607:: with SMTP id n7-v6mr2818392ioh.99.1541394664486; Sun, 04 Nov 2018 21:11:04 -0800 (PST) MIME-Version: 1.0 References: <154124216209.10246.15168950605174657081@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Mon, 5 Nov 2018 12:10:53 +0700 Message-ID: To: Barry Leiba Cc: IETF Gen-ART , dmarc@ietf.org, IETF discussion list , draft-ietf-dmarc-arc-protocol.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f8e890579e3e963" Archived-At: Subject: Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 05:11:09 -0000 --0000000000006f8e890579e3e963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you very much for the corrections! Ines On Mon, Nov 5, 2018, 11:33 AM Barry Leiba > Nits/editorial comments: > > > > Page 18: =E2=80=9Cptypes=E2=80=9D =E2=86=92types > > Page 22: =E2=80=9Cconcocted=E2=80=9D =E2=86=92 connected? > > As Scott K says, "ptypes" is correct as written. > > "Concocted" is also correct as written. > > Barry > --0000000000006f8e890579e3e963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much for the corrections!=C2=A0

Ines

On Mon, Nov 5, 2018, 11:33 AM Barry Leiba <barryleiba@computer.org wrote:
> Nits/editorial comments:
>
> Page 18: =E2=80=9Cptypes=E2=80=9D =E2=86=92types
> Page 22: =E2=80=9Cconcocted=E2=80=9D =E2=86=92 connected?

As Scott K says, "ptypes" is correct as written.

"Concocted" is also correct as written.

Barry
--0000000000006f8e890579e3e963-- From nobody Sun Nov 4 21:14:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4E129C6B for ; Sun, 4 Nov 2018 21:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=3YfnQGKG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=KJk63oiJ 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 3xp1gvl4rNV2 for ; Sun, 4 Nov 2018 21:14:03 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB38E128CF2 for ; Sun, 4 Nov 2018 21:14:03 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541394841; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=kCw+tzqLiI2RdLauXemxgt/veF92DxA/BmQs/LWw+Cg=; b=3YfnQGKG4oWvmeIDDB+Vp+wYnWlT8jK1hetvli/P0P29bD3V8IbELFPF 3xwZYlh8xLosUUSl6lnobUCAirAYCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541394841; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=kCw+tzqLiI2RdLauXemxgt/veF92DxA/BmQs/LWw+Cg=; b=KJk63oiJG4DwvwQt9MSKMZQI7H9Qrks7+GPA7/jz/siCsUm1dqa1ChAA GJ+cDVBjZyysUpbJHpYUeYCU/7wgLJd3BOOm3xrQjbQauHmog6W0Am3Plh QpBE6NyKSO+SeoeG+bqnbXARUuFDpCBZ9QGes7xsmhmBnm17tIXcICyJ7k sDMLCO6+9cTd4E63oToB3yGsOtL+Nf/8Br/6MKCzHKfNoFm5izks1VjNoM jbdluf2HRhHWb9/L4VJIrTVL0aygkjD5L0sIykHYP/XfVECw3e+GKyJ666 kuHuvxQVvGmHmTW1pNoM03/tzJlMt+p+7zlDXMx1XpGRC45iP+8Wvg== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BB933C400D3; Sun, 4 Nov 2018 23:14:01 -0600 (CST) Date: Mon, 05 Nov 2018 05:13:57 +0000 In-Reply-To: References: <2393746.3XrAvFVKfY@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "Kurt Andersen (b)" CC: "dmarc@ietf.org" From: Scott Kitterman Message-ID: <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 05:14:06 -0000 On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" wrote: >On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman >wrote: > >> On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: >> > I think that we could possibly already read this into the existing >> charter, >> > but the following one sentence patch makes it explicit: >> > >> > diff --git a/dmarc-wg-charter b/dmarc-wg-charter >> > index a1d0fac=2E=2Ec8ac6bc 100644 >> > --- a/dmarc-wg-charter >> > +++ b/dmarc-wg-charter >> > @@ -81,6 +81,9 @@ the working group can consider extending the base >DMARC >> > specification >> > to accommodate such a standard, should it be developed during the >> > life of this working group=2E >> > >> > +Clarifying the handling of internationalized email addresses (EAI) >> > +throughout the authentication stack of SPF, DKIM, and DMARC=2E >> > + >> > Improvements in DMARC features (identifier alignment, reporting, >> > policy preferences) will be considered, such as: >> > >> > --Kurt >> >> I don't see anything about changes to SPF or DKIM being within the >current >> charter, so if we are going to do this, then I think it definitely >needs a >> charter change=2E >> >> What needs changing in SPF/DKIM that we need to take this on? >> > >This came out of this morning's DISPATCH meeting at IETF103 ( >https://tools=2Eietf=2Eorg/wg/dispatch/agenda) to be able to accept >http://tools=2Eietf=2Eorg/html?draft=3Ddraft-levine-appsarea-eaiauth into= the >WG >for advancing it to an RFC (probably informational)=2E Thanks=2E It doesn't appear that it proposes any changes for SPF=2E It m= erely documents that non-ascii local parts don't match the related macros= =2E During the SPFbis working group we looked at this and explicitly decid= ed on it=2E It's not by accident=2E Since local part macros are very rarely used, it seemed like very much a c= orner case not worth it to break the installed base over=2E If there's going to be a charter change around this, I think it needs some= words to constrain the work to limit interoperability implications=2E I know less about the implications for DKIM and DMARC, but would imagine b= ackward compatibility is important there too=2E Scott K From nobody Sun Nov 4 21:25:31 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2074B128A6E for ; Sun, 4 Nov 2018 21:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=A+cC3rt7; dkim=pass (2048-bit key) header.d=kitterman.com header.b=SywBTRMB 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 o7e5lWhZKqoS for ; Sun, 4 Nov 2018 21:25:28 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068D71277C8 for ; Sun, 4 Nov 2018 21:25:28 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541395526; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KAWP6bT6y5gBQWanT5bEEyHpDnlYcUOaXpu+w5hHEVU=; b=A+cC3rt7Ml0/IXxJuKQOrmLfvXFIvW3oSN4LXZ0WOGc2V9qmzr77TQaa tejQkmx5hdEr3+8EWdwnIbFFC+7TDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541395525; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=KAWP6bT6y5gBQWanT5bEEyHpDnlYcUOaXpu+w5hHEVU=; b=SywBTRMBXWmEXJFNONWcNyoNah24XwaYnuHBU5N9ltpQp0Alfdc2p96x GeTXP5uyHoqGV4T/0UrD3DoUo2hsxVlaTPVYfM0k0XbWnqSbGFsXE7jCxZ pRUdbv6+H0Beo94ku+Y8zj+aXjY8BtRUSzDEATsVv9FHkyTD72k2qMUwGL RpzLsXWRa7B1lavlM8NQL+a5m95eBKv8B5musvmc6XwSVC/yMr9DhCg3AZ pH++ENO524L0bF0CnETrA9OTzpeo9sYpKeDPur/MtCrebvN2jC1SPgAYqZ tfcAzATJFLcHRdNkHARad17Nj4KHOrdlDP86/PwRGG6HfifmaWCSqw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB124C400D3 for ; Sun, 4 Nov 2018 23:25:25 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 05 Nov 2018 00:25:24 -0500 Message-ID: <4082068.TRYGpCgONJ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 05:25:30 -0000 I don't think it's something we should delay on. In my, admittedly limited, experience with these things, once something is in an experimental version of an RFC, then it 'has' to be preserved in the name of interoperability with the installed base. I think now is the time to remove obvious fluff. This documents makes my head hurt enough as it is. If anything, it should be a separate document as it's got nothing to do with ARC, per se. Any utility of AMS past the immediate previous one is entirely speculative. Let's lean towards easy, not hard. Now is the time to prune this. Having reviewed the thread that Kurt pointed me to, it seemed like this is something only one person wanted. It didn't appear to have a lot of push behind it. Scott K On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote: > Given the intended status is Experimental, is this something that's a > showstopper? > > We have the debate about "fail" versus "invalid" that I believe we consider > to be a showstopper for Proposed Standard, but we're willing to let slide > for Experimental. Is this the same? > > -MSK > > On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman wrote: > > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen > > > > wrote: > > >Taking this back to the dmarc list instead of the IETF-wide one: > > > > > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman > > > > > >wrote: > > >> . . . I understand the desire to just ship it at this point so more > > >> operational experience can be gained before another update. With one > > >> exception, I agree with that approach. > > >> > > >> In Section 5.2. Validator Actions, I think it's highly unlikely that > > > > > >Step > > > > > >> 5, AMS (ARC Message Structure) validation of AMS header fields beyond > > > > > >the > > > > > >> one immediately prior in the chain is useful. > > >> > > >> Failure doesn't change the ARC result, so there are no > > > > > >interoperability > > > > > >> implications for removing it from the draft. The only reason to > > > > > >specify > > > > > >> anything is the notion of 'oldest-pass'. This looks like a dubious > > > > > >and > > > > > >> premature optimization to me. > > >> > > >> I didn't and don't plan to implement it. > > >> > > >> Later, after there is more experience with ARC, if it's established > > > > > >that > > > > > >> validation of AMS beyond the immediately prior step in the chain has > > >> utility and there is sufficient efficiency associated with > > > > > >'oldest-pass', > > > > > >> it can be added then. 'Oldest-pass' seems like an easy way to get > > > > > >around > > > > > >> having downstream validators do AMS validation up the chain (by > > > > > >always > > > > > >> adding arc.oldest-pass=1 to all messages). > > >> > > >> ARC is complicated enough without this and it seems like any easy win > > > > > >for > > > > > >> simplicity in design to take this out for now (and we'll see about > > > > > >the > > > > > >> future). Deleting it also reduces the IANA considerations. > > > > > >I'm not by any means arguing with your analysis and plans to skip this > > >component, but I did want to point you, for informational purposes to > > >the > > >WG thread which was the genesis of this concept. It was originally > > >proposed > > >as "closest-fail" but then inverted to be "oldest-pass". You can find > > >the > > >thread from January 2018 at > > >https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI > > >which references an older discussion circa August 2017. > > > > Thanks. I've reviewed it and my opinion is reinforced. It ought to be > > removed. Nothing other than the immediate prior AMS matters for > > evaluation > > of the ARC result. Everything about prior hops is purely for receiver > > edification, not needed for the protocol. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Nov 4 22:23:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2112F18C for ; Sun, 4 Nov 2018 22:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajj4MYwbHrAl for ; Sun, 4 Nov 2018 22:23:22 -0800 (PST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 208E612EB11 for ; Sun, 4 Nov 2018 22:23:21 -0800 (PST) Received: by mail-ed1-f53.google.com with SMTP id c25-v6so6465407edt.8 for ; Sun, 04 Nov 2018 22:23:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2qFyWeL1WRLVYsigbvmbYeslPF4km0COY435WJ/K30I=; b=lgacZknuecomSdvWgebTcLYOHTkJPSkYyaew/YDMSCIxWPRSoCblEooTZiDjFmzTxI ZbUQd8uVtSjbBhD1ni8MmPcNAQ5yu9IdebdhNJz1Pt4QebzE1bWitMzmtTwIKzUMimJO SrxT8O8LCmM0aMaa5roEJM0IbEblOfkqPbL8jsheyG97ypqr2Zyxu3i/WJ+yh2HHk7B8 pv/DysyiMFoA1mCC4m+cU7KWOFOLD8hJhcqROicbX8pTO+1LC8jWGFe/UGCi2bCg5IsW aWYpWhqutsgQPVX1XNOpybFEaby5u4CAc7dq2bf7ZT9b8ZM5Gqc79yCKh4F3L6UQzlkf 5Ccg== X-Gm-Message-State: AGRZ1gIcAEjdWLTyFVO/veKk5vEOQ3UADcMgWpkyV+7sxtH2v8CzdOLf qH0hrhnTZkjUwWAO/XBtS/vIJxd8AgmsmXOXnBw= X-Google-Smtp-Source: AJdET5e8MarwNiVvvoHcn0BSHByxMwkj1KUuwW9Y5UsNPb/OAYRicedASGnGMrXhekOdYUKROvLfD6EGPA8DEokT1m8= X-Received: by 2002:a50:9979:: with SMTP id l54-v6mr15980158edb.227.1541399000105; Sun, 04 Nov 2018 22:23:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Mon, 5 Nov 2018 13:23:08 +0700 Message-ID: To: Kurt Andersen Cc: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 06:23:23 -0000 > I'd like to recommend that we (DMARC-WG) accept https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 > into our work queue. It aligns with our charter already. I've seen three agreements and no objections, so here's an official call for objections. If there are none by 16 November, we will create draft-ietf-dmarc-psd-00 as a new working group item. Barry From nobody Sun Nov 4 22:32:27 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BC512EB11 for ; Sun, 4 Nov 2018 22:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0HOfH2ttKof for ; Sun, 4 Nov 2018 22:32:22 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 DD7BD128B14 for ; Sun, 4 Nov 2018 22:32:21 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id q6-v6so5274262lfh.9 for ; Sun, 04 Nov 2018 22:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=plVPzj/7V93NMzXqlGCkErfk18IFo1LDdUfrhyswQpQ=; b=ZZUi0vxAyRKsz/IoD8Ts5elhaNKWXZ8Q/j3iUa+wf9Eh1X0It2Z6kDqZAN9BxIMZuf +F8lpVMsSUMImVsAXm5KUDvhpfWy15SDfFEHKpCE9gXTddXG8e1YZg1cHLmqyg76y4P1 FBfx7nXqQjE0oVj26PE+VcBDTbZBqclgPpbj8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=plVPzj/7V93NMzXqlGCkErfk18IFo1LDdUfrhyswQpQ=; b=T/2aNXrdsLEL3wvqAiymctoggE1rgLBmH2415DPvNpnaT5ZRbyhuzXWIVhRwj/7Uwa XFTbb9NfQ+oRbTkUOF+49Qg7uN/pYB5fp7PiEa3mErA8Nc5ysLi7RP4VgQRMEmzujDqk TTfhnio7b6G8qMimtiLbARHqbJhU/FIO0st4QtJxIsDL8vv7amvkx4Rba0R8NEttLiRc abuMDXH+xm4Q07nE4EeWVBObwx4ZuLTJ9VStTCsMZs1PGpRR68Cfc6G6M2/AD2yEXkFw 8OL6EWh2CkDw/l2eYbo92SZS+PLp3T39/skY1fuu940nNaipZaVzCa7aibXJQxxuu7pa i6Lw== X-Gm-Message-State: AGRZ1gLeYlfdCB8qnPYBWff6skEK5AU1zzQEqSR/8TLFGxCXm3qHQbEy ZIWSlsIVRKYAcwAyC7xPuwwAut2bidcNLHN4NBC2wqvKDZFfBw== X-Google-Smtp-Source: AJdET5f6/4EajSbXgPeC0uTVLLjzWf3sWlk/fDvjo50kGoHkD0GMNiXAKQ/iJwUVgCT+73pOQZBKgwsMNaqNozGSvsM= X-Received: by 2002:a19:cec8:: with SMTP id e191mr11619973lfg.13.1541399539826; Sun, 04 Nov 2018 22:32:19 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <4082068.TRYGpCgONJ@kitterma-e6430> In-Reply-To: <4082068.TRYGpCgONJ@kitterma-e6430> From: "Kurt Andersen (b)" Date: Mon, 5 Nov 2018 13:31:50 +0700 Message-ID: To: Scott Kitterman , Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000007593b0579e50c98" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 06:32:25 -0000 --00000000000007593b0579e50c98 Content-Type: text/plain; charset="UTF-8" Explicitly looping in that one person to see if his thoughts have changed over time. --Kurt On Mon, Nov 5, 2018 at 12:25 PM Scott Kitterman wrote: > I don't think it's something we should delay on. In my, admittedly > limited, > experience with these things, once something is in an experimental version > of > an RFC, then it 'has' to be preserved in the name of interoperability with > the > installed base. I think now is the time to remove obvious fluff. This > documents makes my head hurt enough as it is. > > If anything, it should be a separate document as it's got nothing to do > with > ARC, per se. Any utility of AMS past the immediate previous one is > entirely > speculative. Let's lean towards easy, not hard. Now is the time to prune > this. > > Having reviewed the thread that Kurt pointed me to, it seemed like this is > something only one person wanted. It didn't appear to have a lot of push > behind it. > > Scott K > > On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote: > > Given the intended status is Experimental, is this something that's a > > showstopper? > > > > We have the debate about "fail" versus "invalid" that I believe we > consider > > to be a showstopper for Proposed Standard, but we're willing to let slide > > for Experimental. Is this the same? > > > > -MSK > > > > On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman > wrote: > > > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen > > > > > > wrote: > > > >Taking this back to the dmarc list instead of the IETF-wide one: > > > > > > > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman > > > > > > > >wrote: > > > >> . . . I understand the desire to just ship it at this point so more > > > >> operational experience can be gained before another update. With > one > > > >> exception, I agree with that approach. > > > >> > > > >> In Section 5.2. Validator Actions, I think it's highly unlikely > that > > > > > > > >Step > > > > > > > >> 5, AMS (ARC Message Structure) validation of AMS header fields > beyond > > > > > > > >the > > > > > > > >> one immediately prior in the chain is useful. > > > >> > > > >> Failure doesn't change the ARC result, so there are no > > > > > > > >interoperability > > > > > > > >> implications for removing it from the draft. The only reason to > > > > > > > >specify > > > > > > > >> anything is the notion of 'oldest-pass'. This looks like a dubious > > > > > > > >and > > > > > > > >> premature optimization to me. > > > >> > > > >> I didn't and don't plan to implement it. > > > >> > > > >> Later, after there is more experience with ARC, if it's established > > > > > > > >that > > > > > > > >> validation of AMS beyond the immediately prior step in the chain has > > > >> utility and there is sufficient efficiency associated with > > > > > > > >'oldest-pass', > > > > > > > >> it can be added then. 'Oldest-pass' seems like an easy way to get > > > > > > > >around > > > > > > > >> having downstream validators do AMS validation up the chain (by > > > > > > > >always > > > > > > > >> adding arc.oldest-pass=1 to all messages). > > > >> > > > >> ARC is complicated enough without this and it seems like any easy > win > > > > > > > >for > > > > > > > >> simplicity in design to take this out for now (and we'll see about > > > > > > > >the > > > > > > > >> future). Deleting it also reduces the IANA considerations. > > > > > > > >I'm not by any means arguing with your analysis and plans to skip this > > > >component, but I did want to point you, for informational purposes to > > > >the > > > >WG thread which was the genesis of this concept. It was originally > > > >proposed > > > >as "closest-fail" but then inverted to be "oldest-pass". You can find > > > >the > > > >thread from January 2018 at > > > > > https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI > > > >which references an older discussion circa August 2017. > > > > > > Thanks. I've reviewed it and my opinion is reinforced. It ought to be > > > removed. Nothing other than the immediate prior AMS matters for > > > evaluation > > > of the ARC result. Everything about prior hops is purely for receiver > > > edification, not needed for the protocol. > > > > > > Scott K > > > > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000007593b0579e50c98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Explicitly looping in that one person to see if his though= ts have changed over time.

--Kurt

On Mon, Nov 5, 2018 at 12:25 PM Scott = Kitterman <sklist@kitterman.com<= /a>> wrote:
I don't think it= 's something we should delay on.=C2=A0 In my, admittedly limited,
experience with these things, once something is in an experimental version = of
an RFC, then it 'has' to be preserved in the name of interoperabili= ty with the
installed base.=C2=A0 I think now is the time to remove obvious fluff.=C2= =A0 This
documents makes my head hurt enough as it is.

If anything, it should be a separate document as it's got nothing to do= with
ARC, per se.=C2=A0 Any utility of AMS past the immediate previous one is en= tirely
speculative.=C2=A0 Let's lean towards easy, not hard.=C2=A0 Now is the = time to prune
this.

Having reviewed the thread that Kurt pointed me to, it seemed like this is =
something only one person wanted.=C2=A0 It didn't appear to have a lot = of push
behind it.

Scott K

On Monday, November 05, 2018 01:54:33 PM Murray S. Kucherawy wrote:
> Given the intended status is Experimental, is this something that'= s a
> showstopper?
>
> We have the debate about "fail" versus "invalid" t= hat I believe we consider
> to be a showstopper for Proposed Standard, but we're willing to le= t slide
> for Experimental.=C2=A0 Is this the same?
>
> -MSK
>
> On Mon, Nov 5, 2018 at 1:13 PM Scott Kitterman <sklist@kitterman.com> wrote:<= br> > > On November 5, 2018 3:35:23 AM UTC, Kurt Andersen <kurta@drkurt.com>
> >
> > wrote:
> > >Taking this back to the dmarc list instead of the IETF-wide o= ne:
> > >
> > >On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <scott@kitterman.com&g= t;
> > >
> > >wrote:
> > >> . . .=C2=A0 I understand the desire to just ship it at t= his point so more
> > >> operational experience can be gained before another upda= te.=C2=A0 With one
> > >> exception, I agree with that approach.
> > >>
> > >> In Section 5.2.=C2=A0 Validator Actions, I think it'= s highly unlikely that
> > >
> > >Step
> > >
> > >> 5, AMS (ARC Message Structure) validation of AMS header = fields beyond
> > >
> > >the
> > >
> > >> one immediately prior in the chain is useful.
> > >>
> > >> Failure doesn't change the ARC result, so there are = no
> > >
> > >interoperability
> > >
> > >> implications for removing it from the draft.=C2=A0 The o= nly reason to
> > >
> > >specify
> > >
> > >> anything is the notion of 'oldest-pass'.=C2=A0 T= his looks like a dubious
> > >
> > >and
> > >
> > >> premature optimization to me.
> > >>
> > >> I didn't and don't plan to implement it.
> > >>
> > >> Later, after there is more experience with ARC, if it= 9;s established
> > >
> > >that
> > >
> > >> validation of AMS beyond the immediately prior step in t= he chain has
> > >> utility and there is sufficient efficiency associated wi= th
> > >
> > >'oldest-pass',
> > >
> > >> it can be added then.=C2=A0 'Oldest-pass' seems = like an easy way to get
> > >
> > >around
> > >
> > >> having downstream validators do AMS validation up the ch= ain (by
> > >
> > >always
> > >
> > >> adding arc.oldest-pass=3D1 to all messages).
> > >>
> > >> ARC is complicated enough without this and it seems like= any easy win
> > >
> > >for
> > >
> > >> simplicity in design to take this out for now (and we= 9;ll see about
> > >
> > >the
> > >
> > >> future).=C2=A0 Deleting it also reduces the IANA conside= rations.
> > >
> > >I'm not by any means arguing with your analysis and plans= to skip this
> > >component, but I did want to point you, for informational pur= poses to
> > >the
> > >WG thread which was the genesis of this concept. It was origi= nally
> > >proposed
> > >as "closest-fail" but then inverted to be "old= est-pass". You can find
> > >the
> > >thread from January 2018 at
> > >https://mailarc= hive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI
> > >which references an older discussion circa August 2017.
> >
> > Thanks.=C2=A0 I've reviewed it and my opinion is reinforced.= =C2=A0 It ought to be
> > removed.=C2=A0 Nothing other than the immediate prior AMS matters= for
> > evaluation
> > of the ARC result.=C2=A0 Everything about prior hops is purely fo= r receiver
> > edification, not needed for the protocol.
> >
> > Scott K
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/dmarc=

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000007593b0579e50c98-- From nobody Sun Nov 4 22:45:06 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0894F120072 for ; Sun, 4 Nov 2018 22:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM6vlflpTypQ for ; Sun, 4 Nov 2018 22:44:55 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECC512EB11 for ; Sun, 4 Nov 2018 22:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1541400294; d=isode.com; s=june2016; i=@isode.com; bh=3nunSmI8CBnxQ2HbVVmuk2EQ+A9mgviNQo/RBxWlOo8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oqXcq7IqH8TUUUnftzQrWCCuKiwtnLsqyW+RlJem+MCt/HqHBeGeBX7ahTiwqOg5Sw/NDn jWsbyAwDNAoU5h10M9mi4GKXECbZ6oF/3TxYBZsUKqT7hMmvIMfg3qbPv4XPRPpVmKshFm X2IFQaNovwOMYuteXuDw+QDrfwJzM/c=; Received: from [31.133.152.18] (dhcp-9812.meeting.ietf.org [31.133.152.18]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 5 Nov 2018 06:44:54 +0000 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Mon, 5 Nov 2018 13:48:46 +0700 Cc: Kurt Andersen , dmarc@ietf.org Message-Id: References: <0c273037-69c0-a37f-7cf6-6c9a90ad3291@isode.com> To: Barry Leiba MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 06:44:57 -0000 On 5 Nov 2018, at 11:38, Barry Leiba wrote: >> Both of these are indeed normative in usage, but I was under the impressi= on that one could not >> refer to I-Ds as normative. >=20 > One can't, so that means that this document will be held by the RFC > Editor in a "MISSREF" (missing reference) state until both of the I-D > are also in the RFC Editor queue. Then this document will move ahead. True, but being "afraid of a MISSREF" is not a good enough reason to pretend= that a Normative reference is Informative. From nobody Sun Nov 4 22:47:03 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB3712EB11 for ; Sun, 4 Nov 2018 22:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEWtrSpzZrwa for ; Sun, 4 Nov 2018 22:47:01 -0800 (PST) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 BE657120072 for ; Sun, 4 Nov 2018 22:47:00 -0800 (PST) Received: by mail-it1-f182.google.com with SMTP id v11so4971026itj.0 for ; Sun, 04 Nov 2018 22:47:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hxtwFcVSNnPV5vR4Au+oyGdb4wefmbxB3jpugEfOgUw=; b=QafGzO+8qA+mkRKUmVFCXbRSTHSJdOGdFDkGwLvnm71r/6OuDOCkuMh5kKnJHG3Le3 rWOJOLFCumRAaagwbgshmr9IBfpPhdeLbVuDqtXSo5pfeR07p4hgGdfR8q6AB4B23FRe 9oZgNnBPRlHJWLoW6K4au9Omdnil+qdmijuIwkjYZqbGx6UxC/rpBS5tMuVZ/nrlb7WB mziTK4B7jPyRgp7z2UJu48pdqC8QWotq+MuICGDG8zQPP2U5Ra5kdX83EOv8qzMuAaIf Lyb3Q859Blx+cnyYtFxbreIJvgD68RqXqk1iNkvXZj1rHHcQal114OQO4kyB0g87cy69 nt0w== X-Gm-Message-State: AGRZ1gLUmTpvZFNDkKHNRGkfsH/MftL3EdUZSYuBqRi6iT0LGF/CgFoI EE1igLqttvC/PQ3Y0hB/V2APjEJPf/fKuK3G62k= X-Google-Smtp-Source: AJdET5fDVGc9M6poHlebUbtwmRV/kgqGgK/7XnqbPY9T6pdCzNXc85Mnr0d2igEzVetpALpXy0vRenmrcsT6pH8+yVk= X-Received: by 2002:a02:b4ce:: with SMTP id a14-v6mr18369506jak.140.1541400419484; Sun, 04 Nov 2018 22:46:59 -0800 (PST) MIME-Version: 1.0 References: <0c273037-69c0-a37f-7cf6-6c9a90ad3291@isode.com> In-Reply-To: From: Barry Leiba Date: Mon, 5 Nov 2018 13:46:48 +0700 Message-ID: To: Alexey Melnikov Cc: "Kurt Andersen (b)" , dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 06:47:02 -0000 > >> Both of these are indeed normative in usage, but I was under the impression that one could not > >> refer to I-Ds as normative. > > > > One can't, so that means that this document will be held by the RFC > > Editor in a "MISSREF" (missing reference) state until both of the I-D > > are also in the RFC Editor queue. Then this document will move ahead. > > True, but being "afraid of a MISSREF" is not a good enough reason to pretend that a Normative > reference is Informative. Of course not, and I didn't mean to imply that it was. I was explaining that we *can* send the document forward with a missing normative reference. "We" do not have to wait for it to clear; the RFC Editor will. Barry From nobody Sun Nov 4 22:48:56 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0A12EB11 for ; Sun, 4 Nov 2018 22:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ZbCDRoBe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F7mQpRmP 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 InGaqVpfMalT for ; Sun, 4 Nov 2018 22:48:53 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DF3120072 for ; Sun, 4 Nov 2018 22:48:52 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C40DE221F7; Mon, 5 Nov 2018 01:48:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 05 Nov 2018 01:48:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=p LxRiTJN88Mvbvkk/49aVnmiCITdugSzN7KdYjCvwuo=; b=ZbCDRoBeZ4WRqULvt v1Xe1ZGeg9kq5eoRQBWc6y6VLkVS0ZSsqq3K/3osCgB6L8rYLxnBrb47d1OaW0xD 1wb26vGC3H/cS1d8eNPmMBm2t1tGqVOoSZc0x1Ee5RtdM4zssMq0SmiuEw7hJi0H fn6Suy7g2Jep+AdWKFjta7jN3dgdJaUVD2aJrBuhFfctY3SaZmnQ5ruuCeDo/w3C p1Zg2ylxtZLTFKc3dpvLZD/YV1Ww1wwt9un/4kEKhrC+gK5ocFIWA+T5P5dThuDz cZRDVa3rI1fXMPA7Hb1r2XivDlKHj763AQLxIfrEbBPFy5bj0bw+l6cHp2LiiPSG XmbMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pLxRiTJN88Mvbvkk/49aVnmiCITdugSzN7KdYjCvw uo=; b=F7mQpRmPcinYF2lD0mqpDdvHeS65d2yyl33hDFoa6OePqNoaFF1yP1Qro WdptCA8wh1QYvAoG1xG22be96CoqRBc5J6dIpYqN4iZm7sTPCiyJ3iVAhg3GjqYR aSIB4C27JblgFyMGHFfYeWptYbCbLx+frvetX/+IvvxJc9ahhx9bRBQp5kaQvzMn 4bvdoTpqj9R1WsS8MjfCONpL5TcxTQKiR/n+ZEEJ86gmM8/0Z06RX7EU29euHo/9 108l+X9SHzgi4grYl4COn3tlJ7Cf52YKCyq8sOf9tHfA7X0weDOeJs06sOtG3oTI PVRlTr6fiD8fvQC3GlYeigGIf1G5A== X-ME-Sender: X-ME-Proxy: Received: from [31.133.152.18] (dhcp-9812.meeting.ietf.org [31.133.152.18]) by mail.messagingengine.com (Postfix) with ESMTPA id CF324E4698; Mon, 5 Nov 2018 01:48:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Mon, 5 Nov 2018 13:52:43 +0700 Cc: Alexey Melnikov , dmarc@ietf.org, "Kurt Andersen (b)" Content-Transfer-Encoding: quoted-printable Message-Id: <997C3583-E6AD-437A-8EE0-ADFDF138AC59@fastmail.fm> References: <0c273037-69c0-a37f-7cf6-6c9a90ad3291@isode.com> To: Barry Leiba Archived-At: Subject: Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 06:48:55 -0000 On 5 Nov 2018, at 13:46, Barry Leiba wrote: >>>> Both of these are indeed normative in usage, but I was under the impres= sion that one could not >>>> refer to I-Ds as normative. >>>=20 >>> One can't, so that means that this document will be held by the RFC >>> Editor in a "MISSREF" (missing reference) state until both of the I-D >>> are also in the RFC Editor queue. Then this document will move ahead. >>=20 >> True, but being "afraid of a MISSREF" is not a good enough reason to pret= end that a Normative >> reference is Informative. >=20 > Of course not, and I didn't mean to imply that it was. I was > explaining that we *can* send the document forward with a missing > normative reference. "We" do not have to wait for it to clear; the > RFC Editor will. Then we are in full agreement. From nobody Mon Nov 5 00:07:51 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDE0128CFD for ; Mon, 5 Nov 2018 00:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bel5T9uPBIn8 for ; Mon, 5 Nov 2018 00:07:48 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 BE53E1274D0 for ; Mon, 5 Nov 2018 00:07:47 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id q6-v6so5425944lfh.9 for ; Mon, 05 Nov 2018 00:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ONcvv0OVqez8x3R2NhcLQRGWlMfs02TSsmicMgO2GpE=; b=TH/1ACcPaCnub7Y+OkWIhm0VISQYlpTIRcYISYwx9no2Vw5PbLvDYK2ul7LJoES7E+ tOE4QpwTPZOcJJZBFzw6jSpmfCyrMhBcB0JeCgBBW/lUotkryBg30aQayJRgIZunkST8 3cNntB5+xiqpBE8RRBw7WcfhaZJopSvYVt4ghTI7gM/p5Du3nQc+Rxa86pZ7mMsLOFlg EP/5OZ1RcePV8/kks8ztLu+D2rY462GonKVjDbRWyMb4hvtQtEeVe955NqHN+hAgXJpx DRmJPPe4n3cAF9tC+NmY4dhUC742VcYd2OC1Ns91b8tEU5i7D2zcbbkbQ5Ba4xluVA3X 74dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ONcvv0OVqez8x3R2NhcLQRGWlMfs02TSsmicMgO2GpE=; b=Ek+mbsQLjjBi5+MN6bVqJqfoetdeKz2R54X4bwT2GfHALBj13AhraC883DOtMODpkn 6XpaTrOXbVlrkrZ3oj/Zn7zzfoIRaBJYKqTSPvQZ1SSGCryx9nlfeD2edvzmpxfe9C0g qKSka3oW2frY0tyz8hOPvl9jbS5qZpg7dBRJVcAUYZL3mZnXk8SRd8Y1k1odIV/6FjPg 8yVmtQ/zPyfAh2RHk1qwKQmnnnr5kSmNbI/0unssK6Vze5bkL0rPE8epjnj10mO3tFaY mrTh25yabhGE8lagxlPCofHDkVeVnTBvghomNbK+6hvW/Swp6UsuQt2ohVeQJYDBBXQM OHKA== X-Gm-Message-State: AGRZ1gL36zuxVMFS068UTfdfa8gQiT5f2+q/Hhqax02tbIKX1WlVs4JL BmznS5t7KX7yeGh3LgxldFBsXk8YJ634fNONYpI= X-Google-Smtp-Source: AJdET5cEN+MArIQc7GFTGxYCi3ZhcT+EDRHbRMG9pIvfYPAJEYfn0Ai9Hp4UmoXIuZXaHjh86ueIlxwSJ9atUdUYzRc= X-Received: by 2002:a19:920a:: with SMTP id u10mr2056876lfd.122.1541405265689; Mon, 05 Nov 2018 00:07:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 17:07:33 +0900 Message-ID: To: Barry Leiba Cc: "" , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005106840579e6612f" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 08:07:50 -0000 --0000000000005106840579e6612f Content-Type: text/plain; charset="UTF-8" No objection. I've already got opinions ready to go when it gets accepted. :-) On Mon, Nov 5, 2018 at 3:23 PM Barry Leiba wrote: > > I'd like to recommend that we (DMARC-WG) accept > https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 > > into our work queue. It aligns with our charter already. > > I've seen three agreements and no objections, so here's an official > call for objections. If there are none by 16 November, we will create > draft-ietf-dmarc-psd-00 as a new working group item. > > Barry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005106840579e6612f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No objection.=C2=A0 I've already got opinions ready to= go when it gets accepted.=C2=A0 :-)

On Mon, Nov 5, 2018 at 3:23 PM Barry Leiba <barryleiba@computer.org> wrote:<= br>
> I'd like to recommend that= we (DMARC-WG) accept https://tools.ietf.org= /html/draft-kitterman-dmarc-psd-00
> into our work queue. It aligns with our charter already.

I've seen three agreements and no objections, so here's an official=
call for objections.=C2=A0 If there are none by 16 November, we will create=
draft-ietf-dmarc-psd-00 as a new working group item.

Barry

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000005106840579e6612f-- From nobody Mon Nov 5 00:13:18 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86725130EBA for ; Mon, 5 Nov 2018 00:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjW75knwFRVN for ; Mon, 5 Nov 2018 00:13:10 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 25E7B130DE7 for ; Mon, 5 Nov 2018 00:13:06 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id v5so462176lfe.7 for ; Mon, 05 Nov 2018 00:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M7il5vbiVZY6iYFT3ysZlS/cYUxjFjtfxg4zddfxwBU=; b=dGJL5yneomuoz7hD52aqEJZUMT1Pedap8xpkXWmL9fe2LathGI3QFEVLPNbqKD9XDn yeKp0aHncuSw2hucR6MH+frOooRCFBo0oWSy60c3VN4ZcE90xterdy79WZMb/WMAJ4Iq eTiAZDZK0pzrS+LHZlkpf+4FO3JC4mkaGSka8gGdlFDSessd9dvWKT3yhPaXoSrMaEDr 9/Zrk56DZ0FaPIVsPzC3YFWDV3yXM+3MQ85thPtIIjSGZ7m4ckuvK4xqy3CAJiWLB2Xz 9xQgC8ZJjY5I14Fm9OuZeaES5+ryQRIpUqkWGvyjE9wAdazp6x0+RSjkJtVSvCpjhqxD PjaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M7il5vbiVZY6iYFT3ysZlS/cYUxjFjtfxg4zddfxwBU=; b=VWjTR8ekZ2JUcdCEqOoedscSLoT8yJCet+a+YLEabfBA9+sGxMGZoMJguqk8Usa8Gu 0SwDEjNu9cNOgszZMUU/UflNtI+/nUWIpf6rOIkv8E7lO6q0ilS6Ons95H/LZYKV0POu zEglIvUYFKlSfKOedbasGTEpENvemeCga65Iehu0gHTLsg9GgEGUo8DMMObWNPqTBqYn ASDEph/jeCGL5DU1MurJrYEFU3kbP3DxVIGcnLcuipXv8qk1/8AxezXOhDK1ZBd4LwFZ qa2I5wo2Xxkh0tHYKYmw8PVpwVKjqQ/hvqRzO7A+zYP1pBU6mV6Zhbg7/7H00fUZr5gd JgwA== X-Gm-Message-State: AGRZ1gKYC90jyfa4IYivAYVBYfs7W8hOl60ZxVm+e02lqJqLZVWdLelD bdwqDJWdGBblIYEaDj728VxN2URuza3SUv207rQvTfAuYaI= X-Google-Smtp-Source: AJdET5cncABA3lJQeFP5TLVK+zze++vCV9KTXjAywNg7pMKs0CHTv8IOhAEA4EL/9bZdvuSP06ZIbT0bXUbWdDcLdYo= X-Received: by 2002:ac2:4299:: with SMTP id m25-v6mr11766104lfh.115.1541405584160; Mon, 05 Nov 2018 00:13:04 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <4082068.TRYGpCgONJ@kitterma-e6430> In-Reply-To: <4082068.TRYGpCgONJ@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 17:12:51 +0900 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004c7f020579e6742a" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 08:13:17 -0000 --0000000000004c7f020579e6742a Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman wrote: > I don't think it's something we should delay on. In my, admittedly > limited, > experience with these things, once something is in an experimental version > of > an RFC, then it 'has' to be preserved in the name of interoperability with > the > installed base. I think now is the time to remove obvious fluff. That's the opposite of my understanding of Experimental. Rather, I believe explicitly calling it an experiment means we reserve the right to mutate or even jettison portions of ARC we discover, through experimentation, interfere with interoperability either among ARC components, or with the operation of adjacent protocols, or provide more complexity than utility. If there's ambiguity around what "Experimental" means, we should take the time to sort that out and, if needed, add text to make it clear. This documents makes my head hurt enough as it is. > I've felt that on occasion too. Having reviewed the thread that Kurt pointed me to, it seemed like this is > something only one person wanted. It didn't appear to have a lot of push > behind it. > Based on my understanding of Experimental, I think a one-off feature is fine to include, again with the understanding that it could be omitted from a Proposed Standard version because it isn't widely useful. -MSK --0000000000004c7f020579e6742a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman <sklist@kitterman.com> wrote:
I don't think it= 's something we should delay on.=C2=A0 In my, admittedly limited,
experience with these things, once something is in an experimental version = of
an RFC, then it 'has' to be preserved in the name of interoperabili= ty with the
installed base.=C2=A0 I think now is the time to remove obvious fluff.
=C2=A0
That's the opposite of my understanding o= f Experimental.=C2=A0 Rather, I believe explicitly calling it an experiment= means we reserve the right to mutate or even jettison portions of ARC we d= iscover, through experimentation, interfere with interoperability either am= ong ARC components, or with the operation of adjacent protocols, or provide= more complexity than utility.

If there's = ambiguity around what "Experimental" means, we should take the ti= me to sort that out and, if needed, add text to make it clear.
This documen= ts makes my head hurt enough as it is.

= I've felt that on occasion too.

Having reviewed the thread that Kurt pointed me to, it se= emed like this is
something only one person wanted.=C2=A0 It didn't appear to have a lot = of push
behind it.

Based on my understanding of= Experimental, I think a one-off feature is fine to include, again with the= understanding that it could be omitted from a Proposed Standard version be= cause it isn't widely useful.

-MSK
--0000000000004c7f020579e6742a-- From nobody Mon Nov 5 00:14:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32BE1274D0 for ; Mon, 5 Nov 2018 00:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsrUiecBPdaZ for ; Mon, 5 Nov 2018 00:14:44 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 279E91271FF for ; Mon, 5 Nov 2018 00:14:44 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id t190-v6so5743894itb.2 for ; Mon, 05 Nov 2018 00:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4E3zEKsh/WZlqAKipR47dSIfI1AJILU6NdeAdt7shf0=; b=QAAjSRmr5aTs35xom/RuoCNeKFYGcYiXz/ygtbpIQjU3sMFgWZXBHQ4Tw21ep+9JVS M9Vl4IB8Dp2Udie9xpRAaAwsTaZeNMLhq+ioVXhQwsu4elreQijbzgarfhoOnYS9fDkT rjlkslGuXGes5u/T8iDu/Kl24SINQiOrRheUKH7Swy+sE+swKCF7ZI+RsQjAyoKB4blu IwCiaRwvTo2ZeThJFcHlobkOYey3Ho+a6qpwE7Hi6yiTIbhKju1D5DcMS5DQlRlvBpPk VeReXaov/k4s/Hve28Y7WS9oZpcAp6WeAAc365Sk5DPcp58kpb6W0zPnFwRX8+2Otnq3 5Agg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4E3zEKsh/WZlqAKipR47dSIfI1AJILU6NdeAdt7shf0=; b=CDDXINFkUO2qLsmzFixcnlPSfkngD3gaCvPnu80eDw7cYJVQ0B5GJk+fFJfRGiikBU MOduWhmm783TCw16jejmNN8xejCkN4vjnbKtOch3zcs5z5lEDDyBNmdR5i9ekIp/YBkN EmJx7PZdYA6JNb1nYFiylBF0SEJX6mIvcQpln3EbZiEDRNxSYo34/jZgyzUB0kXyYqti k/YpNSZmbD2MlE5pVG2sklWp9ZDjxnzAKb6d9mxNsJpZCsX4M3jrGBS0tg7Mc6mzmalH utCBChe7rdY2hOrq6be8lHdqmAFZ0yw1NNr0BjAAz0nd8XLCnW/e9FwQZhSv6xue4ett 5n6A== X-Gm-Message-State: AGRZ1gLzTnojBAF9tk8KAJilKr8K5Q1FdMm8Ddvgn7qhxeKBZgPQ2YJb t4YilS/Hw8UOK8G5jOKP8Tm2eUn/WGHHaSzpxE4= X-Google-Smtp-Source: AJdET5ckIT4FEJ3B5iqj2HmZMSGXT/Hz+U0TqPD1DSAPV0InEiXOA98cPOkEnA5iGcs+4JY+JS7aGkPSu66nc6fHxh4= X-Received: by 2002:a24:6882:: with SMTP id v124-v6mr5872559itb.124.1541405683433; Mon, 05 Nov 2018 00:14:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 5 Nov 2018 15:14:46 +0700 Message-ID: To: "Murray S. Kucherawy" Cc: Barry Leiba , dmarc@ietf.org, Kurt Andersen Content-Type: multipart/alternative; boundary="00000000000037440d0579e67aac" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 08:14:47 -0000 --00000000000037440d0579e67aac Content-Type: text/plain; charset="UTF-8" No objection here On Mon, Nov 5, 2018 at 3:07 PM Murray S. Kucherawy wrote: > No objection. I've already got opinions ready to go when it gets > accepted. :-) > > On Mon, Nov 5, 2018 at 3:23 PM Barry Leiba > wrote: > >> > I'd like to recommend that we (DMARC-WG) accept >> https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 >> > into our work queue. It aligns with our charter already. >> >> I've seen three agreements and no objections, so here's an official >> call for objections. If there are none by 16 November, we will create >> draft-ietf-dmarc-psd-00 as a new working group item. >> >> Barry >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000037440d0579e67aac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No objection here=C2=A0

On Mon, Nov 5, 2018 at 3:07 PM Murray S. Kucherawy <<= a href=3D"mailto:superuser@gmail.com">superuser@gmail.com> wrote:
No objection.=C2=A0 = I've already got opinions ready to go when it gets accepted.=C2=A0 :-)<= br>

On Mon, Nov 5, 201= 8 at 3:23 PM Barry Leiba <barryleiba@computer.org> wrote:
> I'd like to recommend that we (DMARC-WG) accept= https://tools.ietf.org/html/draft-kitterm= an-dmarc-psd-00
> into our work queue. It aligns with our charter already.

I've seen three agreements and no objections, so here's an official=
call for objections.=C2=A0 If there are none by 16 November, we will create=
draft-ietf-dmarc-psd-00 as a new working group item.

Barry

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000037440d0579e67aac-- From nobody Mon Nov 5 01:29:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910F130E96 for ; Mon, 5 Nov 2018 01:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElBFYXZj54zU for ; Mon, 5 Nov 2018 01:28:53 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85B1130E41 for ; Mon, 5 Nov 2018 01:28:52 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id t9-v6so4156031ljh.6 for ; Mon, 05 Nov 2018 01:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llRJtHqicDNlh6/VTz32YC+qW1JUrJ5IaVGAXGJb008=; b=fQXXjlo2qHg0dTVOItI5p59bOsHOlc4l9J7H76XfqilIFbHi3Ppt2uZknZQ1uisHCB CEaWbPG01j/rF9OpVn8pSEzNLROnhcwr/gi2YsTu1Bg3pM8GZdPx3xr/fjjgHnXrljvh tBPWL5WWTLvGU8ctPaxlUXP12xmQZgMnL5S+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llRJtHqicDNlh6/VTz32YC+qW1JUrJ5IaVGAXGJb008=; b=DXhg5btZ8LAEwxoN7tuAZjyHX/MSrnFm8f0C2vWjrSHIx3lxfdN7t+yKi/x5yUwQ4F u4LUpgfS49m6GuVmvEypNc0ojZn97Te2XxKMlXrp+tE3rPg8wtd4JO9prvj8yvQjgVzd M8MCnOw9KP2VhjgDeoc/MYc+6S+wBHZB+bUnJLRqI8dMGmHccZ+vW2r31x/so5gN+Mxw uQww184mquqvjV/4b7DC0k5oQnPt1m2IWJS/A4H1pueDzqmJgAbW+TtOg6Pe0qQFbVGr VsEwewG642ZkM4728c7631Kk2tdL7aUDuhLZSfGDera8WIHsjp3sITxDj6OGySkJS80Z RNHw== X-Gm-Message-State: AGRZ1gJdnjrzgIvqT7NBZr5XmxPebWBPPoK8HPQbCW9E3aPNUXTI4PT4 XrBqoSeFCXWXJGMdPmH62tg6kvzPabuTZY9Gjun70A== X-Google-Smtp-Source: AJdET5fS+P93hxjRoeBxRrfQRjckaVt0KZpm6RWtrLgONbIXCvz8t7n4d98Nj8aSIf9pW0z7N+SpplzPkEnh9wDI+7E= X-Received: by 2002:a2e:710a:: with SMTP id m10-v6mr10003242ljc.66.1541410130688; Mon, 05 Nov 2018 01:28:50 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <4082068.TRYGpCgONJ@kitterma-e6430> In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 5 Nov 2018 16:28:20 +0700 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , "dmarc@ietf.org" , Bron Gondwana Content-Type: multipart/alternative; boundary="0000000000004b146f0579e78331" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 09:28:59 -0000 --0000000000004b146f0579e78331 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 3:13 PM Murray S. Kucherawy wrote: > On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman > wrote: > >> Having reviewed the thread that Kurt pointed me to, it seemed like this >> is >> something only one person wanted. It didn't appear to have a lot of push >> behind it. >> > > Based on my understanding of Experimental, I think a one-off feature is > fine to include, again with the understanding that it could be omitted from > a Proposed Standard version because it isn't widely useful. > Throwing it in because we were aiming at the "experimental" designation seemed to be the easiest way to resolve the non-progressing discussion when it initially cropped up in August 2017. The topic was permuted from nearest-fail to oldest-pass in January 2018 to make the calculation algorithm and interpretation of the data point a bit clearer but I don't think that anyone has changed their mind much from their positions in August 2017 - unless, as Scott pointed out, the one person who insisted on this has done so silently. --Kurt --0000000000004b146f0579e78331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5,= 2018 at 3:13 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman <sklist@kitterman.co= m> wrote:
H= aving reviewed the thread that Kurt pointed me to, it seemed like this is <= br> something only one person wanted.=C2=A0 It didn't appear to have a lot = of push
behind it.

Based on my understanding of= Experimental, I think a one-off feature is fine to include, again with the= understanding that it could be omitted from a Proposed Standard version be= cause it isn't widely useful.

Throwing it in because we were aiming at the "experimental&qu= ot; designation seemed to be the easiest way to resolve the non-progressing= discussion when it initially cropped up in August 2017. The topic was perm= uted from nearest-fail to oldest-pass in January 2018 to make the calculati= on algorithm and interpretation of the data point a bit clearer but I don&#= 39;t think that anyone has changed their mind much from their positions in = August 2017 - unless, as Scott pointed out, the one person who insisted on = this has done so silently.

--Kurt
--0000000000004b146f0579e78331-- From nobody Mon Nov 5 09:53:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A439112008A for ; Mon, 5 Nov 2018 09:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ULG8m17PeT5 for ; Mon, 5 Nov 2018 09:53:21 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::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 509CD127133 for ; Mon, 5 Nov 2018 09:53:21 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id j202-v6so8242425oih.10 for ; Mon, 05 Nov 2018 09:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1UDGA87pwygtRdN6BeXw/zGZU+y9wQ/+a4UXEEhwn9Q=; b=THjYPhhxzH7G54ZaVbdqgcC/YZFcQKgJE8ChDi261SideC9K+b61qO/9dMx9oTyeAb FzjF5iBu2YOespQiWlW74spQMgPxwALZ/sRLrjqlMuMREPLCbh7Mz9kykV7VlZ4dTtKV D08YfRPPbpOvvhoBzYBjgUDP9cBPM2MB2bb3PjtCs0aFwEDJGehG43d6mJ0wo1+WHCIH GP9mgI/sFpOl1P4/lOC8Nxtj54qPRg8721mNHGRZEXkhgmXnUS8a0wSslY5BqK5NVwdB iJLFnJ3EAifvT70n9E7XI77yLGxnMud0SA/AvNYJSSeEmgdtBzqLo+mWhae/wN+BiieF 4sAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1UDGA87pwygtRdN6BeXw/zGZU+y9wQ/+a4UXEEhwn9Q=; b=PKjsWKO+751bZr4ZO5TL0jL7dAVrw0Ewo/gpZYe/4zX3JctFYM8KcaIAld+jQldJ+d KVfu9fukC5n/Ew6FO8XT4oJtw3FTf0djCkekD3zEDjtt5bl5pQQZw5HkZaN0FuNM4O7t AjgXnwTZvSOyCjiZ0karTFqzSD8Ay1X+VFv0IwDan1XbBB5Uqb609i2E8+wi9/PmAThV zWHS8GCwWwGm6KCcHeTlRYpGLs5SMpGy9I/38STTaR4S3oGnSX4rMswQ0/MQfJmZPqnT FUiaMLK8bAWaYI9YG1qxyyDa45ikrC2z0cPRw90whb/mI8lKQ+nowoGlb2cWsST+QDH2 eJvA== X-Gm-Message-State: AGRZ1gKJdlL19yiHa8WvbckvcyrTbt8V4VaShcT19QZC90y+2M8usaBJ Rkqxm0xwFOxUTswf349ZxALqls1rQpkd9BS6ZeKHceid X-Google-Smtp-Source: AJdET5dr/TfWQ8CzSkHrGfLD+ikBnaKEz+QENPGOhZH03oJqX3SCwe+Iky0979fF5McbSBY+KM46MCpAVjuqstgils8= X-Received: by 2002:aca:dd42:: with SMTP id u63-v6mr12544269oig.306.1541440399885; Mon, 05 Nov 2018 09:53:19 -0800 (PST) MIME-Version: 1.0 References: <2393746.3XrAvFVKfY@kitterma-e6430> <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> In-Reply-To: <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com> From: Seth Blank Date: Mon, 5 Nov 2018 12:53:08 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007a60c40579ee8fa2" Archived-At: Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 17:53:24 -0000 --0000000000007a60c40579ee8fa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think MSK=E2=80=99s text with Kitterman=E2=80=99s caveat cleanly carved o= ut for interoperability regressions is the optimal charter update. On Mon, Nov 5, 2018 at 00:14 Scott Kitterman wrote: > > > On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman > >wrote: > > > >> On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote: > >> > I think that we could possibly already read this into the existing > >> charter, > >> > but the following one sentence patch makes it explicit: > >> > > >> > diff --git a/dmarc-wg-charter b/dmarc-wg-charter > >> > index a1d0fac..c8ac6bc 100644 > >> > --- a/dmarc-wg-charter > >> > +++ b/dmarc-wg-charter > >> > @@ -81,6 +81,9 @@ the working group can consider extending the base > >DMARC > >> > specification > >> > to accommodate such a standard, should it be developed during the > >> > life of this working group. > >> > > >> > +Clarifying the handling of internationalized email addresses (EAI) > >> > +throughout the authentication stack of SPF, DKIM, and DMARC. > >> > + > >> > Improvements in DMARC features (identifier alignment, reporting, > >> > policy preferences) will be considered, such as: > >> > > >> > --Kurt > >> > >> I don't see anything about changes to SPF or DKIM being within the > >current > >> charter, so if we are going to do this, then I think it definitely > >needs a > >> charter change. > >> > >> What needs changing in SPF/DKIM that we need to take this on? > >> > > > >This came out of this morning's DISPATCH meeting at IETF103 ( > >https://tools.ietf.org/wg/dispatch/agenda) to be able to accept > >http://tools.ietf.org/html?draft=3Ddraft-levine-appsarea-eaiauth into th= e > >WG > >for advancing it to an RFC (probably informational). > > Thanks. It doesn't appear that it proposes any changes for SPF. It > merely documents that non-ascii local parts don't match the related > macros. During the SPFbis working group we looked at this and explicitly > decided on it. It's not by accident. > > Since local part macros are very rarely used, it seemed like very much a > corner case not worth it to break the installed base over. > > If there's going to be a charter change around this, I think it needs som= e > words to constrain the work to limit interoperability implications. > > I know less about the implications for DKIM and DMARC, but would imagine > backward compatibility is important there too. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000007a60c40579ee8fa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think MSK=E2=80=99s text with Kitterman=E2=80=99s = caveat cleanly carved out for interoperability regressions is the optimal c= harter update.

On Mon,= Nov 5, 2018 at 00:14 Scott Kitterman <sklist@kitterman.com> wrote:


On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> w= rote:
>On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote:
>> > I think that we could possibly already read this into the exi= sting
>> charter,
>> > but the following one sentence patch makes it explicit:
>> >
>> > diff --git a/dmarc-wg-charter b/dmarc-wg-charter
>> > index a1d0fac..c8ac6bc 100644
>> > --- a/dmarc-wg-charter
>> > +++ b/dmarc-wg-charter
>> > @@ -81,6 +81,9 @@ the working group can consider extending th= e base
>DMARC
>> > specification
>> >=C2=A0 to accommodate such a standard, should it be developed = during the
>> >=C2=A0 life of this working group.
>> >
>> > +Clarifying the handling of internationalized email addresses= (EAI)
>> > +throughout the authentication stack of SPF, DKIM, and DMARC.=
>> > +
>> >=C2=A0 Improvements in DMARC features (identifier alignment, r= eporting,
>> >=C2=A0 policy preferences) will be considered, such as:
>> >
>> > --Kurt
>>
>> I don't see anything about changes to SPF or DKIM being within= the
>current
>> charter, so if we are going to do this, then I think it definitely=
>needs a
>> charter change.
>>
>> What needs changing in SPF/DKIM that we need to take this on?
>>
>
>This came out of this morning's DISPATCH meeting at IETF103 (
>https://tools.ietf.org/wg/dispatch/agenda) to be ab= le to accept
>http://tools.ietf.org/html?draft= =3Ddraft-levine-appsarea-eaiauth into the
>WG
>for advancing it to an RFC (probably informational).

Thanks.=C2=A0 It doesn't appear that it proposes any changes for SPF.= =C2=A0 It merely documents that non-ascii local parts don't match the r= elated macros.=C2=A0 During the SPFbis working group we looked at this and = explicitly decided on it.=C2=A0 It's not by accident.

Since local part macros are very rarely used, it seemed like very much a co= rner case not worth it to break the installed base over.

If there's going to be a charter change around this, I think it needs s= ome words to constrain the work to limit interoperability implications.

I know less about the implications for DKIM and DMARC, but would imagine ba= ckward compatibility is important there too.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000007a60c40579ee8fa2-- From nobody Mon Nov 5 13:06:30 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466811288BD for ; Mon, 5 Nov 2018 13:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGP10bzYBsuX for ; Mon, 5 Nov 2018 13:06:27 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 845F41286E7 for ; Mon, 5 Nov 2018 13:06:27 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id o204-v6so4412429yba.9 for ; Mon, 05 Nov 2018 13:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=te6DlG1tlmxZe+6hxRwUmMv9Y+V+d008KxNZqFNpiq0=; b=o8bWk+8FPYaihatYKp2h+UxjPqe3YpVJXDZD4b7mnRLLrtnxQoqRr6QstD7PVoP9u8 g03uv2RApwGlHM0tisI2YO+WCw4alSyRkVQ3bocmGuBzRdQ+s4PrQKAFmTK6S4wEm9S+ HEdErrxZDxm18wgiJl4tDfUFxZ8RxRPXyx/VFVam/glMCGchTgwLKFs/72KquwG+xOsN OMqAgWnV1oWDENgABFU6H1qHcRzPSSBSywqTCpoyVKs6q9yYWLGI+p8LRFdg6vQMi81f H0XoHmtICGNslQZgfs1LArHnr6bkGomrOm35+K10oCV3iC/AL4wDJM0G3ASEnGwx5sX/ 1y6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=te6DlG1tlmxZe+6hxRwUmMv9Y+V+d008KxNZqFNpiq0=; b=GIMar4wiHGIzr66vxIykCqleH2Rdd4NPnbBqRqv79gxxNN1AdUvWWnW9TAGhMPn62u uZAMsxXWbKj7CxmbQOKBbsPtN1NRQljhqTgBklMjfhBGU74RDa57mggJNz8a9ZsVAjvY FSXlGby+nB13peU5Q/96E7wb+6Zbr3FAnKnDHxS83kZAfO4vZ+pH4fT1DIvliJU+j6wZ Pbk9MXTNxVMGV2xXEnc3sjU9uH/MF4LHvzikJh3D1hbj4hvAo258ruXvtPlKck3ctyYI DDLJtJO1s/R3XiZZpI2LqEl9Isc0R5u40rygJmD0k17I/TT4+viKrFgpSu94RGb9sHzJ RKpQ== X-Gm-Message-State: AGRZ1gIPsM5Qhg0+ryw56ZtMwuPnvT4HD5pM7MtM4CxnwYgMtZefLrsJ WmihHsjwOYmVxfpsUyIK7zwXRygI8vmC1gsSEQBrCpkT0w== X-Google-Smtp-Source: AJdET5dqwWsJB1iAeFRhT1dN04gnNJYoHHVzyyWlLEyHUEjtG2pSuZfYelJrmG0nf0XylkNHIZVoySDkHlPtE3VF8WM= X-Received: by 2002:a25:9381:: with SMTP id a1-v6mr20713353ybm.386.1541451985824; Mon, 05 Nov 2018 13:06:25 -0800 (PST) MIME-Version: 1.0 References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> In-Reply-To: From: Brandon Long Date: Mon, 5 Nov 2018 13:06:13 -0800 Message-ID: To: "Kurt Andersen (b)" Cc: John Levine , IETF DMARC WG , Scott Kitterman Content-Type: multipart/alternative; boundary="0000000000000e3db40579f142f0" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 21:06:29 -0000 --0000000000000e3db40579f142f0 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 2, 2018 at 2:13 AM Kurt Andersen (b) wrote: > On Fri, Nov 2, 2018, 18:09 John R Levine >> On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: >> >> I mean ARC as it's implemented now, not in our multi-signing draft. >> > It seems like a poor implementation choice to be enforcing something >> which >> > is not part of the spec :-), especially when there are parenthetical >> > comments and references to things like ARC-MULTI to warn you against >> > leaping to foot-shooting enforcement choices. >> >> I see it also says: >> >> Valid ARC Sets MUST have exactly one instance of each ARC header >> field (AAR, AMS, and AS) for a given instance value and signing >> algorithm. >> >> I'm reasonably sure that doesn't match a lot of running code. I'm >> particularly thinking of gmail here. >> > > That should be easy to test but not with a tiny keyboard as I board my > flight from ICN --> BKK. > If it does work, I'd be a surprised. Most likely, it'll fail validation prior to full parsing (we extract the i= first, and only fully parse all the k=v pairs later). Also, does that mean you have to use the same algorithm in both the AMS and AS for a given instance? And how does that correspond to an AAR which doesn't have an algorithm... and how does that work with the AS signing previous headers, does it only sign the ones with matching algorithm? I'd be a bit surprised if all of those caveats are correctly matched in the original arc spec. Brandon --0000000000000e3db40579f142f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Nov 2, 2018 at 2:13 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On = Fri, Nov 2, 2018, 18:09 John R Levine <johnl@taugh.com wrote:
On Fri, 2 Nov 2018, Kurt Andersen (b) wrote:
>> I mean ARC as it's implemented now, not in our multi-signing d= raft.
> It seems like a poor implementation choice to be enforcing something w= hich
> is not part of the spec :-), especially when there are parenthetical > comments and references to things like ARC-MULTI to warn you against > leaping to foot-shooting enforcement choices.

I see it also says:

=C2=A0 =C2=A0 Valid ARC Sets MUST have exactly one instance of each ARC hea= der
=C2=A0 =C2=A0 field (AAR, AMS, and AS) for a given instance value and signi= ng
=C2=A0 =C2=A0 algorithm.

I'm reasonably sure that doesn't match a lot of running code.=C2=A0= I'm
particularly thinking of gmail here.

That should be easy to test but not w= ith a tiny keyboard as I board my flight from ICN --> BKK.

If it does work, I'd be a surprised.=C2= =A0 Most likely, it'll fail validation prior to full parsing (we extrac= t the i=3D first, and only fully parse all the k=3Dv pairs later).

Also, does that mean you have to use the same algorithm in= both the AMS and AS for a given instance?=C2=A0 And how does that correspo= nd to an AAR which doesn't have an algorithm... and how does that work = with the AS signing previous headers, does it only sign the ones with match= ing algorithm?

I'd be a bit surprised if all o= f those caveats are correctly matched in the original arc spec.
<= br>
Brandon=C2=A0
--0000000000000e3db40579f142f0-- From nobody Mon Nov 5 13:23:46 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547B812D4ED for ; Mon, 5 Nov 2018 13:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=6BGigH6Q; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bWPJtp0e 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 ItIoCMu3aSuA for ; Mon, 5 Nov 2018 13:23:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6F6123FFD for ; Mon, 5 Nov 2018 13:23:42 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541453021; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OYuNp/aLhitX/KbHOYN8rFYwTrRVQ5a6GTkqDMddg2c=; b=6BGigH6QCUbLTBLHvQ/gJcx0u64DdXaLEyASIjOUPXo7V0FM9rgbCv5A EedmcMCa5B2jAg64AL41uJBjS01BAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541453021; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OYuNp/aLhitX/KbHOYN8rFYwTrRVQ5a6GTkqDMddg2c=; b=bWPJtp0eRgcCw8658KpymCr1zXTCFmtsyJe0KLwkAK74lHvl/2zL24tv th9hwcIiriG8GR6cMZuTdBeytkVQ9GjWLL1NkPXfphSCrgfZOgIIBySKbX iQGdsT1QTYQyDfkil5eCocnqXS2yQ2jo8dKpmycfQU95L/cYDNotz8ccR9 0KJt9hlspDhS5B01pCMuYi64yGvKxJmcFGifpScG/eQayhItPhFbWpi8Hs oZ6sYKmcIlGiOE/0SfxHgaUZsO7yB9OMM1IFxAEeRqjprVmR+NWeho1g97 /Qbv7dHDCcOxMt4Aom+2P36eQ8g5/9pORhb+931a8sB/ITWf2Y1RZQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4BE7CC40216 for ; Mon, 5 Nov 2018 15:23:41 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 05 Nov 2018 16:23:40 -0500 Message-ID: <2822808.Ke6N8m6fH5@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <9957335.dUWMaE32Bo@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 05 Nov 2018 21:23:45 -0000 On Monday, November 05, 2018 01:06:13 PM Brandon Long wrote: > On Fri, Nov 2, 2018 at 2:13 AM Kurt Andersen (b) wrote: > > On Fri, Nov 2, 2018, 18:09 John R Levine >> On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> >> I mean ARC as it's implemented now, not in our multi-signing draft. > >> > > >> > It seems like a poor implementation choice to be enforcing something > >> > >> which > >> > >> > is not part of the spec :-), especially when there are parenthetical > >> > comments and references to things like ARC-MULTI to warn you against > >> > leaping to foot-shooting enforcement choices. > >> > >> I see it also says: > >> Valid ARC Sets MUST have exactly one instance of each ARC header > >> field (AAR, AMS, and AS) for a given instance value and signing > >> algorithm. > >> > >> I'm reasonably sure that doesn't match a lot of running code. I'm > >> particularly thinking of gmail here. > > > > That should be easy to test but not with a tiny keyboard as I board my > > flight from ICN --> BKK. > > If it does work, I'd be a surprised. Most likely, it'll fail validation > prior to full parsing (we extract the i= first, and only fully parse all > the k=v pairs later). > > Also, does that mean you have to use the same algorithm in both the AMS and > AS for a given instance? And how does that correspond to an AAR which > doesn't have an algorithm... and how does that work with the AS signing > previous headers, does it only sign the ones with matching algorithm? > > I'd be a bit surprised if all of those caveats are correctly matched in the > original arc spec. OK. Thanks for the implementation feedback. Do you have any suggestions for a change that would make an AMS/AS be silently ignored? My thought had been one AMS/AS pair per algorithm (treated effectively as one AMS/AS) and a single AAR. I guess it won't be that easy. Scott K From nobody Mon Nov 5 19:08:56 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95693130DCC for ; Mon, 5 Nov 2018 19:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=HdiozpA8; dkim=pass (1536-bit key) header.d=taugh.com header.b=fZ75ZlVi 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 k-xCtAKsn4fA for ; Mon, 5 Nov 2018 19:08:52 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F218127148 for ; Mon, 5 Nov 2018 19:08:51 -0800 (PST) Received: (qmail 45091 invoked from network); 6 Nov 2018 03:08:50 -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=b021.5be105c2.k1811; bh=/9KtLragsaJpnEU6PCxfkpSIy/5ljMTVqF0jumfF+eE=; b=HdiozpA8PFJad6qlkS6FftZOzlFoc0Zw/8vSRYqxjDmWum+eBCGA6F6jn3OwselU1/4j84+0DlF7oFMgMBPWdnCFIbwqx24/FmJw5W6rontA9hzTgSoBFVOtkcxKH2BlKnYZhr0SMd0ruoVymhJDr7E3ywP03pZf+1uoPNxGhgllRtpS7pIJ19bxPSRrD8cdTchv40j3fvUSSs3ptBV22A5uQnSxKC73OkcB++FNLxomyGT0bfQrcowCVq2IzHbP 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=b021.5be105c2.k1811; bh=/9KtLragsaJpnEU6PCxfkpSIy/5ljMTVqF0jumfF+eE=; b=fZ75ZlViAcqcBuM3bljv27yDLPnc0wUOE6HbuflCKvRYebOCr/FqVa3enVToSq6e+EeZJw/OYMyrB9uK19S62mAdW0LlvHS6wRKqhn2EoFXF6lLjEaKi6OEACm1KXmBH01JWFytWjpXgiPFL9NAYrgc9QtJzDsyNNmFKJ9JTEn0UlEMDGsxpQJMIXBdnSenb5K6G0jEfmS4n9fn73GjUilpRIx+vwYN5wogMgZMOLDLBwQ0lWMuzI53MiGDF9F5b Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Nov 2018 03:08:50 -0000 Date: 6 Nov 2018 10:08:46 +0700 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: References: <9957335.dUWMaE32Bo@kitterma-e6430> <20181101235621.AF0B52007DFEBA@ary.local> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC Multi Proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 03:08:54 -0000 On Mon, 5 Nov 2018, Brandon Long wrote: > If it does work, I'd be a surprised. Most likely, it'll fail validation > prior to full parsing (we extract the i= first, and only fully parse all > the k=v pairs later). > > Also, does that mean you have to use the same algorithm in both the AMS and > AS for a given instance? And how does that correspond to an AAR which > doesn't have an algorithm... and how does that work with the AS signing > previous headers, does it only sign the ones with matching algorithm? That's in my draft. Each chain of seals uses a single algorithm, so the AS and AMS algos all have to match. There's no signature in the AAR so it's shared between multiple seals in the same instance. You're only allowed to seal the longest chain(s) so if the longest chain uses an algorithm you don't understand, it fails. > I'd be a bit surprised if all of those caveats are correctly matched in the > original arc spec. No kidding. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 5 23:52:53 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A2612D4E9; Mon, 5 Nov 2018 23:52:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154149076555.25454.15450692499333675304@ietfa.amsl.com> Date: Mon, 05 Nov 2018 23:52:45 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-19.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 07:52:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-19.txt Pages : 39 Date : 2018-11-05 Abstract: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-19 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 6 00:00:47 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0FF127133 for ; Tue, 6 Nov 2018 00:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Roib2pOGkyLr for ; Tue, 6 Nov 2018 00:00:42 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275BB128CF2 for ; Tue, 6 Nov 2018 00:00:42 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id q186-v6so10553922ljb.5 for ; Tue, 06 Nov 2018 00:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eVzM39UUUHS/7wN0WgiWh7Rf534BMfnzNO+y2Hc7/aE=; b=eI8Qabe9RCiDMTzEEprTOCpQeTQapdEmkSnf4BpzQjnCbaW5p++f3JXbZhp94GUiHJ nITTHCuerhPpGzZ8Kpqlh6nvXmMNcgstdf6VCEwxSHb6qfe4Bdkhq34n69MaUnzBGxzT rJLJAk0PzVgiGcexXL+6vDAvtWRup3N5tIgv4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eVzM39UUUHS/7wN0WgiWh7Rf534BMfnzNO+y2Hc7/aE=; b=Gdyvxa6uGXLb0UuPEhqN0XXecGTRaBpK7oBmDNxFBMSuAtcbBTabe4ny7MSF7pOeN6 5iNORhTjMr+yVuFSv/adUlm5f15vcW2t/ZNt6oIzNLzDf0KFK4XF8ff5MZu8iTZPE9Zt F3M4bU4TCHWBNhDKksz8rPb7oXsDVqyg6YmXUzR7/tFS3OQqT+00NxBLe1v5NBt0LDtw mrEJGPHFYcBIWM0EW8wcTnWOJWyhTIkyySOpxTd1erse7SL7ZQXZj9+Rgt3+vyS3YDaw yloxe2tfmeF93j7n1skV48pClR9IOyZ62L3AhEmTSY4f/aLhCwN3xQutr3fKLAxw1gkq EU1g== X-Gm-Message-State: AGRZ1gL418G0ljjiMTAc7/RS+Py61CCE+a6o4sb27NuYjdl80qffJEEi vn4t7v6LvSaLijmQ1edvXyQX8UFKHik+4gGiwaTqBzfr X-Google-Smtp-Source: AJdET5fFRIunbW0IS6mpDHQEo1F8lq1xm5Keg0K6xob+MIeGSlRrKjqrst4dayg05LRiXH2Z4bFF6bnfPVUYZPlmuXk= X-Received: by 2002:a2e:5152:: with SMTP id b18-v6mr2543678lje.88.1541491239582; Tue, 06 Nov 2018 00:00:39 -0800 (PST) MIME-Version: 1.0 References: <154149076555.25454.15450692499333675304@ietfa.amsl.com> In-Reply-To: <154149076555.25454.15450692499333675304@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Tue, 6 Nov 2018 15:00:26 +0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c2a4120579fa6592" Archived-At: Subject: [dmarc-ietf] Changes in draft-ietf-dmarc-arc-protocol-19 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:00:46 -0000 --000000000000c2a4120579fa6592 Content-Type: text/plain; charset="UTF-8" This revision (-19) fixes the following issues from the last call: 1. Alexey's comments regarding the normative/informative classification of John's EAI document and 7601bis; 2. An error discovered in the IANA considerations section; and 3. Provides a sample message with ARC in Appendix B (h/t to Marc Bradshaw for a version of ARC signing and verifying s/w that did not require a fake DNS resolver to look up test records!). --Kurt On Tue, Nov 6, 2018 at 2:53 PM wrote: > > Title : Authenticated Received Chain (ARC) Protocol > Filename : draft-ietf-dmarc-arc-protocol-19 > Pages : 39 > Date : 2018-11-05 > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-19 > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-19 > --000000000000c2a4120579fa6592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This revision (-19) fixes the following issues from the la= st call:
  1. Alexey's comments regarding the normative/informat= ive classification of John's EAI document and 7601bis;
  2. An error= discovered in the IANA considerations section; and
  3. Provides a samp= le message with ARC in Appendix B (h/t to Marc Bradshaw for a version of AR= C signing and verifying s/w that did not require a fake DNS resolver to loo= k up test records!).
--Kurt

On Tue, Nov 6, 2018 at 2:53 PM <internet-drafts@ietf.org> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Authenticated Received Chain (ARC) Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-dmarc-arc-protocol-19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 39
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-11-05

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-dmarc-arc-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-d= marc-arc-protocol-19
https://datatracker.ietf.org/d= oc/html/draft-ietf-dmarc-arc-protocol-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-dmarc-arc-protocol-19
--000000000000c2a4120579fa6592-- From nobody Tue Nov 6 01:10:16 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AB31271FF; Tue, 6 Nov 2018 01:10:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154149540835.30885.15942811944907820379@ietfa.amsl.com> Date: Tue, 06 Nov 2018 01:10:08 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-20.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:10:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-20.txt Pages : 39 Date : 2018-11-06 Abstract: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-20 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 6 01:14:41 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7812D4F1 for ; Tue, 6 Nov 2018 01:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpcaqTpAegDz for ; Tue, 6 Nov 2018 01:14:36 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F0C130DC5 for ; Tue, 6 Nov 2018 01:14:35 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id f3-v6so10731154ljk.9 for ; Tue, 06 Nov 2018 01:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lwU6m30pQ2Z7OumQlyqH5hW8Uu05ClMC0O6jB92c8Tg=; b=Rr1jCUmWrtnIqWkUdRSRJTDzehOduwja8/SwLrCEo52IORndcfKtNHcV807CbjHXF8 5u7YC9Mbe/Wku1woO07HySO97/7yqEb8JY9vbMJK9u8meOTI2TNU7Mdbh2x6bFVu+/3q SodmhC+8c1yjsg0WgcZEpYL7RdliGsVf5z3D8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lwU6m30pQ2Z7OumQlyqH5hW8Uu05ClMC0O6jB92c8Tg=; b=pfdIgc3y8HYpWsTx/g2yHtmTlHz92K0KJGv7cvRrQlLZ1fu7bLwOvykw4ZPl1jBdBc Yp3hTIw1dWt7XqWAsWNRqp+3uAGAKiEUxXcGwmzd80/e1ViSr8FW3wETXP4dcreW01Rn y+q+mGS4psSpobcRghGEUewlePmvmSwNm/0inf3N9/nPDgTd3pbRhsfgqjffKkBEx/G1 m28LKcx5S8E4LV7aJX46U8oJt10eXHvHE9ND4HfSAuorEhpfYMx4U9+zko3X7RgAjbmU 2q8em7Gi7BNmANekKH7ttSWiKmA+eIl/artPMvo9SSq7yLbG4RSbxW2DhY1rx94sPtPC EwpA== X-Gm-Message-State: AGRZ1gLGV1qCZ9tIx0fd8h9/bun40A9eQMK8pxHnbnyIAuek1JI4Li0v Qf6WxDDdp07m/wcFGfZzyzKdDeW6/P11QfpKYFZ2/UcV X-Google-Smtp-Source: AJdET5dXcT1WcNmfIpzOmYl2rDtY4LhtdHgymzCUYkzifJwHz3GSw5iICcNG0tCL7FzAQL9w5VwG1cP6iMIOn3I0trk= X-Received: by 2002:a2e:5b1d:: with SMTP id p29-v6mr16522162ljb.176.1541495672469; Tue, 06 Nov 2018 01:14:32 -0800 (PST) MIME-Version: 1.0 References: <154149540857.30885.17908638545780838605.idtracker@ietfa.amsl.com> In-Reply-To: <154149540857.30885.17908638545780838605.idtracker@ietfa.amsl.com> From: Kurt Andersen Date: Tue, 6 Nov 2018 16:14:19 +0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fb20350579fb6d4e" Archived-At: Subject: [dmarc-ietf] Changes for draft-ietf-dmarc-arc-protocol-20 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:14:40 -0000 --000000000000fb20350579fb6d4e Content-Type: text/plain; charset="UTF-8" Note to the WG - this version corrects the status designation for the ARC header field names in the IANA considerations section per feedback from one of the IANA reviewers. --Kurt On Tue, Nov 6, 2018 at 4:10 PM wrote: > > A new version of I-D, draft-ietf-dmarc-arc-protocol-20.txt > has been successfully submitted by Kurt Andersen and posted to the > IETF repository. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-20.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-20 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-20 > --000000000000fb20350579fb6d4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note to the WG - this version corrects the status designat= ion for the ARC header field names in the IANA considerations section per f= eedback from one of the IANA reviewers.

--Kurt

On Tue, Nov 6, 2018 at 4:10 PM &l= t;internet-drafts@ietf.org&= gt; wrote:

A new version of I-D, draft-ietf-dmarc-arc-protocol-20.txt
has been successfully submitted by Kurt Andersen and posted to the
IETF repository.

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-dmar= c-arc-protocol-20.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-20
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol<= br> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-prot= ocol-20
--000000000000fb20350579fb6d4e-- From nobody Tue Nov 6 01:51:58 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EC3128A5C for ; Tue, 6 Nov 2018 01:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OgZ9XwFS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L3RTQx6T 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 UYcjjo7ifUR3 for ; Tue, 6 Nov 2018 01:51:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8C0130E8B for ; Tue, 6 Nov 2018 01:51:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0F2DB21E07 for ; Tue, 6 Nov 2018 04:51:54 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 06 Nov 2018 04:51:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=Tnh74GVMiCYzmJIU8bkZbdpmjaG7 40mwwshXoImL/hg=; b=OgZ9XwFSIDFWCUFoDWT2TDcNn8xnyJ+QxUqljo5XmkG6 nzVncjt8fTm0PYAlBsIFqw8D5E2RMaOZi0eqFxP/5rkuSNyK1f2646yUUvcgM26b ePP6rWLH3O5jXVoYX5mNfaErVCRY+tvRp0ejtKpmVRvKm+4F0exqebQ+vH1LeRQD tpk16YGskPPZ/ulYJ2e6S0l6GZTo29qhA/2lMmGRbC8ClgE0h6A2vxDOKBMIjDce i3Ioijh2Epd+sf98nqWHbLbFAPzpMG0pxg+GwyD+/Oqo1QrO75yZTONMajaTj0eC PQ3KDLwWHrTHsoaA7HcwwmHR6J0qdu8ktG1yrnUMmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Tnh74GVMiCYzmJIU8 bkZbdpmjaG740mwwshXoImL/hg=; b=L3RTQx6TRBBgAJPsb9qGUF1d6lwHURPGQ HBXlsLbREzH8EX3mHdv+lzDH6zLrZbomyHXU4dLDinuQsfvqRDnar6tF/z/kqYnV dgH8qIe9F01bSZuTUCQlg/+5ITlsXbX8iG3i4lUutgPdXIR020iW8koPg2l6OsWX tyoX6fgTJIRioz5S2eHZNUw6P38PZRTTVf4J+MB/NNUqgxUIhhpbPy6V7l6yKrOM CxG7T13Lm+xPEuf59gHHhHz21q920x5t3TxrI/EusAepy5slfEmC8W8obtKdFJtY QxdLiKQixHlAh3HPqs0XZA8tEKD7557dr5yNVD2FxzfwyS2vfuiwg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 95D7E20207; Tue, 6 Nov 2018 04:51:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Message-Id: <753be398-badd-4089-be3a-1fb027e98567@sloti7d1t02> User-Agent: Cyrus-JMAP/3.1.5-610-gd7ceb27-fmstable-20181026v1 X-Me-Personality: 56629417 In-Reply-To: References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <4082068.TRYGpCgONJ@kitterma-e6430> Date: Tue, 06 Nov 2018 04:51:53 -0500 From: "Bron Gondwana" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=defb108d6b2744d1b6dec136ba8ddc89 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Concerns_about_Oldest-Pass_=28was=3A_Last?= =?utf-8?q?_Call=3A_=3Cdraft-ietf-dmarc-arc-protocol-18=2Etxt=3E=2E=2E=2E?= =?utf-8?q?=29?= X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 09:51:57 -0000 --defb108d6b2744d1b6dec136ba8ddc89 Content-Type: text/plain On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote: > On Mon, Nov 5, 2018 at 3:13 PM Murray S. Kucherawy wrote: >> On Mon, Nov 5, 2018 at 2:25 PM Scott Kitterman wrote: >>> Having reviewed the thread that Kurt pointed me to, it seemed like this is >>> something only one person wanted. It didn't appear to have a lot of push >>> behind it. >> >> Based on my understanding of Experimental, I think a one-off feature is fine to include, again with the understanding that it could be omitted from a Proposed Standard version because it isn't widely useful. > > Throwing it in because we were aiming at the "experimental" designation seemed to be the easiest way to resolve the non-progressing discussion when it initially cropped up in August 2017. The topic was permuted from nearest-fail to oldest-pass in January 2018 to make the calculation algorithm and interpretation of the data point a bit clearer but I don't think that anyone has changed their mind much from their positions in August 2017 - unless, as Scott pointed out, the one person who insisted on this has done so silently. I don't think any of my objections to being unable to distinguish between "sealed and didn't modify" and "sealed and modified" cases have changed. Having said that, it's easier to add an additional field than to take something out, so I don't object to simplifying and seeing what happens. Particularly since we're experimental. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --defb108d6b2744d1b6dec136ba8ddc89 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote:
On Mon, Nov= 5, 2018 at 3:13 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Mon, Nov 5, 2018 at 2:= 25 PM Scott Kitterman <sklist= @kitterman.com> wrote:
Having reviewed= the thread that Kurt pointed me to, it seemed like this is
something only one person wanted. = It didn't appear to have a lot of push
behind it.

Based = on my understanding of Experimental, I think a one-off feature is fine t= o include, again with the understanding that it could be omitted from a = Proposed Standard version because it isn't widely useful.

Throwing it in because we were a= iming at the "experimental" designation seemed to be the easiest way to = resolve the non-progressing discussion when it initially cropped up in A= ugust 2017. The topic was permuted from nearest-fail to oldest-pass in J= anuary 2018 to make the calculation algorithm and interpretation of the = data point a bit clearer but I don't think that anyone has changed their= mind much from their positions in August 2017 - unless, as Scott pointe= d out, the one person who insisted on this has done so silently.

<= div style=3D"font-family:Arial;">I don't think any of my objections to b= eing unable to distinguish between "sealed and didn't modify" and "seale= d and modified" cases have changed.

Having said that, it'= s easier to add an additional field than to take something out, so I don= 't object to simplifying and seeing what happens.  Particularly sin= ce we're experimental.

Bron.

--
  Bron Gondwana, CEO, FastMa= il Pty Ltd
  brong@fastmailteam.c= om


--defb108d6b2744d1b6dec136ba8ddc89-- From nobody Tue Nov 6 11:17:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D10130DEF for ; Tue, 6 Nov 2018 11:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA0RcI40qNmx for ; Tue, 6 Nov 2018 11:17:13 -0800 (PST) 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 3F80512F1A5 for ; Tue, 6 Nov 2018 11:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541531830; bh=UapDPr80B7PxJDhj9+t8GxuMNGrf6mPHuMM0X4KFgDc=; l=1061; h=To:References:From:Date:In-Reply-To; b=CvAzK1/aCeMbEzuQv1KwNojtMKymEXhvagHNO6Uj8o3qpSLi26RDkh1up0YDjmtj0 EDkeUfisKXdMoo6nT9esCxHyrOO4ioQ9sL16IyBXoz57gss8BJRfRbKMsOoKr0rDIK iGNNZPXYHz1odvkjZ21+q02wmZ4/7+3zwfIM8E7gjwv7CnVuJ7DbA7TGwLjpH Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 06 Nov 2018 20:17:10 +0100 id 00000000005DC050.000000005BE1E8B6.00001FF7 To: dmarc@ietf.org References: From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Tue, 6 Nov 2018 20:17:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 19:17:16 -0000 On Mon 05/Nov/2018 07:23:08 +0100 Barry Leiba wrote: >> I'd like to recommend that we (DMARC-WG) accept https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 >> into our work queue. It aligns with our charter already. > > I've seen three agreements and no objections, so here's an official > call for objections. If there are none by 16 November, we will create > draft-ietf-dmarc-psd-00 as a new working group item. Can we have a brief discussion on what exactly is the purpose of the I-D? At a first glance, it seems an attempt to override the Public Suffix List with a IANA registry. The PSL is based on IANA root zones, taking into account PSO policies. So, we're requiring PSOs to register their email policies at IANA, while their web policies will continue to be "registered" at PSL. Does that sound somewhat curious or is it me? BTW, I see "v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk", but neither .bank nor .insurance. Best Ale -- From nobody Tue Nov 6 11:39:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08012F1A5 for ; Tue, 6 Nov 2018 11:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kcf9ebl2; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Cs7RVJvm 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 HlNJUQ5Y6AcH for ; Tue, 6 Nov 2018 11:39:20 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A47C124408 for ; Tue, 6 Nov 2018 11:39:20 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541533159; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=UswJWgI3eHsyUb9Dli7i3EcnCZ60HEF6qloJezlkYyk=; b=kcf9ebl2C6M/H2gy+uECVwvXD4FbUBTW+Q/hCESLzNEoZ+7AOnfTyznt bQ3CtUZMX2jpVnr3hwm5nH5l/PL3Cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541533159; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=UswJWgI3eHsyUb9Dli7i3EcnCZ60HEF6qloJezlkYyk=; b=Cs7RVJvmtT6OivzO/lKRide1YRE+dm1laByx9zEjx3w1mRbIkq7rUueR 82M2PpEFJmf8vWq77KMcvGSSxyq+vMp/W7FOewE/lHA0eCHR4WDUYJUXZ6 RY3KBDarbHVqTyV9dgVAneSeu3LzeML2KISVX8hE7pjlPgzBqAOkJeqZf4 548FEQWFMO7488yfSWhXVRXtjo05sqCl/k4+aIc8wYe7boyB4ZwVZ0mfyB 8Om3Dbls5I/iwHW4HUl4I0vgn24eqDvvefB8Pl6JvUTJcAYXyfmzHIaHrz CFGPq3LVgaDzHfTyPUfXl2A3Vdq0NPJgLnNC3SqlZkoRU0oBbW6SJA== Received: from [10.190.55.0] (mobile-166-170-28-229.mycingular.net [166.170.28.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 12BA1C400ED; Tue, 6 Nov 2018 13:39:18 -0600 (CST) Date: Tue, 06 Nov 2018 19:39:14 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 19:39:23 -0000 On November 6, 2018 7:17:10 PM UTC, Alessandro Vesely w= rote: >On Mon 05/Nov/2018 07:23:08 +0100 Barry Leiba wrote: > >>> I'd like to recommend that we (DMARC-WG) accept >https://tools=2Eietf=2Eorg/html/draft-kitterman-dmarc-psd-00 >>> into our work queue=2E It aligns with our charter already=2E >>=20 >> I've seen three agreements and no objections, so here's an official >> call for objections=2E If there are none by 16 November, we will >create >> draft-ietf-dmarc-psd-00 as a new working group item=2E > > >Can we have a brief discussion on what exactly is the purpose of the >I-D? > >At a first glance, it seems an attempt to override the Public Suffix >List with >a IANA registry=2E The PSL is based on IANA root zones, taking into >account PSO >policies=2E So, we're requiring PSOs to register their email policies at >IANA, >while their web policies will continue to be "registered" at PSL=2E Does >that >sound somewhat curious or is it me? Only in a very limited sense=2E DMARC currently stops at the organization= al domain=2E This sets up processing and structure for the limited cases w= here DMARC 'above' the organizational domain makes sense=2E =20 To pick one notional example (real domains, but not reflective of any know= ledge of domain owner plans or policies): Why shouldn't Google be able to assert DMARC policy over subdomains of =2E= google the same way it does over =2Egoogle=2Ecom? Currently they can't and= this draft provides policy and mechanism for them to do so if they want=2E Does that clarify it for you? Scott K From nobody Tue Nov 6 14:03:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D834127332 for ; Tue, 6 Nov 2018 14:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ftld.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVkTKv_61zhN for ; Tue, 6 Nov 2018 14:03:06 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 006EE126CC7 for ; Tue, 6 Nov 2018 14:03:05 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id n21so1909521qtl.6 for ; Tue, 06 Nov 2018 14:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=wMMXOq49dyI7OZO/mJYnGgI5+RXzVcFt1kU3kepLQGo=; b=BuR6yV6vhs42XyTj0/wpKdEDoIybV39T7x08TQb2Cu073BlySPuwZIePQMrHWLEM/4 1r6ynshipNqg9H7vYhpnhp0WkSTwvJHUxfeYFBeIamnLTFgjdpK83dyzWI4OkMsnFzBw PhmstH7MEYBDBroh6Fz9OV2E2O3AVzKqoLRg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=wMMXOq49dyI7OZO/mJYnGgI5+RXzVcFt1kU3kepLQGo=; b=U9+IKThSSAo/YGKHBrFZrhZEjjHiH0jI+s+3ImMkUwmfNsWP5axtfd2gwoTAYCNDb0 itYfMKGvhtvO1ZF8mGQ8TGWzmFXcDGg7agIE/JCz/vm9quizXO8q9JmogA/gYhz1JgGK yxNiD9QCZj2BYLpwyE9dUbRK7Ggx2VeVVuZIJZPc3aXkW0Wx/z9GT/9k2E6ETM0GKwll gEp7pVfKRlsEfaY5gd5M7Ki0SwD8ivZEYO229jL0lL9nQfyADDnYEY0Y4naCruCxS+ZZ 7VWLxTYYNVGvZsLstgUWiUzBN8KhBL43ORTKYKIC98zXk1697sFKlNtLkJZkjDWwmVD2 TCUQ== X-Gm-Message-State: AGRZ1gJhpbBV2xiCpA0qG1BcdFsX34c40JEl8nXCvNpTjnKL8LpgBYtS getVcoy9XJESI34bFnrkjVftb/EY6xI= X-Google-Smtp-Source: AJdET5fE9GVWNs8jrD+ISa/eV53wDIy/FOJi/gsK5E0uVDTbojrBPb0oWHhagr3R90SuNK1PYt0DGQ== X-Received: by 2002:ac8:2a26:: with SMTP id k35mr7413590qtk.245.1541541784182; Tue, 06 Nov 2018 14:03:04 -0800 (PST) Received: from CSCHWARSP4102 (66-44-112-22.s21.c3-0.grg-cbr1.lnh-grg.md.cable.rcncustomer.com. [66.44.112.22]) by smtp.googlemail.com with ESMTPSA id v5-v6sm24682986qkc.75.2018.11.06.14.03.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 14:03:03 -0800 (PST) From: Craig Schwartz X-Google-Original-From: "Craig Schwartz" To: "'Alessandro Vesely'" , References: In-Reply-To: Date: Tue, 6 Nov 2018 17:03:01 -0500 Message-ID: <00b401d4761c$7cfec420$76fc4c60$@ftld.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLkDRPTIxC10FcK+f4Vyd705D0f0gIR+1GOA4QaK0Gi92x9sA== Content-Language: en-us Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 22:03:09 -0000 >>BTW, I see "v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-rua@dmarc.se rvice.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk", but neither .bank nor .insurance.<< The reason for this is that gov.uk is effectively a second-level domain name and its administrator has a DMARC policy. DMARC at the top-level (e.g., .BANK, .INSURANCE) doesn't currently exist hence the rationale for the proposed work. Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE -----Original Message----- From: dmarc On Behalf Of Alessandro Vesely Sent: Tuesday, November 6, 2018 2:17 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items On Mon 05/Nov/2018 07:23:08 +0100 Barry Leiba wrote: >> I'd like to recommend that we (DMARC-WG) accept >> https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 >> into our work queue. It aligns with our charter already. > > I've seen three agreements and no objections, so here's an official > call for objections. If there are none by 16 November, we will create > draft-ietf-dmarc-psd-00 as a new working group item. Can we have a brief discussion on what exactly is the purpose of the I-D? At a first glance, it seems an attempt to override the Public Suffix List with a IANA registry. The PSL is based on IANA root zones, taking into account PSO policies. So, we're requiring PSOs to register their email policies at IANA, while their web policies will continue to be "registered" at PSL. Does that sound somewhat curious or is it me? BTW, I see "v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-rua@dmarc.se rvice.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk", but neither .bank nor .insurance. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Nov 6 16:21:46 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE9126CB6 for ; Tue, 6 Nov 2018 16:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQjvTAcvPFzP for ; Tue, 6 Nov 2018 16:21:42 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 5EFD1124C04 for ; Tue, 6 Nov 2018 16:21:42 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id n18so10229032lfh.6 for ; Tue, 06 Nov 2018 16:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=afUkTQ5UU3vy2ZXB+KLHhnPwhczn2hYXjcyV4xVgu9A=; b=X7mAFr7zuDFH7/a3lx1fothfx7UXE0tye0Xt7r33st2UG5orCPapTOv1ZSMCOElThT ShghMRkpP+BIJT7I1wjuPWvi1ALK7V1+3pJlcKm2s8PdMVcVmxmOvRFvB2nVcGWu0aPc lkQoemQaTwqshP1oTX2Hzlv7EjA0rc3V+lgiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=afUkTQ5UU3vy2ZXB+KLHhnPwhczn2hYXjcyV4xVgu9A=; b=gsxFY5R7emamgXv+/+C9iWdqE7fzRky4E6wYbgii2Xxg1f+x8xGzlJpZG+viXjxT2S l90nTr1K09a3wnZYsrtktikIkQLPbJWiM0pWV6yGoHOn56/zSSfqW/jHP5ObMOak03xa K8R5iK6iJI1OUh4xPmLAA3tK/kKGtfG3a+4vjbbYcFK3zpYV8WTNmQDespVxgWG/ALhv h6+xtrnZLVhMzgeRMm7WNsLRNQZJDv5zQtzFUMsbhkpyN0Z65h4E213JajoyRYSlqQsk ztToEz1xLgkcnze4ZL8hA+hy+RtssujTQ0fYR+OVQiY7JvEbIhtEpD5cPPUqdac3il1E lBYg== X-Gm-Message-State: AGRZ1gLbtK8XF9e4MiZX/dAMqIZ2/pkPjhsD/+nhS8JGOwCKBVetXdHe rzhTGq7GqD1jwDZj1Ez7lyeBGp4jciMEBWgoy+SjT33giJRWug== X-Google-Smtp-Source: AJdET5f/PMa+H84NnT2o9luIj+3fJABgUK+CLR3GNZrmc/8uJdodO+1F1dsL8w020Se0vxStuYuRTV69OXSmLAs5rjU= X-Received: by 2002:a19:cec8:: with SMTP id e191mr16192756lfg.13.1541550100276; Tue, 06 Nov 2018 16:21:40 -0800 (PST) MIME-Version: 1.0 References: <154030726741.31325.18068939197691810125.idtracker@ietfa.amsl.com> <4082068.TRYGpCgONJ@kitterma-e6430> <753be398-badd-4089-be3a-1fb027e98567@sloti7d1t02> In-Reply-To: <753be398-badd-4089-be3a-1fb027e98567@sloti7d1t02> From: "Kurt Andersen (b)" Date: Wed, 7 Nov 2018 07:21:26 +0700 Message-ID: To: Bron Gondwana Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000218894057a081a1f" Archived-At: Subject: Re: [dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: ...) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 00:21:45 -0000 --000000000000218894057a081a1f Content-Type: text/plain; charset="UTF-8" On Tue, Nov 6, 2018 at 4:52 PM Bron Gondwana wrote: > On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote: > > Throwing it in because we were aiming at the "experimental" designation > seemed to be the easiest way to resolve the non-progressing discussion when > it initially cropped up in August 2017. The topic was permuted from > nearest-fail to oldest-pass in January 2018 to make the calculation > algorithm and interpretation of the data point a bit clearer but I don't > think that anyone has changed their mind much from their positions in > August 2017 - unless, as Scott pointed out, the one person who insisted on > this has done so silently. > > I don't think any of my objections to being unable to distinguish between > "sealed and didn't modify" and "sealed and modified" cases have changed. > > Having said that, it's easier to add an additional field than to take > something out, so I don't object to simplifying and seeing what happens. > Particularly since we're experimental. > Since we are now pretty much through even the IESG last call period, I'm loathe to make any changes without a groundswell of assent across the entire group. Please take a look at the new Appendix B ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-20#appendix-B) which was mocked out with Mail::DKIM. There are traces of where changes happened in the AAR from the ARC chain validation - the motive A-R headers were manually created by me and did not include the newer pieces since the system that generated the A-R did not have access to the info. It's not quite as easy to parse, but the info is there. --Kurt --000000000000218894057a081a1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6, 2018 at 4:52 PM Bron Gondwana <brong@fastmailteam.com> wrote:
On Mon, Nov 5, 2018, at 20:29, Kurt Andersen (b) wrote:
Throwing it in because we were aiming at the "experimen= tal" designation seemed to be the easiest way to resolve the non-progr= essing discussion when it initially cropped up in August 2017. The topic wa= s permuted from nearest-fail to oldest-pass in January 2018 to make the cal= culation algorithm and interpretation of the data point a bit clearer but I= don't think that anyone has changed their mind much from their positio= ns in August 2017 - unless, as Scott pointed out, the one person who insist= ed on this has done so silently.
I don't think any of my objections to being unab= le to distinguish between "sealed and didn't modify" and &quo= t;sealed and modified" cases have changed.

Having said that,= it's easier to add an additional field than to take something out, so = I don't object to simplifying and seeing what happens.=C2=A0 Particular= ly since we're experimental.

Since we are now pretty much through even the IESG last call period, I= 9;m loathe to make any changes without a groundswell of assent across the e= ntire group.=C2=A0

Please take a look at the new A= ppendix B (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protoc= ol-20#appendix-B) which was mocked out with Mail::DKIM. There are trace= s of where changes happened in the AAR from the ARC chain validation - the = motive A-R headers were manually created by me and did not include the newe= r pieces since the system that generated the A-R did not have access to the= info. It's not quite as easy to parse, but the info is there.

--Kurt=C2=A0
--000000000000218894057a081a1f-- From nobody Tue Nov 6 18:33:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415B9128CE4 for ; Tue, 6 Nov 2018 18:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfYWVV5vkquS for ; Tue, 6 Nov 2018 18:33:44 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 EAEEB126CB6 for ; Tue, 6 Nov 2018 18:33:43 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id p86so10407656lfg.5 for ; Tue, 06 Nov 2018 18:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XM/mzvSBwGfSobA/Fru9geWGRCp1ZiJG+Io6bFpnZ1Y=; b=ahY1olJtfMY6Lb72H5GWiZ2GNsMF+OD7PeVtjf8Qu/sNSJhm/lxq40VAACfuCrOmCQ juxsqkwBw+NU4DVpHMgL0J6+jQc/P2sTw09pVLA5+xSZav3eqwivA33+YwL3ZTim3Etp a2yoC3hCLXu1N7c56coJUTorlns3zuenwkVfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XM/mzvSBwGfSobA/Fru9geWGRCp1ZiJG+Io6bFpnZ1Y=; b=OmxDIT9YEDDNRbu/xmL7q4PXs555NnsJx9wCGgDLZ39vwdVO71+6I3JokTbHF/PP6S WmfJJQEUJcwCGvSgQkCUibIGf8FCZm/cm0Jg+DvaMNo1p0ChQPNXkf6lfp3+wVfbSsIF tCc7F3kpsbXm+7vhgh+oGwAqSm4WVd+r3dqDA04gvnjsMZK387jVyAuGzOziSlzANfr/ i/8C9QL01QcaN9IM/vLvifVeSdm1N5TUkNVXSMtJVN1jR8NocJmvn8rjhdqD2enswfTi GO9j1UFqNjvIqMhfqftayB/0ofY0FNeUwuGpPwsTbzKoCSSVupnL/IwUX+VwuYooQOPF KENQ== X-Gm-Message-State: AGRZ1gJ+O2Lq6m6NDhK9oIhjYZclqbNnovuMeMcMt0+GC/jN/HnVfj6d Wu1rgFyfdAqS0sfpU7Glrk/Pc1Rq8lwktE6BO2bwV7vtTtE= X-Google-Smtp-Source: AJdET5dJMIOjsuRqik+DshrzQNDAu+uc8tjAarnqBDKwYRagyiqPCGg9SaX5E06zrwGpYMDUVq2Yel6LKc0gi9NKZqQ= X-Received: by 2002:ac2:4116:: with SMTP id b22mr28489lfi.19.1541558021848; Tue, 06 Nov 2018 18:33:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 7 Nov 2018 09:33:28 +0700 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b14df057a09f219" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 02:33:46 -0000 --0000000000004b14df057a09f219 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 2:17 AM Alessandro Vesely wrote: > > Can we have a brief discussion on what exactly is the purpose of the I-D? > The intent is to allow the expression of a DMARC policy which would cover non-existent org domains under a "longest public suffix". Right now, there is no way to do that. > At a first glance, it seems an attempt to override the Public Suffix List > with > a IANA registry. > The IANA registry listing is to constrain which LPSs are exerting such claims and to prevent abuse such as happened a few years ago on web wildcards. --Kurt --0000000000004b14df057a09f219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7,= 2018 at 2:17 AM Alessandro Vesely <ve= sely@tana.it> wrote:

Can we have a brief discussion on what exactly is the purpose of the I-D?

The intent is to allow the expression of= a DMARC policy which would cover non-existent org domains under a "lo= ngest public suffix". Right now, there is no way to do that.
=C2=A0
At a first glance, it seems an = attempt to override the Public Suffix List with
a IANA registry.=C2=A0=C2=A0

The IANA r= egistry listing is to constrain which LPSs are exerting such claims and to = prevent abuse such as happened a few years ago on web wildcards.
=
--Kurt
--0000000000004b14df057a09f219-- From nobody Tue Nov 6 19:09:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7B7127332 for ; Tue, 6 Nov 2018 19:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WJMxMVX2xxB for ; Tue, 6 Nov 2018 19:09:05 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 BF27C128CE4 for ; Tue, 6 Nov 2018 19:09:04 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id q6-v6so10419462lfh.9 for ; Tue, 06 Nov 2018 19:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5mM9ihOzNfq68R+OlLV9TVXRZrHYX6QXK/Vp36oUuE=; b=HCXdq5/5ga+cSnM1xvY0FGk+n1oHsc4AhKdY7iAKiEWDoDbN4wV/dzYVG2GAoTSZTL ADRRPu7rBV6VwoDWn0SGTeujyv31QcyxD6P96xjJO4WLUNi/R1va/vhwbY6zzKxIbISG CNxJgnlBh/Sply8CFoPnysGkyCs78z8DoBHYBOwAgIqRSZWkHoMjCznpj9b6RyceEWqa 5IIoK6VltA9X1vvUIYYP0FsTjQaJz1oWHb4KzKYhz0c9RM7pRTVrXNnniGhcgC7ygUOD L0iUf2X/iS3+AOgOqJwE8+E3cfJ120U/c1rP93kKTVEdMBaDX0CJ5u8Yi1slH0UkaA2I djUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5mM9ihOzNfq68R+OlLV9TVXRZrHYX6QXK/Vp36oUuE=; b=MO3jEQeq9jtjwHHIwZHInHtG7a6bXxO3g4PmfboKd5rgfA8vRlaUmppIPshbWWG9l0 ccG5i2vBnZxVJ9blPq5s3z5HC0lh5w91O7xDPYajm09FeKbtbtz/ydBmjIh2NS5UxKl0 gG6HHoiAz9FT7aaAv0OjiSIH9+LNQUwKcztDvzbYy33/qh1aOgNDDITUu69mMQowCtUl pUclc09M+vyrJiuwyoPl0FumLDlchiXhf4sOXUpYnSejUsJXuCG0IUyFm02LehUlBONs yDo2zhtEbXkkyggNCj0o/yV9vFewrh9Kv9v0xyuZXTOr4dT4jGQ5gIBJA39SR5Jxabbe lUBQ== X-Gm-Message-State: AGRZ1gI34nBUflhBWtiZKVoBrM2+l4xZTXnuiTYHCI3t2S2A/ZrJJs6i iyAUOC3K3GkllovqHf7jdAtq4VXwE5CkPdb89W4= X-Google-Smtp-Source: AJdET5c94iTpV+UH4WiFpb1O1V1geDSji7OhWrt8ETatxlUKL8OCxlLZ81utmIqGeZMGXxnNOCM2pEuD4lv59IO44+g= X-Received: by 2002:a19:d9d6:: with SMTP id s83mr67840lfi.57.1541560142781; Tue, 06 Nov 2018 19:09:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 7 Nov 2018 10:08:50 +0700 Message-ID: To: "" Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b5e45b057a0a70c4" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 03:09:07 -0000 --000000000000b5e45b057a0a70c4 Content-Type: text/plain; charset="UTF-8" My concern with this approach (which doesn't rise to the level of objecting to its application as a WG document, though perhaps it should) is that it is trending toward needing an IANA registry to be queryable in real-time, and I don't believe they are equipped with the infrastructure to provide that kind of service, nor is that likely to happen anytime soon. -MSK On Wed, Nov 7, 2018 at 9:33 AM Kurt Andersen (b) wrote: > On Wed, Nov 7, 2018 at 2:17 AM Alessandro Vesely wrote: > >> >> Can we have a brief discussion on what exactly is the purpose of the I-D? >> > > The intent is to allow the expression of a DMARC policy which would cover > non-existent org domains under a "longest public suffix". Right now, there > is no way to do that. > > >> At a first glance, it seems an attempt to override the Public Suffix List >> with >> a IANA registry. >> > > The IANA registry listing is to constrain which LPSs are exerting such > claims and to prevent abuse such as happened a few years ago on web > wildcards. > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b5e45b057a0a70c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My concern with this approach (which doesn't rise= to the level of objecting to its application as a WG document, though perh= aps it should) is that it is trending toward needing an IANA registry to be= queryable in real-time, and I don't believe they are equipped with the= infrastructure to provide that kind of service, nor is that likely to happ= en anytime soon.

-MSK

On Wed, Nov 7, 2018 at 9:33 AM Kurt Ande= rsen (b) <kboth@drkurt.com> w= rote:
On Wed, Nov 7, 2018 at 2:17 AM Alessandro= Vesely <vesely@tana= .it> wrote:

Can we have a brief discussion on what exactly is the purpose of the I-D?

The intent is to allow the expression of= a DMARC policy which would cover non-existent org domains under a "lo= ngest public suffix". Right now, there is no way to do that.
=C2=A0
At a first glance, it seems an = attempt to override the Public Suffix List with
a IANA registry.=C2=A0=C2=A0

The IANA r= egistry listing is to constrain which LPSs are exerting such claims and to = prevent abuse such as happened a few years ago on web wildcards.
=
--Kurt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b5e45b057a0a70c4-- From nobody Tue Nov 6 20:37:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4F1277D2 for ; Tue, 6 Nov 2018 20:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB38V65PZZYF for ; Tue, 6 Nov 2018 20:37:39 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 8F955127148 for ; Tue, 6 Nov 2018 20:37:38 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id v15-v6so4921805ljh.13 for ; Tue, 06 Nov 2018 20:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RiG35K/16dKjW59i8lEQpoSqZ4l3tpQ91WUgykdHQj4=; b=VsF8lukCRSZwCGBpCWysg+RNX+REIdOMQ6auLR1SwNdipwgMJaEGLgA6dJyJmrvJ6k dttY/o+2SnwrmBmx7KYuBNAJtzmIh21b2UhZXTiDuPwZrN5tbqb2HFqFD6rCDObDsvaj BNLplf/Yx3u44bzSoX4N+y3vD9c6ecbN9QJcmtzwMOwk8Hd+lx4ClkDfcpg0XxA1qatG VUHanIXj6ziNneMpj6KAWSELjYqxGMqwZ8d9eJ7OhnRBPhKhQit3n1nRLrzBOhO50x12 Var3vePPBZMT6+hau5sc+JOfcPlQtFt1pa2i3i3nN8Fb6l92Y4jeu5IOsN4Ss07pN3gU Wn0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RiG35K/16dKjW59i8lEQpoSqZ4l3tpQ91WUgykdHQj4=; b=gmCvyxafJ7G0dZFjd9BqD4l6NKvTsKM8N+VDfYFgWEa5fQeITUoyAObE1Dkc5K8+Oz l9/vr4bGZQkVWwWjQnu1WSpHRU1OvihodgU7kFHZm8Q1ePoc5b8T4SAO3HF9Yq/yP+cK 9LvK9dxrsi8Y409f29ZhXkLTglvn4yXoBicces9KRrheg/VdkHZfKt3iDZyTYhSglC9h cNBnp+O7YmswGLYzMHtTwmxO0BImb/XWCwfVJ2XLBp4fhDNUbcOdcv5I5fh/L9sN+Lgr YAtAeAA2H88Bus4v4+xSxOjTZfI0sVXtwd8OX+MXA0kko0waz6t44Hhh51TCnUue4P3B EdfQ== X-Gm-Message-State: AGRZ1gLvEB80jYE+VNnBHjf3ZQNh1GlHJfbUHSUkHNpt8Oe3TbcsO7ug yBQEzLC3UHCO9tR5UsjA3DyM6aPS9Of4Z0dHnD4= X-Google-Smtp-Source: AJdET5eaRzmSYO7Ipr+r8z4Vyk5W5j1vD3JCazFsszMjee9mkHo0o9o9eqNoV7ucA0EA3xMN3Dzr606IV/S/CITGGtU= X-Received: by 2002:a2e:478f:: with SMTP id u137-v6mr204233lja.142.1541565456418; Tue, 06 Nov 2018 20:37:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 7 Nov 2018 11:37:24 +0700 Message-ID: To: "" Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006d8c6b057a0badf9" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 04:37:41 -0000 --0000000000006d8c6b057a0badf9 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 10:08 AM Murray S. Kucherawy wrote: > My concern with this approach (which doesn't rise to the level of > objecting to its application as a WG document, though perhaps it should) is > that it is trending toward needing an IANA registry to be queryable in > real-time, and I don't believe they are equipped with the infrastructure to > provide that kind of service, nor is that likely to happen anytime soon. > This issue or something like it came up when I was chairing WEIRDS, so that's where this is coming from. There are IANA folks here at IETF this week. I'll ask them. -MSK --0000000000006d8c6b057a0badf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7, 2018 at 10:08 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
=
=
My concern with this approach (which doesn't rise to the level of = objecting to its application as a WG document, though perhaps it should) is= that it is trending toward needing an IANA registry to be queryable in rea= l-time, and I don't believe they are equipped with the infrastructure t= o provide that kind of service, nor is that likely to happen anytime soon.<= /div>

This issue or something like it= came up when I was chairing WEIRDS, so that's where this is coming fro= m.

There are IANA folks here at IETF this week.=C2=A0 I&#= 39;ll ask them.

-MSK
--0000000000006d8c6b057a0badf9-- From nobody Tue Nov 6 20:54:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965AF130F35 for ; Tue, 6 Nov 2018 20:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ba8wXueN; dkim=pass (2048-bit key) header.d=kitterman.com header.b=pNY/wQzQ 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 iYltlbSoSDMh for ; Tue, 6 Nov 2018 20:54:11 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82188130F1E for ; Tue, 6 Nov 2018 20:54:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541566449; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=2pGyfvsmL0hEBOcznqQwhrbNvFXb6FA2JCoHTH3fjfQ=; b=ba8wXueN9fxvwBRQZG/zK/QGTHeRUmBi0JKgsuOpk+WHkiVD09iQyn1w U7i+tL6RchbtL+v+NNvooWPsZi+/CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541566449; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=2pGyfvsmL0hEBOcznqQwhrbNvFXb6FA2JCoHTH3fjfQ=; b=pNY/wQzQx85Ca306AUJ6J5KW9KgtT+1SJKa9VBfQEznuqzCph3WKVG7e aABleca/yMtJ7h116VDx73Z2EZ22vDjsbKN1w4B9e/qsdN2ku6pqtMVgy8 PQETPt7WCqL7UMZBsp6eZph2CLj3Xysp7hs5QeRnAp/roddTfFdluPcnLO 5n63bcqSe2yb4yIKa2IVdNjhHhnTEEyvTNQXAb/TkHT+Hrx46DZyTNrl+C 3wVH9enSFJa+manDmjTA+rI2OZXE4vA54qYFSg51/UAekt+cRflx5usL0w sK+iWzXhTTelr7ydC2j2BfT279nUSbDtFED7i1GOeFjetFox3RS4Yw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C66D7C401DD for ; Tue, 6 Nov 2018 22:54:09 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 06 Nov 2018 23:54:08 -0500 Message-ID: <4226992.SIzckGkbUk@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 04:54:16 -0000 On Wednesday, November 07, 2018 11:37:24 AM Murray S. Kucherawy wrote: > On Wed, Nov 7, 2018 at 10:08 AM Murray S. Kucherawy > > wrote: > > My concern with this approach (which doesn't rise to the level of > > objecting to its application as a WG document, though perhaps it should) > > is > > that it is trending toward needing an IANA registry to be queryable in > > real-time, and I don't believe they are equipped with the infrastructure > > to > > provide that kind of service, nor is that likely to happen anytime soon. > > This issue or something like it came up when I was chairing WEIRDS, so > that's where this is coming from. > > There are IANA folks here at IETF this week. I'll ask them. Thanks, My estimation is that this would change very rarely. If I were developing software for this, I'd probably check at build time and use that unless there are some reason to update. Not that people won't try, but I think not very real time is sufficient. Scott K From nobody Tue Nov 6 23:56:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C667E130ED7 for ; Tue, 6 Nov 2018 23:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBNHC2iEZ2bR for ; Tue, 6 Nov 2018 23:56:29 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 14138130E1C for ; Tue, 6 Nov 2018 23:56:29 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id f3-v6so13897019ljk.9 for ; Tue, 06 Nov 2018 23:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TjUOv5wueoGHtBGnKVd3y5kRETvAeT8pGqe8OzcuMho=; b=AoSGUJOsUCBfz3hidQ5kaq8q43/xo2NZzE60G7Ma+twTTef07ucRWJsDVUGq/1oDjg mhhcV90Hqq0Ne+XDePcEcGBzRiLdEl8ISgisuiYRUK9FLob4DpXQSNLKxOS9LULCTyzu aS9EcKEMQT28m5Kte62TOvJ+ojBESb+GHSafsvWGHWIVLa6F2m2a0WNI+tPaXzhDz3OJ UQMh5S4aLNn7Dgr1lnW3uU2R6m+nFak/5ApmpU/OXmbsy5sF8IrG8zX6JYGPTrNlDY4j 8YwoStecCWb1yVTqXWoV6GhO0MpTaS+TZScPH/MHaN/SYN6bG8St33VEb/wtFls3Xx0A D+IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TjUOv5wueoGHtBGnKVd3y5kRETvAeT8pGqe8OzcuMho=; b=cevUIA2w63+cl6dgPNh4/oNDuMCfOouCGD6gm81LSwlOU9FsoZc94Hd1eGNyywgg4d BOaH8vqQ4+3LqlEs2VsMlSBRtA+mqdkzej52dnDm30cCgigSo9FH2EOEXK3VAmt6GafK iYzyIqh9wJ+TAG/eF96TChbCm8ig6gYfo7gYcQxtyOAg6ngBFMB9XtU05fTp9LssPwLo 0PKmM7veINGwM238/kbA0JCefSM2e2H77Pa+x63aSwkbDED292nR9BUeOoNNdJLoASFy Bew+xLywhg9TAfjsKpqknbMOLWIryR++ofCBaDDXamQK8/t1BRkC2NVYJOB16VvxoBR2 m6VA== X-Gm-Message-State: AGRZ1gI/HS078K+cW7/zyGZDT0keecbypC5ADSYJ8Unvv1DuhQTkwrJJ UB4XpKabBGLLqT7Sp+KvFTI3W4VRCaAKB/wHTcLNS6DL X-Google-Smtp-Source: AJdET5e1pcRMS9TZgzRq8yoFLgsFQ7vmnp8ZVRqU4NLZyOx6FydlDXCWHKxG80HVc+7vp698C9i6YKHp9oFSiDxFAec= X-Received: by 2002:a2e:b00a:: with SMTP id y10-v6mr529008ljk.109.1541577387189; Tue, 06 Nov 2018 23:56:27 -0800 (PST) MIME-Version: 1.0 References: <4226992.SIzckGkbUk@kitterma-e6430> In-Reply-To: <4226992.SIzckGkbUk@kitterma-e6430> From: "Murray S. Kucherawy" Date: Wed, 7 Nov 2018 14:56:14 +0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008eb092057a0e7448" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 07:56:36 -0000 --0000000000008eb092057a0e7448 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 11:54 AM Scott Kitterman wrote: > My estimation is that this would change very rarely. If I were developing > software for this, I'd probably check at build time and use that unless > there > are some reason to update. Not that people won't try, but I think not > very > real time is sufficient. > Sure, but: (a) You are probably a more reasonable and thoughtful implementer than average; and (b) It only takes one large operator to, through neglect or a desire to ensure up-to-the-minute data, disregard any query rate advice we give and accidentally DoS IANA off the 'net. If IANA doesn't have a highly scalable CDN in front of it, which I doubt, then this is something the IESG would legitimately raise (as they did with WEIRDS) when this goes up for formal review. DBOUND tried to do this inside the DNS, which solves the CDN problem, but it couldn't reach consensus on the preferred approach, and shut down not long ago without producing anything. -MSK --0000000000008eb092057a0e7448 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7, 2018 at 11:54 AM Scott Kitterman <sklist@kitterman.com> wrote:
My estimation is th= at this would change very rarely.=C2=A0 If I were developing
software for this, I'd probably check at build time and use that unless= there
are some reason to update.=C2=A0 Not that people won't try, but I think= not very
real time is sufficient.

Sure, but:
=
(a) You are probably a more reasonable and thoughtful implem= enter than average; and

(b) It only takes one larg= e operator to, through neglect or a desire to ensure up-to-the-minute data,= disregard any query rate advice we give and accidentally DoS IANA off the = 'net.

If IANA doesn't have a highly scalable CDN = in front of it, which I doubt, then this is something the IESG would legiti= mately raise (as they did with WEIRDS) when this goes up for formal review.=

DBOUND tried to do this inside the DNS, which sol= ves the CDN problem, but it couldn't reach consensus on the preferred a= pproach, and shut down not long ago without producing anything.
<= br>
-MSK
--0000000000008eb092057a0e7448-- From nobody Wed Nov 7 00:49:51 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FF212007C; Wed, 7 Nov 2018 00:49:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154158058931.21696.4829292003230855@ietfa.amsl.com> Date: Wed, 07 Nov 2018 00:49:49 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-21.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 08:49:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-21.txt Pages : 39 Date : 2018-11-07 Abstract: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-21 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 7 04:26:04 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA712D4E9 for ; Wed, 7 Nov 2018 04:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=sJrbMwpv; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jobYPn9/ 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 gXMUygohxlxY for ; Wed, 7 Nov 2018 04:26:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A64128CF2 for ; Wed, 7 Nov 2018 04:26:00 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541593557; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=r78c+XZckmGdTQQxve3rp/PbCkZklJHBgizxke/smug=; b=sJrbMwpvw7bcXH0cqqOzQQhGwlMJokv8+3eKz5mdD5PEkAS4T1+Tig+j LVLwGJqbCpfOum4WbOi4DPoL+LKGDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541593557; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=r78c+XZckmGdTQQxve3rp/PbCkZklJHBgizxke/smug=; b=jobYPn9/0d3PgGVL/Le7W3c6a9gxWvkmvVRFNcwv2ixAq8CXE4AgMIT3 C8AR9VaiqGhas65626YQMzHwDyo5T+tWHu/UYkxGVgSBtxRQkFLb6NYn8t ZlLOxobmAN76mFEU46/Rded0Fp0USh+IaceRBVzP9h7k+TTtCeLqOYndiJ gmPfUvDj8Se2ilkfpsLG8hD/LKWdWDaVS0w1rlP19nyiE9/rYcsz95qVpM ekJD4LRyx2NtWW6wkOSCneE1AMuTnmV34iioj70DLyd8IWudkUKVb1+W5o OoTJUOwe+Oj1NImJl27dF8XMmtb59iVR6QnPBfanKGH3EYf/6SpsdA== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 37A5FC400F8; Wed, 7 Nov 2018 06:25:57 -0600 (CST) Date: Wed, 07 Nov 2018 12:25:52 +0000 In-Reply-To: References: <4226992.SIzckGkbUk@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "Murray S. Kucherawy" CC: IETF DMARC WG From: Scott Kitterman Message-ID: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 12:26:03 -0000 On November 7, 2018 7:56:14 AM UTC, "Murray S=2E Kucherawy" wrote: >On Wed, Nov 7, 2018 at 11:54 AM Scott Kitterman >wrote: > >> My estimation is that this would change very rarely=2E If I were >developing >> software for this, I'd probably check at build time and use that >unless >> there >> are some reason to update=2E Not that people won't try, but I think >not >> very >> real time is sufficient=2E >> > >Sure, but: > >(a) You are probably a more reasonable and thoughtful implementer than >average; and > >(b) It only takes one large operator to, through neglect or a desire to >ensure up-to-the-minute data, disregard any query rate advice we give >and >accidentally DoS IANA off the 'net=2E > >If IANA doesn't have a highly scalable CDN in front of it, which I >doubt, >then this is something the IESG would legitimately raise (as they did >with >WEIRDS) when this goes up for formal review=2E > >DBOUND tried to do this inside the DNS, which solves the CDN problem, >but >it couldn't reach consensus on the preferred approach, and shut down >not >long ago without producing anything=2E Unfortunately, I didn't come up with an idea for how to do this in DNS=2E = This seems like a legitimate issue for the WG to work through=2E There are lots of ways to do denial of service attack protection without a= CDN=2E I would hope it's not so trivial to bounce IANA off the net=2E =20 Scott K From nobody Wed Nov 7 04:43:05 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340612EB11 for ; Wed, 7 Nov 2018 04:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9euViKtC7KHG for ; Wed, 7 Nov 2018 04:43:01 -0800 (PST) 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 A36821274D0 for ; Wed, 7 Nov 2018 04:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541594580; bh=DQXCvDClgMt7r8y2RAJqQsh4RtxltIju9LIzu8f48w0=; l=1357; h=To:References:From:Date:In-Reply-To; b=Ag4dBmxwpIiMyFye+iK5I22/M6Pixo/seeu+jC2Ctr/J6YeNdXSITPUXb4uJdrKJP HxlKMJ1Yf11gpEggR6YEV4VNrHqAfmqWSD3WkEML59OZuM5PGCEPxshp2IArj3kJ8y lvXcXu2DQGuOPJaazqAFFG5SBgZDvmW2gwOQvbM2eMfbKNaDwvrMTg8tP+vGd Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 07 Nov 2018 13:42:59 +0100 id 00000000005DC033.000000005BE2DDD3.000010D2 To: dmarc@ietf.org References: <154100859354.5360.795312478907721541@ietfa.amsl.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <1ee67064-9d9a-5edb-c07c-eaa587e8fcea@tana.it> Date: Wed, 7 Nov 2018 13:42:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 12:43:04 -0000 On Mon 05/Nov/2018 05:04:04 +0100 Murray S. Kucherawy wrote: >> 7.3. Header Field Position >>>> This section explains that headers fields are *not* guaranteed to be >>>> in a specific order. The section then states that "there will be >>>> *some* indication...">>>> >>>> Since the order is not guaranteed, what do you expect an implementer >>>> to take away from this?>>>> >>> "in the general case" and "but most do not". >>> >>> So: Most of the time, you can rely on header field ordering to determine >>> the sequence of handling. You are at least certain about whether you can >>> trust the tail end of that, because you know your own environment from the >>> ingress point. >>> >>> >> Fair enough; I think it is worth adding this sentence to make it clear. >> > Doesn't the last sentence of that paragraph already say exactly that? I think Rifaat means, literally: OLD Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here. NEW Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here, because operators know their own environment from the ingress point. That doesn't seem to be a bad change to me. Best Ale From nobody Wed Nov 7 05:42:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444C12D4EA for ; Wed, 7 Nov 2018 05:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Br0ZKZzTGh for ; Wed, 7 Nov 2018 05:42:44 -0800 (PST) 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 5ABBE1274D0 for ; Wed, 7 Nov 2018 05:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541598162; bh=ppLofrSjKN8r0nt6+D4K91qQkwQ8q3+xkZD7sekj9oQ=; l=2126; h=To:References:From:Date:In-Reply-To; b=A5I9HSkZdHexiefwkaFD4t2D5CwqUn3J0VT1LTYTcTdS2MUjuCOYdyGCsbkfcXv9z fYQ/5EkYQQ6Hh71ckDvh364DVjO36hWvfeI2FOHrEHbbKYybYU1s2/EER2nxlO7qaw J5vq0gtSLhwS5gMs2Kuur6/i4b8vMCz5cGtz7KuFBBShQNu4Mo8DC2ebYIkrQ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 07 Nov 2018 14:42:42 +0100 id 00000000005DC033.000000005BE2EBD2.000016D0 To: dmarc@ietf.org References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> Date: Wed, 7 Nov 2018 14:42:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 13:42:46 -0000 On Tue 06/Nov/2018 20:39:14 +0100 Scott Kitterman wrote: > On November 6, 2018 7:17:10 PM UTC, Alessandro Vesely wrote: >> >> At a first glance, it seems an attempt to override the Public Suffix List >> with a IANA registry. The PSL is based on IANA root zones, taking into >> account PSO policies. So, we're requiring PSOs to register their email >> policies at IANA, while their web policies will continue to be >> "registered" at PSL. Does that sound somewhat curious or is it me?> > Only in a very limited sense. DMARC currently stops at the organizational > domain. This sets up processing and structure for the limited cases where > DMARC 'above' the organizational domain makes sense. I appreciate DMARC's concept of "Organizational domain", which is central for alignment (and reputation tracking, although the latter is unspecified). This is Section 3.2 of rfc7489, where the Public Suffix List is introduced. However, I'm not clear what security concerns, if any, are implied in Section 6.6.3. For the web case —the Storage Model of rfc6265— the PSL is necessary to avoid session fixation attacks. Rfc7849 is rather worried by the opposite concern, _sub_domains which send evil mail in order to disrupt the reputation of a parent domain (Section 10.4). How can a parent domain attack a subdomain using an evil policy? > To pick one notional example (real domains, but not reflective of any > knowledge of domain owner plans or policies):> > Why shouldn't Google be able to assert DMARC policy over subdomains of > .google the same way it does over .google.com? Currently they can't and > this draft provides policy and mechanism for them to do so if they want. And what's wrong if Verisign publish a _dmarc.com record? Section 6.6.3 of DMARC is meant to avoid too many DNS queries or are there security issues to worry about? Which ones? > Does that clarify it for you? Only in part. If the I-D must involve a IANA registry, I'm opposed. If the intent is to refine policy discovery algorithms otherwise, possibly in general, then I'm wholly in favor. Best Ale From nobody Wed Nov 7 06:42:16 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D143E130DDF for ; Wed, 7 Nov 2018 06:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kQCcxTXT; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Alc0Ogpy 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 5LxdJU3gmUGO for ; Wed, 7 Nov 2018 06:42:11 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84688130DD6 for ; Wed, 7 Nov 2018 06:42:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541601729; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=JzrWEhbiLSLtXToglCzcUem92uwGTIhqc6SEwTqxtyE=; b=kQCcxTXTMBNfrAFesHe12WmhVO1IpG+/eTxsXs/HcHX6PmOy85sfAZEc guR9dbyGcQ+jeVbC4SnSZsshCtzqAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541601729; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=JzrWEhbiLSLtXToglCzcUem92uwGTIhqc6SEwTqxtyE=; b=Alc0Ogpyjx6jaIrn/sIjkdpDcFINLz1VjBJ1e9IAJZLPwdfQ3bMcrGrg iskqGU8u0a4T7hLLUbogNPvVCHdMgCRGT4KYSuLv19N7+HCb5RRoZ72Zew asmP0kIufKUKDUwiv3N5X/FC/+g2OSvq8cKnfZF3fHDptulZVJynFRGDDH CVYAqAzK1IgNgQole282CDZZkKgt4pWsdvT3VtuT1g/TJ//VvEgTHCa+bi s6OYLVDf9VbYPF64/r8oJlXGOYgl6Dl7JPcNpA9vCRpTerYzrPtAMdCc69 a3IboYP8hrKC8oIQDcipJDEerdzZaXiKgtQwNlsPLrzmFrFQeIiHbQ== Received: from [10.75.181.187] (mobile-166-170-32-1.mycingular.net [166.170.32.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4DBCCC400F8; Wed, 7 Nov 2018 08:42:09 -0600 (CST) Date: Wed, 07 Nov 2018 14:41:25 +0000 In-Reply-To: <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org,Alessandro Vesely From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2018 14:42:14 -0000 On November 7, 2018 1:42:42 PM UTC, Alessandro Vesely w= rote: >On Tue 06/Nov/2018 20:39:14 +0100 Scott Kitterman wrote: >> On November 6, 2018 7:17:10 PM UTC, Alessandro Vesely wrote: >>> >>> At a first glance, it seems an attempt to override the Public Suffix >List >>> with a IANA registry=2E The PSL is based on IANA root zones, taking >into=20 >>> account PSO policies=2E So, we're requiring PSOs to register their >email >>> policies at IANA, while their web policies will continue to be >>> "registered" at PSL=2E Does that sound somewhat curious or is it me?> >> Only in a very limited sense=2E DMARC currently stops at the >organizational >> domain=2E This sets up processing and structure for the limited cases >where >> DMARC 'above' the organizational domain makes sense=2E >I appreciate DMARC's concept of "Organizational domain", which is >central for >alignment (and reputation tracking, although the latter is >unspecified)=2E This >is Section 3=2E2 of rfc7489, where the Public Suffix List is introduced= =2E > >However, I'm not clear what security concerns, if any, are implied in >Section >6=2E6=2E3=2E For the web case =E2=80=94the Storage Model of rfc6265=E2= =80=94 the PSL is >necessary to >avoid session fixation attacks=2E Rfc7849 is rather worried by the >opposite >concern, _sub_domains which send evil mail in order to disrupt the >reputation >of a parent domain (Section 10=2E4)=2E How can a parent domain attack a >subdomain >using an evil policy? > > >> To pick one notional example (real domains, but not reflective of any >> knowledge of domain owner plans or policies):> >> Why shouldn't Google be able to assert DMARC policy over subdomains >of >> =2Egoogle the same way it does over =2Egoogle=2Ecom? Currently they ca= n't >and >> this draft provides policy and mechanism for them to do so if they >want=2E > > >And what's wrong if Verisign publish a _dmarc=2Ecom record? Section >6=2E6=2E3 of >DMARC is meant to avoid too many DNS queries or are there security >issues to >worry about? Which ones? > > >> Does that clarify it for you? > >Only in part=2E If the I-D must involve a IANA registry, I'm opposed=2E= =20 >If the >intent is to refine policy discovery algorithms otherwise, possibly in >general, >then I'm wholly in favor=2E > The registry is meant to be a solution to the 'what about =2Ecom' problem = you mention=2E It's a solution, not necessarily the best or only one=2E I'd suggest we adopt the draft/work item and then try to figure it out=2E Scott K From nobody Wed Nov 7 16:23:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90400130E3F for ; Wed, 7 Nov 2018 16:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIrHeJwP1apo for ; Wed, 7 Nov 2018 16:23:27 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41780130E2E for ; Wed, 7 Nov 2018 16:23:27 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id q186-v6so16418365ljb.5 for ; Wed, 07 Nov 2018 16:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NX9ktFAZBMWgdg3ZTFDMz8ZYXLuoibVKndpPqffB1RE=; b=dm5+sqoWBMluYAFabbghLXaYyQC0yBwNEKqUC70sp9Y8IlCp6fJOQ76yl5MSd/Kutq sUY88j6COwwSwqncPqtt/2gKnr+SQQd4ZrHxCWbxcsw+V3hQNKEEueTN/Ego5YU/MB88 7DYfKCeOCLA6mum2/EbWdQqNpqmyoWgm94Wmc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NX9ktFAZBMWgdg3ZTFDMz8ZYXLuoibVKndpPqffB1RE=; b=CR5RNKfqov07yiU25fnu2sYz+oLn5Vqv4dCGiGzEh6zWazlf8rKT82ewgbC1+6zmko /+qEvOAg99e3y2h8q57hV9l+a+pvFEp7PmpuLPOcbKbwqvFuD/F/J61K0B8F0MF6FA6+ 9taXRsp4kbIEk+FwumHjUND+3AiVXSOx7/2tJmedqYEjRiG0SqtvjeNZJLl82FmIGrj8 vh45iNkWtm77EvWUPbBDTFEf4BpDaC6gbygy0B2N5C6Kgv7CjctbNxVzZ1282IgjrO7l nL+66Zb6h5oNv/6TalPmcEtJBg8MNtGg17OdP6onItkdx/vIaeFyrQP4dSXKUt95tvJb 5Dcw== X-Gm-Message-State: AGRZ1gIbeM3FMZu5wpGe/y1zFaOsHfmcKwRyIBm4k//KHaIxikPX0Vaq Bk4kKQ86lLHJ0yiihFag6Z57ukIjZUfvN8IOwGBYfQ== X-Google-Smtp-Source: AJdET5d5uFNV3CZsAM2zqzaY8y31YVaS7/HG1ztD1AULLhedrFvZjIKjjJix1RYcWEVrtek3xX7r9g58JSoDJHVEztk= X-Received: by 2002:a2e:50d:: with SMTP id 13-v6mr1426548ljf.85.1541636605193; Wed, 07 Nov 2018 16:23:25 -0800 (PST) MIME-Version: 1.0 References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 8 Nov 2018 07:23:10 +0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" , Alessandro Vesely Content-Type: multipart/alternative; boundary="00000000000039da95057a1c3e00" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 00:23:36 -0000 --00000000000039da95057a1c3e00 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 7, 2018 at 9:42 PM Scott Kitterman wrote: > > The registry is meant to be a solution to the 'what about .com' problem > you mention. It's a solution, not necessarily the best or only one. > > I'd suggest we adopt the draft/work item and then try to figure it out. > +1 - this is a good problem for the WG to wrestle with; and maybe it can solve the "PSL problem" if we can constrain the problem space to just the DMARC issues instead of recreating the DBOUND-solve-for-all morass. --Kurt --00000000000039da95057a1c3e00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 7,= 2018 at 9:42 PM Scott Kitterman <sklist@kitterman.com> wrote:

The registry is meant to be a solution to the 'what about .com' pro= blem you mention.=C2=A0 It's a solution, not necessarily the best or on= ly one.

I'd suggest we adopt the draft/work item and then try to figure it out.=

+1 - this is a good problem for the WG= to wrestle with; and maybe it can solve the "PSL problem" if we = can constrain the problem space to just the DMARC issues instead of recreat= ing the DBOUND-solve-for-all morass.

--Kurt=C2=A0<= /div>
--00000000000039da95057a1c3e00-- From nobody Wed Nov 7 17:00:49 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AAC12D4E7 for ; Wed, 7 Nov 2018 17:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9skrpCuHJEq for ; Wed, 7 Nov 2018 17:00:47 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCDE1286E7 for ; Wed, 7 Nov 2018 17:00:47 -0800 (PST) Received: from [192.168.4.215] ([153.150.250.176]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id wA810bNI021330 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 8 Nov 2018 01:00:46 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com wA810bNI021330 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1541638847; bh=rBaUsGyKwC1cQzGq1V37hkWb3xEZFg+MAXkWpC9vQ04=; h=Subject:To:References:From:Date:In-Reply-To; b=mShOb/hrmEnXsgncapkDa4dn0SXUXgUFqDZbBvzFM7krKMSJSkTDXGa+rUk8u/Enf 2wVDxoYN36tTd488jGVqRiq1VdRdZZB7RGgOxqn6TBb6U8MIIqKbL0sxIOs2MZBZ97 9Skt1mDkUOnhD46gZa8Jtm8AHpaQ+BNv/eh5XWMPcM8KYgdBk3jC0CbUSL4nhs+79q og/xCAEgmhlkMb9OTtN9+/HbaBfAA3CM1Xiop0OjZqpYt6l1sHr8wMh9gWczMmFzTX yAvevslNR2aXi1PyZfCb/r/IdbjBzM+DHT6QbzJjwS+Jy2dQHMPaUecbDav+8536BR BTevxCrROGFmw== X-Authentication-Warning: segv.crash.com: Host [153.150.250.176] claimed to be [192.168.4.215] To: dmarc@ietf.org References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> From: Steven M Jones Message-ID: Date: Thu, 8 Nov 2018 10:00:30 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Thu, 08 Nov 2018 01:00:47 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 01:00:49 -0000 On 11/07/2018 11:41 PM, Scott Kitterman wrote: > I'd suggest we adopt the draft/work item and then try to figure it out. +1. We should see where we can get with this topic. --S. From nobody Wed Nov 7 17:20:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BDF130DD8 for ; Wed, 7 Nov 2018 17:20:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi3qogjS-RY0 for ; Wed, 7 Nov 2018 17:20:13 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 5CCF8130DC2 for ; Wed, 7 Nov 2018 17:20:13 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id w3-v6so8083685pgs.11 for ; Wed, 07 Nov 2018 17:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=9VKnArgV0BqRJLuXcR+6+LXGl87LfJF+5cdqn4quvl0=; b=nZUIHkVMj8vJP9SyBNl0Vk90X6TvcYf9+pUERNAPh9+Bl/h0dZwG1quo5XoM7/fa9l tW10ED+8X3LQoE4lSl0sG96rsZqcIDv1PslVGbWQZrEWkhKF7Cgf+yu4tiICRV31COjm m9AdxkGwuo4d9tHPlgW1jYx2XO94f55/IFlUzkXDQ8NDDGYijJ2vVvEIpTMPsRLgi2Y2 eAH4NzdcCgN8ZqYgGaWq/4bBH3rkKzsD137KcfgQjU7aMCOjt6ozjWfp9rEhZAPJ2GV4 x15cJvTQ1IM+YG559nnVhn1zRXW2FhITpXNgcrOIDRzmouQLcqYiPiey9nsMo+/cNDKa Pk6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=9VKnArgV0BqRJLuXcR+6+LXGl87LfJF+5cdqn4quvl0=; b=NiddWlgjmabK4kftiEA/UXlfd2cS/7PoYhM2QfMKI6iWKxrxdkff+aXcagftLdiub+ KIdufR7B9K0R/Rsc2ftZaeMDhTSowjfQjf82XvmwZOyERPIeuKkSypBx9x3Mw7fhRmD8 Z9ryAqvMC8VhGLrxkMT7TVtGlrdB/xKTLgfNfbcwCDCYXiYDmH5IOKV1To+934/iU2NO WShobtUcUvMu5B3CvMMQNhiULLPrZx21Jb3XeUa+lq2qlMANF0dwm4CHYuaIUCn5DvC1 nWAXWMTDfcHdYLwuRxjthCZLT+LP+It7Zz8ZtgDomRlGVXGKxEiYZ6rh68L7QR35Q8Hz BH5Q== X-Gm-Message-State: AGRZ1gLLr6mFjirIzsawVepkjMg0Ep7vhoM9pKCpTMh0XjqCLg3Qt93S pay9gQUor/L3WBuzxIsoCB5VgtIwfsY= X-Google-Smtp-Source: AJdET5eWaqMzVS02QO0oDPhz2uIUjSCBzWvFg0tc/g0Rk83Bbz0qa/Sj8hh9q68e64kOlpvbqk3LLw== X-Received: by 2002:a63:26c1:: with SMTP id m184mr2031659pgm.367.1541640012663; Wed, 07 Nov 2018 17:20:12 -0800 (PST) Received: from [172.19.248.8] ([38.98.37.141]) by smtp.gmail.com with ESMTPSA id v1-v6sm1932965pfn.94.2018.11.07.17.20.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 17:20:12 -0800 (PST) From: tjw ietf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 8 Nov 2018 10:20:05 +0900 Message-Id: References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> In-Reply-To: To: dmarc@ietf.org X-Mailer: iPhone Mail (16A404) Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 01:20:15 -0000 Total +1 on this.=20 =46rom my high tech gadget > On Nov 8, 2018, at 10:00, Steven M Jones wrote: >=20 >> On 11/07/2018 11:41 PM, Scott Kitterman wrote: >> I'd suggest we adopt the draft/work item and then try to figure it out. >=20 > +1. We should see where we can get with this topic. >=20 > --S. >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Nov 7 22:16:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72A2130E04 for ; Wed, 7 Nov 2018 22:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=L7VS1s+0; dkim=pass (1536-bit key) header.d=taugh.com header.b=cMFCkkqN 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 LAxCeCYiGY_q for ; Wed, 7 Nov 2018 22:16:54 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0699912D4ED for ; Wed, 7 Nov 2018 22:16:53 -0800 (PST) Received: (qmail 40784 invoked from network); 8 Nov 2018 06:16:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9f4e.5be3d4d4.k1811; bh=VQ0by21uwP03iorP7EsbcKo52zKZgQogKTK8LcNfaWQ=; b=L7VS1s+0eQtAZHe4WMCAa5eEufb7jI+BImbMXugLzjgLU1eC3pNQMCidsyu938FaW6UERR4TQI4P/9kDK/w8TOfDzNyB5krhFqFNbKd6ZWbK5b2/M8cFQcCb4bjSMrW84FncqHWpaq/uXV3IrReab35fhLitqUMPqz+D1vb7UBSyZN9VhWauLnz1T1PfTndhBGDrOLceKf2pjC2y1vS+vA/R3wStAkrdvHsUFuaVf7GVrVkgvmfx3/c+RUEkk0wc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9f4e.5be3d4d4.k1811; bh=VQ0by21uwP03iorP7EsbcKo52zKZgQogKTK8LcNfaWQ=; b=cMFCkkqNf/Pf2U+r1JqV2dFVnSPcCrmvdpc13kPTK+zINflM9sUAz/UzY93vw/UvAj225dqcXHwZ3kxDJ7hkxf1upMQoH5ttxoMA9Ii+skn0A1am+3eQiKlgq2ROs5mN+58Cb/qq+L2HI6ktsclyGHkPr6hjgzEeGpGEXm9YffVfZUyj3qET2BtxWihXiHio7L3v9CfkNlV+RO35/jLj5haIDsDfBkT2KqfpUz1NLAv4nt4FoK9nge41POr0d4B3 Received: from dhcp-8071.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 08 Nov 2018 06:16:51 -0000 Received: by dhcp-8071.meeting.ietf.org (Postfix, from userid 501) id 0AF13200829C06; Thu, 8 Nov 2018 13:16:50 +0700 (+07) Date: 8 Nov 2018 13:16:50 +0700 Message-Id: <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:16:56 -0000 In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write: >Unfortunately, I didn't come up with an idea for how to do this in DNS. This seems like a legitimate issue >for the WG to work through. There were two DNS proposals in DBOUND, a more complex one from Casey Deccio and a simpler one from me. Mine would certainly work for identifying org domains. R's, John From nobody Wed Nov 7 22:19:58 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54618130E8E for ; Wed, 7 Nov 2018 22:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbL3YLnDcgIK for ; Wed, 7 Nov 2018 22:19:51 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 485D3130E04 for ; Wed, 7 Nov 2018 22:19:51 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id z13so3307479lfe.11 for ; Wed, 07 Nov 2018 22:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p0K+z0Hmp9bprmV3hvwZiPuQm/NCkxupqreid4bH0bw=; b=Z8jJPYkO9+z2aCkNZ7djP3KuL+wDKGnFfZtOUgQzcHjXwpXhQRvRXOzLMy0RJtp/qj Cz/oZ0GHN1MCB6SuFAQzm0gEv3JhVSES8fSjtw5k6kGcSjRcB1M7IieAetpi8eIPJfB3 s2hOjAEPEbwMi7n7SKd6/iI+eNtf1bcLO/Lzw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p0K+z0Hmp9bprmV3hvwZiPuQm/NCkxupqreid4bH0bw=; b=OCGW9KaJi0vxPqfgaFQBdinS81XGvMTtxnH7vzmlks9ACBvPNu9ef+gEFBloEPv9+D jH3/mDWGfvcxm4ArbmmQ4qJ+9PMGUDS0B2blIy3R1G8kMTWeIrh2gN11l3gG5g38rcIp 6mbnkMqQQebK/NnP7oXbBRTZhUTQvXnXt18ez4h8y6hN7wcMrdRCr+ZA8oUSN6tyX0/O /qQrf/HUPoUXMcDvTIRCyDf+ZaHgg+j8F3ot8qErdMGQmII3Jjfb8tmZvj9CXznIQY3i VoXM5782wbI9CKgrDpiXIkWgpIj1QgmCUXoSgIDOip60g3u8Vu9m6OdIspNz3+lTL+Pv z3Ng== X-Gm-Message-State: AGRZ1gL+ZUK5IteUBomaYnGBbyAvcm0oPf4KVI0RNe2KGngbXrnfeoPA JuMDfbi8Bb3oQF1gHoBLC/MaxnBV2hekk0DkvzV+g4oYcc4rng== X-Google-Smtp-Source: AJdET5cXjpnvItbFdGlDekftrArq3GlMfxuBbCb/CpTqfSSvcyGerHje4+sIxB0gDf5RqkNxf5EZA5lURes9Z4AsLj8= X-Received: by 2002:a19:a086:: with SMTP id j128mr1738640lfe.93.1541657989185; Wed, 07 Nov 2018 22:19:49 -0800 (PST) MIME-Version: 1.0 References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> In-Reply-To: <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> From: "Kurt Andersen (b)" Date: Thu, 8 Nov 2018 13:19:34 +0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000cfaacc057a213871" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:19:55 -0000 --000000000000cfaacc057a213871 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: > In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write: > >Unfortunately, I didn't come up with an idea for how to do this in DNS. > This seems like a legitimate issue > >for the WG to work through. > > There were two DNS proposals in DBOUND, a more complex one from Casey > Deccio and a simpler one from me. Mine would certainly work for > identifying > org domains. > I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG. --Kurt --000000000000cfaacc057a213871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 8,= 2018 at 1:17 PM John Levine <johnl@t= augh.com> wrote:
In article = <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com>= you write:
>Unfortunately, I didn't come up with an idea for how to do this in = DNS.=C2=A0 This seems like a legitimate issue
>for the WG to work through.

There were two DNS proposals in DBOUND, a more complex one from Casey
Deccio and a simpler one from me.=C2=A0 Mine would certainly work for ident= ifying
org domains.

I thought that there was a= third one from Andrew too, but let's defer getting into the discussion= until we get this proposal adopted into the WG.

-= -Kurt=C2=A0
--000000000000cfaacc057a213871-- From nobody Wed Nov 7 22:42:46 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425D130DE2 for ; Wed, 7 Nov 2018 22:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8r6wR3U5dzn for ; Wed, 7 Nov 2018 22:42:41 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 23A09130DC8 for ; Wed, 7 Nov 2018 22:42:41 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id t6-v6so9070176plo.9 for ; Wed, 07 Nov 2018 22:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Cgcqg5BdbK8bXdqoAPB3zUd0gNT7fkyD9CwxFjqPJ/8=; b=gsFCgmPd//Vo8X1E/tEZOZ8/+I1DhiPIqTtHkyFCug0r0x5+GT5UVww6SVeFXija4p 0wKBPTM+Pe2eewvQL9ZCcd0OgdQGKEhQf9FEujGqHFnX5+2DH7jVmcfpJSa37w6nDI6Y SwQYc0PC1NRTZqsQHJ/VGWlaWmV/HH0nw9b/lnv44k/MEXkXfRjajU3zU4pcn/DuJcX0 KD/HFMVYqLADA1IDy1oS5TNdjWo7KN/VQWM1cUFh1BewQlP/Feaob5cjy2rXdCRkaqQM eo/B1RmunHMpyEbdOmfFl5XoI5qfvhbQmuoEK0ebkarEc251juH3WQfUc2+x5nZXv2/P nHbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Cgcqg5BdbK8bXdqoAPB3zUd0gNT7fkyD9CwxFjqPJ/8=; b=bBq6PKtNVqUM0qFEn2RQoYjyq9uHaubhKA/f5wCHOmmUNYfyKTYav6bOFcmwtshbKU 7WA9fbC/wflEGIKQcbr5peP3D3tAHQwgR/0M93Rva1cVG2qFtixg7P1EIfL/V+OOFLWl oLAS6jh65wjDjQ7Dd/hnn7IeSdmeXW0/1Z+z82InYQrXYCPTo5/jLd3XCX9VKZ+8EdJj Vp5ZyL+u0W1IPsZdTd4tDltZ1iKTgxckyCrfx7cMPkxGoknIzWijaQ5yCkD+W+uUHUDc 0k3/5Itz/D0CN1gW1xa+PyfE3kYJpweTtymltp5cxLTyza7cR+3iA/nXu/G81HKN+8me dvhQ== X-Gm-Message-State: AGRZ1gIz0dzZsbVCn4KWPVe5ROKqVJeQ9oenOKXKgmWSoIYNTsGa1ZG+ BjvmT0WevRHGPI2F/TlWP8V9PSHibr4= X-Google-Smtp-Source: AJdET5ei/Tjpb/IFZ+lKa60apoLmCSfNDqbNR1WkjqQi5AuXCzrkUQvdEsWMh8QTM5m++2bE0vtZaw== X-Received: by 2002:a17:902:6b46:: with SMTP id g6-v6mr3356628plt.33.1541659360495; Wed, 07 Nov 2018 22:42:40 -0800 (PST) Received: from [192.168.3.225] (static-222-229-224-101.adsl8.svips.gol.ne.jp. [222.229.224.101]) by smtp.gmail.com with ESMTPSA id v20-v6sm2632472pfm.114.2018.11.07.22.42.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 22:42:39 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-CAF209A9-11AB-4E89-8E6C-DFEE85E1057C Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Thu, 8 Nov 2018 15:42:38 +0900 Cc: John Levine , "dmarc@ietf.org" , Scott Kitterman Content-Transfer-Encoding: 7bit Message-Id: <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> To: "Kurt Andersen (b)" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:42:44 -0000 --Apple-Mail-CAF209A9-11AB-4E89-8E6C-DFEE85E1057C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I remember the two hog mentioned but there could of been a third.=20 =46rom my high tech gadget > On Nov 8, 2018, at 15:19, Kurt Andersen (b) wrote: >=20 >> On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: >> In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write= : >> >Unfortunately, I didn't come up with an idea for how to do this in DNS. = This seems like a legitimate issue >> >for the WG to work through. >>=20 >> There were two DNS proposals in DBOUND, a more complex one from Casey >> Deccio and a simpler one from me. Mine would certainly work for identify= ing >> org domains. >=20 > I thought that there was a third one from Andrew too, but let's defer gett= ing into the discussion until we get this proposal adopted into the WG. >=20 > --Kurt=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-CAF209A9-11AB-4E89-8E6C-DFEE85E1057C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I remember the two hog mentioned but there could of been a third. 



From my high tech gadget

On Nov 8, 2018, at 15:19, Kurt Andersen (b) <kboth@drkurt.com> wrote:

On Thu, Nov 8, 2018 at 1:17 PM John Levine <johnl@taugh.com> wrote:
In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write:
>Unfortunately, I didn't come up with an idea for how to do this in DNS.  This seems like a legitimate issue
>for the WG to work through.

There were two DNS proposals in DBOUND, a more complex one from Casey
Deccio and a simpler one from me.  Mine would certainly work for identifying
org domains.

I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG.

--Kurt 
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--Apple-Mail-CAF209A9-11AB-4E89-8E6C-DFEE85E1057C-- From nobody Wed Nov 7 22:47:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087ED130DEF for ; Wed, 7 Nov 2018 22:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WCDSGtkT; dkim=pass (1536-bit key) header.d=taugh.com header.b=aM/5/VnX 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 v3gMy5tEzcsK for ; Wed, 7 Nov 2018 22:47:35 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB59130DC8 for ; Wed, 7 Nov 2018 22:47:32 -0800 (PST) Received: (qmail 52912 invoked from network); 8 Nov 2018 06:47:31 -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=ceac.5be3dc03.k1811; bh=tZgEUVo5eU4aWAIsBmNJyeKaiE65kdJc64f6Wu+PElk=; b=WCDSGtkT5quVwKuYYwQpAI7HWp3RuJmAiDZr5hIn/d/Buqj9XixuvOb6oWSJ9+4F2fEFwwSA9nhc+nlRyODm+XC5PDOcv43JTfxQnIjzAkZ4EulIabFMrsHogB72fu0EE4xQICcRXExYWJkh2ZdAuhdzua6KIl1JRjulVQ0LSBlTVHbwdMAOxme/XfIsPwmRN+OXz2d03wxZ6q+0lus3YLTAyRKqc+eYcbh93+X6XKnzJLkfw0OZOvTWk6XgEs5g 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=ceac.5be3dc03.k1811; bh=tZgEUVo5eU4aWAIsBmNJyeKaiE65kdJc64f6Wu+PElk=; b=aM/5/VnXLegbFNp6N82adJGZ0Xn7h1iskWH+FN50HO7jhtSZ8vrd0vgbKiXqY1Tm2jIjQ6dzgzus5fG+4pS0I6pa2xdOuIByD1ppMeNYXCp9Ft9CH4SmY7YF90/M+MgEP6Zi/CYCwHgv+SUe0pgUQgWVZN7b1JGJLiy30HbZJKAJCaB/p2XbVzBuYyCvwpg2zkd1lhCV/uJk2xxRDZNA/WoCB58t4g8ck1Nib7BQzrPlmgRKkNm9Y7CoYwkiu+BG Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 08 Nov 2018 06:47:30 -0000 Date: 8 Nov 2018 13:47:27 +0700 Message-ID: From: "John R Levine" To: "tjw ietf" Cc: "dmarc@ietf.org" In-Reply-To: <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:47:37 -0000 On Thu, 8 Nov 2018, tjw ietf wrote: > I remember the two hog mentioned but there could of been a third. At this point I can't find any of the drafts other than mine, and a problem statement mostly by Andrew Sullivan. In any event, I agree it's worth having the WG take a whack at this, keeping in mind that its history is not encouraging. R's, John > From my high tech gadget > >> On Nov 8, 2018, at 15:19, Kurt Andersen (b) wrote: >> >>> On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: >>> In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write: >>>> Unfortunately, I didn't come up with an idea for how to do this in DNS. This seems like a legitimate issue >>>> for the WG to work through. >>> >>> There were two DNS proposals in DBOUND, a more complex one from Casey >>> Deccio and a simpler one from me. Mine would certainly work for identifying >>> org domains. >> >> I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG. From nobody Wed Nov 7 22:55:44 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276C2130F03 for ; Wed, 7 Nov 2018 22:55:39 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv1C43ToqQ09 for ; Wed, 7 Nov 2018 22:55:37 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 B0B79130F80 for ; Wed, 7 Nov 2018 22:55:36 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id v68-v6so5290485pfk.0 for ; Wed, 07 Nov 2018 22:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XhGqqr4OxQ30xf0ZOD4WnoFa5qVzKrd/xFFHYemc4Ik=; b=Qzs6ZmCmDmTPXS9b6iF0zoi1cMycNu5/d5BCPYOtP9FnMsi4oftDJHSxP4SGa3H67R S1uDty428Zc0SGeHxeT2onyXKKmGz93fyeCDC/KsDmn3a9r/ffLvy9ijG1qm0iSGxcfu MIQpcR562PuDXMPlTe2q/sIt3o0MYtVm817SU1GsAn+bRiZA9pCoejyoqXRBX3gegXqF iYndyYgGhXm50EMOsQuSc47aJreRgrLUJgX8Pv/mtsE1f0lzy8Y1gpZnhlrA6U6NjSLB 1YqcLJOEqcb3Nqw93BAo/MhROasTQQd5UtnO0t573O7It2ygqEQ+tWxTxDaftf/iIzMO 5cBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XhGqqr4OxQ30xf0ZOD4WnoFa5qVzKrd/xFFHYemc4Ik=; b=cNpzsDOjtiuVdLZOE60js23j8nOwpElGh6oKiRKvGRpDU/+veCRdHD8WiEbs/rLXWd /f61QlhGF02zrnzIVOFGbVBMQxAeRvszNRXb3vR7ClSRqXORC/fTX++9I+hHwP8XJ+li VjlCoW7UXQ3RUZd0QERykrc4N4YbyiNVpQmPLtInIn1eKoMGZqDsCeumWGJTFGLUk6XM utcUuw91cBXZIejlOcczwFteKmBxCbhPLaxQ02ZJdclvMPCr2XCst8JdWVgTUIIXk7Er +yqEUc+wnThJ4Ve466ME46qlZl6Ku9w9VDVuAtIjQVX2rwl/Oxzxsf9K0AxJDpIgqmw7 XUNQ== X-Gm-Message-State: AGRZ1gKYQ5iLqEU+KWIHRqVuWlHbVxgD8c25mpdLICtPkD8h+APC44d7 deixWJHuM55ib2vMH0/pbgtCVAkE13A= X-Google-Smtp-Source: AJdET5eaHeuDONYHvcWtAJnrsuuGA/FxX+Pg/Al0dLOnDJwxsqR63D/zIsTJ+59pxdFIIfWxrA37zw== X-Received: by 2002:a62:5b43:: with SMTP id p64-v6mr3535674pfb.122.1541660136251; Wed, 07 Nov 2018 22:55:36 -0800 (PST) Received: from [192.168.3.225] (static-222-229-224-101.adsl8.svips.gol.ne.jp. [222.229.224.101]) by smtp.gmail.com with ESMTPSA id u76-v6sm3134185pfa.176.2018.11.07.22.55.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 22:55:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Thu, 8 Nov 2018 15:55:34 +0900 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> To: John R Levine Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:55:43 -0000 Agree with John but from the dns side, simpler solutions tend to get tractio= n faster.=20 John May agree with that.=20 =46rom my high tech gadget > On Nov 8, 2018, at 15:47, John R Levine wrote: >=20 >> On Thu, 8 Nov 2018, tjw ietf wrote: >> I remember the two hog mentioned but there could of been a third. >=20 > At this point I can't find any of the drafts other than mine, and a proble= m statement mostly by Andrew Sullivan. >=20 > In any event, I agree it's worth having the WG take a whack at this, keepi= ng in mind that its history is not encouraging. >=20 > R's, > John >=20 >> =46rom my high tech gadget >>=20 >>>> On Nov 8, 2018, at 15:19, Kurt Andersen (b) wrote: >>>>=20 >>>>> On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: >>>>> In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you wr= ite: >>>>> Unfortunately, I didn't come up with an idea for how to do this in DNS= . This seems like a legitimate issue >>>>> for the WG to work through. >>>>=20 >>>> There were two DNS proposals in DBOUND, a more complex one from Casey >>>> Deccio and a simpler one from me. Mine would certainly work for identi= fying >>>> org domains. >>>=20 >>> I thought that there was a third one from Andrew too, but let's defer ge= tting into the discussion until we get this proposal adopted into the WG. From nobody Wed Nov 7 22:57:18 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B83130E29 for ; Wed, 7 Nov 2018 22:57:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCxS7VhuQTBn for ; Wed, 7 Nov 2018 22:57:14 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 B4F5F130E1A for ; Wed, 7 Nov 2018 22:57:14 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id y18-v6so6489186pfn.1 for ; Wed, 07 Nov 2018 22:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UzSj7Fd3K5QHKeR+sKj9Ctwskkkr7erbsoUan3bUnOw=; b=f0U9RAOrOPYotVf4e2fVAYwUPapL+I68EGG3Dr6ASF/XbatkTSF582qx3EY2iY03Jv qBYlyixUh2SxfnYzCFVgJYSYsosMKZTl2jmGzCMj9ArlQnG+Gtf3aPUSqfOVeVxCj+o0 Q0iGxTpGMhrXB3WPaedEH6fYVJGmNhi7wJivOou7yX6/5LwG7+qRrlweNeGMmL0CIqug c7niINhiAe0t9B1AT+CpLf9xCjW4wmCGXVCGrI2Vtogo5dl0pv1B9FAbWOM91DbzC6+d ijktbATnmwv6Wn6R4BJMaFSDW+sSErq31DnoP0z94yr+cRw7l3EBR6E5LAfJ1NfBjq+2 znwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UzSj7Fd3K5QHKeR+sKj9Ctwskkkr7erbsoUan3bUnOw=; b=iWCJARMJM6hl+tiYkt8KMK/QnJkqWdjD2WBMaoGbk6aJVaLLuqcGISyP4vvYg8QGzt QvQWHw9Bla8eIe2eOmvEtK+eQzLaoJClmiBsF3ST7CRzhCL4Cx7nBTIILHN0R/CRMdNY Uz6SZYRXO6wfMMgKfGadLwJ3fZ7ctJWytyDF97YsABMg54k3RXIoQG8HwGL3acD3TwMp q+9zpWith7aaBRxNqevjiFHt/BKSPshNJuo/Dv7Kpobrge/fzeJbwC/HX8oKbKP6Q/t8 zrza2i/vheFZLh58Mkngput4fVL8QHJjBzgqwq6vMWp4UpykJpIU88UEqeZxyhDws2VI QCUA== X-Gm-Message-State: AGRZ1gIFpAwr3hGiM+nC7tOiAMw/45FKwldI/jEIv4EvwCp2ssqgyz33 uuNupIPdPUJtPv6hEocfEqz5fGLzIeg= X-Google-Smtp-Source: AJdET5fOEzZZzYl+QOhdh9R/a2J/YsTSMzHf/NwRrR7bcJsEX7sCGcqQqevA+MD7euQTannzfIhCHA== X-Received: by 2002:a62:de84:: with SMTP id h126-v6mr3381756pfg.129.1541660234274; Wed, 07 Nov 2018 22:57:14 -0800 (PST) Received: from [192.168.3.225] (static-222-229-224-101.adsl8.svips.gol.ne.jp. [222.229.224.101]) by smtp.gmail.com with ESMTPSA id i26-v6sm2761785pgb.9.2018.11.07.22.57.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 22:57:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: tjw ietf X-Mailer: iPhone Mail (16A404) In-Reply-To: Date: Thu, 8 Nov 2018 15:57:12 +0900 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <40E299D7-1272-4297-9CB4-3690C9B7280D@gmail.com> References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> To: John R Levine Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:57:17 -0000 Also totally willing to tackle this.=20 =46rom my high tech gadget > On Nov 8, 2018, at 15:47, John R Levine wrote: >=20 >> On Thu, 8 Nov 2018, tjw ietf wrote: >> I remember the two hog mentioned but there could of been a third. >=20 > At this point I can't find any of the drafts other than mine, and a proble= m statement mostly by Andrew Sullivan. >=20 > In any event, I agree it's worth having the WG take a whack at this, keepi= ng in mind that its history is not encouraging. >=20 > R's, > John >=20 >> =46rom my high tech gadget >>=20 >>>> On Nov 8, 2018, at 15:19, Kurt Andersen (b) wrote: >>>>=20 >>>>> On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: >>>>> In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you wr= ite: >>>>> Unfortunately, I didn't come up with an idea for how to do this in DNS= . This seems like a legitimate issue >>>>> for the WG to work through. >>>>=20 >>>> There were two DNS proposals in DBOUND, a more complex one from Casey >>>> Deccio and a simpler one from me. Mine would certainly work for identi= fying >>>> org domains. >>>=20 >>> I thought that there was a third one from Andrew too, but let's defer ge= tting into the discussion until we get this proposal adopted into the WG. From nobody Wed Nov 7 22:57:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE281130F11 for ; Wed, 7 Nov 2018 22:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=PQSxjV0O; dkim=pass (1536-bit key) header.d=taugh.com header.b=OwstNiBm 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 tcUlG453d8FO for ; Wed, 7 Nov 2018 22:57:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21680130EF3 for ; Wed, 7 Nov 2018 22:57:21 -0800 (PST) Received: (qmail 57531 invoked from network); 8 Nov 2018 06:57:20 -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=e0b9.5be3de50.k1811; bh=8fTJEux4lrcWxWm5/ZkEvPeWTI2w0qA6jo4reJdP+4M=; b=PQSxjV0Ol95J1vyWaDjMQ/vflmvYe+HJpdNnKLHDcXPs3mOkAEJ9mQjYRojm/YT9/AN/ghZxQiDNE4U+91OZz8kEu9oPGNpz4m8VSloknnRTEOWf3UUW6AtAb7KIJ7yUukmHIU2IJwlXjEGhqtKEoYKEssERZ7UMhgxhcOu83KeTGoeaXn3mV2dpGxvV5b7ayKUEJYQ9GlwINUVSc73ZcrK4fPkd4ekBsxBCqrCtqkGUhpxL3uOsmnPZC2BoA1yy 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=e0b9.5be3de50.k1811; bh=8fTJEux4lrcWxWm5/ZkEvPeWTI2w0qA6jo4reJdP+4M=; b=OwstNiBmToPIMCQ+TYxZY9nm8rFsObJcIFUeDe3cz7+Nk5nA27UrErb1J1IZ7V8gGWBLaoHXyCXu3QQzAKJMI4e4jiXEDsP5Gne1M63DH/XjP/fpYi5rq2YgS1013Vpq+s0movthKMgimO+zN1gyUtgP02N3PIGTmxqgz9EGRxWVaKobCDQjWvToS678S5bOmB1MUCPMgWbSDLV+XZJ6UJJgQy8q/tenYmjbOfJpfcpjHH/zqZVglw7fIQcgLamR Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 08 Nov 2018 06:57:19 -0000 Date: 8 Nov 2018 13:57:15 +0700 Message-ID: From: "John R Levine" To: "tjw ietf" Cc: "John R Levine" , "dmarc@ietf.org" In-Reply-To: References: <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> <20181108061651.0AF13200829C06@dhcp-8071.meeting.ietf.org> <0B3FC7A0-E811-4800-A5F8-ED9EBA21C79C@gmail.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 06:57:26 -0000 > Agree with John but from the dns side, simpler solutions tend to get traction faster. > John May agree with that. Sure. My DBOUND approach was pretty simple, using no new rrtypes or other magic. > > From my high tech gadget > >> On Nov 8, 2018, at 15:47, John R Levine wrote: >> >>> On Thu, 8 Nov 2018, tjw ietf wrote: >>> I remember the two hog mentioned but there could of been a third. >> >> At this point I can't find any of the drafts other than mine, and a problem statement mostly by Andrew Sullivan. >> >> In any event, I agree it's worth having the WG take a whack at this, keeping in mind that its history is not encouraging. >> >> R's, >> John >> >>> From my high tech gadget >>> >>>>> On Nov 8, 2018, at 15:19, Kurt Andersen (b) wrote: >>>>> >>>>>> On Thu, Nov 8, 2018 at 1:17 PM John Levine wrote: >>>>>> In article <0E28DA8C-09A6-4E64-AD5E-3741EFE60569@kitterman.com> you write: >>>>>> Unfortunately, I didn't come up with an idea for how to do this in DNS. This seems like a legitimate issue >>>>>> for the WG to work through. >>>>> >>>>> There were two DNS proposals in DBOUND, a more complex one from Casey >>>>> Deccio and a simpler one from me. Mine would certainly work for identifying >>>>> org domains. >>>> >>>> I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG. > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Nov 8 00:53:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68479130E6D for ; Thu, 8 Nov 2018 00:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBDehFnPsaTm for ; Thu, 8 Nov 2018 00:53:42 -0800 (PST) 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 0EE15130DCC for ; Thu, 8 Nov 2018 00:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541667220; bh=YhiL5X2QT/OMw0UFooDUT7p+5glLy/4UkdN6w/UY18A=; l=846; h=To:Cc:References:From:Date:In-Reply-To; b=CtV1Hz1zV4MNUE3+VsOTiEVAiz8bnp4bh+6lCI8qpnuRClux/iFo5EpXa7ZpCXxDT qeBm1LRLnl0aP0XnQWYuwz6qavh6YTUfKj9giCQ35+xLRuT4nbmqZsAQaok4bW6VXt iag0uRz9re3W+7Ejb3D9uUNQtB4XZ4MeINgUJiGOZ0PrAIx9HnJKEfSuhP/oC Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 08 Nov 2018 09:53:40 +0100 id 00000000005DC033.000000005BE3F994.00002435 To: "Kurt Andersen (b)" , Scott Kitterman Cc: "dmarc@ietf.org" References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> Date: Thu, 8 Nov 2018 09:53:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 08:53:44 -0000 On Thu 08/Nov/2018 01:23:10 +0100 Kurt Andersen (b) wrote: > On Wed, Nov 7, 2018 at 9:42 PM Scott Kitterman wrote: > >> >> The registry is meant to be a solution to the 'what about .com' problem >> you mention. It's a solution, not necessarily the best or only one. >> >> I'd suggest we adopt the draft/work item and then try to figure it out. >> > > +1 - this is a good problem for the WG to wrestle with; Agreed > and maybe it can solve the "PSL problem" if we can constrain the problem > space to just the DMARC issues instead of recreating the > DBOUND-solve-for-all morass. This problem is simpler than DBOUND. Looking up text policies is common to a handful of protocols. A careful wording might make some statements reusable in general, even if the focus is kept on DMARC. Best Ale From nobody Thu Nov 8 10:19:56 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3FC128BCC for ; Thu, 8 Nov 2018 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjNg8zbmPFzJ for ; Thu, 8 Nov 2018 10:19:52 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 30D3112426A for ; Thu, 8 Nov 2018 10:19:52 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id u6-v6so18894804ljd.1 for ; Thu, 08 Nov 2018 10:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mFcoH/BIjD3RGkML20rO9eqPH/4VJ4zxKCsiRqCPCJM=; b=tzPwtdjtduatmnnGnnSnd0aBmpqNwQbH5WU/JbrLHgMAfi9B1gobUjnxYis2FxyUzI BZPijcgPFqP5VI4lZZqkKbDP21mRBfKrlAXxMg1LN35Pl0/qTEv4UzGC6pcxLsqVN9YA XYnuMAAoITEX8b7UJSkMrT2AoiP/zhSaCCUjuCJWRmDBSE3sdYCylsi5gOc8k0N6ZN/m TCIzwiXu8Dh1RxX0LL/9+iQ3bfpuiDzE3wdJixXTe7gV5i0+DJqZJoGk9C221OUXetJO WKBEZ2WeZ7glQflN8tnKxv4/KTVG7iuLbX55p2kw/GIKvRhjuC0kZBBW+aVV9NS9pD1R B6Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mFcoH/BIjD3RGkML20rO9eqPH/4VJ4zxKCsiRqCPCJM=; b=CE7TmTL6N15EIdNu6srkTkEdaTYCUtn8NdmrFYxKXqb/141UBr+BJ6WtOan6eVQPwr ZppJqSopbomM1ohn3UHFdyqC90/sl9IGkDbpjCSYsmvflp626nCpjkEF+NQWlJgAt69Z IhJT0dmMmTYVIXxKqHegTTvsqNAFPqJg5mEW3XYJcQhwUaK9EJWHj6fBU6W82d+aOaAs WVHrmWgS6mhGwNvd2/j2wJPbDdmE9a7xpL9DaNYz2RT1BMi0QKXMbNhSUCQYTLg20QQk 4MeJ8NNAV8POMYalbm9uBditk4j7XpGIFzsJW5dQ4z0zZmXJitpHvnrKWo49ambbLzFf enuQ== X-Gm-Message-State: AGRZ1gL+Solcd+nfVOiKqf58t8hgBxsJzytSAcC0Sys8N33fV/OaJGSs QlivGxgT5KjPaOQmoc30M0QWLG7IBvf+fbN4pYgpPUqB X-Google-Smtp-Source: AJdET5evf0C/wjMwA9OJ4GxNfc/ARtrCpUlihHwLAfhkX94tc32s5C1d4jqL8rpYcjAlBQxScWNzkfEzSPIc6+Skbl4= X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr2076743ljm.72.1541701190204; Thu, 08 Nov 2018 10:19:50 -0800 (PST) MIME-Version: 1.0 References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> In-Reply-To: <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> From: "Murray S. Kucherawy" Date: Fri, 9 Nov 2018 01:19:38 +0700 Message-ID: To: Alessandro Vesely Cc: "" , Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000cac446057a2b478d" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 18:19:54 -0000 --000000000000cac446057a2b478d Content-Type: text/plain; charset="UTF-8" On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: > > > and maybe it can solve the "PSL problem" if we can constrain the problem > > space to just the DMARC issues instead of recreating the > > DBOUND-solve-for-all morass. > > This problem is simpler than DBOUND. Looking up text policies is common > to a > handful of protocols. A careful wording might make some statements > reusable in > general, even if the focus is kept on DMARC. > Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND had focused just on the DMARC use case, it would've succeeded. If possible, we should be careful to create a solution that's extensible to other use cases, not exclusive of them. Reviewing what DBOUND tried to do might be very instructive here. -MSK --000000000000cac446057a2b478d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely <vesely@tana.it> wrote:

> and maybe it can solve the "PSL problem" if we can constrain= the problem
> space to just the DMARC issues instead of recreating the
> DBOUND-solve-for-all morass.

This problem is simpler than DBOUND.=C2=A0 Looking up text policies is comm= on to a
handful of protocols.=C2=A0 A careful wording might make some statements re= usable in
general, even if the focus is kept on DMARC.

Sure, the DMARC case is half of what DBOUND tried to tackle.=C2=A0 If= DBOUND had focused just on the DMARC use case, it would've succeeded.<= /div>

If possible, we should be careful to create a solu= tion that's extensible to other use cases, not exclusive of them.=C2=A0= Reviewing what DBOUND tried to do might be very instructive here.

-MSK
--000000000000cac446057a2b478d-- From nobody Thu Nov 8 10:37:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E2B1293FB for ; Thu, 8 Nov 2018 10:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE-b-R8lz6RM for ; Thu, 8 Nov 2018 10:37:05 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 9400A12426A for ; Thu, 8 Nov 2018 10:37:05 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id j79-v6so3198024itb.2 for ; Thu, 08 Nov 2018 10:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=unoailACrEhVj7fh57haSAY0/CX8newiu2DCZASJxJE=; b=ilsQwznu4oN7bNLtbwXly4bZe3r3rnMaK0XyJMkafBZ3XRQ2Ywh7OUFGWJEO7QuIZH 4FgUPTuVbFFvHbJB3vGo9mfuIwJAKT05wnbsGLwaW/PJT4nmpTh8PY/ok17ejo4NMiat SLKq4GLZtwdrJRBxOyc+0y38Ajo81WHqrOw9CvUOaRv7Xg/xGsl0lf00SdYF/fVqaGSg 7i3x8+MAO8elgMWXGu2/OK1sGu4um6FSF2sYXpE0S0jqMrRrax1AGaidbJ0XoqXZZlyy m7FxZrWRTz6vjejuX0ufjA3dTBISsh+0Xwj4H1GoPDU5Q9PKYI71B5XB+usb+8wZeO/F te1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=unoailACrEhVj7fh57haSAY0/CX8newiu2DCZASJxJE=; b=R+RkhqnLiAGZucVF4jTHD33Pz8APbzQTUsaEHUkLcoBMdG9WVj3qD9ZwH1gOszw34k 1KNOM4J8HB7JsxQfM6VluMnaEgk0BnIljSOfPYBpuY1xW0+WJMYmpPeIJF3vK2DckPmz NiTEwxsEePfhSaxaAzA0Tf16eXxXNYgKThaOBut2PruEypEwydV3p60D8VPb9gljkawh hv4F3pcsFWLckKZecf3nX+ZTnYMPw5sS5W6SvEgbVuTS93f1wc8rXJ0MM/ktVSxe1znz hVwaTq7Tmr0JzKXSUaSOO/U8U3AJRm8RN9R0D2mdP+ygvC+NgmNDJhpcmYZipmiof4pV zOAg== X-Gm-Message-State: AGRZ1gJzYRXSAClgm6rF8bLI1umsSFO+iDeM0lALzhRDJs6/5m3l4JKU Q2sX5ypH2j/lDmdzb9ttcywqr9zPSmPEFHEgvt4= X-Google-Smtp-Source: AJdET5eqfQELHD2EoGWfyfHf12uEX9mjgthoVkusbmRQ1i8uifpyujf5oiqdlBN+wEvokvcTnE+zeW6L5wYFo+feW6A= X-Received: by 2002:a24:85d4:: with SMTP id r203-v6mr1422166itd.124.1541702224891; Thu, 08 Nov 2018 10:37:04 -0800 (PST) MIME-Version: 1.0 References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> In-Reply-To: From: Tim Wicinski Date: Thu, 8 Nov 2018 13:36:53 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: vesely@tana.it, dmarc@ietf.org, "Kurt Andersen (b)" , Scott Kitterman Content-Type: multipart/alternative; boundary="00000000000076d19d057a2b85c5" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 18:37:08 -0000 --00000000000076d19d057a2b85c5 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 8, 2018 at 1:20 PM Murray S. Kucherawy wrote: > On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: > >> >> > and maybe it can solve the "PSL problem" if we can constrain the problem >> > space to just the DMARC issues instead of recreating the >> > DBOUND-solve-for-all morass. >> >> This problem is simpler than DBOUND. Looking up text policies is common >> to a >> handful of protocols. A careful wording might make some statements >> reusable in >> general, even if the focus is kept on DMARC. >> > > Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND > had focused just on the DMARC use case, it would've succeeded. > > If possible, we should be careful to create a solution that's extensible > to other use cases, not exclusive of them. Reviewing what DBOUND tried to > do might be very instructive here. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000076d19d057a2b85c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Thu, Nov 8, 2018 at 1:20 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Nov 8, 2018 at 3:53 PM Alessand= ro Vesely <vesely@ta= na.it> wrote:

> and maybe it can solve the "PSL problem" if we can constrain= the problem
> space to just the DMARC issues instead of recreating the
> DBOUND-solve-for-all morass.

This problem is simpler than DBOUND.=C2=A0 Looking up text policies is comm= on to a
handful of protocols.=C2=A0 A careful wording might make some statements re= usable in
general, even if the focus is kept on DMARC.

Sure, the DMARC case is half of what DBOUND tried to tackle.=C2=A0 If= DBOUND had focused just on the DMARC use case, it would've succeeded.<= /div>

If possible, we should be careful to create a solu= tion that's extensible to other use cases, not exclusive of them.=C2=A0= Reviewing what DBOUND tried to do might be very instructive here.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000076d19d057a2b85c5-- From nobody Thu Nov 8 10:37:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BA91293FB for ; Thu, 8 Nov 2018 10:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cjeC8KFNGy6 for ; Thu, 8 Nov 2018 10:37:50 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 919AD12426A for ; Thu, 8 Nov 2018 10:37:50 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id b7-v6so3058315itd.5 for ; Thu, 08 Nov 2018 10:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:from:date:message-id:subject:to:cc; bh=mOBiW5C2zOCdHMVtYfplmhCX6aK+rah8PYDaKueHqpM=; b=ZpyBea3u8sOu5XkLU7mtiLzRr29LnWOqDlRAqaNiSMjGC+Ot4JbXxlCF09vXjklNDx psf/CClDxe6xFRmZJAs9Iyz/Q32swMS8T5ApYfHQtLQu4XyRBUQKzMbNd72WBM0a9IAu RPRdxA1Bbe82EtwXYrep+ybRerXzd4cUEnEIbyT9Ggg0DphFMhYSY+4oSnGo3SuIvkz9 DkivjnO0Q1oa9wnN7no6BeSKwbeddKzIwxZywkHAq2tfbNB1amKRPiEceib7j0DzhtJc 0h4cKtFZhC82D8AHIRnDYoI+YoZ17b72Y6fWXTifa+/zuk3galqhljV6cGdNnRSJaLP6 Bsug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc; bh=mOBiW5C2zOCdHMVtYfplmhCX6aK+rah8PYDaKueHqpM=; b=R7maa6IbdB44o7zwI5OtItat9rao0zDoW2bgzbJYnCm+QfBO8iQamxY8OA4L9v0AWM hvZ9Yxbzj6nu3QYinqYKfqHl6CJZbGXpmfPn9K6vddxtR5MLzK5JbHE1ZXl3tUZR6eL6 nDoBdaqNCLLGYnim5PCAIE2t/5iyaSQEO5dhi65DhlDOvVQvP7Tqe4NauRJ5kgU9yKBQ p2Zwo23ABEEzFv02hm3wG76YS+9pfAtIvxOcrzpAhEVG5xeSHhdJ5Kh5ko2jeEjLTFC7 JDBAhoMOPtFUO2OyEQKlZlTqGa5RKrUKRSlKbCuT3b0Lr2Rr/UzTfAaVX8TczoDPV/7y SiSw== X-Gm-Message-State: AGRZ1gIVNmp1nCDWshsb72TgR8mgSE8FSfoY52Nmsr37b8sXe9i7inNo V3HgvbNgFTDjs50d+vhkn0ItP8OHsmUAzOEaQHE= X-Google-Smtp-Source: AJdET5eSxuqfDn64YKCdz/mvO63Ayux/oIk3U7CDI4+Cfo4Tpq/05N+K8oPyVRmK8d4XomK9X77EuVbQhH8cvTgIJU4= X-Received: by 2002:a02:c6da:: with SMTP id r26-v6mr5467122jan.22.1541702269892; Thu, 08 Nov 2018 10:37:49 -0800 (PST) MIME-Version: 1.0 References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> From: Tim Wicinski Date: Thu, 8 Nov 2018 13:37:37 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: vesely@tana.it, dmarc@ietf.org, "Kurt Andersen (b)" , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000257f6b057a2b88f8" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 18:37:53 -0000 --000000000000257f6b057a2b88f8 Content-Type: text/plain; charset="UTF-8" Stated Very elegantly Murray. On Thu, Nov 8, 2018 at 1:36 PM Tim Wicinski wrote: > > > On Thu, Nov 8, 2018 at 1:20 PM Murray S. Kucherawy > wrote: > >> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: >> >>> >>> > and maybe it can solve the "PSL problem" if we can constrain the >>> problem >>> > space to just the DMARC issues instead of recreating the >>> > DBOUND-solve-for-all morass. >>> >>> This problem is simpler than DBOUND. Looking up text policies is common >>> to a >>> handful of protocols. A careful wording might make some statements >>> reusable in >>> general, even if the focus is kept on DMARC. >>> >> >> Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND >> had focused just on the DMARC use case, it would've succeeded. >> >> If possible, we should be careful to create a solution that's extensible >> to other use cases, not exclusive of them. Reviewing what DBOUND tried to >> do might be very instructive here. >> >> -MSK >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --000000000000257f6b057a2b88f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stated Very elegantly Murray. =C2=A0=C2=A0

On Thu, Nov 8, 2018 at 1:36 PM Tim Wi= cinski <tjw.ietf@gmail.com>= wrote:

=
On Thu, Nov 8, 2018 at 1:20= PM Murray S. Kucherawy <superuse= r@gmail.com> wrote:
On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely <vesely@tana.it> wrote:

> and maybe it can solve the "PSL problem" if we can constrain= the problem
> space to just the DMARC issues instead of recreating the
> DBOUND-solve-for-all morass.

This problem is simpler than DBOUND.=C2=A0 Looking up text policies is comm= on to a
handful of protocols.=C2=A0 A careful wording might make some statements re= usable in
general, even if the focus is kept on DMARC.

Sure, the DMARC case is half of what DBOUND tried to tackle.=C2=A0 If= DBOUND had focused just on the DMARC use case, it would've succeeded.<= /div>

If possible, we should be careful to create a solu= tion that's extensible to other use cases, not exclusive of them.=C2=A0= Reviewing what DBOUND tried to do might be very instructive here.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000257f6b057a2b88f8-- From nobody Thu Nov 8 17:05:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9A130DD0 for ; Thu, 8 Nov 2018 17:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=zf7vq77c; dkim=pass (2048-bit key) header.d=kitterman.com header.b=knw/N8pj 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 3nBYvKyS1hPl for ; Thu, 8 Nov 2018 17:05:54 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A24512F1AB for ; Thu, 8 Nov 2018 17:05:54 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541725551; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=vB4m75ZjX39zptkeUdfUtI/A5N7l3hNGuGidPnISNXY=; b=zf7vq77czygegCgOcfWBMei5IKiyNnUWjbGUeotESE4v3JkH5oHU+vpA pG52SvaOPqVPJRh9aJhA66olID+SDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541725551; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=vB4m75ZjX39zptkeUdfUtI/A5N7l3hNGuGidPnISNXY=; b=knw/N8pjPE+6U70genGLqlL6bgHbddlZkGWcS87B8yjRnow6urp9N9SB NvNTQyS+5u3ThbKdgkHyQT+DgtpVV1HIrDqfNX4v7nINKL+NFtbfr4PCvM TeNduH1u0hzmO2ljBR6R6hDfHzdg/QIKC3I/YTwVFVrCdA8jOsBdDHHLJ+ FEOdSEQUNwlQkcJPYq59CiK3K1V6G0UwfD7n96s+LWDvYcIZXKz/U+tYC1 ytCHXvTRc/2n5+OV5hXyU6go842MZ1dPvZS+RTLK7yUJKPKT86QsND64rx IRUfbbteaeXBjN5+REce86XjymhJBcQ9QD0jDBtHaEUae5HPyDKGqg== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8E3A7C40198; Thu, 8 Nov 2018 19:05:51 -0600 (CST) Date: Fri, 09 Nov 2018 01:05:04 +0000 In-Reply-To: References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 01:05:56 -0000 On November 8, 2018 6:19:38 PM UTC, "Murray S=2E Kucherawy" wrote: >On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely >wrote: > >> >> > and maybe it can solve the "PSL problem" if we can constrain the >problem >> > space to just the DMARC issues instead of recreating the >> > DBOUND-solve-for-all morass=2E >> >> This problem is simpler than DBOUND=2E Looking up text policies is >common >> to a >> handful of protocols=2E A careful wording might make some statements >> reusable in >> general, even if the focus is kept on DMARC=2E >> > >Sure, the DMARC case is half of what DBOUND tried to tackle=2E If DBOUND >had >focused just on the DMARC use case, it would've succeeded=2E > >If possible, we should be careful to create a solution that's >extensible to >other use cases, not exclusive of them=2E Reviewing what DBOUND tried to >do >might be very instructive here=2E > >-MSK Independent of the current discussion about the new PSD DMARC draft, I thi= nk this would be a great idea=2E =20 DBOUND was set up to provide, among other things, a specific input that DM= ARC needs=2E The failure of that working group left DMARC with a hole in i= ts design=2E Operators use the Mozilla PSL as an ad hoc mechanism to fill = that hole=2E If we can actually solve the problem in a useful way, then that's great fo= r DMARC=2E I propose we add a second work item for this piece of work, sin= ce it's independent of PSD DMARC=2E If no one else wants to define the wor= k item, I can do it=2E Scott K From nobody Fri Nov 9 01:06:16 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72F1294D0 for ; Fri, 9 Nov 2018 01:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSoO3EFSjktk for ; Fri, 9 Nov 2018 01:06:13 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 5CB2A127332 for ; Fri, 9 Nov 2018 01:06:13 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id e11so2179986itl.5 for ; Fri, 09 Nov 2018 01:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kLyZtV0xvF1ElqMv5uekEXiAsp/Vr61hAxBgu+CQUk8=; b=Lvo9yp3nPI4BthSF5vaFmzSyGillUD3LIP8ytHK3PGu8npGW9YbIBi3R/vfhK1V9NB SIyxS8S7dOIW0RZmTxdk6NnhRKmRKzzSVlR5+L+PF/4x9WGLYUslMWcAVMaXtFXHAn3w q8yn4lle4zCnYXgVTJGlW7MJSn51slQnqfCWmeB+g5wepJB6uww3v1R6khoV9an7deRQ XaW5lP0ygoXg4mXnQ8MQik0Hp4ZoqnsyOpIw5+JAYzvsTiuLfx6hyTGgQcZ3awycWNsX H97rqTuyg3C/zR9TfvSg/dnQwblSfKV688uDXlQ+6oGeagJEEQ9Yi+42Z+5IIfkwsw3u Us3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kLyZtV0xvF1ElqMv5uekEXiAsp/Vr61hAxBgu+CQUk8=; b=Cry6zy27XKqN6XXpLbrkL7Lb2v9/9EN03oOdhUPyBvSCVoi9dMU6sBkqM5py6dKcEV Hr8+zG+bWuVGP3K4dqe3lLOvHxH23JoHIIvIOWTgsakYmZAlWkLFjE6z7xmw0Q6Y7Y34 yKy4OhYqvmAkmwXeOKbWEEcDrg2dh640sTI9la3Y0/+jd9vutqlDcMK9zuBLzHXZ8SHu 5ELNQZq/KLfk8Yebi0a4s0II36+fxc5MF4kPXtSxgHJuS+hBijKVIiR8U7BGQIH4bOwk cpfoccbU0mJNdChYDYpDbg0xSsJVgI+UwovvvsgcC6NMqv6q0xOFeMEaKfu6i3trx2Kp /RJw== X-Gm-Message-State: AGRZ1gLZyLj53EmoIDGaLuS2zYnScE1EqjWpCKE/JxJ19Orp6jLuKDRN o+MllDSXmkz5Vk5N9LJShpWkNJwA2/Om78a9KMwz/nNK X-Google-Smtp-Source: AJdET5dyHY/tYOzVdnPcKSuX3LoHbeULz7w8YQ26/g/p3gR2P6qAWd/jxbr6wQQWG7LJPDdK961xClF9WC1tf3SnuPs= X-Received: by 2002:a05:660c:510:: with SMTP id d16mr1341349itk.109.1541754372543; Fri, 09 Nov 2018 01:06:12 -0800 (PST) MIME-Version: 1.0 References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> In-Reply-To: From: Tim Wicinski Date: Fri, 9 Nov 2018 04:06:02 -0500 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4d99d057a37a9fa" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 09:06:15 -0000 --000000000000b4d99d057a37a9fa Content-Type: text/plain; charset="UTF-8" I dug up John's old DBOUND draft to refresh myself and it's nice and straightforward. I could not find if John shard the link so here it is: https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt (hope that is OK John) t\m On Thu, Nov 8, 2018 at 8:06 PM Scott Kitterman wrote: > > > On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" < > superuser@gmail.com> wrote: > >On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely > >wrote: > > > >> > >> > and maybe it can solve the "PSL problem" if we can constrain the > >problem > >> > space to just the DMARC issues instead of recreating the > >> > DBOUND-solve-for-all morass. > >> > >> This problem is simpler than DBOUND. Looking up text policies is > >common > >> to a > >> handful of protocols. A careful wording might make some statements > >> reusable in > >> general, even if the focus is kept on DMARC. > >> > > > >Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND > >had > >focused just on the DMARC use case, it would've succeeded. > > > >If possible, we should be careful to create a solution that's > >extensible to > >other use cases, not exclusive of them. Reviewing what DBOUND tried to > >do > >might be very instructive here. > > > >-MSK > > Independent of the current discussion about the new PSD DMARC draft, I > think this would be a great idea. > > DBOUND was set up to provide, among other things, a specific input that > DMARC needs. The failure of that working group left DMARC with a hole in > its design. Operators use the Mozilla PSL as an ad hoc mechanism to fill > that hole. > > If we can actually solve the problem in a useful way, then that's great > for DMARC. I propose we add a second work item for this piece of work, > since it's independent of PSD DMARC. If no one else wants to define the > work item, I can do it. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b4d99d057a37a9fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I dug up John's old DBOUND draft to r= efresh myself and it's nice and straightforward.=C2=A0 I could not find= if John shard the link
so here it is:=C2=A0
=

(hope that is OK John)

t\m


On Thu, Nov 8, 2018 at 8:06 PM Scott Kitterman <sklist@kitterman.com> wrote:


On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely <vesely@tana.it>
>wrote:
>
>>
>> > and maybe it can solve the "PSL problem" if we can = constrain the
>problem
>> > space to just the DMARC issues instead of recreating the
>> > DBOUND-solve-for-all morass.
>>
>> This problem is simpler than DBOUND.=C2=A0 Looking up text policie= s is
>common
>> to a
>> handful of protocols.=C2=A0 A careful wording might make some stat= ements
>> reusable in
>> general, even if the focus is kept on DMARC.
>>
>
>Sure, the DMARC case is half of what DBOUND tried to tackle.=C2=A0 If D= BOUND
>had
>focused just on the DMARC use case, it would've succeeded.
>
>If possible, we should be careful to create a solution that's
>extensible to
>other use cases, not exclusive of them.=C2=A0 Reviewing what DBOUND tri= ed to
>do
>might be very instructive here.
>
>-MSK

Independent of the current discussion about the new PSD DMARC draft, I thin= k this would be a great idea.=C2=A0

DBOUND was set up to provide, among other things, a specific input that DMA= RC needs.=C2=A0 The failure of that working group left DMARC with a hole in= its design.=C2=A0 Operators use the Mozilla PSL as an ad hoc mechanism to = fill that hole.

If we can actually solve the problem in a useful way, then that's great= for DMARC.=C2=A0 I propose we add a second work item for this piece of wor= k, since it's independent of PSD DMARC.=C2=A0 If no one else wants to d= efine the work item, I can do it.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b4d99d057a37a9fa-- From nobody Fri Nov 9 02:12:17 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68255128D09 for ; Fri, 9 Nov 2018 02:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NxIH4zqF; dkim=pass (1536-bit key) header.d=taugh.com header.b=Wtv5z7wM 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 rciRccs7Guao for ; Fri, 9 Nov 2018 02:12:14 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D7112777C for ; Fri, 9 Nov 2018 02:12:14 -0800 (PST) Received: (qmail 1408 invoked from network); 9 Nov 2018 10:12:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=57e.5be55d7d.k1811; bh=3tMdHTBfWYnHziUarGXVovsdVFf6V1GNaQ+10wjBi+Q=; b=NxIH4zqFpyPe5AnGjQVdku1IJmMTSmPSjNFa8N3FEBG8hC9F5Wp2Aii8VO5qyLb6iqDiN3jbjtMgw285LDhTIUc3k/KERRUg0q/SaOYqHDrYdFky2/3Mq/KlRhQCfxnqZqBxOjp/cFM07FYSpkqe387jbxeOjFmkrVr7kadNrk7y+uk9hRbbzZLs7ketoqwCLBZdv8YrLGY41D8GOF6gAHUbenfnn+43oU+dtwJEFe/IQZIMvLoPXwi4L6W0Dbgv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=57e.5be55d7d.k1811; bh=3tMdHTBfWYnHziUarGXVovsdVFf6V1GNaQ+10wjBi+Q=; b=Wtv5z7wMHVl7g0nj1Tb8za/V2pX5lkP0E9OTaFd7v3/WtR4eN5kGVkPuO4/UCa4E0VJc5ghd+k/nJn/4dzz1vu1L9NSONAQ3CHEKrN8aq0VpegBsTRki+TwvZoDyecwGJbOk9HWQ6LIzYoER6UzGh49GYpsPYG1GH8aImRRLLCI4/tDkkpyc88lLbKX7YHrGV94x723VScyhgin/mUeD7Layuic5nKjAtUv1KRpPi6PikHDIuuZZPS0AQM5nCaTO Received: from dhcp-8071.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 09 Nov 2018 10:12:12 -0000 Received: by dhcp-8071.meeting.ietf.org (Postfix, from userid 501) id B672C2008317D4; Fri, 9 Nov 2018 17:12:11 +0700 (+07) Date: 9 Nov 2018 17:12:11 +0700 Message-Id: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 10:12:16 -0000 In article you write: >-=-=-=-=-=- > >I dug up John's old DBOUND draft to refresh myself and it's nice and >straightforward. I could not find if John shard the link >so here it is: > >https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt > >(hope that is OK John) That is fine. I thought it was pretty straightforward, too. R's, John From nobody Fri Nov 9 02:58:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4E130DD3 for ; Fri, 9 Nov 2018 02:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn6gfwlkeM6Y for ; Fri, 9 Nov 2018 02:58:29 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 12B13130DC8 for ; Fri, 9 Nov 2018 02:58:29 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id a5-v6so951300ioq.8 for ; Fri, 09 Nov 2018 02:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SS1VdjSvRD09+cVmpZSv5IKksFSoZ5wFGUp1E9+H2DU=; b=YnFf9SQNtEEJ/k00Ys6eTJteiceTE6/SG1ClLWoclLYzUWWlBbK1m+CaoV2HI/a+5r wpTdu8wktWyX3RgE287Z47O3a8umJZ2UW9UWubbXMlSVycBgD/FIVmm0Kun4Am2qVlDE O+Y81AKXtvaKwK6vlS6BnxmxxbYw0zxmHKNFySLS/jhBdxR4yj0XkI3A9VqFNNg0uVEj TtlYCm9MxW4mUBzYpP/BJfZVO5s7lGZVxoom3ooGyvFI0qiUXJ7KjdsPxuXsJyE8UN77 16C1XWGjwHMp9RBUjii5MHyxYv8l1kO323YWIhhuB8leCq4laI54+DfRmmt/kOJCzA7p qa7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SS1VdjSvRD09+cVmpZSv5IKksFSoZ5wFGUp1E9+H2DU=; b=FSkx34EtqizdAr+gIOzKyuVAxIYOJg8/7uGldw8AAyEI76HTdwGwYwePC3Lkxh6qNS Swhzb5F4wLI8PWlwCTwgkegT/uU4/Dc6A0WcWLu43E+yTgGALK+xJJAZ2GZE2jYBpol2 +AJAhaM6R5iMIc55gwLeHd4mBB18jdb+ZT/jlrsIy0dVC9EqyZdTDs8pSIxWIXksaa79 SzaY3go4MMwYwutsAt3pQvpS5zYHvbd82SkSWRGITK4+5s10YhvE/ajtC/b9b+rhs4iV ATn6Sij9tJ0k78VVC2K8WSgyh1r9Rzpk+5rQlSkdijYrg2AcEQQONnUW3jhMxUNltOP9 VWQw== X-Gm-Message-State: AGRZ1gLY79O/1vK1s913kGWzzFptsDgWJ7BSOshX9GeCraX6gk4tjxbe sTlw5tQen02rSQEGDMfmam438BTUlEDS2hv44GHXqw== X-Google-Smtp-Source: AJdET5dFZneZu8ZSD09Hj1dkXc60/IHAsLiAE1kHmCA2yduYfUoPjlDGPrl0DwPMqD59WoxEWgGXvKFo0fsXj0U/73c= X-Received: by 2002:a5e:de07:: with SMTP id e7-v6mr3729443iok.21.1541761108245; Fri, 09 Nov 2018 02:58:28 -0800 (PST) MIME-Version: 1.0 References: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> In-Reply-To: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> From: Tim Wicinski Date: Fri, 9 Nov 2018 05:58:18 -0500 Message-ID: To: John Levine Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000002f8497057a393b78" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 10:58:31 -0000 --0000000000002f8497057a393b78 Content-Type: text/plain; charset="UTF-8" John's document reminded me of how CAA records are done, They push all the processing outside the DNS servers. Like CAA, we should make the RRTYPE require no special resolver processing and then we can get the RRTYPE fairly quickly to start. On Fri, Nov 9, 2018 at 5:12 AM John Levine wrote: > In article < > CADyWQ+HnmoQqkCzwZpjqHiD7sFVc0u3E7Yc76uw6hoPsv08j2Q@mail.gmail.com> you > write: > >-=-=-=-=-=- > > > >I dug up John's old DBOUND draft to refresh myself and it's nice and > >straightforward. I could not find if John shard the link > >so here it is: > > > >https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt > > > >(hope that is OK John) > > That is fine. I thought it was pretty straightforward, too. > > R's, > John > --0000000000002f8497057a393b78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John's document reminded me of how CAA records are don= e, =C2=A0They=C2=A0
push all the processing outside the DNS servers.=C2= =A0
Like CAA, we should make the RRTYPE require no special resolver= processing and
then we can get the RRTYPE fairly quickly to star= t.=C2=A0


On Fri, Nov 9, 2018 at 5:12 AM John Levine <johnl@taugh.com> wrote:
In article <CADyWQ+HnmoQ= qkCzwZpjqHiD7sFVc0u3E7Yc76uw6hoPsv08j2Q@mail.gmail.com> you write: >-=3D-=3D-=3D-=3D-=3D-
>
>I dug up John's old DBOUND draft to refresh myself and it's nic= e and
>straightforward.=C2=A0 I could not find if John shard the link
>so here it is:
>
>https://www.ietf.org/archive/id/dr= aft-levine-dbound-dns-01.txt
>
>(hope that is OK John)

That is fine.=C2=A0 I thought it was pretty straightforward, too.

R's,
John
--0000000000002f8497057a393b78-- From nobody Fri Nov 9 03:38:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0290E130DDA for ; Fri, 9 Nov 2018 03:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTzlkPG6IDtm for ; Fri, 9 Nov 2018 03:38:09 -0800 (PST) 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 EB917130DE9 for ; Fri, 9 Nov 2018 03:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1541763487; bh=Cwk3tVJlY2DLUDqFC7pyMW3Z1uElJbFT/UyJpIRZ3q8=; l=1650; h=To:References:From:Date:In-Reply-To; b=CMLRytvRy0EV7G7qHwm2gej9Kw3IG9eTplVEYJrsIUuD6pDMhkUbhUTEnG640EA6c RRg2nzzfM027qCLKjL5NBnLUtPkPYWzXSNr43GaGCMoM75YSeT2Hg2t5rrMlCmA7FD U0c1T4UgBANELhr0uiZtAD9c1qroZlOPY4PSK0QS4MWd5m8GANA3NqdA/BBXr Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 09 Nov 2018 12:38:07 +0100 id 00000000005DC033.000000005BE5719F.000059FF To: dmarc@ietf.org References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <86b11f6e-e305-ac07-8408-bdd821ac25a4@tana.it> Date: Fri, 9 Nov 2018 12:38:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 11:38:14 -0000 On Fri 09/Nov/2018 02:05:04 +0100 Scott Kitterman wrote: > On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" wrote: >> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote: >>> >>> This problem is simpler than DBOUND. >>> >> >> Sure, the DMARC case is half of what DBOUND tried to tackle. If DBOUND >> had focused just on the DMARC use case, it would've succeeded. "Half of DBOUND" is exact. Apparently, DBOUND tried to simultaneously solve both the concept of Organizational domain (which is also related to reputation, responsibility, and possibly liability) and the concept of establishing a default, easily overridden policy. We only need the latter half. >> [...] > > DBOUND was set up to provide, among other things, a specific input that > DMARC needs. The failure of that working group left DMARC with a hole in > its design. Operators use the Mozilla PSL as an ad hoc mechanism to fill > that hole. By its very nature, PSL defines Organizational domains —the first half. If you can exchange session cookies, you share liability. We don't need to define a topology in the DNS. We only need a default policy, established by the parent domain. Top level TXT RRs can allow some TLD's own semantics. DMARC policies also feature reporting addresses. They are quite different from, say, the point of contact (POC) linked to IP address space allocations, but let's note the concept of assigning some responsibility to the entity owning the first allocation. So, again, what's wrong with, for example: _dmarc.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc_stats@verisign.com" eh? Best Ale -- From nobody Fri Nov 9 04:58:37 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE74130E03 for ; Fri, 9 Nov 2018 04:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=andreasschulze.de header.b=F24j1R1p; dkim=pass (2048-bit key) header.d=andreasschulze.de header.b=pok7SvFX 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 Zr2hr62ewLlQ for ; Fri, 9 Nov 2018 04:58:33 -0800 (PST) Received: from mta.somaf.de (mta.somaf.de [IPv6:2001:470:77b3:103::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F273F130DFF for ; Fri, 9 Nov 2018 04:58:32 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=andreasschulze.de; i=@andreasschulze.de; q=dns/txt; s=ed25519; t=1541768310; h=date : message-id : from : to : subject : references : in-reply-to : content-type : mime-version : date : from : subject; bh=DhAt6DF797D0y82e8QL8OzLtkykNIJUJCiY/R4kEbmE=; b=F24j1R1pEBxVjsYFuCD7n44wrl6Es8VadpxLp01nrjaymnz60SaclyCd z4bglZXf1lp3bE2EDYrgYkvWKTK0Dw== Date: Fri, 09 Nov 2018 13:58:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=20181104-D157; t=1541768310; x=1546768310; bh=DhAt6DF797D0y82e8QL8OzLtkykNIJUJCiY/R4kEbmE=; h=Date:Message-ID:From:To:Subject:References:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=pok7SvFXlYqb05d+uwA+5zEL/be3hJD6vCxiPrpk4sSCi7g8qgeiwBaQZBHpNqGFj 0uy5ZZCbSqBPoedvngRKGWopx1HaiB9/fQa+VHJ6bQXdDjdSpzdda+xywkTewwStr4 VteK8UURYm8d8xOhsl2bAlLBXaIxu8BTVobvKx1gOpixitaAPYuk/jMWX40xnFjh1I k5bw7/+/5n7JClv+E87J8KYt0qmOKEShvx+BGxGvYTSJs+EBQ/QkYBJlulwkRYevla p6ffmeyacIYVBgEU/usDFc3dn+PtX8oelPb7jOFpN/EBhPICjmgLTtbMSHCA7sHgBv JmlRZLdVqL1hA== Message-ID: <20181109135829.Horde.kt-9aTgfD77P2oTpU6PNO_F@andreasschulze.de> From: "A. Schulze" To: dmarc@ietf.org References: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> In-Reply-To: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 12:58:36 -0000 John Levine: >> https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt > That is fine. I thought it was pretty straightforward, too. I read the document. It's clear and simple. one comment: When evaluating "www.foo.example.com", the first query would be to "www.foo.example._bound.com". If the reply to this is "BOUND 0 0 com", then the second query would go to "www.foo._bound.example.com". I ask myself if DNS query minimisation could be contrary to the query sequence for subdomains. QNAME minimization is normally performed by recursive resolvers. So it should not disturb. But for cases where an application implement that logic it would be good to point to RFC 7616. (in a next document version, if any will happen) Andreas From nobody Fri Nov 9 08:32:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924FD12D4F0 for ; Fri, 9 Nov 2018 08:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=c/VfRt6O; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=kjGH8osh 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 wHOosR0z-5yT for ; Fri, 9 Nov 2018 08:32:30 -0800 (PST) Received: from demo.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59B128CF2 for ; Fri, 9 Nov 2018 08:32:29 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2495; t=1541781147; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=fWS36cQaHt9uyKRahvRO+dPjSDo=; b=c/VfRt6OVrb506p5t+KPBnjpPJ6NB7ILPhx7894O5i6kyLS/MdSMB3F42rB6UZ PgIJMwH2XDB9YJTC+qROUC9H5lO20yrSyod7ykSo2ePcnXqTUbDh6V0BiuqXXyrL RBXFEQtd3lCOnKQjiBmOss8XwN9R3LHnSBIgbKL/rNpfs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 09 Nov 2018 11:32:27 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 778097247.1.1828; Fri, 09 Nov 2018 11:32:26 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2495; t=1541781041; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gwD37FV n78N89trTRVaZIjEafiGg5icZpSeY64hGtQs=; b=kjGH8oshTpnvl68z0xmlcJJ XUNIwUCgrLyF1YCPv20Jqq19CM/16FkqV1pwpFaNsV32tA06OFCMGM9IesmpOCf0 UO+THxu242WIrO81v4icYId6RiLjD2OMzgQJR1QhThLzQFWvKGspOcrx2GcXDEhI KStG4LjzqTSm7mScqDp8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Fri, 09 Nov 2018 11:30:41 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1326086641.9.305472; Fri, 09 Nov 2018 11:30:40 -0500 Message-ID: <5BE5B693.9060706@isdg.net> Date: Fri, 09 Nov 2018 11:32:19 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <93BFC1AD-9CC4-4CB4-89E1-A735AF5CD8E4@kitterman.com> <635dea71-2077-9a1a-e7a2-8594697e1068@tana.it> <446b8d5d-c059-a7d7-c38f-9c3a92241adf@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 09 Nov 2018 16:32:32 -0000 On 11/8/2018 1:19 PM, Murray S. Kucherawy wrote: > On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely > wrote: > > > > and maybe it can solve the "PSL problem" if we can constrain the problem > > space to just the DMARC issues instead of recreating the > > DBOUND-solve-for-all morass. > > This problem is simpler than DBOUND. Looking up text policies is > common to a > handful of protocols. A careful wording might make some > statements reusable in > general, even if the focus is kept on DMARC. > > > Sure, the DMARC case is half of what DBOUND tried to tackle. If > DBOUND had focused just on the DMARC use case, it would've succeeded. > > If possible, we should be careful to create a solution that's > extensible to other use cases, not exclusive of them. Reviewing what > DBOUND tried to do might be very instructive here. +1 (although I am not too keen on depending on a new RRTYPE) I think we should be focusing on working on a DMARC proposed standard, Standard Track status document and codify the many implementation issues, including: - The Author Domain identity (ADID) policy Lookup procedure with support for minimal organizational lookup concepts, - alignment issues (clarifications), - rejection logic (clarifications), and - ADID Rewriting implementation logic for List Systems, in order to maintain (as much as possible) the original organizational POLICY security. The above are the key implementation issues I am currently going through as I am updating/migration/augmenting DMARC into my existing ADSP/ATPS/DKIM package but one where we would like to finally add and honor the (risky) policy disposition logic (rejection, quarantine). For all these years, we did the Auth-Res header generation/recording with the idea of using a future filtering module. We are at this point now, especially since the industry has finally "accepted" after more than a decade, the original proof of concept, DKIM Author Domain Policy model. Anyway, there is good new proposed work, but in my opinion, since this is really all time consuming (and costly), and it will take a long time, I think we should view the new work as part of DMARC and finally focus on working on the IETF-sanctioned DMARC "Standard Track" status specification and get all the learned implementation details codified and worked out. Have a good weekend, Hector Santos/CTO Santronics Software, Inc. From nobody Fri Nov 9 19:57:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094D130E07 for ; Fri, 9 Nov 2018 19:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=ntOPAeQo; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=qJcUdiZO 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 aV1gwIQYdWM3 for ; Fri, 9 Nov 2018 19:57:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E69130DD5 for ; Fri, 9 Nov 2018 19:57:50 -0800 (PST) Received: (qmail 520 invoked by uid 100); 10 Nov 2018 03:57:49 -0000 Date: 10 Nov 2018 03:57:49 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:cleverness; s=1fd.5be6573d.k1811; i=news@user.iecc.com; bh=cRKtdi/ZSb+kXN1JJvvAlgkxfE242cek1pn6jePSjsY=; b=ntOPAeQosgbNZPT0UojHTKDs7C7Z3ZXejS0IBQQtiYJpGJ9khrcE92PnfwRAyj1LPF3mm1EmOetb5w3Ii2bN7KGBIZkiRXosTWUaQ8yBupvkJ42mEyJBkP/lA5QkkxZh0m/49DV04WhNq447BiQSm3xTK2yDWhn2I3E2JCfC9JPUOIR8OXmwj0msqLib0NtGertm3nsmCMtyVxzQ2oO25c33r+REqv8bTfmUD5WVTaOVPbtIlRWeIkR8Mx5MJpQg DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:cleverness; s=1fd.5be6573d.k1811; olt=news@user.iecc.com; bh=cRKtdi/ZSb+kXN1JJvvAlgkxfE242cek1pn6jePSjsY=; b=qJcUdiZOuXwkRTn7vcdCttar8zXRjBaV5mvLZyeo+PsIT/JIi1+iGY+ZI6YkE2LAM3X4/6vLs4PN8AeIubzEbB2TuIL3/GFQi8VX/dyb+x1+x7l0ZLiXvbgaIgtOaqlg4kP4+ibe4z5vtdE1l/hLCSAHUD6cZCXgpjvOBoJrk53Mv73zScW6N5zmooAHVc5XpigJQyYh620IwBAJDmEkvamqShENVhNLIW1kojCofyfR5i1X7MvODPOFsExaVqTE Organization: Taughannock Networks References: <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> <20181109101211.B672C2008317D4@dhcp-8071.meeting.ietf.org> <20181109135829.Horde.kt-9aTgfD77P2oTpU6PNO_F@andreasschulze.de> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Nov 2018 03:57:53 -0000 In article <20181109135829.Horde.kt-9aTgfD77P2oTpU6PNO_F@andreasschulze.de>, A. Schulze wrote: > When evaluating "www.foo.example.com", the first query would be to > "www.foo.example._bound.com". If the reply to this is "BOUND 0 0 > com", then the second query would go to > "www.foo._bound.example.com". > >I ask myself if DNS query minimisation could be contrary to the query >sequence for subdomains. >QNAME minimization is normally performed by recursive resolvers. So it >should not disturb. >But for cases where an application implement that logic it would be >good to point to RFC 7616. I worry that if we try to enumerate every possible dumb way someone might implement even a very simple design, we will end up with a very very very long document. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Nov 9 20:38:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46BF130FF0 for ; Fri, 9 Nov 2018 20:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=kbJdZYzc; dkim=pass (1536-bit key) header.d=taugh.com header.b=LwXl016e 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 JMWyZ_o5kRVz for ; Fri, 9 Nov 2018 20:38:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E49D130E7F for ; Fri, 9 Nov 2018 20:38:53 -0800 (PST) Received: (qmail 22669 invoked from network); 10 Nov 2018 04:38:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5889.5be660dc.k1811; bh=rhwx7a/WIA6TrPuNH4ePVAofFZw1eKy79f2w6218KUI=; b=kbJdZYzcGINP0k0hkRUbhL7gwTAe3pyEcAoSafbPibkpwWiVuO26pWw/qE4bn8SuvML2bBHaqohFJPpkiujXhF6GTbETRXciK7a6GZ7nyS2CM1aHpbjwLtSUGEeVEkTr2Zp0zsFlCsOMHiZkv3Zuc45OS4rM+4/qax/2hTHBsAVibN7SEm8GToeBNYcizMi49rW2mizQO+RWOVxUPqBZRhdlGH54kdKsTgWijuDsrXxw/eUIEckbH9UbFCXm1PUA DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5889.5be660dc.k1811; bh=rhwx7a/WIA6TrPuNH4ePVAofFZw1eKy79f2w6218KUI=; b=LwXl016e52jBn5XVVHrujKcGt06gM0uWOuFaPhG9w7HS0rIxLSZJsjrZKmuaoHH2E+YXJclexYcCDU4iskYVwP25wkAIm7MHfTWqqGyLa+25Jhqd/V0biUc3+RmbjNDZjlUEHUIDBkbQWY5TLs+gfiYkTx+qFK4hzFQjw4xQMF8i/Yr3cgK2D2YdfuUswNyD3eptRphn6jLXoCXSca8Q/16+1ERILo5ByGho9IHgYbWGRmDlrAAypbzRClwpy2hm Received: from dhcp-8071.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Nov 2018 04:38:51 -0000 Received: by dhcp-8071.meeting.ietf.org (Postfix, from userid 501) id C0BED200834BFD; Sat, 10 Nov 2018 11:38:50 +0700 (+07) Date: 10 Nov 2018 11:38:50 +0700 Message-Id: <20181110043850.C0BED200834BFD@dhcp-8071.meeting.ietf.org> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Nov 2018 04:38:55 -0000 In article you write: >-=-=-=-=-=- > >John's document reminded me of how CAA records are done, They >push all the processing outside the DNS servers. >Like CAA, we should make the RRTYPE require no special resolver processing >and then we can get the RRTYPE fairly quickly to start. In my proposal it's just a container, nothing special. The magic all comes from the closest encloser rule for wildcards, which is unrelated to rrtype. R's, John From nobody Wed Nov 14 16:32:49 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B83741294D0; Wed, 14 Nov 2018 16:32:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154224196769.19210.11052308771300257639@ietfa.amsl.com> Date: Wed, 14 Nov 2018 16:32:47 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-04.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Nov 2018 00:32:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-dmarc-rfc7601bis-04.txt Pages : 48 Date : 2018-11-14 Abstract: This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 19 12:52:15 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCC5130DF4; Mon, 19 Nov 2018 12:52:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles To: Cc: dmarc@ietf.org, ietf@ietf.org, draft-ietf-dmarc-arc-protocol.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154266072031.16394.11028131755209052240@ietfa.amsl.com> Date: Mon, 19 Nov 2018 12:52:00 -0800 Archived-At: Subject: [dmarc-ietf] Genart telechat review of draft-ietf-dmarc-arc-protocol-21 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Nov 2018 20:52:01 -0000 Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dmarc-arc-protocol-21 Reviewer: Ines Robles Review Date: 2018-11-19 IETF LC End Date: 2018-11-06 IESG Telechat date: 2018-11-21 Summary: I believe the draft is technically good. This document is well written and clear to understand. This document describes the Authenticated Received Chain (ARC) protocol, which provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. I like that the document mentions the available implementations. Major issues: Not found Minor issues: Not found Nits/editorial comments: Not found From nobody Mon Nov 19 13:04:47 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647F130DED; Mon, 19 Nov 2018 13:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T-jjqQFZgP7; Mon, 19 Nov 2018 13:04:44 -0800 (PST) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (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 6AB47130DE8; Mon, 19 Nov 2018 13:04:44 -0800 (PST) Received: by mail-it1-f179.google.com with SMTP id o19so181291itg.5; Mon, 19 Nov 2018 13:04:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/tYkNSLzN9dDrdZFNyGtw2QwInnqwEpsPRyeO6d8gwk=; b=Z5K/HMDbZY2ZMeWvutLlGWg7kv+yQ0nSZEhPvON4f0/HseT7vVGLzlV6TJP/X8spIK zqoSG10BkywUxypYmAhURMX7ocyCDJo7pM09KUB8LlY/9jYrSL0eB2j4NKtlvAtdGdu/ DZMwbBJo55sd5MwYfCa9utYeIt0tHIU9E3Ui02jqE0VxirzrXh+/48aPO16lGckcLdPQ Qv6BAaIT6slXhdqdlDIaIHvlk+czwLkz+djKmTcXMZunJug5X9iawVu0h1frNXPBLvd0 lpG4EKzqkNLeGc0xwuIo8D5/5LC6mjxEv95tVXedp9d56YBpwa5HZ+jc9RtrSjqk5OWb WseA== X-Gm-Message-State: AGRZ1gLrT2L+zakO3YPymxO2JHesX3TNEA5l+9nNSX2nM5sDET0m18mO 60/O/e2nI6zuRDkLRybmSTngHCELNXzdWL2RHTk= X-Google-Smtp-Source: AJdET5ePYpCReuL1QyyZYsCxx2WvU5g3X2ON5vgPMqKBIW5wvh8G40egwnBB+deiyFRr4RWyGWaFqFqWMHcJJi6FNJg= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr9380220itf.84.1542661483196; Mon, 19 Nov 2018 13:04:43 -0800 (PST) MIME-Version: 1.0 References: <154266072031.16394.11028131755209052240@ietfa.amsl.com> In-Reply-To: <154266072031.16394.11028131755209052240@ietfa.amsl.com> From: Barry Leiba Date: Mon, 19 Nov 2018 16:04:31 -0500 Message-ID: To: Ines Robles Cc: General Area Review Team , dmarc@ietf.org, IETF discussion list , draft-ietf-dmarc-arc-protocol.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Genart telechat review of draft-ietf-dmarc-arc-protocol-21 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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 Nov 2018 21:04:46 -0000 Hi, Ines. Thanks again for another review. Barry On Mon, Nov 19, 2018 at 3:52 PM Ines Robles wrote: > > Reviewer: Ines Robles > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dmarc-arc-protocol-21 > Reviewer: Ines Robles > Review Date: 2018-11-19 > IETF LC End Date: 2018-11-06 > IESG Telechat date: 2018-11-21 > > Summary: > > I believe the draft is technically good. This document is well written and > clear to understand. > > This document describes the Authenticated Received Chain (ARC) protocol, which > provides an authenticated "chain of custody" for a message, allowing each > entity that handles the message to see what entities handled it before, and to > see what the message's authentication assessment was at each step in the > handling. > > I like that the document mentions the available implementations. > > Major issues: Not found > > Minor issues: Not found > > Nits/editorial comments: Not found > > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Mon Nov 19 13:05:33 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A59130E6A; Mon, 19 Nov 2018 13:05:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org, ldunbar@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154266152011.16407.16520048851856617842.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 13:05:20 -0800 Archived-At: Subject: [dmarc-ietf] Warren Kumari's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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 Nov 2018 21:05:24 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank to Linda Dunbar for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-dmarc-rfc7601bis-03-opsdir-lc-dunbar-2018-10-31/ From nobody Tue Nov 20 09:03:02 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B111294D0; Tue, 20 Nov 2018 09:02:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154273337967.18363.3557179370600723342.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 09:02:59 -0800 Archived-At: Subject: [dmarc-ietf] Alvaro Retana's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 17:03:00 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't understand why this document is tagged as an Update to RFC7601 and not as Obsoleting it. This change was made between the -03 (which was the one in the IETF LC) and the -04 (current) versions. As far as I can tell, the contents of this document are the same as rfc7601, + 2 new headers. Just as the reference for the Authentication-Results Header Field is being updated to point at this document, the registry pointers to rfc7601 can also be moved. I note that this point was brought up during both the AD Review [1] and the IETF LC [2], which is why I'm not balloting DISCUSS. However, I think that the solution (Updating instead of Obsoleting) is not the correct one. [1] https://mailarchive.ietf.org/arch/msg/dmarc/ug2XvXqGjyd6S7utkrSq7pq3wv0 [2] https://mailarchive.ietf.org/arch/msg/ietf/L28CWVReXoBBiSSy2tc-JPeXD3I From nobody Tue Nov 20 09:33:32 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97D12008A; Tue, 20 Nov 2018 09:33:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: dmarc-chairs@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154273521107.29833.12344323303560312131.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 09:33:31 -0800 Archived-At: Subject: [dmarc-ietf] Alvaro Retana's No Objection on charter-ietf-dmarc-01-00: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 17:33:31 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-dmarc-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Phase I description is still included: "Draft description of interoperability issues for indirect mail..." Isn't that rfc7960? From nobody Tue Nov 20 12:45:00 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F3712D4EF; Tue, 20 Nov 2018 12:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9mEq7KwWwNn; Tue, 20 Nov 2018 12:44:57 -0800 (PST) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) (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 67B9512785F; Tue, 20 Nov 2018 12:44:57 -0800 (PST) Received: by mail-it1-f170.google.com with SMTP id c9so5709848itj.1; Tue, 20 Nov 2018 12:44:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dj/TYEnVMzT8wQs12ZGDFe2Gug121AOaPHzNDuh6428=; b=NwyJeNA7rbH8/dIb4p2ShrHO2jOrO8vvz/GfkEXbNs+NXqxO47ZLJi5ryILiz6pJwk S5er3nKfGjGkmVCAR9xeWqs4w2sh8EqoOKeXbWKOVvaoB20aWqD5gACG4AA8vCtJwNAF Md6xE+tzZlS7O1Te9VcyxtYvA87GKaYZ/tIcsfnYcV0jxPt3bAXYcY7P5YJML6oBv1vA a+QU2pl8DfRmasAPkne8e8JIz+80kcJXvQbBA/jH2U3Qx/JwAuE1XQCwoocMfhg+z8PJ VrNWrf9sqmH3yb8X1+aFE8iR8J83U1q9WGYP3Udr27QtGBcIfDWiMRMYBRfwOBOlMdjL THzA== X-Gm-Message-State: AA+aEWadvqM1InfMV/GKo3Gj6QmS3HyR6KCRhCyGJrlNLBPBmhiL8JH6 GKlQWlTQnYRQkJ04gwfYgidDuXu5Px0b3+fnwb8= X-Google-Smtp-Source: AJdET5dTX3NPQtcGh4HpeiZWSoZvMI15qCgdFUI/jC3/nVzbuT8DWxaSxnyLTpBnwqo8QRX1OuBA+K1AWmkBMPu+1uc= X-Received: by 2002:a02:778a:: with SMTP id g132mr2943795jac.140.1542746696301; Tue, 20 Nov 2018 12:44:56 -0800 (PST) MIME-Version: 1.0 References: <154273521107.29833.12344323303560312131.idtracker@ietfa.amsl.com> In-Reply-To: <154273521107.29833.12344323303560312131.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Tue, 20 Nov 2018 15:44:45 -0500 Message-ID: To: "Alvaro Retana (aretana)" Cc: IESG , dmarc-chairs@ietf.org, dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Alvaro Retana's No Objection on charter-ietf-dmarc-01-00: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 20:44:59 -0000 > The Phase I description is still included: "Draft description of > interoperability issues for indirect mail..." Isn't that rfc7960? Yeh, we did this too quickly, I'm afraid. We should make a few other minor changes to reflect the now-past: OLD The existing DMARC base specification has been submitted as an Independent Submission to become an Informational RFC. NEW The existing DMARC base specification is published as Informational RFC 7489. END OLD Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. NEW Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. END OLD Specification of DMARC improvements to support indirect mail flows NEW Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol END Alexey, will you make those changes, please? -- Barry From nobody Tue Nov 20 13:03:38 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED688124D68; Tue, 20 Nov 2018 13:03:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: dmarc-chairs@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154274780493.29758.10284579659666859291.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 13:03:24 -0800 Archived-At: Subject: [dmarc-ietf] Alissa Cooper's Block on charter-ietf-dmarc-01-00: (with BLOCK and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 21:03:25 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-dmarc-01-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- (1) I realize this re-charter is motivated by a small update, but it seems confusing to maintain text that is out-of-date when publishing a re-charter. Someone already pointed out the issue with RFC 7960; I would also argue that the following change is needed: OLD The existing DMARC base specification has been submitted as an Independent Submission to become an Informational RFC. NEW The existing DMARC base specification has been published as RFC 7489 in the Independent Stream. (2) "Any issues related to the email authentication space ..." seems like a rather broad charge. I understand the desire to work on draft-levine-appsarea-eaiauth, but does that really justify this much wider charter expansion? I feel like the point of the chartering process is to avoid this kind of catch-all. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable." It's not clear how documenting authentication requirements implies directly improving the base specification. From nobody Tue Nov 20 14:09:21 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994DF130EA7 for ; Tue, 20 Nov 2018 14:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkKzo-KNXJ3E for ; Tue, 20 Nov 2018 14:09:14 -0800 (PST) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (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 D16EB130EEA for ; Tue, 20 Nov 2018 14:09:12 -0800 (PST) Received: by mail-ed1-f50.google.com with SMTP id r27so3296800eda.0 for ; Tue, 20 Nov 2018 14:09:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mTeZbZGmK0PJxuugBsFrFn+uu9JgKVTBlqD8zkvm85I=; b=DbsQ+eZItmvdJHRHSTjXpGxvdawimnQveVsUvEwd5Xgy4yw6hrOL1pNAZ0sE9QHZY9 8OzFJfvDRZm9gWDAiS8Ckm8cpMbk8/DJVj6pjtQgRTLXZ9Z4uDa/NrQUu4499Cog89Lw 1QbMX6OhiRTLGnC4Q0r2pDjgZiqNlUQDvpCmmY2wMkFJku59tgFscunwXptnHrWmTycl +dqrNcxAU95D0g5/+EPTWhYqqD7PwjnCDtOYW3G19FFV5EhUDJopmY4WiRNyooBX821O i3FPgwCsYA823nUxF3wWzzuThNgrhvJ/pVWmNeWkUsNsuz70l9pYfqXMkIeJIZ19DYPC LxZg== X-Gm-Message-State: AA+aEWa7aThS/CLpP3BcMbeUl+qLmZnfUHMxAtCqRuctMb6ib58fsY9E phgJM6WqfUS+YfVBviDkpWIj0UtN4wEmSr29O8D5GyoG X-Google-Smtp-Source: AFSGD/VkV/AOHphM9nR7XqZEkvlczLb0J1DtRuBa5DOZvF9uShw4oAKFgcGp3/neQMB+OH2xVxSElVbqn3bOAUDQZr8= X-Received: by 2002:a50:ce0f:: with SMTP id y15mr3110830edi.207.1542751750798; Tue, 20 Nov 2018 14:09:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Tue, 20 Nov 2018 17:08:59 -0500 Message-ID: To: dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 22:09:20 -0000 > > I'd like to recommend that we (DMARC-WG) accept https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 > > into our work queue. It aligns with our charter already. > > I've seen three agreements and no objections, so here's an official > call for objections. If there are none by 16 November, we will create > draft-ietf-dmarc-psd-00 as a new working group item. Lots of discussion, and no objections to working on this and starting with Scott's draft. So, Scott, please post draft-ietf-dmarc-psd-00, and let's continue the discussion. Barry From nobody Tue Nov 20 15:09:15 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2A1130E52; Tue, 20 Nov 2018 15:09:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 15:09:00 -0800 Archived-At: Subject: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 23:09:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is mainly a process discuss. I share Alvaro's concern about this being marked as "updating" RFC7601, when it seem like a full replacement. I'm promoting it to a DISCUSS because I think this needs to be resolved before publication. The current structure will make it very difficult for readers to figure out which parts of each doc they need to worry about. I think it needs to either go back to "obsoleting" 7601, or it needs to be recast to just talk about the changes. Note that if the former path is chosen, the IANA considerations in 7601 will need to be copied forward. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary changes. That makes the diff tools much more useful than they are for bis drafts that make wholesale organization and stylistic changes. From nobody Tue Nov 20 15:29:02 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202E8126CC7 for ; Tue, 20 Nov 2018 15:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Wa0E3VcV; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dfMCCSCO 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 DyDZeyUPkyyX for ; Tue, 20 Nov 2018 15:28:58 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0453612007C for ; Tue, 20 Nov 2018 15:28:58 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542756536; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=r90atbl6cOURGratrruISv11QPis6pjO1J/u9qUt0Kk=; b=Wa0E3VcV+o28A8Rc9m3EfYnda0BnWp1DgcIClgf+ctO6Oux+QlEKVs6g 7dR44mqBtaXdttSnCZDfuskL93KeAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542756536; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=r90atbl6cOURGratrruISv11QPis6pjO1J/u9qUt0Kk=; b=dfMCCSCOlfuQCWVzUUbGU7KVSuohseQcfASVRnw7h8KnkfxbHiYzOoQy 4xWjPx/Zys+CXIK3ABG2/iUbZspsaeSvhN+wwJA83KTi2Fd0ZGZvPsKOhQ uFNq2Mln70Uob5Y9ryg0abi+7eUdeLSZsDWKV3GpXst2VmliEg+hdMrqax 5Zci4gkraOdwiSeEpcpPwh+6tJ3iYLAp88v5PcmQNJgujMkKB4T0BqEr2X G+pum35JF7cpHBdRC7ABSkzbFfzVeP07eFKaT45yLy+URumLvmd28xPY5N 6XU2ahlByv7tizRM1onJw4icL+FpCOQsO7EkYKVTYKZzMNyahfgP5g== Received: from [10.55.130.173] (mobile-166-171-58-112.mycingular.net [166.171.58.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6CE03C400ED; Tue, 20 Nov 2018 17:28:56 -0600 (CST) Date: Tue, 20 Nov 2018 23:28:51 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 23:29:00 -0000 On November 20, 2018 10:08:59 PM UTC, Barry Leiba wrote: >> > I'd like to recommend that we (DMARC-WG) accept >https://tools=2Eietf=2Eorg/html/draft-kitterman-dmarc-psd-00 >> > into our work queue=2E It aligns with our charter already=2E >> >> I've seen three agreements and no objections, so here's an official >> call for objections=2E If there are none by 16 November, we will >create >> draft-ietf-dmarc-psd-00 as a new working group item=2E > >Lots of discussion, and no objections to working on this and starting >with Scott's draft=2E So, Scott, please post draft-ietf-dmarc-psd-00, >and let's continue the discussion=2E Will do=2E I'll post it tonight or tomorrow=2E Scott K From nobody Tue Nov 20 16:01:02 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F891130EA1; Tue, 20 Nov 2018 16:00:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , Barry Leiba , dmarc-chairs@ietf.org, tjw.ietf@gmail.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275845451.29890.8183624574759474872.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 16:00:54 -0800 Archived-At: Subject: [dmarc-ietf] Ben Campbell's Yes on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 00:00:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmarc-arc-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for including the Experimental Considerations From nobody Tue Nov 20 16:46:52 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1D3130EAE; Tue, 20 Nov 2018 16:46:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: Tim Draegen , dmarc@ietf.org, tim@dmarcian.com, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154276121031.29824.13392388978609143158.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 16:46:50 -0800 Archived-At: Subject: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 00:46:50 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5317 IMPORTANT S 7.10. > processing of these is outside of the intended scope of this document > (see Section 1.3), some early guidance to MUA developers is > appropriate here. > > Since MTAs are unlikely to strip Authentication-Results header fields > after mailbox delivery, MUAs are advised in Section 4.1 to ignore I think you want to be stronger than "are advised to" COMMENTS S 1.1. > its contents are valid. Rather, the header field is reporting > assertions made by one or more authentication schemes applied > somewhere upstream. For an MUA or downstream filter to treat the > assertions as actually valid, there must be an assessment of the > trust relationship among such agents, the validating MTA, and the > mechanism for conveying the information. And also a trustworthy path from the validating MTA S 1.2. > Thus, this document defines a "trust boundary" as the delineation > between "external" and "internal" entities. Services that are > internal -- within the trust boundary -- are provided by the ADMD's > infrastructure for its users. Those that are external are outside of > the authority of the ADMD. By this definition, hosts that are within > a trust boundary are subject to the ADMD's authority and policies, This seems like a reasonable design, but not the only one. For instance, Gmail might attach these headers, but I don't think of my MUA as being subject to its authority and policies. S 1.5.1. > > 1.5.1. Key Words > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [KEYWORDS]. I'm probably the 10th person to suggest 8174 boilerplate. S 1.5.3. > agents, assign (some) responsibility for the message (which implies > authorization), and ensure that the listed portions of the message > were not modified in transit. Since the signatures are not tied to > SMTP connections, they can be added by either the ADMD of origin, > intermediate ADMDs (such as a mailing list server), other handling > agents, or any combination. I'm not sure how persuaded I am by this terminology. However, regardless of that, this claim about SPF seems problematic in the sense that you could have an intermediate MTA decorate the message with the incoming IP address (in some unspecified way) but then have the terminal MTA do the SPF validation. S 2.2. > combination of these can be applied. > > 2.2. Formal Definition > > Formally, the header field is specified as follows using Augmented > Backus-Naur Form ([ABNF]): An example would be kind of helpful here. S 2.4. > > This ptype existed in the original specification for this header > field, but without a complete description or example of intended use. > As a result, it has not seen any practical use to date that matches > its intended purpose. These added details are provided to guide > implementers toward proper use. This text is odd in a bis draft, because "the original" is not 7601 or 7001. S 5. > example.com receiving a message MUST delete or otherwise obscure any > instance of this header field bearing an authentication service > identifier indicating that the header field was added within > example.com prior to adding its own header fields. This could mean > each MTA will have to be equipped with a list of internal MTAs known > to be compliant (and hence trustworthy). It's not "known to be compliant" but rather "known to be trusted by any MUA within the trust boundary" S 5. > version (express or implied) that it does not support. However, an > MTA MUST remove such a header field if the [SMTP] connection relaying > the message is not from a trusted internal MTA. This means the MTA > needs to be able to understand versions of this header field at least > as late as the ones understood by the MUAs or other consumers within > its ADMD. Doesn't this have the impact of breaking signatures as you just said above? S 7.1. > 7.1. Forged Header Fields > > An MUA or filter that accesses a mailbox whose messages are handled > by a non-conformant MTA, and understands Authentication-Results > header fields, could potentially make false conclusions based on > forged header fields. A malicious user or agent could forge a header I think the text here you want is that the MUA understands these fields, not the non-conformant MTA. So perhaps you can rewrite this? S 8.2. > > A message that was delivered by an MTA that conforms to this > specification and applied some message authentication: > > Authentication-Results: example.com; > spf=pass smtp.mailfrom=example.net Maybe this example would be good to put up front? S 8.2. > to know how to do the work that upstream MTAs do; they only need > the results of that work. > > 4. Evaluations about the quality of a message, from simple token > matching (e.g., a list of preferred DNS domains) to cryptanalysis > (e.g., public/private key work), do have a cost and thus need to This is not usually what we would call "cryptanalysis". Perhaps you mean "cryptographic verification"? From nobody Tue Nov 20 17:31:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF0130E2E; Tue, 20 Nov 2018 17:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=juReCxck; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ML5/psdl 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 XJw0fuMC-6FP; Tue, 20 Nov 2018 17:31:02 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83304130E18; Tue, 20 Nov 2018 17:31:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 142D423AE6; Tue, 20 Nov 2018 20:30:45 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 20 Nov 2018 20:30:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=V 29QepCansevoNQhsW/YyswiO5LDGc3qPdaxBVaxWPA=; b=juReCxck605pKEKLI DNlthDglJrp9KxMhnSWPh3AU4NTNtDXvUC3LVHUtLlLkhFe3BDuhwQV9U4vdwmmX 08S7POkBIz21rWFbYWGQIRFgp4PepDxF2LEis1fDV4GproC0M57KseeqG4RxlQBS D99WCv4eIaDRUsAXCtRIFFWi6dOcdB/3SbV3p8INXBYhKgiqhcJ7e9wEOGgMCsL1 nPWDPb1QdkzIsRhs47cxwTgLf2XIAuOzzRqJRNf+DR7wVlirxJNkQ8b56Li1pHCv nKSmZ0wrPFDUbPFIn7zXYDmrQUjvkL1uouai1d1Js17HbLfFiFFypbMGPwHEVXou 2j6Ig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=V29QepCansevoNQhsW/YyswiO5LDGc3qPdaxBVaxW PA=; b=ML5/psdlS+pKU5cNb3qdy3AN51I4syUrKpuHIr//Kus4YsAz8tFnrlEso ibj8z05H/TLRf7sJFC5MnvJ4cTjW+fnaVtf23hIy68e6sE4nHKAkcAlSTrIX6cvh PW58003G4yC3RjR9bFa/NtoajtKVsQFCt8RO26HbPbuVujNadaCFbUvTZxHNjz5J oTMb8cPxUpczNdcA7D9UGEq6IIt3a8nneA6eQZp1lPyo1njB6R74pI2tnHEVpMoK Daiaqdf2Qgj+cou96SrBvWcIDFHm+Fv7CxRKcA5g6AoitLRh9yijfA1TlYL0z9zC PIQMvnaVSHyuRsB5STbTkgVllVu7Q== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 60FAC103E0; Tue, 20 Nov 2018 20:30:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154266072031.16394.11028131755209052240@ietfa.amsl.com> Date: Tue, 20 Nov 2018 20:30:43 -0500 Cc: General Area Review Team , dmarc@ietf.org, draft-ietf-dmarc-arc-protocol.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8FD1E82C-F3CA-4A38-A8D3-46B00252DCEC@cooperw.in> References: <154266072031.16394.11028131755209052240@ietfa.amsl.com> To: Ines Robles X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [dmarc-ietf] [Gen-art] Genart telechat review of draft-ietf-dmarc-arc-protocol-21 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 01:31:05 -0000 Ines, thanks for your reviews of this document. Thanks to those who = responded. I entered a No Objection ballot. Alissa > On Nov 19, 2018, at 3:52 PM, Ines Robles = wrote: >=20 > Reviewer: Ines Robles > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-dmarc-arc-protocol-21 > Reviewer: Ines Robles > Review Date: 2018-11-19 > IETF LC End Date: 2018-11-06 > IESG Telechat date: 2018-11-21 >=20 > Summary: >=20 > I believe the draft is technically good. This document is well written = and > clear to understand. >=20 > This document describes the Authenticated Received Chain (ARC) = protocol, which > provides an authenticated "chain of custody" for a message, allowing = each > entity that handles the message to see what entities handled it = before, and to > see what the message's authentication assessment was at each step in = the > handling. >=20 > I like that the document mentions the available implementations. >=20 > Major issues: Not found >=20 > Minor issues: Not found >=20 > Nits/editorial comments: Not found >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Nov 20 17:57:57 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 857AA124C04; Tue, 20 Nov 2018 17:57:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: dmarc-chairs@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154276546748.29873.13968026001049295698.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 17:57:47 -0800 Archived-At: Subject: [dmarc-ietf] Ben Campbell's No Objection on charter-ietf-dmarc-01-00: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 01:57:48 -0000 Ben Campbell has entered the following ballot position for charter-ietf-dmarc-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's 2nd block point. I _think_ this section 4 is about MTA-MTA authentication, right? For example, s/mime or other e2e signature enhancements would not be in scope, would they? How about new user-to-MUA authentication methods? From nobody Tue Nov 20 18:49:06 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F70127B92; Tue, 20 Nov 2018 18:49:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154276854434.29845.2318681395241682940.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 18:49:04 -0800 Archived-At: Subject: [dmarc-ietf] Adam Roach's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 02:49:04 -0000 Adam Roach has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone for the work that went into this revision. I agree with Ben's DISCUSS. In particular, I'm concerned by the text in §6.4, which indicates that the IANA registry will continue to point at RFC 7410 while the actual *meaning* of those values will mean something different than RFC 7410 defines. At a minimum, I think this document needs to add itself to the IANA table for those entries. But I think the cleanest approach -- and the one that is most consistent with the predecessor documents to this one -- is to copy the IANA entries forward with an indication that the values are already registered, but should be updated to point to this document. --------------------------------------------------------------------------- RFC 7208 is referred to by both [SPF] and [RFC7208], while only appearing as [SPF] in the references section. Consider rationalizing this. I recognize that the title was copied directly from RFC 7601, but please consider revising it to indicate that this document pertains to email. --------------------------------------------------------------------------- §1.5.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [KEYWORDS]. Please consider updating to match the boilerplate in RFC 8174. --------------------------------------------------------------------------- I have otherwise reviewed the diffs from RFC 7601, and find nothing to comment on. I echo Ben's comments thanking you for making limited changes to the document. From nobody Tue Nov 20 20:07:16 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B509130F2D; Tue, 20 Nov 2018 20:07:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , Barry Leiba , dmarc-chairs@ietf.org, tjw.ietf@gmail.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154277322456.29950.9124294245241485227.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 20:07:04 -0800 Archived-At: Subject: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 04:07:09 -0000 Adam Roach has entered the following ballot position for draft-ietf-dmarc-arc-protocol-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone for the work that went into this document. I'm excited by this experiment, and hope it eventually grows into something we can put on the standards track. --------------------------------------------------------------------------- id-nits reports: ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. --------------------------------------------------------------------------- §7.2: > remote-ip[1]=10.10.10.13 Please consider using an IPv6 address here. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ In any case, please use an address from the ranges reserved by either RFC 5737 or (preferably) RFC 3849. --------------------------------------------------------------------------- Appendix B: > Received: from example.org (example.org [208.69.40.157]) ... > Received: from segv.d1.example (segv.d1.example [72.52.75.15]) ... > Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) ... > [208.69.40.157]) by clochette.example.org with ESMTP id The two comments I made on §7.2 apply to these four IP addresses as well. From nobody Tue Nov 20 20:12:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B30B130EAA; Tue, 20 Nov 2018 20:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05AMCuUAMtFb; Tue, 20 Nov 2018 20:12:32 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0D9FE130DE4; Tue, 20 Nov 2018 20:12:32 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAL4CRWj026463 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Nov 2018 22:12:29 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at From: Adam Roach To: The IESG Cc: draft-ietf-dmarc-arc-protocol@ietf.org, tjw.ietf@gmail.com, dmarc@ietf.org, Barry Leiba , dmarc-chairs@ietf.org References: <154277322456.29950.9124294245241485227.idtracker@ietfa.amsl.com> Message-ID: <03df6fc1-f2f2-6f17-62af-896a141c6786@nostrum.com> Date: Tue, 20 Nov 2018 22:12:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <154277322456.29950.9124294245241485227.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 04:12:33 -0000 >> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) Oh, I missed this one -- the domain ISP.com is registered and in active use. Please consider changing to "isp.example" or similar. /a From nobody Tue Nov 20 23:24:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E8130EE9 for ; Tue, 20 Nov 2018 23:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=8ixz1XE2; dkim=pass (2048-bit key) header.d=kitterman.com header.b=RxM8y2+I 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 WsVULmhctXW5 for ; Tue, 20 Nov 2018 23:24:06 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E132127332 for ; Tue, 20 Nov 2018 23:24:06 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542785044; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=HvLzWwEKtvN4H7+z1wQTh0DDhsJXbd+IZiSWJKIpcxs=; b=8ixz1XE2RKkGiDmEbbKWncKsGfwN/S8PGrifpW5TI4yYtY/aqAT8rvTK p4QmITxQgGcy5nOEtnkV7mtuwgUMBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542785044; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=HvLzWwEKtvN4H7+z1wQTh0DDhsJXbd+IZiSWJKIpcxs=; b=RxM8y2+IJFIEsy4p3x+FWAseL5a2JIl0guPIn+BggcJQWnodtLBjZ8Si 7xyvUdxjTlmPx82A7e0AkVyCbgy170/HJ8XogFwEyULNgG10BTS6m392wM hB18esokCj+1/xcQ2BmljNLnfbvhusDPTvwx5RRgmHvO/xuLZZc6PwoU4k 1fldA5vwqELM4ljuCXPntMQr3z/e9EieQsGDeewbOSzAhLoB+4hkQPFEAE LPWMT1xb3cOpmnLK/0wrBXHE2x42vYUbWxldN/7RVqmYz62gtNfZVkWZFW mLri8OaokC0Ez4faqop185DnW+6mMF+6OU56wZgejnGrLbFOR/Qyqw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 92082C401F4 for ; Wed, 21 Nov 2018 01:24:04 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 21 Nov 2018 02:24:03 -0500 Message-ID: <17157118.LyGi52DVxo@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 07:24:09 -0000 On Tuesday, November 20, 2018 11:28:51 PM Scott Kitterman wrote: > On November 20, 2018 10:08:59 PM UTC, Barry Leiba wrote: > >> > I'd like to recommend that we (DMARC-WG) accept > > > >https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 > > > >> > into our work queue. It aligns with our charter already. > >> > >> I've seen three agreements and no objections, so here's an official > >> call for objections. If there are none by 16 November, we will > > > >create > > > >> draft-ietf-dmarc-psd-00 as a new working group item. > > > >Lots of discussion, and no objections to working on this and starting > >with Scott's draft. So, Scott, please post draft-ietf-dmarc-psd-00, > >and let's continue the discussion. > > Will do. I'll post it tonight or tomorrow. It's posted, queued for chair approval. Scott K From nobody Tue Nov 20 23:37:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223C9127332 for ; Tue, 20 Nov 2018 23:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=o+ac2pyw; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bcWK4Cmp 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 K9VlyZ_x1LIa for ; Tue, 20 Nov 2018 23:37:21 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0178A128A6E for ; Tue, 20 Nov 2018 23:37:21 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542785840; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=skdp2d4wvI+xfIb40t1zqpJS3EciuiEM969huTefmtE=; b=o+ac2pyw3MGkdcNG0cZHeLWKWOGBGVruZxneDkE3ioUCskQu1Qr+60Dd aHWkIvA27gfOkgEqACoFGbv5QwJ3DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542785840; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=skdp2d4wvI+xfIb40t1zqpJS3EciuiEM969huTefmtE=; b=bcWK4CmpI+rYhiiqc5O1VIiHU3cwPklXfTlwOW5dZxiGC7wOE+mijRqf QEFpcVu1HQxpkys+mi8xKSJsLAlSRq0ByPPEyk5RLDENa5SfobIRER6Acq vCWhWUPOmdN+WLxGFfsoyBK4xh0V2vLad7hY2jZqLFFI77RODCH0+2D1hV +clZ4HvXbutQzconM8ktZUnQaY23FADtqohEQg1tgQ2KW23lbtJNlBNtDv fw2NflkBpGt2pIsN75JUpqSfqPuCTAt0Ia0A20oHoMDrBOPNlZc0qQhvMQ nE34EeAwuXbr4FXbcEP9C6sj3Q32C/2YG9SJI6ei4G+BMz1764Jy8A== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2593FC401F4 for ; Wed, 21 Nov 2018 01:37:20 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 21 Nov 2018 02:37:19 -0500 Message-ID: <3881693.rR9BVk4Dlq@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 07:37:22 -0000 While we were discussing making draft-kitterman-dmarc-psd a working group item, the main discussion point was about the use of an IANA registry to identify participating public suffix domains. I think it would be useful to consider what problems we were trying to solve and see if there are alternative approaches that address those requirements. Also, while I think the discussion about a DMARC specific public boundary discovery mechanism was useful, and we should consider taking on that work, I think it's not closely coupled to Public Suffix Domains and should be discussed as a separate work item. Goals: 1. Minimize additional verifier burden for adding PSD DMARC support. Currently it requires consulting a locally stored, infrequently changing list and one additional DNS lookup only for participating public suffixes when there is no organizational domain DMARC record. 2. Externalize signaling about PSD participation. As discussed in the Privacy Considerations (section 4.1), we were concerned about the privacy implications of feedback on organizational domain traffic for organizational domains that don't participate in DMARC being inappropriately captured by public suffix operators. In order to avoid this, we identified criteria for which public suffixes PSD DMARC would be appropriate for and require an external review to ensure those criteria are met. No solution that's in DNS will address this part of the problem. I believe that if there are alternatives that support both these requirements, then they should be seriously considered, we just didn't think of one when working up the draft. Scott K From nobody Tue Nov 20 23:40:56 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DE6127332 for ; Tue, 20 Nov 2018 23:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=nXvNhfpY; dkim=pass (1024-bit key) header.d=kitterman.com header.b=nYhg/GUr 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 rfCRP4wmqh9A for ; Tue, 20 Nov 2018 23:40:53 -0800 (PST) Received: from relay02.kitterman.com (unknown [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF798130EDD for ; Tue, 20 Nov 2018 23:40:52 -0800 (PST) Received: from relay02.kitterman.com (localhost [127.0.0.1]) by relay02.kitterman.com (Postfix) with ESMTP id 9E0E07FECE for ; Wed, 21 Nov 2018 02:40:51 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=simple/relaxed; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201802; t=1542786051; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=N+z0rHyfk7q8LiYZYbX+3jdKqpJDzbJkJON3YPaEmLc=; b=nXvNhfpYqBNOEH84L4QBqdNUgpslmO+XSC+hFKb3e/2ExWMlTALt8J4l F2xvosNwSf2zHXRrFL3ucbY7wXQyCg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201802r1; t=1542786051; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=N+z0rHyfk7q8LiYZYbX+3jdKqpJDzbJkJON3YPaEmLc=; b=nYhg/GUr/lTZwKrE9hqkALwWJLg/86SKyfqivMwEn5H1GkfDe68QwZSL NERCPe1XH8Haf5pn4wKibJQg3fujNCVoTH0nUGz0Mm4lXaXqO1kZmTI/3H 8hgNnzmc2/qMM+e5q//S2yvynGM/wYaLeKJBIMmyHOG258PfEuQjG69a8= Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by relay02.kitterman.com (Postfix) with ESMTPS id 696287FC35 for ; Wed, 21 Nov 2018 02:40:51 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 21 Nov 2018 02:40:50 -0500 Message-ID: <2234898.PWReRsCt3X@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: Subject: [dmarc-ietf] Editor's Git Repository For draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 07:40:54 -0000 As I've been working on this draft, I've kept the work in git. Since it's a working group draft now, I've published the repository [1], for those the prefer those sorts of things. Scott K [1] https://github.com/kitterma/draft-ietf-dmarc-psd From nobody Tue Nov 20 23:43:41 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EB3130EE2 for ; Tue, 20 Nov 2018 23:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=0gb0Svg5; dkim=pass (2048-bit key) header.d=kitterman.com header.b=lGKBGAib 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 ealWRsrB-seu for ; Tue, 20 Nov 2018 23:43:38 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EC3130EDD for ; Tue, 20 Nov 2018 23:43:38 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542786217; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=JN2Be/4qIOFjsGKO6cqRA6wf5Kxvh7JflOut2FZ2KBY=; b=0gb0Svg5ep8XZq5mFqC3r1NlOv1czJ2kIGWnbgR/GAIDuvKdvOgEGxED SGEvZmYgiqo7phKWzlWhFzUH4LTZBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542786217; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=JN2Be/4qIOFjsGKO6cqRA6wf5Kxvh7JflOut2FZ2KBY=; b=lGKBGAibGec6VBXOHXZFfDDs+A7yoz35WeYrT1lj6/7VAQqaE4Y1Bc1p mS7pjjeO8ATbiq/dtWUMb4Cw2EpM2AF+6j6zxpaUxXMbb0n7ofS3CXevw0 IX4dUk8zHoj829tkxXY0utLEvuCpDjloHn2+WZz8UUTMAokfk5dQAH0TJE ZI21rWEaowLfx2w6hQt6PAfmwdqMI3POtXJCATsffeTVnIDG3YPbJWglHW y5wn6oKV/m9hHSV5s9iIP9Y/gAYYsUOFogUco9rQrodNxJdHs6sZHqHarV gwk9tps93oX7fN8RQHvgSYak8NpeWX/Qbj3bjSo2yGCCr3zCNywCwQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4A9C7C40229 for ; Wed, 21 Nov 2018 01:43:37 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 21 Nov 2018 02:43:37 -0500 Message-ID: <1752433.LPKdqegoTl@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] DMARC Specific Organizational Boundary Determination X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 07:43:39 -0000 While we were discussing the Public Suffix Domain DMARC draft, there seemed to be a fair amount of juice on this topic. I'd suggest further discussions in this thread. Scott K From nobody Wed Nov 21 00:54:34 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA6A12870E; Wed, 21 Nov 2018 00:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umcHyY_7FLQW; Wed, 21 Nov 2018 00:54:23 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 A97C81277D2; Wed, 21 Nov 2018 00:54:19 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id v5so3374108lfe.7; Wed, 21 Nov 2018 00:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rbpmGYlEjVkj+H5VQ20vBhL0HMdJCwW7keTbuSNIUOY=; b=mwVSdRicoghWeazSpOig8iP2ox7U7GFj/uRSO8eG/HkkO5Bh0UPPP3B8s0hQkh+Axx Zexo0DR4uIrpvS4FJ/ljReD4v21sJ4N+CiJwH4wT0O+GeImExIKcXu+abnMPmmLFC5rB St5wf8bZ6Ek58+QC6lQ1+hsNqaRfQzFXcnIwgu2A68H95yq2bns6oPc8mgdqMZCUJCkp zZq3fWPFKsz3OHtZpDl9VIZXQ/liCoPaGVtjd8BRpOoPFEHbhgL902RzFAk4DpZ8Hi0v aU1seEqaSFlEhYQDdFQSnYWUmPZXkmPgDsa7v7rrMB1b315xgigypKdtz1lpRY+hOTDS LeBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rbpmGYlEjVkj+H5VQ20vBhL0HMdJCwW7keTbuSNIUOY=; b=K59ebCrGufdiHnX1BzuAkgQKjW46nYZUBjXEFCt8XEKr+jiPW/BzwQSyN9+kpUA0F5 Q2jbELp4vmkUOitdvR2T5naRWrOLbSQruQY8uyLi8PcboWDNUXX7dz9BuERBVC4BbvgN rRgujM2tHBxr7z7orp/r1FQhHNM+p5Ls9rLzroZprZhxyQ3rA4WJhWKIuzSJs6CH3EfN MrrOd2vmwkdzZJwNNfpUu50466zkrIVxT9vgX4sbZmSjx5J94XnCgYt4JK9eklHgGsjU Q6w3uiu0aiV54g0fXpzKQODKu9T4mZ3SaRZWCCkFsm1dWUUevqsCbe1WhBZo1TV2OBqe +TRg== X-Gm-Message-State: AGRZ1gJw73/Se1xUg53V6561FF7jVEaMo+iHbtdzyiaeUYD4jK0eVdm1 HOBREkFmNGY/NL6oAYtZjDmFdKsdE78dEc6e9Fo= X-Google-Smtp-Source: AJdET5dAxc5l0Fs4yAQzoJ71FI1/9pefFFkkxsmOJ85r0kaY4p4tlpBdzEW21EO3jLcR1y9Zp3+oZ42uSDsd9RlX+x8= X-Received: by 2002:a19:c014:: with SMTP id q20mr2968224lff.16.1542790457693; Wed, 21 Nov 2018 00:54:17 -0800 (PST) MIME-Version: 1.0 References: <154273337967.18363.3557179370600723342.idtracker@ietfa.amsl.com> In-Reply-To: <154273337967.18363.3557179370600723342.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Wed, 21 Nov 2018 00:54:03 -0800 Message-ID: To: aretana.ietf@gmail.com Cc: The IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000319a97057b28e5bd" Archived-At: Subject: Re: [dmarc-ietf] Alvaro Retana's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 08:54:24 -0000 --000000000000319a97057b28e5bd Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 9:03 AM Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-dmarc-rfc7601bis-04: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't understand why this document is tagged as an Update to RFC7601 and > not > as Obsoleting it. This change was made between the -03 (which was the one > in > the IETF LC) and the -04 (current) versions. > There are some things in this document that are not copied from RFC7601, which means obsoleting RFC7601 rather than updating it would leave various IANA registry entries pointing at a dead document. I note that this point was brought up during both the AD Review [1] and the > IETF LC [2], which is why I'm not balloting DISCUSS. However, I think > that the > solution (Updating instead of Obsoleting) is not the correct one. > The change to "Updates" rather than "Obsoletes" was done as a result of those same review comments, most notably the second citation you offered. -MSK --000000000000319a97057b28e5bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 20, 2018 at 9:03 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
Alvaro Retana ha= s entered the following ballot position for
draft-ietf-dmarc-rfc7601bis-04: No Objection

----------------------------------------------------------------------<= br> COMMENT:
----------------------------------------------------------------------

I don't understand why this document is tagged as an Update to RFC7601 = and not
as Obsoleting it.=C2=A0 This change was made between the -03 (which was the= one in
the IETF LC) and the -04 (current) versions.

There are some things in this document that are not copied from RFC76= 01, which means obsoleting RFC7601 rather than updating it would leave vari= ous IANA registry entries pointing at a dead document.

=
I note that this point was brought up during= both the AD Review [1] and the
IETF LC [2], which is why I'm not balloting DISCUSS.=C2=A0 However, I t= hink that the
solution (Updating instead of Obsoleting) is not the correct one.

The change to "Updates" rather than &q= uot;Obsoletes" was done as a result of those same review comments, mos= t notably the second citation you offered.

-MS= K
--000000000000319a97057b28e5bd-- From nobody Wed Nov 21 03:23:31 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4691292AD; Wed, 21 Nov 2018 03:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=svSSGmDh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dVbSs0k2 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 bCoilyBmtMEk; Wed, 21 Nov 2018 03:23:20 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DB6128CE4; Wed, 21 Nov 2018 03:23:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2E00221EEB; Wed, 21 Nov 2018 06:23:19 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 21 Nov 2018 06:23:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:in-reply-to:subject:date; s=fm1; bh=siZ csgwDvCPvVLafEiwPhso4Q5GjvJcLH/FIQJ4O4dU=; b=svSSGmDhJ39Lm9OarSL xHzqFFoO31eqENy8BRyG8fzv2QdphZCqehsWGtAe1WY5A+p+EwNoAoTvvHwPy6A/ vRsVUeOyfj/9IQuTrNX0Lx/uODnYP64HFQz6F1xxVRj7e0wBvcRsgnreFeMhPp2v k7/M77haVbO1ZK5zSUIGgqXaaChq2lGNSqbQjq21JLjyYe+3lEwzjUkKFZa92Nyj WX0nfE9NDKjY02tzus+3CgooviUhgjSfvHvXZ/9yzP7ocGWGyizS5Zi2J2a1Et6H IVm/B4gGP4TjIPSydCYovuCvblrVZRjhnZzde49gx5oeGXNFIj3Kp6Lo5ibOZMeI /ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=siZcsgwDvCPvVLafEiwPhso4Q5GjvJcLH/FIQJ4O4 dU=; b=dVbSs0k2Zg33Xy7p6Eeqj13myEsLNtc+/qKtU0IfovlUc/FSHKWzajrcd b5AGIwvk5VNuB0d+Uw0ceQsUkyxo88Me70Q45TeQsLCEVwLCF5sS2MqGaKgyH76c qfHGVuVsZIP3c74IweZ5fJJ2j+2vdjC7lowpJUMT6Jv7dOm7DxcmktnDzixQwqkN ST6XxI8gaml2CckGOzOhEXXDCmfMMcVrkcfM1INVwMb/0grz0VgxxZuVYW4QWpcq ET+cpKN+y4B2HuIfZdIOLOfkDK1mUxCWGG5EgCErrQdLBeN+1oS6t1EobuwErgXC 2FtEv4LAR5HF9FCl0wSoV0klwX8tg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BB1B79E11A; Wed, 21 Nov 2018 06:23:18 -0500 (EST) Message-Id: <1542799398.1256451.1584341648.328E471E@webmail.messagingengine.com> From: Alexey Melnikov To: Barry Leiba , "Alvaro Retana (aretana)" Cc: dmarc@ietf.org, IESG , dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b References: <154273521107.29833.12344323303560312131.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 21 Nov 2018 11:23:18 +0000 Archived-At: Subject: Re: [dmarc-ietf] Alvaro Retana's No Objection on charter-ietf-dmarc-01-00: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 11:23:22 -0000 I applied these changes. Thank you, Barry! On Tue, Nov 20, 2018, at 8:44 PM, Barry Leiba wrote: > > The Phase I description is still included: "Draft description of > > interoperability issues for indirect mail..." Isn't that rfc7960? > > Yeh, we did this too quickly, I'm afraid. We should make a few other > minor changes to reflect the now-past: > > OLD > The existing DMARC base specification has been submitted as an > Independent Submission to become an Informational RFC. > NEW > The existing DMARC base specification is published as Informational > RFC 7489. > END > > OLD > Draft description of interoperability issues for indirect mail > flows and plausible methods for reducing them. > NEW > Draft description of interoperability issues for indirect mail > flows and plausible methods for reducing them. This is now > complete and published as RFC 7960. > END > > OLD > Specification of DMARC improvements to support indirect mail flows > NEW > Specification of DMARC improvements to support indirect mail flows; > this is now complete as draft-ietf-dmarc-arc-protocol > END > > Alexey, will you make those changes, please? > -- > Barry > From nobody Wed Nov 21 03:33:24 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0441512F1A2; Wed, 21 Nov 2018 03:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=POwTh2Iu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XWBF/Enm 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 xPAVOmR9NHgM; Wed, 21 Nov 2018 03:33:20 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4A41298C5; Wed, 21 Nov 2018 03:33:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3CFBA21F83; Wed, 21 Nov 2018 06:33:19 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 21 Nov 2018 06:33:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:date:subject:in-reply-to:references; s=fm1; bh=hIE TCaUKRYE2XxcprlI0mWEWopNZd4CY0VW25Y4RXQE=; b=POwTh2IuW16Oe6bMHK+ WwGwUoERNQQGNi2+0zJ5bgST3+9F7r5ntkyPjRhfQI1djA1jRM9cHa3dKUWLEmZZ jpgQ+oRPotW4fRwmc9+oQ6hXM92PiFHEGJZOPvqs2tof2r4ZeNhDfBeu89wMNEgO Q4W7rIIs9Pc4DfoNCVTwZDeEmTwTZnS0prFhVGhMz3Yq/t/mAmsOfIqagil4izCe g27O8afGxUZU8a/tKgxvNc9t+1jY0eNR8mV5G3sl9Fa+3nUZFGh57RomQmhl3W3X 0IFGlHFLD8s5gGWxphjATzk2DukQL/0Zjg2b7i3H8WTKscxDaD7SRr8z6SgJOui/ qdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=hIETCaUKRYE2XxcprlI0mWEWopNZd4CY0VW25Y4RX QE=; b=XWBF/EnmsRmzmw53fs6MycaYBkJK/mbOfy+dcYO8OpVBDgAQdA28cFJfv qF/32wGmOg5ZjXseR8oUddfvyuDI/SklIW2Hkl8WfLUhNM1Y8UMUHcbwUzXBm0Fr VnmmNTZNGrmDo+Y3ajP34Hpvb2NZO2qJjAEZkZAq03fjNMt2Z1x6rS8r1pH8Tdap U1wnEgWnUiA5WM41vlbNg2wIVJVoUDGyTmMypgS6j0B78Tcp2BAJPZwvotY+QY23 er+xEJkpPKzsTt6W5zcsbfkNFdf567+YDuit1apdKmeCovzSkivk/wxV325vDWLu AVMwvOux6wgL+kNzxAe80ePvHeNYQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F13E39E11A; Wed, 21 Nov 2018 06:33:18 -0500 (EST) Message-Id: <1542799998.1258867.1584343472.0FAA324C@webmail.messagingengine.com> From: Alexey Melnikov To: Alissa Cooper , The IESG Cc: dmarc@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b Date: Wed, 21 Nov 2018 11:33:18 +0000 In-Reply-To: <154274780493.29758.10284579659666859291.idtracker@ietfa.amsl.com> References: <154274780493.29758.10284579659666859291.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [dmarc-ietf] Alissa Cooper's Block on charter-ietf-dmarc-01-00: (with BLOCK and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 11:33:23 -0000 Hi Alissa, On Tue, Nov 20, 2018, at 9:03 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-dmarc-01-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-dmarc/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > (1) I realize this re-charter is motivated by a small update, but it seems > confusing to maintain text that is out-of-date when publishing a re-charter. > Someone already pointed out the issue with RFC 7960; I would also argue that > the following change is needed: > > OLD > The existing DMARC base specification has been submitted as an > Independent Submission to become an Informational RFC. > NEW > The existing DMARC base specification has been published as RFC 7489 in the > Independent Stream. Done. > (2) "Any issues related to the email authentication space ..." seems like a > rather broad charge. I understand the desire to work on > draft-levine-appsarea-eaiauth, but does that really justify this much wider > charter expansion? I feel like the point of the chartering process is to avoid > this kind of catch-all. I was trying to clarify that this only meant things like SPF/DKIM/DMARC, and not, for example, SASL. But it looks like my attempt wasn't successful. How about something like this: OLD: Any issues related to the email authentication space (SPF/DKIM/DMARC) that are large enough to mandate working group review but do not already fit under the charter of any existing working group can be considered for adoption by DMARC. NEW: Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC. ? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "2. Reviewing and improving the base DMARC specification > > The working group will not develop additional mail authentication > technologies, but may document authentication requirements that are > desirable." > > It's not clear how documenting authentication requirements implies directly > improving the base specification. From nobody Wed Nov 21 04:36:15 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E271271FF; Wed, 21 Nov 2018 04:36:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154280376729.11324.16984734283948990022@ietfa.amsl.com> Date: Wed, 21 Nov 2018 04:36:07 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 12:36:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-00.txt Pages : 9 Date : 2018-11-20 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-00 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 21 05:16:43 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2297C130DBE; Wed, 21 Nov 2018 05:16:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: dmarc-chairs@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154280620110.11494.7092897940395206804.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 05:16:41 -0800 Archived-At: Subject: [dmarc-ietf] Alissa Cooper's No Objection on charter-ietf-dmarc-01-02: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 13:16:41 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-dmarc-01-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my issues. From nobody Wed Nov 21 05:31:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0996D12F1A6 for ; Wed, 21 Nov 2018 05:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1de-elZbQlEZ for ; Wed, 21 Nov 2018 05:31:39 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 C5B6D1292AD for ; Wed, 21 Nov 2018 05:31:39 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id s22so4027031ioc.8 for ; Wed, 21 Nov 2018 05:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yi9MjJfOHqEa61q80GmHx66ZTh/azoyTGsPVHXP5dDo=; b=DIzNVQjp/XeAWO9FZoQgiJGZm/dLJDS6elF41pddeQGANxMihK3/mYVbCBuojnT8SN e4exVwV4uYM9dJjTc8RdqLx7shv+eDcbStgS725PyyR7L3dt+Iz9pR+OZaXhFkm6O1f6 Ck2wC2HqxZpIoPNZfh3qjm9vsmM4e2AmOSt0Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yi9MjJfOHqEa61q80GmHx66ZTh/azoyTGsPVHXP5dDo=; b=rTp+K7YetvsFGoyZAUFmP6a50lDj4CLu3Bgg6PT4FxSznUtjIU1izsbdYdkQ7/RjXz Xw+gGimN7v0u62XIdU4NQbhtEEqg+rvRVaVfadn6UxvWd8MQ2q8qf61LGGwCPwUE0RSO W/ce7gcEB33NtZC/d0fXpMaxHrO1QWbdYdKPes1tGHQDHpH8+vrpvGN1VYDsmsMBs++4 oyLMCVsRFZwSvF9kTQ2NM1Vp1ezbsQ0Nvu8RlhXLhu8VQQ0y5wX7bzyVzfXxoi4VVQzB nMdgOyYYsIr8OxtpTJTRsdZKIKnsDuABu5RE+tSEUxkAuUrBi8waG3PRN02qPO3carNb qJDA== X-Gm-Message-State: AA+aEWbBHzlWCL3ktta2pkEoTkLvmeDIn7t9nBTvhRhz2WTBSNAP6vTk jJ9hLZoGkvAN3BWRyt98yd74LvYF6iHIQgDPqZ3Txw== X-Google-Smtp-Source: AFSGD/VaKbL5RB4NbM5k7QNf0Dm9WXqFa91Ui5ARLlxlUrRXfaaTMeWKTFXtH+PEHlNG4oL0E7dqmyNKzEGS08l6Hlc= X-Received: by 2002:a5e:940c:: with SMTP id q12mr4259666ioj.228.1542807098874; Wed, 21 Nov 2018 05:31:38 -0800 (PST) MIME-Version: 1.0 References: <154277322456.29950.9124294245241485227.idtracker@ietfa.amsl.com> <03df6fc1-f2f2-6f17-62af-896a141c6786@nostrum.com> In-Reply-To: <03df6fc1-f2f2-6f17-62af-896a141c6786@nostrum.com> From: Kurt Andersen Date: Wed, 21 Nov 2018 05:31:20 -0800 Message-ID: To: Adam Roach Cc: draft-ietf-dmarc-arc-protocol@ietf.org, "dmarc@ietf.org" , Barry Leiba , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000163088057b2cc59e" Archived-At: Subject: Re: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 13:31:42 -0000 --000000000000163088057b2cc59e Content-Type: text/plain; charset="UTF-8" No objections to making the changes suggested by Adam. Will update pending AD direction. --Kurt On Tue, Nov 20, 2018 at 8:12 PM Adam Roach wrote: > > >> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) > > > Oh, I missed this one -- the domain ISP.com is registered and in active > use. Please consider changing to "isp.example" or similar. > > /a > > --000000000000163088057b2cc59e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No objections to making the changes suggested by Adam. Wil= l update pending AD direction.

--Kurt

On Tue, Nov 20, 2018 at 8:12 PM Ad= am Roach <adam@nostrum.com> w= rote:

>> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com<= /a> [w.x.y.z])


Oh, I missed this one -- the domain ISP.com is registered and in active use. Please consider changing to "isp.example" or similar.

/a

--000000000000163088057b2cc59e-- From nobody Wed Nov 21 05:58:39 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A936B126CB6; Wed, 21 Nov 2018 05:58:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, tim@dmarcian.com, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154280871768.11502.10059395575461348698.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 05:58:37 -0800 Archived-At: Subject: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 13:58:38 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmarc-rfc7601bis-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I also appreciate the efforts to reduce the diff between RFC 7601 and this document; it does help readability greatly. (I also support Ben's Discuss.) Unfortunately, it also can obscure some aspects where the text of the document did need to change as part of the update, but has not done so. For example, in Section 1: There exist registries for tokens used within this header field that refer to the specifications listed above. Section 6 describes the registries and their contents and specifies the process by which I don't think all of this is still present anymore. (If we were talking about registration policies, for example, we'd need an 8126 reference to replace the 5226 reference that was removed.) entries are added or updated. It also updates the existing contents to match the current states of these specifications. [We should double-check that everything that now allows EAI-formatted stuff is updated to also refer to this document from the IANA registry. On first glance this might include vbr.mv and vbr.md, but probably much more.] Don't we need to mention the updates (or obsoletes) relationship w.r.t. 7601 in the Abstract and Introduction? Section 4.1 has: MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" registry for such values as defined in Section 6. [...] This would seem to be an internal inconsistency, in that it seems to preclude any sort of experimental usage as described in Sections 2.7.x. In Section 2.3: Combinations of ptypes and properties are registered and described in the "Email Authentication Methods" registry, coupled with the authentication methods with which they are used. This is further described in Section 6. The relevant subsection of section 6 is a pretty empty stub now. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks you for updating in response to the secdir review! Are we now intending to restrict ourselvesto domain-based authentication schemes, having removed the disclaimer present in 7601 about the intent of the document? Section 1.1 In particular, the mere presence of this header field does not mean its contents are valid. Rather, the header field is reporting assertions made by one or more authentication schemes applied somewhere upstream. For an MUA or downstream filter to treat the assertions as actually valid, there must be an assessment of the trust relationship among such agents, the validating MTA, and the mechanism for conveying the information If this document is reporting assertions made upstream, we should say what kind of integrity and authenticity guarantees we do or do not provide for the reported information. (That is, "this header is transmitted in cleartext and could be modified by any agent along the delivery path", modulo the speculation we have later about potential ways to improve on that situation.) Section 1.6 goes a bit farther in this vein; maybe a forward reference is in order? Section 1.4 Isn't there a requirement to drop this header on the boundary, if there are any internal consumers? This is not a global requiremnet on existing servers, of course, but a deployment consideration that may affect existing servers. The end of section 7.1 seems to cover this situation pretty well, as well. Section 1.5.1 Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 1.5.4 o An "intermediate MTA" is any MTA that is not a delivery MTA and is also not the first MTA to handle the message. Is this intended to be global or within an ADMD? Section 2.2 I guess wouldn't be a whole lot of value in subtyping Keyword to have one symbol per registry, though the thought did occur to me while reading. Section 2.3 body: Information that was extracted from the body of the message. [...] interest. The "property" is an indication of where within the message body the extracted content was found, and can indicate an offset, identify a MIME part, etc. I'm not seeing where it's specified how the "property" gives an offset. I see other descriptions below about specific header fields and SMTP verbs and such, though. (Do we need to make it more clear that the "property" is defined within the context of the method?) The results for Sender ID are listed and described in Section 4.2 of [SENDERID], but for the purposes of this specification, the SPF definitions enumerated above are used instead. Also, [SENDERID] specifies result codes that use mixed case, but they are typically used all lowercase in this context. We use much stronger statements about lowercasing than "typically", elsewhere in this doc. Is this time different? Section 2.7.6 Experimental method identifiers MUST only be used within ADMDs that have explicitly consented to use them. These method identifiers and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use. [...] This part seems to value RFC status too highly -- earlier in the section we only say that they should "preferably" be published in an RFC. Section 2.7.7 Do we want to say that temporary registrations are available for wide-scale or long-running experiments? Section 3 of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. Does that in practice constrain "iprev" usage to within a single ADMD? Section 4.1 MUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments. When would I want to not ignore it? Section 5 I guess there's not really any special behavior to worry about when a message's path causes it to have two or more disjoint path segments in its delivery path that go through a given ADMD. (That is, delete on entry is still the right thing to do.) The last paragraph of Section 1.2 covers a related case, but I am thinking of something like a message that gets delivered to an expander and some of the recipients' delivery path would then return through a previously visited domain. For example, an MTA for example.com receiving a message MUST delete or otherwise obscure any instance of this header field bearing an authentication service identifier indicating that the header field was added within example.com prior to adding its own header fields. [...] Do we want to say anything about the authserv-id here? Section 6.4 I think we need to update the registry to also refer to this document. Appendix C 2. Border MTAs are more likely to have direct access to external sources of authentication or reputation information since modern MUAs are more likely to be heavily firewalled. [...] It's unclear that this statement about "modern MUAs" is still true, given the "zero trust" movement and such. From nobody Wed Nov 21 06:10:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C71C127133; Wed, 21 Nov 2018 06:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VmK7n7uP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jB5Ks7a5 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 xiZzaE9WY239; Wed, 21 Nov 2018 06:10:34 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57406126CB6; Wed, 21 Nov 2018 06:10:34 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 80C1521D8B; Wed, 21 Nov 2018 09:10:33 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 21 Nov 2018 09:10:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:date:references:in-reply-to; s=fm1; bh=R2a frsJy+FKX6cmV+BmEC3LDPLbennWQ0ftV9dFDIYo=; b=VmK7n7uPwNQ3RWfxe2S scAdBIjvfKF3Crqgo6qIV/T66zkkrtuBK1QvkClwyGKgV+Ulo8ayZpJ8TovHwQQG nsq7xR/Sx1C6lK9l0IwAKRkGHvtpCyW3/Md62PRnNth43Ts6Q2kKwiXpCS+TMSp5 5tO8u1SY2baLfMRxsHDE5TivqQWOuZsuVOnpPPmDwesCkNMZUhNEqDzFvoClOAtV poyaDVbACjGlRZzwkHFIZkSqP/UoqUlhiUxOmrHjhiS8aSX0PRo21St8RBIMUi14 Uvx0rFXDzSFtnugR0BVUpUtaEbSUdrqKT7qUJqMmzdfmkCmJ7HaaVF29oxRlkak0 /Ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=R2afrsJy+FKX6cmV+BmEC3LDPLbennWQ0ftV9dFDI Yo=; b=jB5Ks7a5mRVT11V7xDebxTDbniShhuicRiDA32voVqxVVbldlsG3LTfFR /arASiayXdkp48jqlxYzu/q9InkYDMFL1tLUCmKWBDUrh+IwWKrz3KUd+kziZUp1 RRl7QMlmBOJV61gXMApFD9S0Rue67OCErlnlm7HMO3E9M31iKovM90qrk5FTLeHU dLFXrSpLLZUYcJxZfELQUEmZ+eJsQ7DXc4ZNI2WlCFFy9hhi2DRtRWitew1mgE20 6zeOQI8bURx55qi2JxTCSY6V6tgfpCDFIzx3LVDBg5Lt8w7ziZ5/Z5a1y3d7W2uQ qIxePtVCMz73zO8oWNXhDA9xkYEnQ== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id ADF469E1EC; Wed, 21 Nov 2018 09:10:32 -0500 (EST) Message-Id: <1542809432.1302010.1584499040.1D94365D@webmail.messagingengine.com> From: Alexey Melnikov To: Kurt Andersen , Adam Roach Cc: draft-ietf-dmarc-arc-protocol@ietf.org, dmarc@ietf.org, Barry Leiba MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154280943213020102" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b Date: Wed, 21 Nov 2018 14:10:32 +0000 References: <154277322456.29950.9124294245241485227.idtracker@ietfa.amsl.com> <03df6fc1-f2f2-6f17-62af-896a141c6786@nostrum.com> In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] Adam Roach's Yes on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 14:10:36 -0000 This is a multi-part message in MIME format. --_----------=_154280943213020102 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Kurt, On Wed, Nov 21, 2018, at 1:31 PM, Kurt Andersen wrote: > No objections to making the changes suggested by Adam. Will update > pending AD direction.Please apply these changes to your copy, but wait before posting a new version. Best Regards, Alexey > > --Kurt > > On Tue, Nov 20, 2018 at 8:12 PM Adam Roach wrote: >> >> >> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com >> >> [w.x.y.z])>> >> >> Oh, I missed this one -- the domain ISP.com is registered and in >> active>> use. Please consider changing to "isp.example" or similar. >> >> /a >> --_----------=_154280943213020102 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Kurt,

On Wed, Nov 21, 2018, at 1:31 PM, Kurt Andersen wrote:
No objections to making the changes suggested by Adam. Will update pending AD direction.
Please apply these changes to your copy, but wait before posting a new version.

Best Regards,
Alexey

--Kurt


>> Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])


Oh, I missed this one -- the domain ISP.com is registered and in active
use. Please consider changing to "isp.example" or similar.

/a


--_----------=_154280943213020102-- From nobody Wed Nov 21 06:16:51 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5113130DFE; Wed, 21 Nov 2018 06:16:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: tjw.ietf@gmail.com, Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , dmarc@ietf.org, dmarc-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154280980293.11332.11492838987199614779.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 06:16:42 -0800 Archived-At: Subject: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 14:16:43 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dmarc-arc-protocol-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3829 These would be DISCUSS-worthy comments but this is an Experimental document so I am just making them comments. IMPORTANT S 9. > handlers for a message. This record may include Personally > Identifiable Information such as IP address(es) and domain names. > Such information is also included in existing non-ARC related header > fields such as the "Received" header fields. > > 9. Security Considerations You need to document what the semantics of a received message with an ARC Chain is. As I understand it, it's that the highest-numbered instance N vouches that: It processed a message with this body, a given authres, and ARC chains 1..N-1. And then instance N-1 vouches that it received a message with a given authres, and ARC chains 1..N-2, and so on. Is that correct? COMMENTS S 4.1.3. > > To preserve the ability to verify the integrity of a message, the > signature of the AMS header field SHOULD include any DKIM-Signature > header fields already present in the message. > > 4.1.3. ARC-Seal (AS) It would be useful to state the rationale here for why you have separate signatures for headers and body. S 7.2. > Through the collection of ARC-related data, an ADMD can identify > handling paths that have broken authentication. > > An Authenticated Received Chain allows an Internet Mail Handler to > potentially base decisions of message disposition on authentication > assessments provided by different ADMDs. "potentially base" seems pretty handwavy. As below, I think you need to provide some guidance about what on would actually do. From nobody Wed Nov 21 08:04:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769FB130DEE for ; Wed, 21 Nov 2018 08:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhwxYu0xQUXH for ; Wed, 21 Nov 2018 08:04:33 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 7C0DD130DCA for ; Wed, 21 Nov 2018 08:04:33 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id a185so9614584itc.0 for ; Wed, 21 Nov 2018 08:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dd20B2CPOcQ8Sn2j8qrQRoP4z6xDhIO0EgUe3Krw+VI=; b=Q3Ae5UCyfz9QSHETExEyTDmp8Pfcb4A3FPkTjmeedAL3wab1kiUEOCCKJOEqGnqPw0 6JorJgt2zMacnNR+fJnKCp4OzXaKXAenaShRWUQ70uv1iGpryRU31vbjgpbT4Wo6GGvL BtsAwZq8vCPJXXhpaG2ZGyoIlxgaC/U6872RE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dd20B2CPOcQ8Sn2j8qrQRoP4z6xDhIO0EgUe3Krw+VI=; b=tsLkKI5BFIj/S2Lnm7ZJy6RJ4dT42Hhcvz9GwIKs+D30H2HYi2N/1tRkWoTnV34lIc 9XhW2HkWRYOCFSf5Q61TadJTCY6a1DdlVW67g6Nnmg+oQ/T+ds6Qs6mIsEDlNE64+6YO Q8xkNUegoa2yrIxov96zPpmMcOP8V0cQ6llQM4nD5j4yHHAWmxF+09Z4KDIWONrStNmY T0DOMTBnzICueIOi7sOyjknOQd9VEUaX2Ks6DKZFm/sOfl3Ks1xsSVKc7W4NCYZDWjij ICuHBGkaGRrI0VcmUOkVjEetdfTVSiodL8Ez864QZyRK49rLOOaXkzT1oHasAz7nYCaf sisw== X-Gm-Message-State: AGRZ1gKBvm62g41ocCg1Wje2Xx3AquDHA2oW85EEvUrZ4wq+KHcnSCss qrE9a4zw3k/w7XalGt+4AtQU8jiJTfIt2OZp1N4jLQ== X-Google-Smtp-Source: AJdET5eUmCvFHOzp7ZySG3T2QuDJWJNIoR5F3ZW40kdFULe+3q5adT+tyV3pxCkh3W0uTZMDxHTg2jIsDhPhJW3Embg= X-Received: by 2002:a24:6747:: with SMTP id u68-v6mr6291781itc.173.1542816272480; Wed, 21 Nov 2018 08:04:32 -0800 (PST) MIME-Version: 1.0 References: <154280980293.11332.11492838987199614779.idtracker@ietfa.amsl.com> In-Reply-To: <154280980293.11332.11492838987199614779.idtracker@ietfa.amsl.com> From: Kurt Andersen Date: Wed, 21 Nov 2018 08:04:13 -0800 Message-ID: To: ekr@rtfm.com Cc: iesg@ietf.org, Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, tjw ietf , "dmarc@ietf.org" , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e02d8c057b2ee7cf" Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 16:04:36 -0000 --000000000000e02d8c057b2ee7cf Content-Type: text/plain; charset="UTF-8" On Wed, Nov 21, 2018 at 6:16 AM Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-dmarc-arc-protocol-21: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3829 > > > These would be DISCUSS-worthy comments but this is an Experimental > document so I am just making them comments. > > IMPORTANT > S 9. > > handlers for a message. This record may include Personally > > Identifiable Information such as IP address(es) and domain names. > > Such information is also included in existing non-ARC related header > > fields such as the "Received" header fields. > > > > 9. Security Considerations > > You need to document what the semantics of a received message with an > ARC Chain is. As I understand it, it's that the highest-numbered > instance N vouches that: > It processed a message with this body, a given authres, and ARC chains > 1..N-1. And then instance N-1 vouches that it received a message with > a given authres, and ARC chains 1..N-2, and so on. Is that correct? > Yes, that is correct, as long as you meant authres-payload. This was stated earlier in the document, does it need to be repeated in section 9? > COMMENTS > S 4.1.3. > > > > To preserve the ability to verify the integrity of a message, the > > signature of the AMS header field SHOULD include any DKIM-Signature > > header fields already present in the message. > > > > 4.1.3. ARC-Seal (AS) > > It would be useful to state the rationale here for why you have > separate signatures for headers and body. > They are not separate signatures for header and body. They are separate signatures for ARC chain as an entity vs. the normal DKIM signing scope of headers (excluding ARC) & body. > S 7.2. > > Through the collection of ARC-related data, an ADMD can identify > > handling paths that have broken authentication. > > > > An Authenticated Received Chain allows an Internet Mail Handler to > > potentially base decisions of message disposition on authentication > > assessments provided by different ADMDs. > > "potentially base" seems pretty handwavy. As below, I think you need > to provide some guidance about what on would actually do. > Receivers are always free to do whatever they choose, including, in many cases, completely ignoring information that is made available. We are writing a separate document within the DMARC WG to cover usage recommendations pertaining to ARC. --Kurt Andersen --000000000000e02d8c057b2ee7cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 21= , 2018 at 6:16 AM Eric Rescorla <ekr@rtf= m.com> wrote:
Eric Rescorla = has entered the following ballot position for
draft-ietf-dmarc-arc-protocol-21: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3829

These would be DISCUSS-worthy comments but this is an Experimental
document so I am just making them comments.

IMPORTANT
S 9.
>=C2=A0 =C2=A0 =C2=A0 handlers for a message.=C2=A0 This record may incl= ude Personally
>=C2=A0 =C2=A0 =C2=A0 Identifiable Information such as IP address(es) an= d domain names.
>=C2=A0 =C2=A0 =C2=A0 Such information is also included in existing non-= ARC related header
>=C2=A0 =C2=A0 =C2=A0 fields such as the "Received" header fie= lds.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A09.=C2=A0 Security Considerations

You need to document what the semantics of a received message with an
ARC Chain is. As I understand it, it's that the highest-numbered
instance N vouches that:
It processed a message with this body, a given authres, and ARC chains
1..N-1. And then instance N-1 vouches that it received a message with
a given authres, and ARC chains 1..N-2, and so on. Is that correct?

Yes, that is correct, as long as you meant aut= hres-payload. This was stated earlier in the document, does it need to be r= epeated in section 9?
=C2=A0
= COMMENTS
S 4.1.3.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 To preserve the ability to verify the integrity of= a message, the
>=C2=A0 =C2=A0 =C2=A0 signature of the AMS header field SHOULD include a= ny DKIM-Signature
>=C2=A0 =C2=A0 =C2=A0 header fields already present in the message.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A04.1.3.=C2=A0 ARC-Seal (AS)

It would be useful to state the rationale here for why you have
separate signatures for headers and body.

They are not separate signatures for header and body. They are separate = signatures for ARC chain as an entity vs. the normal DKIM signing scope of = headers (excluding ARC) & body.=C2=A0
=C2=A0
S 7.2.
>=C2=A0 =C2=A0 =C2=A0 Through the collection of ARC-related data, an ADM= D can identify
>=C2=A0 =C2=A0 =C2=A0 handling paths that have broken authentication. >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 An Authenticated Received Chain allows an Internet= Mail Handler to
>=C2=A0 =C2=A0 =C2=A0 potentially base decisions of message disposition = on authentication
>=C2=A0 =C2=A0 =C2=A0 assessments provided by different ADMDs.

"potentially base" seems pretty handwavy. As below, I think you n= eed
to provide some guidance about what on would actually do.
<= div>
Receivers are always free to do whatever they choose, in= cluding, in many cases, completely ignoring information that is made availa= ble. We are writing a separate document within the DMARC WG to cover usage = recommendations pertaining to ARC.=C2=A0

--Kurt An= dersen
--000000000000e02d8c057b2ee7cf-- From nobody Wed Nov 21 08:11:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B2130DF1 for ; Wed, 21 Nov 2018 08:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxxokGMzbCmI for ; Wed, 21 Nov 2018 08:11:16 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 CE6E0130DEE for ; Wed, 21 Nov 2018 08:11:15 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id b20so4361130lfa.12 for ; Wed, 21 Nov 2018 08:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DX+x41xKWkxZLbozJa7rHJqUxV4jdt4i5ubVF1Fu4jA=; b=wGmjZ3jKedTADr/oJSBMhHchaNUxvgBmXOu2DLzM5LqoTAffQg5jP9bXOmjQX9izmu 9OYaYkCi/pB17dTaSYZHc6ap4i5LCDHCqre/9lV/JZ9HJVpoA0dRsY8L/QkD3LUnSvfQ fRxCAdAJVc0NOnaMpKF3jd3sIgGV8hrZQzuIC0EpDfuHFfKxogEviohmFK/LZAL3Xo79 9UKBMprCg5v22+64K4Ws25Kew0ianh+OUgUU1hFx1jl5799bX7qTi/JXr0wtNH0RR/8v zXGsHwXkizmUdPOAfm6sSCszrtIxf6wlEOti8Cc9FrjlhslU/3SKWe+IjkaZTOmX7CdA gYqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DX+x41xKWkxZLbozJa7rHJqUxV4jdt4i5ubVF1Fu4jA=; b=JRA9cdYJpsYi4vORWEgZ7eO71T6/dxXxY9WJHH7JMiuCEpTCbxC6vBZYexaXqp+1AQ HLf64pJlcNE8Alj8zEiflygd6cpSMOwCuyX2aHHn7U0YARwQIkA4bNVDd7yiaD1MZNpE OazHEC89w6c8ggB6G+e9myo6H8Ujrzs/T6AkXXjBJUFzydGmPnkw3cbdHZnkdWttxtuF V+LkZkZKdX8hzgGX2ZcKcjVSUg8qnGc0SlyRpxmtXZr89dEcJgajv459eDgAwlwLsQL1 OLwYN6zm16rkOj9XeuzjeezJoy6cnMwcN0WYgsilTK5B+niKsmZdoznQmVvF7dhaT8oT bn3g== X-Gm-Message-State: AGRZ1gLZ/wFCUG8qgzG/xaNoW9hvjYrdP6Jto6RqVBdRdykDKfzZIkDB 71g6kYyOHHqbPGcI+wWBLwC7aWw9qNW0bJr27+RfPg== X-Google-Smtp-Source: AJdET5fXJyoMib9mqR7/nUxW0SX1S11uUvRGDA0uHRfiSKTkYr/v4AldWySIBJtjfZz4Li1SwHRXTwEL5MMT6ZdFPJo= X-Received: by 2002:a19:41c4:: with SMTP id o187mr4393644lfa.32.1542816673907; Wed, 21 Nov 2018 08:11:13 -0800 (PST) MIME-Version: 1.0 References: <154280980293.11332.11492838987199614779.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Wed, 21 Nov 2018 08:10:37 -0800 Message-ID: To: kurta@drkurt.com Cc: IESG , Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , dmarc@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000cd5c39057b2effdd" Archived-At: Subject: Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-arc-protocol-21: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 16:11:19 -0000 --000000000000cd5c39057b2effdd Content-Type: text/plain; charset="UTF-8" On Wed, Nov 21, 2018 at 8:04 AM Kurt Andersen wrote: > On Wed, Nov 21, 2018 at 6:16 AM Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-dmarc-arc-protocol-21: No Objection >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Rich version of this review at: >> https://mozphab-ietf.devsvcdev.mozaws.net/D3829 >> >> >> These would be DISCUSS-worthy comments but this is an Experimental >> document so I am just making them comments. >> >> IMPORTANT >> S 9. >> > handlers for a message. This record may include Personally >> > Identifiable Information such as IP address(es) and domain names. >> > Such information is also included in existing non-ARC related >> header >> > fields such as the "Received" header fields. >> > >> > 9. Security Considerations >> >> You need to document what the semantics of a received message with an >> ARC Chain is. As I understand it, it's that the highest-numbered >> instance N vouches that: >> It processed a message with this body, a given authres, and ARC chains >> 1..N-1. And then instance N-1 vouches that it received a message with >> a given authres, and ARC chains 1..N-2, and so on. Is that correct? >> > > Yes, that is correct, as long as you meant authres-payload. This was > stated earlier in the document, does it need to be repeated in section 9? > Where is it stated? > COMMENTS >> S 4.1.3. >> > >> > To preserve the ability to verify the integrity of a message, the >> > signature of the AMS header field SHOULD include any DKIM-Signature >> > header fields already present in the message. >> > >> > 4.1.3. ARC-Seal (AS) >> >> It would be useful to state the rationale here for why you have >> separate signatures for headers and body. >> > > They are not separate signatures for header and body. They are separate > signatures for ARC chain as an entity vs. the normal DKIM signing scope of > headers (excluding ARC) & body. > OK, so that would be useful to state. > S 7.2. >> > Through the collection of ARC-related data, an ADMD can identify >> > handling paths that have broken authentication. >> > >> > An Authenticated Received Chain allows an Internet Mail Handler to >> > potentially base decisions of message disposition on authentication >> > assessments provided by different ADMDs. >> >> "potentially base" seems pretty handwavy. As below, I think you need >> to provide some guidance about what on would actually do. >> > > Receivers are always free to do whatever they choose, including, > That's theoretically true in all protocols and yet we routinely tell people how they need to behave to be conformant. My problem here is that this document needs to provide sufficient information to the reader to understand how to interpret the ARC data and see what to do about that. -Ekr in many cases, completely ignoring information that is made available. We > are writing a separate document within the DMARC WG to cover usage > recommendations pertaining to ARC. > > > --Kurt Andersen > --000000000000cd5c39057b2effdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Nov 21, 2018 at 8:04 AM Kurt Andersen <kurta@drkurt.com> wrote:
On Wed, Nov = 21, 2018 at 6:16 AM Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-dmarc-arc-protocol-21: No Objection

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3829

These would be DISCUSS-worthy comments but this is an Experimental
document so I am just making them comments.

IMPORTANT
S 9.
>=C2=A0 =C2=A0 =C2=A0 handlers for a message.=C2=A0 This record may incl= ude Personally
>=C2=A0 =C2=A0 =C2=A0 Identifiable Information such as IP address(es) an= d domain names.
>=C2=A0 =C2=A0 =C2=A0 Such information is also included in existing non-= ARC related header
>=C2=A0 =C2=A0 =C2=A0 fields such as the "Received" header fie= lds.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A09.=C2=A0 Security Considerations

You need to document what the semantics of a received message with an
ARC Chain is. As I understand it, it's that the highest-numbered
instance N vouches that:
It processed a message with this body, a given authres, and ARC chains
1..N-1. And then instance N-1 vouches that it received a message with
a given authres, and ARC chains 1..N-2, and so on. Is that correct?

Yes, that is correct, as long as you meant aut= hres-payload. This was stated earlier in the document, does it need to be r= epeated in section 9?

Whe= re is it stated?

=C2=A0
COMMENTS
S 4.1.3.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 To preserve the ability to verify the integrity of= a message, the
>=C2=A0 =C2=A0 =C2=A0 signature of the AMS header field SHOULD include a= ny DKIM-Signature
>=C2=A0 =C2=A0 =C2=A0 header fields already present in the message.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A04.1.3.=C2=A0 ARC-Seal (AS)

It would be useful to state the rationale here for why you have
separate signatures for headers and body.

They are not separate signatures for header and body. They are separate = signatures for ARC chain as an entity vs. the normal DKIM signing scope of = headers (excluding ARC) & body.=C2=A0

OK, so that would be useful to state.

=C2=A0
S 7.2.
>=C2=A0 =C2=A0 =C2=A0 Through the collection of ARC-related data, an ADM= D can identify
>=C2=A0 =C2=A0 =C2=A0 handling paths that have broken authentication. >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 An Authenticated Received Chain allows an Internet= Mail Handler to
>=C2=A0 =C2=A0 =C2=A0 potentially base decisions of message disposition = on authentication
>=C2=A0 =C2=A0 =C2=A0 assessments provided by different ADMDs.

"potentially base" seems pretty handwavy. As below, I think you n= eed
to provide some guidance about what on would actually do.
<= div>
Receivers are always free to do whatever they choose, in= cluding,

That's theor= etically true in all protocols and yet we routinely tell people how they ne= ed to behave to be conformant. My problem here is that this document needs = to provide sufficient information to the reader to understand how to interp= ret the ARC data and see what to do about that.

-Ekr


<= div dir=3D"ltr">
in many cases, completely = ignoring information that is made available. We are writing a separate docu= ment within the DMARC WG to cover usage recommendations pertaining to ARC.= =C2=A0

=C2=A0
<= br>
--Kurt Andersen
--000000000000cd5c39057b2effdd-- From nobody Wed Nov 21 13:35:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242F6130EF3; Wed, 21 Nov 2018 13:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 zskb9dqWf1nh; Wed, 21 Nov 2018 13:35:21 -0800 (PST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 B1207130EB0; Wed, 21 Nov 2018 13:35:20 -0800 (PST) Received: by mail-io1-f48.google.com with SMTP id f6so5168410iob.1; Wed, 21 Nov 2018 13:35:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T/2iWcNF7FL+6Lvzl46pUodERTrhGrlicy3J9u8SUI8=; b=at+QNOijloZTHMb0e7tcPEdcC10dCbMXDiwsAOkgJHxMip6v5E7pGYUvBLbR/HOK4a sVwCYqfgCYuWMiVThKmh/cmXo55UrZzy86zBRiSMBVROSyz5dvbt/ogqpCBVkLXdNlHz 1xRQYMUx1NADk7kvZynjudXsFDvXCDj5LbFG9/8rOkeH80iq8Kfg8gRQuQRhRhFiHmzx Udiwj0VyDx5ngrrg4gfsS5IJVHuDvoDYx8nbbvB7N0QlD/fSWSudR/8sveCVpIB8nwHe Cy3hWNdJDgzFp6vibroi3D93eqp/yyKXHrV6NdGoeHj6tDX9eHBsZCJKrpJaHcpZRgED eiDQ== X-Gm-Message-State: AA+aEWaqUA5HLPU2BaXmw0etFWsFUkFeJdNgnHvbdMUS36yywCMriBpk XoXTqyBX4jjXGdRfcomHcpZQs9NyDXCQU+YHy6DX+A== X-Google-Smtp-Source: AFSGD/XWKXG1papqsuo7ANycegkAxv2kfyyul/LDXoNG+6HcPzi/epy6D5dzuKDoHK5+mGzrx5MbhZz9/SGvY0h57PE= X-Received: by 2002:a6b:2c17:: with SMTP id s23mr6342514ios.76.1542836119665; Wed, 21 Nov 2018 13:35:19 -0800 (PST) MIME-Version: 1.0 References: <154276546748.29873.13968026001049295698.idtracker@ietfa.amsl.com> In-Reply-To: <154276546748.29873.13968026001049295698.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 21 Nov 2018 16:35:08 -0500 Message-ID: To: Ben Campbell Cc: IESG , dmarc-chairs@ietf.org, dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's No Objection on charter-ietf-dmarc-01-00: (with COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 21:35:31 -0000 > I _think_ this section 4 is about MTA-MTA authentication, right? For example, > s/mime or other e2e signature enhancements would not be in scope, would they? > How about new user-to-MUA authentication methods? It's unfortunate that we've settle on the term "email authentication" to refer to what is actually much narrower than that, but, alas, that's the terminology that's used. What we mean by the term is more like "validation of the email sending domain", which isn't what we would call "authentication" in other security contexts. So, no, anything dealing with s/mime or email content signatures are not in the scope we're talking about here. Barry From nobody Wed Nov 21 13:39:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3366B12F295; Wed, 21 Nov 2018 13:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 heCl0Z4xB5dS; Wed, 21 Nov 2018 13:39:45 -0800 (PST) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (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 57B6112D4E9; Wed, 21 Nov 2018 13:39:45 -0800 (PST) Received: by mail-it1-f171.google.com with SMTP id x19so11178039itl.1; Wed, 21 Nov 2018 13:39:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FMVi1WOZurH850LcYQdN+Xo0yilXadqM44Q4CDxqT+s=; b=eM0tIi/d5dMXNe9mav6JqJW48Eg5pJF5NOUUSb2d5e3RZuUUU+QoZIBX/1Ozk56pUi WTVZ8AjeStJqNQrF11jHpsp/PjIQ7rkRZK5ybNWpDcqEZqSFc855MWQVdvsqyK6Gn31y g8yJIs4F3g4/MbjqnbldFdfSKZrrbR2YKUo1LNvdkPs6t6hHPa1bW3c3RgnrEXPyyYjV pV4m2bsW6Yn3DV2oVpQ498HP8szshJIqKCLW7L+1MTSNj3wl28InJHpompleSu83z3/P FbInNaESoaZSuximCzHMFGyE69Aw7oSQSP67dNzCcp+SEAXqAy4U4y2bL+TXT9VPytrO 4ePA== X-Gm-Message-State: AA+aEWZM5In/uPg4DW45BDTCTTJfTmIBvfaqEOdRHn63/5qIZY/teozc R8+dOY0LnLyH2Aw4xVOt4ono4ngnLKMNekaLiciK9g== X-Google-Smtp-Source: AFSGD/VoH877cqRcJhrH/2cqWsJTCe+3yF4rAEnt4IU5b5vTbAQhJ9reGbOERbGiGbpWbXvzWWojE3+6wZ978ExEHQ8= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr7077878itf.84.1542836384183; Wed, 21 Nov 2018 13:39:44 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> In-Reply-To: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 21 Nov 2018 16:39:33 -0500 Message-ID: To: Ben Campbell Cc: IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, Tim Draegen , dmarc-chairs@ietf.org, dmarc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2018 21:39:47 -0000 I actually agree with this: I think the better answer is to go back to "obsoletes" and to have this document include the details of what was put in the registries before. But the working group decided to do it the other way, and there's been criticism in the past of ADs (and, so, by extension, chairs) picking on this sort of stuff, so I decided to let it go. I'll let the IESG sort this one out, but I'll go on record as saying what I think the better way to handle it is. That said, I don't think it's a huge deal either way. Barry On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-dmarc-rfc7601bis-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is mainly a process discuss. I share Alvaro's concern about this being > marked as "updating" RFC7601, when it seem like a full replacement. I'm > promoting it to a DISCUSS because I think this needs to be resolved before > publication. > > The current structure will make it very difficult for readers to figure out > which parts of each doc they need to worry about. I think it needs to either go > back to "obsoleting" 7601, or it needs to be recast to just talk about the > changes. Note that if the former path is chosen, the IANA considerations in > 7601 will need to be copied forward. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary > changes. That makes the diff tools much more useful than they are for bis > drafts that make wholesale organization and stylistic changes. > > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Wed Nov 21 14:59:22 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D20D130DD3; Wed, 21 Nov 2018 14:59:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154284116005.5109.1903253153430271421.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 14:59:20 -0800 Archived-At: Subject: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 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, 21 Nov 2018 22:59:20 -0000 The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-12-03. Domain-based Message Authentication, Reporting & Conformance (dmarc) ----------------------------------------------------------------------- Current status: Active WG Chairs: Barry Leiba Ned Freed Tim Draegen Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: Address: dmarc@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Group page: https://datatracker.ietf.org/group/dmarc/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification is published as Informational RFC 7489 in the Independent Stream. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue three tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options 4. Related work Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC Working Group after consultation with the responsible AD. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. Any such work needs to carefully consider interoperability implications. Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. Phase II: Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol (ARC). Draft Guide on DMARC Usage. Phase III: Review and refinement of the DMARC specification. Completion of Guide on DMARC and ARC Usage. References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Milestones: Done - Complete Authenticated Received Chain (ARC) protocol spec Jan 2019 - Complete EAI update to SPF/DKIM/DMARC Feb 2019 - Complete Authenticated Received Chain (ARC) usage recommendations From nobody Wed Nov 21 17:02:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0544130DD4 for ; Wed, 21 Nov 2018 17:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EArn0iJPrNrG for ; Wed, 21 Nov 2018 17:02:39 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 5A6C6130E52 for ; Wed, 21 Nov 2018 17:02:39 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id r200so5429927iod.11 for ; Wed, 21 Nov 2018 17:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l3DnjmMLfwS0DDRn98rkDCJiB6R/V1kvIUJ1Yy/+14M=; b=dov2g55jQx98+LUnLHin+hoBIRENhXYsMHBpBoSKyNePMEsNcbKJ69AqhzSgj6/3gW /egi6kf7JMNJvl1QngS/rWPDoEacv0IaLVPeQ8iV7LSgOsxL//t/BJGk3OH5r7KyBs6P 60cfLX7OEWptAUQ4Z7frKcBetdVIrcIulTR2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l3DnjmMLfwS0DDRn98rkDCJiB6R/V1kvIUJ1Yy/+14M=; b=mENlTNsiJFLxxNI2Na1URqnTji4zrAPmgRUeJbGvXfTv1iKsZgZTeeId+3USbCJuCh 8x6t1VRsAjhx404ALuXNaA3uTXKL5cEoU9dMNFfD6InjJf/eC0TTU0dVsMFcU+NHeiGK xHbaX9nbEPkEtlQPhzjHplNYAb04IYU11pj2vVGxkUEKUspsKjh5ZrmEkmTTDAslWyd7 Vn0h5zI/19Yr/Y7PU+4qMJLs0jTYMfS9UOyQEdhRqckfl8uBbeMDunLZvah/FPkItx6w XzcX6afFYqa01uzFiV/tFI3B69ONR8YR1tXKNrlK/bnbC/Xe2JsLqyQOdWJYR5tLjcAh N9bw== X-Gm-Message-State: AA+aEWbCFhohSYoO25/q6hDBMOakuLi6qY8rahhaGCJ/loCp80ZGNTqR qkkOAM77qB5m4Pn32ZJsestNjKOzIhG4saU5AKuaX3bnsQkMuQ== X-Google-Smtp-Source: AFSGD/XmMCR7+N9+Auykt1U+peQc3VW7qjr7c+slXSTY/rfFwb72cuLOJqdnKL59KtWkXJxvkLXX9BVWu9TreQLB/SE= X-Received: by 2002:a6b:e301:: with SMTP id u1mr6853943ioc.196.1542848558439; Wed, 21 Nov 2018 17:02:38 -0800 (PST) MIME-Version: 1.0 References: <154284116005.5109.1903253153430271421.idtracker@ietfa.amsl.com> In-Reply-To: <154284116005.5109.1903253153430271421.idtracker@ietfa.amsl.com> From: "Kurt Andersen (b)" Date: Wed, 21 Nov 2018 17:02:19 -0800 Message-ID: To: iesg-secretary@ietf.org Cc: ietf-announce@ietf.org, "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000044b616057b366c84" Archived-At: Subject: Re: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Nov 2018 01:02:42 -0000 --00000000000044b616057b366c84 Content-Type: text/plain; charset="UTF-8" Minor nit noted below, otherwise in favor of the change from three to four work areas. --Kurt Andersen On Wed, Nov 21, 2018 at 2:59 PM The IESG wrote: > The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG > in the Applications and Real-Time Area of the IETF is undergoing > rechartering. The IESG has not made any determination yet. The following > draft charter was submitted, and is provided for informational purposes > only. > Please send your comments to the IESG mailing list (iesg@ietf.org) by > 2018-12-03. > > > Working group activities will pursue three tracks: > Should now be "...pursue four tracks" or "...pursue three tracks and necessary supporting work". 1. Addressing the issues with indirect mail flows > > > 2. Reviewing and improving the base DMARC specification > > > 3. DMARC Usage > > > 4. Related work > --00000000000044b616057b366c84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Minor nit noted below, otherwise in favor of the change fr= om three to four work areas.

--Kurt Andersen

On Wed, Nov 21, 2018 at 2:59 PM T= he IESG <iesg-secretary@ietf.= org> wrote:
The Domain-based= Message Authentication, Reporting & Conformance (dmarc) WG
in the Applications and Real-Time Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes onl= y.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
2018-12-03.

<elided>=C2=A0
=C2=A0 =C2=A0Working group activities will pursue three tracks:
=C2=A0
Should now be "...pursue four tracks" = or "...pursue three tracks and necessary supporting work".
<= div>
=C2=A0 =C2=A0 =C2=A0 1. Addressing the issues with indirect mail flows
<= /blockquote>
<elided>=C2=A0

=C2=A0 =C2=A0 =C2=A0 2. Reviewing and improving the base DMARC specificatio= n
<elided>=C2=A0

=C2=A0 =C2=A0 =C2=A0 3.=C2=A0 DMARC Usage
<elided&g= t;=C2=A0

=C2=A0 =C2=A0 =C2=A0 4. Related work
<elided>=C2= =A0
--00000000000044b616057b366c84-- From nobody Thu Nov 22 09:20:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA102130F47 for ; Thu, 22 Nov 2018 09:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hhbo7pcPrng for ; Thu, 22 Nov 2018 09:20:55 -0800 (PST) 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 7EE3912E036 for ; Thu, 22 Nov 2018 09:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1542907252; bh=OAh77NrStRPfMFRhhOV4lDqFTTjlXIC2H24xHWUfvDE=; l=2480; h=To:References:From:Date:In-Reply-To; b=Ca0F13SxDAlY77FWeuwvnEHiWSuSdoXYvO70nodCxXL6V8AjZa+7eP+DsKFYSv/eF g1oWrx88RCJ4QsKCRmLJ4kqGjnu6P9w6CGH2FRy8e3bbvDHmJ58eZ+G5MXiLpW0Fan Xlxj4o9Qf8aQZfV1qOxAfXSgTlQ699s60hJYmxe/TNjUCE54QYPYT5D+yJ47u Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 22 Nov 2018 18:20:52 +0100 id 00000000005DC013.000000005BF6E574.00000544 To: dmarc@ietf.org References: <3881693.rR9BVk4Dlq@kitterma-e6430> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Autocrypt: addr=vesely@tana.it; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bub Message-ID: <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it> Date: Thu, 22 Nov 2018 18:20:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <3881693.rR9BVk4Dlq@kitterma-e6430> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Nov 2018 17:20:58 -0000 On Wed 21/Nov/2018 08:37:19 +0100 Scott Kitterman wrote: > [...] > Also, while I think the discussion about a DMARC specific public boundary > discovery mechanism was useful, and we should consider taking on that work, I > think it's not closely coupled to Public Suffix Domains and should be > discussed as a separate work item. /DMARC specific public boundary discovery/ is still ambiguous. Given the nature of the I-D, we are splitting the concept of boundary into two types: 1. *Alignment* which defines sets of shared responsibility, and 2. *Policing and reporting* which defines sets of shared criteria. Type #1 is a refinement of #2. For example, all banks may wish to share a secure policy and possibly a common surveillance method. However, they don't necessarily share customer accounts (let me recall that sharing session cookies implies just that.) > Goals: > > 1. Minimize additional verifier burden for adding PSD DMARC support. > Currently it requires consulting a locally stored, infrequently changing list > and one additional DNS lookup only for participating public suffixes when > there is no organizational domain DMARC record. Browsing a copy of the PSL, I found just 17 entries with 5 labels, like: s3.cn-north-1.amazonaws.com.cn and app.os.stg.fedoraproject.org Querying each subdomain would require 4 extra lookups. How much do we save in a dbound-like scenario? What about organizations that have not yet published boundary information? How about the camel[*]? [*] https://ietf.org/blog/herding-dns-camel/ > 2. Externalize signaling about PSD participation. As discussed in the > Privacy Considerations (section 4.1), we were concerned about the privacy > implications of feedback on organizational domain traffic for organizational > domains that don't participate in DMARC being inappropriately captured by > public suffix operators. In order to avoid this, we identified criteria for > which public suffixes PSD DMARC would be appropriate for and require an > external review to ensure those criteria are met. No solution that's in DNS > will address this part of the problem. I'm not clear what kind of inappropriateness is implied here. The overwhelming majority of people is pretty comfortable with having their personal stuff stored in "Echelon". Yet, if a domain is uncomfortable with the policy in _dmarc.com, it can opt out by publishing its own record. Best Ale -- From nobody Thu Nov 22 23:20:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C317124BAA for ; Thu, 22 Nov 2018 23:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=7jNGKbe4; dkim=pass (2048-bit key) header.d=kitterman.com header.b=GFxFSw28 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 q6BiSRRLCwhR for ; Thu, 22 Nov 2018 23:20:49 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80A61286E3 for ; Thu, 22 Nov 2018 23:20:49 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542957648; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ulcC8iZ/Sev76uWNq5+FY8+B1EqGsskmHUPT317K+p4=; b=7jNGKbe4hokJu9eJ9fze16TX8WvoTDBOciLXu/jHOsOCjoMVe32Cli2o Jc3+JdxY7mXEOIPk1PEEtDYHwGSjDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542957648; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=ulcC8iZ/Sev76uWNq5+FY8+B1EqGsskmHUPT317K+p4=; b=GFxFSw28zJ7+pGfISKpsuXLBh1BWtiQPjrIZAbxBM3y8dJCfk2TQbebh T1VO48dGBzafhAUiGiALluc5v19URCCTqnJ1AGfHcucq62Yfe7b5WuOXgF LvXD1MGfQb5apUaaJ00QxNZgx0/UGwQZ0krBJH99KH6hRWl/hXAqTG2CqA U229EMME9KlY3dPWZyIreGo97Tf3Q9rHeFgNLrcoy1MWF4/tnuirFTO76M 5BAC0VTDDq0JUhhfXiI8blcl84OlCVQ+ijF7q9yAtRRsNpjCLOU8EnnxSd wy56MrhDB6jDidNUsOSfAtqyfXI//rinoNiCPGbDNtXqaMbkxXkGLA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4EAA5C40198 for ; Fri, 23 Nov 2018 01:20:48 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Nov 2018 02:20:50 -0500 Message-ID: <4277375.HHtkFxoYCE@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it> References: <3881693.rR9BVk4Dlq@kitterma-e6430> <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2018 07:20:53 -0000 On Thursday, November 22, 2018 06:20:52 PM Alessandro Vesely wrote: > On Wed 21/Nov/2018 08:37:19 +0100 Scott Kitterman wrote: > > [...] > > Also, while I think the discussion about a DMARC specific public boundary > > discovery mechanism was useful, and we should consider taking on that > > work, I think it's not closely coupled to Public Suffix Domains and > > should be discussed as a separate work item. > > /DMARC specific public boundary discovery/ is still ambiguous. Given the > nature of the I-D, we are splitting the concept of boundary into two types: > > 1. *Alignment* which defines sets of shared responsibility, and > > 2. *Policing and reporting* which defines sets of shared criteria. > > Type #1 is a refinement of #2. For example, all banks may wish to share a > secure policy and possibly a common surveillance method. However, they > don't necessarily share customer accounts (let me recall that sharing > session cookies implies just that.) I'd suggest having the argument about if PSL is good enough or if we need a mechanism in DNS in a separate thread (which is why I wrote another mail to discuss that very topic). There's nothing in this draft about defining where the boundary is (just as in DMARC itself). > > Goals: > > > > 1. Minimize additional verifier burden for adding PSD DMARC support. > > Currently it requires consulting a locally stored, infrequently changing > > list and one additional DNS lookup only for participating public suffixes > > when there is no organizational domain DMARC record. > > Browsing a copy of the PSL, I found just 17 entries with 5 labels, like: > s3.cn-north-1.amazonaws.com.cn and > app.os.stg.fedoraproject.org > > Querying each subdomain would require 4 extra lookups. How much do we save > in a dbound-like scenario? What about organizations that have not yet > published boundary information? How about the camel[*]? No. There's nothing in the draft about walking up a tree. The draft looks one label higher in the tree than the organizational domain, that's it. One and only one is the maximum additional number of lookups in the current draft. I've no idea how a DNS indication of the boundary would help or hurt these cases, but it's orthogonal to the subject of this message. > > [*] https://ietf.org/blog/herding-dns-camel/ I'm not sure why you even mention this since the draft proposes no new DNS functionality. > > 2. Externalize signaling about PSD participation. As discussed in the > > Privacy Considerations (section 4.1), we were concerned about the privacy > > implications of feedback on organizational domain traffic for > > organizational domains that don't participate in DMARC being > > inappropriately captured by public suffix operators. In order to avoid > > this, we identified criteria for which public suffixes PSD DMARC would be > > appropriate for and require an external review to ensure those criteria > > are met. No solution that's in DNS will address this part of the > > problem. > > I'm not clear what kind of inappropriateness is implied here. The > overwhelming majority of people is pretty comfortable with having their > personal stuff stored in "Echelon". Yet, if a domain is uncomfortable with > the policy in _dmarc.com, it can opt out by publishing its own record. That's exactly backwards and the reason I wrote the privacy considerations. It's also completely contrary to IETF policy on the subject, see RFC 7258/BCP 188 [1]. During the adoption discussions there was some concern with the registry approach used so far. I would really like to have a discussion on alternatives. Personally, I don't think it's very useful to spend working group time on if privacy matters. Scott K [1] https://tools.ietf.org/rfc/rfc7258.txt From nobody Fri Nov 23 04:17:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68179128B14 for ; Fri, 23 Nov 2018 04:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tNx2OoM8Kg3 for ; Fri, 23 Nov 2018 04:17:44 -0800 (PST) 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 756D0124D68 for ; Fri, 23 Nov 2018 04:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1542975461; bh=0MPIFL6/eSSnQtrLnYdrNIIvCyTXRZ0DJX4tLeK+Vm0=; l=3854; h=To:References:From:Date:In-Reply-To; b=CASbpqpiYXS6jNNQytStGhRalAAFPZjOXqPYMRQmF07s3htWYxMB3COWQYnU5vIKk NiT3CNB1xA0AjLByvJguG9zEZy7lkR8Hp1hEag3M6tH2Vj3bUxqolnNlp49wWgAidM 99OSOXyK/OsqmexcUMvo0rzASbWGrBCMcFxbzLqi2NHIY37TiKr5Kf7XpzRRj Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 23 Nov 2018 13:17:41 +0100 id 00000000005DC013.000000005BF7EFE5.00001F97 To: dmarc@ietf.org References: <3881693.rR9BVk4Dlq@kitterma-e6430> <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it> <4277375.HHtkFxoYCE@kitterma-e6430> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Autocrypt: addr=vesely@tana.it; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bub Message-ID: <15458f87-f7ca-f83d-92c9-da144238c476@tana.it> Date: Fri, 23 Nov 2018 13:17:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <4277375.HHtkFxoYCE@kitterma-e6430> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2018 12:17:46 -0000 On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote: > > [...] There's nothing in the draft about walking up a tree. The draft looks > one label higher in the tree than the organizational domain, that's it. One > and only one is the maximum additional number of lookups in the current draft. That sounds acceptable to me. I don't think one extra query is going to have a tremendous impact: DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since that is required for sending aggregate reports. The availability of such a database makes it handy to store parsed policies as well. That is to say, a well designed mail filter can cache DNS data directly. Hence, given a decent SOA TTL, that extra lookup can probably be skipped on most messages. Compared to the amount of per-message DNS queries, it doesn't seem to hurt. DMARC could have a better say on implied TTLs, since data seen at lookup time is going to be reported at end-of-day time. > I've no idea how a DNS indication of the boundary would help or hurt these > cases, but it's orthogonal to the subject of this message. Neither do I. >> >> [*] https://ietf.org/blog/herding-dns-camel/ > > I'm not sure why you even mention this since the draft proposes no new DNS > functionality. I had read about instructive re-readings of DBOUND in previous discussions on this subject, so it seemed worth to consider the camel load. >>> 2. Externalize signaling about PSD participation. As discussed in the >>> Privacy Considerations (section 4.1), we were concerned about the privacy >>> implications of feedback on organizational domain traffic for >>> organizational domains that don't participate in DMARC being >>> inappropriately captured by public suffix operators. In order to avoid >>> this, we identified criteria for which public suffixes PSD DMARC would be >>> appropriate for and require an external review to ensure those criteria >>> are met. No solution that's in DNS will address this part of the >>> problem. >> >> I'm not clear what kind of inappropriateness is implied here. The >> overwhelming majority of people is pretty comfortable with having their >> personal stuff stored in "Echelon". Yet, if a domain is uncomfortable with >> the policy in _dmarc.com, it can opt out by publishing its own record. > > That's exactly backwards and the reason I wrote the privacy considerations. > It's also completely contrary to IETF policy on the subject, see RFC 7258/BCP > 188 [1]. Agreed. Rfc7489 misses an analysis of the risk implied by feedback reports, except for mentioning that ruf targets receive more privacy-sensible data than rua's (Section 12.5). Your I-D discourages ruf tags in PSD DMARC records, so that's partly addressed. Your I-D says some PSDs can impose a default DMARC policy while others cannot, but doesn't mention a rule to tell which is which. Yes, it mentions a IANA registry, but then it is not clear what rules or principles the designated expert would consider adequate. The case that all domain owners are part of a single organization with the PSO would rather seem to be an error of the PSL. > During the adoption discussions there was some concern with the registry > approach used so far. I would really like to have a discussion on > alternatives. Personally, I don't think it's very useful to spend working > group time on if privacy matters. Right, the consensus is that privacy matters. In rfc7258's words, we need to have a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?" Unless we do the same for all PSDs, a good answer should also explain PSDs differences a little bit better than the current I-D does, which seems to be another hairy question. Best Ale -- From nobody Fri Nov 23 08:57:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD9130DFF for ; Fri, 23 Nov 2018 08:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGpYM5uJX6bc for ; Fri, 23 Nov 2018 08:57:29 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 80F1212F1A6 for ; Fri, 23 Nov 2018 08:57:29 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id x19so19255976itl.1 for ; Fri, 23 Nov 2018 08:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=67lXZyrYLn9/R7b7Ms6T1Tdaui9QPv4jt9kHlDJxG44=; b=J9wKM2FHW9k4C55t6rt2wlHM3u6zmU8Qn2ACx6OjqJlZC0VtI+ae6AXFpPz1BxuEF+ /kULMT1BAnLeTte9JO9UlP/XSEHHvLyriP9rh06u6igRIxIyh11nKHjm2BH9Y6zodSKZ hx9NIkBV9CZ6D5nopT63F5R3lMFajYIUneU+TaQKR1DrQFlyO5q7pqsFQvYb392QlXC7 xl47EeEkE++znc39QbAFqYY73U6mpmzzTlkCAX9mRdiH0NegSYN3/zMiQcRdzzugIFJ8 wpZZFz9XfFfdPsVQuqQdEEm+iWsbvzaMN9H8Ii025LITyPjWAhJ+buCAx2C3RetekKjL HGpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67lXZyrYLn9/R7b7Ms6T1Tdaui9QPv4jt9kHlDJxG44=; b=Nz8mRW+yAg39UYnICqPORakS5GHBHz3QLVpaLIh4kRDSnxxP6YbMJbkU4f25CFNYzC b5S9QJ7dcPR5SWmsrQm/ozXdhNYX3TBuC4++aDR1FKEQQkiF1jaLqUrBT/z7OL1/uIMA 4beZm3UDjxU/qaHo1ISAyWp2UsyEEDqBDwdgEYHjLtELAKJXZDAcsbNxr/95dR5TXmmP DRaCBa98efh5BDo9vlmqxWTd8w3WCrVuXhXtcrMMg550O3kgBhon30pOH4xA/H+v3cli Ol30I7lqZ9CcubUFoiUVKo7XrebVar0glV9h8RY+HvoNO0GDMbuTUA0G6uosfe0ZlhpA ZizA== X-Gm-Message-State: AA+aEWZq2cW1kG/oQT67KDAMB2fJpUmxe7uZKfQDs2cALyU3Av1pwR0d KgDYUDs6YxoCnG0iQ5FGdH6taodDgZ+9v4nkK218Sw== X-Google-Smtp-Source: AFSGD/Vj7wfUntVifMJZX0M+q+6G5FjAlfLJGq+DxGdSor1pdSvJ5yqfC2woS/UlgWnG6as7bLT1ctp2obuxDc5iyZg= X-Received: by 2002:a24:301:: with SMTP id e1mr1253583ite.109.1542992248831; Fri, 23 Nov 2018 08:57:28 -0800 (PST) MIME-Version: 1.0 References: <3881693.rR9BVk4Dlq@kitterma-e6430> <6627107f-ee8b-89a4-65cd-b3875f06b1a7@tana.it> <4277375.HHtkFxoYCE@kitterma-e6430> <15458f87-f7ca-f83d-92c9-da144238c476@tana.it> In-Reply-To: <15458f87-f7ca-f83d-92c9-da144238c476@tana.it> From: Tim Wicinski Date: Fri, 23 Nov 2018 11:57:20 -0500 Message-ID: To: Alessandro Vesely Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000e201fb057b57e006" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2018 16:57:32 -0000 --000000000000e201fb057b57e006 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 23, 2018 at 7:17 AM Alessandro Vesely wrote: > On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote: > > > > [...] There's nothing in the draft about walking up a tree. The draft > looks > > one label higher in the tree than the organizational domain, that's it. > One > > and only one is the maximum additional number of lookups in the current > draft. > > > That sounds acceptable to me. I don't think one extra query is going to > have a > tremendous impact: > > DMARC mechanics entails keeping tracks of A-Rs, indexed by domain, since > that > is required for sending aggregate reports. The availability of such a > database > makes it handy to store parsed policies as well. That is to say, a well > designed mail filter can cache DNS data directly. Hence, given a decent > SOA > TTL, that extra lookup can probably be skipped on most messages. Compared > to > the amount of per-message DNS queries, it doesn't seem to hurt. > > DMARC could have a better say on implied TTLs, since data seen at lookup > time > is going to be reported at end-of-day time. > > I remember chatting with John Levine about this maybe six month ago about ARC and DNS lookups and he said "the extra DNS lookups should not be an issue" which I agreed with. Since I do DNS Operations for a mid-sized SaaS vendor, and we play lots of SOA/TTL games (10s NXTTL, 300s TTLs for most records, etc) I went and looked at our DNS query usage around our SPF records as an example (since we do layered SPF), and those queries barely scratch the top 25, but the DMARC/DKIM queries are way down in the noise. I can't see where a second query is an issue, as long as the applications are fine in doing them. Tim --000000000000e201fb057b57e006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Nov 23, 2018 at 7:17 AM Alessandro Vesely <vesely@tana.it> wrote:
; Fri, 23 Nov 2018 13:09:51 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB05912426A for ; Fri, 23 Nov 2018 13:09:50 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1543007387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=6IrvBMvtR6FkeDJd/m7UWMxm0W2N+p9OgJ4nWraKaN8=; b=wIHkrKGljsbLhI807IZf6LrOsbaf4fU6TScJa7n+yhkl4/3xs71oBwLU jUVOcZ15Q6+iggyNxJvetOz4AK6uBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1543007387; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=6IrvBMvtR6FkeDJd/m7UWMxm0W2N+p9OgJ4nWraKaN8=; b=pN/20EhF1RQoubDGB09qv6DGN3uMTT+XtZyGNhks+HjieUg40E5sXdoi azjeBdGGeg2g11flaDF9RmfQFshLE/YYAg42bcbbzMlIiquxTxqEL2eW7G aCdmtWGhklNRkWSBeBuOvay8fy92a7xAGqV9T5XVDF4pGMql7nMe4ny051 eS9CCEBFU4Jo6n6D05Iu1adUmIy+K5iopXx4GF8zd1NktUUBXzpTmhPNq7 JKckbpQZYWjtz4p2ecpN88K0lsXnlHe0dKyJVDjNb/Jj0EuRnbFLXMwoCU 50U1ctSnfVQnfzobsvKIkess2rN5gTxpOi4uJyTLIardJ/05yo3PyA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0E5D4C401F4 for ; Fri, 23 Nov 2018 15:09:47 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Nov 2018 16:09:46 -0500 Message-ID: <1615692.fplaSCgD6h@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <15458f87-f7ca-f83d-92c9-da144238c476@tana.it> References: <3881693.rR9BVk4Dlq@kitterma-e6430> <4277375.HHtkFxoYCE@kitterma-e6430> <15458f87-f7ca-f83d-92c9-da144238c476@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2018 21:09:53 -0000 On Friday, November 23, 2018 01:17:41 PM Alessandro Vesely wrote: > On Fri 23/Nov/2018 08:20:50 +0100 Scott Kitterman wrote: ... > >>> 2. Externalize signaling about PSD participation. As discussed in the > >>> Privacy Considerations (section 4.1), we were concerned about the > >>> privacy > >>> implications of feedback on organizational domain traffic for > >>> organizational domains that don't participate in DMARC being > >>> inappropriately captured by public suffix operators. In order to avoid > >>> this, we identified criteria for which public suffixes PSD DMARC would > >>> be > >>> appropriate for and require an external review to ensure those criteria > >>> are met. No solution that's in DNS will address this part of the > >>> problem. > >> > >> I'm not clear what kind of inappropriateness is implied here. The > >> overwhelming majority of people is pretty comfortable with having their > >> personal stuff stored in "Echelon". Yet, if a domain is uncomfortable > >> with > >> the policy in _dmarc.com, it can opt out by publishing its own record. > > > > That's exactly backwards and the reason I wrote the privacy > > considerations. > > It's also completely contrary to IETF policy on the subject, see RFC > > 7258/BCP 188 [1]. > > Agreed. Rfc7489 misses an analysis of the risk implied by feedback reports, > except for mentioning that ruf targets receive more privacy-sensible data > than rua's (Section 12.5). Your I-D discourages ruf tags in PSD DMARC > records, so that's partly addressed. > > Your I-D says some PSDs can impose a default DMARC policy while others > cannot, but doesn't mention a rule to tell which is which. Yes, it > mentions a IANA registry, but then it is not clear what rules or principles > the designated expert would consider adequate. The case that all domain > owners are part of a single organization with the PSO would rather seem to > be an error of the PSL. The problem is that there is no generic rule to cover all cases, ccTLDs, generic TLDs, and legacy TLDs all have different rules (and different rules within each of those groups). That's why we designate an expert to figure it out. Typically (as far as I can tell) RFCs that use designated experts for IANA registry review only give very general guidance. The guidance here is, I think, appropriate (DMARC use is required for private domains registered in the PSD/TLD). Arguing the PSL is wrong, isn't really helpful for this use case. Even if the PSL were fixed/replaced by some dbound type thing, that would only affect the single use TLD case (so we delete a handful of lines from the draft). They are the simplest case. I think we should focus on the mechanism to allow for "above org level" DMARC checks (which is what this draft does) that is limited in scope so that registrars can't conduct an inappropriate land grab. It's not like this kind of thing hasn't happened before [1]. [1] https://www.theregister.co.uk/2003/09/16/all_your_web_typos/ > > During the adoption discussions there was some concern with the registry > > approach used so far. I would really like to have a discussion on > > alternatives. Personally, I don't think it's very useful to spend working > > group time on if privacy matters. > > Right, the consensus is that privacy matters. In rfc7258's words, we need > to have a good answer to the question "Is pervasive monitoring relevant to > this work and if so, how has it been considered?" Unless we do the same > for all PSDs, a good answer should also explain PSDs differences a little > bit better than the current I-D does, which seems to be another hairy > question. I am open to suggestions. Scott K From nobody Fri Nov 30 11:00:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB598130E5A; Fri, 30 Nov 2018 11:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=qUkstKLe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o1uAIvie 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 M2s3wa0Qnlvo; Fri, 30 Nov 2018 11:00:19 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939C6130F33; Fri, 30 Nov 2018 11:00:19 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 56520214; Fri, 30 Nov 2018 14:00:18 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 30 Nov 2018 14:00:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=qB7 gXNxh6oPw/g0ZES3leR330TwdVG4qM+Ju7qNUPRk=; b=qUkstKLeQOqHLlNP31y poER7wj7W7ZYB8jEq4WpwQfeU9OuuD1Domzs/3FlZUM9BKOBwY5ZrTdNRYqP6Mph bjUxPW1MV5cYK5f7U8Yg+x9p0p78ZVOx4xDKaZqGX2yLGZAtfdUEGD188PvLD7uW 6ErPMBybMl2VRIFW19yNi0LaJmqp0A+15mfApY7/bHm6tqv/IwwBUwetn9c7IkSx 6CdjaEVfG8qj9s9xjKVvFrgTJWrAvl1mnnrizQDWlx4EnKg4F4SyhR4l5vN7GRSZ qb+463E755vj5X3LYSSI2NFlzb1nkmOONIaT9eLF1dZ+XNjtcf56OhnlWJG92POg uZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qB7gXNxh6oPw/g0ZES3leR330TwdVG4qM+Ju7qNUP Rk=; b=o1uAIvieW7WMxoR5wi2dwI0dyQT6Ww7wdsmAzAaLwp/C7zP7C7RBT6iTk 75NimJC+UEgof11MZEUOPrxfNZv72QR+Ixi5POQjtZTdh0QR4PdPQsSOK8LKGn6z uLfOtVU/GltwJYkLQIV0BMbu9kjPrKJA/uFiRvtONwdHs745jEGlD7IlCkzt1PFk kscMRV+C7aeZ2mk6wUDRNiS4pW1ZGbUebMiSF34loxyudvl9JiQ9sIyNGnN8qX+Z JJPmBFj0ek+t44sQIPO1SXY05c+HDv9DtV9fNm/atPwpOh362XvvEvtg1aPpXD+C qujBXBlX1TPZX69iwloCHmr3onLTg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 46EAD9E130; Fri, 30 Nov 2018 14:00:17 -0500 (EST) Message-Id: <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> From: Alexey Melnikov To: Barry Leiba , Ben Campbell Cc: Tim Draegen , dmarc@ietf.org, IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> Date: Fri, 30 Nov 2018 19:00:17 +0000 In-Reply-To: Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 19:00:22 -0000 Hi all, On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > I actually agree with this: I think the better answer is to go back to > "obsoletes" and to have this document include the details of what was > put in the registries before. But the working group decided to do it > the other way, and there's been criticism in the past of ADs (and, so, > by extension, chairs) picking on this sort of stuff, so I decided to > let it go. I'll let the IESG sort this one out, but I'll go on record > as saying what I think the better way to handle it is. I think incorporating older registrations is the cleaner way of dealing with Ben's & Benjamin's DISCUSSes, as then the document is self contained and there is no need for readers to see obsoleted RFCs. So this would be my preference. If the WG doesn't want to do this, then the document needs editing to be correct as per Benjamin's DISCUSS. Best Regards, Alexey > That said, I don't think it's a huge deal either way. > > Barry > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell wrote: > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is mainly a process discuss. I share Alvaro's concern about this being > > marked as "updating" RFC7601, when it seem like a full replacement. I'm > > promoting it to a DISCUSS because I think this needs to be resolved before > > publication. > > > > The current structure will make it very difficult for readers to figure out > > which parts of each doc they need to worry about. I think it needs to either go > > back to "obsoleting" 7601, or it needs to be recast to just talk about the > > changes. Note that if the former path is chosen, the IANA considerations in > > 7601 will need to be copied forward. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary > > changes. That makes the diff tools much more useful than they are for bis > > drafts that make wholesale organization and stylistic changes. > > > > > > > -- > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ > From nobody Fri Nov 30 11:31:38 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D64130F82 for ; Fri, 30 Nov 2018 11:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENsldSjpk-lp for ; Fri, 30 Nov 2018 11:31:26 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 D38D4130F7C for ; Fri, 30 Nov 2018 11:31:25 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id x19so156695itl.1 for ; Fri, 30 Nov 2018 11:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eUDBab6mvM9p2LUvnO6qVaBWS2tmumSOnk+Mx5p4vE4=; b=AQK05m2Dl9y3bX3kXP/ULiKtgOSqpHKtg3M5Vkj1UjM4jtGfH+np1k4bgSPS4oF1wb RiNZz9riJ2qTCyOI50/xTvp9uvasga7yo1a3wIEetdwGY6LT4ajV0VPD4PinWL4AkhJn sbU89V4ZVTL5h8Fbh0l5tdCxGrjQ8oNe9pdwA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eUDBab6mvM9p2LUvnO6qVaBWS2tmumSOnk+Mx5p4vE4=; b=kcPKJoGjO+0l6mMgQ0Y5x/n0NctkholJElOK1OgcI/gdfayLOVleQDpadGHExIfcLd JRvjuM3FZtkG1wFIag4g0UP3Y+UKM31HjlIo9N6xk8H0YvN0x0UKUg7bOX5aDJ6oWtDR wi4YmmPAmApEJsxh2EOEvLARxWYEnqBCn1EvaG+ogkPGtrqXw/hmKtZJkaEeKgl1Ruhz dHa0VNct+P8HnBnmHQ2WgyPhHMMfL/O/lv7j/cBsQhhE/+MQvWi+/vjm8dSs0ZtE5GUL tAVfHXfjoeSVFiMoaslGPSPc/2O2sgl3N2G6969EDQQX4/WzrOu74pX3a+O+tS9RS3jv oGRg== X-Gm-Message-State: AA+aEWYU2pS4JBMhWbuy8Q2snWyxy2uhWcKYSJJ34vk1cPJRsgNSIao+ LtTrMlfmmxs4ylPTZK7LgApUWgzPXWCfsSgwfzGGhuPGa9/qW32M X-Google-Smtp-Source: AFSGD/WEnwc06zCcHHAYOQI+DHXT0afZh8vqZOKsnVW+r5Yph9Ji29wJv6oUNJqEjCvjGanMQ3HHcCkqCNN41IGEtyg= X-Received: by 2002:a24:8302:: with SMTP id d2mr97397ite.78.1543606285065; Fri, 30 Nov 2018 11:31:25 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> In-Reply-To: <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> From: "Kurt Andersen (b)" Date: Fri, 30 Nov 2018 11:31:12 -0800 Message-ID: To: Alexey Melnikov Cc: Barry Leiba , Ben Campbell , Tim Draegen , "dmarc@ietf.org" , iesg@ietf.org, draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004b7146057be6d83e" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 19:31:28 -0000 --0000000000004b7146057be6d83e Content-Type: text/plain; charset="UTF-8" On Fri, Nov 30, 2018 at 11:00 AM Alexey Melnikov wrote: > Hi all, > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > I actually agree with this: I think the better answer is to go back to > > "obsoletes" and to have this document include the details of what was > > put in the registries before. > > I think incorporating older registrations is the cleaner way of dealing > with Ben's & Benjamin's DISCUSSes, as then the document is self contained > and there is no need for readers to see obsoleted RFCs. So this would be my > preference. > > If the WG doesn't want to do this, then the document needs editing to be > correct as per Benjamin's DISCUSS. > > Best Regards, > Alexey > >From a committee POV, I have no objection. I think that the current arrangement was preferred by the author. --Kurt --0000000000004b7146057be6d83e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 30= , 2018 at 11:00 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi all,

On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote:
> I actually agree with this: I think the better answer is to go back to=
> "obsoletes" and to have this document include the details of= what was
> put in the registries before.=C2=A0=C2=A0

I think incorporating older registrations is the cleaner way of dealing wit= h Ben's & Benjamin's DISCUSSes, as then the document is self co= ntained and there is no need for readers to see obsoleted RFCs. So this wou= ld be my preference.

If the WG doesn't want to do this, then the document needs editing to b= e correct as per Benjamin's DISCUSS.

Best Regards,
Alexey

From a committee POV, I have no objec= tion. I think that the current arrangement was preferred by the author.
--Kurt=C2=A0
--0000000000004b7146057be6d83e-- From nobody Fri Nov 30 12:54:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AAD131001; Fri, 30 Nov 2018 12:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDfy-tNHYExG; Fri, 30 Nov 2018 12:54:16 -0800 (PST) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (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 66745130E8F; Fri, 30 Nov 2018 12:54:16 -0800 (PST) Received: by mail-it1-f171.google.com with SMTP id i145so501109ita.4; Fri, 30 Nov 2018 12:54:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2jNVfU9vTcAzUexa0lfYzqMyc9QeMx+0gGo1G7Ygg7A=; b=q9qBIbFzvbWqy0txN0uX33cv8N1p/4IahTjDM3od9e7HtrCsseJPWs1AIiY4QIOhrF mw3LgKlIn7iOfNC0OtrXLxjvqU9un9DkqytNSR0+gjZEIv6Kj2ItSfKVnGmasA/wzmAV arynAyUe/MRdeKLVjYLzhWT17lm2j2TxqPO/CnQKZLEYmXtwjBVOBM9T9Ay23Kftr0w9 oEu7OFDBhqftjdeXfjrwBhsY6SqDyuJb+akuzLD69WDaJOLTexE29AMyV6KCCCzkRUo3 ozsiPn7Q0bCX6ntWEfWeegHFxz9X6YCPcN4yaQns35tQIe4KnEI8SS0ObMhOWHGKe+r3 Nk2g== X-Gm-Message-State: AA+aEWbWe3g2U3dZhDp8hwJABzk44Lxv+G5+Uj4kEtB4NQSWhvXZgoQ3 QUyMiygnHd2w56K42VVhQmA6QepmIkmYVaFTOzU= X-Google-Smtp-Source: AFSGD/Xe36rQ/in0JT0Q3dEAvbReQH9nC16PbQ+yJef7bEUFd3kCfb5CmeusWaZxX1EKXulbrt+4y5FEPrBBfhHSkW4= X-Received: by 2002:a24:a49:: with SMTP id 70-v6mr310813itw.122.1543611255232; Fri, 30 Nov 2018 12:54:15 -0800 (PST) MIME-Version: 1.0 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> In-Reply-To: <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> From: Barry Leiba Date: Fri, 30 Nov 2018 15:54:04 -0500 Message-ID: To: Alexey Melnikov Cc: Ben Campbell , Tim Draegen , dmarc@ietf.org, IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 20:54:19 -0000 Murray, would you please copy the relevant IANA Considerations sections from RFC 7601 into 7601bis and change the tenses appropriately (perhaps just with a sentence in each subsection that says, "The following was done in the previous edition of this document, RFC 7601:", or some such), and then let's have a quick working group review of the result? (And, of course, change it back to "obsoletes" rather than "updates".) As it's editorial, I'm sure we don't need to go back through any approval process, and we can get the DISCUSS cleared and move forward. Thanks, Barry On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov wrote: > > Hi all, > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > I actually agree with this: I think the better answer is to go back to > > "obsoletes" and to have this document include the details of what was > > put in the registries before. But the working group decided to do it > > the other way, and there's been criticism in the past of ADs (and, so, > > by extension, chairs) picking on this sort of stuff, so I decided to > > let it go. I'll let the IESG sort this one out, but I'll go on record > > as saying what I think the better way to handle it is. > > I think incorporating older registrations is the cleaner way of dealing with Ben's & Benjamin's DISCUSSes, as then the document is self contained and there is no need for readers to see obsoleted RFCs. So this would be my preference. > > If the WG doesn't want to do this, then the document needs editing to be correct as per Benjamin's DISCUSS. > > Best Regards, > Alexey > > > That said, I don't think it's a huge deal either way. > > > > Barry > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell wrote: > > > > > > Ben Campbell has entered the following ballot position for > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > This is mainly a process discuss. I share Alvaro's concern about this being > > > marked as "updating" RFC7601, when it seem like a full replacement. I'm > > > promoting it to a DISCUSS because I think this needs to be resolved before > > > publication. > > > > > > The current structure will make it very difficult for readers to figure out > > > which parts of each doc they need to worry about. I think it needs to either go > > > back to "obsoleting" 7601, or it needs to be recast to just talk about the > > > changes. Note that if the former path is chosen, the IANA considerations in > > > 7601 will need to be copied forward. > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary > > > changes. That makes the diff tools much more useful than they are for bis > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > > > -- > > Barry > > -- > > Barry Leiba (barryleiba@computer.org) > > http://internetmessagingtechnology.org/ > > From nobody Fri Nov 30 13:02:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96029131008 for ; Fri, 30 Nov 2018 13:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p02H7O_YdweC for ; Fri, 30 Nov 2018 13:02:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9AB2C131007 for ; Fri, 30 Nov 2018 13:02:40 -0800 (PST) Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAUL2Wj1000950 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 30 Nov 2018 15:02:39 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F0AB11BE-DF15-4D3E-A763-8B5AE7B6DC2F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Fri, 30 Nov 2018 15:02:31 -0600 In-Reply-To: Cc: Alexey Melnikov , Tim Draegen , dmarc@ietf.org, IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org To: Barry Leiba References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 21:02:44 -0000 --Apple-Mail=_F0AB11BE-DF15-4D3E-A763-8B5AE7B6DC2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In case it=E2=80=99s not obvious, that would be sufficient for me to = clear. Thanks! Ben. > On Nov 30, 2018, at 2:54 PM, Barry Leiba = wrote: >=20 > Murray, would you please copy the relevant IANA Considerations > sections from RFC 7601 into 7601bis and change the tenses > appropriately (perhaps just with a sentence in each subsection that > says, "The following was done in the previous edition of this > document, RFC 7601:", or some such), and then let's have a quick > working group review of the result? (And, of course, change it back > to "obsoletes" rather than "updates".) >=20 > As it's editorial, I'm sure we don't need to go back through any > approval process, and we can get the DISCUSS cleared and move forward. >=20 > Thanks, > Barry > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov = wrote: >>=20 >> Hi all, >>=20 >> On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: >>> I actually agree with this: I think the better answer is to go back = to >>> "obsoletes" and to have this document include the details of what = was >>> put in the registries before. But the working group decided to do = it >>> the other way, and there's been criticism in the past of ADs (and, = so, >>> by extension, chairs) picking on this sort of stuff, so I decided to >>> let it go. I'll let the IESG sort this one out, but I'll go on = record >>> as saying what I think the better way to handle it is. >>=20 >> I think incorporating older registrations is the cleaner way of = dealing with Ben's & Benjamin's DISCUSSes, as then the document is self = contained and there is no need for readers to see obsoleted RFCs. So = this would be my preference. >>=20 >> If the WG doesn't want to do this, then the document needs editing to = be correct as per Benjamin's DISCUSS. >>=20 >> Best Regards, >> Alexey >>=20 >>> That said, I don't think it's a huge deal either way. >>>=20 >>> Barry >>>=20 >>> On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell = wrote: >>>>=20 >>>> Ben Campbell has entered the following ballot position for >>>> draft-ietf-dmarc-rfc7601bis-04: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> This is mainly a process discuss. I share Alvaro's concern about = this being >>>> marked as "updating" RFC7601, when it seem like a full replacement. = I'm >>>> promoting it to a DISCUSS because I think this needs to be resolved = before >>>> publication. >>>>=20 >>>> The current structure will make it very difficult for readers to = figure out >>>> which parts of each doc they need to worry about. I think it needs = to either go >>>> back to "obsoleting" 7601, or it needs to be recast to just talk = about the >>>> changes. Note that if the former path is chosen, the IANA = considerations in >>>> 7601 will need to be copied forward. >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I mostly just reviewed the diff. Thank you for mostly avoiding = unnecessary >>>> changes. That makes the diff tools much more useful than they are = for bis >>>> drafts that make wholesale organization and stylistic changes. >>>>=20 >>>>=20 >>>=20 >>>=20 >>> -- >>> Barry >>> -- >>> Barry Leiba (barryleiba@computer.org) >>> http://internetmessagingtechnology.org/ >>>=20 --Apple-Mail=_F0AB11BE-DF15-4D3E-A763-8B5AE7B6DC2F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwBpWcACgkQgFZKbJXz 1A2Vnw//fNGeRVryFZLBla2woh+1i+i5MLZAXYcutmdDNZeE3Wizq416ur4hY2A5 4UhxpU0flfXI8sTRKqHIP7WCso+I4BeUCaqUQH1mJxky6dQhyve74nRxIyxj/f/q 0DqWisV+bue7dlG71/er16Ao1BEos9KAneiE6uLTSq6FYar8z8FJDIYORmtlLLrb ufS2lCvIMMjED1TMi16r3UjQEcvV3Sy1NqORrUaCsRx8B/o22mj4USkVDWAdTeNw lWLeSB4NCAzQok7RX+z5nQky+CISEi/tWZ4sk2x3RlG10CjAXYUakM/aVLmWsjQ7 wlRYeAdroVs/4XTg3r/6+WmlrAOuCWse+BDqQUWOBGwyJcX1sWLagpXV27RvbQ5R 1GyQMriRLh39896q+LlO0qO7pHF5UsUUFgnfKEgrDh8Kfy+SK5vBlxkmYpZm5T52 fBHRkvx4wBB6VWESuQZ+2ADvToLhxlfB2x8VJVAOoW2od0V/ViD0foYdZtKk4qVX fIyHWXBTCElovgc3nzGYXaIGcP/8EbY0MHUMB10yXsbx3uy88oj9Tmd3l8Y4Gp7+ oeltXnxebYlL3aHrA6wkL/sGa9AKOGnKbvvNBhAjdeHCnsyuAZ/3BCS949bK50iL OHbh0+VgCbMXQotXAcLZVHH5gI5SwB+BLncO+FkAe50lwx+Foh0= =4hyS -----END PGP SIGNATURE----- --Apple-Mail=_F0AB11BE-DF15-4D3E-A763-8B5AE7B6DC2F-- From nobody Fri Nov 30 13:31:32 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5ED13104D; Fri, 30 Nov 2018 13:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=S/tVjeLM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F3IILKHp 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 wwwR-IBTqNK4; Fri, 30 Nov 2018 13:31:29 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C0D131036; Fri, 30 Nov 2018 13:31:28 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C01FB22B; Fri, 30 Nov 2018 16:31:27 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 30 Nov 2018 16:31:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:date:references:subject; s=fm1; bh=JE3 lBhwNn8iUAS8mG5F6k9qXNCV9+8HWjg+xKQjYiqY=; b=S/tVjeLMFYYLyCG8OkR pqz1NUTAHjj2oXcdxOBU990m6sj/Ur1Wq+uo+jADCVE8XtjMPSUAPn3gA/0Srobg 2BXyn9ArOD9Y+OYl8bzYp+hmKRpE2ci/ziQxi3SxRComR3Oc1fAu0goNUjbvG+A0 2+ye+Sx6RFJifLUodPse7PVqiR36+cY6wbOuT7cumIW/HIkAGtwqnrx++OQRD9c+ PhoeIcrvdxo6PxfNRFTSOLoe7sFMfNnq9sYemnhC2IIDESXALp3RQxKtRZ81u9za eSnOnDcZy4BkHlCo8sGKdXiMryctXZxDSymNiHkt9O4ISTSDeKn0G7yowVYuuvwE SCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=JE3lBhwNn8iUAS8mG5F6k9qXNCV9+8HWjg+xKQjYi qY=; b=F3IILKHpmHZqG/ZrTlSxzDxnvR4YBCf5bpS9aBTBaC7q3hxNylIeyVBZ5 iWFLtZxXaXdEWOTK1TbJVKyPjwlb+4+CPqu321ekXagjVvuXYLVnST8ppFzFY4aD k+Fr45jZkfank0F1wrU9UFCs9dNiLLeSklyr/dkecocn83dPMsVgIOX8wOHVBMcg hoGyBLZQWsUhx1Y5OXzXyOQXBWOmqhnvK1mOEiDsRHq3jCvnaLDNsYwyzm0+XBB4 yTUqdNoZVo/g73IlGUeh9X3jgGFcqpPgWZ8QhaT5ursIBQEDxhK0EnUoPPfF8LgJ oJ39fki7E59egcesdzvLy/0gjbCdA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BE9B19E114; Fri, 30 Nov 2018 16:31:25 -0500 (EST) Message-Id: <1543613485.3765543.1594837224.1E64FAB8@webmail.messagingengine.com> From: Alexey Melnikov To: Barry Leiba , "Murray S. Kucherawy" Cc: Ben Campbell , Tim Draegen , dmarc@ietf.org, IESG , draft-ietf-dmarc-rfc7601bis@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b In-Reply-To: Date: Fri, 30 Nov 2018 21:31:25 +0000 References: <154275534023.29886.12970892679231398383.idtracker@ietfa.amsl.com> <1543604417.3723984.1594680736.00216E5A@webmail.messagingengine.com> Archived-At: Subject: Re: [dmarc-ietf] Ben Campbell's Discuss on draft-ietf-dmarc-rfc7601bis-04: (with DISCUSS and COMMENT) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 21:31:31 -0000 On Fri, Nov 30, 2018, at 8:54 PM, Barry Leiba wrote: > Murray, would you please copy the relevant IANA Considerations > sections from RFC 7601 into 7601bis and change the tenses > appropriately (perhaps just with a sentence in each subsection that > says, "The following was done in the previous edition of this > document, RFC 7601:", or some such Even better if you say something like "the following is unchanged from RFC 7601:". >), and then let's have a quick > working group review of the result? (And, of course, change it back > to "obsoletes" rather than "updates".) > > As it's editorial, I'm sure we don't need to go back through any > approval process, and we can get the DISCUSS cleared and move forward. I agree. I think this is purely editorial, albeit an important issue for the final document. > Thanks, > Barry > On Fri, Nov 30, 2018 at 2:00 PM Alexey Melnikov wrote: > > > > Hi all, > > > > On Wed, Nov 21, 2018, at 9:39 PM, Barry Leiba wrote: > > > I actually agree with this: I think the better answer is to go back to > > > "obsoletes" and to have this document include the details of what was > > > put in the registries before. But the working group decided to do it > > > the other way, and there's been criticism in the past of ADs (and, so, > > > by extension, chairs) picking on this sort of stuff, so I decided to > > > let it go. I'll let the IESG sort this one out, but I'll go on record > > > as saying what I think the better way to handle it is. > > > > I think incorporating older registrations is the cleaner way of dealing with Ben's & Benjamin's DISCUSSes, as then the document is self contained and there is no need for readers to see obsoleted RFCs. So this would be my preference. > > > > If the WG doesn't want to do this, then the document needs editing to be correct as per Benjamin's DISCUSS. > > > > Best Regards, > > Alexey > > > > > That said, I don't think it's a huge deal either way. > > > > > > Barry > > > > > > On Tue, Nov 20, 2018 at 6:09 PM Ben Campbell wrote: > > > > > > > > Ben Campbell has entered the following ballot position for > > > > draft-ietf-dmarc-rfc7601bis-04: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > This is mainly a process discuss. I share Alvaro's concern about this being > > > > marked as "updating" RFC7601, when it seem like a full replacement. I'm > > > > promoting it to a DISCUSS because I think this needs to be resolved before > > > > publication. > > > > > > > > The current structure will make it very difficult for readers to figure out > > > > which parts of each doc they need to worry about. I think it needs to either go > > > > back to "obsoleting" 7601, or it needs to be recast to just talk about the > > > > changes. Note that if the former path is chosen, the IANA considerations in > > > > 7601 will need to be copied forward. > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > I mostly just reviewed the diff. Thank you for mostly avoiding unnecessary > > > > changes. That makes the diff tools much more useful than they are for bis > > > > drafts that make wholesale organization and stylistic changes. > > > > > > > > > > > > > > > > > -- > > > Barry > > > -- > > > Barry Leiba (barryleiba@computer.org) > > > http://internetmessagingtechnology.org/ > > > From nobody Fri Nov 30 13:40:42 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E47013104E for ; Fri, 30 Nov 2018 13:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 j0xA3iFjVbYZ for ; Fri, 30 Nov 2018 13:40:38 -0800 (PST) Received: from maleficent.mr.itd.umich.edu (smtp.mail.umich.edu [141.211.125.12]) (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 1CEB813104D for ; Fri, 30 Nov 2018 13:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2016-05-12; t=1543614036; bh=OaidzqDjF/bY6vXXOZn3BhWdo98SFc+LnRh4heGptSo=; h=Date:From:To:Subject:References:In-Reply-To; b=KVQGp3Sa8pmv2gHnsEw8zvZhAUrXPNenHn4S2afSOVnFItq3rz+junW9IjB0AWfdo /1FnVYbChmiNR9gG+0mDTlhOnR0Kkjfo1JmHIEX5W2tDkMLihCWubky9krIIftp8iW ZOB1BO0K4EGzICgQrLeXth7Hw0dhqwKPJHxufD7y4Z/c584JUNfNjQj49whmRsUW2D 6UD/zu7PxYmMjlHqdsRvqQBbPgyDkZy3MncN0R5R09IXMSDndBBeW2JrRj7QHA1vum J3rngVHD5xy4FasFwYVnwVTDFaclUOqws7h/WODuVNl4n9DIvxvXGPDEd4dpEv9Whj yVbHHr4ky1aew== Authentication-Results: maleficent.mr.itd.umich.edu; iprev=pass policy.iprev=45.79.218.81 (vereveel.marwnad.com); auth=pass smtp.auth=ezekielh Received: FROM marwnad.com (vereveel.marwnad.com [45.79.218.81]) By maleficent.mr.itd.umich.edu ID 5C01AE54.5CA4C.25214; Authuser ezekielh; Fri, 30 Nov 2018 16:40:36 -0500 Date: Fri, 30 Nov 2018 21:40:33 +0000 From: Zeke Hendrickson To: dmarc@ietf.org Message-ID: <20181130214033.GA20002@marwnad.com> References: <3881693.rR9BVk4Dlq@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3881693.rR9BVk4Dlq@kitterma-e6430> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 21:40:41 -0000 On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote: > While we were discussing making draft-kitterman-dmarc-psd a working group > item, the main discussion point was about the use of an IANA registry to > identify participating public suffix domains. I think it would be useful to > consider what problems we were trying to solve and see if there are > alternative approaches that address those requirements. > > Goals: > > 1. Minimize additional verifier burden for adding PSD DMARC support. > Currently it requires consulting a locally stored, infrequently changing list > and one additional DNS lookup only for participating public suffixes when > there is no organizational domain DMARC record. > > 2. Externalize signaling about PSD participation. As discussed in the > Privacy Considerations (section 4.1), we were concerned about the privacy > implications of feedback on organizational domain traffic for organizational > domains that don't participate in DMARC being inappropriately captured by > public suffix operators. In order to avoid this, we identified criteria for > which public suffixes PSD DMARC would be appropriate for and require an > external review to ensure those criteria are met. No solution that's in DNS > will address this part of the problem. I feel that restricting the additional PSD check to nonexistent organizational domains is the best approach, as it preserves the opt-in nature of DMARC, limits privacy concerns, remains very straightforward to implement as a verifier, and does not rely on an additional list. draft-ietf-dmarc-psd-00 addresses a slightly broader problem space, but I feel that adding the ability to get feedback on abuse of nonexistent domains is the most needed aspect; treating branded PSDs as organizational domains would be better addressed by improving the way organizational boundaries are determined. -- Zeke Hendrickson (ezekielh@umich.edu) University of Michigan | Information and Technology Services Infrastructure | Application Operations | Collaboration Services From nobody Fri Nov 30 14:52:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1735C130E30 for ; Fri, 30 Nov 2018 14:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1fIB3IBE0_N for ; Fri, 30 Nov 2018 14:52:17 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 066AD1274D0 for ; Fri, 30 Nov 2018 14:52:17 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id c9so869041itj.1 for ; Fri, 30 Nov 2018 14:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywWT/qc6Brudw6s6GAQfKTEGfPE0jXBlwh6Dg8hVEn8=; b=TR8kpVjdZfYKSaEwdOt3w2Xmw1tQoYNOJRQ+TlznN9C3bVLs84fc1B3AC9ApMcoZn3 mmEK6jCOZBujoaWfyF5/yI9xbz16NmQ7tlerBssaIXbSInmcwSjcEn43UWV71y/+Eb6w 5C08GvgO/SFt8R07VrMn59OxHmuWjeoJ2aeCE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ywWT/qc6Brudw6s6GAQfKTEGfPE0jXBlwh6Dg8hVEn8=; b=Qj6i/XSoIyn6ND9UIeRpLwGsp7PSPnh7FoHI1RgFsCdX1j8IMlavL7nrl/uZ22u7US IpmpGexcF5tujMc71MR+W8DDk8Khswj7IM8Kd+6aPPKopCbmY3PGB+sqrXixT03nM077 6cSNJZ8YQspzbcfytqPm16AXnLbbF2zWRuk40Lre+lsc30DXfNEGzCBB2q9MwqzWSdpM bWKObD+wJEtpk1bXrsi8AtdzPPnF3BJ7crwC44/Elct2lqwU7NZedfy+Gq4R0IsBTw7u TDV//iEsw/T5tSkjzgnD4GpOnrDb/OThMeDTL/q4OXaPxOzzDnVRMyRvTUmr3QR120ky glLA== X-Gm-Message-State: AA+aEWaUsx8tGvPwq2ldClcxJvVL1MxUN/NV6s6xdllD4eu2ktZfYZlC 3ywTobMBtng33V9240XZBsNUSXj1/7rJ8FiLDHbewQ== X-Google-Smtp-Source: AFSGD/XAGwRtBr8tuBwmcM92/vNOmJxwFG6Pt+hTgMAMUCsjHXCu9SZZ2tcNuNoswKSRxg5oNQ+aVtiQOkm0vG+Ld5A= X-Received: by 2002:a24:8302:: with SMTP id d2mr682549ite.78.1543618336199; Fri, 30 Nov 2018 14:52:16 -0800 (PST) MIME-Version: 1.0 References: <3881693.rR9BVk4Dlq@kitterma-e6430> <20181130214033.GA20002@marwnad.com> In-Reply-To: <20181130214033.GA20002@marwnad.com> From: "Kurt Andersen (b)" Date: Fri, 30 Nov 2018 14:52:04 -0800 Message-ID: To: ezekielh@umich.edu Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000993489057be9a671" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 22:52:19 -0000 --000000000000993489057be9a671 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 30, 2018 at 1:40 PM Zeke Hendrickson wrote: > > I feel that restricting the additional PSD check to nonexistent > organizational domains is the best approach, I disagree...see below > as it preserves the opt-in nature of DMARC, granted > limits privacy concerns, No - this is the very essence of the need for a controlled registry of LPS (longest public suffix) to be checked. It's easy for a human to mistype a domain name and that could result in a report to the LPS's RUA. > remains very straightforward to implement as a verifier, and does not rely > on an > additional list. > Agreed, but the downside is high. > draft-ietf-dmarc-psd-00 addresses a slightly broader problem space Yes, and it is an important additional area to cover IMO --Kurt Andersen --000000000000993489057be9a671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 30= , 2018 at 1:40 PM Zeke Hendrickson <ezekielh@umich.edu> wrote:

I feel that restricting the additional PSD check to nonexistent
organizational domains is the best approach,

I disagree...see below
=C2=A0
as it preserves the opt-in nature of DMARC,

granted
=C2=A0
limits p= rivacy concerns,

No - this is the very ess= ence of the need for a controlled registry of LPS (longest public suffix) t= o be checked. It's
easy for a human to mistype a domain name = and that could result in a report to the LPS's RUA.
=C2=A0
remains very straightforward to implement= as a verifier, and does not rely on an
additional list.

Agreed, but the downsi= de is high.
=C2=A0
draft-ie= tf-dmarc-psd-00 addresses a slightly broader problem space

Yes, and it is an important additional area to cover IMO=C2= =A0

--Kurt Andersen
--000000000000993489057be9a671-- From nobody Fri Nov 30 15:37:34 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8189130EE0 for ; Fri, 30 Nov 2018 15:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=3640dltS; dkim=pass (2048-bit key) header.d=kitterman.com header.b=tDXMUm3x 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 dbTiFQDzXbzc for ; Fri, 30 Nov 2018 15:37:30 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6B81274D0 for ; Fri, 30 Nov 2018 15:37:30 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1543621049; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=kI/b1jOw+EvriXTN9enAP9iH8waV0b+6MP/m4Cw0WfM=; b=3640dltS114Jwza0CiD2Z6ffCaBo7V37mZjQOcfz4o9XqmnaItaAk9Fl gssbgXe8NB+JknfZD420GHnVeM4NAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1543621049; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=kI/b1jOw+EvriXTN9enAP9iH8waV0b+6MP/m4Cw0WfM=; b=tDXMUm3xG/3no4pLkgloNdNTZj28IXMub6TrYtS4zhN4UsS8RAmF9jme R7sIgNW6+gDsIDsgYbfiQITUaKuEpxk3KVx5hJY89nRGz4bUZUrJ6+3dcx SfWKWa67HwQ17bcSQ9OKUPS057xCaUIO7p2ZP/2TmFGKEZLckTfwQBkg01 l1KPvE3UCbZnNBP0qASb+1BNH/GkK9CNYAAR2gI2IWY5/snnSYI+rw+KSP 9N1EhjHPVVO9wDoxUFW6Ld1cbqga0Cebr1w7H0gjYMe0jEf26EJqpbRYZB qVO6Tp0WxhpIH5ogARyj5ECPUpgwaOs43m0CeCJFlUVc/0j5CIf3fg== Received: from [10.20.2.67] (mobile-166-170-35-7.mycingular.net [166.170.35.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 14AF8C4027E; Fri, 30 Nov 2018 17:37:29 -0600 (CST) Date: Fri, 30 Nov 2018 23:37:24 +0000 In-Reply-To: <20181130214033.GA20002@marwnad.com> References: <3881693.rR9BVk4Dlq@kitterma-e6430> <20181130214033.GA20002@marwnad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <7E9366E1-D0E4-4F3F-A45C-854EB475C747@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 30 Nov 2018 23:37:33 -0000 On November 30, 2018 9:40:33 PM UTC, Zeke Hendrickson wrote: >On Wed, Nov 21, 2018 at 02:37:19AM -0500, Scott Kitterman wrote: >> While we were discussing making draft-kitterman-dmarc-psd a working >group=20 >> item, the main discussion point was about the use of an IANA registry >to=20 >> identify participating public suffix domains=2E I think it would be >useful to=20 >> consider what problems we were trying to solve and see if there are=20 >> alternative approaches that address those requirements=2E >>=20 >> Goals: >>=20 >> 1=2E Minimize additional verifier burden for adding PSD DMARC support= =2E >=20 >> Currently it requires consulting a locally stored, infrequently >changing list=20 >> and one additional DNS lookup only for participating public suffixes >when=20 >> there is no organizational domain DMARC record=2E >>=20 >> 2=2E Externalize signaling about PSD participation=2E As discussed in >the=20 >> Privacy Considerations (section 4=2E1), we were concerned about the >privacy=20 >> implications of feedback on organizational domain traffic for >organizational=20 >> domains that don't participate in DMARC being inappropriately >captured by=20 >> public suffix operators=2E In order to avoid this, we identified >criteria for=20 >> which public suffixes PSD DMARC would be appropriate for and require >an=20 >> external review to ensure those criteria are met=2E No solution that's >in DNS=20 >> will address this part of the problem=2E > >I feel that restricting the additional PSD check to nonexistent >organizational domains is the best approach, as it preserves the >opt-in nature of DMARC, limits privacy concerns, remains very >straightforward to implement as a verifier, and does not rely on an >additional list=2E RFC 7489 (DMARC) Appendix A=2E4 mentions that a domain existence test was = tried and abandoned as unreliable=2E Before reconsidering that kind of app= roach, it would be important to understand the limitations that caused it t= o be discarded before=2E As Kurt mentioned, I don't think it solves the registry problem in any cas= e because I don't think wide open TLDs like =2Ecom ought to be stimulating = feedback on any lower level elements of the DNS tree=2E >draft-ietf-dmarc-psd-00 addresses a slightly broader problem space, >but I feel that adding the ability to get feedback on abuse of >nonexistent domains is the most needed aspect; treating branded PSDs >as organizational domains would be better addressed by improving the >way organizational boundaries are determined=2E Currently we have no mechanism at all for that, so I'd be reluctant to aba= ndon the use case in favor of a non-existent solution=2E Also, I think a formal non-existence test would require additional DNS loo= kups and might not even be simpler to implement=2E Scott K From nobody Fri Nov 30 16:33:07 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08111129A87 for ; Fri, 30 Nov 2018 16:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=hRU56lYn; dkim=pass (1536-bit key) header.d=taugh.com header.b=aal/o2jT 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 ignLmuGeQIr3 for ; Fri, 30 Nov 2018 16:33:03 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF133126F72 for ; Fri, 30 Nov 2018 16:33:02 -0800 (PST) Received: (qmail 94510 invoked from network); 1 Dec 2018 00:33:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17126.5c01d6bd.k1811; bh=l8XYEPWI4mJfu7lR0C02c3HiRzzzjDdg6KaZL9Vrpcs=; b=hRU56lYnKyGgLTPignfnarevfUTKDrS2bKr6pyhI2ENrbVUcn/jF2yQ+iX+LEHVFdxptB0SHSXnp1ppqADS2GPG/l/y0RWuMtE6nAzjY+Jg76Jq9zlb0P2zNPbNsswHe3JHWF3y+cEqtbbXL058WSoejnt6NY2ecGhadSGbEdmtAinb8FAeQaVP0BwmsOtgxM9V+bJkb9k+Bsp1EuSrK8Iz5wuUtQVESIuW2DOD/pMKMDjyZX3E8dDuatzF2sJMN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=17126.5c01d6bd.k1811; bh=l8XYEPWI4mJfu7lR0C02c3HiRzzzjDdg6KaZL9Vrpcs=; b=aal/o2jToVoixFf+4xFIRRjVHDv86xuw9j+qWupMaF1278auEZDo2mMgpn8u9J0RRfLjGDaazBTjdkqjbO29J/HiEAjs0RZaDroXy1I9tiVe6JT5s0/wafyEFEpE/hy1QGm0KDn9Ll1DmNOJ88wcG5B6bxUIz74pff3kPQawXp3xoj2dVV0mKF1LkZ2cGubs0gSL0VLfYFRM8BpkcJMw7QQDxEEqUFi3h4HCKWpAKuE9q2dG91NdJXw0czief2Xx Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Dec 2018 00:33:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 1DFFA200915FC3; Fri, 30 Nov 2018 19:33:00 -0500 (EST) Date: 30 Nov 2018 19:33:00 -0500 Message-Id: <20181201003301.1DFFA200915FC3@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <3881693.rR9BVk4Dlq@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2018 00:33:05 -0000 In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write: >2. Externalize signaling about PSD participation. As discussed in the >Privacy Considerations (section 4.1), we were concerned about the privacy >implications of feedback on organizational domain traffic for organizational >domains that don't participate in DMARC being inappropriately captured by >public suffix operators. It seems to me this horse left the barn a long time ago. Mail systems routinely check domains in HELO and in MAIL FROM against DNSBLs, which is at least as loggy as anything a DNS version of this check will do. Also, if you really want to keep people from logging your queries, you can set up a local mirror of the DNS zone, and update it in the usual way with AXFR and IXFR. Whatever one might have in mind for a text version of this, a binary AXFR would be about as fast and IXFR of just the occasional change faster. Take a look at my DBOUND proposal. I think it would be just the ticket for this application. R's, John From nobody Fri Nov 30 17:04:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE825128D68 for ; Fri, 30 Nov 2018 17:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=FObd2/84; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Fn9faUAd 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 3XzPZoT6MG0H for ; Fri, 30 Nov 2018 17:04:08 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC75128CB7 for ; Fri, 30 Nov 2018 17:04:08 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1543626245; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=n8r0aq0nl6LhA6vkgumIcfOYTA7jOq0UQxdshehZPKM=; b=FObd2/84mfBKMT9RX1V3xR1jAP2WkpshgTqKJywY/9AlslnsTaxQfADM nFB/7Fp8xvf+CkbK+19KgmEOdtGYCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1543626245; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=n8r0aq0nl6LhA6vkgumIcfOYTA7jOq0UQxdshehZPKM=; b=Fn9faUAdx60YhKQIFER5tOMxSBU3UfClpGoKGUALlzRvf6ldH2PS7My0 EEPBgx9qb9Bkb44b9g1PTq75cu20VrkJwloq92n3TGJrOhn5CEI8xqitFd hXjEQyW8e6Mr++tLDJZBpknW6uk91Efhs9ClKhQCo7kTcsrJSGPdGOczva YibEFaDbPSND1AW7O94dC8+t9QrcS0MUWWeh5as7lA+ta1xELNC7UdG1jo BA/uLbFIgfbisxKg274LvQHtLtOUwNKB5tlTfzu9wEbHaLNgp38a2qaes5 g9z3r7zQzutqzhg5drcisCK81+axH4RmuPelOaQjqsXSEepBoUOK1Q== Received: from kitterma-e6430.localnet (mobile-166-170-35-7.mycingular.net [166.170.35.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB6F9C40190 for ; Fri, 30 Nov 2018 19:04:04 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 30 Nov 2018 20:04:04 -0500 Message-ID: <6368515.cyHHj4lf58@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20181201003301.1DFFA200915FC3@ary.qy> References: <20181201003301.1DFFA200915FC3@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2018 01:04:10 -0000 On Friday, November 30, 2018 07:33:00 PM John Levine wrote: > In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write: > >2. Externalize signaling about PSD participation. As discussed in the > >Privacy Considerations (section 4.1), we were concerned about the privacy > >implications of feedback on organizational domain traffic for > >organizational domains that don't participate in DMARC being > >inappropriately captured by public suffix operators. > > It seems to me this horse left the barn a long time ago. Mail systems > routinely check domains in HELO and in MAIL FROM against DNSBLs, which > is at least as loggy as anything a DNS version of this check will do. > > Also, if you really want to keep people from logging your queries, you > can set up a local mirror of the DNS zone, and update it in the usual > way with AXFR and IXFR. Whatever one might have in mind for a text > version of this, a binary AXFR would be about as fast and IXFR of just > the occasional change faster. > > Take a look at my DBOUND proposal. I think it would be just the > ticket for this application. I've lost track. Which draft was that? I don't agree that a situation being bad is a reasonable reason not to try and keep it from getting worse. I think the implications of the DMARC feedback reports are greater than logging queries. Scott K From nobody Fri Nov 30 17:06:28 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02B312958B for ; Fri, 30 Nov 2018 17:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QVQ7_LS_im9 for ; Fri, 30 Nov 2018 17:06:25 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 3E691128CB7 for ; Fri, 30 Nov 2018 17:06:25 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id i145so1317382ita.4 for ; Fri, 30 Nov 2018 17:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w7A5x23ApCci/sC3jjLSxtz2r/tHmzrHUI3JJ01Y+mI=; b=JxynrNG92JzmqO5hVF7dUpy+9VH3GyVHARmu4ivSvys/GvM6uxFadzSmsLaUdDLi1B BeVAIlrRbL7ku4S8N4cPSEtJZSI4HIVmd92EKFNMmtroJtvxkrGZe/r2vdRyENKIyOgd 358wdmXpq7rl1VYajZuEgN9cN478aMfWd5hHbnhC5gitldm3TAnSLfqBqRjVj30suw7c Qwc9jsAof0pDl+vz5KeFnMEmrTxVIYgP/Y6FO6Qn8LJd15HyPT48zypqkcCr03lhAU0h XTkdhK4H+P13XMPR54fBDhLeQDZfYzZufsDSLiUQx9VfihvT+FXghvgEP5dJlo14dvS5 tHSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w7A5x23ApCci/sC3jjLSxtz2r/tHmzrHUI3JJ01Y+mI=; b=ADymwT/AAR20StXmJ3iGMKkrg2vBWM3KzfMe1NEwQSnu3Z5BomAQCJ8+ohguikJ7Cl B6wDaEO43NSMbL6bFQtTR952Clcfob6GytNFQGOiQASc6Fd2SMPcHztBeYNcN+b9118/ krzeJx/lMOfoA568j4H14dO9jTiIsYpyLO+qCtVo9J+9lA0yjYj0dd37W5EZq1cojbVu rz1pSw6C7XXsQTZBo1DY5lOZsh/sVvbkjCLfDsN2rBbuyhL3vStNml1ZMKvQYwSNvsG0 XD88SlCvuti2TBzlC1DGMXJ4FGDokb90qFw+QqimJbOuOnC3Vgf1MFT+vF4nC87i7Lnp TPAA== X-Gm-Message-State: AA+aEWYbLP8TixBFlI/fL1GFMHpeuXUDwOHZ6pFGoZ4Nv2c/LzJ6uqho +1KopNzg48pnzSe/9L1B+aa7SYIrEQ++V5MxO4mpqgvX X-Google-Smtp-Source: AFSGD/Wnb8ul0fB3eBjMM8pOAkFsxQutmwIjee/+5RsRCIwVa5Ai7RiYTMDWsbgxZIhsHQs5Oc3yzVooFfAOXPmMBAc= X-Received: by 2002:a02:6019:: with SMTP id i25mr7443068jac.137.1543626384415; Fri, 30 Nov 2018 17:06:24 -0800 (PST) MIME-Version: 1.0 References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> In-Reply-To: <6368515.cyHHj4lf58@kitterma-e6430> From: Tim Wicinski Date: Fri, 30 Nov 2018 20:06:17 -0500 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f1f8e057beb86bd" Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2018 01:06:27 -0000 --0000000000004f1f8e057beb86bd Content-Type: text/plain; charset="UTF-8" https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman wrote: > On Friday, November 30, 2018 07:33:00 PM John Levine wrote: > > In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write: > > >2. Externalize signaling about PSD participation. As discussed in the > > >Privacy Considerations (section 4.1), we were concerned about the > privacy > > >implications of feedback on organizational domain traffic for > > >organizational domains that don't participate in DMARC being > > >inappropriately captured by public suffix operators. > > > > It seems to me this horse left the barn a long time ago. Mail systems > > routinely check domains in HELO and in MAIL FROM against DNSBLs, which > > is at least as loggy as anything a DNS version of this check will do. > > > > Also, if you really want to keep people from logging your queries, you > > can set up a local mirror of the DNS zone, and update it in the usual > > way with AXFR and IXFR. Whatever one might have in mind for a text > > version of this, a binary AXFR would be about as fast and IXFR of just > > the occasional change faster. > > > > Take a look at my DBOUND proposal. I think it would be just the > > ticket for this application. > > I've lost track. Which draft was that? > > I don't agree that a situation being bad is a reasonable reason not to try > and > keep it from getting worse. I think the implications of the DMARC > feedback > reports are greater than logging queries. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004f1f8e057beb86bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri,= Nov 30, 2018 at 8:04 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Friday, November 30, 2018 07:33:00 PM John Levine wrote:
> In article <3881693.rR9BVk4Dlq@kitterma-e6430> you write:
> >2.=C2=A0 Externalize signaling about PSD participation.=C2=A0 As d= iscussed in the
> >Privacy Considerations (section 4.1), we were concerned about the = privacy
> >implications of feedback on organizational domain traffic for
> >organizational domains that don't participate in DMARC being > >inappropriately captured by public suffix operators.
>
> It seems to me this horse left the barn a long time ago.=C2=A0 Mail sy= stems
> routinely check domains in HELO and in MAIL FROM against DNSBLs, which=
> is at least as loggy as anything a DNS version of this check will do.<= br> >
> Also, if you really want to keep people from logging your queries, you=
> can set up a local mirror of the DNS zone, and update it in the usual<= br> > way with AXFR and IXFR.=C2=A0 Whatever one might have in mind for a te= xt
> version of this, a binary AXFR would be about as fast and IXFR of just=
> the occasional change faster.
>
> Take a look at my DBOUND proposal.=C2=A0 I think it would be just the<= br> > ticket for this application.

I've lost track.=C2=A0 Which draft was that?

I don't agree that a situation being bad is a reasonable reason not to = try and
keep it from getting worse.=C2=A0 I think the implications of the DMARC fee= dback
reports are greater than logging queries.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000004f1f8e057beb86bd-- From nobody Fri Nov 30 17:28:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8C130DC4 for ; Fri, 30 Nov 2018 17:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=JKWzHwDl; dkim=pass (2048-bit key) header.d=kitterman.com header.b=kvizbBqC 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 rEuWoaHvD50x for ; Fri, 30 Nov 2018 17:28:08 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5E612D7F8 for ; Fri, 30 Nov 2018 17:28:08 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1543627686; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RxZiidTYSL+hVLqA4m5ePC0gx44953unT+xUHy8iXfg=; b=JKWzHwDlCPde0OwsEUBrmXQcTRKQaoZxHZ6QbOcrMOl4iqqktIGK+bZH T8M/KnauQoenHfR/BKok/Zl5tPepDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1543627686; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=RxZiidTYSL+hVLqA4m5ePC0gx44953unT+xUHy8iXfg=; b=kvizbBqCsxADcd2DSC5EV0c/aMTEVUzLs1J2UksoQYjMhD/jFIeAcHCS nOX9OGvwhssGi+UjXHrf/ypRNFnjzVffUsBlNfpMv0Zned5LbBdCxX6jVQ SSpD6ojl+mXpwQ4qj3elBNi6O2le6F+50GRf316J1ZHQbZAc4GzMtM68Mg Elk4VdYLRXjXNcz8AmIZBR02KaqTSzYa0/6wCjt77f0blwKHE6aCwSvzOo 2Dcha9p9gR5ADX18qPhydH5os8z1TPZ2q/6FIIWtoTFUYeTMDYI4y0P81r FHtlhBrzs6DRlZi5XALkE03Qm9LPJg9uB7pEq+oEVGPG3tUhHcnSzw== Received: from [10.20.2.67] (mobile-166-170-35-7.mycingular.net [166.170.35.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E9ADFC40190; Fri, 30 Nov 2018 19:28:05 -0600 (CST) Date: Sat, 01 Dec 2018 01:27:54 +0000 In-Reply-To: References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2018 01:28:11 -0000 Thanks=2E That refreshes my memory=2E I think it's a proposal that has potential to be an eventual standardized = replacement for using the public suffix and we should look into publishing = a DMARC specific variation=2E It doesn't, however, seem to address the issue described in the draft's pr= ivacy considerations=2E Perhaps we need to step back and see if there is consensus that the privac= y considerations in the draft are substantially correct and if risk mitigat= ion is needed as described=2E Scott K On December 1, 2018 1:06:17 AM UTC, Tim Wicinski = wrote: >https://www=2Eietf=2Eorg/archive/id/draft-levine-dbound-dns-01=2Etxt > > > >On Fri, Nov 30, 2018 at 8:04 PM Scott Kitterman >wrote: > >> On Friday, November 30, 2018 07:33:00 PM John Levine wrote: >> > In article <3881693=2ErR9BVk4Dlq@kitterma-e6430> you write: >> > >2=2E Externalize signaling about PSD participation=2E As discussed >in the >> > >Privacy Considerations (section 4=2E1), we were concerned about the >> privacy >> > >implications of feedback on organizational domain traffic for >> > >organizational domains that don't participate in DMARC being >> > >inappropriately captured by public suffix operators=2E >> > >> > It seems to me this horse left the barn a long time ago=2E Mail >systems >> > routinely check domains in HELO and in MAIL FROM against DNSBLs, >which >> > is at least as loggy as anything a DNS version of this check will >do=2E >> > >> > Also, if you really want to keep people from logging your queries, >you >> > can set up a local mirror of the DNS zone, and update it in the >usual >> > way with AXFR and IXFR=2E Whatever one might have in mind for a text >> > version of this, a binary AXFR would be about as fast and IXFR of >just >> > the occasional change faster=2E >> > >> > Take a look at my DBOUND proposal=2E I think it would be just the >> > ticket for this application=2E >> >> I've lost track=2E Which draft was that? >> >> I don't agree that a situation being bad is a reasonable reason not >to try >> and >> keep it from getting worse=2E I think the implications of the DMARC >> feedback >> reports are greater than logging queries=2E >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc >>