From nobody Mon Feb 3 10:48:04 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9291200B4 for ; Mon, 3 Feb 2020 10:48:02 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 f5wfcjrUl997 for ; Mon, 3 Feb 2020 10:48:00 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 8F910120072 for ; Mon, 3 Feb 2020 10:47:57 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id g15so9662528vsf.1 for ; Mon, 03 Feb 2020 10:47:57 -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=L0Nqfj2c+xldqdGOYF5KQ1dL0QLsmyyM4DvtyOsTKdk=; b=QKpFkt0hHWHIxiqyxLS3UVb+TJyPDd2Q3X6qbjCGD1PqP0d3Ga7jFJ2RXpAfV10zBb 3cQZOXjh+RQ9+dQYNc78rcaMLesMpWZVyV3i/K6EBHBw1WQkUWyaYyBF2Klq9h/Tg/4w 4FvV1U3KeMSUcB2b2K4p5FWxbX+UCR9HCjdQhOse2bCiMqG4vur5VTSlMwj+8JolWaaJ 1CgGD/REfSdaHZEuxlfNJbQnvi35/e6dfeERaPN17Ct8veBWzivFE+XDX4ko+vsvEHla cFd7WENBelusaeqXVR6V4zhn4K8+1UUfkit+KG9vNqg9oCQWgqcjZED5T6OzlJ3IbxoV m6zg== 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=L0Nqfj2c+xldqdGOYF5KQ1dL0QLsmyyM4DvtyOsTKdk=; b=LDuVNYbIjP6PLzTNMSDPpcDVNGauvXT4gObbbc434T7//WpRa6S9ywb4AVvAlOrQQL svf5P6dwT/Y3zymRcqANyL75h7Pr6n+zfh55BbVvXNFkHpC08tdeOnSSuFO429XYa9Z+ JYU34t1DdlKHx0d2e0lCPgDiBKu1vvpcBVK6x5nD/Yjr//e5Lw9BQbTQrfERHBuwA0+f FDOu9rFAwZblTjSoeaRi5MlcsJyZraBtF26hAYJa2JFB58sV0hCl/NuGFDYCoflfgPuL o2dW5J2x2sV5XYlUHwPMlXGw2oIzME4KX3BPzpg3jAHgN5u4cv3qyeozmZek08llagK8 SBQg== X-Gm-Message-State: APjAAAWIcRHX/rxidYD6M+nKhIBsmbDmBDuN9v0GszXTPAKxDgR0580c fc1UbEWSaN5vu4cgkoKm9/Mdu51uVJGgMV9/tho= X-Google-Smtp-Source: APXvYqyIznYRPIGisplvzVkDI6+/Dtw5nMtEaQvf7KT0UGhxn8XgSWG4mRu/abT3pwcnqk9FWmN7icMIaTniF1iy1HQ= X-Received: by 2002:a67:ce86:: with SMTP id c6mr16439179vse.7.1580755676364; Mon, 03 Feb 2020 10:47:56 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> From: "Murray S. Kucherawy" Date: Mon, 3 Feb 2020 10:47:45 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="0000000000009103c7059db05ccf" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Mon, 03 Feb 2020 18:48:03 -0000 --0000000000009103c7059db05ccf Content-Type: text/plain; charset="UTF-8" Dave, On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker wrote: > Nothing I've worked on at the IETF with such a label is something I would > necessarily stand behind as Internet-scalable. > > Such as? > RFC 6541 comes to mind. To the best of my knowledge, it's an experiment that never even ran. Implementations shipped, but its use on the open Internet was never detected or reported. And I had my doubts about the scalability of the second DNS check that was added to it, but it didn't seem like it could go forward without. One that wasn't mine: RFC 6210, an experiment to prove how bad something can be. > > But I would probably expect something at Informational probably to scale, > and anything with "Standard" in it certainly to scale. > > Laying any general expectation on an IETF Informational RFC would be a > mistake, because there is so much variety in their content and intent. > Why would the expectations for Experimental be higher than for Informational? LMTP is Informational, and it certainly needs to succeed. > So: Can you propose any sort of specific restructuring of the document or > the experiment that achieves the same goal as the current version while > also resolving your concerns? > > I'm pretty sure I've raised fundamental concerns about this work and that > those concerns have not been addressed. The simple summary is that the way > to restructure this work is to go back to first principles. But there > doesn't seem to be any interest in having that sort of discussion. > I thought we were having that sort of a discussion right here. Your position as I recall is that we have no choice but to take all of this back to first principles and separate DMARC from the determination of Organizational Domain (i.e., make them separate documents) before PSD can proceed. Since that will take months, I've proposed a compromise, because I don't think that's strictly necessary to allow the data collection work to proceed. The proposed compromise, then, is to do the work in hand, then rip the experiment down and apply whatever we learn from it to standards track DMARC, which is the next milestone. That will include the separation of function you proposed, because we agree it's an improvement. I believe the set of likely participants in the experiment are present on the list, and it can be made clear to them that they should have no expectation of the mechanism it describes surviving past the termination of the experiment. So the path forward here comes down to whether the working group achieves consensus on that compromise, or whether the asserted risk of the experiment's structure leaking into the permanent deployed base warrants shutting it down before it starts. Now, to the working group as a whole: The chairs note that we have a duly and properly completed WGLC in hand. Still, Dave's concerns have validity, so they need to be considered by the working group. Since we need to do *something*, we are now putting the question back to the working group, and we need to see some answers. The chairs will not accept hearsay replies or opinions, or expressions of needing this work but not knowing how to engage; you either give your feedback on the list or privately to the chairs or Area Directors, or you are along for whatever ride results. Please indicate, as soon as possible, where your support lies given the above. We're not going to let this go additional months (probably not even weeks) without progress in some direction. I will also say for the record that we don't find compelling the assertion that resources will not be dedicated to the experiment absent a document in the RFC Editor queue. That constraint is fully external to the IETF, and it will carry no weight in the decision made here. It should indeed be possible to run an experiment based on a document in any state at all. We're entertaining publication not because it must happen, but because that action (currently) has consensus, and it's our job to act on consensus. Dave also made an additional observation, that experiments expected to fail are not generally what the IETF produces. I would quibble some with that wording: The working group doesn't expect the experiment to "fail", but rather expects it to be ephemeral. Were we to refer to chapter-and-verse, there's nothing in RFC2026 (which defines "Experimental" as a document status) that precludes what the working group appears to be trying to do here. As for whether the IETF generally should produce an Experimental document describing something ephemeral, I would claim that a working group or its chairs are below the pay grade where authoritative claims like those are made; it's the kind of thing about which the IESG makes proclamations. Accordingly, I've Cc'd our current Area Director to see what he thinks might happen if we were to send this up, and give him a chance to provide guidance in case that's the decision (but we won't wait long for that either). > The real challenge for most IETF specs is community engagement, not >> engineering adequacy. >> > > Interestingly I would claim we have clearly achieved the former here, > though obviously not the latter. > > My sense is -- as has become common in the IETF -- an extremely small core > of folk interesting in promoting this work, rather than extensive community > interest. > That's probably true, but by that argument we should just terminate most of the email-related working groups because the critical mass we can get today is a fraction of what it used to be. Those sorts of existential questions can't be answered at this level, however. I would claim the working group was chartered with the understanding that the participation here won't be like it was for, say, DKIM, or DRUMS, etc. We're not in a position to fix that here. We have a job to do, and we need to get moving again. -MSK --0000000000009103c7059db05ccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave,

On Fri, Jan 17, 2020 at 8:44= AM Dave Crocker <dcrocker@gmail.c= om> wrote:
Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable.=C2=A0

Such as?


RFC 6541 comes to= mind.=C2=A0 To the best of my knowledge, it's an experiment that never= even ran.=C2=A0 Implementations shipped, but its use on the open Internet = was never detected or reported.=C2=A0 And I had my doubts about the scalabi= lity of the second DNS check that was added to it, but it didn't seem l= ike it could go forward without.

One that wasn't mine= : RFC 6210, an experiment to prove how bad something can be.


But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.

Why would the expectations for E= xperimental be higher than for Informational?=C2=A0 LMTP is Informational, = and it certainly needs to succeed.
So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?
=20

I'm pretty sure I've raised fundamental concerns about this = work and that those concerns have not been addressed.=C2=A0 The simple summary is that the way to restructure this work is to go back to first principles.=C2=A0 But there doesn't seem to be any interest= in having that sort of discussion.

I thought = we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of t= his back to first principles and separate DMARC from the determination of O= rganizational Domain (i.e., make them separate documents) before PSD can pr= oceed.=C2=A0 Since that will take months, I've proposed a compromise, b= ecause I don't think that's strictly necessary to allow the data co= llection work to proceed.=C2=A0 The proposed compromise, then, is to do the= work in hand, then rip the experiment down and apply whatever we learn fro= m it to standards track DMARC, which is the next milestone.=C2=A0 That will= include the separation of function you proposed, because we agree it's= an improvement.=C2=A0 I believe the set of likely participants in the expe= riment are present on the list, and it can be made clear to them that they = should have no expectation of the mechanism it describes surviving past the= termination of the experiment.=C2=A0 So the path forward here comes down t= o whether the working group achieves consensus on that compromise, or wheth= er the asserted risk of the experiment's structure leaking into the per= manent deployed base warrants shutting it down before it starts.
<= div>
Now, to the working group as a whole:

= The chairs note that we have a duly and properly completed WGLC in hand.=C2= =A0 Still, Dave's concerns have validity, so they need to be considered= by the working group.=C2=A0 Since we need to do *something*, we are now pu= tting the question back to the working group, and we need to see some answe= rs.=C2=A0 The chairs will not accept hearsay replies or opinions, or expres= sions of needing this work but not knowing how to engage; you either give y= our feedback on the list or privately to the chairs or Area Directors, or y= ou are along for whatever ride results.=C2=A0 Please indicate, as soon as p= ossible, where your support lies given the above.=C2=A0 We're not going= to let this go additional months (probably not even weeks) without progres= s in some direction.

I will also say for the record that = we don't find compelling the assertion that resources will not be dedic= ated to the experiment absent a document in the RFC Editor queue.=C2=A0 Tha= t constraint is fully external to the IETF, and it will carry no weight in = the decision made here.=C2=A0 It should indeed be possible to run an experi= ment based on a document in any state at all.=C2=A0 We're entertaining = publication not because it must happen, but because that action (currently)= has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected= to fail are not generally what the IETF produces.=C2=A0 I would quibble so= me with that wording: The working group doesn't expect the experiment t= o "fail", but rather expects it to be ephemeral.=C2=A0 Were we to= refer to chapter-and-verse, there's nothing in RFC2026 (which defines = "Experimental" as a document status) that precludes what the work= ing group appears to be trying to do here.=C2=A0 As for whether the IETF ge= nerally should produce an Experimental document describing something epheme= ral, I would claim that a working group or its chairs are below the pay gra= de where authoritative claims like those are made; it's the kind of thi= ng about which the IESG makes proclamations.=C2=A0 Accordingly, I've Cc= 'd our current Area Director to see what he thinks might happen if we w= ere to send this up, and give him a chance to provide guidance in case that= 's the decision (but we won't wait long for that either).
=


The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I would claim we have clearly achieved the former here, though obviously not the latter.
=20

My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.

That's p= robably true, but by that argument we should just terminate most of the ema= il-related working groups because the critical mass we can get today is a f= raction of what it used to be.

Those sorts of exis= tential questions can't be answered at this level, however.=C2=A0 I wou= ld claim the working group was chartered with the understanding that the pa= rticipation here won't be like it was for, say, DKIM, or DRUMS, etc.=C2= =A0 We're not in a position to fix that here.=C2=A0 We have a job to do= , and we need to get moving again.

-MSK
<= /div> --0000000000009103c7059db05ccf-- From nobody Mon Feb 3 11:51:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61921200A3 for ; Mon, 3 Feb 2020 11:51:54 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_i-ybGb2nkk for ; Mon, 3 Feb 2020 11:51:51 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110130.outbound.protection.outlook.com [40.107.11.130]) (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 6DE1F12012D for ; Mon, 3 Feb 2020 11:51:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIrIivnzFMJrvly9ZAUmANO9ilJjPbmhPE0J+Fgdzrhc59EXcWzN9hkpvCw5D7GlVj6Rc1RsuHqMEgULJb/M1Y5C68waekNo9vdw69J57Uvv+AU2atKMJOWg7FU1kfkY/ocp4OzWpn16ksmZGAZ98oLICzsA8t/7hjk/T2HqjZfIJZYWUmOTToRdsV0mNIcmE/pXR/9HkTOdFLwNjEsx15Teeev0kJ/ZKC8ObVLU1nnaBAw8Rn6+li5a+9OifPJMZSCNMgMJGdIZbi8Po2nLizaqmqgizaHsVIG0kSOQwnEHTvCsnn+rn/raYBhuMW7N43/WJ1PtyE0pu4Eqy+7D8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lbxSvPzSnWU5r0hI7GD0J9VC4KtX+tijvNQMhvsNr4A=; b=fZ793AFUTGcRN5nfT6JStzRnI09GZzd+x5sNCaj2c0nueW1eK15MxHRrk0/IZL3AB4WfJWbarec0DIfcBJsTn0uqjf3dcuzF1GVQan6SXFIpAntCCEYjN5woMpACaKgxpbI4CY19G4OgziO2LnqhzZ3TMd5P5nBIwgWR9sorKNlexbI4/yueIQeD0rvaoQ/5W18DfiHjWP5dp0ScO+T927rS+Cb+UeCaRrEdNyEPzCCRt/pyhov3PRsd4X6nTipNDm+yWiZFaV2hMMpSf4qvyKeXCzDVI6NTpFJclRtyQmYQDOKX8a9IrxM4oU8HNIIYFwftwSmqsAMoq7oG5dGWwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lbxSvPzSnWU5r0hI7GD0J9VC4KtX+tijvNQMhvsNr4A=; b=TBFbJIJ5gpvrt/fhe9xGY0I/90SEoaP8Y59HERsiyxW0RE2z/87zl8xdcmyCXX7x418fdAo+GsJ/lzPIZkLD6x0Bmgnq5tkLrGQiO/DpWc63mXddHkt5Er+pM5Zv7lSH395BFD2jBna5IKO7oQ2xIojr39m3aZd2eWBSAsMrkdk= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2592.GBRP123.PROD.OUTLOOK.COM (20.176.154.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.30; Mon, 3 Feb 2020 19:51:48 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::458:e94e:72f4:3803]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::458:e94e:72f4:3803%7]) with mapi id 15.20.2686.031; Mon, 3 Feb 2020 19:51:48 +0000 From: Ian Levy To: "Murray S. Kucherawy" , Dave Crocker CC: IETF DMARC WG , Alexey Melnikov Thread-Topic: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Thread-Index: AQHVUkRUHW06UOOZ+kq6kqLLLMMrLqcaPC6AgANurWOAaHWPgIAADzIAgAAY2wCAAGFPgIAAblcAgCMwBICACHMnAIA8uiWAgACQy4CAGtoXgIAAETUF Date: Mon, 3 Feb 2020 19:51:48 +0000 Message-ID: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.140.114.144] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1adab8d4-10d8-43d0-ec3b-08d7a8e281b6 x-ms-traffictypediagnostic: LO2P123MB2592: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(39850400004)(346002)(376002)(396003)(199004)(189003)(44832011)(53546011)(6506007)(186003)(110136005)(86362001)(52536014)(2906002)(8936002)(8676002)(316002)(478600001)(26005)(64756008)(66556008)(66476007)(76116006)(66574012)(66946007)(66446008)(81166006)(54906003)(81156014)(55236004)(33656002)(71200400001)(4326008)(5660300002)(9686003)(55016002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2592; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3vrNdYdcTW454LETGnY2lkRsijoEu8kK7aA2WYw/MSqoyfIhCbVkOEYtIW7ELIJww6n1rWJfow8blV/gY62ez2OHwF16e+/oLS4H3qnzzYxKnSlizutIlqix76XxefotQk1v8Kza6NeBPanADJBw7eCSHMwpxwBZGhmCS1Q0xeeAA30hg95baEfL1tX0v5CqXCY/BW5sG2Bm0cu3y8s47QliwZVIs3JQRgPuFidW62LS2f9MoTiZ73xdbV1rarg90Sp70HD/e83k5NBHPxzEXU/FFWCMNml6QVigXtbhnHRglMyhIPwZELt/YVZ/IQGrfxFdLxPzrbjUldx8NL4SREbxNFf5rw5uQQfSFHYPLahfpvk8RZ0rPsUPzy5ew6PlKnrnqDBVSL/HDX3K9oPg50Ju7N9awGRw7kJWQh7qw+b28m6bBmhHyZKc7ZaUbcZS x-ms-exchange-antispam-messagedata: 1An2DvLi25FFwBNSwXOXn7Fx0ZIAYAeQctLiKSDs2odsYn+z1WZqH1OzIQ+uPfibODzSk5vNgG/QukqS5qa+0yVej1CE7o3drUbdlMDqKn1XPWHrMveoZPiT5Qqm58yt+HuUdZryFHcF9nSRwrsQ0w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB2285E848D3C1DC603C0F0538C9000LO2P123MB2285GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 1adab8d4-10d8-43d0-ec3b-08d7a8e281b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2020 19:51:48.7469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: t7uDB6aqokLjuC7A2LeM3c/+iEUksc7rI3lD8FjKyLSNZfEoHG9EMFacu8jzMMc5NtQTs5WCLqh3I/BQkBnUJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2592 Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Mon, 03 Feb 2020 19:51:55 -0000 --_000_LO2P123MB2285E848D3C1DC603C0F0538C9000LO2P123MB2285GBRP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > I believe the set of likely participants in the experiment > are present on the list, and it can be made clear to > them that they should have no expectation of the > mechanism it describes surviving past the termination > of the experiment. I believe I represent one of those participants and I=92m happy with Murray= =92s caution. Experiments will give us data that helps us make better solut= ions in the future. If those solutions look like the current draft then gre= at. If they don=92t then we=92ll be changing them based on data and experie= nce. Surely that=92s a good outcome for all?? Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk Staff officer : Tracy, Tracy.l@ncsc.gov.uk or 07468 837625 Assistant : Rose, rose.p@ncsc.gov.uk Pronouns : he/him (I work stupid hours and weird times =96 that doesn=92t mean you have to. I= f this arrives outside your normal working hours, don=92t feel compelled to= respond immediately!) ________________________________ From: dmarc on behalf of Murray S. Kucherawy Sent: Monday, February 3, 2020 6:47:45 PM To: Dave Crocker Cc: IETF DMARC WG ; Alexey Melnikov Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Dave, On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker > wrote: Nothing I've worked on at the IETF with such a label is something I would n= ecessarily stand behind as Internet-scalable. Such as? RFC 6541 comes to mind. To the best of my knowledge, it's an experiment th= at never even ran. Implementations shipped, but its use on the open Intern= et was never detected or reported. And I had my doubts about the scalabili= ty of the second DNS check that was added to it, but it didn't seem like it= could go forward without. One that wasn't mine: RFC 6210, an experiment to prove how bad something ca= n be. But I would probably expect something at Informational probably to scale, a= nd anything with "Standard" in it certainly to scale. Laying any general expectation on an IETF Informational RFC would be a mist= ake, because there is so much variety in their content and intent. Why would the expectations for Experimental be higher than for Informationa= l? LMTP is Informational, and it certainly needs to succeed. So: Can you propose any sort of specific restructuring of the document or t= he experiment that achieves the same goal as the current version while also= resolving your concerns? I'm pretty sure I've raised fundamental concerns about this work and that t= hose concerns have not been addressed. The simple summary is that the way = to restructure this work is to go back to first principles. But there does= n't seem to be any interest in having that sort of discussion. I thought we were having that sort of a discussion right here. Your position as I recall is that we have no choice but to take all of this= back to first principles and separate DMARC from the determination of Orga= nizational Domain (i.e., make them separate documents) before PSD can proce= ed. Since that will take months, I've proposed a compromise, because I don= 't think that's strictly necessary to allow the data collection work to pro= ceed. The proposed compromise, then, is to do the work in hand, then rip t= he experiment down and apply whatever we learn from it to standards track D= MARC, which is the next milestone. That will include the separation of fun= ction you proposed, because we agree it's an improvement. I believe the se= t of likely participants in the experiment are present on the list, and it = can be made clear to them that they should have no expectation of the mecha= nism it describes surviving past the termination of the experiment. So the= path forward here comes down to whether the working group achieves consens= us on that compromise, or whether the asserted risk of the experiment's str= ucture leaking into the permanent deployed base warrants shutting it down b= efore it starts. Now, to the working group as a whole: The chairs note that we have a duly and properly completed WGLC in hand. S= till, Dave's concerns have validity, so they need to be considered by the w= orking group. Since we need to do *something*, we are now putting the ques= tion back to the working group, and we need to see some answers. The chair= s will not accept hearsay replies or opinions, or expressions of needing th= is work but not knowing how to engage; you either give your feedback on the= list or privately to the chairs or Area Directors, or you are along for wh= atever ride results. Please indicate, as soon as possible, where your supp= ort lies given the above. We're not going to let this go additional months= (probably not even weeks) without progress in some direction. I will also say for the record that we don't find compelling the assertion = that resources will not be dedicated to the experiment absent a document in= the RFC Editor queue. That constraint is fully external to the IETF, and = it will carry no weight in the decision made here. It should indeed be pos= sible to run an experiment based on a document in any state at all. We're = entertaining publication not because it must happen, but because that actio= n (currently) has consensus, and it's our job to act on consensus. Dave also made an additional observation, that experiments expected to fail= are not generally what the IETF produces. I would quibble some with that = wording: The working group doesn't expect the experiment to "fail", but rat= her expects it to be ephemeral. Were we to refer to chapter-and-verse, the= re's nothing in RFC2026 (which defines "Experimental" as a document status)= that precludes what the working group appears to be trying to do here. As= for whether the IETF generally should produce an Experimental document des= cribing something ephemeral, I would claim that a working group or its chai= rs are below the pay grade where authoritative claims like those are made; = it's the kind of thing about which the IESG makes proclamations. According= ly, I've Cc'd our current Area Director to see what he thinks might happen = if we were to send this up, and give him a chance to provide guidance in ca= se that's the decision (but we won't wait long for that either). The real challenge for most IETF specs is community engagement, not engineering adequacy. Interestingly I would claim we have clearly achieved the former here, thoug= h obviously not the latter. My sense is -- as has become common in the IETF -- an extremely small core = of folk interesting in promoting this work, rather than extensive community= interest. That's probably true, but by that argument we should just terminate most of= the email-related working groups because the critical mass we can get toda= y is a fraction of what it used to be. Those sorts of existential questions can't be answered at this level, howev= er. I would claim the working group was chartered with the understanding t= hat the participation here won't be like it was for, say, DKIM, or DRUMS, e= tc. We're not in a position to fix that here. We have a job to do, and we= need to get moving again. -MSK This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB2285E848D3C1DC603C0F0538C9000LO2P123MB2285GBRP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
> I believe the set of likely participant= s in the experiment
> are present on the list, and it can be = made clear to
> them that they should have no expectati= on of the
> mechanism it describes surviving past t= he termination
> of the experiment.

I believe I represent one of those participa= nts and I=92m happy with Murray=92s caution. Experiments will give us data = that helps us make better solutions in the future. If those solutions look = like the current draft then great. If they don=92t then we=92ll be changing them based on data and experience. <= /div>

Surely that=92s a good outcome for all??

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk

Staff officer : Tracy, Tracy.l@ncsc.gov.uk o= r 07468 837625
Assistant : Rose, rose.p@ncsc.gov.uk

Pronouns : he/him
(I work stupid hours and weird times =96 tha= t doesn=92t mean you have to. If this arrives outside your normal working h= ours, don=92t feel compelled to respond immediately!)
From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Murray S. Kucherawy <superuser@gmail.com>= ;
Sent: Monday, February 3, 2020 6:47:45 PM
To: Dave Crocker <dcrocker@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>; Alexey Melnikov <aameln= ikov@fastmail.fm>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
 
Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <dcrocker@gmail.com> wrote:
Nothing I've worked on at the IETF with such a label is something I wo= uld necessarily stand behind as Internet-scalable. 

Such as?


RFC 6541 comes to mind.  To the best of my knowledge, it's an exp= eriment that never even ran.  Implementations shipped, but its use on = the open Internet was never detected or reported.  And I had my doubts= about the scalability of the second DNS check that was added to it, but it didn't seem like it could go forward without.=

One that wasn't mine: RFC 6210, an experiment to prove how bad somethi= ng can be.


But I would probably expect something at Informational probably to sca= le, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mist= ake, because there is so much variety in their content and intent.

Why would the expectations for Experimental be higher than for Informa= tional?  LMTP is Informational, and it certainly needs to succeed.
So: Can you propose any sort of specific restr= ucturing of the document or the experiment that achieves the same goal as t= he current version while also resolving your concerns?

I'm pretty sure I've raised fundamental concerns about this work and tha= t those concerns have not been addressed.  The simple summary is that = the way to restructure this work is to go back to first principles.  B= ut there doesn't seem to be any interest in having that sort of discussion.

I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of= this back to first principles and separate DMARC from the determination of= Organizational Domain (i.e., make them separate documents) before PSD can = proceed.  Since that will take months, I've proposed a compromise, because I don't think that's strictly necessar= y to allow the data collection work to proceed.  The proposed compromi= se, then, is to do the work in hand, then rip the experiment down and apply= whatever we learn from it to standards track DMARC, which is the next milestone.  That will include the sepa= ration of function you proposed, because we agree it's an improvement. = ; I believe the set of likely participants in the experiment are present on= the list, and it can be made clear to them that they should have no expectation of the mechanism it describes survivi= ng past the termination of the experiment.  So the path forward here c= omes down to whether the working group achieves consensus on that compromis= e, or whether the asserted risk of the experiment's structure leaking into the permanent deployed base warrants s= hutting it down before it starts.

Now, to the working group as a whole:

The chairs note that we have a duly and properly completed WGLC in han= d.  Still, Dave's concerns have validity, so they need to be considere= d by the working group.  Since we need to do *something*, we are now p= utting the question back to the working group, and we need to see some answers.  The chairs will not accept hearsay = replies or opinions, or expressions of needing this work but not knowing ho= w to engage; you either give your feedback on the list or privately to the = chairs or Area Directors, or you are along for whatever ride results.  Please indicate, as soon as possibl= e, where your support lies given the above.  We're not going to let th= is go additional months (probably not even weeks) without progress in some = direction.

I will also say for the record that we don't find compelling the asser= tion that resources will not be dedicated to the experiment absent a docume= nt in the RFC Editor queue.  That constraint is fully external to the = IETF, and it will carry no weight in the decision made here.  It should indeed be possible to run an exper= iment based on a document in any state at all.  We're entertaining pub= lication not because it must happen, but because that action (currently) ha= s consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected to= fail are not generally what the IETF produces.  I would quibble some = with that wording: The working group doesn't expect the experiment to "= ;fail", but rather expects it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in RFC2026 (which d= efines "Experimental" as a document status) that precludes what t= he working group appears to be trying to do here.  As for whether the = IETF generally should produce an Experimental document describing something ephemeral, I would claim that a working group or its = chairs are below the pay grade where authoritative claims like those are ma= de; it's the kind of thing about which the IESG makes proclamations.  = Accordingly, I've Cc'd our current Area Director to see what he thinks might happen if we were to send this up, an= d give him a chance to provide guidance in case that's the decision (but we= won't wait long for that either).


The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I would claim we have clearly achieved the former here, = though obviously not the latter.

My sense is -- as has become common in the IETF -- an extremely small co= re of folk interesting in promoting this work, rather than extensive commun= ity interest.

That's probably true, but by that argument we should just terminate mo= st of the email-related working groups because the critical mass we can get= today is a fraction of what it used to be.

Those sorts of existential questions can't be answered at this level, = however.  I would claim the working group was chartered with the under= standing that the participation here won't be like it was for, say, DKIM, o= r DRUMS, etc.  We're not in a position to fix that here.  We have a job to do, and we need to get moving aga= in.

-MSK
This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9
--_000_LO2P123MB2285E848D3C1DC603C0F0538C9000LO2P123MB2285GBRP_-- From nobody Mon Feb 3 16:25:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5FE1200B1 for ; Mon, 3 Feb 2020 16:25:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 eaW8bkuyu2uS for ; Mon, 3 Feb 2020 16:25:20 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 90291120025 for ; Mon, 3 Feb 2020 16:24:43 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id m16so20673221wrx.11 for ; Mon, 03 Feb 2020 16:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XKl+Ub2r4X8f9e/3j+IQMF+ImMKGU0zKD6Ek6vOi3uM=; b=QZIw6jRf7cJel1dgNJIGN2vxkKcKJOOHaU9b5Cs23TFPm96JU4bC1X5FqEbKhDHWnU ygjGPznFmvUJ+55KOYSIUYGigG1rmUHkZKx8QsUbqdzTizm8mF5uY+xlDD4Coq5zG3Bb UG2PkNVpmqcsqdCBMubh9xlNJVsHP/FUn+MkA= 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=XKl+Ub2r4X8f9e/3j+IQMF+ImMKGU0zKD6Ek6vOi3uM=; b=rY6CF8GoWQYxoUsFA/GsK4K8ulLzQtyGOungbVNU5ZEGEPbXsn3DlcZyIqwNguJeSx sV83qnz9Dlfky2Ax0cVU/21Jt6nz78OzQTCtuVGY79rSJ57BKCEUgjuXEjT/VlnnAszU es1N2wx132cSojeaSqwtmO6RX53WnuVsBI1azVT66VusxsGsShafls9qeetmqdliXFtd 0mNkSIGuDzQvja7yy2iyRLLMchLfO/qH6KMJnAa0c5RNBSR1SbsYd/zHUsGMwbRqNw6C jz8jIoLNTdXNHS6AQQD+ThMDhGVIWgfxTngk6W9R87dKd5bifBqNNo32VnoGAhY1BOjs Ib3Q== X-Gm-Message-State: APjAAAW0PphOv7CgCYT3Rwet7bbqbNi7iRuDPqTYk05LuaiZ2rVQ5gSa iulvpbjIwx/24Y7VfjRxEXUZptyw4tGCa/iDayfxOw== X-Google-Smtp-Source: APXvYqxdcTZDlUugM3Eqie+6azBb2zfuSjdvObSW/Rwthf265XlxuRfACX1WsRGJQRizt1EzMC5N9fZHyMK7uv5hRMQ= X-Received: by 2002:a5d:61cb:: with SMTP id q11mr19361436wrv.71.1580775882067; Mon, 03 Feb 2020 16:24:42 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: Craig Schwartz Date: Mon, 3 Feb 2020 19:21:25 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Dave Crocker , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000eba6b8059db51018" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 00:25:23 -0000 --000000000000eba6b8059db51018 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Murray, <<>> In my capacity as managing director of fTLD Registry Services (fTLD), registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would provide invaluable threat intelligence to domain registrants and to TLD administrators like ourselves for NXDOMAINs. PSD has tremendous value to specialized TLDs including, but not limited to, .BRANDS, community-based domains, high-security domains, governments, etc. and as such I believe PSD should proceed. I=E2=80=99ve previously posted to this list expressing this= view and while fTLD cannot participate in experimentation due to a prohibition by ICANN, we remain committed to supporting and seeing this work continue. Sincerely, Craig *--* Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Office: +1 202 589 2532 Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy wrote: > Dave, > > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker wrote: > >> Nothing I've worked on at the IETF with such a label is something I woul= d >> necessarily stand behind as Internet-scalable. >> >> Such as? >> > > RFC 6541 comes to mind. To the best of my knowledge, it's an experiment > that never even ran. Implementations shipped, but its use on the open > Internet was never detected or reported. And I had my doubts about the > scalability of the second DNS check that was added to it, but it didn't > seem like it could go forward without. > > One that wasn't mine: RFC 6210, an experiment to prove how bad something > can be. > >> >> But I would probably expect something at Informational probably to scale= , >> and anything with "Standard" in it certainly to scale. >> >> Laying any general expectation on an IETF Informational RFC would be a >> mistake, because there is so much variety in their content and intent. >> > > Why would the expectations for Experimental be higher than for > Informational? LMTP is Informational, and it certainly needs to succeed. > >> So: Can you propose any sort of specific restructuring of the document o= r >> the experiment that achieves the same goal as the current version while >> also resolving your concerns? >> >> I'm pretty sure I've raised fundamental concerns about this work and tha= t >> those concerns have not been addressed. The simple summary is that the = way >> to restructure this work is to go back to first principles. But there >> doesn't seem to be any interest in having that sort of discussion. >> > I thought we were having that sort of a discussion right here. > > Your position as I recall is that we have no choice but to take all of > this back to first principles and separate DMARC from the determination o= f > Organizational Domain (i.e., make them separate documents) before PSD can > proceed. Since that will take months, I've proposed a compromise, becaus= e > I don't think that's strictly necessary to allow the data collection work > to proceed. The proposed compromise, then, is to do the work in hand, th= en > rip the experiment down and apply whatever we learn from it to standards > track DMARC, which is the next milestone. That will include the separati= on > of function you proposed, because we agree it's an improvement. I believ= e > the set of likely participants in the experiment are present on the list, > and it can be made clear to them that they should have no expectation of > the mechanism it describes surviving past the termination of the > experiment. So the path forward here comes down to whether the working > group achieves consensus on that compromise, or whether the asserted risk > of the experiment's structure leaking into the permanent deployed base > warrants shutting it down before it starts. > > Now, to the working group as a whole: > > The chairs note that we have a duly and properly completed WGLC in hand. > Still, Dave's concerns have validity, so they need to be considered by th= e > working group. Since we need to do *something*, we are now putting the > question back to the working group, and we need to see some answers. The > chairs will not accept hearsay replies or opinions, or expressions of > needing this work but not knowing how to engage; you either give your > feedback on the list or privately to the chairs or Area Directors, or you > are along for whatever ride results. Please indicate, as soon as possibl= e, > where your support lies given the above. We're not going to let this go > additional months (probably not even weeks) without progress in some > direction. > > I will also say for the record that we don't find compelling the assertio= n > that resources will not be dedicated to the experiment absent a document = in > the RFC Editor queue. That constraint is fully external to the IETF, and > it will carry no weight in the decision made here. It should indeed be > possible to run an experiment based on a document in any state at all. > We're entertaining publication not because it must happen, but because th= at > action (currently) has consensus, and it's our job to act on consensus. > > Dave also made an additional observation, that experiments expected to > fail are not generally what the IETF produces. I would quibble some with > that wording: The working group doesn't expect the experiment to "fail", > but rather expects it to be ephemeral. Were we to refer to > chapter-and-verse, there's nothing in RFC2026 (which defines "Experimenta= l" > as a document status) that precludes what the working group appears to be > trying to do here. As for whether the IETF generally should produce an > Experimental document describing something ephemeral, I would claim that = a > working group or its chairs are below the pay grade where authoritative > claims like those are made; it's the kind of thing about which the IESG > makes proclamations. Accordingly, I've Cc'd our current Area Director to > see what he thinks might happen if we were to send this up, and give him = a > chance to provide guidance in case that's the decision (but we won't wait > long for that either). > > >> The real challenge for most IETF specs is community engagement, not >>> engineering adequacy. >>> >> >> Interestingly I would claim we have clearly achieved the former here, >> though obviously not the latter. >> >> My sense is -- as has become common in the IETF -- an extremely small >> core of folk interesting in promoting this work, rather than extensive >> community interest. >> > That's probably true, but by that argument we should just terminate most > of the email-related working groups because the critical mass we can get > today is a fraction of what it used to be. > > Those sorts of existential questions can't be answered at this level, > however. I would claim the working group was chartered with the > understanding that the participation here won't be like it was for, say, > DKIM, or DRUMS, etc. We're not in a position to fix that here. We have = a > job to do, and we need to get moving again. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000eba6b8059db51018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

<<<The chairs will = not accept hearsay replies or opinions, or expressions of needing this work= but not knowing how to engage; you either give your feedback on the list o= r privately to the chairs or Area Directors, or you are along for whatever = ride results.=C2=A0 Please indicate, as soon as possible, where your suppor= t lies given the above.>>>

In my capacity as managing director of fTLD Registry Services (fTLD), = registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would pro= vide invaluable threat intelligence to domain registrants and to TLD admini= strators like ourselves for NXDOMAINs. PSD has tremendous value to speciali= zed TLDs including, but not limited to, .BRANDS, community-based domains, h= igh-security domains, governments, etc. and as such I believe PSD should pr= oceed. I=E2=80=99ve previously posted to this list expressing this view and= while fTLD cannot participate in experimentation due to a prohibition by I= CANN, we remain committed to supporting and seeing this work continue.=C2= =A0


Sincerely,

Craig

<= div dir=3D"ltr">
= --

Craig Schwartz
Managing Director
<= div>fTLD Registry Services | .BANK &= .INSURANCE
Office: +1 = 202 589 2532
Mobile= : +1 202 236 1154
Skype= : craig-schwartz




<= br>
=
=


On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable.=C2=A0

Such as?


RFC 6541 comes to= mind.=C2=A0 To the best of my knowledge, it's an experiment that never= even ran.=C2=A0 Implementations shipped, but its use on the open Internet = was never detected or reported.=C2=A0 And I had my doubts about the scalabi= lity of the second DNS check that was added to it, but it didn't seem l= ike it could go forward without.

One that wasn't mine= : RFC 6210, an experiment to prove how bad something can be.


But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.

Why would the expectations for E= xperimental be higher than for Informational?=C2=A0 LMTP is Informational, = and it certainly needs to succeed.
So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?
=20

I'm pretty sure I've raised fundamental concerns about this = work and that those concerns have not been addressed.=C2=A0 The simple summary is that the way to restructure this work is to go back to first principles.=C2=A0 But there doesn't seem to be any interest= in having that sort of discussion.

I thought = we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of t= his back to first principles and separate DMARC from the determination of O= rganizational Domain (i.e., make them separate documents) before PSD can pr= oceed.=C2=A0 Since that will take months, I've proposed a compromise, b= ecause I don't think that's strictly necessary to allow the data co= llection work to proceed.=C2=A0 The proposed compromise, then, is to do the= work in hand, then rip the experiment down and apply whatever we learn fro= m it to standards track DMARC, which is the next milestone.=C2=A0 That will= include the separation of function you proposed, because we agree it's= an improvement.=C2=A0 I believe the set of likely participants in the expe= riment are present on the list, and it can be made clear to them that they = should have no expectation of the mechanism it describes surviving past the= termination of the experiment.=C2=A0 So the path forward here comes down t= o whether the working group achieves consensus on that compromise, or wheth= er the asserted risk of the experiment's structure leaking into the per= manent deployed base warrants shutting it down before it starts.
<= div>
Now, to the working group as a whole:

= The chairs note that we have a duly and properly completed WGLC in hand.=C2= =A0 Still, Dave's concerns have validity, so they need to be considered= by the working group.=C2=A0 Since we need to do *something*, we are now pu= tting the question back to the working group, and we need to see some answe= rs.=C2=A0 The chairs will not accept hearsay replies or opinions, or expres= sions of needing this work but not knowing how to engage; you either give y= our feedback on the list or privately to the chairs or Area Directors, or y= ou are along for whatever ride results.=C2=A0 Please indicate, as soon as p= ossible, where your support lies given the above.=C2=A0 We're not going= to let this go additional months (probably not even weeks) without progres= s in some direction.

I will also say for the record that = we don't find compelling the assertion that resources will not be dedic= ated to the experiment absent a document in the RFC Editor queue.=C2=A0 Tha= t constraint is fully external to the IETF, and it will carry no weight in = the decision made here.=C2=A0 It should indeed be possible to run an experi= ment based on a document in any state at all.=C2=A0 We're entertaining = publication not because it must happen, but because that action (currently)= has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected= to fail are not generally what the IETF produces.=C2=A0 I would quibble so= me with that wording: The working group doesn't expect the experiment t= o "fail", but rather expects it to be ephemeral.=C2=A0 Were we to= refer to chapter-and-verse, there's nothing in RFC2026 (which defines = "Experimental" as a document status) that precludes what the work= ing group appears to be trying to do here.=C2=A0 As for whether the IETF ge= nerally should produce an Experimental document describing something epheme= ral, I would claim that a working group or its chairs are below the pay gra= de where authoritative claims like those are made; it's the kind of thi= ng about which the IESG makes proclamations.=C2=A0 Accordingly, I've Cc= 'd our current Area Director to see what he thinks might happen if we w= ere to send this up, and give him a chance to provide guidance in case that= 's the decision (but we won't wait long for that either).
=


The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I would claim we have clearly achieved the former here, though obviously not the latter.
=20

My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.

That's p= robably true, but by that argument we should just terminate most of the ema= il-related working groups because the critical mass we can get today is a f= raction of what it used to be.

Those sorts of exis= tential questions can't be answered at this level, however.=C2=A0 I wou= ld claim the working group was chartered with the understanding that the pa= rticipation here won't be like it was for, say, DKIM, or DRUMS, etc.=C2= =A0 We're not in a position to fix that here.=C2=A0 We have a job to do= , and we need to get moving again.

-MSK
<= /div> _______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000eba6b8059db51018-- From nobody Mon Feb 3 19:08:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F166E120033 for ; Mon, 3 Feb 2020 19:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 06JB6_EktUuY for ; Mon, 3 Feb 2020 19:08:20 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 5238912002F for ; Mon, 3 Feb 2020 19:08:20 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id 80so3326164uah.9 for ; Mon, 03 Feb 2020 19:08:20 -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=x7fra/XXfMFe0wnH8Y3f/79LsZrlRTgw3PfuFvBQIZU=; b=CsKvB54Dzg9Z7ZqBHYgPJ0cM4NSFXoat4OQm31ERu16Q2MiMl71WClvTjTxiRBBJ3V jQEE/FHG052mIT2neqZBR2S+WTqBZ0WLqQrUaxY5jAeE8Gbkg8FM0N7NsdOPecmnVDAh 7W8+xExgmBPswkr8whQd7P49vT2l+RXF6Irp0A0YWYl5IlD638NZmUPY9/saZ0N0TiWl O2RrddYXyquU9TOhgG/p4jwtERRl7Meae7ssglmQQoi4a3hGfLZ5jJxKL8S3/m87z9hU jPpvGOVDbSY+ORmz06afogdmZ1aSLpGf/ja/IvGqVK7D9rZM8ryCX32ZJNzyS94+jj8M 2duA== 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=x7fra/XXfMFe0wnH8Y3f/79LsZrlRTgw3PfuFvBQIZU=; b=Utbtpv4DPXPoF4tbQZEOmTTUKRaT8J9AIbjQSlfk7aZIODMLosdPNtk9ZHoziULBpT ppOJ1Qa5GoCByfaUrew3yMgmMyke6C8pXGDz2DvnhQHsO76cWaYeaj9BIOJfdIgy3tF7 F+sq56CrWkt/tHBfIjmlZtqSENcRNbrBQzrOChvWafq9W3KlbOnHCdkBQyhoVne5ndYy yLT3WoWxucFhzDaohLTNdlmt7KBxeOO7QR06x77jkxlqGeUMhZe5XntPy6usvQJScmfd XgmSJ9D6Ne1m5nl3TVUk2fOX0fYJGWl9M8AuUZCOgJVxlDngRncztQGC5Jxkx0O11zCy DgXg== X-Gm-Message-State: APjAAAWgFRFMUkdp6Eop9y7FmY+OkjMb5HzdfuUICv0laFjFvtRpnQ06 tIs0IhZ4O33+IBzSUJEfcPasF8Uzt8FbswW9Ixw= X-Google-Smtp-Source: APXvYqx5WFwZm+6Kt1vuC1/5sz553OMYNe+lC/Cdmdc+0qySAjE8/YPSqrQWmt+cibsPSELEs2hik6Rsa4TPO3boJic= X-Received: by 2002:ab0:63cb:: with SMTP id i11mr7844614uap.87.1580785699285; Mon, 03 Feb 2020 19:08:19 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 3 Feb 2020 19:08:06 -0800 Message-ID: To: Craig Schwartz Cc: Dave Crocker , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000127366059db75a60" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 03:08:22 -0000 --000000000000127366059db75a60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz wrote: > Hi Murray, > > << of needing this work but not knowing how to engage; you either give your > feedback on the list or privately to the chairs or Area Directors, or you > are along for whatever ride results. Please indicate, as soon as possibl= e, > where your support lies given the above.>>> > > In my capacity as managing director of fTLD Registry Services (fTLD), > registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would > provide invaluable threat intelligence to domain registrants and to TLD > administrators like ourselves for NXDOMAINs. PSD has tremendous value to > specialized TLDs including, but not limited to, .BRANDS, community-based > domains, high-security domains, governments, etc. and as such I believe P= SD > should proceed. I=E2=80=99ve previously posted to this list expressing th= is view > and while fTLD cannot participate in experimentation due to a prohibition > by ICANN, we remain committed to supporting and seeing this work continue= . > Craig, Thanks for this, and for one other person that sent to the chairs privately (it was a list non-member caught in moderation, nothing secret). To be clear, however: I think the working group mailing list archive has enough of a record that participants think the experiment will be useful or even critical to the evolution of DMARC, though people are of course welcome to affirm that support for the record. The question being put, however, goes to the form of the experiment and the current form of DMARC as a protocol with respect to determining Organizational Domains, and whether there are indeed risks to the deployed infrastructure that the experiment could become permanent. That's the meaty stuff that would really help to move this along. -MSK --000000000000127366059db75a60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 3, 2020 at 4:24 PM Craig Schw= artz <craig@ftld.com> wrote:
Hi Murr= ay,

<<<The chairs will not accep= t hearsay replies or opinions, or expressions of needing this work but not = knowing how to engage; you either give your feedback on the list or private= ly to the chairs or Area Directors, or you are along for whatever ride resu= lts.=C2=A0 Please indicate, as soon as possible, where your support lies gi= ven the above.>>>

In my capacity as managing director of fTLD Regist= ry Services (fTLD), registry operator of the .BANK and .INSURANCE TLDs, I b= elieve PSD would provide invaluable threat intelligence to domain registran= ts and to TLD administrators like ourselves for NXDOMAINs. PSD has tremendo= us value to specialized TLDs including, but not limited to, .BRANDS, commun= ity-based domains, high-security domains, governments, etc. and as such I b= elieve PSD should proceed. I=E2=80=99ve previously posted to this list expr= essing this view and while fTLD cannot participate in experimentation due t= o a prohibition by ICANN, we remain committed to supporting and seeing this= work continue.


Craig,

Thanks for this, and for one other person that se= nt to the chairs privately (it was a list non-member caught in moderation, = nothing secret).

To be clear, however: I think the= working group mailing list archive has enough of a record that participant= s think the experiment will be useful or even critical to the evolution of = DMARC, though people are of course welcome to affirm that support for the r= ecord.=C2=A0 The question being put, however, goes to the form of the exper= iment and the current form of DMARC as a protocol with respect to determini= ng Organizational Domains, and whether there are indeed risks to the deploy= ed infrastructure that the experiment could become permanent.=C2=A0 That= 9;s the meaty stuff that would really help to move this along.

-MSK
--000000000000127366059db75a60-- From nobody Tue Feb 4 07:30:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140511200B2 for ; Tue, 4 Feb 2020 07:30: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, SPF_HELO_FAIL=0.001, 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=0ULIYj3M; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XeXvP53F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHNMNS-jM_m6 for ; Tue, 4 Feb 2020 07:30:44 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4301812011F for ; Tue, 4 Feb 2020 07:30:44 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 17B12F80308 for ; Tue, 4 Feb 2020 10:30:43 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580830242; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KnHmWH6dqKUApvXtwU1JWLged1p+q+igFIywiVGWQWc=; b=0ULIYj3MdTNU+gHH86WM0b2o2GZZHqesgCZW7HuKgk/TuaYF9sbpsl8/ uy5I5WaEKgFOrNvTPnLNIu38UqgSCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580830242; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=KnHmWH6dqKUApvXtwU1JWLged1p+q+igFIywiVGWQWc=; b=XeXvP53Fdn1SRXTBh6SwihEdaWCWQp3fINhb7K3hDsEtTxnvDNIdALtT AuTSmIlwb9ezQnkieJsbyxVBlwngsR87ver749GdVKtvqnxNueAp5E5FNN mKOE+H5iUeTjabzJJsHPvrkIiqSPIAT8qS4qOrbIIYMfF0Uj0v1ZbkLox1 upG4/cP4/9nhUtNVE6q9tiSsBzuzYVJKx4z6zKFMWHeJhc/eNPi2oGEf9O oruw2zKLQTcl1ka09qTuuu8D4sB23GJFk6uusA+JJHg7+AL2/4Y/KXnFtB KFaO6hD9CID2D9JJ9qXQ6AndukVt3Bd1z1U+FlZ/pd+bK0zYpxi5LQ== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id D1ABCF801EA for ; Tue, 4 Feb 2020 10:30:42 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 04 Feb 2020 10:30:41 -0500 Message-ID: <2041721.1BiOycRJ3A@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 15:30:46 -0000 On Monday, February 3, 2020 1:47:45 PM EST Murray S. Kucherawy wrote: > Now, to the working group as a whole: > > The chairs note that we have a duly and properly completed WGLC in hand. > Still, Dave's concerns have validity, so they need to be considered by the > working group. Since we need to do *something*, we are now putting the > question back to the working group, and we need to see some answers. The > chairs will not accept hearsay replies or opinions, or expressions of > needing this work but not knowing how to engage; you either give your > feedback on the list or privately to the chairs or Area Directors, or you > are along for whatever ride results. Please indicate, as soon as possible, > where your support lies given the above. We're not going to let this go > additional months (probably not even weeks) without progress in some > direction. Personally, I think Dave is wrong. I think he's given an assertion, but nothing beyond that. Given that DMARC has been successfully deployed at scale depending on a list (PSL), I believe that's an adequate existence proof that Dave's assertion that anything depending on a list can't scale is not correct. Dave's claim that the IETF hasn't done anything depending on a list may or may not be correct, I don't know, but that's not a technical point. If the IETF was stopped by "we haven't done this before", we wouldn't have much of an Internet today. That isn't to argue using the PSL to find the org domain is a technically clean solution. It's not. It's only less horrible than the alternatives. > I will also say for the record that we don't find compelling the assertion > that resources will not be dedicated to the experiment absent a document in > the RFC Editor queue. That constraint is fully external to the IETF, and > it will carry no weight in the decision made here. It should indeed be > possible to run an experiment based on a document in any state at all. > We're entertaining publication not because it must happen, but because that > action (currently) has consensus, and it's our job to act on consensus. I think the IETF tells external organizations not to use I-Ds [1], so I don't really understand this point, but I don't think it affects consensus much. > > Dave also made an additional observation, that experiments expected to fail > are not generally what the IETF produces. I would quibble some with that > wording: The working group doesn't expect the experiment to "fail", but > rather expects it to be ephemeral. Were we to refer to chapter-and-verse, > there's nothing in RFC2026 (which defines "Experimental" as a document > status) that precludes what the working group appears to be trying to do > here. As for whether the IETF generally should produce an Experimental > document describing something ephemeral, I would claim that a working group > or its chairs are below the pay grade where authoritative claims like those > are made; it's the kind of thing about which the IESG makes proclamations. > Accordingly, I've Cc'd our current Area Director to see what he thinks > might happen if we were to send this up, and give him a chance to provide > guidance in case that's the decision (but we won't wait long for that > either). It won't surprise you to find that I support publishing the draft substantially as is. I believe there are some open questions described in the experimental portions of the draft that will take some operational experience to evaluate and having a stable reference will be useful for that purpose. As a side note, I don't think this is anywhere near the most extreme experimental document that IETF has considered for publication. The Sender ID RFCs conflicted with current Internet Standards and were still published even after an appeal on that point. Having just re-read the IAB response to that appeal [2], particularly Section 3, I'm even more convinced that the DMARC PSD draft is well within the realm of what's appropriate for an experimental RFC. Scott K [1] https://ietf.org/standards/ids/ [2] https://www.iab.org/appeals/2006-2/iab-response-to-appeal-from-julian-mehnle-2-march-2006/ From nobody Tue Feb 4 09:39:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3A012087E for ; Tue, 4 Feb 2020 09:39: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jALyItrrBpBp for ; Tue, 4 Feb 2020 09:39:21 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-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 F0F6A120880 for ; Tue, 4 Feb 2020 09:39:20 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id i7so16606476ilr.7 for ; Tue, 04 Feb 2020 09:39:20 -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=kBYN46rGrHTj+GWLm/Qqzy2LRU/OJ/qf502mMD1gsGo=; b=GaLswRESdLi5D59XWD2CVvUowtSyDLk9kpOdqxg8sgUTzvXpiUXiZyCs9gCyZjGr4m ZE9b8qqPo85V0RNiVDIZ2uk90aTkIeGmc0Wq42eCkX69LG+a4d6f97qd4fr7hpCz5Bfu 9/Akh3UsHOz9TBTq5WkhkNoQMCm6OJvnqvhaE= 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=kBYN46rGrHTj+GWLm/Qqzy2LRU/OJ/qf502mMD1gsGo=; b=FCewtyxdKdL59tNFLQ6Z9Uk6TIBQXW57N0F8TJy6/tJOSoqVEessJ6SwYGAB+CbIiz VvrDsCTxIit5JcRQiNTUbhw//HgCK2we6JuRv/w0BBaKI+vBeIhucot5Pui6gVZK7FxI RjUElei6oaDOLtGXkSRMTSONI0ZvPhYUtiNxXhoJX89bnY418R5B85ej/jk1RJIL12IM GmYmYOY4hHPh4VdVc11LPMKGEj4P7GCoBcaSVnXtDt9hToQ9CSWnBVdtIxN9AnNNHAIA 8M5PJHMno2QoHEniyqafm9rftwRjsMrGxJocKUY6+tUm7fVkNgmaocfClm2YkWomix8j vw7Q== X-Gm-Message-State: APjAAAVXpWyiBmfgX5MOlDYJAPorTyeTQXEi2u2tKarJRR7rcFK2316I DF0arqZq9AYA8Ke8MCcZ7YUnT+feJ3CSV/A7US3XVQ== X-Google-Smtp-Source: APXvYqwArIDp9wZBOn8ebb3VTjgp1afJJtPJCkMg4f7HzRVI0f+j0SdmpyW/FuSCPdH2Jvy2B+6ZwmTco29WWlqtGcw= X-Received: by 2002:a92:b506:: with SMTP id f6mr22251813ile.103.1580837960153; Tue, 04 Feb 2020 09:39:20 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 4 Feb 2020 09:39:09 -0800 Message-ID: To: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000100dcd059dc38570" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 17:39:23 -0000 --000000000000100dcd059dc38570 Content-Type: text/plain; charset="UTF-8" I support publishing the I-D as confirmed in the WGLC with (perhaps) some additional caveats regarding the ephemerality of the Experiment as deemed necessary by the chairs. Given the expected duration of the experiment (at least a year to collect some useful data, if not 2-3 years), I also support unblocking the other work in this WG since we ought not wait for this experiment to "conclude" (whatever that means) before proceeding on other work items. --Kurt --000000000000100dcd059dc38570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support publishing the I-D as confirmed= in the WGLC with (perhaps) some additional caveats regarding the ephemeral= ity=C2=A0of the Experiment as deemed necessary by the chairs.

Given the expected duration of the experiment (at least a year to col= lect some useful data, if not 2-3 years), I also support unblocking the oth= er work in this WG since we ought not wait for this experiment to "con= clude" (whatever that means) before proceeding on other work items.

--Kurt=C2=A0
--000000000000100dcd059dc38570-- From nobody Tue Feb 4 10:27:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172A3120856; Tue, 4 Feb 2020 10:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 5VF8VjcvXiCH; Tue, 4 Feb 2020 10:27:28 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 B7F8E120877; Tue, 4 Feb 2020 10:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1580840838; bh=2YTq9WeQhz0w+PEcl84TBEvvDrRSz3z7xCYEdZxs/VA=; l=3726; h=To:References:From:Date:In-Reply-To; b=DYarfcofV5pS00L8KXKfEvMHbRsku7qApeygtg0ev9kUcS+aozUCoSzRDXyseGZ3y iSP7HIM9Vu/dqZ5xRGmdA0vrdlojKoq5fCNtW8sewKWgBMy+1Nyk1B8/SiifYJB7TO V3DlZ9UzmgaMunPqAGEIatWh17t4H5Lfm9g2cQgckKORvA4YxjMQNG6ct8kUs 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005E39B786.00003F23; Tue, 04 Feb 2020 19:27:18 +0100 To: dmarc@ietf.org, dmarc-ads@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> From: Alessandro Vesely Message-ID: <01e149da-3ff6-7e91-d815-d79316f53d58@tana.it> Date: Tue, 4 Feb 2020 19:27:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.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] Comment on 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: Tue, 04 Feb 2020 18:27:31 -0000 On Mon 03/Feb/2020 19:47:45 +0100 Murray S. Kucherawy wrote: > > Now, to the working group as a whole: > > The chairs note that we have a duly and properly completed WGLC in hand.  > Still, Dave's concerns have validity, so they need to be considered by the > working group.  Since we need to do *something*, we are now putting the > question back to the working group, and we need to see some answers.  The > chairs will not accept hearsay replies or opinions, or expressions of needing > this work but not knowing how to engage; you either give your feedback on the > list or privately to the chairs or Area Directors, or you are along for > whatever ride results.  Please indicate, as soon as possible, where your > support lies given the above.  We're not going to let this go additional months > (probably not even weeks) without progress in some direction. I support publishing draft-ietf-dmarc-psd as is. As I wrote already, I appreciate Dave's narration and think it can lead to a better overall statement of DMARC. However, I don't think it suggests any practical software technique that may improve [PSD]DMARC implementations in the short term. > I will also say for the record that we don't find compelling the assertion that > resources will not be dedicated to the experiment absent a document in the RFC > Editor queue.  That constraint is fully external to the IETF, and it will carry > no weight in the decision made here.  It should indeed be possible to run an > experiment based on a document in any state at all.  We're entertaining > publication not because it must happen, but because that action (currently) has > consensus, and it's our job to act on consensus. There are a number of ICANN liaisons mentioned in IETF website[*]. I think it is their, or at least some of them's, duty to inform the relevant ICANN authority about the experiment, so that they can allow it to proceed, as soon as draft-ietf-dmarc-psd enters the RFC Editor queue. Will Area Directors please advise them? NOTE: The provision to publish _dmarc resource records, or whatever selection of registered underscored node names[†], under selected global TLDs is *not* to be considered ephemeral. [*] https://ietf.org/about/liaisons/ [†] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names > Dave also made an additional observation, that experiments expected to fail are > not generally what the IETF produces.  I would quibble some with that wording: > The working group doesn't expect the experiment to "fail", but rather expects > it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in > RFC2026 (which defines "Experimental" as a document status) that precludes what > the working group appears to be trying to do here.  As for whether the IETF > generally should produce an Experimental document describing something > ephemeral, I would claim that a working group or its chairs are below the pay > grade where authoritative claims like those are made; it's the kind of thing > about which the IESG makes proclamations.  Accordingly, I've Cc'd our current > Area Director to see what he thinks might happen if we were to send this up, > and give him a chance to provide guidance in case that's the decision (but we > won't wait long for that either). I don't expect the experiment to fail. What seems to me to be ephemeral is its providing for three different services[‡] to determine which TLDs deserve an extra DNS lookup. The experiment will hopefully determine which one(s) are fit. [‡] https://psddmarc.org/ Best Ale -- From nobody Tue Feb 4 11:49:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC956120131 for ; Tue, 4 Feb 2020 11:49: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, 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=LDThADd/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NWt9lqEw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ3fLkmgtadL for ; Tue, 4 Feb 2020 11:49:05 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626E81200B7 for ; Tue, 4 Feb 2020 11:49:05 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 19E4EF80308 for ; Tue, 4 Feb 2020 14:49:04 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580845743; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=g0MNxG2H+alHQ9KQuvOauFuSmXKRt8yGy4SoKqC4um0=; b=LDThADd/uWbvTs6/H/F9dHjwxiCAA8Utx3gHvwKlgmfkWfUg+NBZkHlV ZIqitITmgx305gu1X1x0lRPSpUoSAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580845743; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=g0MNxG2H+alHQ9KQuvOauFuSmXKRt8yGy4SoKqC4um0=; b=NWt9lqEw8GDQbiXHVZ0kr5QbmdxZJNN+WNu1AlEYY+aVecZPtAswB3W7 XWsRzV5xI6W4XdTqfmAIDj8xyMXz1rKJWlo9svgiPI/zptD+H6Khpl76BK 5jL8rj1S+u1ldj9iHh4F9X92zQNQS0TMWOatwvyPYaBafih0TXlrEYAnh2 LcmeSLHf5Wo6qm3HWGI7yFZyuZJgZUO3xzMOBtPkvWuaSiyz2dLQ1KIA0a WA278gj2iJqdvFkLUgx44l6SdmrjFs1MIgr+UqiNEy6EjSU3A1+8zMS71c t//o89XEmNsj8sBVB4edUY1YXRqhyq1uC29usezgm7H1K+2lkIyCfg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id E1F04F801EA for ; Tue, 4 Feb 2020 14:49:03 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 04 Feb 2020 14:49:03 -0500 Message-ID: <3386547.LmEUfHP9lS@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 19:49:07 -0000 On Tuesday, February 4, 2020 12:39:09 PM EST Kurt Andersen (b) wrote: > I support publishing the I-D as confirmed in the WGLC with (perhaps) some > additional caveats regarding the ephemerality of the Experiment as deemed > necessary by the chairs. > > Given the expected duration of the experiment (at least a year to collect > some useful data, if not 2-3 years), I also support unblocking the other > work in this WG since we ought not wait for this experiment to "conclude" > (whatever that means) before proceeding on other work items. I don't see any reason the other WG items can't proceed in parallel with the experiment. I believe the changes to DMARC to bring it to IETF standards, particularly the need for an alternative to the PSL, will take significant effort to achieve. As a result, I think there's little risk that results from the experiment will end up being a critical path item for any WG effort. Scott K From nobody Tue Feb 4 12:25:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003FD1208CA for ; Tue, 4 Feb 2020 12:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KgwPUAcl4gkA for ; Tue, 4 Feb 2020 12:25:32 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 AA33C1208C7 for ; Tue, 4 Feb 2020 12:25:31 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id p17so48366wma.1 for ; Tue, 04 Feb 2020 12:25:31 -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=M7tohPFTwyFd4SclqL27/tqoPrwUKyhxsdmcf6HlXxg=; b=AWPDOCOBRCAAA7MRDQS5gB50Go9qOsuhCmc1R1GPvoDVoOVoRpOm51kHtZTqwaebk/ 2rSisuCZMO4G+LyCLi42AvfRTbsiELWA5w879dT0ki3RvEoLBHQqqaS3F65Ep+lYk5TR DIK8oMFVe28WfFJVIzyaas8OPYTcQy8kxkKPwM7gCMiOUBE4gAfii7FiZ6Gz2C9FyGMR 0uecAjeK0CYcSGz+PlIU23ewZUtOcl+GkAUwFRq5YPXvXnZru8q6KGZsRrqR5UJpol8Y LXWNh8f/FqxlI8NuMtzRaj2iiSLfJxz1SRZaaJkXtNwcLSyIeajTFYNdV5AnCE8xeA7r 1Rxw== 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=M7tohPFTwyFd4SclqL27/tqoPrwUKyhxsdmcf6HlXxg=; b=c7DNDIQraYiner/jn4Kz5MEr0S5PAVOzgEpLnYGw35UC1FeR7+2zExoVGNgE7HyW0a QEkk20Xvmfy1kfFXLr7g+5KmoHbUEKmFeTET2etx8JXU7LbZsTPllJnXe3LUooNAj3vq /i96E+aUL8TFuMXua48+OcitRcD+VFpyw3iHpV74A5PYBi0nlFBthLKBrZWCRlU/dhep nSwWsiS60U9aUcFA95CalEoAFTqs/NdlsPNcKRJ/k9dY1e5DmdV7yCGIrcfEwHs7ySX6 5Z+ea7Y2tyuIy0EWssp1X62JM8so4CkmEFi9auQdDrjecVJqLYeppp7Hi0ow6IpYQOAb eEQw== X-Gm-Message-State: APjAAAUfXsLBjBp/A6fMUHsJ8WyDnZ1PPfXrnAQSP2u8Ints75xdKF8y e0jBF5DjPLLrmrwyG+PoYVwW6IQ++uuyznKUEWBPVfFN6Og= X-Google-Smtp-Source: APXvYqxxoM7/MZzI6QdzFEq3vKuFmOjGgD5axyPlePClaq+oiHkTZpwN5ftzfAFZcN/4+a2Qf6WH78jSd6ZnTSQ4PQs= X-Received: by 2002:a05:600c:2c06:: with SMTP id q6mr834939wmg.154.1580847930185; Tue, 04 Feb 2020 12:25:30 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: Dotzero Date: Tue, 4 Feb 2020 15:25:06 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Dave Crocker , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="000000000000529ec2059dc5d7ed" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:25:35 -0000 --000000000000529ec2059dc5d7ed Content-Type: text/plain; charset="UTF-8" I do not support publishing draft-ietf-dmarc-psd as is. Running code and rough consensus. I, as were a few others on the list, was part of the private effort that eventually became the "DMARC team". I point out that until DMARC was published openly, the experiment had absolutely zero impact on others and the Internet at large. It was a closed system. Subsequent to publication (not originally as an I-D), some receivers did take steps that some considered coercive towards senders, but that was beyond the specification itself. At a subsequent point, some (large) sender domains published DMARC policies that were painful for both intermediaries as well as users with accounts at those domains but which sent mail from other origins. Someone pointed to Sender-ID as an example experiment. A very poor example to choose. It was broken from the start. As an aside, I kept sending email to the folks at Microsoft using @Microsoft.com email addresses by using "Sender" to game PRA to get a neutral". Furthermore, it dragooned senders who had no intention of participating in the experiment by reusing their published SPF records in a manner they did not intend them to be used. I also point out how long it took to put a stake in the heart of Sender-ID. And yet even today we can find Sender-ID records littering the Internet and even a few places doing Sender-ID checks. For some definition of "We", we are good at additions and modifications but poor at deletes. I am not against experiments, but having reread the entire thread starting from Dave's post in August, I believe his concerns are valid. My question to the chairs and the group as a whole is whether an experiment can be constructed that is valid and useful without "comingling" PSD issues and concerns with the core of DMARC at scale? That is, the group that is seriously interested does their experiment amongst themselves to produce data that supports and justifies such changes in the wild. "Be conservative in what you do, be liberal in what you accept from others. ..." Michael Hammer On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy wrote: > Dave, > > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker wrote: > >> Nothing I've worked on at the IETF with such a label is something I would >> necessarily stand behind as Internet-scalable. >> >> Such as? >> > > RFC 6541 comes to mind. To the best of my knowledge, it's an experiment > that never even ran. Implementations shipped, but its use on the open > Internet was never detected or reported. And I had my doubts about the > scalability of the second DNS check that was added to it, but it didn't > seem like it could go forward without. > > One that wasn't mine: RFC 6210, an experiment to prove how bad something > can be. > >> >> But I would probably expect something at Informational probably to scale, >> and anything with "Standard" in it certainly to scale. >> >> Laying any general expectation on an IETF Informational RFC would be a >> mistake, because there is so much variety in their content and intent. >> > > Why would the expectations for Experimental be higher than for > Informational? LMTP is Informational, and it certainly needs to succeed. > >> So: Can you propose any sort of specific restructuring of the document or >> the experiment that achieves the same goal as the current version while >> also resolving your concerns? >> >> I'm pretty sure I've raised fundamental concerns about this work and that >> those concerns have not been addressed. The simple summary is that the way >> to restructure this work is to go back to first principles. But there >> doesn't seem to be any interest in having that sort of discussion. >> > I thought we were having that sort of a discussion right here. > > Your position as I recall is that we have no choice but to take all of > this back to first principles and separate DMARC from the determination of > Organizational Domain (i.e., make them separate documents) before PSD can > proceed. Since that will take months, I've proposed a compromise, because > I don't think that's strictly necessary to allow the data collection work > to proceed. The proposed compromise, then, is to do the work in hand, then > rip the experiment down and apply whatever we learn from it to standards > track DMARC, which is the next milestone. That will include the separation > of function you proposed, because we agree it's an improvement. I believe > the set of likely participants in the experiment are present on the list, > and it can be made clear to them that they should have no expectation of > the mechanism it describes surviving past the termination of the > experiment. So the path forward here comes down to whether the working > group achieves consensus on that compromise, or whether the asserted risk > of the experiment's structure leaking into the permanent deployed base > warrants shutting it down before it starts. > > Now, to the working group as a whole: > > The chairs note that we have a duly and properly completed WGLC in hand. > Still, Dave's concerns have validity, so they need to be considered by the > working group. Since we need to do *something*, we are now putting the > question back to the working group, and we need to see some answers. The > chairs will not accept hearsay replies or opinions, or expressions of > needing this work but not knowing how to engage; you either give your > feedback on the list or privately to the chairs or Area Directors, or you > are along for whatever ride results. Please indicate, as soon as possible, > where your support lies given the above. We're not going to let this go > additional months (probably not even weeks) without progress in some > direction. > > I will also say for the record that we don't find compelling the assertion > that resources will not be dedicated to the experiment absent a document in > the RFC Editor queue. That constraint is fully external to the IETF, and > it will carry no weight in the decision made here. It should indeed be > possible to run an experiment based on a document in any state at all. > We're entertaining publication not because it must happen, but because that > action (currently) has consensus, and it's our job to act on consensus. > > Dave also made an additional observation, that experiments expected to > fail are not generally what the IETF produces. I would quibble some with > that wording: The working group doesn't expect the experiment to "fail", > but rather expects it to be ephemeral. Were we to refer to > chapter-and-verse, there's nothing in RFC2026 (which defines "Experimental" > as a document status) that precludes what the working group appears to be > trying to do here. As for whether the IETF generally should produce an > Experimental document describing something ephemeral, I would claim that a > working group or its chairs are below the pay grade where authoritative > claims like those are made; it's the kind of thing about which the IESG > makes proclamations. Accordingly, I've Cc'd our current Area Director to > see what he thinks might happen if we were to send this up, and give him a > chance to provide guidance in case that's the decision (but we won't wait > long for that either). > > >> The real challenge for most IETF specs is community engagement, not >>> engineering adequacy. >>> >> >> Interestingly I would claim we have clearly achieved the former here, >> though obviously not the latter. >> >> My sense is -- as has become common in the IETF -- an extremely small >> core of folk interesting in promoting this work, rather than extensive >> community interest. >> > That's probably true, but by that argument we should just terminate most > of the email-related working groups because the critical mass we can get > today is a fraction of what it used to be. > > Those sorts of existential questions can't be answered at this level, > however. I would claim the working group was chartered with the > understanding that the participation here won't be like it was for, say, > DKIM, or DRUMS, etc. We're not in a position to fix that here. We have a > job to do, and we need to get moving again. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000529ec2059dc5d7ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not support publishing draft-ietf-dmarc-psd as is. Run= ning code and rough consensus.=C2=A0

I, as were a = few others on the list, was part of the private effort that eventually beca= me the "DMARC team". I point out that until DMARC was published o= penly, the experiment had absolutely zero impact on others and the Internet= at large. It was a closed system. Subsequent to publication (not originall= y as an I-D), some receivers did take steps that some considered coercive t= owards senders, but that was beyond the specification itself. At a subseque= nt point, some (large) sender domains published DMARC policies that were pa= inful for both intermediaries as well as users with accounts at those domai= ns but which sent mail from other origins.=C2=A0

S= omeone pointed to Sender-ID as an example experiment. A very poor example t= o choose. It was broken from the start. As an aside, I kept sending email t= o the folks at Microsoft using=C2=A0@Microsoft.com email addresses by using= "Sender" to game PRA to get a neutral". Furthermore, it dra= gooned senders who had no intention of participating in the experiment by r= eusing their published SPF records in a manner they did not intend them to = be used. I also point out how long it took to put a stake in the heart of S= ender-ID. And yet even today we can find Sender-ID records littering the In= ternet and even a few places doing Sender-ID checks. For some definition of= "We", we are good at additions and modifications but poor at del= etes.

I am not against experiments, but having rer= ead the entire thread starting from Dave's post in August, I believe hi= s concerns are valid. My question to the chairs and the group as a whole is= whether an experiment can be constructed that is valid and useful without = "comingling" PSD issues and concerns with the core of DMARC at sc= ale? That is, the group that is seriously interested does their experiment = amongst themselves to produce data that supports and justifies such changes= in the wild.

"Be conservative in what you do, be liberal in what you acce= pt from others. ..."
=
Michael Hammer

On Mon, Feb 3, 202= 0 at 1:48 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Dave,

On Fri, Jan 17, 2020 at= 8:44 AM Dave Crocker <dcrocker@gmail.com> wrote:
Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable.=C2=A0

Such as?


RFC 6541 comes to= mind.=C2=A0 To the best of my knowledge, it's an experiment that never= even ran.=C2=A0 Implementations shipped, but its use on the open Internet = was never detected or reported.=C2=A0 And I had my doubts about the scalabi= lity of the second DNS check that was added to it, but it didn't seem l= ike it could go forward without.

One that wasn't mine= : RFC 6210, an experiment to prove how bad something can be.


But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.

Why would the expectations for E= xperimental be higher than for Informational?=C2=A0 LMTP is Informational, = and it certainly needs to succeed.
So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?
=20

I'm pretty sure I've raised fundamental concerns about this = work and that those concerns have not been addressed.=C2=A0 The simple summary is that the way to restructure this work is to go back to first principles.=C2=A0 But there doesn't seem to be any interest= in having that sort of discussion.

I thought = we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of t= his back to first principles and separate DMARC from the determination of O= rganizational Domain (i.e., make them separate documents) before PSD can pr= oceed.=C2=A0 Since that will take months, I've proposed a compromise, b= ecause I don't think that's strictly necessary to allow the data co= llection work to proceed.=C2=A0 The proposed compromise, then, is to do the= work in hand, then rip the experiment down and apply whatever we learn fro= m it to standards track DMARC, which is the next milestone.=C2=A0 That will= include the separation of function you proposed, because we agree it's= an improvement.=C2=A0 I believe the set of likely participants in the expe= riment are present on the list, and it can be made clear to them that they = should have no expectation of the mechanism it describes surviving past the= termination of the experiment.=C2=A0 So the path forward here comes down t= o whether the working group achieves consensus on that compromise, or wheth= er the asserted risk of the experiment's structure leaking into the per= manent deployed base warrants shutting it down before it starts.
<= div>
Now, to the working group as a whole:

= The chairs note that we have a duly and properly completed WGLC in hand.=C2= =A0 Still, Dave's concerns have validity, so they need to be considered= by the working group.=C2=A0 Since we need to do *something*, we are now pu= tting the question back to the working group, and we need to see some answe= rs.=C2=A0 The chairs will not accept hearsay replies or opinions, or expres= sions of needing this work but not knowing how to engage; you either give y= our feedback on the list or privately to the chairs or Area Directors, or y= ou are along for whatever ride results.=C2=A0 Please indicate, as soon as p= ossible, where your support lies given the above.=C2=A0 We're not going= to let this go additional months (probably not even weeks) without progres= s in some direction.

I will also say for the record that = we don't find compelling the assertion that resources will not be dedic= ated to the experiment absent a document in the RFC Editor queue.=C2=A0 Tha= t constraint is fully external to the IETF, and it will carry no weight in = the decision made here.=C2=A0 It should indeed be possible to run an experi= ment based on a document in any state at all.=C2=A0 We're entertaining = publication not because it must happen, but because that action (currently)= has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected= to fail are not generally what the IETF produces.=C2=A0 I would quibble so= me with that wording: The working group doesn't expect the experiment t= o "fail", but rather expects it to be ephemeral.=C2=A0 Were we to= refer to chapter-and-verse, there's nothing in RFC2026 (which defines = "Experimental" as a document status) that precludes what the work= ing group appears to be trying to do here.=C2=A0 As for whether the IETF ge= nerally should produce an Experimental document describing something epheme= ral, I would claim that a working group or its chairs are below the pay gra= de where authoritative claims like those are made; it's the kind of thi= ng about which the IESG makes proclamations.=C2=A0 Accordingly, I've Cc= 'd our current Area Director to see what he thinks might happen if we w= ere to send this up, and give him a chance to provide guidance in case that= 's the decision (but we won't wait long for that either).
=


The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I would claim we have clearly achieved the former here, though obviously not the latter.
=20

My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.

That's p= robably true, but by that argument we should just terminate most of the ema= il-related working groups because the critical mass we can get today is a f= raction of what it used to be.

Those sorts of exis= tential questions can't be answered at this level, however.=C2=A0 I wou= ld claim the working group was chartered with the understanding that the pa= rticipation here won't be like it was for, say, DKIM, or DRUMS, etc.=C2= =A0 We're not in a position to fix that here.=C2=A0 We have a job to do= , and we need to get moving again.

-MSK
<= /div>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000529ec2059dc5d7ed-- From nobody Tue Feb 4 12:39:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E22112012E for ; Tue, 4 Feb 2020 12:39:41 -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_HELO_FAIL=0.001, 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=nsFaeZ9q; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Ih+i5Svq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24u4JZ74BXL8 for ; Tue, 4 Feb 2020 12:39:39 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EFA12011A for ; Tue, 4 Feb 2020 12:39:39 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id B15EBF80308 for ; Tue, 4 Feb 2020 15:39:38 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580848778; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=QIViY+MrSzSIoUdMEqVWUyNOTE78/BfjPuB4XcG4+44=; b=nsFaeZ9qTcCCvuOeCIyzluHnhG8EIdxjT2FFxPAaBPVE+ZygCIxcOKvo 20kNnRzNIWwsqe/aMsqP6KIdyHIXDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580848778; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=QIViY+MrSzSIoUdMEqVWUyNOTE78/BfjPuB4XcG4+44=; b=Ih+i5SvqFoYfFuf4UWzS5NHPyibR1uLiAzM7YqDN+ZTWaT4JbSQukEb5 CjDPY74VFJIu4qz3iaa4rPl4Wr57Jhoufec6a+fKrIzgu/JHubzFZcNtjS JbvezL+jDVH2aSKwm8g2FfLPdhLB5+vs74m0MfRQ3Msb5IPBLAtSOvyO8G kBevXLkGSo7I0qxFdDmBAAlvNkxaQp5GitrsoDxjcdkhkRdAT7iKsSvsH/ hPSzREPq1AgbzVFcFovGv/Ue9YXpjwwmEPRZ4DStOFRzdEClocuNa+fdsK KSZm3g1fK2auOy92ncLiXfFJ7KzzZEjASY81+oXbf4H9CvBO3NBmIQ== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 84082F801EA for ; Tue, 4 Feb 2020 15:39:38 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 04 Feb 2020 15:39:38 -0500 Message-ID: <1975032.yYTNxk3MA7@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:39:41 -0000 On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > Someone pointed to Sender-ID as an example experiment. A very poor example > to choose. It was broken from the start. As an aside, I kept sending email > to the folks at Microsoft using @Microsoft.com email addresses by using > "Sender" to game PRA to get a neutral". Furthermore, it dragooned senders > who had no intention of participating in the experiment by reusing their > published SPF records in a manner they did not intend them to be used. I > also point out how long it took to put a stake in the heart of Sender-ID. > And yet even today we can find Sender-ID records littering the Internet and > even a few places doing Sender-ID checks. For some definition of "We", we > are good at additions and modifications but poor at deletes. That was me. I agree it was a horrible idea. The point wasn't that Sender ID was great, it wasn't. The point was that the AIB considered it reasonable as an experiment. I think this is far less risky than that was. I was trying to respond to the idea what the IETF doesn't support experiments where there are technical concerns about the nature of the technology. The AIB's position, as I read it, was that such experiments are fine and if the IESG has concerns, they should add a note to document. Scott K From nobody Tue Feb 4 12:44:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEBF12012E for ; Tue, 4 Feb 2020 12:44:03 -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=u3HHX/ME; dkim=pass (2048-bit key) header.d=kitterman.com header.b=A8PdJMdE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvg_oGv3HvwI for ; Tue, 4 Feb 2020 12:44:02 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28AF12011A for ; Tue, 4 Feb 2020 12:44:01 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 43E33F80308 for ; Tue, 4 Feb 2020 15:44:01 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580849041; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=g21Ws4AcKRy1oMCcLjtu+vFpts9O6DlNA0jfh2tPp9I=; b=u3HHX/MEACp87ETvyAYYjJGHB2zRId0jEhe65GiHfeoViHSG3e7tfaPY LlT4UZeO8i1OA3ieKstWxEYC2pCvDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580849041; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=g21Ws4AcKRy1oMCcLjtu+vFpts9O6DlNA0jfh2tPp9I=; b=A8PdJMdESP45OKXrMdyYFQBVjIcvBYaWopHb/fQukcamkKKF+Wr8a/ik MQtO/AA0xTPbhaUyOqoL6cOfRjo2EfUbg/8QQpX43JNO1N4Qs3SW9KfoWV BsrogNQUe1Dv3U0/tTHUPMIYJSda6TbTRa3LlLP0qpNz35CA0WUGIrs+vt kYv6T6ZcUhSniV6Q6tdd1w6FIw4QYowwlBISAYhikPQBq7Jwzh5dPLvPfp nWfvhubqAZ3RTWclXOm6dOz8pDVxFa7tZNdEDxcmg+4DEfzCLmiNlPBb0w rTpBo7FnWHjuHkHJ4o/n8FIX9Cmu1sVCnKbTlhRUErjhdG8TfNDY5g== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 12C1EF801EA for ; Tue, 4 Feb 2020 15:44:01 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 04 Feb 2020 15:44:00 -0500 Message-ID: <2197062.EyKCtXoLNb@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:44:03 -0000 On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > I am not against experiments, but having reread the entire thread starting > from Dave's post in August, I believe his concerns are valid. My question > to the chairs and the group as a whole is whether an experiment can be > constructed that is valid and useful without "comingling" PSD issues and > concerns with the core of DMARC at scale? That is, the group that is > seriously interested does their experiment amongst themselves to produce > data that supports and justifies such changes in the wild. I think the draft as written works as you suggest. I think Dave's concerns are really about DMARC (or at least 99.6% about DMARC) and not significantly related to this addition. As designed, the experiment is self-contained: For senders, it only affects PSDs that have been listed as participants. For receivers, it only affects receivers that choose to deploy code to do the additional check related to PSD DMARC. As far as I can determine, there is zero impact on anyone else. We have running code. I'll leave it to the chairs to evaluate the consensus. Scott K From nobody Tue Feb 4 12:47:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56560120823 for ; Tue, 4 Feb 2020 12:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3kKf3bZ60UE9 for ; Tue, 4 Feb 2020 12:47:05 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 758951208CF for ; Tue, 4 Feb 2020 12:47:05 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id z3so24903746wru.3 for ; Tue, 04 Feb 2020 12:47: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=LqsROib/3FmJaMjWZ45X6vkIwgzRBU0naUdKe8dQqbE=; b=uZsgDS4AAhZuZE/UPd0i8E/UD/yr/14KCcQBbNhRaT+7sLeW2z8xQknTRKRKXtPbcE ggToHNcTmUulM2liTQ2EQcSipnHlTVkpQXdq9FcRpRWCAZVkgxRCIm0c7+yyFfW8n6R/ sCyVGsy/xAL4z8OojrAIgeh9Zl1ChTz/pP4r9YM5qfH8OaqGIs+rBvYdwj5eablhoemL LnIZWKpavA8pNTWbcW0OzqoSBOE55iFi5slkOXbPh6tmV+2SjtdurYnnFzgtcWDv6/y8 KzSRJFriGRifDn0vjUSlYEwF+jVwpBKDYRDBxDVjAHEq8ssUIMncLs7zPuVCWQMzXclI OP3Q== 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=LqsROib/3FmJaMjWZ45X6vkIwgzRBU0naUdKe8dQqbE=; b=HJ9QCuNJKfoN8tJEDs4L8qcHM+mm/q78qV+F28mF+JIfyOHp14QpoApGq7OFNg3058 ANzbzqwx58J/d5XZ33UJ6Jv+NwsCde72LdAK9W/PUOkYqBjY1aza5quPJBsVYt0LFZHX jxSEkfaoZK0e2Akthmu4ikdyhNrBXV+IBeSSkc8cDx7HgH3pf/5exR+bnP2G07fY0ymv 1KBk0HO7xhrvoQhd6I5eSI8wV6xv0WuIlt67lQ/c/4v+kgqt8NnYW6p13JRtSlD6AChe 3lT46JEMVvaYsRL+eCGvrYj6p1QNp/AiKvugZIlDllzt54qg77ziuMIY9YmLEKk0wSjG FVUg== X-Gm-Message-State: APjAAAWelE9oRPXUTRGWID0/2FQhJZZazZ9q3+ciHAzuG/u3hOwnFl9m qJe7fyCM2nC06BOqIKc+JhyPDeGEaQuzx+KsZpoRXmsr X-Google-Smtp-Source: APXvYqxzfJ/tIOEFela76fD+2BLEKPeGOWtgDqepIqcx2DqCKRggQRm6SxOVLgrB7CwCvftkT6/E/jYggL02giJ1f4I= X-Received: by 2002:adf:fc4b:: with SMTP id e11mr25129742wrs.326.1580849224063; Tue, 04 Feb 2020 12:47:04 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <1975032.yYTNxk3MA7@l5580> In-Reply-To: <1975032.yYTNxk3MA7@l5580> From: Dotzero Date: Tue, 4 Feb 2020 15:46:41 -0500 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000719ee6059dc62454" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:47:13 -0000 --000000000000719ee6059dc62454 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 3:39 PM Scott Kitterman wrote: > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > > Someone pointed to Sender-ID as an example experiment. A very poor > example > > to choose. It was broken from the start. As an aside, I kept sending > email > > to the folks at Microsoft using @Microsoft.com email addresses by using > > "Sender" to game PRA to get a neutral". Furthermore, it dragooned senders > > who had no intention of participating in the experiment by reusing their > > published SPF records in a manner they did not intend them to be used. I > > also point out how long it took to put a stake in the heart of Sender-ID. > > And yet even today we can find Sender-ID records littering the Internet > and > > even a few places doing Sender-ID checks. For some definition of "We", we > > are good at additions and modifications but poor at deletes. > > That was me. I agree it was a horrible idea. The point wasn't that > Sender ID > was great, it wasn't. The point was that the AIB considered it reasonable > as > an experiment. I think this is far less risky than that was. I was > trying to > respond to the idea what the IETF doesn't support experiments where there > are > technical concerns about the nature of the technology. The AIB's > position, as > I read it, was that such experiments are fine and if the IESG has > concerns, > they should add a note to document. > > Scott K > At the risk of offending some, politics was the elephant in the room on Sender-ID and SPF both ending up being designated as experimental. Michael Hammer --000000000000719ee6059dc62454 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 3:39 PM Scott = Kitterman <sklist@kitterman.com<= /a>> wrote:
On Tuesday, February 4, 2020 3:25:= 06 PM EST Dotzero wrote:
> Someone pointed to Sender-ID as an example experiment. A very poor exa= mple
> to choose. It was broken from the start. As an aside, I kept sending e= mail
> to the folks at Microsoft using @Microsoft.com email addresses by usin= g
> "Sender" to game PRA to get a neutral". Furthermore, it= dragooned senders
> who had no intention of participating in the experiment by reusing the= ir
> published SPF records in a manner they did not intend them to be used.= I
> also point out how long it took to put a stake in the heart of Sender-= ID.
> And yet even today we can find Sender-ID records littering the Interne= t and
> even a few places doing Sender-ID checks. For some definition of "= ;We", we
> are good at additions and modifications but poor at deletes.

That was me.=C2=A0 I agree it was a horrible idea.=C2=A0 The point wasn'= ;t that Sender ID
was great, it wasn't.=C2=A0 The point was that the AIB considered it re= asonable as
an experiment.=C2=A0 I think this is far less risky than that was.=C2=A0 I = was trying to
respond to the idea what the IETF doesn't support experiments where the= re are
technical concerns about the nature of the technology.=C2=A0 The AIB's = position, as
I read it, was that such experiments are fine and if the IESG has concerns,=
they should add a note to document.

Scott K


--000000000000719ee6059dc62454-- From nobody Tue Feb 4 12:49:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B675A12012E for ; Tue, 4 Feb 2020 12:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Hj7edhya2Vo6 for ; Tue, 4 Feb 2020 12:49:16 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-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 D4B0812011A for ; Tue, 4 Feb 2020 12:49:15 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id s85so13693975ill.11 for ; Tue, 04 Feb 2020 12:49:15 -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=FJvqBKlYv4C9BkZooIuzLleeF/ojuztz9NsbjE+Xe30=; b=VZdB004njfo/GWihET5GEuYwletS+tllDen6G2qoSyR4Cq270zBaUdHhNFHHWW9wXN 56AscbfDCbv7u4AIgk2lvyCOowL424fy44LszAy8CIN+bcAT1nExIBwkQAgRwxQt1UL6 nJoJzPiqnZkNIEpguaP/FEhSkqi2nTmVfwr5L9bYuwseGa87UDAIa0yWgs4c5fviQAeT /cAMVwrLaYgsCbYxgT07A7uw9Tii9hfJqL4Azx1EafNlhYEYxU/d5BS7gsiKPgMFlVx0 KvOqHNpYLtL0WZ21XW40v6yh1Vq7WzohHOng7r9WSf4IUCB/aoxGvloT6SFFfYwted+W C/Lw== 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=FJvqBKlYv4C9BkZooIuzLleeF/ojuztz9NsbjE+Xe30=; b=cDfxg/NU/NIfRkm9jYiVkFYsU6ti71vEj2pczz3pLooONOljJaVEJKBjp8C2t1TDbH Kwc2epamoBF46L0FBH9D7gH1+TbtG7MWFULVKUrFy/m9u8c74rB1D8liaBfXVLCm6WQr Up/ZJf5sq1OuTK0v8RjTl8UCHbVprAA8xoIzvG1bdB2izIEriVJYe3VASeRAxZyGOuGP OxXFq1jTZZzAhP6EuOhkLByZbSDWSc34gDi1dNKpzIMl8OwlAgzG2X59g5EwbOssC6YQ TZGBoS65uTk0eRG7VbVlq0MBG7ouRXHSALNJaKiB4dN388kbORXmWo6uiX0mNPwEWh4Y zRwA== X-Gm-Message-State: APjAAAW8FGOlXJ1tMsjW8k9Oj26eb1y3HJANE12IJhmCDo+JWux7Ym4M LXlpfamrYQe4V4nYfIwoM+M61fQUWefoJM6HbTF+wwAe6x0= X-Google-Smtp-Source: APXvYqwCt+hJHj3VLh0U05K8754fcYPCdzn1APEEuBN7IiYJDlfUj5vQNRObKq1RvbGQfaSCW5CaHM9+hcYmO2MhF2w= X-Received: by 2002:a92:8307:: with SMTP id f7mr23152757ild.73.1580849355047; Tue, 04 Feb 2020 12:49:15 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <3386547.LmEUfHP9lS@l5580> In-Reply-To: <3386547.LmEUfHP9lS@l5580> From: Andrew Kennedy Date: Tue, 4 Feb 2020 15:49:03 -0500 Message-ID: To: Scott Kitterman Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="00000000000040468f059dc62c7c" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:49:18 -0000 --00000000000040468f059dc62c7c Content-Type: text/plain; charset="UTF-8" Scott--I agree whole-heartedly. One has to wonder if delaying or impeding advancement of this I-D, because of an external dependency that appears unlikely to be resolved in a timely fashion, is making the perfect the enemy of the good. This group has much accomplish in a time frame quite possibly measured in years and that work can and should be done in parallel to competing IETF equities. The stated risk, as I understand it, appears small as it is constrained by the experiment and resolvable in future drafts (and implementations). -Andrew On Tue, Feb 4, 2020 at 2:49 PM Scott Kitterman wrote: > On Tuesday, February 4, 2020 12:39:09 PM EST Kurt Andersen (b) wrote: > > I support publishing the I-D as confirmed in the WGLC with (perhaps) some > > additional caveats regarding the ephemerality of the Experiment as deemed > > necessary by the chairs. > > > > Given the expected duration of the experiment (at least a year to collect > > some useful data, if not 2-3 years), I also support unblocking the other > > work in this WG since we ought not wait for this experiment to "conclude" > > (whatever that means) before proceeding on other work items. > > I don't see any reason the other WG items can't proceed in parallel with > the > experiment. I believe the changes to DMARC to bring it to IETF standards, > particularly the need for an alternative to the PSL, will take significant > effort to achieve. As a result, I think there's little risk that results > from > the experiment will end up being a critical path item for any WG effort. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000040468f059dc62c7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott--I agree whole-heartedly.=C2=A0 One has to wonder if= delaying or impeding advancement of this I-D, because of an external depen= dency that appears unlikely to be resolved in a timely fashion, is making t= he perfect the enemy of the good.=C2=A0 This group has much accomplish in a= time frame quite possibly measured in years and that work can and should b= e done in parallel to competing IETF equities.=C2=A0 The stated risk, as I = understand it, appears small as it is constrained by the experiment and res= olvable in future drafts (and implementations).=C2=A0=C2=A0

<= div>-Andrew

On Tue, Feb 4, 2020 at 2:49 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Tuesday, February 4= , 2020 12:39:09 PM EST Kurt Andersen (b) wrote:
> I support publishing the I-D as confirmed in the WGLC with (perhaps) s= ome
> additional caveats regarding the ephemerality of the Experiment as dee= med
> necessary by the chairs.
>
> Given the expected duration of the experiment (at least a year to coll= ect
> some useful data, if not 2-3 years), I also support unblocking the oth= er
> work in this WG since we ought not wait for this experiment to "c= onclude"
> (whatever that means) before proceeding on other work items.

I don't see any reason the other WG items can't proceed in parallel= with the
experiment.=C2=A0 I believe the changes to DMARC to bring it to IETF standa= rds,
particularly the need for an alternative to the PSL, will take significant =
effort to achieve.=C2=A0 As a result, I think there's little risk that = results from
the experiment will end up being a critical path item for any WG effort.
Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000040468f059dc62c7c-- From nobody Tue Feb 4 12:50:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD7120130 for ; Tue, 4 Feb 2020 12:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MJr7pIxhWK4t for ; Tue, 4 Feb 2020 12:50:36 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 E80F012011A for ; Tue, 4 Feb 2020 12:50:35 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id w15so24910516wru.4 for ; Tue, 04 Feb 2020 12:50:35 -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=QYFqEGrJfD61YFA7OFLu7oWmafLLXi9GeECCV9N1yTw=; b=rCxqJFdjH5DzDWEcaOWNctKg92BO2qb600VH/uq5jldRlhTkkFl+bf/UOLaKm27wOr nKMPOrwfIM1zGrQB3P1fX+K3kJr3zQBS/51HwX0na2kA/syFy+njbWYRsEO0aai46aK6 DGp1lXyCplfkVT8ly3+240fklL85rFdY8YE6LRHMYMiowML5Wr7dy7VK2AYIufr/vltt +7VMhuWaqxicT0IUJ8C+qDWF9GqtwB7EvnMxJnB7/XtaNNskUBxQWPUO1WZPtb41prlI jBaS9uzz1fZF15sYrm6BfvdFzqqixNqdfIfrI4P094UnnDbo0ejn46ialGV4p+nm9mcK h0xQ== 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=QYFqEGrJfD61YFA7OFLu7oWmafLLXi9GeECCV9N1yTw=; b=AAVhkSGgKP75yhlpXRg/Y/xVuYLPYffCNqmyFCNtvIC7xLtiGhraWB9KwY4kwtizSV tS7cgE+bHkPW1JUgDeONmc6jUqUhMdDnMQIgBcGymiw5pztObfazxsqXbtCgfm31Ah69 cPNMgVX2hytYkwY3IDomLfY5PDjj4LI7dud6OHph2sANrWmU57d65XcDmX3XUl71o2d4 GPN/MnUzXRYNpc62Uu1eZ91hhm64V1IcCFe7eRJXAdf5VJjDNi4AFJ28ryOEGJQJKhWA vE49EgT5LH34EzP3pnOa+efb03GzdSP2Bal1s5Cm56VrJvm/8YaQwLYsKOQp2uWKa2vz Vs8w== X-Gm-Message-State: APjAAAVLZ9KccKx7WrX8tGZt4nGIAGpN7VUb9YFzxI2U2nmy5JpdMWMm vlbTMSWYhRqbrENTLs+y8nb0m5n+YDlFrNYIYLMjFJog X-Google-Smtp-Source: APXvYqyp1K2ruwoFfwA6HpGwTmneqLGQk1a0YkX0DES1pMx+uBVvbWrLe8TnyKk4t1+FYFf2mQ4H1HBy8lPcQI6NJmQ= X-Received: by 2002:adf:f10a:: with SMTP id r10mr23946444wro.202.1580849434364; Tue, 04 Feb 2020 12:50:34 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> In-Reply-To: <2197062.EyKCtXoLNb@l5580> From: Dotzero Date: Tue, 4 Feb 2020 15:50:12 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fa92b6059dc630a3" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 20:50:38 -0000 --000000000000fa92b6059dc630a3 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 3:44 PM Scott Kitterman wrote: > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > > I am not against experiments, but having reread the entire thread > starting > > from Dave's post in August, I believe his concerns are valid. My question > > to the chairs and the group as a whole is whether an experiment can be > > constructed that is valid and useful without "comingling" PSD issues and > > concerns with the core of DMARC at scale? That is, the group that is > > seriously interested does their experiment amongst themselves to produce > > data that supports and justifies such changes in the wild. > > I think the draft as written works as you suggest. I think Dave's > concerns > are really about DMARC (or at least 99.6% about DMARC) and not > significantly > related to this addition. As designed, the experiment is self-contained: > > And those are my concerns as well. I would rather see DMARCbis go forward > For senders, it only affects PSDs that have been listed as participants. > > For receivers, it only affects receivers that choose to deploy code to do > the > additional check related to PSD DMARC. > > As far as I can determine, there is zero impact on anyone else. > > We have running code. I'll leave it to the chairs to evaluate the > consensus. > > Scott K > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000fa92b6059dc630a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 3:44 PM Scott = Kitterman <sklist@kitterman.com<= /a>> wrote:
On Tuesday, February 4, 2020 3:25:= 06 PM EST Dotzero wrote:
> I am not against experiments, but having reread the entire thread star= ting
> from Dave's post in August, I believe his concerns are valid. My q= uestion
> to the chairs and the group as a whole is whether an experiment can be=
> constructed that is valid and useful without "comingling" PS= D issues and
> concerns with the core of DMARC at scale? That is, the group that is > seriously interested does their experiment amongst themselves to produ= ce
> data that supports and justifies such changes in the wild.

I think the draft as written works as you suggest.=C2=A0 I think Dave's= concerns
are really about DMARC (or at least 99.6% about DMARC) and not significantl= y
related to this addition.=C2=A0 As designed, the experiment is self-contain= ed:


For senders, it only affects PSDs that have been listed as participants.
For receivers, it only affects receivers that choose to deploy code to do t= he
additional check related to PSD DMARC.

As far as I can determine, there is zero impact on anyone else.

We have running code.=C2=A0 I'll leave it to the chairs to evaluate the= consensus.

Scott K



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000fa92b6059dc630a3-- From nobody Tue Feb 4 13:20:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B847120170 for ; Tue, 4 Feb 2020 13:20: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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=3cVv/bCh; dkim=pass (2048-bit key) header.d=kitterman.com header.b=irbpIZ2F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv0MyIZO37KW for ; Tue, 4 Feb 2020 13:20:06 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7099912012E for ; Tue, 4 Feb 2020 13:20:06 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id B34E9F80308 for ; Tue, 4 Feb 2020 16:20:05 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580851205; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=iNQbQ1j9zy/VaJjfYA9k5utboEvUDv1uL4l4srziOPs=; b=3cVv/bChWUJHkj7y8wujkfqDCP7LKO9uhFRCFvAd6G2XNCN1nqJkhyoi oojBkokUmFlw+wlHASkJTPghwT6TBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580851205; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=iNQbQ1j9zy/VaJjfYA9k5utboEvUDv1uL4l4srziOPs=; b=irbpIZ2FFSEvjqhnI2Ca3kpin2+BhaB6R+b4Hvcz5AeCYcJI9D4FJsb3 snPR4fJAt7P0BU9De8UemqOkv0YPUmulPv9UoYILHeyKO47fompoI8qASQ kTQ8aPd8CTTdq0s9JDS4Trlo3cm6sgHpgtcTHl079FJoJ9SQlCq33nko5d Y44c3xAyh0Yggc7jNXHRodyySaWLsptP/AEmRp5zue3Z0BH9v/qkEpiXSS /cJm7wLymyV4Xn7L0H/44mVR7ErDHS+VUZdKACNZsSF3A2uh9OQ0mzWAvb Q6cT7+Gb+pbDZ0jXkHVDI1ishC8tIvEdcR0ByDgfcGswS4Z1pmpDsg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 879DBF801EA for ; Tue, 4 Feb 2020 16:20:05 -0500 (EST) From: Scott Kitterman To: IETF DMARC WG Date: Tue, 04 Feb 2020 16:20:05 -0500 Message-ID: <9467613.0cjHueyR6G@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 21:20:08 -0000 On Tuesday, February 4, 2020 3:50:12 PM EST Dotzero wrote: > On Tue, Feb 4, 2020 at 3:44 PM Scott Kitterman wrote: > > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote: > > > I am not against experiments, but having reread the entire thread > > > > starting > > > > > from Dave's post in August, I believe his concerns are valid. My > > > question > > > to the chairs and the group as a whole is whether an experiment can be > > > constructed that is valid and useful without "comingling" PSD issues and > > > concerns with the core of DMARC at scale? That is, the group that is > > > seriously interested does their experiment amongst themselves to produce > > > data that supports and justifies such changes in the wild. > > > > I think the draft as written works as you suggest. I think Dave's > > concerns > > are really about DMARC (or at least 99.6% about DMARC) and not > > significantly > > related to this addition. As designed, the experiment is self-contained: > > And those are my concerns as well. I would rather see DMARCbis go forward I agree on DMARCbis. I don't think advancing this draft has a significant effect on that. Worst case, if DMARCbis is done before we can reach any conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in it. I don't see anything about PSD DMARC being inherently on the critical path for DMARCbis. I suspect the current major obstacle to DMARCbis is that the question of how to take the PSL out of the equation is unsolved, despite one IETF WG that was supposed to be dedicated to the question. I don't think not publishing PSD DMARC helps move DMARCbis forward, so I think it's a false choice. Scott K > > > For senders, it only affects PSDs that have been listed as participants. > > > > For receivers, it only affects receivers that choose to deploy code to do > > the > > additional check related to PSD DMARC. > > > > As far as I can determine, there is zero impact on anyone else. > > > > We have running code. I'll leave it to the chairs to evaluate the > > consensus. > > > > Scott K From nobody Tue Feb 4 13:20:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D357F120152 for ; Tue, 4 Feb 2020 13:20:56 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jJHbP0CYrMuv for ; Tue, 4 Feb 2020 13:20:55 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 422C012012E for ; Tue, 4 Feb 2020 13:20:55 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id x123so12475464vsc.2 for ; Tue, 04 Feb 2020 13:20:55 -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=G5G2EKAzN6zJ9RKwmqnicxAo4/rLVFG72tAEcgL023k=; b=gPIZ3ldPJwVj6493p4xMB+TeQ4ay+G08YVrDDToeqY33rILD4v6AnYOBDhV3l1ySeT vaE+iII/UMsvZokB99P1HxSF/qJ5H4GJ3MQdANRZ4eMwIdgeAIpzPSGq5NkgDF+YXEBE +K2bF80CKZgpo9QDdxxmG6/YNqlEgUyuNoPCgcxipkc0q6Fsmo4sZf6ubDfYOgO5Dwq8 wxuhXIwz+4a+wt7QlRicjumhs4sS+UAAdRsE5y1l0W3Z5eJqT0iPYCsddq+s/uXevsrH xGnc3shFpMYQpLqTQhoBrpEZZtmqkZ7FCieZtiLO4jFKGiP9x/xCbqZqzwvFHEwwA/nw Hi6A== 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=G5G2EKAzN6zJ9RKwmqnicxAo4/rLVFG72tAEcgL023k=; b=eNJw6djbvx5WEkRYPuJqw4WxMFT2aTDq0cxVi8fZ7bZEB4n9FJwqSJzLlCxdEWDNen k/cQ1KFs6TezZpyEE0AM92zOpgkCGKCHTigwViZUK0YBpLfGOa7LpqICnMtDW/K0bSwj 1La8gdAKqSfy90gpDXdaXCYGOPnqGyDrL3iV+nZR6cnKNyPFNVLdYbzIjpvsF68iXAW7 9zzPHhs/xVfsIysZew0zIWlqkRIl3dSFmkGytuN6t0Fqdzjcowyse3UNMuxMOOMZ47w2 I7O8UXBLReytb2gERSJ9EKessWryFZ2lRr8wAcXGXB3KfMiGCW6Gp0ijqOnRLdtxMWsV DnjQ== X-Gm-Message-State: APjAAAV2oJItqxHQqChGaEI0O8b4CyT20UOy+YkiKHgbyXwzkrPBh+ZX CZ00RiixH3iSB6qHqK4xekklgiCc3wMOwRN+IPk= X-Google-Smtp-Source: APXvYqw6brpIXjMBPzZ5G1/SQpAuwltCatg/X1ZbhczbzUbUFTDqSsHpSTXmsMVDVkRzPh0RrKi+omNeOKzUkVXGPoc= X-Received: by 2002:a67:ce86:: with SMTP id c6mr20752696vse.7.1580851254214; Tue, 04 Feb 2020 13:20:54 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 4 Feb 2020 13:20:40 -0800 Message-ID: To: Dotzero Cc: Dave Crocker , IETF DMARC WG , Alexey Melnikov Content-Type: multipart/alternative; boundary="0000000000007343c2059dc69d6a" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 21:20:57 -0000 --0000000000007343c2059dc69d6a Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 12:25 PM Dotzero wrote: > I am not against experiments, but having reread the entire thread starting > from Dave's post in August, I believe his concerns are valid. > I want to say again that I make no assertion that any of Dave's claims are invalid. The main thing I want us to discuss is whether any of them rise to the level of halting PSD's movement through the process versus finding a way to do all of it in parallel, accepting the risks being identified. Fixing everything first will be extremely time-consuming, but it is a possible course of action. My question to the chairs and the group as a whole is whether an experiment > can be constructed that is valid and useful without "comingling" PSD issues > and concerns with the core of DMARC at scale? That is, the group that is > seriously interested does their experiment amongst themselves to produce > data that supports and justifies such changes in the wild. > Yes, that is the question. And the working group can still legitimately conclude that it wants to advance this document before conducting that experiment. As you said, rough consensus. I would remind everyone, however, that this document still needs to pass a two week IETF-wide Last Call, appropriate directorate reviews, and IESG review before it can be sent to the RFC editor queue, where again it will wait for a while. Assuming we have consensus to proceed in spite of what Dave and now Mike are saying, we're still at least a month or two from publication. That seems a long time to wait before starting the experiment and collecting data. Are we sure we want to serialize everything this way? -MSK --0000000000007343c2059dc69d6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 12:25 PM Dotzero &= lt;dotzero@gmail.com> wrote:
I am not against experiments, but having reread the entire thread start= ing from Dave's post in August, I believe his concerns are valid.

I want to say again = that I make no assertion that any of Dave's claims are invalid.=C2=A0 T= he main thing I want us to discuss is whether any of them rise to the level= of halting PSD's movement through the process versus finding a way to = do all of it in parallel, accepting the risks being identified.=C2=A0 Fixin= g everything first will be extremely time-consuming, but it is a possible c= ourse of action.

My question to the chairs and the group as a whole is whether an = experiment can be constructed that is valid and useful without "coming= ling" PSD issues and concerns with the core of DMARC at scale? That is= , the group that is seriously interested does their experiment amongst them= selves to produce data that supports and justifies such changes in the wild= .

Yes, that is the = question.=C2=A0 And the working group can still legitimately conclude that = it wants to advance this document before conducting that experiment.=C2=A0 = As you said, rough consensus.

I would remind everyone, ho= wever, that this document still needs to pass a two week IETF-wide Last Cal= l, appropriate directorate reviews, and IESG review before it can be sent t= o the RFC editor queue, where again it will wait for a while.=C2=A0 Assumin= g we have consensus to proceed in spite of what Dave and now Mike are sayin= g, we're still at least a month or two from publication.=C2=A0 That see= ms a long time to wait before starting the experiment and collecting data.= =C2=A0 Are we sure we want to serialize everything this way?
=
-MSK
--0000000000007343c2059dc69d6a-- From nobody Tue Feb 4 13:26:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F47120130 for ; Tue, 4 Feb 2020 13:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2pZLSlyUtzxj for ; Tue, 4 Feb 2020 13:26:42 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 6D77912012E for ; Tue, 4 Feb 2020 13:26:42 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id p6so12434060vsj.11 for ; Tue, 04 Feb 2020 13:26:42 -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=xSou1n1RHyrbXUgAHRVfoRT98L35jX3xin5DTRocxIg=; b=inHziCBEEVO3/YsQKfXZYTwFKg+M/6czIxdfCA54Ucl/eZ/CzY0hc1SWYd/balsLSB GDbv/Eq1s/H/BM31mCqfBf9hDs5qQxUvrJfHAt+/Bzpz2UyehLZkGqvZkMPPtdHMbHjn IY1u6SH2jLIe4RxBuYb7i3fdOMnCbLXN96eolND0yK0E28eTla6nOMt44uh8qbB9YlFi Lbk9GC1MrLcEdWmeNhfPUTfSPK++v6OVjYNRBNh/5hEFll1lOA8F7LVO8eoA8X2Q28Uq +8J2AzdO7s6Xj0G+SKYS7DPzbSUBTqAperTAs+RRnbHCqZuY0taK3kc0r/8Qcp+lNmrZ 5pMw== 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=xSou1n1RHyrbXUgAHRVfoRT98L35jX3xin5DTRocxIg=; b=VbdhvEpEizaNcI3SgnqY/WZI7m3E+mIJF5bbxFHwf/+23NJerJC2NB77wSMxyZVJDc ddPoOsptIsKdM1ThMXAcibb0FWihpWmOmioTh4IKqPr+cH8L59F9gPbLufDJU6Wl3gjw HI6f421JFBTA3fqvvxOkUelLwn4nFvVLzZY5Z9DOW1Rkdj4BatliTwR0lxo+2Uk4BLrQ in3HpyxDEYBdSsFWMvcrAFBRdp3l+b2W9PXQw0x6lKCBPYEOmDNvZqxu4QTmvWoUGKpR 88is5gIV4gkH4R8e3+NH4OBNSPdCTdwjalkVsIIBzBsoVQxSv4dYjn0+u2UrsoAaYaSp e+ZQ== X-Gm-Message-State: APjAAAUIXIbvsYg5d5ICZ5C9HuHvUJAJvSsfa/Ze0tMTzExBfpCM2TQE 4ad63mJKKHp9LpBRutuIMojHNvuqQ20iz0YhfM3cCg== X-Google-Smtp-Source: APXvYqwr9xWrX4cgIavqWqgrh5xkkop0YQCVhlVrxiFgVRdX47D+bsTYDyr/XyTG6243FqTZZzyKBQBENk0Rygm7WQ8= X-Received: by 2002:a05:6102:376:: with SMTP id f22mr19417151vsa.175.1580851601542; Tue, 04 Feb 2020 13:26:41 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> In-Reply-To: <9467613.0cjHueyR6G@l5580> From: "Murray S. Kucherawy" Date: Tue, 4 Feb 2020 13:26:30 -0800 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002710f3059dc6b26e" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 21:26:44 -0000 --0000000000002710f3059dc6b26e Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman wrote: > I agree on DMARCbis. I don't think advancing this draft has a significant > effect on that. Worst case, if DMARCbis is done before we can reach any > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in > it. > I think we've always been assuming that PSD DMARC would be input to DMARCbis, so we were planning to start the latter but not close it until the former was completed. This is the first time I've seen a different suggestion. I'd love to hear more opinions about ordering of the work here. This seems like an ideal time to review and update our milestones. I don't see anything about PSD DMARC being inherently on the critical path > for > DMARCbis. I suspect the current major obstacle to DMARCbis is that the > question of how to take the PSL out of the equation is unsolved, despite > one > IETF WG that was supposed to be dedicated to the question. > > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I > think > it's a false choice. > I think what Dave proposed about PSL separation from DMARC is entirely appropriate and pragmatic, and in fact probably easy enough: DMARC is changed so that it says the organizational domain is determined using some process [currently] external to DMARC, and then a second document explains how that process is accomplished using the PSL (and/or PSD, depending on when the experiment result comes in). That's a fairly simple edit overall, and is actually probably minor and non-controversial compared to some of the other surgery that I believe is in the queue. Seth, our illustrious WG secretary, has been compiling that list, and perhaps can give us some idea where it stands? -MSK --0000000000002710f3059dc6b26e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 1:20 PM Scott Kitt= erman <sklist@kitterman.com&= gt; wrote:
I agree on DMARCbis.=C2=A0 I don't think advancin= g this draft has a significant
effect on that.=C2=A0 Worst case, if DMARCbis is done before we can reach a= ny
conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in = it.

I think we've always been assum= ing that PSD DMARC would be input to DMARCbis, so we were planning to start= the latter but not close it until the former was completed.=C2=A0 This is = the first time I've seen a different suggestion.

I= 9;d love to hear more opinions about ordering of the work here.=C2=A0 This = seems like an ideal time to review and update our milestones.

I don't see anything about PSD DMARC being inherently on the critical p= ath for
DMARCbis.=C2=A0 I suspect the current major obstacle to DMARCbis is that th= e
question of how to take the PSL out of the equation is unsolved, despite on= e
IETF WG that was supposed to be dedicated to the question.

I don't think not publishing PSD DMARC helps move DMARCbis forward, so = I think
it's a false choice.

I think what Dave p= roposed about PSL separation from DMARC is entirely appropriate and pragmat= ic, and in fact probably easy enough: DMARC is changed so that it says the = organizational domain is determined using some process [currently] external= to DMARC, and then a second document explains how that process is accompli= shed using the PSL (and/or PSD, depending on when the experiment result com= es in).=C2=A0 That's a fairly simple edit overall, and is actually prob= ably minor and non-controversial compared to some of the other surgery that= I believe is in the queue.

Seth, o= ur illustrious WG secretary, has been compiling that list, and perhaps can = give us some idea where it stands?

=
-MSK
--0000000000002710f3059dc6b26e-- From nobody Tue Feb 4 13:44:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70BE120144 for ; Tue, 4 Feb 2020 13:44:17 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 B4BxU3a7hN7Z for ; Tue, 4 Feb 2020 13:44:16 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 21B6E1200F5 for ; Tue, 4 Feb 2020 13:44:16 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id z9so12809885wrs.10 for ; Tue, 04 Feb 2020 13:44:16 -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=cIFMYJz9Lt0Ffn64cZdVvN3cyb/zpfHP3cDF9spMMnA=; b=eQ9CEvfuShU5H+CAKjztQo5yoAT0h2Pz+BOlWYWTdPKmSJG8q8Gokbg9RSFkDx/QoY IovfLBxz1tZiUUHUa21+Q80bYSQznt44+c4jwUqen7E0o/B3iZ56sKKXnaCtbLrCqevI VAVGmr6igS7acGwG1YFwKlVIzqs+I8uKyLt7Syo8JdzK/shrx9Y8agWwELv4eDm6WTf8 hZIr/k3PJ49kD06vVNJJ1QwYjpZ3JbHhQcktxik+yi6Lhf9JY074A37rapmQivE6yDYL zzJGgxD99s8K+HkmJIH8mQkEGgIcKWd9b7SYNdpifibZC8gD1gBTqcJA+tAr/WqNLI12 3U5A== 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=cIFMYJz9Lt0Ffn64cZdVvN3cyb/zpfHP3cDF9spMMnA=; b=oUcDSiDKu7rqY1hS+0UbTVF7D1FmNzDe+DIL6VZ1I9YxR9dgOIU/Az41+OBV/zA9Dv TPRs17/CbQ/m5y/HwqUwSCxJFW+FPL/GgHWvdBBvxxUFq6iswmYPeC8c3jIrvM91Qlpn jN5nmr1fJatnjjLOAbjWe9xCWRBLukdfUMZKF3pDeF4CMXhfTRZDvlkmKrIKXGzfqn8Q wLHZ6s4KjTqTf6N5jlqZmeNhNoG7TVTx2M3/rz4+oMNudNMQyzx2vuH1Xf1WKQtGRRSC rH1PJzQ4Mb4gn5Xt9f4DPnp4RSk4NJAJh6ZpTYbdUae44ETkF0DO8LWVCWXrM69DciZC SkgA== X-Gm-Message-State: APjAAAWFz3LO4W29O8NHjADQHIyD5vzuyvCECMyaoXI1Kq9q0nqPcDSU hvI/IvDCdDw2TfO3FP0+Sh7cYQBGhQ1ZXkzkUkc= X-Google-Smtp-Source: APXvYqxm5jrcxu1sSyObw0GTakqeiKzu8+zr7Pz67fwqmlSwESMmSnvZ1Pk4Y0nYAf24Wx1xG1HgaOkcxWjJgIa3o/0= X-Received: by 2002:a5d:66cc:: with SMTP id k12mr23505284wrw.72.1580852654796; Tue, 04 Feb 2020 13:44:14 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> In-Reply-To: From: Dotzero Date: Tue, 4 Feb 2020 16:43:55 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ee777a059dc6f008" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 21:44:18 -0000 --000000000000ee777a059dc6f008 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy wrote: > > > I think what Dave proposed about PSL separation from DMARC is entirely > appropriate and pragmatic, and in fact probably easy enough: DMARC is > changed so that it says the organizational domain is determined using some > process [currently] external to DMARC, and then a second document explains > how that process is accomplished using the PSL (and/or PSD, depending on > when the experiment result comes in). That's a fairly simple edit overall, > and is actually probably minor and non-controversial compared to some of > the other surgery that I believe is in the queue. > > This would go a long way to alleviating my concerns. Michael Hammer > Seth, our illustrious WG secretary, has been compiling that list, and > perhaps can give us some idea where it stands? > > -MSK > > --000000000000ee777a059dc6f008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 4:26 PM Murray= S. Kucherawy <superuser@gmail.co= m> wrote:
<snippa= ge>

I think what Dave pro= posed about PSL separation from DMARC is entirely appropriate and pragmatic= , and in fact probably easy enough: DMARC is changed so that it says the or= ganizational domain is determined using some process [currently] external t= o DMARC, and then a second document explains how that process is accomplish= ed using the PSL (and/or PSD, depending on when the experiment result comes= in).=C2=A0 That's a fairly simple edit overall, and is actually probab= ly minor and non-controversial compared to some of the other surgery that I= believe is in the queue.


This would go a long way to alleviating my concerns.

Michael Hammer
=C2=A0
Seth, our ill= ustrious WG secretary, has been compiling that list, and perhaps can give u= s some idea where it stands?

=
-MSK

--000000000000ee777a059dc6f008-- From nobody Tue Feb 4 14:05:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B6120130 for ; Tue, 4 Feb 2020 14:05:29 -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=pj26Idgx; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FAW7LNOT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQJXAJaMVxBa for ; Tue, 4 Feb 2020 14:05:27 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A7912003F for ; Tue, 4 Feb 2020 14:05:27 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 6A1F8F80308 for ; Tue, 4 Feb 2020 17:05:25 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580853925; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=h0tjKz2spg4MrlL88POFBnqCHqlo5V5F18fLigLGVk0=; b=pj26Idgx8P6+N1ASQcRTGzzTi5jjQKZJhyxfnqd/urr3U73RjsoK8ZYk hpUa711X/AHZWHgc6sua1MXoaOztCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580853925; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=h0tjKz2spg4MrlL88POFBnqCHqlo5V5F18fLigLGVk0=; b=FAW7LNOTdJI/Avh/1661QRQvAAf6eJ9wP7/4E/wNM8IR+Rwuuf7B7vDv mkVbQbjK83KX1MPNfW+XMgt/sZMfEupJzxoewfldYbxCcfXkZa943PUlBc WfjBffwzvtTb07Ff9OlodpN/nk+XNuOqxfFw2+Lu32M4eh1C/NO0lCMrPb y7OC28imIBjl55PiPjX2yzdsFdKv76LpeRcb6hCv15Le5vKywJpkFK8CAM Dn0l8x39lOeF+OvxkWxdP7udnj9zzouKQaBjxuDqSwKGggSR1V2knkOXdg d2Er8vOus2GFCuHwzGECR5rSz98Ldx7Q/nBodjP1p1Zd+Y7I4Z+osg== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 2CC2DF801EA for ; Tue, 4 Feb 2020 17:05:25 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 04 Feb 2020 17:05:24 -0500 Message-ID: <1992438.9lekWDq1mR@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <9467613.0cjHueyR6G@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 22:05:29 -0000 On Tuesday, February 4, 2020 4:26:30 PM EST Murray S. Kucherawy wrote: > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman wrote: > > I agree on DMARCbis. I don't think advancing this draft has a significant > > effect on that. Worst case, if DMARCbis is done before we can reach any > > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in > > it. > > I think we've always been assuming that PSD DMARC would be input to > DMARCbis, so we were planning to start the latter but not close it until > the former was completed. This is the first time I've seen a different > suggestion. I think DMARCbis will take long enough that that is how things will work out, but if there's working group consensus to eventually proceed without it because it's not ready, that may well be a reasonable course of action. Proceeding with DMARC PSD doesn't tie the working group's hands. I agree that's been the plan, but if the situation changes (and DMARCbis is ready, but PSD DMARC isn't ready to be included) then we can change it. It does occur to me that a more relaxed approach to the question of if PSD DMARC will be included in the working group DMARCbis deliverable would be much easier to sustain if there was a stable reference for it (i.e. we publish the draft). > I'd love to hear more opinions about ordering of the work here. This seems > like an ideal time to review and update our milestones. I think it's not predictable when DMARCbis will be mostly complete and it's also hard to predict how long it will take to resolve the open questions in the experiment. They can run in parallel for some period of time and we can make a decision when there's one to make. There's none needed now. > > I don't see anything about PSD DMARC being inherently on the critical path > > for > > DMARCbis. I suspect the current major obstacle to DMARCbis is that the > > question of how to take the PSL out of the equation is unsolved, despite > > one > > IETF WG that was supposed to be dedicated to the question. > > > > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I > > think > > it's a false choice. > > I think what Dave proposed about PSL separation from DMARC is entirely > appropriate and pragmatic, and in fact probably easy enough: DMARC is > changed so that it says the organizational domain is determined using some > process [currently] external to DMARC, and then a second document explains > how that process is accomplished using the PSL (and/or PSD, depending on > when the experiment result comes in). That's a fairly simple edit overall, > and is actually probably minor and non-controversial compared to some of > the other surgery that I believe is in the queue. That's exactly the approach PSD DMARC takes about organizational domain, so I'm even more confused how that's problematic for PSD DMARC but doing the exact same thing solves the problem for DMARC? I also don't see how that actually helps. It seems to be something along the lines of claiming DMARC no longer relies on the PSL, but telling people to pay no attention to the man behind the curtain [1]. Scott K > Seth, our illustrious WG secretary, has been compiling that list, and > perhaps can give us some idea where it stands? > > -MSK [1] https://www.shmoop.com/quotes/pay-no-attention-man-behind-the-curtain.html From nobody Tue Feb 4 15:36:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0517C1200B7 for ; Tue, 4 Feb 2020 15:36:39 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ND_suY31clIW for ; Tue, 4 Feb 2020 15:36:37 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 4361E12007C for ; Tue, 4 Feb 2020 15:36:37 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id p14so171441vsq.6 for ; Tue, 04 Feb 2020 15:36:37 -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=lCl4Ycg7TDLavVWe5SpyP3YDqnO6bjk0+422G3gsD8E=; b=QW7nWkHx/EQ0U6FvCIIG4q6ZlqOz6bIo781TlptzE1Q3rTFoB6DNoTQM2YeTKdEo1m 1DcXXB6zz+a1WvFeqCq4om9rLWzOlaFkJeaiylYF7+9xTTMDRUu67i6P7ioKTkXrNAyP sIJr642HCDxUo+xYCi5HXMjA8K1h+NG49TYlqxmLBjSxbuCCpZUD3XPTMGy/RY262z35 a4GYoeNbmiuRPkhH4bxtNSWYzropZOzdjfu0T2m2FBOtjFIr2GKMCpH8XjDQYPGcYoV8 wt38KnYtJmJh+mMhyXnqxfCdUavaOPAycE/Cle1v5Gc4VM/n4HJv6qHX8tE9YUzLpbsQ 9Nyw== 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=lCl4Ycg7TDLavVWe5SpyP3YDqnO6bjk0+422G3gsD8E=; b=FQiVF/MKApdA088QmqDPHSzT12PPoHMAzov9o26vO5u58j9RpPvc8qHYdWgnJ6nDBd 86lQUIw+gcdSlwycDUNBTWKRnnfQR8B/xV73b1ocPZ9Tizbc2IAlqdV2JpK2NyXvw5dX 3Wq51qqxtap5vmAzSQW9mkfnWkYW1yQVlzBwYcViuHq/wlehZTX2NWIVxuqNuiawjFVC 7bG6n82/ObwMswVLDe3efKi989kr1GYq0JkRDocvl5zZcbfKzh2VYJD7IcQKU6NmCBE5 57L9VkFNDWkXaEs62mfmdwHQRPbPAdm1L0boL2zpyOdckA//QxpczEGtbGlniUtgFBwT 3hwQ== X-Gm-Message-State: APjAAAUJ4ULKkPWYKrwvFcRrltvbN7M3pJ/ma1z9ON5j2FLORzxkc39i AlHrXBh4IDojHpOGTJUSvep/rN0jZqMR/dJ+ktE= X-Google-Smtp-Source: APXvYqz8hSG5RFYu9fdPbXdBDnoVwltgymIVjRUF8fMCG/MPKh9/+MhC2jrWA5TBxOoOnEaImIG1DXfxBkuCif6FZjY= X-Received: by 2002:a05:6102:3235:: with SMTP id x21mr18994117vsf.8.1580859396314; Tue, 04 Feb 2020 15:36:36 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 4 Feb 2020 15:36:24 -0800 Message-ID: To: Dotzero Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c1db2e059dc882b7" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 23:36:39 -0000 --000000000000c1db2e059dc882b7 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 1:44 PM Dotzero wrote: > On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy > wrote: > >> >> >> I think what Dave proposed about PSL separation from DMARC is entirely >> appropriate and pragmatic, and in fact probably easy enough: DMARC is >> changed so that it says the organizational domain is determined using some >> process [currently] external to DMARC, and then a second document explains >> how that process is accomplished using the PSL (and/or PSD, depending on >> when the experiment result comes in). That's a fairly simple edit overall, >> and is actually probably minor and non-controversial compared to some of >> the other surgery that I believe is in the queue. >> >> > This would go a long way to alleviating my concerns. > The question to you, then, is: Is it the case that this MUST be done *first*? -MSK --000000000000c1db2e059dc882b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 1:44 PM Dotzero &l= t;dotzero@gmail.com> wrote:
=
On Tue, Feb 4, 2020 at 4:26 PM Mu= rray S. Kucherawy <superuser@gmail.com> wrote:
=
<= ;snippage>

I think what D= ave proposed about PSL separation from DMARC is entirely appropriate and pr= agmatic, and in fact probably easy enough: DMARC is changed so that it says= the organizational domain is determined using some process [currently] ext= ernal to DMARC, and then a second document explains how that process is acc= omplished using the PSL (and/or PSD, depending on when the experiment resul= t comes in).=C2=A0 That's a fairly simple edit overall, and is actually= probably minor and non-controversial compared to some of the other surgery= that I believe is in the queue.


<= /div>
This would go a long way to alleviating my concerns.
<= /div>

The question to you, then, is: Is it = the case that this MUST be done *first*?

-MSK
<= /div>
--000000000000c1db2e059dc882b7-- From nobody Tue Feb 4 15:43:53 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A52120115 for ; Tue, 4 Feb 2020 15:43: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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xEz1DLbMK9Lm for ; Tue, 4 Feb 2020 15:43:49 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 1BED8120127 for ; Tue, 4 Feb 2020 15:43:49 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id m16so278687wrx.11 for ; Tue, 04 Feb 2020 15:43:49 -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=kgL664yALjy3kjFeNkBVaoicE8y4dRkdZ6muihhKwnw=; b=HVtw4vhWv6KOokaE04gidJeM5PbO6r2N3F7BTiaDu4IINqq5rqmM+Jz4dcq2zQQIMy IecIvjbN8R/8n8vjqxzyrsg4MVCrVqhTIc7J5vZe+evyIQDR3xrP4n9YXg0eET4lfKlA h4BfKp300tx5beqSa961TJi7Qaz9aR0rGiv5NSiFlxLI4pyvwbqRba1KrvCW3QcO0/tl KdJQA5brv7Kn3b8YFkG+XK0D+PSjo5AMfKRJYFQ0ksqt3SskwUZfq2TDIfogc5Uyk1fT 5oLt0xmfRrc+XgSxR1Uq7orj1cLO8I7RYcH4N3BvtnM6+6MYaSQTu9QdFVF2KiJXkKSW jAnQ== 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=kgL664yALjy3kjFeNkBVaoicE8y4dRkdZ6muihhKwnw=; b=qnOOj5F3R51hOtwtnHqxxYAI7BnoNl8bqfXe9r6Xl6HJvmckg0DVHfzfvkzX8lG04o QzlrkD87iCSrue7pcYryhQ2EMDzDlaVztIVjQjaKaMSLHNBrTWP8VKut3uMsNSyllwxY MlW3GVzzFFJDoyfynrpdDUhTlmbUAp8ZZ4sy41SbCD9ujrMc4iWCrL0w27cFJQn6Vrzb bsylqxmxQkALtlqKnqXjow20QYv7DwkSd41r6H6B285nbGr/is5MnQLjJ3BkjsUcB6hD lJIb9Pc60MCYIQNi9j8D0leOTipV310ZMDd6dQpmQHGeS1ttCrF1zQuKpvhTe5rFMfRN dXZA== X-Gm-Message-State: APjAAAXTAERmXhrhYxZB9kq5BWuD/QVimVd8RxiML3EGvfPamngr1yLl n1W/KhMpgWCvQIQegE2FOYMZgoKKY3PyWPpCqzQ= X-Google-Smtp-Source: APXvYqyNF+93flAXkvO9nDgYDY7dtHBcvnbd/3rrlyghJNyM6oczxFX5DCEaKyGY6ZCkjrd9TwnwMA9PUu40fKEo6bg= X-Received: by 2002:a5d:68c5:: with SMTP id p5mr24210015wrw.193.1580859827703; Tue, 04 Feb 2020 15:43:47 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> In-Reply-To: From: Dotzero Date: Tue, 4 Feb 2020 18:43:27 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000078560e059dc89c44" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 23:43:52 -0000 --00000000000078560e059dc89c44 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 6:36 PM Murray S. Kucherawy wrote: > On Tue, Feb 4, 2020 at 1:44 PM Dotzero wrote: > >> On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy >> wrote: >> >>> >>> >>> I think what Dave proposed about PSL separation from DMARC is entirely >>> appropriate and pragmatic, and in fact probably easy enough: DMARC is >>> changed so that it says the organizational domain is determined using some >>> process [currently] external to DMARC, and then a second document explains >>> how that process is accomplished using the PSL (and/or PSD, depending on >>> when the experiment result comes in). That's a fairly simple edit overall, >>> and is actually probably minor and non-controversial compared to some of >>> the other surgery that I believe is in the queue. >>> >>> >> This would go a long way to alleviating my concerns. >> > > The question to you, then, is: Is it the case that this MUST be done > *first*? > > -MSK > Dropping IETF "MUST" on me are you? "Alex, I'll take something between "MUST" and "SHOULD" for $200". Let me cogitate on this a bit. Michael Hammer --00000000000078560e059dc89c44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 6:36 PM Murray= S. Kucherawy <superuser@gmail.co= m> wrote:
On Tue, Feb 4, 2020 at 1:44 PM Dotzero <dotzero@gmail.com> wrote:
On Tu= e, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
<snip= page>

I think what Dave p= roposed about PSL separation from DMARC is entirely appropriate and pragmat= ic, and in fact probably easy enough: DMARC is changed so that it says the = organizational domain is determined using some process [currently] external= to DMARC, and then a second document explains how that process is accompli= shed using the PSL (and/or PSD, depending on when the experiment result com= es in).=C2=A0 That's a fairly simple edit overall, and is actually prob= ably minor and non-controversial compared to some of the other surgery that= I believe is in the queue.


=
This would go a long way to alleviating my concerns.
=

The question to you, then, is: Is it the c= ase that this MUST be done *first*?

-MSK
=

Dropping IETF "MUST"= on me are you? "Alex, I'll take something between "MUST"= ; and "SHOULD" for $200".

Let me co= gitate on this a bit.

Michael Hammer=C2=A0
--00000000000078560e059dc89c44-- From nobody Tue Feb 4 18:33:48 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080AC1200F5 for ; Tue, 4 Feb 2020 18:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-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=maNPVxyP; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=UfO1h12h Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8WaN3U1CFRa for ; Tue, 4 Feb 2020 18:33:45 -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 6299C120045 for ; Tue, 4 Feb 2020 18:33:45 -0800 (PST) Received: (qmail 13501 invoked by uid 100); 5 Feb 2020 02:33:43 -0000 Date: 5 Feb 2020 02:33:43 -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:in-reply-to:cleverness; s=34b5.5e3a2987.k2002; i=news@user.iecc.com; bh=StzDHDZ5CYEgiSEHy2c/ODkvCf8FNpYaR3SKl57bmwM=; b=maNPVxyPEvBrZQDEg2whP2dn/3D2lCVd0wx7n+XYZQKRdEDIPeVhwWzb+J0GtUWJZL7argqfXx78yUViqzxIjdCxEsPmsTtJXYf7Yv47hpBjUSsdlgWHi+ZgxxOwEZh6ruF/tz95L0ADbtu3r8oVDxpBhgv0y1MeZ7zKuKJmcdah5E5tc8HXOZnMTpntN8DBlMtYb7tC/nDNdjK5c1mlmwu44ZQ2xsFmoaGydg/q6Q8khe5hBCwdMKQWfbPQSfs+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=34b5.5e3a2987.k2002; olt=news@user.iecc.com; bh=StzDHDZ5CYEgiSEHy2c/ODkvCf8FNpYaR3SKl57bmwM=; b=UfO1h12hnGIrTt4t648NM8Qu8KHaccAVgxzXB/6uMyypfmmvzOBykNYpO2IwawvLcxgfKOLUtChCnel7THw0Wedz3e5mXO7MQneEI37XraYlOhiah5qfybQ0zm/N06KzInnriMPBPo8tnDykStEl0lXfu6ERhk0RGZ0wi3aliSSHIWG60OzYCkU+EfZXBUM1MWkD32U5VJqL+caTHeYz6T6tkBUNcziTiYNdVvbZ0DoHor9UfwU4lfUXY++m67n9 Organization: Taughannock Networks References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> In-Reply-To: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Org domaines, not really Comment on 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, 05 Feb 2020 02:33:47 -0000 In article , Murray S. Kucherawy wrote: >>> >>> >>> I think what Dave proposed about PSL separation from DMARC is entirely >>> appropriate and pragmatic, and in fact probably easy enough: DMARC is >>> changed so that it says the organizational domain is determined using some >>> process [currently] external to DMARC, and then a second document explains >>> how that process is accomplished using the PSL (and/or PSD, depending on >>> when the experiment result comes in). The current DMARC spec essentially says the first part, that you have to find the org domain but waves its hands about how. I really would not want to make the PSL a requirement for any spec. The people who maintain it say in large letters on their web site not to use it for any new applications. There's no technical bar to doing something else. I have running code for a DNS lookup technique that does everything the PSL does without a tree walk at https://github.com/jrlevine/bound The problem is that we seem unable to agree on any PSL or not-PSL like thing. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Feb 4 19:20:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85B12001A for ; Tue, 4 Feb 2020 19:20:19 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3ubeZAc2xI3Z for ; Tue, 4 Feb 2020 19:20:17 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 A7C061201A3 for ; Tue, 4 Feb 2020 19:20:17 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id 66so601854otd.9 for ; Tue, 04 Feb 2020 19:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IG/aWzW/+pQzEfup8GJCsIciU+LKwzg9cD67Oyhn2J0=; b=bX9f3PQ2hKDXZBxIIMFpb7vTnCBiIsHZuenjmdWgdztpTe+NC2QC/LfgjwpaASKYY0 fdn+WMoRvbXSidxRA+u4uEor8Ebu5SDN4EcwmOXF6CEy0ZTb3ttEtRw3v+kcirkpaEXQ 7hD907tuvreRJkmmZNvTg1O3OnOfm5t54vuNl6q7hWBQoNl+rpTs7r2vKPbmV3DqHVAv X+2bDvyf97omMs/myvHMMenxNpbzcT2ZzvevfjNHDtM/3QLl9GnKllDV0kbwp3tZ3P3J 4np5ZpuzRRfamQ7011+gBzh5frWQz5kF2YRIe0/orps/qZod/Z3/2pCj0JHBKWlCurSw 1aKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IG/aWzW/+pQzEfup8GJCsIciU+LKwzg9cD67Oyhn2J0=; b=FPnnkWH3bCZ6JkITBhubAxNXJqDdvJZmALd0vb+LnU9eHbSMJusRBE9GJc33T6AolB JSfu507DjUD9388F1XnMnDPO5O4VdFH6C/qh8a++fQn4fPrAvx+0khjt/eI/I9efFv7A MuK/dgbJlnDbU1l5mQLS3x6i6Gl8ZeUbrgROUqLxR27GtR6jmY8g90Su2TE8obc4ukyQ Mqljij60Yh5hfATvJnnRwm/PDSRG+8JHV2ZkOlSQAs/dwYa0QeEAubN1sSmlaITPMmRl w5UCVUkBq7gRZkn1QnmZ4bkUPTcFuqRR4GdNr5Q0rhV4ZrZwq6CuGlfTkcV6AfV1luuZ FkSw== X-Gm-Message-State: APjAAAVWg16FqYrPH4QIWAyNbKEtIc5MpYzSAv7iRN0EzXZmpSmZlJD+ jwqNom912drz6REOU+XFVQY= X-Google-Smtp-Source: APXvYqxCGY3L27hjZqELbEdHoomIiepuGaKm6I6NZCqohVBI3VlaVCq4shxhVhcK0TDXas8HytWaKA== X-Received: by 2002:a05:6830:15c2:: with SMTP id j2mr23095482otr.351.1580872816898; Tue, 04 Feb 2020 19:20:16 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:4186:9fa4:da5d:f255? ([2600:1700:a3a0:4c80:4186:9fa4:da5d:f255]) by smtp.gmail.com with ESMTPSA id i12sm8590810otk.11.2020.02.04.19.20.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Feb 2020 19:20:16 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG , Alexey Melnikov References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> From: Dave Crocker Message-ID: <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> Date: Tue, 4 Feb 2020 19:20:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E55BAD87CA4CBACCA9264DBC" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 03:20:19 -0000 This is a multi-part message in MIME format. --------------E55BAD87CA4CBACCA9264DBC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit (I am trying to formulate a response on the higher-level technical and process issues under consideration, but decided to respond now on these particulars, since they are more focused...) On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote: > Dave, > > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker > wrote: > >> Nothing I've worked on at the IETF with such a label is something >> I would necessarily stand behind as Internet-scalable. > > Such as? > > > RFC 6541 comes to mind.  To the best of my knowledge, it's an > experiment that never even ran. I don't recall that scaling limitation was an embedded and acknowledged fact about that spec. And with a quick scan I don't see anything about that in the document. There is a difference between having some folk be critical of an experiment, versus have its non-scalability be an admitted limit to its future.  That is, you or I or whoever might know a spec sucks and can't succeed, but that's different from having the formal process declare that an experiment is /intended/ not to scale, which seems to be the case here. > Implementations shipped, but its use on the open Internet was never > detected or reported.  And I had my doubts about the scalability of > the second DNS check that was added to it, but it didn't seem like it > could go forward without. > > One that wasn't mine: RFC 6210, an experiment to prove how bad > something can be. There is a reasonable argument to be made that little about /any/ security spec actually scales well, but that's such a cheap shot, I wouldn't dream of taking it. However, yeah, "to find out how bad including hash parameters will be" does seem to provide an existence proof for using IETF Experimental to bench-test something rather than as a gateway to standard for that something.  sigh. >> But I would probably expect something at Informational probably >> to scale, and anything with "Standard" in it certainly to scale. > Laying any general expectation on an IETF Informational RFC would > be a mistake, because there is so much variety in their content > and intent. > > > Why would the expectations for Experimental be higher than for > Informational?  LMTP is Informational, and it certainly needs to succeed. As a rule -- or certainly a solid pattern -- Experimental means that the document wants to be standards track or BCP but needs some vetting before being permitted that honor.  Informational docs don't have an expectation of making it to standards track. >> So: Can you propose any sort of specific restructuring of the >> document or the experiment that achieves the same goal as the >> current version while also resolving your concerns? > > I'm pretty sure I've raised fundamental concerns about this work > and that those concerns have not been addressed.  The simple > summary is that the way to restructure this work is to go back to > first principles.  But there doesn't seem to be any interest in > having that sort of discussion. > > I thought we were having that sort of a discussion right here. > > Your position as I recall is that we have no choice but to take all of > this back to first principles and separate DMARC from the > determination of Organizational Domain (i.e., make them separate > documents) before PSD can proceed. Unfortunately, that's accurate. At the least, I'd expect to see thoughtful responses and some breadth of support for those responses, countering the fundamental concerns I expressed. I don't recall seeing responses with such substance. (One of the challenges for me, in trying to formulate the 'thoughtful' response I'm considering is to provide/repeat a concise summary of those fundamental concerns.  As I recall they were both architectural and operational.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------E55BAD87CA4CBACCA9264DBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
(I am trying to formulate a response on the higher-level technical and process issues under consideration, but decided to respond now on these particulars, since they are more focused...)


On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker <dcrocker@gmail.com> wrote:
Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable. 

Such as?


RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment that never even ran. 


I don't recall that scaling limitation was an embedded and acknowledged fact about that spec. And with a quick scan I don't see anything about that in the document.

There is a difference between having some folk be critical of an experiment, versus have its non-scalability be an admitted limit to its future.  That is, you or I or whoever might know a spec sucks and can't succeed, but that's different from having the formal process declare that an experiment is /intended/ not to scale, which seems to be the case here.


Implementations shipped, but its use on the open Internet was never detected or reported.  And I had my doubts about the scalability of the second DNS check that was added to it, but it didn't seem like it could go forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something can be.


There is a reasonable argument to be made that little about /any/ security spec actually scales well, but that's such a cheap shot, I wouldn't dream of taking it. 

However, yeah, "to find out how bad including hash parameters will be" does seem to provide an existence proof for using IETF Experimental to bench-test something rather than as a gateway to standard for that something.  sigh.


But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.

Why would the expectations for Experimental be higher than for Informational?  LMTP is Informational, and it certainly needs to succeed.

As a rule -- or certainly a solid pattern -- Experimental means that the document wants to be standards track or BCP but needs some vetting before being permitted that honor.  Informational docs don't have an expectation of making it to standards track.


So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?

I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed.  The simple summary is that the way to restructure this work is to go back to first principles.  But there doesn't seem to be any interest in having that sort of discussion.

I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of this back to first principles and separate DMARC from the determination of Organizational Domain (i.e., make them separate documents) before PSD can proceed.


Unfortunately, that's accurate. At the least, I'd expect to see thoughtful responses and some breadth of support for those responses, countering the fundamental concerns I expressed. I don't recall seeing responses with such substance. 

(One of the challenges for me, in trying to formulate the 'thoughtful' response I'm considering is to provide/repeat a concise summary of those fundamental concerns.  As I recall they were both architectural and operational.)


d/ 
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------E55BAD87CA4CBACCA9264DBC-- From nobody Tue Feb 4 22:13:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB3120096 for ; Tue, 4 Feb 2020 22:13:11 -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=gKscV6bo; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Sjv4kL1U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKccbMXJi_jq for ; Tue, 4 Feb 2020 22:13:08 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E4B1207FC for ; Tue, 4 Feb 2020 22:13:03 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id CFA75F80248 for ; Wed, 5 Feb 2020 01:13:02 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1580883182; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=onEcKcPTefsG3W+7DSJg9rVDjZ4zvA0i4nk1imHUH1w=; b=gKscV6boVyXTqZo2RHffLgOIGP1Xy/0y3DYu7ahGaxbhSvXfkVmLkWSc eX4PUxoxmEsPZ3UYSjS1UAoBp5zJDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1580883182; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=onEcKcPTefsG3W+7DSJg9rVDjZ4zvA0i4nk1imHUH1w=; b=Sjv4kL1UsK3tP2gLK1/lSwSC0ldZd/VOpscrL0B/XAn7JWB3HB0sJjVW J7zPuyjHHjmEENC60LsP7GsAYWT9m3T6lYQ0TjrBeD34rSq1DdSmtSiXtv NsIK7KefRi8RlIYFZY/pI50w52p9lWs1IOiJjYxJGd2t2hlsPSygjnyy74 bY8/EdOZ6FFiXnMKhkjBrk29/sVYrorG6NGYxdd/hW2Ouei/XApW5VMz/8 gHsCy4LJG4bhueXvgtfga3AKhIRLDKig6Bm7By18AXo75UOt/z9BQPxHyr FhHPYEaLMzNU927xPCQZq9yhD0kfd6jyXwsG4QumIwqwacoz7LJCKw== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 9C353F80027 for ; Wed, 5 Feb 2020 01:13:02 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 05 Feb 2020 01:13:02 -0500 Message-ID: <4570465.bmySQvRiU0@l5580> In-Reply-To: <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 06:13:11 -0000 On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote: > (I am trying to formulate a response on the higher-level technical and > process issues under consideration, but decided to respond now on these > particulars, since they are more focused...) > > On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote: > > Dave, > > > > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker > > > > wrote: > >> Nothing I've worked on at the IETF with such a label is something > >> I would necessarily stand behind as Internet-scalable. > > > > Such as? > > > > RFC 6541 comes to mind. To the best of my knowledge, it's an > > experiment that never even ran. > > I don't recall that scaling limitation was an embedded and acknowledged > fact about that spec. And with a quick scan I don't see anything about > that in the document. > > There is a difference between having some folk be critical of an > experiment, versus have its non-scalability be an admitted limit to its > future. That is, you or I or whoever might know a spec sucks and can't > succeed, but that's different from having the formal process declare > that an experiment is /intended/ not to scale, which seems to be the > case here. This claim seems to me to be unrelated to anything in the draft. Would you please point to where you found this? > > Implementations shipped, but its use on the open Internet was never > > detected or reported. And I had my doubts about the scalability of > > the second DNS check that was added to it, but it didn't seem like it > > could go forward without. > > > > One that wasn't mine: RFC 6210, an experiment to prove how bad > > something can be. > > There is a reasonable argument to be made that little about /any/ > security spec actually scales well, but that's such a cheap shot, I > wouldn't dream of taking it. > > However, yeah, "to find out how bad including hash parameters will be" > does seem to provide an existence proof for using IETF Experimental to > bench-test something rather than as a gateway to standard for that > something. sigh. > > >> But I would probably expect something at Informational probably > >> to scale, and anything with "Standard" in it certainly to scale. > > > > Laying any general expectation on an IETF Informational RFC would > > be a mistake, because there is so much variety in their content > > and intent. > > > > Why would the expectations for Experimental be higher than for > > Informational? LMTP is Informational, and it certainly needs to succeed. > > As a rule -- or certainly a solid pattern -- Experimental means that the > document wants to be standards track or BCP but needs some vetting > before being permitted that honor. Informational docs don't have an > expectation of making it to standards track. Would you withdraw your objections if we made this informational? > >> So: Can you propose any sort of specific restructuring of the > >> document or the experiment that achieves the same goal as the > >> current version while also resolving your concerns? > > > > I'm pretty sure I've raised fundamental concerns about this work > > and that those concerns have not been addressed. The simple > > summary is that the way to restructure this work is to go back to > > first principles. But there doesn't seem to be any interest in > > having that sort of discussion. > > > > I thought we were having that sort of a discussion right here. > > > > Your position as I recall is that we have no choice but to take all of > > this back to first principles and separate DMARC from the > > determination of Organizational Domain (i.e., make them separate > > documents) before PSD can proceed. > > Unfortunately, that's accurate. At the least, I'd expect to see > thoughtful responses and some breadth of support for those responses, > countering the fundamental concerns I expressed. I don't recall seeing > responses with such substance. > > (One of the challenges for me, in trying to formulate the 'thoughtful' > response I'm considering is to provide/repeat a concise summary of those > fundamental concerns. As I recall they were both architectural and > operational.) Help me understand. Currently the proposal is: PSD DMARC defines PSD relative to org domain and points to DMARC for how one finds org domain (no PSL reference in the PSD DMARC draft - there have been at times, but there aren't now). You find this unacceptable, as I understand it. What you think we should do is first split the DMARC spec into two so that: PSD DMARC defines PSD relative to org domain and points to DMARCbis for how one finds org domain and DMARCbis points to a new spec that explains how to use the PSL to find the org domain (or some other method if it's agreed). You find this acceptable, as I understand it. Assuming that's correct, please help me understand what PSD DMARC is affected at all. All it does is consume the org domain however DMARC/DMARCbis choose to define it. I don't see as it makes a difference from a PSD DMARC perspective. I get that you want to fix the architectural warts in DMARC and I don't disagree with you about working on that. Where I get lost is how PSD DMARC has anything to do with it. PSD DMARC could be done first, in parallel, or after the DMARC architectural work. It would have no impact on that work. I would like to understand your position, but I don't, so please help me out here. Scott K From nobody Tue Feb 4 22:30:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D625120096 for ; Tue, 4 Feb 2020 22:30: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW7QVhtduMpA for ; Tue, 4 Feb 2020 22:30:12 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0: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 837FE120045 for ; Tue, 4 Feb 2020 22:30:12 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id f5so925584ilq.5 for ; Tue, 04 Feb 2020 22:30:12 -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=FNo0XB0XIIJPAZWlpvIz3a/kKMSxAJKLamCd72Jpz74=; b=AdGDBHXzYbQZhxIsu5ySd3dW2mAIvQE/AXR1/1bIdXAHt3K2NV5qNJrULcFupRVM0C AqngUVzLwaGyIIUeN2MNwxsBNG1MQlmHjE3/MQT89jqnM+S+Hnf+/ueNhEXVH+fURSgD sYjm9MowRrpTrWAcg0Nwe6GvgqGPAUoGQjLi8= 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=FNo0XB0XIIJPAZWlpvIz3a/kKMSxAJKLamCd72Jpz74=; b=mtSNzhdRCZ6YkYFT2QUNoQDjHp6678RCFTGAm5zkIX9jFw9r0IJZHVdWB+/tf0jM8h aOLN/IOATyE1jCgVUBcZ0Np7vzlzK0LgaYFF/zlVLZDtQfuer3oyk3LUhdOxz0Dyluqc 6rUI6cy+2+8SFmRAQzUXXMOfGMaL83aYer5WOkQzil3/hPZQqRBIqTTh8/a0gfMpavoa AHT8NBu4kDZSeVWPD75podJ/kkZmBnyceksAn9bUi/xNxKf2GCrZ9HMl+IVW9jTFia6/ +vhbhMCIE6EH+oN2r91wyhUxAMhbvjZwIY12xvaSM/prSAAnI7OEHq+KXgfsYb6u3Y/p GqXA== X-Gm-Message-State: APjAAAVxEh6RgPLCtHjEGkaSWBk1iuwGS3x41s/yJIJF3uJfZYgdCzH2 u6y7wIhtGPGw/lQR2oHRlcIcAP7WRYQaIuBl50na85FCXBP72A== X-Google-Smtp-Source: APXvYqxHL4grQiYJk15Ddm3OBQJaIs0eXN4NJ5RUc1KiJ2ig4QGqrqXZYbOnYmXQw5IRAIei0PKeEwxsI4GfcJunt60= X-Received: by 2002:a92:b506:: with SMTP id f6mr25023218ile.103.1580884211762; Tue, 04 Feb 2020 22:30:11 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> <4570465.bmySQvRiU0@l5580> In-Reply-To: <4570465.bmySQvRiU0@l5580> From: "Kurt Andersen (b)" Date: Tue, 4 Feb 2020 22:29:24 -0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dfa39c059dce493a" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 06:30:14 -0000 --000000000000dfa39c059dce493a Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman wrote: > > Assuming that's correct, please help me understand what PSD DMARC is > affected at all. All it does is consume the org domain however > DMARC/DMARCbis choose to define it. I don't see as it makes a difference > from a PSD DMARC perspective. > > I get that you want to fix the architectural warts in DMARC and I don't > disagree with you about working on that. Where I get lost is how PSD DMARC > has anything to do with it. PSD DMARC could be done first, in parallel, or > after the DMARC architectural work. It would have no impact on that work. > > I would like to understand your position, but I don't, so please help me > out here. > Scott, Thank you for expressing this so clearly. This is exactly the issue that I've been trying to understand in this series of conversations. It seems like the PSD proposal has been being used as leverage to have an (almost) entirely separate discussion about DMARCbis. --Kurt --000000000000dfa39c059dce493a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2020 at 10:13 PM Scott Kit= terman <sklist@kitterman.com= > wrote:

Assuming that's correct, please help me understand what PSD DMARC is af= fected=C2=A0at all.=C2=A0 All it does is consume the org domain however DMA= RC/DMARCbis choose=C2=A0to define it.=C2=A0 I don't see as it makes a d= ifference from a PSD DMARC perspective.

I get that you want to fix the architectural warts in DMARC and I don't= disagree with you about working on that.=C2=A0 Where I get lost is how PSD= DMARC has anything to do with it.=C2=A0 PSD DMARC could be done first, in = parallel, or after the DMARC architectural work.=C2=A0 It would have no imp= act on that work.

I would like to understand your position, but I don't, so please help m= e out here.

Scott,

=
Thank you for expressing this so clearly. This is exactly the issue th= at I've been trying to understand in this series of conversations. It s= eems like the PSD proposal has been being used as leverage to have an (almo= st) entirely separate discussion about DMARCbis.

-= -Kurt=C2=A0
--000000000000dfa39c059dce493a-- From nobody Wed Feb 5 03:02:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83812012D for ; Wed, 5 Feb 2020 03:02:43 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Euufg85yRwXi for ; Wed, 5 Feb 2020 03:02:35 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 7A0CE120099 for ; Wed, 5 Feb 2020 03:02:35 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id c84so2174638wme.4 for ; Wed, 05 Feb 2020 03:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9K1AZWfnfjChlhVQrVQ/a3ay6nYqe0HGmoYBNPD/cL8=; b=P5u+K3Flw3VGEzEGxg958+dhGDMVFvOZh0uY9p90UXFZdfhIMm4QR7q2DdQUTKIwty KdJHsJfn4DPgiT754RJ/5dusTbb4lC4sC5ez8Q6HpgEXG1iOR1cRsTkgQBU6r7Tb67O3 sJqHyF2+yUDnOl11JieH+oNXvDvZoKzRpy4ns= 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=9K1AZWfnfjChlhVQrVQ/a3ay6nYqe0HGmoYBNPD/cL8=; b=O2nOS2iupAF2Bik+1mvkUWoJd7aNFZ13k0gU86OkablOUvJsbDleRI1sjnuok0Jdu8 ZPJqDEXgDS+FxWT87Pvqq6iDEnK3rVWZ1wI6s2WOTKb8Cr8mvelImBhpd6FLTRVWOoSH 9LZ8m7COMUXwm1hrtJwwyFPIMqF8DoJam5AU2fkUpkNRBsmbDUi6C9LmKQag9iLQmKbI rtmNUc4RizKXz8NwqbsQPlEH91MWp9U5XDEwybP5Yf+CE6Y99XWmWYxnb54ZgTRVmKOs vWQLJZsgBS4KSJh4Zhp0HA8sO+gQ9Yixb/NpKlmpSz2SPL/4xwYkW7WzIahjlvIm5ZIa /V3A== X-Gm-Message-State: APjAAAVflh+RPv6XOOgP8ENtMOt7XA2nZWKqysEoZJ8kuOjl5u08g+Ur LYuLha8BScNBRch/Kj6xVa+jIj4RDRauc/4FPBu+//xAaWA= X-Google-Smtp-Source: APXvYqxkcP54fhS98PH1FBjqX18A5+3HdlXfUtMIBBzL/cW9A1fYjmm7a/pV8G8Th/2HLuA3KZ7KWm7VgZr/RK2bSVk= X-Received: by 2002:a1c:3b09:: with SMTP id i9mr5020794wma.31.1580900553574; Wed, 05 Feb 2020 03:02:33 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: Craig Schwartz Date: Wed, 5 Feb 2020 05:59:11 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ebea35059dd21785" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 11:02:43 -0000 --000000000000ebea35059dd21785 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Murray, Notwithstanding the extensive commentary on this list in the last 24 hours, you wrote the following so let me share some thoughts. <<>> First, while I know you've said the needs of external actors won't weigh on your decision about moving forward, I would like to mention that having a stable reference for PSD DMARC will help us with working towards policy changes that would allow us to participate in this experiment. It may not be impor= tant to the WG Chairs' decision on the draft, but there are stakeholders for whom it is important. Second, I have consulted with my technical advisors and our conclusion is that the risks to deployed infrastructure if this experiment becomes permanent are negligible. Currently the PSL has 8,818 non-comment entries. For PSD DMARC, we have 4. We don't believe adding a list that's .04% as long as the one that is currently being used successfully for DMARC is an issue at all. Additionally, we believe that the use of this list to constrain when PSD DMARC lookups will need to occur provides a very useful limit on the impacts to DNS (not that we would expect them to be significant regardless). Finally, if the DMARC working group is successful in updating DMARC not to use the PSL, then PSD DMARC would naturally evolve to use that solution (PSD is currently defined relative to org domain, so if the method for finding org domain changes, PSD DMARC will use it without any change needed). As a result, to the extent the use of lists like the PSL is a problem, PSD DMARC is already ready to take advantage of whatever solution the IETF develops. In short, we've reviewed this and see many advantages to proceeding and none for not. Craig *--* Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Office: +1 202 589 2532 Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com On Mon, Feb 3, 2020 at 10:08 PM Murray S. Kucherawy wrote: > On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz wrote: > >> Hi Murray, >> >> <<> of needing this work but not knowing how to engage; you either give your >> feedback on the list or privately to the chairs or Area Directors, or yo= u >> are along for whatever ride results. Please indicate, as soon as possib= le, >> where your support lies given the above.>>> >> >> In my capacity as managing director of fTLD Registry Services (fTLD), >> registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would >> provide invaluable threat intelligence to domain registrants and to TLD >> administrators like ourselves for NXDOMAINs. PSD has tremendous value to >> specialized TLDs including, but not limited to, .BRANDS, community-based >> domains, high-security domains, governments, etc. and as such I believe = PSD >> should proceed. I=E2=80=99ve previously posted to this list expressing t= his view >> and while fTLD cannot participate in experimentation due to a prohibitio= n >> by ICANN, we remain committed to supporting and seeing this work continu= e. >> > > Craig, > > Thanks for this, and for one other person that sent to the chairs > privately (it was a list non-member caught in moderation, nothing secret)= . > > To be clear, however: I think the working group mailing list archive has > enough of a record that participants think the experiment will be useful = or > even critical to the evolution of DMARC, though people are of course > welcome to affirm that support for the record. The question being put, > however, goes to the form of the experiment and the current form of DMARC > as a protocol with respect to determining Organizational Domains, and > whether there are indeed risks to the deployed infrastructure that the > experiment could become permanent. That's the meaty stuff that would > really help to move this along. > > -MSK > --000000000000ebea35059dd21785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Murray,

Notwithstanding the extensive commentary=C2=A0on t= his list in the last 24 hours, you wrote the following so let me share some= thoughts.=C2=A0

<<<To be clear, however: I think the working group mailing list = archive has enough of a record that participants think the experiment will = be useful or even critical to the evolution of DMARC, though people are of = course welcome to affirm that support for the record.=C2=A0 The question be= ing put, however, goes to the form of the experiment and the current form o= f DMARC as a protocol with respect to determining Organizational Domains, a= nd whether there are indeed risks to the deployed infrastructure that the e= xperiment could become permanent.=C2=A0 That's the meaty stuff that wou= ld really help to move this along.>>>

First, while I know you've said= the needs of external actors won't weigh on=C2=A0your decision about moving forward= , I would like to mention that having a=C2=A0stable reference for PSD DMARC will help us= with working towards policy=C2=A0changes that would allow us to participate in this exp= eriment.=C2=A0 It may not be=C2=A0important to the WG Chairs' decision on the draft,= but there are stakeholders=C2=A0for whom it is important.

Second, I ha= ve consulted with my technical advisors and our conclusion is that=C2=A0the risks to dep= loyed infrastructure if this experiment becomes permanent are=C2=A0<= span style=3D"font-family:Arial,Helvetica,sans-serif">negligible.=C2=A0 Cur= rently the PSL has 8,818 non-comment entries.=C2=A0 For PSD DMARC,=C2=A0we have 4.=C2=A0= We don't believe adding a list that's .04% as long as the one that= =C2=A0is curr= ently being used successfully for DMARC is an issue at all.=C2=A0Additionally, we believ= e that the use of this list to constrain when PSD DMARC=C2=A0lookups will need to occur = provides a very useful limit on the impacts to DNS
(not that we would expect them to be significant regardless)= .

Finally, if the DMARC working group is successful in upd= ating DMARC not to use=C2=A0the PSL, then PSD DMARC would naturally evolve to use that s= olution (PSD is=C2=A0currently defined relative to org domain, so if the method for find= ing org=C2=A0= domain changes, PSD DMARC will use it without any change needed).=C2=A0 As = a=C2=A0result= , to the extent the use of lists like the PSL is a problem, PSD DMARC is=C2= =A0already re= ady to take advantage of whatever solution the IETF develops.

In short, we've reviewed this and see many advantages to proceeding= and none=C2=A0for not.

Craig
<= div dir=3D"ltr">
--

Craig Schwartz
Managing Director
fT= LD Registry Services | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz






=
=

On Mon, Feb 3, 2020 at 10:08 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
O= n Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz <craig@ftld.com> wrote:
Hi Murray,

<<<The chairs will not accept hearsay replies o= r opinions, or expressions of needing this work but not knowing how to enga= ge; you either give your feedback on the list or privately to the chairs or= Area Directors, or you are along for whatever ride results.=C2=A0 Please i= ndicate, as soon as possible, where your support lies given the above.>&= gt;>

In my capacity as managing director of fTLD Registry Services (fTLD), r= egistry operator of the .BANK and .INSURANCE TLDs, I believe PSD would prov= ide invaluable threat intelligence to domain registrants and to TLD adminis= trators like ourselves for NXDOMAINs. PSD has tremendous value to specializ= ed TLDs including, but not limited to, .BRANDS, community-based domains, hi= gh-security domains, governments, etc. and as such I believe PSD should pro= ceed. I=E2=80=99ve previously posted to this list expressing this view and = while fTLD cannot participate in experimentation due to a prohibition by IC= ANN, we remain committed to supporting and seeing this work continue.
<= /font>


Craig,

=
Thanks for this, and for one other person that sent to the chairs priv= ately (it was a list non-member caught in moderation, nothing secret).

To be clear, however: I think the working group mailin= g list archive has enough of a record that participants think the experimen= t will be useful or even critical to the evolution of DMARC, though people = are of course welcome to affirm that support for the record.=C2=A0 The ques= tion being put, however, goes to the form of the experiment and the current= form of DMARC as a protocol with respect to determining Organizational Dom= ains, and whether there are indeed risks to the deployed infrastructure tha= t the experiment could become permanent.=C2=A0 That's the meaty stuff t= hat would really help to move this along.

-MSK
<= /div>
--000000000000ebea35059dd21785-- From nobody Wed Feb 5 06:41:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB61200C1 for ; Wed, 5 Feb 2020 06:41:57 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ClsHq9vOCyra for ; Wed, 5 Feb 2020 06:41:55 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E958C120059 for ; Wed, 5 Feb 2020 06:41:54 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id d62so907448oia.11 for ; Wed, 05 Feb 2020 06:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ryOZq1uBQd84XtCk/+RJUY65fR+6QkPBndSh3i0ChR4=; b=MctTa62FhLPWOGUEgDfqe4vbEPKO4L81nZV2s4aGR10s97KSi/lHttpLl8643vRcBw 8QS/uF4c2qmPx6RB85Q0C1pZE8sPKCjTzaaeyYpGHQlsuo2zzqsX6lIXpkTnww4CXg9N C05WHf3gTfP3bCJLBJgHO751kaWq9rX44uLc5rrdSA+cFMj7gVhVFmwBB+/QTp40e7pn e7Enu4Wy8p6SSl0RBAc2Z7G9CXZD29NFafIlf16pZe2AGB2QRmuU7dTPxHVNwPICz37w EZRMdU0idp11SAFhZngPtKtAvd8F+x+PXZfnCbWd4H5RgKuX0hFzHb1FZ7DJwQtEfzss HIkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ryOZq1uBQd84XtCk/+RJUY65fR+6QkPBndSh3i0ChR4=; b=g4ZHFRY7EP1J4QKoPpI0Qo30RVDwXpLqcWCDtym8WrL5bSC5gZHjFSo+XWpzwz1jnl mp8g/L7PAVQhRy74n7bj7KqHK2hvHOtSVjqw7waoxlHE7h+BnMqKB9pEQ4ma/DFwuXoc IwmLk7txOqB9dHtzzMCR72bGMR9k7dWYZttX8tPJMJFi45gGMjUOP7XtDoazuGkaceQ8 udz5LOxhj5yrJ3E6eDBXsEXoWW6iFwxRxtKAXqFA32ei1YgvN3IKCz7mlMi0Cg2vKJbh bj8ay9bsvS9Q7tid96dKddp0bNUJhvwXnheg5Sy2o5Jf04BjfvHGeFfull4CSUZLDqeh jCPQ== X-Gm-Message-State: APjAAAVCIbUf1yQZnNIkZ2AmfPE/9EeGWp1oim8sIYFO0tBGOY83RSPY B3Ig3CarjqF+yeVuOgKL7ejZTn3P4TA= X-Google-Smtp-Source: APXvYqyPpH48sYZAgm9RAO2AR6ptxRjb+U8j/OlwroRrj0W6rchVo7pbCqcDEuvsz7KPUZLWA9UDoA== X-Received: by 2002:aca:c7cb:: with SMTP id x194mr3065995oif.157.1580913713398; Wed, 05 Feb 2020 06:41:53 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:e84c:3508:22dd:d63c? ([2600:1700:a3a0:4c80:e84c:3508:22dd:d63c]) by smtp.gmail.com with ESMTPSA id t131sm7830061oih.35.2020.02.05.06.41.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Feb 2020 06:41:51 -0800 (PST) To: Scott Kitterman , dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> <4570465.bmySQvRiU0@l5580> From: Dave Crocker Message-ID: Date: Wed, 5 Feb 2020 06:41:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <4570465.bmySQvRiU0@l5580> Content-Type: multipart/alternative; boundary="------------82BBC78642D3087E7C646428" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 14:41:57 -0000 This is a multi-part message in MIME format. --------------82BBC78642D3087E7C646428 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/4/2020 10:13 PM, Scott Kitterman wrote: > On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote: >> >> I don't recall that scaling limitation was an embedded and acknowledged >> fact about that spec. And with a quick scan I don't see anything about >> that in the document. >> >> There is a difference between having some folk be critical of an >> experiment, versus have its non-scalability be an admitted limit to its >> future. That is, you or I or whoever might know a spec sucks and can't >> succeed, but that's different from having the formal process declare >> that an experiment is /intended/ not to scale, which seems to be the >> case here. > This claim seems to me to be unrelated to anything in the draft. Would you > please point to where you found this? Murray's 12/3 email: "I don't think it's based entirely on naivety.  I think there's a healthy dose of feeling that the experiment as it's currently designed couldn't possibly scale to "the entire domain namespace" and/or "all servers on the Internet", so in that sense from where I sit there's a built in safeguard against this becoming a permanent wart." >> >>> Why would the expectations for Experimental be higher than for >>> Informational? LMTP is Informational, and it certainly needs to succeed. >> As a rule -- or certainly a solid pattern -- Experimental means that the >> document wants to be standards track or BCP but needs some vetting >> before being permitted that honor. Informational docs don't have an >> expectation of making it to standards track. > Would you withdraw your objections if we made this informational? It would eliminate my concerns about this being Experimental, of course.  With an equal 'of course', it would not affect the technical concerns. > > Help me understand. I'll try with the other note I'm considering. However my intent for that note is as a summary, not as offering some new material. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------82BBC78642D3087E7C646428 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/4/2020 10:13 PM, Scott Kitterman wrote:
On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:


I don't recall that scaling limitation was an embedded and acknowledged
fact about that spec. And with a quick scan I don't see anything about
that in the document.

There is a difference between having some folk be critical of an
experiment, versus have its non-scalability be an admitted limit to its
future.  That is, you or I or whoever might know a spec sucks and can't
succeed, but that's different from having the formal process declare
that an experiment is /intended/ not to scale, which seems to be the
case here.

This claim seems to me to be unrelated to anything in the draft.  Would you 
please point to where you found this?


Murray's 12/3 email:

"I don't think it's based entirely on naivety.  I think there's a healthy dose of feeling that the experiment as it's currently designed couldn't possibly scale to "the entire domain namespace" and/or "all servers on the Internet", so in that sense from where I sit there's a built in safeguard against this becoming a permanent wart."



Why would the expectations for Experimental be higher than for
Informational?  LMTP is Informational, and it certainly needs to succeed.

As a rule -- or certainly a solid pattern -- Experimental means that the
document wants to be standards track or BCP but needs some vetting
before being permitted that honor.  Informational docs don't have an
expectation of making it to standards track.

Would you withdraw your objections if we made this informational?

It would eliminate my concerns about this being Experimental, of course.  With an equal 'of course', it would not affect the technical concerns.



Help me understand.


I'll try with the other note I'm considering. However my intent for that note is as a summary, not as offering some new material. 


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------82BBC78642D3087E7C646428-- From nobody Wed Feb 5 06:59:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5203C1200BA for ; Wed, 5 Feb 2020 06:59: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1AX7iW0nA8Pg for ; Wed, 5 Feb 2020 06:59:06 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 79989120059 for ; Wed, 5 Feb 2020 06:59:06 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id h9so2139538otj.11 for ; Wed, 05 Feb 2020 06:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6rxni3cjK3DkxoqBU2QhpBOFRqwY+HlkFfFrA3n/S6E=; b=RxjUGlDWR9PU2ZRrexWyFmaHk10WJPq0I3V4tMe8QsCHOkhXCXkfWUQ8zzc9fgRuqH VmehBZnCcWEILXpX9j+RBgF73ULZQaul9GGbJHRONoRKtSWYAeZ5CdXuFZogHdNGlZBh 102vroLJGLWUNv/73VOBi1aYDPMLIMBSyxwAndZ9kpWAFgjYL9MSYzoM40yms2VSdt9n ETner+vp2yIlWK/bvpzYXyIe+u9nKLg2nn2Q8pEuBUnmwuzFdaV8zJkdFcvDQesVuzKs CMIHc1eaVqDnJpp++CzfZofq1hycU50+NoF22v4d5p20FfYUzLHleiesnWpWJX/UhkLF nFYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6rxni3cjK3DkxoqBU2QhpBOFRqwY+HlkFfFrA3n/S6E=; b=Gc1gpenvQltYIqZZMZCG3M+vCJTGcd56l5UnWySGqJSJQZv2cVLdDpukEycCNJHlDi XSc5zmyzFjGW4h59uCjGNu7iDUvOHWqTPx1GegSpT4tIgX/3iDSkTjF3wGvWJFqIdw2s X/uVCrPmdER2npNqptu/Zf6KRxEJ0AQS1sOzQvEawSUdC9HsyL76dNVkHnuzEWUjfD+X PKwl9xUw0zvQ4qVDIngHkpmcxQx9k0I4Qdl265aog1qOw7J57GynRxNr+Gfybta3dLeq WivRnsR4QppNBpND0OQNaWrY9xvgegWM3PW4LjK7ruWl/IFOk7gFCYiP1C3BMxsiz0Q4 jfPA== X-Gm-Message-State: APjAAAWDTydFHou8TzXqsr6O9rxzUhRjPMefQZ7rTjAnmdfOM0jSPgjG EHxGkxGgYVvr/+giKvacu4U76HM0nXo= X-Google-Smtp-Source: APXvYqzp1dLbO7D/4/vj3rDd0oK5Q6GvpZhAGuzQ9M0x5+64sOCmKPTOtUZf0g4le4HkVXSTwAMVpw== X-Received: by 2002:a9d:588c:: with SMTP id x12mr25541192otg.2.1580914745002; Wed, 05 Feb 2020 06:59:05 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:e84c:3508:22dd:d63c? ([2600:1700:a3a0:4c80:e84c:3508:22dd:d63c]) by smtp.gmail.com with ESMTPSA id b145sm4813054oii.31.2020.02.05.06.59.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Feb 2020 06:59:03 -0800 (PST) From: Dave Crocker To: Scott Kitterman , dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74241ca2-7c32-1bef-759d-47bf48eb2a3d@gmail.com> <4570465.bmySQvRiU0@l5580> <52d064ec-99a3-4ab0-36c3-6271236919ba@gmail.com> Message-ID: <55256a8d-fa20-d2dc-7162-43aabc0405cc@gmail.com> Date: Wed, 5 Feb 2020 06:59:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <52d064ec-99a3-4ab0-36c3-6271236919ba@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 14:59:09 -0000 On 2/5/2020 6:40 AM, Dave Crocker wrote: >> >> Help me understand. > > > I'll try with the > no idea why my text got truncated. what I typed was: I'll try with the other response I'm considering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Feb 5 15:11:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA812083C for ; Wed, 5 Feb 2020 15:11:56 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail.mil Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjAStfjRlbVt for ; Wed, 5 Feb 2020 15:11:54 -0800 (PST) Received: from USAT19PA20.eemsg.mail.mil (USAT19PA20.eemsg.mail.mil [214.24.22.194]) (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 7F3F61200A4 for ; Wed, 5 Feb 2020 15:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1580944314; x=1612480314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ggXo79J9pFCbfnrw5LbT7GVOuXscL4l79oSr9Sq+UnA=; b=cRu/cp2CuTd2DgHGfo9HOY6N7NjolLTWWo5uxwGjXdtVz5zrXctarUL4 xvAAzOM0tqPkWN9/+jLvRddedmHH8kQgaFeiojxABW1a1dByglolLMUPB pWwhTPq103f7nwONgKthgcxrL8437+5je65CDO5e7nTCSN93rKtvFTa+C Jz6gpwS52qGfIMxkypFBMpAc3aIQM/nCNP3gMKmRhluY0usK9YtP5jq+O enOigoYV7NQA7jSF3MOxJYL6VGLBxaRj2B5J2ShJfLWd8yg6YwAuInLwg 8nP/C/QD8Yg2whGqYpJOXRNW81qwG3FcLtdkiQrR74ORcY0liUJjRVSoP A==; X-EEMSG-check-017: 76825829|USAT19PA20_ESA_OUT01.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.70,407,1574121600"; d="scan'208";a="76825829" Received: from edge-mech02.mail.mil ([214.21.130.231]) by USAT19PA20.eemsg.mail.mil with ESMTP; 05 Feb 2020 23:11:53 +0000 Received: from UMECHPAOT.easf.csd.disa.mil (214.21.130.163) by edge-mech02.mail.mil (214.21.130.231) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 5 Feb 2020 23:11:36 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.47]) by umechpaot.easf.csd.disa.mil ([214.21.130.163]) with mapi id 14.03.0468.000; Wed, 5 Feb 2020 23:11:36 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: 'Craig Schwartz' , "'Murray S. Kucherawy'" CC: 'IETF DMARC WG' Thread-Topic: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Thread-Index: AQHV3BPv2W0yzjHaD0K8k+plARSzYagNOOWg Date: Wed, 5 Feb 2020 23:11:35 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC0311DFF7DD9@UMECHPA7D.easf.csd.disa.mil> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Comment on 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, 05 Feb 2020 23:11:56 -0000 T24gVHVlc2RheSwgRmVicnVhcnkgMDQsIDIwMjAgMzo0NCBQTSBTY290dCBLaXR0ZXJtYW4gd3Jv dGU6DQo+IEFzIGRlc2lnbmVkLCB0aGUgZXhwZXJpbWVudCBpcyBzZWxmLWNvbnRhaW5lZDogRm9y IHNlbmRlcnMsIGl0IG9ubHkgYWZmZWN0cw0KPiBQU0RzIHRoYXQgaGF2ZSBiZWVuIGxpc3RlZCBh cyBwYXJ0aWNpcGFudHMuIEZvciByZWNlaXZlcnMsIGl0IG9ubHkgYWZmZWN0cw0KPiByZWNlaXZl cnMgdGhhdCBjaG9vc2UgdG8gZGVwbG95IGNvZGUgdG8gZG8gdGhlIGFkZGl0aW9uYWwgY2hlY2sg cmVsYXRlZCB0byANCj4gUFNEIERNQVJDLiBBcyBmYXIgYXMgSSBjYW4gZGV0ZXJtaW5lLCB0aGVy ZSBpcyB6ZXJvIGltcGFjdCBvbiBhbnlvbmUgZWxzZS4NCg0KT24gV2VkbmVzZGF5LCBGZWJydWFy eSAwNSwgMjAyMCA1OjU5IEFNIENyYWlnIFNjaHdhcnR6IHdyb3RlOg0KPiBTZWNvbmQsIEkgaGF2 ZSBjb25zdWx0ZWQgd2l0aCBteSB0ZWNobmljYWwgYWR2aXNvcnMgYW5kIG91ciBjb25jbHVzaW9u IGlzDQo+IHRoYXQgdGhlIHJpc2tzIHRvIGRlcGxveWVkIGluZnJhc3RydWN0dXJlIGlmIHRoaXMg ZXhwZXJpbWVudCBiZWNvbWVzIA0KPiBwZXJtYW5lbnQgYXJlIG5lZ2xpZ2libGUuDQoNCkFzIGJv dGggQ3JhaWcgYW5kIFNjb3R0IHBvaW50ZWQgb3V0LCB0aGlzIGV4cGVyaW1lbnQgd2lsbCBvbmx5 IGltcGFjdCBzZW5kZXJzIA0KYW5kIHJlY2VpdmVycyB3aG8gb3B0LWluIHRvIHBhcnRpY2lwYXRp bmcgYW5kIGhhcyBtaW5pbWFsIHJpc2tzIHRvIGRlcGxveWVkIA0KaW5mcmFzdHJ1Y3R1cmUsIHNv IHRoZXJlIHNob3VsZG7igJl0IGJlIGFuIGlzc3VlIHRoZXJlLiBGb3Igc2NhbGFiaWxpdHksIGl0 IG1heSANCm9yIG1heSBub3Qgc2NhbGUgYXMgaXMsIGJ1dCB0aGUgZXhwZXJpbWVudCBoYXMgbGlt aXRlZCByaXNrIGFuZCBzaG91bGQgcHJvdmlkZSANCmRhdGEgb24gc2NhbGFiaWxpdHkgb3Igb3Ro ZXIgaXNzdWVzLCBhbmQgc28gd291bGQgYmUgYSBnb29kIGV4cGVyaW1lbnQgdG8gDQpwcm92aWRl IGlucHV0IGludG8gbWFraW5nIERNQVJDIGJldHRlci4gDQoNCk9uIFdlZG5lc2RheSwgRmVicnVh cnkgMDUsIDIwMjAgNTo1OSBBTSBDcmFpZyBTY2h3YXJ0eiB3cm90ZToNCj4gRmluYWxseSwgaWYg dGhlIERNQVJDIHdvcmtpbmcgZ3JvdXAgaXMgc3VjY2Vzc2Z1bCBpbiB1cGRhdGluZyBETUFSQyBu b3QgdG8gDQo+IHVzZSB0aGUgUFNMLCB0aGVuIFBTRCBETUFSQyB3b3VsZCBuYXR1cmFsbHkgZXZv bHZlIHRvIHVzZSB0aGF0IHNvbHV0aW9uIChQU0QNCj4gaXMgY3VycmVudGx5IGRlZmluZWQgcmVs YXRpdmUgdG8gb3JnIGRvbWFpbiwgc28gaWYgdGhlIG1ldGhvZCBmb3IgZmluZGluZyBvcmcNCj4g ZG9tYWluIGNoYW5nZXMsIFBTRCBETUFSQyB3aWxsIHVzZSBpdCB3aXRob3V0IGFueSBjaGFuZ2Ug bmVlZGVkKS4gIEFzIGEgDQo+IHJlc3VsdCwgdG8gdGhlIGV4dGVudCB0aGUgdXNlIG9mIGxpc3Rz IGxpa2UgdGhlIFBTTCBpcyBhIHByb2JsZW0sIFBTRCBETUFSQyANCj4gaXMgYWxyZWFkeSByZWFk eSB0byB0YWtlIGFkdmFudGFnZSBvZiB3aGF0ZXZlciBzb2x1dGlvbiB0aGUgSUVURiBkZXZlbG9w cy4NCg0KRm9yIHRoZSBxdWVzdGlvbiByZWxhdGVkIHRvIHRoZSBQU0wgYW5kIGRldGVybWluaW5n IHRoZSBPcmdhbml6YXRpb25hbCBEb21haW4sIA0KSSB0aGluayBTY290dCwgS3VydCwgYW5kIENy YWlnIGVzdGFibGlzaGVkIHRoaXMgaXMgbm90IGFuIGlzc3VlIGZvciB0aGlzIA0KZXhwZXJpbWVu dCBzaW5jZSB0aGF0IGlzc3VlIGxpZXMgd2l0aCBETUFSQyBpdHNlbGYgYW5kIHNvIGl0IGRvZXMg bm90IG5lZWQgdG8gDQpiZSBhZGRyZXNzZWQgaW4gUFNEIERNQVJDIG9yIGZvciB0aGlzIGV4cGVy aW1lbnQgdG8gcHJvY2VlZC4gDQoNCk9uIFR1ZXNkYXksIEZlYnJ1YXJ5IDQsIDIwMjAgMzo0OSBQ TSBBbmRyZXcgS2VubmVkeSB3cm90ZToNCj4gT25lIGhhcyB0byB3b25kZXIgaWYgZGVsYXlpbmcg b3IgaW1wZWRpbmcgYWR2YW5jZW1lbnQgb2YgdGhpcyBJLUQsIGJlY2F1c2UNCj4gb2YgYW4gZXh0 ZXJuYWwgZGVwZW5kZW5jeSB0aGF0IGFwcGVhcnMgdW5saWtlbHkgdG8gYmUgcmVzb2x2ZWQgaW4g YSB0aW1lbHkNCj4gZmFzaGlvbiwgaXMgbWFraW5nIHRoZSBwZXJmZWN0IHRoZSBlbmVteSBvZiB0 aGUgZ29vZC4gIA0KDQpPbiBNb25kYXksIEZlYnJ1YXJ5IDMsIDIwMjAgMjo1MiBQTSBJYW4gTGV2 eSB3cm90ZToNCj4gRXhwZXJpbWVudHMgd2lsbCBnaXZlIHVzIGRhdGEgdGhhdCBoZWxwcyB1cyBt YWtlIGJldHRlciBzb2x1dGlvbnMgaW4gdGhlIA0KPiBmdXR1cmUuIElmIHRob3NlIHNvbHV0aW9u cyBsb29rIGxpa2UgdGhlIGN1cnJlbnQgZHJhZnQgdGhlbiBncmVhdC4gSWYgdGhleQ0KPiBkb27i gJl0IHRoZW4gd2XigJlsbCBiZSBjaGFuZ2luZyB0aGVtIGJhc2VkIG9uIGRhdGEgYW5kIGV4cGVy aWVuY2UuIA0KDQpMYXN0bHksIEkgYWdyZWUgd2l0aCBJYW4sIEFuZHJldywgYW5kIG90aGVycyB0 aGF0IG1ha2luZyBldmVyeXRoaW5nIHBlcmZlY3QgDQpub3cgaXMgdGhlIGVuZW15IG9mIHRoZSBn b29kIGFuZCB3ZSBzaG91bGQgbW92ZSBhaGVhZCB3aXRoIHRoZSBleHBlcmltZW50IHRvIA0KZ2V0 IGJldHRlciBkYXRhIHRvIG1ha2UgYmV0dGVyIHNvbHV0aW9ucy4gSSB0aGluayB0aGF0IFBTRCBE TUFSQyB3aWxsIGJlIA0KdmFsdWFibGUgYW5kIHNob3VsZCBwcm9jZWVkLg0KDQpUaGFua3MsDQot RXJpYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX18NCkVyaWMgQ2h1ZG93DQpEb0QgQ3liZXJz ZWN1cml0eSBNaXRpZ2F0aW9ucw0KDQo= From nobody Thu Feb 6 10:03:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045ED12008B for ; Thu, 6 Feb 2020 10:03:35 -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 (1024-bit key) header.d=isdg.net header.b=XoTiTuYj; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=uGGreSr8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGXJ09KeOccY for ; Thu, 6 Feb 2020 10:03:32 -0800 (PST) Received: from mail.winserver.com (listserv.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CC1120077 for ; Thu, 6 Feb 2020 10:03:32 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2729; t=1581012211; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7cNvw6Td9pTuF45cUPbb1lKubrA=; b=XoTiTuYjwMXOiDVO3CNtQ1iV7kLDZ9xPrupQP3N3O2zfk8/A3sWm+YlZpSLAf+ NPCbPR6Wjq+bM47j9ry50ZqOuM+CBLaAx3zRVZHhAth9ua0w0wcldm9XB1AobMnL HI8TBwIbeuTob2LLCTqXhLZt5hHXvRYgXaQIEa1OHOGyI= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Thu, 06 Feb 2020 13:03:30 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=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 v8.0.454.9) with ESMTP id 329576691.1402.3780; Thu, 06 Feb 2020 13:03:30 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2729; t=1580964712; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tlkd3TN Cwq8nHIj1XOJ5JJccf7UtWpsNpFl0GkKntC4=; b=uGGreSr8Ab93tP0H38bN0AH rLTerj5yUsZ8NylBQAdUGqtgl8OxEqi2WoHgDU2JfX3FNRTwfongw/ah5TmLUrcK AxrR+AA6DLOg0+5d6178059z4EOUIGrt3yWBitEG0koj5tFt3L82WB+AUdW8xP+H 02HOiXc6TVqKvh38RYIg= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 05 Feb 2020 23:51:52 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 130352703.4.944; Wed, 05 Feb 2020 23:51:51 -0500 Message-ID: <5E3B9C41.8080403@isdg.net> Date: Wed, 05 Feb 2020 23:55:29 -0500 From: Hector Santos Reply-To: hsantos@isdg.net 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: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Thu, 06 Feb 2020 18:03:35 -0000 From a software engineering standpoint, we have an "Lookup" black box mechanism. It should be left open-ended so the DMARC-bis can move it. The default mechanism is the existing DMARC one. Consider PSD a Lookup extension to DMARCbis. DMARCbis can describe "Lookup Extensions." Remember, we still TPA design issues and we have an extended lookup ATPS deployed. Until we get a valid TPA method more systems accept, we will never be done with DKIM Policy modeling. Can we please move on to completing DMARC as a standard? On 2/3/2020 10:08 PM, Murray S. Kucherawy wrote: > On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz > wrote: > > Hi Murray, > > << expressions of needing this work but not knowing how to engage; > you either give your feedback on the list or privately to the > chairs or Area Directors, or you are along for whatever ride > results. Please indicate, as soon as possible, where your support > lies given the above.>>> > > In my capacity as managing director of fTLD Registry Services > (fTLD), registry operator of the .BANK and .INSURANCE TLDs, I > believe PSD would provide invaluable threat intelligence to domain > registrants and to TLD administrators like ourselves for > NXDOMAINs. PSD has tremendous value to specialized TLDs including, > but not limited to, .BRANDS, community-based domains, > high-security domains, governments, etc. and as such I believe PSD > should proceed. I’ve previously posted to this list expressing > this view and while fTLD cannot participate in experimentation due > to a prohibition by ICANN, we remain committed to supporting and > seeing this work continue. > > > Craig, > > Thanks for this, and for one other person that sent to the chairs > privately (it was a list non-member caught in moderation, nothing secret). > > To be clear, however: I think the working group mailing list archive > has enough of a record that participants think the experiment will be > useful or even critical to the evolution of DMARC, though people are > of course welcome to affirm that support for the record. The question > being put, however, goes to the form of the experiment and the current > form of DMARC as a protocol with respect to determining Organizational > Domains, and whether there are indeed risks to the deployed > infrastructure that the experiment could become permanent. That's the > meaty stuff that would really help to move this along. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- HLS From nobody Thu Feb 6 10:44:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC231201EA for ; Thu, 6 Feb 2020 10:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 qLy6cW_I6Ye7 for ; Thu, 6 Feb 2020 10:44:36 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 002971200B2 for ; Thu, 6 Feb 2020 10:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1581014673; bh=dsl7et0MR7NaKIfu9E/WzoT5H+vpxiJs1tGYH3xZXO0=; l=3107; h=To:References:From:Date:In-Reply-To; b=CXTRM9rY1nnXGBXxsigIDDPZtFJi4zW6PIR+Ic2wktwtkiJsb+fyuFDeXIIHRz3aZ K4LGZpLs9xCm+Wkq4vU9wslgYvjdqGBjWL67HVdXyhBgWiRhyzPKNp5hJhSS3URdAg 26uigBwB/J7lArqcpFkQNdRTAzJnJpsbrYPxcMKvNHp/sm3jUq0U5hFLNHyoJ 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC092.000000005E3C5E90.000034D2; Thu, 06 Feb 2020 19:44:32 +0100 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> From: Alessandro Vesely Message-ID: Date: Thu, 6 Feb 2020 19:44:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.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] Comment on DMARCbis, was 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: Thu, 06 Feb 2020 18:44:38 -0000 On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote: > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman wrote: > >> I agree on DMARCbis. I don't think advancing this draft has a significant >> effect on that. Worst case, if DMARCbis is done before we can reach any >> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in >> it. +1, albeit I don't think DMARCbis arrives so quickly > I think we've always been assuming that PSD DMARC would be input to > DMARCbis, so we were planning to start the latter but not close it until > the former was completed. This is the first time I've seen a different > suggestion. > > I'd love to hear more opinions about ordering of the work here. This seems > like an ideal time to review and update our milestones. There are quite some issues about DMARC. Let me mention aggregate report format first, as this brings out a third thing which can be done in parallel, namely to publish http://dmarc.org/dmarc-xml/0.2. Various tweaks have been proposed, I think they're well summarized in http://bit.ly/dmarc-rpt-schema For a second issue, consider whether report generators should track policy changes during the day and, in case, send multiple reports with different PolicyPublished. Otherwise, PolicyPublished would be valid for only a part of the reported rows, presumably the last. Is that acceptable? Another case for sending multiple reports at once is on hitting size limits. Is better to increase sending frequency instead? How to negotiate sending frequency between report consumer's ri= and producer's conditions deserves some discussion. I'm sure there's a bunch of other issues, and we should start to collect them. >> I don't see anything about PSD DMARC being inherently on the critical >> path for DMARCbis. I suspect the current major obstacle to DMARCbis is >> that the question of how to take the PSL out of the equation is unsolved, >> despite one IETF WG that was supposed to be dedicated to the question.>> >> I don't think not publishing PSD DMARC helps move DMARCbis forward, so I >> think it's a false choice.>> > > I think what Dave proposed about PSL separation from DMARC is entirely > appropriate and pragmatic, and in fact probably easy enough: DMARC is > changed so that it says the organizational domain is determined using some > process [currently] external to DMARC, and then a second document explains > how that process is accomplished using the PSL (and/or PSD, depending on > when the experiment result comes in). That's a fairly simple edit overall, > and is actually probably minor and non-controversial compared to some of > the other surgery that I believe is in the queue. +1, let DMARC core define _organizational domain_ by characteristics. A second document present a process, possibly demonstrating how the required characteristics are met. Scott's I-D already outlines the characteristics of Branded and Multi-organization PSDs, that the experimental processes are suited for. Best Ale -- From nobody Fri Feb 7 09:20:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581941200F9 for ; Mon, 3 Feb 2020 16:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87lXJOMIc840 for ; Mon, 3 Feb 2020 16:47:49 -0800 (PST) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 AF817120025 for ; Mon, 3 Feb 2020 16:47:23 -0800 (PST) Received: (qmail 4267 invoked from network); 4 Feb 2020 00:47:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Feb 2020 00:47:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v9.28.0) with SMTP; Mon, 03 Feb 2020 19:47:23 -0500 (EST) Received: (qmail 5004 invoked from network); 4 Feb 2020 00:47:22 -0000 Received: from unknown (HELO zixc2.strongport.com) (204.11.174.141) by 0 (rfx-qmail) with (AES256-GCM-SHA384 encrypted) SMTP; 4 Feb 2020 00:47:22 -0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.strongport.com (Proprietary) with SMTP id A1B1926197E for ; Mon, 3 Feb 2020 16:47:20 -0800 (PST) Received: from antispam1.ciosolutions.com (antispam1.ciosolutions.com [52.52.106.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zixc2.strongport.com (Proprietary) with ESMTPS id B175F2600DF for ; Mon, 3 Feb 2020 16:47:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by antispam1.ciosolutions.com (Postfix) with ESMTP id 033F73A03D4 for ; Mon, 3 Feb 2020 16:47:21 -0800 (PST) Authentication-Results: antispam1.ciosolutions.com; none Received: from mail.americanrivierabank.com (unknown [136.179.3.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by antispam1.ciosolutions.com (Postfix) with ESMTPS id 857D93A03DB for ; Mon, 3 Feb 2020 16:47:18 -0800 (PST) Received: from ARB-LV-Exch1.americanrivierabank.bank (10.13.237.16) by ARB-LV-EXCH1.americanrivierabank.bank (10.13.237.16) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 Feb 2020 16:47:17 -0800 Received: from ARB-LV-Exch1.americanrivierabank.bank ([fe80::502c:d8b4:2bc9:37d3]) by ARB-LV-EXCH1.americanrivierabank.bank ([fe80::502c:d8b4:2bc9:37d3%15]) with mapi id 15.00.1497.000; Mon, 3 Feb 2020 16:47:17 -0800 From: Paul Abramson To: "'dmarc@ietf.org'" Thread-Topic: Comment on draft-ietf-dmarc-psd Thread-Index: AdXa9KXs62dZu6UKSgOuR6Q/4pdE6g== Date: Tue, 4 Feb 2020 00:47:16 +0000 Message-ID: <6e648736a087468a82b04a99feff382a@ARB-LV-EXCH1.americanrivierabank.bank> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.13.237.77] Content-Type: multipart/related; boundary="_005_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_"; type="multipart/alternative" MIME-Version: 1.0 X-VPM-MSG-ID: 7bccc1f2-8220-4060-8a5a-f33e90179766 X-VPM-HOST: zixc2s4.strongport.com X-VPM-GROUP-ID: 9d88b2ed-b132-4ca7-b7e4-839bf430ea71 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: X-Mailman-Approved-At: Fri, 07 Feb 2020 09:20:15 -0800 Subject: [dmarc-ietf] Comment on 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: Tue, 04 Feb 2020 00:47:51 -0000 --_005_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_ Content-Type: multipart/alternative; boundary="_000_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_" --_000_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List members, I have been working with fTLD on the advisory council for a few years now, = an adopter of both a .BANK domain and DMARC reject policy since 2015. I su= pport the work related to DMARC PSD. It helps close an important security = gap allowing the abuse of unregistered domains in the trusted TLD space. Thanks for your consideration. Paul Abramson EVP, Chief Technology Officer AmericanRivieraBank.com | PH 805.730.4997 | FX 805.965.8523 1033 Anacapa St | Santa Barbara Ca 93101 [cid:image002.jpg@01D3EB59.D24329B0] = [cid:image004.png@01D50B1A.D5CE25D0] CONFIDENTIALITY?NOTICE:?This?communication,?including?attachments,?is?for?t= he?exclusive?use?of?the?person?or?entity?to?which?it?is?addressed?and?may?c= ontain?confidential,?proprietary?and/or?privileged?information.?Any?review,= ?retransmission,?dissemination?or?other?use?of,?or?taking?of?any?action?in?= reliance?upon,?this?information?by?persons?or?entities?other?than?the?inten= ded?recipient?is?prohibited.?If?you?received?this?by?mistake,?please?contac= t?the?sender?immediately.?American?Riviera?Bank?keeps?a?copy?of?all?E-mails= ?sent?and?received?for?a?minimum?of?18?months.?All?retained?E-mails?may?be?= subject?to?audits?and?litigation?research. --_000_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

List members,

 

I have been working with fTLD on the advisory counci= l for a few years now, an adopter of both a .BANK domain and DMARC reject p= olicy since 2015.  I support the work related to DMARC PSD.  It h= elps close an important security gap allowing the abuse of unregistered domains in the trusted TLD space.

 

Thanks for your consideration.

 

 

Paul Abramson

EVP, Ch= ief Technology Officer

&n= bsp;

AmericanRivieraB= ank.com | PH= 805.730.4997 | FX 805.965.8523

1033 An= acapa St | Santa Barbara Ca 93101

&n= bsp;

3D"cid:image002.jpg@01D3EB59.D24329B0"  3D"cid:image004.png@01D50B1A.D5CE25=

 

 

 



CONFIDENTIALITY NOTICE: This communication, includi= ng attachments, is for the exclusive us= e of the person or entity to whic= h it is addressed and may contain = ;confidential, proprietary and/or privileged inform= ation. Any review, retransmission, dissemination= 196;or other use of, or taking of = ;any action in reliance upon, this info= rmation by persons or entities other th= an the intended recipient is prohibited.̳= 6;If you received this by mistake, plea= se contact the sender immediately. American&#= 8196;Riviera Bank keeps a copy of all&#= 8196;E-mails sent and received for a mi= nimum of 18 months. All retained E-mail= s may be subject to audits and li= tigation research.

--_000_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_-- --_005_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2915; creation-date="Tue, 04 Feb 2020 00:47:16 GMT"; modification-date="Tue, 04 Feb 2020 00:47:16 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAuARQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2Ri20 7RluwJrGutXkQtDNbtDKOducrIO4zTNVljSYD+05o23fMF5CD6Cs2a4uFgaR7jzlceXG7ZDY74H6 GgTYtvqckFpNF5shMjKFJOSq85xXS2s2YFLqsIwNiFuQPeuZ8yNJfLtYzIkkADqvPz46/gajREUR 3M2Z1diCd2MH0ORQJM7MHNFVdOu4rq2BjG3Z8pXdnFWqCgoqK3uoLpXaCVZBG5jYqejDqKloAKKM 0ZoAKKM0ZoAKKM0UAFFGaM0AFFFGaACiqt7qVppqI95N5SOwVWKkgk9Bx3ottTs7ud4IZ1aVBloy CrAeuDzigC1RRRmgAoozRQAUUZozQAUUUUAFFU7jV7G1uhazTFZypcIEYkqOpGB0qe1uoL23S4tp kmicZV0OQaAJaKM0ZoAKKKM0AFFGaKAObvm/05oLO3WbyVwd4yqHufTPuaqpOkcsvmMrvFCVjG0b dxPOPpmtmXTAxitFZhE5Mlw3eQ+lRx6NHL9pkkQpltsIXjao6fnSJsY6GO3s7e6j4nExyc9QOaIG aZJhGqt+88wQMPvduD681LpNtHe6jsmyUjUvj1PFaraNH50kSqRE/wA8TjrE4/oaYEukvE6khHSQ r91+SB7HuM/lUusX39naVPcqN0irtjUDJZzwox9SKsW6uIV85VEmPm2+vrVO+064vL+zl8+Nba2k 80xFCS7YIHOeMZz0oKMLQGTR/EDaavmiC/hEqGSNlzOoxJ19RzWp4g1O40yWylhXfErNJcqOvlAY Yj6bgfwqbW9IfVY7ZoJxb3NrOs0UxTdgjqMZHBHFSvYTTahDczvE8aQPE8YQ/MWIyevTjpQBT13V 5bRLUWbKwaWN5n6hYS4H65x+dL4iuJLZ9P2XE0KS3Qjk8kZLKVJ6YJ6gdKj/AOEYVNCudNjumLTE bJZF3GNVbKLjPRcYq3qOnXd99hdLiGOS1mEzZjJDkAjHXjrQBBfTvD4TvLm1u7hnjhkeOWQYcEZ6 gjsRjpTNLu5ptTSOC9N3bfZQ824hvLkONuCPUZ49quXthdX+jXVlNPEJbhGTesZ2qDx0zz+dRyaP L5ttd21wsF5CgjdgmUmT+6y5/I5yKAEjmmPi2a2M7mAWSSCM42hi7An8gKZpkk2tRS3r3MsUBmeO GKI7cBSVyx6kkgmrEenTrrr6k0yFXtlgMYQ5GCTnOfU1FFpN1p9zPJptzGsFw5ka3nQlVc9SpByM +nNAFmNW0yznkurt544y0geTG5UxnB9cc1R8O6pPem6tryRGuIXEg2Hjy3GVH4cr+FT3Gn393aiC 4uomDTB5QIztKAg7Bz7cmnT6U39rW2o2siQtGjRTIUyJUOCBxjBBGc0AUDrN1p2q3T3uH0sz+Usw HNs20fe/2Tnr2rQspJH1m/Qzu8SrE0akgquQc4/Kn2lhJE979oeOaO6lL7NmMAqBtOTz0/Wo9K0Z dJkuBFPI8MpXy4358pRn5QfTnj0oAo+NG2aTasFLYv4DtXqfnHT3pqSw6p4wgkCPbTafbsWSVdry h+Bgd1GOvqav69pU2r2kMENwkBjnSYsyFs7TkDqKTVdF/tIQXCTm1v7Y5iuY1zt9QQeqn0oAbq80 8eraRHFM8cc9wyyKpGHARmGfxApks9xY+J4Elnd7O+jZI1YjEcq84/Fc/lUtxpt5dXGnXEtxCJLO UyNtjOHypX146mpdY0warYG3ErQyK6yRTKOY2B4I/UfjQBHYtNeS3t0biQW7MY4FBGAF4LD6tn8q qabc3M/glbyS4ka5a1aQy5Gd2Ca2I7cQWi29uAiom1M8gccVQs9IltfDg0kzo7CExCXYQMEEZxn3 9aAIvD9wLmCOQ3l1NK9ujSJMhCgkdVyB79KzI9RvP9KWHUWe8j1JoIrdyCHjDDIIxn7uTn2re020 vLOCG3nnikjhhEa+XGVLEYAJyT2HT3qonh4Pa3lvczBvtFy1zHLEpV4XJyCDk8igC7q12bTTnaN1 SWQiKJmOAHbgH8Ov4VHoF+2o6THLIytPGTFPt6b1OCfx6/jTE069lubSS+uYZ0tg2VWErvcjAY8k cDP50+10ySz1a6uoZUW3ugrPBs6OBjcDnuMZGO1AGbqTTL4304wRrI/2Kb5WfaOq98GpPCssUa3t g8bQ30Vw0tzCegLnIKnuvpVi80m8m1231S3uoY/IiaIRvEW3BsZ5BHoKdHpE8T3t4tyn9oXihPNM fyRgD5QFz2yT1oAq2etvL4je3eWNrW4DJbAEZDxnDZ+uSR/u0/VtQ1Cy1aN7aP7RbRW/mT26j52G 7G5PcenepLnQRJpdrb28iQXNoyPFP5efmXrkdwRkHnvVpbO4OrrfNNHs+z+UyBDnOc5BzQBWW+S9 1LTZrO7Z7W4ikYhD8r4C4z7jJqmdSuF8Q32lx3J82Up5Hm/diG3LEep54H9KvRaFDb60NRtpGiRg 3mW4+4znHzgdjxz61HL4fW7ub97uQPHdMjx7FKvCyjAYNnrQBqW8JggWNppJio5eQ5Zvyoqvawaj BAsU11FcMvHmtGVLD3AOM/SigC7igjIxRRQBRstIgsZ2midyzDB3Gr2KKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACqM1/LE9z+6QpbhWPzcsD6cdavVhXNxb/AG+9jlhLkqoU 46Ee/agTNsOCF7bhwDRvUHG5c+maw7yfyJIo5hukRYmaQclueevT+tF1LBuvpPLO4SR4bHIPFAXN aOdmu54n2hYwpB+vrU+fy9aw7u5Rb+eZgXjiMZeMgYbjg/hmr+ovmxWUfcVldl/vLnkUAXN643bh j1zTgQwyCCPasKd4mV5Nn7l7mMKmOhHXj3q9psiGW8jjXaqzcDGAOBQO5PJOwvI4V2hSpZyew6D9 an3YOMjNY7ILzUriE/fLAFj/AAoMcD3OaiEyPb3l025po9y89Bk44/CgVzaFxEVRhIuHOFOepp5Y DPI4689KyBsW6toRDH+6gLgds/16frUUKR3OnbwXMtw6ozue5OSaAubuc0VUhkhh8yGKMqI3weep wDn9aKQz/9k= --_005_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=7957; creation-date="Tue, 04 Feb 2020 00:47:16 GMT"; modification-date="Tue, 04 Feb 2020 00:47:16 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAD4AAAA+CAYAAABzwahEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAB6VSURBVGhD zXsJfFTlufdzlpkzSyaZyWSZLIR9CTthUYGwREWwirZai0tbhfZqr97bSvtdr62FC7b1s9d6q14X KK2KWrTaVoQqKBKSYaeEJQmBsAjZJttkZjKZObOcOef+35OFJCRQsP3u9ybzmznnvMvzf7b3eZ/3 PeKaNWvoH1n2ee2SEqE84qNDieezSKU0ldQknjSJjasSF+WJ7yCeWklVPaRKF0QT1dzg9Ef/kXSJ /4jO3V77RFISi3iOK1Ap4eRECmua0ESq1gCozUDbQLwm62OrnBmgU3BvKHHCDZyYyFQSZNnTnOxV Na2MROHTQqe/4u9N598NuLtesvNG833E0SIeKBUSDsW1+DqbaKiY6fT7robwjypcyc7M0AyO5+dz qvbMnlZ7gjR+uxoLbSrMifqvpq/B6n5p4G6v5hTUlO8LklBInHYsodAzhZmBA2zAVQ/kW9e+XRXq HjwtLW0Ez/Ojm5ubt7tcrmTcT25sbKzrTVxubtrEJ4ZHmqu+CO7EffYhd5P9Ol5I3CdIlj/vbZHc CT7wQqGT834ZBnwp4G6PdSUvCndrxO9UOW0ZVLKJETPcbs+RTabvrd/h2wSADJgdnwX4pDCw2dnZ BlVVczmOuw7Pt+HeKHw+xWeWqvLJHp/yHO67wJRG1l9hpp8x8gBMKJPX+H/h1ZQtbk/ig8Ks0PPX Cv6agLubrNNIo+eJ52pUPvqNQme0tjcBAO3CdR2kOxwAH8V3raZpmfiwenIikVgE0EdwfQrXc/E7 gt/fxodD/adNJtNI3L8Z2D34rgD+kzoDOhn7lNsrDSHe8DN3o7UYprWyMDN05GoZcNXA3R7zDzRO e4hLaKsKc+TNgwyYi/sWgJiA7y/wkQDuMD7eWCwWEEWxNBKJnAdApu5J8Xicx73heG7C/ajFYvkq 2opgxAx8EqijA+8unYyOfttdb75DE7g3QNPrhVnyr68G/FUBdzdafqcRZXOGUFGh67I21g4Ab4OQ OMBZw+Fwk9/vjw9AWEuvez1SQ5s/KIqigRmFjGGDAWKMh4/ZrcWs74C2yYWu8PK/FfzfBHyf3S7G T0TfJl49Ny8rgs65y/YP1SzuVeGqPDprh/Znu9qfuxKQTicXXlzaaPpFaYP5XcN46YEb/H7lSu2u CHz16lXcTd/71VaVNKuW0F6EWt2kIuIgdM33ah2P4AauBVGkhKJqAhxAApUEdrOrsPpxRSH8k2QS 0cnF0v8+60/hVU0yGrnueiqDgz7YNfudQEcC+lFjGJDXtoocPaucjG9d/eqqJWvWrIVyDl6uCPzG R/7zLYPJdgsX6VA50bAnrqhkEASKYmRREImD8MORODmdDsQnGn7HSDB2Dmg2WBCscSTjOfuOxRWC GlOSRaJgKKLXgSpTJBoji9lGFpORguEIRWJxSranoH+evIEQ7hsIXVMcc6WRjYl2GiIeR4qNQnKU LMlWgsNk3FBJNPOMZlR54JqBl3ikZySL7X65I0AP3HoDL/AC7Tp8kpq87fT1oqn07vYDIEijohn5 NHJIBrWByGPVNZSd7iBfMESzp4yiksOnMH+lUntI1kHdNncKydE47T5aTec9XtJUjcYOddH8GWPB gDh9sqecRmZl6G0TqkrVF5r0MSWjSN+4aSZt3lWmM/qrRQWUZJbw7BRNGplDk0cPQdvj/NHTtZSc knp/iUetnZ8VfXIw8INKvNgj3WMyJf17LNyhc57DX0iO0PDsNDIbDTRtTB7tOlRFBoNIo/Iy6bUP iklAvXHDsijNnoSINaG3afa109AsJwmQ+A2TRtLW3ceovtlHVpOk9ysYOLrpuvH03qcH9bouZwrN KxhDGz4shabE6Ht3L6RTFzy6Nkwbm0eVZ+vpQMVZcqUm434jNaAvGRqT5kiispPnyYx+Y3KQjKC9 2ENHFmZF/zAQ+AGBI/zME0XjhoQS1yXKOJ/usNHpmibaX36Wvn/vzZBWK906dzKVllVDbWUKdITJ LBmhcliCoD5rx8Dr7XFPFAWdMZ4WP8XjCYohqGXqbwITdYfmDVAMNmtAPQX1W/0d8AcJCkKVGZOW zJlEZ+ua9e+j0Ko3t+6l2won06IbJpL7SLU+DuIFvS9NwwoBtIu8cYO7nvYjzK3pD35A4BrPbTAY JVtc7mBWSEYQ09Dqp7c+3ks3XzeBapvaaCekfVvhFIrCHtmAD90+l9qhyswMFABntltxpk5n1vUT R1KLL4jrenpoaSHVNbfRqfONej/MPKpR5zt3ztPBH666QB6M9fBd83XfwJgoCJzOxC2lx+gWAL1+ 4gjKzUyFFsHHgjmsJGAyFwtHajxGBnOSLa7GN+D+oisCL/GYl0lm680xGSE2iGeOhHX6F/cxnfOn a5ugaud0wG/9Za8O8J1P9tH1UOP2DlmXClNlpn5MPdMdybT32BldazogPX+XZgSgJawt04IdBypp DOw8xWrWneNHJUdo4qhcXYOYhjHTef2j3bojY8xntn2uvpXyXKlUDmYm1ARt31eha0tPQd/xSIiM 5qSbSzzcsvlZ8ru9wfeR+EcVktnupGeZmnQX5k1VqM5Ns8bDkxJtdR/VbXDvsbM0AU6Fqe68aWPI COdz4lwDzRw/nJra2mkUnN27sNsbZ+ZTW3uIJozI0e2cOaOxw1y6k/sMgJnkJo3KoVLcLyk7RTaL iW6fNw0O0k7b9pbTwhnj6GDlF6iTS/vBcOZDahq9ev8ZsHNfMExGg0DXQauOw7EdOXkBjrDTfHRN ABYI71lg27x0YrRzKYzSB7jDwX8H6pHHnEPvIIURbMeUwTjtTEmiISBWVU9TDrw3c0BZIJKpK5My c2RMsrcVTtXV2yQZIDGbDuRcPZbikPxoOEPm5ZlKM01hNt/iD+qgGXPLz9RiPDNMwqcDL4fJMBNh ZnPf4utpIzSNOUHm6ZmWMQFIcLLnG1p1DepdEvEopG7Lczg6voP7L10CHNGZUfNEf5iAbfSPzBgx TOWZ5IZmpelOJ4o5mc3bzL43bdtPd904QwfFQDMJfIhpx26z6IQzybMprKktqNf/qOQoFUET7lxQ oGvQ/Onj6I75BXBYe9AWAQlMS8GUzAqb0xmDmTdfAT/ApJ1sNekxAYsFEqDhEDSCCYDR8LvNbp15 F2NLjhgmjacfAuM6RHUM4EWJK1XR2w0m61BmF/2Lru4ghnXG7KyuyQcJzEVsxtEeSIWpJrMv9oxJ jXlxVv6087AuXeZxWds8aEozzIBNaylgCpuO5heMo1wA87Z36MEQK4yhDDArrM8MZzK5Me8zczl6 qobyoFWsjisthWw1Ek3E/WHZTvJBMN1j9ZG6AkcHbEpV6HbKoj/2AQ5sjxkkM+715RerxDr75GC1 Pu96WgP6NOSTEzoIP77d5RfICjO44GmjmtaQDvyL5iBluTLpd385pKuk9/AZsidZCJMMlRy/QJkA c66uBQ7MQI2BiK6mtmS7Dr49otKuo5iTrUm0u6JWv8e07HRDpe7JW4Ix3TE64fQSvJEOn/aQNxSH QNoIjhwC6avuDBPDFo+GHgWci8Cxvh6FENAWDfkfVpQYhunfkKgm0KYz0YyQUwWwsoqTUEsjrkWq r28iRYsBvIUC3hBxIlKJUFUBgJn6yxBeuy9AtZqiwVNzGtSnsamZbFYTF4KNHmlpZm01YNJlrscB Xe3lWOd6g/XJCpu8oh2dGtXY7CET4mPByNORSi/6MPXM5b0lzlKaqhJj8vsnhhXr9zOdzk1R7+QR 5M9JD67v22Cgq27HyGhk6tg9A7DrHqfZ1XCglWjv5Gnvvvq3ZV0M1L43Td006KxhLLkM+VFye0zZ DCsqPacD1ziagRn7tSuDvvYaSDfdhQXKYqzNX4KaLgP7G+DoTkK6Y7H23utwOL4VCoU+b2ho2Hrt o1ypJbcLWB9htUTmzbnGqIMSKWX9JWa32yWWBkJCAF72ikvcAUc1m82cLMutANgejUY1gP4NQO9A 5Sn4MJ2div5H4TlLU/0T0k370SYTbS67rBwMYjetSIScRfKjrwqoKWWcEHAwzKJyKp6H+CQ8L6ex fYDOVAAOXytonbNgWpfOtkiSNAMSZ+mqyWAAcKoV+C4AI36FZeUOaMCPcS+ONqFrHbNXu05H0KsU AiOSFWGGmXmfYRA/S+pdUrrSReevpECXe97a2qo/ZllTV1ra981iTWUlAjC7SfNVfdFYlZub27Bi xYr6l19+eSnqVrO6yMAEvsyYl2vLsILlwwCcsuFN6wer7G4SpvGibbYai/ooRd2sBuhOoznFqoQC 2zAzJTtaRlRNnFiVKK6XRookGlRemW402pyRSLAE/aJvMdOnKH9cSo0nHn74z+Lk5XPz7hqa2Psf h7S0Mdmm0UVUd5ptYzHQH9VLNgfPf50XJYsak7djVXW6uN58q8WaMiwSCtTOz5G3MDrdYclOQcot zIxWsLRYrDJ+J9JiSbyqbkV26Kui2WqKRUPFC/G8Py7MDfUMM8v/OPGweSDgehpZTdyFym/FeNUu BsUsmOV0Mqpv+ELks6vCD9vSvmDG/0OR56dCe2QAPx9PhAtEB9WqAX4xnjUgmf5NfL9S9EjRA5h+ cU9elp9tmQHGpOL+aTb2vn12Y8oweSX62K1K8QZCfIU0Fxs7WzXSxxRSb3Z7pG8WZkXfogC/CA5g GZp9LVIpT8bcPpfj1XWkOmI8BfxqVJmSJEYgzAFzg80Ms4gpEzM+32c3o5sJsLc5mObewQYey38T 1rYWjhdS+Rg/20TUgu2dw4gWrFjRfRedXcBmQCQoKidTIvzpeZZ4mztgyuU0LkMVlXff8doNeWo0 F2OdKK4XxoGBPqTurN1jRfLiowAyACl/rk9LSDyXNpofgJRX607XQmcxzmrGIDVPHol+jhY3WWf/ 8015+1/beX6mpvCLAg7fekeQTpASN8/M5AZMcqrE+8HcLEhcM6qkDDIBqnWk8oUgrgrJCROZKF2L aKeusze/xvZGSprMLuM56dexvGgR6vwYAcGTpohJglexMEAqNgoQiaSIifTyXCW4AGHXENFgPoOM w+1glBspsh6RYN5oRuSf5a53JTMnBHW2IuAIYNy5YMZugJzJk9oayZOnQ8KjDGZrJfIFi9fvPleP 9cpGb5C/z+HjFylirIonkz7+QIVhReSJ0OoyZWfRiI8W7Di/fI839UfEIzYl9T0E+0l7/K4fhEK+ P0nEVytjfLb5Tm7bzlpzBrqLmcWOaDRsucC6Re6gFCtubAP5bgNQyZegHy11tQZR916BV80Gs2VO cb1SuzAncQDgWt1N0p+J/Cv3tNgj8bC8syOYsiHFGXjsQLtrlqgGsLwPv9wRsSzxe9WVSye2BoqD 5mXI2WW3RPgHYTYxLAW3Bn2qySZBYFcocG5cjOcF7FVfKvQ1VVUq5dCG1aslac0arBY6y09WvzPJ uOb+RlghS+l0Cq1oiLyx8zGunbIeDxd1OaP8/PzDVayvroK6mzp/RouZ6lKOX7+Cs9oPZ/XXlkqT ZelQP6ZXfevsF4dUyVGYLEN19ejw96BJLwuHdCYXkALfv/iFFwWWT7eP3Cf6/TfojB+o8CRKUPUY fBL8I6n2gSoVTNDutTtsT8z9WFYjYe4//lqpfVQwgXts96snlkcixnQ5Gr1DVuhcssmwxWKSJgf8 HfeLonZWkEwfR+S4L8kqpYSC8mNlVVWfdPc/bQJ9kGQ1T0DWxBuJRldCwgenjSc3AvjNZVX8c/pm QA61Tx1PH8MRho9U0t0z+c5t5klj1a+nOpJ+0R4M+8wprgVyoOn9lBTLqC1/WnO+rJy7ZWq+el9y StHzHUG5TVa12VVVXCdHexWYix3aF2TTmRc/hgzIHpWGd3REJuHZZojrg1mz7JZ42DcyLMemwRE9 jf2CBpPAPYU1x0xkaR7HVBJSDFwb9tXcKcmWb0ZjsQ8w5fVP9BWBYQcEjpc0lfvTMrt9+CnOPwvz a3k3DQX5ao5kNi2JY4FSMDyRVvYF1zp1grYwzWn/QygUgflw0Bgf8kzaomhUOYgV0ubZ+SZrRIi9 Hosp7+P+YbOZ9BMXA5QMYK5l01kDQF0/SKVEPK60YqBtGml3og7wcgks+puPVtIqpnrTJnBZBoMQ WXDLv/0G87Ee1w4fHv1pbprwzY5w6JnyKmNln74RsSkR5XNFRKKVF1+oyWowkmaBWnMXbY3nZiHH LnOkGeBQZ6L9JxzxqwLtofpDRxPzWX+z831WEiwkh2OfHK3iXykYHnFIqZIxFlUayyq5/xoED4uR c6DlBwCcP88lVMzPlxZIMGJLMqeJgrDOH+jYdPCgPzYNhzxSHbaMaROCCqazXNjLzwVBWlq87dma jnb5lrIqrjzJxDlYoG0QRfslvapaq9kqrcZpB6ssR57bW2UJQf1FPQ3QVUDcIkRX+zArpILVNzHg kOIkaACmul5zM7LQzrSkpwsmBieXVXD3TLNGfzEkJ+PHnOBNPXOh5WG/33nJ8o7TkIoQ+POiONZQ o5yMWrqnkb72QMawHA0g5/acIPJP5Od3IBaxULBD9gP0fSaHqX3v3mijy942ftSY1F1IS7+J9gUG EdH/IAU5AitMY58WV352pJIrXbVqFbf1j2uxS6aByG5Q3BxO4Muwqu9A4keXMEoDx3OY/3sVjpJD HdG3RU77FWt7pIL7Cae1nk5LT3l9mJLYedRPbMe2pzCMWKRYGGaR5aBKVbOP4wMFqLGrd0WW0kaG GtMS1+hMTUpWWxM2LCi0BDL+AF2uKOZEfn4kK9vhUNoCEWzzcvM6Mzide2IDFez9W2Ox+LEjJ7jS zufvoyKXgHZkF+QnxiJUaUE+YiiyPdhj1wQNicj8/ApBowkv5Walrxc438ooKR+S4sC8HzXEY4lG BA5NmDmwJ1k5CrNUSQeSG7zK43BCvwUeMEIkPoa5az3OH8Luw439gUPNYg5HkiMcjv3G7w9ughrX TR2v8U6nLRXgayOyb7aVhZ28YWtyskCwwcc6pcYJndnOS9GDFCSueAQYF4nCQYNAckrS/W2+4Gyz qj1uMhmTI7HIFDhPV2qafXtb64RC2O1vBL5tTka6/VeNTW3/6iPfZEmztDmc1h9529rvuOfue8Zu +WDtuowM+wL0U2syq+/1D1mhPTcSxx9i7NaB87zysaYKlzgES4r825HD6H2fry38wV+c+mEbi6b9 Ok4JdNoRxxSie+Ib5wWny4F47GilUV8UyIrpZBKnTDfZZMThfYMoixSa4jBR4EjX/bVrq9TZBeG5 cdXqMvBqePGkTWd3VC8eVlbuZHPx8fmzEwUUYcfEODpcrj74lRvrfoz0nvVImaV91iTtpjiXEMxS fSMcqyby6gqTMeY6eFTZO1CcDi2cyfHK4z3AEThUlXosanGTVIAVDRISneXcuQlpdfX8XRFZDuXm 8klY6xpPePKe9Vcd9FRUmKy33ur6KcfxU6rOqQcOVUfX51j0gIOqqqJyFRH6sbDl6KOI+Rtw0glR GdGZunGTcI1Ubl0xu8bzb1XXiZHW5jps7vFU533yG9CWRXl5CPwjkbdK9jbj5BNPSIo4jUbjg0dO mZF+Mzba7S1tB8v9FRXhPPNXJmU/lJbm+/RgeesZqdqcM3y46998Pi+09OIxM4YN85/KsPYAZz80 NbFV0LgV+NkDHLIbIQqW71qt0iicXWHVjptMNS+CWHRu3ofEQSbSRaeRpblr7gTzk7LsKsRaus/0 BZfwNdSbAxu0sOiN46KvYHudze1z0Y8Fbd8EQJbr+wPSU79PS7Pf29LSch7SsWVkZDyI+0+Aab9E ciIL6anngsHgBRwRSk9KSqpFlmbagrSW0anJQ16OhoJF6I/DkbJSr9f7uzFjxgQPHjzYLUMSVG4F w9h9oydW58n3tkrOT9m5te4zZADxGSqOzszMZImKbU1NTQ+xhrj+EF+2QCAwEevoSgw4Ggd2DgDk G6tXr57F1K57ABj7CyCyCASPRr0GABgCzXF0PZ/RlaF5Gs9uT09PZ6Af93g8v4aEEVXyb+D7WXyz 0LSdZVegLXchi9OOBEY1GMaCq2afz4fErZqKvjaApu1ovwKfHtAME5zqdOgN9ss7tbIHeGGOpd3d SJ9pMQvCSPknPa3wg3logNLzuyAwHVJa0NHRsZaBZvfAoNOQzs9tNttz69aty8V1z/EvEFQMQnFq Q2Hz8Xlc+9BfMvqZjj4Xox8PO+SH6/WQbAMDzfqEmrJgaCXSVffjeynycJvYqQcwYQoYmQLQLA/o wW8JuTzC85ehlV5cf6U37ew3w4Sg5bNC18X0Wp/VmckQfl6OmT/HObKXcKSqkzWdBbT2eGgzpIg9 KqEz0X6x+Nh9cL2PNwOoIDRkF6rdC6JbQeyL+F4A0P+Keyzfpi9Y8G0HU8K9OwSDZRwFY7eSu5KP Gu79FvU0MOzbYE4trqd0CSYN/XZA+mx8tvmnF2Bh09oSk0HGrHVxiu0DfKaT85XUc29ivfZLtPlW P2D6JTjNdKjJYDA8jODjxbVrOw/ZwPE8CnUOtLW1XbIJD8I2QiLMlhMgjgFugWm8iGsOgPWzKqhT DPtkycY50KQ9XWN/F3ZNMLHdbAjU0SDdLfheCgbqyRHWFLQwun4AGp5B/2xleHE/PCb8EkvXNxm2 3nguWY8j4/FCqcdcivMvS3CGpHtVxTIlSLroKhiHE/o/Tqdz44YNG/ZDRd8DIXfCPgugpo+AsEt2 BkDUNkYcQHqhATWwzx1QYea1q3F9rIugl+AovwtV3QWtQdaFwIe0x6H+btQpxTjjYO88JPoqnmlW q3Un6rEFagwmxkHND+NzT15e3sdg3s/Q5ikkShbDSIcB0yVCHDARgTj5UcSzm5D92MdOC4PggwCn Z0BZQdL/LXActEurAQjhInnq6+sfA5HrenO1+zeY1QyVZNPXF+ze8uXLq9evX8+mlQ+667BzqwCz EGBfguR+DuITcFQboUHfZ3UAMgZGHce4fvx+GHV2wgyWwX98CDM4zqpg/E8g8ZctZvPtqmT/MKFE nga7lw9E04DAAbYc+a1XGXg0WgJVY1Fdn4JBkKBY/dstW7Y4N27c6Js4cWLnmYxBCiSxuLq6WjcL Zh6QYAHUONZ1TldvBYlX4lOEqY8lIRVMfz25/rq6OnbYj21C6AXtJsyaNcuIKSsGxva+j+gRyctm y+fwRK8X5oR6lru9SRs09YSjEy/jtOA0JOD/e162rHfWv7Bpq6ysrBWgL4dZf8YI7F0JhEd6g+79 DID7O84B++/fZ3elXQ3SizynnZufE35lMMIum3Ob54p8B5nOT/BZM8/Fsp1/v6Lnxn2ia8f6H51i DHznHa9hxOLRd8ZioTHY+X0Ds8qguf7LUcFoxbw7el6WvORy9S4LnDU0jJPuiFdFt5d6TGtxjhXJ hy9fSurNK1huO0DKf0//+hMm5O8fHnGrcyX2qwLIAdz9yNwRnvfff1+4kvn0p4SBxtpnHs6z3oKN +8sSekXgbAm3L99+S/xkdDMS/K/gePQ/Xyt0OMtJojnpv4gPizClBSUe6xIhI/N5ky11XKTde2Ru ZkcBy5Wv33HOVpOVdQwGdFm/0ZsORhum6eGGfOmW7uMeX0rirLHekYuWsGPbWMxs44yh+6/m1QgA zuZE409Fi/ERFSd8eWM4z91o+78GyfiEfpY12NYUj8g/wMH7jbymnhRrzL+8/wbn37Q9q4ejOLaN bhrmucJLriTpbmZcUeK9ucbOg+sH9ePWne76yx7U15uxTQE1yM/BIdivInsyFEev9qjxuJ0TrB9a 7GkzYuEgTirgEJ8SjyHH/kfMYCZogo2yLq+m3TR1HdRfi7n69ULXP/CgPhuQvQkAmyxBbuZ5d1PS 10iMP9X/1YweZvlwRIXUNhLVN2OxCIfNxPGYIr+FjcS6kLdpJ6L/XIPBxA7jr0a4eziRUPLcXusU dkh/1yv/Xt57sdNHrdmrGYrhZyRoeZD0gxAIsj9XV65K4t1dd70DslB/GUeV3tvTYt4Jp4T4vvNl nJ56OVF2NvuvuvS9UgZWFV9BZrVATcTT4dwyEDkHlXg0iCzuoxB6h4DoDrm8SlGh1wYCrb+Mo9K/ gJlF0A72Ms63rw7uxdrXBLwHGN4Cgo29qb9+pQnv7mlNOa4muN93vTXUhyZoBXZko09hO/kzo2gs xGGjCdgbS0dEcw6n+VvgjY8jm/LpwrTQif5gOl+/0u4TiJsMf8dev7q9MOt/8fUrXfX1VyPaV8Hm 8cKd815eUJ/c05KCnAaVYXekRI3FjiIS7AlIFuZES8AAfAYvcIapvNE4VePwwp1GBTgmj2PQwvZE LLS684W7gROZVyP9LyXxvmrNtmva2ALi1e5XLGG7y8lgdO5uMuIVS60JqxTkzqgZcXiA51XsPrGE AI/FD2/Hzwws0bLRJpMMyFlpnBfZhTJNFJ78//oVyz5M6HwXVE88DvRSLew7E1KTGNeRgMdLtcRe qr2AQwj7tcT/m5dq/we6gzldZHDSgQAAAABJRU5ErkJggg== --_005_6e648736a087468a82b04a99feff382aARBLVEXCH1americanrivie_-- From nobody Fri Feb 7 10:22:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0711200FA for ; Fri, 7 Feb 2020 10:22:55 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 40wmRWfvEVdx for ; Fri, 7 Feb 2020 10:22:54 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 1D3221200B9 for ; Fri, 7 Feb 2020 10:22:54 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id g15so216163vsf.1 for ; Fri, 07 Feb 2020 10:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=x7UJi63WphTmF73flQlU9ekTY0+cF4nDZF+aBFUFAiI=; b=apB+MuydJTVKNBOprq1BqdRkxPOTvxzgM//aQ/FUCqmxHCI184uzfQVI4uZokou8Ii s+RHGtMeIctcIYkQ3ea8ceg5Nscf0y6odQ/54g1bjidLb1swyC1eKbXV8795uPEncDWN 3VgY5FFbGNh6IQPf8jU2W4UNqZP/kNwOXpd/lkF4N+rHkNsTF24fVRvKiIPNpWAP60Kf 9p4iRM5BeMQrDemfegpO79Jvna+XVsVjUMRIveMgMX6REpEPybcu44RlSDyGmjK8gbOr UtzgCM6D81o33tfET/aXB60PDF3vA3t5iWCYjiMGlIff49Ea0qXI3ZSKqq5L2lSDB5uI qB2A== 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=x7UJi63WphTmF73flQlU9ekTY0+cF4nDZF+aBFUFAiI=; b=KX3wALQNn8J3/BNjW1RenomFA/LKJ6cM0HpTKD81u2joH3MwOBktp0Vk5GJIiQIWI1 2xc/wVS8BrxasanSAvqFxPv+XZ0pkH7sWgQkfpcgM5GBF9N/4KEshOEuJ89uVI14uI9o emS+kG1H6gu7CWAaKEB0YbkFkRcl/cjxkCLP34ba4web7AgZKWXKHiIwRz+/YPQoOlV2 +u/TWyBZnee69CHYiavlmgMUIiUdAztBHaIzd81WW+LFVYvlAgeyHPHWGE1ou/dgB/tV HtTeamvXoJb+B5BZ5MYL/Zx/J92USf5MiqmauNdPQdBmW5TV0umdIvtMSlHk2Wqcu2LB zbHw== X-Gm-Message-State: APjAAAWXpSaWus+kzUH16s3iXQW+OAoxdFmoEG0wCuljeY5gXrGy/7OB kOnIQ/fG1KalbeQym1Ewl2bTFQneO8K/f2xstCTv/Q== X-Google-Smtp-Source: APXvYqxhsjVXIIsZQMT89YEaSNPAxDsdGS007enkXEkTV3uqTBGRjlVdAQU3l7ua8bj7T2QWzKSq800R4dSqdRe0hL4= X-Received: by 2002:a05:6102:376:: with SMTP id f22mr299336vsa.175.1581099773004; Fri, 07 Feb 2020 10:22:53 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Fri, 7 Feb 2020 10:22:42 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000531027059e007ae2" Archived-At: Subject: [dmarc-ietf] Upcoming personnel changes 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, 07 Feb 2020 18:22:56 -0000 --000000000000531027059e007ae2 Content-Type: text/plain; charset="UTF-8" Colleagues, We have some personnel changes to announce. First, we would like to thank Tim Wicinski for stepping in to co-chair DMARC with me. Going forward he will be focusing on his duties with DNSOP and other IETF work and is still, of course, welcome to participate here. For the next couple of months, I will be going it alone. Second, I have been appointed by the NomCom to a two year term as ART Area Director. Alexey Melnikov and Adam Roach are finishing their terms in March at the Vancouver meeting, and the IESG has elected to close one of those positions. I will assume that role at the March meeting. Barry Leiba still has a year left in his current term as the other ART AD. Accordingly, at that time, Alexey and I will effectively trade roles: He will become DMARC chair and I will become its supervising Area Director, while we consider our options for assigning a co-chair to carry the load with him. So nothing changes until March, but we thought it appropriate to advise the WG of the plan ahead of time. -MSK, still chairin' for now --000000000000531027059e007ae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

We have some perso= nnel changes to announce.=C2=A0 First, we would like to thank Tim Wicinski = for stepping in to co-chair DMARC with me.=C2=A0 Going forward he will be f= ocusing on his duties with DNSOP and other IETF work and is still, of cours= e, welcome to participate here.=C2=A0 For the next couple of months, I will= be going it alone.

Second, I have been appointed b= y the NomCom to a two year term as ART Area Director.=C2=A0 Alexey Melnikov= and Adam Roach are finishing their terms in March at the Vancouver meeting= , and the IESG has elected to close one of those positions.=C2=A0 I will as= sume that role at the March meeting.=C2=A0 Barry Leiba still has a year lef= t in his current term as the other ART AD.

Accordingly, a= t that time, Alexey and I will effectively trade roles: He will become DMAR= C chair and I will become its supervising Area Director, while we consider = our options for assigning a co-chair to carry the load with him.=C2=A0 So n= othing changes until March, but we thought it appropriate to advise the WG = of the plan ahead of time.

-MSK, still chairin'= ; for now
--000000000000531027059e007ae2-- From nobody Mon Feb 10 07:58:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFD71200EC for ; Sun, 9 Feb 2020 05:32: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=pass (1024-bit key) header.d=isdg.net header.b=PO4JLt4B; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=zCenZspk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Ncs87Nu7uY for ; Sun, 9 Feb 2020 05:31:59 -0800 (PST) Received: from mail.winserver.com (ntbbs.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA1912003E for ; Sun, 9 Feb 2020 05:31:59 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1545; t=1581255111; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=CeoYT80rI45wKBmv7YxckTcYwUA=; b=PO4JLt4Be3PHSWeZsqGMtyjMG+QwjueRDvwsUQeduyOQ1b4KFqOizTxrFCEVhc N9hP02z1a8vlUuLYpGRT6c4su/wpKKrvImxyAD2g2s5Jm1TlA1MReVEUUmQooOoe xZCaOz7V7Z0dayljjHnXO9d78x+UNUCpGjWk8/UM2qO0s= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sun, 09 Feb 2020 08:31:51 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=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 v8.0.454.9) with ESMTP id 572473789.17.6212; Sun, 09 Feb 2020 08:31:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1545; t=1581254877; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OOJudBy BoDCVw5CKMEW1kKSzSF5HDDpZylnun/1GO+Q=; b=zCenZspk4a7p1G67569d8yf utyQmrOUepGuhWp0hVrozRK1alDPNBsetuir1IiGn6AAFRYEOUzBFvR11ZNbORVr xkGZaeE/6o7EY5of10Of+zI+oznyqLRPhcjjMkO7KmFENpt+T+VL4m3BHXQ1Vbx0 pdW1NCFOMLU/0vSBdWkw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Sun, 09 Feb 2020 08:27:57 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 420517015.4.2876; Sun, 09 Feb 2020 08:27:56 -0500 Message-ID: <5E4009C1.3070201@isdg.net> Date: Sun, 09 Feb 2020 08:31:45 -0500 From: Hector Santos Reply-To: hsantos@isdg.net 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: "Murray S. Kucherawy" , IETF DMARC WG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Upcoming personnel changes 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, 09 Feb 2020 13:32:02 -0000 Congratulations. The IETF will be enhanced with your new assignments and roles. How will this affect the future and editorship of DMARCbis? I wonder if there could be a "conflict of interest" concerns. Thanks -- HLS On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote: > Colleagues, > > We have some personnel changes to announce. First, we would like to > thank Tim Wicinski for stepping in to co-chair DMARC with me. Going > forward he will be focusing on his duties with DNSOP and other IETF > work and is still, of course, welcome to participate here. For the > next couple of months, I will be going it alone. > > Second, I have been appointed by the NomCom to a two year term as ART > Area Director. Alexey Melnikov and Adam Roach are finishing their > terms in March at the Vancouver meeting, and the IESG has elected to > close one of those positions. I will assume that role at the March > meeting. Barry Leiba still has a year left in his current term as the > other ART AD. > > Accordingly, at that time, Alexey and I will effectively trade roles: > He will become DMARC chair and I will become its supervising Area > Director, while we consider our options for assigning a co-chair to > carry the load with him. So nothing changes until March, but we > thought it appropriate to advise the WG of the plan ahead of time. > > -MSK, still chairin' for now > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon Feb 10 08:12:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27C7120864 for ; Mon, 10 Feb 2020 08:01: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=de9iasfr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ArpuqaG7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSuUM0my1zc3 for ; Mon, 10 Feb 2020 08:01:19 -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 C5483120A0A for ; Mon, 10 Feb 2020 08:01:19 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ECB4A2233C; Mon, 10 Feb 2020 11:01:18 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Mon, 10 Feb 2020 11:01:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=4c1yTy19UOip5Nq0d56zjxskSbcor1O YqSdKMR89MsA=; b=de9iasfrRAcBtZy/rRx9QaRwEuHatF5SYEGtovticFV3+kX qGpZIlCq4j6GMe2Fz+ZBm8BpdELe1qZXmitlLpdL4qn0UgQQkx5hBelR6fVwV7PX h4sjrZqvndfJlDnOSsM4BNqrJsuovR/ecwDLmEjFYmEgezx7LJrnPmfCy3+lUFKP C9/+IBQ/UpsYLm6Oy3LbHkq/bgo3VrQy6v2QDq2/roEOG9xiNrnV4IwGy6TVI/3b X8+JOKu7sH1o/8aQKJfRjZXOHkKJ22NFwlqLfxdaIRETdzF6OxcZ3gTFJqOcEoPI /4Yth2r3zVbLNV1x6NRE4mE5FRoUFKTnpiPxPew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=4c1yTy 19UOip5Nq0d56zjxskSbcor1OYqSdKMR89MsA=; b=ArpuqaG7xioEwZS/2xkQQK o+tudgWADdrKApgNT9lg1vx4YSFSN5OS/u5MEwVa5Ja2NuOHptacBxLIRuO2cgOK b72a2G+mnWC1DDJ9WDfrdyyFwNc7nCJELFnoEgvCD4fnRiL0pGxhWAia+7cIuQNP e0y08x197as3Cz4np42sl5Ivz0AXnfkbViBytpUazeVE8piAdoLvPGYqR/YtDUiJ 8YHJ6XatHXPpcICWNQAewow6dxH3fWO0r9zoO4n6dFc9GQ2pcMvQ371/eY0VKfHC lTtz9QpeHjRXdD2vUBfOyCVRJmCA5dl9iaZ7z9kaHHBCrZ8Gzc4GEuO49c2GApJw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedriedugdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 12BD06600CC; Mon, 10 Feb 2020 11:01:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <96161f11-db74-4064-99fb-0dae7c43b716@www.fastmail.com> In-Reply-To: <5E4009C1.3070201@isdg.net> References: <5E4009C1.3070201@isdg.net> Date: Mon, 10 Feb 2020 16:00:55 +0000 From: "Alexey Melnikov" To: "Hector Santos" , "Murray S. Kucherawy" , "IETF DMARC WG" Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] Upcoming personnel changes 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, 10 Feb 2020 16:01:26 -0000 Hi Hector, On Sun, Feb 9, 2020, at 1:31 PM, Hector Santos wrote: > Congratulations. The IETF will be enhanced with your new assignments > and roles. > > How will this affect the future and editorship of DMARCbis? I wonder > if there could be a "conflict of interest" concerns. In cases when an Area Director [co-]edit a document another Area Director is typically in charge of document shepherding/judging consensus. Best Regards, Alexey > Thanks > > -- > HLS > > On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote: > > Colleagues, > > > > We have some personnel changes to announce. First, we would like to > > thank Tim Wicinski for stepping in to co-chair DMARC with me. Going > > forward he will be focusing on his duties with DNSOP and other IETF > > work and is still, of course, welcome to participate here. For the > > next couple of months, I will be going it alone. > > > > Second, I have been appointed by the NomCom to a two year term as ART > > Area Director. Alexey Melnikov and Adam Roach are finishing their > > terms in March at the Vancouver meeting, and the IESG has elected to > > close one of those positions. I will assume that role at the March > > meeting. Barry Leiba still has a year left in his current term as the > > other ART AD. > > > > Accordingly, at that time, Alexey and I will effectively trade roles: > > He will become DMARC chair and I will become its supervising Area > > Director, while we consider our options for assigning a co-chair to > > carry the load with him. So nothing changes until March, but we > > thought it appropriate to advise the WG of the plan ahead of time. > > > > -MSK, still chairin' for now > > > > > > _______________________________________________ > > 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 > From nobody Thu Feb 13 02:26:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49A1200DB for ; Thu, 13 Feb 2020 02:26:04 -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 (1024-bit key) header.d=protonmail.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 eIV5bZ9g4HEl for ; Thu, 13 Feb 2020 02:26:00 -0800 (PST) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (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 441551200DF for ; Thu, 13 Feb 2020 02:26:00 -0800 (PST) Date: Thu, 13 Feb 2020 10:25:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1581589557; bh=qyIxYG4fwL7wC9e8B8oEOT/T805P9hHWVL0lL7dyI+4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=jMUNjuVcFRNccHtLr/yS2F32nmm7wf4eE0GnMTlFbYXc376ako9QZ3W7iV+YgrZhI g28JRCkHPRTo+zdClwKWT0KUeMJxDEMOd1n7HztUul1mx9R4Oe+nx1GECQMGE8zz8s 9FX2EBJ5irwAGFfEad+gmj6kDCJZPCQ7hzeIePfo= To: Alessandro Vesely From: Jane Moneypenny Cc: "dmarc@ietf.org" Reply-To: Jane Moneypenny Message-ID: In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> Feedback-ID: maG8rBvbVesMvSttssIWvHvk4FVyIn95_Qx9mK3VOL2K8_0Gp4G9wiVKu5rDHO6CjG4Ix8q6os17SKjYvK8tHA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Comment on DMARCbis, was 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: Thu, 13 Feb 2020 10:26:04 -0000 > For a second issue, consider whether report generators should track polic= y > changes during the day and, in case, send multiple reports with different > PolicyPublished. Otherwise, PolicyPublished would be valid for only a par= t of > the reported rows, presumably the last. Is that acceptable? > Shall the "policy tracking" mechanism take into consideration:- - TTL, - DNS cache issues? Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, February 6, 2020 7:44 PM, Alessandro Vesely w= rote: > On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote: > > > On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman sklist@kitterman.com wro= te: > > > > > I agree on DMARCbis. I don't think advancing this draft has a signifi= cant > > > effect on that. Worst case, if DMARCbis is done before we can reach a= ny > > > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMA= RC in > > > it. > > +1, albeit I don't think DMARCbis arrives so quickly > > > I think we've always been assuming that PSD DMARC would be input to > > DMARCbis, so we were planning to start the latter but not close it unti= l > > the former was completed. This is the first time I've seen a different > > suggestion. > > I'd love to hear more opinions about ordering of the work here. This se= ems > > like an ideal time to review and update our milestones. > > There are quite some issues about DMARC. Let me mention aggregate report > format first, as this brings out a third thing which can be done in paral= lel, > namely to publish http://dmarc.org/dmarc-xml/0.2. > > Various tweaks have been proposed, I think they're well summarized in > http://bit.ly/dmarc-rpt-schema > > For a second issue, consider whether report generators should track polic= y > changes during the day and, in case, send multiple reports with different > PolicyPublished. Otherwise, PolicyPublished would be valid for only a par= t of > the reported rows, presumably the last. Is that acceptable? > > Another case for sending multiple reports at once is on hitting size limi= ts. > Is better to increase sending frequency instead? How to negotiate sending > frequency between report consumer's ri=3D and producer's conditions deser= ves some > discussion. > > I'm sure there's a bunch of other issues, and we should start to collect = them. > > > > I don't see anything about PSD DMARC being inherently on the critical > > > path for DMARCbis. I suspect the current major obstacle to DMARCbis i= s > > > that the question of how to take the PSL out of the equation is unsol= ved, > > > despite one IETF WG that was supposed to be dedicated to the question= .>> > > > I don't think not publishing PSD DMARC helps move DMARCbis forward, s= o I > > > think it's a false choice.>> > > > > I think what Dave proposed about PSL separation from DMARC is entirely > > appropriate and pragmatic, and in fact probably easy enough: DMARC is > > changed so that it says the organizational domain is determined using s= ome > > process [currently] external to DMARC, and then a second document expla= ins > > how that process is accomplished using the PSL (and/or PSD, depending o= n > > when the experiment result comes in). That's a fairly simple edit overa= ll, > > and is actually probably minor and non-controversial compared to some o= f > > the other surgery that I believe is in the queue. > > +1, let DMARC core defineorganizational domain by characteristics. A seco= nd > document present a process, possibly demonstrating how the required > characteristics are met. > > Scott's I-D already outlines the characteristics of Branded and > Multi-organization PSDs, that the experimental processes are suited for. > > Best > Ale > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------- > > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Feb 21 08:01:22 2020 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 7D2941208C0 for ; Fri, 21 Feb 2020 08:01:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158230088050.28993.18092704718232444395.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2020 08:01:20 -0800 From: IETF Secretariat Archived-At: Subject: [dmarc-ietf] Milestones changed for dmarc WG 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: Fri, 21 Feb 2020 16:01:21 -0000 Deleted milestone "Complete EAI update to SPF/DKIM/DMARC". Deleted milestone "Complete Authenticated Received Chain (ARC) usage recommendations". URL: https://datatracker.ietf.org/wg/dmarc/about/ From nobody Wed Feb 26 20:57:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA2C3A1147 for ; Wed, 26 Feb 2020 20:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SglELfICuwyZ for ; Wed, 26 Feb 2020 20:57:49 -0800 (PST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 B98F33A1142 for ; Wed, 26 Feb 2020 20:57:49 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id i4so381669vkc.3 for ; Wed, 26 Feb 2020 20:57:49 -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=7lHIj9LB0vPqLiTb3LXde2mTh8EdFAmJF0B2RXBgv3k=; b=dnvnALPhzIJgRS7DAXKwPsBklQGlgEPsDGQuIc8dBAm2FSaKpPtVSiCep7suN8WQlt evi0QIemmyzGVODne5onm7xJznd40VV+3eGkMFL1mV1ZW6jIsgZ4OhJBUO4y1tLt+op6 pIQTnuOsKt0Yrv+0K+yOKhgOxYYWfFVq1kM4TlblFPmfxQIiKJzml84kLCG/Vp4niW8n MgQjU1jbO0+uvkrG1u8J8+VaLeSByiInykhgDW7++n91JtJH1OV1/J/eYawbi4E6mHTh BXpOcD9CnKoM3OK2Y53lA5WaB0+UfAYPfulY6swqH0Qz/7tgEYywrXZ2va3UVv34nDSq rqmQ== 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=7lHIj9LB0vPqLiTb3LXde2mTh8EdFAmJF0B2RXBgv3k=; b=Z9HN2HQr+XaG5WUsEZHkyGkK29gJY8nxz8Ii1XCD0sRklAiy/06l+H5B6QTyRJVz7d lCv9DYQhYbOSAVIGkyK5HuH5kC7W2XTsk8p+FkcMjoPs3wFO3nz0xRpYW4887ysBLk9W K4WXDqim309+11xwzvEI0Fm+n1vXFrpYKhCewgAC6VLmH2rPU6BTaBmfoTcEuvwYj9YP yjN/lPtXXDWtbxkIpidSha3OGg4uAS+vm0HA8jiS4Sjbg2FF23UfiR8DTCuDbRz+TW3f HsC2y57y5eiJsRZjt9Ylo63W3snY+4EFiaZbL6+flG9DjrpTLJ0s64QJ2Q8aDjWI7Ko9 A8Ww== X-Gm-Message-State: APjAAAXibSCj2a32heThwm7SkBtgzRz9KfcWaoijNjZ43Xkxpa07yQSz /ssSqJ/+SLm3O7MNEouSjj6XcMKmZv43nbynKVrIfg== X-Google-Smtp-Source: APXvYqztIiZ80BwY3WVnA8SeBH+KrFahWNF3pdX+T3EnSMceH3KWivtiy7bDGTMJSti5zljdAxpUmO1KXuJTqOzrV10= X-Received: by 2002:a05:6122:332:: with SMTP id d18mr1613747vko.89.1582779468700; Wed, 26 Feb 2020 20:57:48 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 26 Feb 2020 20:57:35 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fd602d059f878fd7" Archived-At: Subject: Re: [dmarc-ietf] Comment on DMARCbis, was 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: Thu, 27 Feb 2020 04:57:51 -0000 --000000000000fd602d059f878fd7 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 6, 2020 at 10:44 AM Alessandro Vesely wrote: > +1, albeit I don't think DMARCbis arrives so quickly > I don't actually think there's much stopping us from beginning the work on DMARCbis now. Seth has dutifully been collecting those and putting them in the group's tracker for a while now, and everyone else is invited to make sure their favorite issues are thus recorded so we can go through them all when the time comes. With only a few weeks left in this chair, I won't pull that trigger now, but you should all expect to get going on that before long. > I think we've always been assuming that PSD DMARC would be input to > > DMARCbis, so we were planning to start the latter but not close it until > > the former was completed. This is the first time I've seen a different > > suggestion. > > > > I'd love to hear more opinions about ordering of the work here. This > seems > > like an ideal time to review and update our milestones. > > There are quite some issues about DMARC. Let me mention aggregate report > format first, as this brings out a third thing which can be done in > parallel, > namely to publish http://dmarc.org/dmarc-xml/0.2. > [...] > Please make sure that these are all recorded in the tracker so they can be discussed and factored in when the time comes. I'm sure there's a bunch of other issues, and we should start to collect > them. > This started some time ago. :-) -MSK --000000000000fd602d059f878fd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 6, 2020 at 10:44 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
+1, albeit I don't think DMARCbis arrives so quickly

I don't actually think there's much = stopping us from beginning the work on DMARCbis now.=C2=A0 Seth has dutiful= ly been collecting those and putting them in the group's tracker for a = while now, and everyone else is invited to make sure their favorite issues = are thus recorded so we can go through them all when the time comes.
<= div>
With only a few weeks left in this chair, I won't pu= ll that trigger now, but you should all expect to get going on that before = long.

> I think we've always been assuming that PSD DMARC would be input t= o
> DMARCbis, so we were planning to start the latter but not close it unt= il
> the former was completed.=C2=A0 This is the first time I've seen a= different
> suggestion.
>
> I'd love to hear more opinions about ordering of the work here.=C2= =A0 This seems
> like an ideal time to review and update our milestones.

There are quite some issues about DMARC.=C2=A0 Let me mention aggregate rep= ort
format first, as this brings out a third thing which can be done in paralle= l,
namely to publish http://dmarc.org/dmarc-xml/0.2.
[...]

Please make sure that these are a= ll recorded in the tracker so they can be discussed and factored in when th= e time comes.

I'm sure there's a bunch of other issues, and we should = start to collect them.

This started som= e time ago.=C2=A0 :-)

-MSK
--000000000000fd602d059f878fd7-- From nobody Wed Feb 26 21:31:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB063A120C for ; Wed, 26 Feb 2020 21:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DzKZNQWxG-sw for ; Wed, 26 Feb 2020 21:31:14 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 9F8CD3A1210 for ; Wed, 26 Feb 2020 21:31:14 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id w15so534539uap.0 for ; Wed, 26 Feb 2020 21:31:14 -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=p+c/zh2fAI/SsiCXAps07qpOcCfjEhiyFpjJdS/YR9M=; b=vDZOHS3YHUpZrcdhB7P03h0gvx3gBpg/iZU3X9UBHUp+JH2yZCboHDWcuUxAL8ECmv JYwKXKVGDoq6SKg9hB/IIiyZtaO0SWtHD+0Rd1vT3x41IvtBUaLcr1BX9/xKLFxqZMRu buZL/fMba3CDwNEtDTFOcBOmj24vQtndDapyQMIbj/WiNF96aqQ7XMCQF4lu6ph8cF5B tZKpvUj77CWBUNO3bRzk5AjGEfnj2xudFcMLxZILTwuKY2D7ZK4Q5qdjh7j7BZ1Vm5H6 YEubaUAV68gWaWzZLdqFhjd+VR9qqzhSorvdK+NHRRkJesujQ5XjNY+Pk+HQvYq12yJ+ Jcew== 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=p+c/zh2fAI/SsiCXAps07qpOcCfjEhiyFpjJdS/YR9M=; b=aRjMR8PdPaL/tVWy6zBUFhqvWGv8y+8yzCnXw16m3P1GaI2b4bAlTvXFHLVUc7OcrT /PTt6EOWsF2uQFkVDKPCoF4rWnFx1afcXeGYQMESayI1XKbEbDWJkGK3L+545dCV6pnA PS3GpWdCkFmmrHI1NQDzpXUDvhtonBwLP0BpRSF8DRHpaGWBojNZGHBRQMaS/aQhN/Bu ZZb9iJcyFIzzXyPbqxwUmuE8SjMUxyV8HXKgXLFPAwTMKDY1Ze9f7yVWCargE63HbFrV VcziHQzeQyjgJtptXFMPzMjT0pfZmJD1AR1WPKF7wrjrH7rLsz/CYH5QHdOcNCZalebm kiXg== X-Gm-Message-State: APjAAAVl8fP/NlwJKahaXNHMe3n/0jCmsCM+Vv7gcyFVDNRpU8FdiKes SJ+wtjbo1UA4Wffg3jhLWESHHfoYm9z8IIC2klDi1g== X-Google-Smtp-Source: APXvYqzkYg5hwBdhUgHNX2ffWJb8sD2N1/b6To5bplq4PHKsF+XErtk80twOCks6fH/vxKAeJGjKtzl8pxns3ncDM1k= X-Received: by 2002:ab0:7358:: with SMTP id k24mr1525289uap.87.1582781473456; Wed, 26 Feb 2020 21:31:13 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 26 Feb 2020 21:30:59 -0800 Message-ID: To: Craig Schwartz Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007b8661059f880725" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Thu, 27 Feb 2020 05:31:17 -0000 --0000000000007b8661059f880725 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz wrote: > First, while I know you've said the needs of external actors won't weigh > on your decision about moving forward, I would like to mention that > having a stable reference for PSD DMARC will help us with working towards > policy changes that would allow us to participate in this experiment. It > may not be important to the WG Chairs' decision on the draft, but there > are stakeholders for whom it is important. > Just to be clear, I don't mean to suggest the restriction you're referring to is invalid. I'm sympathetic to the idea that some potential participants in PSD are constrained by policies outside of their control or ours. But I look at it this way: A series of "X can't happen until Y happens" assertions have been made over the last while, and the series is roughly circular. I don't mean to be insensitive to the pain of you or others under external constraints, yet at the same time, from the perspective of the IETF, those constraints are very much external and thus are easier to disqualify as we try (sometimes desperately) to find a way out of this deadlock we're in. I will also be somewhat ashamed to hand Alexey a deadlocked working group in March. :-) With my chair hat on, I'm leaning toward making the following consensus evaluation: With a completed (and now seven month old) Working Group Last Call on the PSD document, and as far as I can see no sustained objection, we should proceed toward publication. Unless someone wants to argue that this is not the WG's consensus, we'll proceed at the end of next week. To be specific: Dave raised a post-WGLC concern that DMARC and its use of the PSL really ought to be teased apart. I have heard no objection to that, and in fact have seen some support for it, so I consider that also to have consensus. The part that does not appear to have consensus is that it is mandatory for this to be done before the PSD work can proceed. Dave also suggested that Experimental status is not procedurally appropriate for this work, and stated some reasons. There appear to be no others lending support for this assertion either. However, while I disagree, and I believe I gave an existence proof to the contrary, I will put this question to the working group: Can we solve this problem by switching the document to Informational status, and can the working group accept that outcome? That seems an easy compromise, and I saw it proposed but not fully discussed yet. This seems quite reasonable as well when one considers that PSD's proponents could very likely get the thing published as an RFC via the Independent Stream if they continue to find no progress here. So, please discuss this option on the list and I'll measure consensus on it at the end of next week as well when next steps are chosen. Mike objected to PSD generally, also long after WGLC completed. This too does not appear to have swayed consensus. (And he's been cogitating on that thread for a few weeks now...) As a reminder, we still need to do AD evaluation, an IETF-wide last call, directorate reviews, and IESG evaluation before it lands in the RFC editor's queue. -MSK --0000000000007b8661059f880725 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 5, 2020 at 3:02 AM Craig Schw= artz <craig@ftld.com= > wrote:
First, while I know you've said the needs of ex= ternal actors won't weigh on=C2=A0your decision about moving forward, I would like t= o mention that having a=C2=A0stable reference for PSD DMARC will help us with working to= wards policy=C2=A0changes that would allow us to participate in this experiment.=C2=A0 I= t may not be=C2=A0important to the WG Chairs' decision on the draft, but there are s= takeholders=C2=A0for whom it is important.

= Just to be clear, I don't mean to suggest the restriction you're re= ferring to is invalid.=C2=A0 I'm sympathetic to the idea that some pote= ntial participants in PSD are constrained by policies outside of their cont= rol or ours.=C2=A0 But I look at it this way: A series of "X can't= happen until Y happens" assertions have been made over the last while= , and the series is roughly circular.=C2=A0 I don't mean to be insensit= ive to the pain of you or others under external constraints, yet at the sam= e time, from the perspective of the IETF, those constraints are very much e= xternal and thus are easier to disqualify as we try (sometimes desperately)= to find a way out of this deadlock we're in.

<= div>I will also be somewhat ashamed to hand Alexey a deadlocked working gro= up in March.=C2=A0 :-)

With my chair hat on, I'= ;m leaning toward making the following consensus evaluation: With a complet= ed (and now seven month old) Working Group Last Call on the PSD document, a= nd as far as I can see no sustained objection, we should proceed toward pub= lication.=C2=A0 Unless someone wants to argue that this is not the WG's= consensus, we'll proceed at the end of next week.

=
To be specific:

Dave raised a post-WGLC conce= rn that DMARC and its use of the PSL really ought to be teased apart.=C2=A0= I have heard no objection to that, and in fact have seen some support for = it, so I consider that also to have consensus.=C2=A0 The part that does not= appear to have consensus is that it is mandatory for this to be done befor= e the PSD work can proceed.

Dave also suggested that Ex= perimental status is not procedurally appropriate for this work, and stated= some reasons.=C2=A0 There appear to be no others lending support for this = assertion either.=C2=A0 However, while I disagree, and I believe I gave an = existence proof to the contrary, I will put this question to the working gr= oup: Can we solve this problem by switching the document to Informational s= tatus, and can the working group accept that outcome?=C2=A0 That seems an e= asy compromise, and I saw it proposed but not fully discussed yet.=C2=A0 Th= is seems quite reasonable as well when one considers that PSD's propone= nts could very likely get the thing published as an RFC via the Independent= Stream if they continue to find no progress here.=C2=A0 So, please discuss= this option on the list and I'll measure consensus on it at the end of= next week as well when next steps are chosen.

Mike objected to PSD generally= , also long after WGLC completed.=C2=A0 This too does not appear to have sw= ayed consensus.=C2=A0 (And he's been cogitating on that thread for a fe= w weeks now...)

As a reminder, we still need to do AD evaluation, an IETF-wid= e last call, directorate reviews, and IESG evaluation before it lands in th= e RFC editor's queue.

-MS= K

--0000000000007b8661059f880725-- From nobody Thu Feb 27 03:59:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850FD3A0A24 for ; Thu, 27 Feb 2020 03:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 VpSEThfe-V_e for ; Thu, 27 Feb 2020 03:58:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 876F23A0A21 for ; Thu, 27 Feb 2020 03:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1582804729; bh=ocfQfGtpzyhIQThQ14fCrbxlkcCqCQtQgTlcWPTeFQA=; l=1088; h=To:Cc:References:From:Date:In-Reply-To; b=BAEsHvOy+PWylPbHS+JmRBhHJmhtIGcxYhncBhYDFkAYNwoZXf3AvxP03mr7evPya 1/z3t65xBM6EVQfa38Jf0vpvcQclnJjvh6c8RmuJIR4QSWytHts3WOY+rjJ8ztRU4l WDIJfMwxjIvpfp80G0dBCHjISYZ8gNPr3M37dkIh4PuGHS3b9UVhfgMjYK1GV 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02F.000000005E57AEF9.000013CB; Thu, 27 Feb 2020 12:58:49 +0100 To: "Murray S. Kucherawy" Cc: IETF DMARC WG , Freddie Leeman References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <9467613.0cjHueyR6G@l5580> From: Alessandro Vesely Message-ID: <86473ecf-84d1-eb00-6459-862762d2b5ad@tana.it> Date: Thu, 27 Feb 2020 12:58:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.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] Comment on DMARCbis, was 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: Thu, 27 Feb 2020 11:59:01 -0000 On Thu 27/Feb/2020 05:57:35 +0100 Murray S. Kucherawy wrote: > On Thu, Feb 6, 2020 at 10:44 AM Alessandro Vesely wrote: >> >> There are quite some issues about DMARC. Let me mention aggregate report >> format first, as this brings out a third thing which can be done in >> parallel, namely to publish http://dmarc.org/dmarc-xml/0.2. >> [...] >> > > Please make sure that these are all recorded in the tracker so they can be > discussed and factored in when the time comes. I've added tickets 31, 32, and 33. The first two ones are Freddie's entries I found walking top down http://bit.ly/dmarc-rpt-schema . Then I stopped adding his entries, as I don't fully understand some details. Freddie, please get there[*] and edit as needed. #33 is the proposal to substitute the element with the URI of the spec, so as to let automatic parsers understand the syntax. When the WG agrees on XML format details, we can publish the resulting schema at http://dmarc.org/dmarc-xml/0.2. Best Ale -- [*] https://trac.ietf.org/trac/dmarc/ From nobody Thu Feb 27 04:16:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7183A0A69 for ; Thu, 27 Feb 2020 04:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 xOjPeH2y56Z4 for ; Thu, 27 Feb 2020 04:16:35 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 E51EC3A0A65 for ; Thu, 27 Feb 2020 04:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1582805793; bh=sE3e+fA5QucUz7uGXQhQsyqhunku7dpJ7Pu52JQiv6o=; l=868; h=To:References:From:Date:In-Reply-To; b=A0pUO2/Qk7atrF/lFYZ8XfFTk/22FGN2JEijAVmqZZP5zBv89XCspBvNSjUcIVdAc Z/g+gWfZmXx6FR98xtQ5+z5filGUrClj0b7G5tmNlrvgfheHuqLmmjCzJg5pL3V47A hOVF1gvApiBq3Kok5w0Pl32XEo3l5A+m5A8NTS6/xatCtf9PW5DYMfz5pDkJi 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, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02F.000000005E57B321.0000164A; Thu, 27 Feb 2020 13:16:33 +0100 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> From: Alessandro Vesely Message-ID: <281fcc15-049c-b586-8514-0322cd0578c6@tana.it> Date: Thu, 27 Feb 2020 13:16:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.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] Comment on 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: Thu, 27 Feb 2020 12:16:36 -0000 On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote: > > With a completed (and now seven month old) Working Group Last Call on the > PSD document, and as far as I can see no sustained objection, we should > proceed toward publication. Great! > I will put this question to the working group: Can we solve this problem by > switching the document to Informational status, and can the working group > accept that outcome? IMHO, experimental is appropriate. There are three competing methods; maybe it will be worth to maintain all of them indefinitely, maybe some of them will turn out to be impractical or not used. That's the experimental question. The sooner we run it the sooner the response. If publishing as experimental would further delay publication, I'd accept informational. However, I don't understand why. jm2c Ale -- From nobody Thu Feb 27 13:50:09 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C133A0CC1 for ; Thu, 27 Feb 2020 13:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Sh-q1OcC_vba for ; Thu, 27 Feb 2020 13:50:07 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0: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 4F5BF3A0CB0 for ; Thu, 27 Feb 2020 13:50:07 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id b15so961717iln.3 for ; Thu, 27 Feb 2020 13:50:07 -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=ozomyOuqgRBgs4b9MO2SkPnhjjw0Q2hVmMJocla+78Y=; b=VSiMhYbYQHbZ9VPsN6lkbET/fG/ptUj7S05oo/96qk6+fuCi7KeFQcbb5LJpGn+/eF upz82E+lb+FQ88TF74E0LySVTnsYNdSY/9DAzveiHQVMpeU+wWyiwml5rmwoo/iIlpwk iAv9bc9Bv5JPWVtDpeNbwoHLoTlsCYn6jmiDQ= 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=ozomyOuqgRBgs4b9MO2SkPnhjjw0Q2hVmMJocla+78Y=; b=TNIWASYnh99ZSHLCbZhvEJskOCQgIXmEcKkjnrHgYeCTSCGDDYIfHYx3pvgx2xmUJ3 OERkpMU3hQBWDEKY1H5ZbTAJ8hUZJDYvnpoXEeM/Waht20u57ryeZuFjFVXe105zjDno NDEIbNZjDDuVKycCrhpKQnQ5ihm7sa/GB16elzECE7NxN0I+vNa22YYfdFUhOrVKbQB+ 60717U285jDxZ9SGNdmqa6APovHfowxfnyS1YtE2fizJ3RmMnG9XbUzFePfsMSzKwba2 2tSPzIVTujVXQbhQPlIqy2Chdr6xDAPgrSRrYQT2hgvkYjSJU85bVsRAmVzcmCoJTZ// I4MA== X-Gm-Message-State: APjAAAXOLr04JSWPWLaq8pJy5cBnUZEzQeFRjbOg4TDqGMrPoZCJeSH9 x1EBBOTqx0q8mrHfeki5SFiQe8N+TKdPkgSrSYlMbgbDML4= X-Google-Smtp-Source: APXvYqwflEQyBiEWJQZDVAtX2kY7Z1oVB5nsTHG0MtzZaO4aLNM9ff1vrRbF60PlJFx+5PwebQ148ry2tyEWFWb+59M= X-Received: by 2002:a92:b506:: with SMTP id f6mr1364882ile.103.1582840205903; Thu, 27 Feb 2020 13:50:05 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> <281fcc15-049c-b586-8514-0322cd0578c6@tana.it> In-Reply-To: <281fcc15-049c-b586-8514-0322cd0578c6@tana.it> From: "Kurt Andersen (b)" Date: Thu, 27 Feb 2020 13:48:59 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000035a812059f95b44f" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Thu, 27 Feb 2020 21:50:09 -0000 --00000000000035a812059f95b44f Content-Type: text/plain; charset="UTF-8" On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely wrote: > On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote: > > > > With a completed (and now seven month old) Working Group Last Call on the > > PSD document, and as far as I can see no sustained objection, we should > > proceed toward publication. > > Great! > +1 > I will put this question to the working group: Can we solve this problem > by > > switching the document to Informational status, and can the working group > > accept that outcome? > > If publishing as experimental would further delay publication, I'd accept > informational. > Also agree. --Kurt --00000000000035a812059f95b44f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 27, 2020 at 4:16 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote: >
> With a completed (and now seven month old) Working Group Last Call on = the
> PSD document, and as far as I can see no sustained objection, we shoul= d
> proceed toward publication.

Great!

+1=C2=A0

> I will put this question to the working group: Can we solve this probl= em by
> switching the document to Informational status, and can the working gr= oup
> accept that outcome?

If publishing as experimental would further delay publication, I'd acce= pt
informational.=C2=A0=C2=A0

Also agree.<= /div>

--Kurt=C2=A0
--00000000000035a812059f95b44f-- From nobody Thu Feb 27 14:13:56 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A943A0D71 for ; Thu, 27 Feb 2020 14:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BucstD11dnqY for ; Thu, 27 Feb 2020 14:13:53 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0: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 4D0293A0D6B for ; Thu, 27 Feb 2020 14:13:53 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id l12so848240oil.9 for ; Thu, 27 Feb 2020 14:13:53 -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=iD/IbtAwMmmJkz4xLxGzypxRtLXqzF+iIzEmudzI2dU=; b=iRAvz3v1AgkSY7bPyMSl9IwQU0fKhvxVUQnUoALuBXHQomFnhrOkAleehDyNCq4Roe aWo9pcwVTlbV8L7OgILrfqbRrn2d+fkY1xTaG5qg24i2d6JeiL+VMFVqMzm0UCtz5CQy rnQMvO7eRCF7eHTR3Rwp4TDtj8P1aqW7b9E5vEpmTIQ7IDLb7vILLzwIqr2INf0QmcyJ CIxQ3nbgC/Q4x2P9KvbkoR6H2OjHmEQqrUlMjdBNv7b+R8V9FdgffozY3cxIUSakLEut yHsPhREF2A8uAEEyZHoTh8jLHlxWJ9XcIwWy0dqsu2mWV6utJcVi2xUUL+OT06SsD7rS qZpg== 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=iD/IbtAwMmmJkz4xLxGzypxRtLXqzF+iIzEmudzI2dU=; b=WFvgaZdbRUUqnzh5jc6AhZ7ivGNhXaYXI3taoMxr7yvv8zYWQHZCITlr/xAHazdQM0 8TKFnn3GhT4TY94cMLn2IvHv5hHiDppYI6sVIW7zqk1V4RhXCp86b2cKLdKBfiuM25vO dNPhZ4I04C2Jn29lCWIuShSGkpSIBtSdPnPgEKjnHLJEmBgKqgoURKFPazhwmV0wE4ol AsMmCh94vVIFdXuNZ3PHbWIIUqZd5YBCkTOIICSQ2HFjby33wU1RcEpfpJxpWk+jNyCw 0tn1gQ31A6TS7G3VN+W2+o51JRlDjzyCf5Zdyn95IUKP6hrd8HGgtRxxzPzpJoq09PFo 6iMw== X-Gm-Message-State: APjAAAUPzEE8AfJcKbb0w9K6aXjJtRHS2OuqWwFIFdo93gg7FatsILKJ nASuP/YyeaaeOoSbc8i3sLuKAeIdxM4TZGU7SYX7fA== X-Google-Smtp-Source: APXvYqyHeq3nxQLyoHVLBFQKJuQ6cENJvXvQcsxT8tmaA0GBMCUMYwMLLYpmzDk8rMgWizLVQ0Gw33WfpU7J3SF24qQ= X-Received: by 2002:a05:6808:a8e:: with SMTP id q14mr854100oij.173.1582841632388; Thu, 27 Feb 2020 14:13:52 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> <281fcc15-049c-b586-8514-0322cd0578c6@tana.it> In-Reply-To: From: Tim Wicinski Date: Thu, 27 Feb 2020 17:13:41 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003bf93a059f9609ec" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Thu, 27 Feb 2020 22:13:55 -0000 --0000000000003bf93a059f9609ec Content-Type: text/plain; charset="UTF-8" Informational works for me if that helps moves things forward. I also agree with Mr. Crocker's thesis on teasing about the PSL from DMARC, but that should not hinder forward progress on PSD. tim On Thu, Feb 27, 2020 at 4:50 PM Kurt Andersen (b) wrote: > On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely wrote: > >> On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote: >> > >> > With a completed (and now seven month old) Working Group Last Call on >> the >> > PSD document, and as far as I can see no sustained objection, we should >> > proceed toward publication. >> >> Great! >> > > +1 > > > I will put this question to the working group: Can we solve this problem >> by >> > switching the document to Informational status, and can the working >> group >> > accept that outcome? >> >> If publishing as experimental would further delay publication, I'd accept >> informational. >> > > Also agree. > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000003bf93a059f9609ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Informational works for me if that helps moves th= ings forward.

I also agree with Mr. Crocker's = thesis on teasing about the PSL from DMARC, but that should not hinder forw= ard progress on PSD.=C2=A0

tim




On Thu, Feb 27, 2020 at 4:50 PM Kurt Anderse= n (b) <kboth@drkurt.com> wrot= e:
On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely <= vesely@tana.it> = wrote:
On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wro= te:
>
> With a completed (and now seven month old) Working Group Last Call on = the
> PSD document, and as far as I can see no sustained objection, we shoul= d
> proceed toward publication.

Great!

+1=C2=A0

> I will put this question to the working group: Can we solve this probl= em by
> switching the document to Informational status, and can the working gr= oup
> accept that outcome?

If publishing as experimental would further delay publication, I'd acce= pt
informational.=C2=A0=C2=A0

Also agree.<= /div>

--Kurt=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000003bf93a059f9609ec-- From nobody Fri Feb 28 00:57:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4703A137A for ; Fri, 28 Feb 2020 00:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mimecast.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 XprJLEOh42JI for ; Fri, 28 Feb 2020 00:57:43 -0800 (PST) Received: from eu-smtp-1.mimecast.com (service-alpha-uk.mimecast.com [91.220.42.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3029D3A1376 for ; Fri, 28 Feb 2020 00:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mimecast.com; s=20130419; t=1582880260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gXsOJ5IlmrImLeryL2x9aujmbT7Iy6C4K+RTybzXXnk=; b=XmJ2tAqsFlA0FOPXtteP8ZJjScSCoa5+Plh4o5J7h8mMXmrChr/LyIS3l+iWaHz+i8cFH/ DwrpH8eNLV4qYJf0jRKt2i9zJHAJQcHIeIIaDZ1QEz/lU8gIkw75GIeW2hhTW7g3NqlNWM QYyRu30h6rd66khbA4xdstFm+1CbGao= Received: from mail.mimecast.com (45.91.17.200 [45.91.17.200]) (Using TLS) by relay.mimecast.com with ESMTP id uk-sl-b-hzJYb9JuMOqwf1xXimJuzw-1; Fri, 28 Feb 2020 08:57:37 +0000 X-MC-Unique: hzJYb9JuMOqwf1xXimJuzw-1 Received: from MC-BHC-EXCH1.mcsltd.internal (172.16.26.23) by MC-LHC-EXCH1.mcsltd.internal (172.17.26.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Fri, 28 Feb 2020 08:57:35 +0000 Received: from MC-BHC-EXCH3.mcsltd.internal (172.16.26.25) by MC-BHC-EXCH1.mcsltd.internal (172.16.26.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Fri, 28 Feb 2020 03:57:32 -0500 Received: from MC-BHC-EXCH3.mcsltd.internal ([fe80::71ed:4757:af14:a04]) by MC-BHC-EXCH3.mcsltd.internal ([fe80::71ed:4757:af14:a04%18]) with mapi id 15.01.1779.007; Fri, 28 Feb 2020 03:57:32 -0500 From: Martijn van der Lee To: "dmarc@ietf.org" Thread-Topic: Typo in draft-ietf-dmarc-psd Thread-Index: AQHV7hUcyFFDkr9jokyAHPpDVsvyaQ== Date: Fri, 28 Feb 2020 08:57:31 +0000 Message-ID: <40CD84EC-7DA0-498E-B2D6-1A8BA6996DD4@mimecast.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.26.71] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mimecast.com Content-Type: multipart/alternative; boundary="_000_40CD84EC7DA0498EB2D61A8BA6996DD4mimecastcom_" Archived-At: Subject: [dmarc-ietf] Typo in 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: Fri, 28 Feb 2020 08:57:45 -0000 --_000_40CD84EC7DA0498EB2D61A8BA6996DD4mimecastcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Q2hhcHRlciA1IG9mIHRoZSBjdXJyZW50IGRyYWZ0IGNvbnRhaW5zIGEgdHlwbyBpbiB0aGUgd29y ZCDigJxzdWNlc3NmdWzigJ0gKHNpYykuDQoNCnAucy4gSXMgdGhlcmUgYW55IG90aGVyIHdheSBv ZiByZXBvcnRpbmcgc3VjaCBpbmNvbnNlcXVlbnRpYWwgaXNzdWVzIG90aGVyIHRoYW4gYm90aGVy aW5nIHRoZSBlbnRpcmUgbGlzdCBsaWtlIHRoaXM/DQoNCktpbmQgcmVnYXJkcywNCk1hcnRpam4g dmFuIGRlciBMZWUNCg== --_000_40CD84EC7DA0498EB2D61A8BA6996DD4mimecastcom_ Content-Type: text/html; charset=UTF-8 Content-ID: <78FCFF394DA309409F92405C928D9006@mimecast.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhcHRlciA1IG9mIHRoZSBj dXJyZW50IGRyYWZ0IGNvbnRhaW5zIGEgdHlwbyBpbiB0aGUgd29yZDxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+IOKAnHN1Y2Vzc2Z1bOKAnSAoc2ljKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+cC5z LiBJcyB0aGVyZSBhbnkgb3RoZXIgd2F5IG9mIHJlcG9ydGluZyBzdWNoIGluY29uc2VxdWVudGlh bCBpc3N1ZXMgb3RoZXIgdGhhbiBib3RoZXJpbmcgdGhlIGVudGlyZSBsaXN0IGxpa2UgdGhpcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1hcnRpam4gdmFuIGRlciBMZWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_40CD84EC7DA0498EB2D61A8BA6996DD4mimecastcom_-- From nobody Fri Feb 28 08:38:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340263A1B3C for ; Fri, 28 Feb 2020 08:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QhM44Fi7e2-e for ; Fri, 28 Feb 2020 08:38:27 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 A83A73A1B25 for ; Fri, 28 Feb 2020 08:38:12 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id h5so1366615vsc.4 for ; Fri, 28 Feb 2020 08:38:12 -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=Nf8fM6mjzxlLRy0z/RMOMk29LzX5y3hVnLVMN+ZhNf0=; b=YKTXz0jjVskhFndIC4LW1ww8QkLOwDCvcuXQX0wDULuMZVN9L5rgtxaF/NUZ96AAEV GScXQ1EyKLaJJ2a4t2spMyQO8sS6vK+9uufsGf91nz2rUUIGwvTpFJlBwgGhngVe7Z7X Ww7F7ah7VTdNi3r9f6SDFcgC3odP9PaVOH+OQPDlI8PP/JFTkx5TsFkYYMFxH9Pl5s6+ ZPiCRux9D/1kV4ImT2AO12eGWLhsLiWsau29yjz+6LUCdKTsxgtKbboXs1YrCQfhJJPd lcnO6LUcnYm5l8YQR81zUfOFjG0ZptrkkKKOKMXiDGN307R9vg5VlrraWKnnCIxHZhT+ f3Og== 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=Nf8fM6mjzxlLRy0z/RMOMk29LzX5y3hVnLVMN+ZhNf0=; b=fvqw+vIE6UnlY4vF10vhygBuf22L/9tfLET2gNNdfmNDgeZuZg7M6QxdlV4sqxChF0 WDyYuu3RJMuWEVSJkQ3hNOR4RTcgSKnyH/LvuFZ2enD9m+hiQP9wHrIQv8V4M+4zVxyY cxsjPNeUJSzFyHtypsv3zNa9Au7GADblHwSkYd80X2S4RDDP48bJodW/OPJm6vfBxGf/ fKLolt2KMBJg45o8/JodwvlwJaFQGSWDha+ly7WxbT/rxy3pQugD3uCJbTOXu8NBIbUc mGX9Qy3nL30FM/dxUiMBXXZ2ioTIXl2x7iIhrKXdH7iNDX7bg+/SNjRsYqm6tF7KCZXe p/zw== X-Gm-Message-State: ANhLgQ0Vbm6YPsOEYZyovwCrwD1bPLrLSKR7O65GXLAHpCx7G/vpTgrE lIfRvU7Z+1eQ/Mput2jA07D3c9S+g/aGUUG6KwM= X-Google-Smtp-Source: ADFU+vu+gZbWtRC5DsUAmW+uorcDc/kHQpwNsT1TJOqo7ufJy+hSjCfaiOjKkaXw1dH1X3RtJ5ptRJoMBhnoDxSH4ws= X-Received: by 2002:a05:6102:3235:: with SMTP id x21mr2948976vsf.8.1582907891628; Fri, 28 Feb 2020 08:38:11 -0800 (PST) MIME-Version: 1.0 References: <40CD84EC-7DA0-498E-B2D6-1A8BA6996DD4@mimecast.com> In-Reply-To: <40CD84EC-7DA0-498E-B2D6-1A8BA6996DD4@mimecast.com> From: "Murray S. Kucherawy" Date: Fri, 28 Feb 2020 08:37:59 -0800 Message-ID: To: Martijn van der Lee Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000097be31059fa57644" Archived-At: Subject: Re: [dmarc-ietf] Typo in 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: Fri, 28 Feb 2020 16:38:38 -0000 --00000000000097be31059fa57644 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You could email the author(s) directly. On Fri, Feb 28, 2020 at 12:57 AM Martijn van der Lee wrote: > Chapter 5 of the current draft contains a typo in the word =E2=80=9Csuces= sful=E2=80=9D > (sic). > > > > p.s. Is there any other way of reporting such inconsequential issues othe= r > than bothering the entire list like this? > > > > Kind regards, > > Martijn van der Lee > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000097be31059fa57644 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You could email the author(s) directly.

On Fri, Feb 28,= 2020 at 12:57 AM Martijn van der Lee <MvanderLee=3D40mimecast.com@dmarc.ietf.org> wrote:

Chapter 5 of the current draft contains a typo in th= e word =E2=80=9Csucessful=E2=80=9D (sic).

=C2=A0

p.s. Is there any other way of reporting such = inconsequential issues other than bothering the entire list like this?

=C2=A0

Kind regards,

Martijn van der Lee

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000097be31059fa57644-- From nobody Sat Feb 29 11:06:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18FB3A1152 for ; Sat, 29 Feb 2020 11:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xRv8RLnwXJzj for ; Sat, 29 Feb 2020 11:06:22 -0800 (PST) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 8A4B83A1151 for ; Sat, 29 Feb 2020 11:06:22 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id 94so275497uat.0 for ; Sat, 29 Feb 2020 11:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CfWtgedhzvcGvF+DdwlADBacj7ZpVw5fDMy3JuvwmC8=; b=PRmNulhAcujPltMFZulJBRZCREiVn9fFQpksMEVDbuG3D0j7RFhk8tWNTx/BUsmT7g 81ZSFHVExetFM3HEPh3cRIWI8p89ZBkoDWWgEJ6bKWXM4Emkhyc9FoBoCSBFxI2pIVpE VfiogdhA72+MIwMMV/VC8GHfV78sT2TOVY6zvhsV589lNX0Y5RmgmJekJAb7DqQGIgSv UGi9u2EfbddqwY/miz1E133kn/IUA+/I4/LqFUur6+SUvuOxBUnF31vVGsxC0b7XI5vB ZvpKFBixWT7gJkMJAEzRa5ZI1JHNj9SlcdTem9nF3Uy2tAFgOTGEGLQNapIqINQMSd9I YI6w== 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=CfWtgedhzvcGvF+DdwlADBacj7ZpVw5fDMy3JuvwmC8=; b=JjrLuuxxrGTYuRGJMahTIlrnalONJYKBd+uuqZBxhWhOOuGFjapSFxZi4DnkfM4zyQ rIB/1cGhoGl9jp/YDkkEVOTM31LzZUrApaAXyfPiiO2eyJui60vrHKg8uO5hZy6QXoUB 9J8/NVpCFVunXh9XG2iF6RxhTLz4BxO2Yj7/Wel4Xuqm3btY1tJ+mpM4l5RK1Vkyn4CI WK26IM0SxMt7ov1KU9dQ7/lL+L0RgroWtJ3DsJTs19NCgexyTjJ2Geveiy35BSQGswpG f1xzZZ6coKtgEBrdPakSBqiBkqDC/zeWV5vnJs49amWfkjSq9ooAo3wh1RPE7wIE9iUJ qkNA== X-Gm-Message-State: ANhLgQ3WOtwYcywdNZIOU/QGlksY+xWJvrv6c9pUYW3WULmFseKL+7n+ i9VlcDJ5ICJnSNJw1UouFnZ6aFWduqyz4rtfe5GSZ0oR X-Google-Smtp-Source: ADFU+vtYikTZr6tA6N5Ph2m9GSGjB2jruN6M55H/EwWgZ6Syh5CdKvw+kaz7UxGI3Xg9n73smvYyxX5Mm6vQ6WqIEUo= X-Received: by 2002:ab0:432:: with SMTP id 47mr3421695uav.67.1583003181429; Sat, 29 Feb 2020 11:06:21 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Sat, 29 Feb 2020 11:06:08 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004eb9ea059fbba69d" Archived-At: Subject: [dmarc-ietf] A tweak to 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: Sat, 29 Feb 2020 19:06:24 -0000 --0000000000004eb9ea059fbba69d Content-Type: text/plain; charset="UTF-8" It occurs to me on review that this draft refers to Organizational Domain, and probably some other terms, without defining them or expressly importing them from RFC7489. In particular Section 2.3 refers to the OD with no prior definition. Maybe: Insert a new Section 2.2 (pushing others down) that explicitly refers to RFC7489 Section 3.2, or more generally points out that this document uses terms defined in that one. This doesn't have to be done now; Scott, you can wait until IETF LC has ended if you like, unless you have other nits pending to be posted. -MSK --0000000000004eb9ea059fbba69d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It occurs to me on review that this draft refers to O= rganizational Domain, and probably some other terms, without defining them = or expressly importing them from RFC7489.=C2=A0 In particular Section 2.3 r= efers to the OD with no prior definition.

Maybe: I= nsert a new Section 2.2 (pushing others down) that explicitly refers to RFC= 7489 Section 3.2, or more generally points out that this document uses term= s defined in that one.

This doesn't have to be= done now; Scott, you can wait until IETF LC has ended if you like, unless = you have other nits pending to be posted.

-MSK
=
--0000000000004eb9ea059fbba69d-- From nobody Sat Feb 29 11:09:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86E3A116E for ; Sat, 29 Feb 2020 11:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OKGg-qEHUHBz for ; Sat, 29 Feb 2020 11:09:32 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 2CC4C3A116A for ; Sat, 29 Feb 2020 11:09:32 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id h5so3147651vsc.4 for ; Sat, 29 Feb 2020 11:09:32 -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=Hu9tmnLbo5/2sUreKnwzhXExw4aZkjBJgq3GF/f3IFs=; b=VNYzpyYOOEGXgP97JSJeBOYMXOyJp/qxsNNTatd2LfAvgz72lbEMAVe9iMUKi6zTHO 6ckgghQW26EyhFpTP648siml708pFZEGUyzwmXBUKr92PwIS0eKqBzo0etCMGEDBBvCR YrcAUatTvKK+Jib4xRMSA0yRyO7tgIIb1QKAZNA5ROnl3UBlJI0w0Sm7z5KaI1VNjXJU 4BHr6VXCBqpqglMaTDYnmYoYAmB5DT2ZJEvUfDECOfX273Wm7LHirxDeT9ZlyRg5aoX7 BY9Z2zMpdhFYmGA61wlMU00/PTOPxVSKdTqwys/gTgCM8tb6An78OXoBbdG56Hao5bYJ +RMQ== 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=Hu9tmnLbo5/2sUreKnwzhXExw4aZkjBJgq3GF/f3IFs=; b=ldGOzRdEa6VF3xajzzB+twnY1x/1z4SgwGXdCa8IANXAxDC3PxWh1l9OxPgj72B4lq Jo0XUii8IBn5kOk+NBo+SqjRbzffxLXCCoCQqv4acD8OLBmuTOQW02WNa9HO9kDdVE3q g21fJyY4RgKm7RuLa5yHp/TJ4la5QE1ssbnCrwziY3Po9cnZzX5ir9Zht4Nzv5l6UhdA G9iAqk7bW2ruhiVTrsiEtyKFuWb5XHfWSwiirr7OmixHn/peZx9YWIntns0unlFcZE+a H3rE1ljK8ILUaiw4sDhir4t4hx1wZZArozdnPACZf2TPOb8tonJjeJsi/8p+tcRLYyra BXcQ== X-Gm-Message-State: ANhLgQ3wWRYtJ9zi5PDAy4Gt9pCnG3hWclZFcVoP06DMmqE2nGbNfOJG LrYdakTS2aj5/oau7zy42cd2698zker8K+GJqKs= X-Google-Smtp-Source: ADFU+vv3ZWKLMvDCG9YGslUL//LlD3uYQmpObp1TQdkyOSHEWsh0TMX9/+nmIusOQ7jrYnToIwvs73gLMbjhIjcCCyo= X-Received: by 2002:a05:6102:376:: with SMTP id f22mr5558054vsa.175.1583003371034; Sat, 29 Feb 2020 11:09:31 -0800 (PST) MIME-Version: 1.0 References: <5E4009C1.3070201@isdg.net> <96161f11-db74-4064-99fb-0dae7c43b716@www.fastmail.com> In-Reply-To: <96161f11-db74-4064-99fb-0dae7c43b716@www.fastmail.com> From: "Murray S. Kucherawy" Date: Sat, 29 Feb 2020 11:09:16 -0800 Message-ID: To: Alexey Melnikov Cc: Hector Santos , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009bdc5f059fbbb192" Archived-At: Subject: Re: [dmarc-ietf] Upcoming personnel changes 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, 29 Feb 2020 19:09:34 -0000 --0000000000009bdc5f059fbbb192 Content-Type: text/plain; charset="UTF-8" I'm not the current author of any DMARC documents in any case, and I'm happy to leave DMARCbis to new blood. On Mon, Feb 10, 2020 at 8:01 AM Alexey Melnikov wrote: > Hi Hector, > > On Sun, Feb 9, 2020, at 1:31 PM, Hector Santos wrote: > > Congratulations. The IETF will be enhanced with your new assignments > > and roles. > > > > How will this affect the future and editorship of DMARCbis? I wonder > > if there could be a "conflict of interest" concerns. > > In cases when an Area Director [co-]edit a document another Area Director > is typically in charge of document shepherding/judging consensus. > > Best Regards, > Alexey > > > Thanks > > > > -- > > HLS > > > > On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote: > > > Colleagues, > > > > > > We have some personnel changes to announce. First, we would like to > > > thank Tim Wicinski for stepping in to co-chair DMARC with me. Going > > > forward he will be focusing on his duties with DNSOP and other IETF > > > work and is still, of course, welcome to participate here. For the > > > next couple of months, I will be going it alone. > > > > > > Second, I have been appointed by the NomCom to a two year term as ART > > > Area Director. Alexey Melnikov and Adam Roach are finishing their > > > terms in March at the Vancouver meeting, and the IESG has elected to > > > close one of those positions. I will assume that role at the March > > > meeting. Barry Leiba still has a year left in his current term as the > > > other ART AD. > > > > > > Accordingly, at that time, Alexey and I will effectively trade roles: > > > He will become DMARC chair and I will become its supervising Area > > > Director, while we consider our options for assigning a co-chair to > > > carry the load with him. So nothing changes until March, but we > > > thought it appropriate to advise the WG of the plan ahead of time. > > > > > > -MSK, still chairin' for now > > > > > > > > > _______________________________________________ > > > 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 > > > --0000000000009bdc5f059fbbb192 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not the current author of any DMARC documents in a= ny case, and I'm happy to leave DMARCbis to new blood.

On Mon, Feb 1= 0, 2020 at 8:01 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Hector,

On Sun, Feb 9, 2020, at 1:31 PM, Hector Santos wrote:
> Congratulations. The IETF will be enhanced with your new assignments <= br> > and roles.
>
> How will this affect the future and editorship of DMARCbis?=C2=A0 I wo= nder
> if there could be a "conflict of interest" concerns.

In cases when an Area Director [co-]edit a document another Area Director i= s typically in charge of document shepherding/judging consensus.

Best Regards,
Alexey

> Thanks
>
> --
> HLS
>
> On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote:
> > Colleagues,
> >
> > We have some personnel changes to announce.=C2=A0 First, we would= like to
> > thank Tim Wicinski for stepping in to co-chair DMARC with me.=C2= =A0 Going
> > forward he will be focusing on his duties with DNSOP and other IE= TF
> > work and is still, of course, welcome to participate here.=C2=A0 = For the
> > next couple of months, I will be going it alone.
> >
> > Second, I have been appointed by the NomCom to a two year term as= ART
> > Area Director.=C2=A0 Alexey Melnikov and Adam Roach are finishing= their
> > terms in March at the Vancouver meeting, and the IESG has elected= to
> > close one of those positions.=C2=A0 I will assume that role at th= e March
> > meeting.=C2=A0 Barry Leiba still has a year left in his current t= erm as the
> > other ART AD.
> >
> > Accordingly, at that time, Alexey and I will effectively trade ro= les:
> > He will become DMARC chair and I will become its supervising Area=
> > Director, while we consider our options for assigning a co-chair = to
> > carry the load with him.=C2=A0 So nothing changes until March, bu= t we
> > thought it appropriate to advise the WG of the plan ahead of time= .
> >
> > -MSK, still chairin' for now
> >
> >
> > _______________________________________________
> > 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
>
--0000000000009bdc5f059fbbb192-- From nobody Sat Feb 29 11:16:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2B3A118B for ; Sat, 29 Feb 2020 11:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1huVrm8hgjL5 for ; Sat, 29 Feb 2020 11:16:40 -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 53AA63A1187 for ; Sat, 29 Feb 2020 11:16:40 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id r16so6343023oie.6 for ; Sat, 29 Feb 2020 11:16: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=YajrYGeXwcrNWjng1cCEDahVFnn+R6QUrvqeVaG5BvI=; b=moCgVaHdA0dpB41mN58ek9abQw3jtodKGx/Q7iBIdelFEEr0ESwndJ+UnYGrmTMQQP Ru6q1icbdQqco9gJG34J3yQP4QIbM3CSWygex/9oJXG7J8fMoJCzxLVkoFrDWWYvC3dd H433Jx1lXtoiEcliCbeB3cuiQh0R8i9K8cQ5Mp/O/ULmNVNmy8YPegC1bvsApFN9UH0N 7BRH2xMvc9rwmcaK9bL4hhNZ4FgDiRZ5DwItJLBn7EwChE5XI31pEIVfWLMl3RV5smIT CXNIdWPFKT8AYGvnaW5+ETnOIll3tsAbvWf0Rx8uKkCxR1y3u9QXGXnErlgILwQ/FxJ5 9mDA== 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=YajrYGeXwcrNWjng1cCEDahVFnn+R6QUrvqeVaG5BvI=; b=b8/izfCuNk9GwTqxKfdK0xgtOf0FABtkIBGSWWnXrp0ssY5sGAONBAfi1I3A5ZJBwi 84UCeK4A1S6XL93Z+rx/sXdvLVVrBCAmG9zx1P+NwTp14/uUiQnmtmLp1j6eK85OFy9d 2FPB35ZpbylZ9gRsG4Xo1ImKXveOWZwSIFDDvgFzkn1sLVrXhN7xXd0nsEMoMpJR0Deq +MqG1p96VWp1M+kI0LzeTmRKaNUMZ/MbpVhJsrYNGtXGr5R/FYWGeNx54LqcStDMpCAM he+p6VOzVN6ESWPwAC5v2+MfeltN9kKHcJCH0QC6oqVpssOSqztrstnnXjt3suL000kS dEHg== X-Gm-Message-State: APjAAAVwQ0ISAuf8nbD2B1EKKHLlHKXTW8eSjEa2loQtMHQE8aZImI9P wFTykYlpHIKFJC3fXW44t+zMf6H01aEfDfH6qZdbTVS/ X-Google-Smtp-Source: APXvYqwBI/cw3q1QdW3G120XP5c2XVBpvren7Cs04c/MUqVt2oOp5kTCf/Asq56FNLl2cqj9iDfAqy1CBCLFR5kPYIY= X-Received: by 2002:a54:4f16:: with SMTP id e22mr7241577oiy.170.1583003799780; Sat, 29 Feb 2020 11:16:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Sat, 29 Feb 2020 14:16:28 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002a0146059fbbcb7f" Archived-At: Subject: Re: [dmarc-ietf] A tweak to 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: Sat, 29 Feb 2020 19:16:42 -0000 --0000000000002a0146059fbbcb7f Content-Type: text/plain; charset="UTF-8" If we're going down the road of definitions, RFC8499 defines what a "Public suffix" is https://tools.ietf.org/html/rfc8499#page-28 Which could assist in the Public Suffix Domain definition here. If this makes sense, I can offer some suggested text On Sat, Feb 29, 2020 at 2:06 PM Murray S. Kucherawy wrote: > It occurs to me on review that this draft refers to Organizational Domain, > and probably some other terms, without defining them or expressly importing > them from RFC7489. In particular Section 2.3 refers to the OD with no > prior definition. > > Maybe: Insert a new Section 2.2 (pushing others down) that explicitly > refers to RFC7489 Section 3.2, or more generally points out that this > document uses terms defined in that one. > > This doesn't have to be done now; Scott, you can wait until IETF LC has > ended if you like, unless you have other nits pending to be posted. > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002a0146059fbbcb7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If we're going=C2=A0down the road of definiti= ons, RFC8499 defines what a "Public suffix" is=C2=A0
https://tools.ietf.or= g/html/rfc8499#page-28

Which could assist = in the Public Suffix Domain definition here.=C2=A0=C2=A0
If this = makes sense, I can offer some suggested text

On Sat, Feb 29, 2020 at 2= :06 PM Murray S. Kucherawy <super= user@gmail.com> wrote:
It occurs to me on review that this dra= ft refers to Organizational Domain, and probably some other terms, without = defining them or expressly importing them from RFC7489.=C2=A0 In particular= Section 2.3 refers to the OD with no prior definition.

Maybe: Insert a new Section 2.2 (pushing others down) that explicitly= refers to RFC7489 Section 3.2, or more generally points out that this docu= ment uses terms defined in that one.

This doesn= 9;t have to be done now; Scott, you can wait until IETF LC has ended if you= like, unless you have other nits pending to be posted.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002a0146059fbbcb7f-- From nobody Sat Feb 29 11:19:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42E3A1192 for ; Sat, 29 Feb 2020 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dmXX58ug5l-7 for ; Sat, 29 Feb 2020 11:19:42 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 742F33A1168 for ; Sat, 29 Feb 2020 11:19:42 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id p6so4088463vsj.11 for ; Sat, 29 Feb 2020 11:19:42 -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=S7av2pQP07lSCMp3v4qI/IlmjVPkJnMwmpxoU1S+zKs=; b=u+c15yi86Oby2+K9JwdHOJv1/12LjMd/4dVBOt8wKar/dCrshIJjXIp95+VGP2m0eG XMFbW0W2o6VbUtEBdJndjSxatXLP1SEfAy8hlGjVlizmbPXheCTrNK+6fJQEhn49ijPh 5nwux8tuIhrx86YQe480M/PyEWzvYN78GtIW7O97GKJgHAJQkXjs96MqtuS/8sHtftZi eOg5qhvVTtOBnkmHwmIpVendBAVqVZG4p3y9L4ch+wG4/DwB7Ye99m1lVDFGmyI7zuVw YcWXxFBegOZtkXWSQ6WfkGmWWCOjtjkkl36OBONYShDYjNCjGTgYyKRJ13QvXIndhxMB Wu5A== 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=S7av2pQP07lSCMp3v4qI/IlmjVPkJnMwmpxoU1S+zKs=; b=rs1GNmgbJ3JSfKCwMROPOhtmgjvC1/r/GFZiz54Bj+anLxgYqQgv8i+rWIyPcfoGtM 2oVxZqypUP+Y0UzETqbH4zBLxaQ0v1NSNyz92urXrRMBgWl9lFHRrPMaxiP8pTj8SjNG tN1p8YNODmK8jT7MkhSGz7JjOqO8oe48UJQOZ9v8Fxu8RFAz0aJ4FgUlkZS5giIeRFT/ r9s8B3xRQEeXMUbACGoWkEW0C88oR6GlKW2391ZeZooB9IZQsI6i/qfDUC24GkSIzMcC P1KrQCWuot4GGrCp2MW4nh1ZZvvmLfzykvbXw4q5yI/PRyTTxS5h6FBTPitOkgOQyCzH 2ZMg== X-Gm-Message-State: ANhLgQ3y3AcITp66TGLI5jFy+5sPamH0JpRImoeQISNlEYRXfvoThfwl Ymk5LIHaVNOgDQggT3fRV9DwztlTh4D+b9Tsx48= X-Google-Smtp-Source: ADFU+vucHdg8AdVIwcuQ7ZyyHisP9MCTRmbWBU6CoyVIaIhulTYsMj4nObQnSa+DhtoVkcd+d5RdWPv990H06Aim+iQ= X-Received: by 2002:a05:6102:376:: with SMTP id f22mr5573893vsa.175.1583003980605; Sat, 29 Feb 2020 11:19:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 29 Feb 2020 11:19:27 -0800 Message-ID: To: Tim Wicinski Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f130d9059fbbd510" Archived-At: Subject: Re: [dmarc-ietf] A tweak to 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: Sat, 29 Feb 2020 19:19:45 -0000 --000000000000f130d9059fbbd510 Content-Type: text/plain; charset="UTF-8" I'm ambivalent at this stage about whether this makes it into the PSD document, but please someone do add it to the queue for DMARCbis. On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski wrote: > > If we're going down the road of definitions, RFC8499 defines what a > "Public suffix" is > https://tools.ietf.org/html/rfc8499#page-28 > > Which could assist in the Public Suffix Domain definition here. > If this makes sense, I can offer some suggested text > > On Sat, Feb 29, 2020 at 2:06 PM Murray S. Kucherawy > wrote: > >> It occurs to me on review that this draft refers to Organizational >> Domain, and probably some other terms, without defining them or expressly >> importing them from RFC7489. In particular Section 2.3 refers to the OD >> with no prior definition. >> >> Maybe: Insert a new Section 2.2 (pushing others down) that explicitly >> refers to RFC7489 Section 3.2, or more generally points out that this >> document uses terms defined in that one. >> >> This doesn't have to be done now; Scott, you can wait until IETF LC has >> ended if you like, unless you have other nits pending to be posted. >> >> -MSK >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --000000000000f130d9059fbbd510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm ambivalent at this stage about whether this makes = it into the PSD document, but please someone do add it to the queue for DMA= RCbis.

On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

If we= 9;re going=C2=A0down the road of definitions, RFC8499 defines what a "= Public suffix" is=C2=A0

Which could assist in the Public Su= ffix Domain definition here.=C2=A0=C2=A0
If this makes sense, I c= an offer some suggested text

On Sat, Feb 29, 2020 at 2:06 PM Murray S.= Kucherawy <sup= eruser@gmail.com> wrote:
It occurs to me on review that this d= raft refers to Organizational Domain, and probably some other terms, withou= t defining them or expressly importing them from RFC7489.=C2=A0 In particul= ar Section 2.3 refers to the OD with no prior definition.

Maybe: Insert a new Section 2.2 (pushing others down) that explicit= ly refers to RFC7489 Section 3.2, or more generally points out that this do= cument uses terms defined in that one.

This doesn&= #39;t have to be done now; Scott, you can wait until IETF LC has ended if y= ou like, unless you have other nits pending to be posted.

-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f130d9059fbbd510-- From nobody Sat Feb 29 12:01:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DA23A134B for ; Sat, 29 Feb 2020 12:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rGb0pxxKsPQL for ; Sat, 29 Feb 2020 12:00:52 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 835EE3A1349 for ; Sat, 29 Feb 2020 12:00:52 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id a6so5891741ilc.4 for ; Sat, 29 Feb 2020 12:00: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=SwVpMym9tXEpEfzIDL5/mF7qh3PFtKwl/BB0K0+Izs4=; b=Gi1hfHHz0hDSCLv1CD13ufsFe+D5pEuoJt4Vw/diXZn7L7zfvgRZvxHsvjgIqAx0to XYMmVVJ7rA6Fudg7esC0lThqtPv1Wz9jS3PH2Tm5SaCuDJZKczmFx+6skURQUMallsTV EVhqj2lTQq5DU4mw0KPZrx5otsa/+D4njumOk= 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=SwVpMym9tXEpEfzIDL5/mF7qh3PFtKwl/BB0K0+Izs4=; b=NX6nZ0wZxUmv5vfmDc+ayyX8T6Wj9c6SCn/O2FfEFblhar7iNF4jzMY/p1kK6qswwx wrL5RMH8Gx3hnzCFn7VHhh0X8RkmF8I0p4jL5tZCcOFWwg0Uill25IErfWCzz0my7PrL FIGYWo/aYXauGojPcodCi0/Q7QNbCj1P5VkUlEKHGVfUqP3NMKv69YUaBUL6gK1yBvUc jRZuufRqnu93xqRFgWhaXpkyIkTpBOX+xmlPfjriVcs92f1J5OQEXvvlFtMedbzvU+xq i0iGnFAe8E/HQ3iyU0ZZznjxVR8Wzq0QvcYJUr1UEXokZxTJ74d1cuQY8+b3ulomWENq VIWg== X-Gm-Message-State: APjAAAUZaBvYOY1M7mcNFATYDsrSB9g38b/Tz022F8jINdc3PVXMu5w3 zm84ogYUxCMkm+XIXd0hmGHalctUA3FDYx9w49fQug== X-Google-Smtp-Source: APXvYqzXLDGNfAmYBa13jOQqbcUBtPrgg1vh0QYWCdA5fOx2sntT0kPEJg6VLjCByhtY1t/JvPTeTcoaY6YaZBAwdAQ= X-Received: by 2002:a92:b506:: with SMTP id f6mr10108876ile.103.1583006451615; Sat, 29 Feb 2020 12:00:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Sat, 29 Feb 2020 11:59:44 -0800 Message-ID: To: Tim Wicinski Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000039dba1059fbc696c" Archived-At: Subject: Re: [dmarc-ietf] A tweak to 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: Sat, 29 Feb 2020 20:01:01 -0000 --00000000000039dba1059fbc696c Content-Type: text/plain; charset="UTF-8" On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski wrote: > > If we're going down the road of definitions, RFC8499 defines what a > "Public suffix" is > https://tools.ietf.org/html/rfc8499#page-28 > > Which could assist in the Public Suffix Domain definition here. > If this makes sense, I can offer some suggested text > No, that does not help. RFC8499 just refers back to RFC6265 section 5.3 which in turn invokes the PSL - that's Dave's problem with DMARC in the first place. I think that Murray's suggestion about importing definitions from DMARC (RFC7489) makes much more sense than forking elsewhere since this is a riff on DMARC. --Kurt --00000000000039dba1059fbc696c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 29, 2020 at 11:16 AM Tim Wici= nski <tjw.ietf@gmail.com> w= rote:

If we're going=C2=A0down the= road of definitions, RFC8499 defines what a "Public suffix" is= =C2=A0

Which could assist in the Public Suffix Domain definition= here.=C2=A0=C2=A0
If this makes sense, I can offer some suggeste= d text

No, that does not help. = RFC8499 just refers back to RFC6265 section 5.3 which in turn invokes the P= SL - that's Dave's problem with DMARC in the first place.

I think that Murray's suggestion about importing defini= tions from DMARC (RFC7489) makes much more sense than forking elsewhere sin= ce this is a riff on DMARC.

--Kurt=C2=A0
--00000000000039dba1059fbc696c-- From nobody Sat Feb 29 15:43:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7103A15D8 for ; Sat, 29 Feb 2020 15:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, 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=M2x1/Oo8; dkim=pass (2048-bit key) header.d=kitterman.com header.b=lLHrhmYY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2K3NhkU692z for ; Sat, 29 Feb 2020 15:43:05 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5913A15D7 for ; Sat, 29 Feb 2020 15:43:05 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id B0C90F802C0 for ; Sat, 29 Feb 2020 18:43:03 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1583019783; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BT31zf6XtMFfLGYU0CUi+X3mWB44JZxuTzSmMq1O1cA=; b=M2x1/Oo8GSoQneoDWJi4N20d6cdyngu52v4E8w6A4xsU3ztEY/WMmZxCllU6DYxutmP54 gLB+WYMwkSl4irjBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1583019783; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BT31zf6XtMFfLGYU0CUi+X3mWB44JZxuTzSmMq1O1cA=; b=lLHrhmYYcp2BDaw6IwDw04gAq6wYq0Dwf8IBwaQ9oAGATridv/C7D2aDmFN28OLAdh8q+ HVurtE2KLLM40HT6yD6Z/eFd4vRfxAtABDNMY5iPObzD9YG/Eh7SS/nRwytCb19g+x3we2Q EbJuWv5NBMzMVZptCRIvpFqKa5XgdzCp+t8Nb6Y/7WvaVd8bNUuvTidYiz08ocNnDHLqJwu GA5KPAiHcJ5GVGDIWgzqk6BQAg6I0Ij2x9SZtEPKZIa7cxMk/f+qcjan9kARJO1tNs4RwQL rChdwyFAmh5uuLyR/dtoYxYufI9mpNs6WbppEq9OPnJyYYnN9s9hLLP/hI+Q== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 7DF52F801F5 for ; Sat, 29 Feb 2020 18:43:03 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 29 Feb 2020 18:43:02 -0500 Message-ID: <2284143.qfsaAzHM67@l5580> 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] A tweak to 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: Sat, 29 Feb 2020 23:43:07 -0000 On Saturday, February 29, 2020 2:59:44 PM EST Kurt Andersen (b) wrote: > On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski wrote: > > If we're going down the road of definitions, RFC8499 defines what a > > "Public suffix" is > > https://tools.ietf.org/html/rfc8499#page-28 > > > > Which could assist in the Public Suffix Domain definition here. > > If this makes sense, I can offer some suggested text > > No, that does not help. RFC8499 just refers back to RFC6265 section 5.3 > which in turn invokes the PSL - that's Dave's problem with DMARC in the > first place. > > I think that Murray's suggestion about importing definitions from DMARC > (RFC7489) makes much more sense than forking elsewhere since this is a riff > on DMARC. I think the only thing that might be missing is explicitly importing the term organizational domain from RFC 7489. I think it wouldn't hurt to add it, but I don't think it's needed. As early as the second sentence of the introduction the draft is discussing organizational domain and clearly in a DMARC context (even with an RFC 7489 reference). I don't think there's any real risk a reader of the draft would be confused. Scott K From nobody Sat Feb 29 15:47:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35C3A15F3 for ; Sat, 29 Feb 2020 15:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=1mn8BnH+; dkim=pass (2048-bit key) header.d=kitterman.com header.b=aycc4bjS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtq7F3kvoCgq for ; Sat, 29 Feb 2020 15:47:04 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D3D3A15EA for ; Sat, 29 Feb 2020 15:47:04 -0800 (PST) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 46E73F802C0 for ; Sat, 29 Feb 2020 18:47:03 -0500 (EST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1583020023; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=pazNeS9cVELQWZgoWCL+xHEHYcJk/6SE0agL/PfOjVk=; b=1mn8BnH+QzCkrDxXkS5rfM4hZ21sbWDOjkcFOTThlgEPXYKiabuzC53IA7dZGdZMJFewY 5y1pcJ1CM9I2AxvAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1583020023; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=pazNeS9cVELQWZgoWCL+xHEHYcJk/6SE0agL/PfOjVk=; b=aycc4bjSjmsjC4WwUL2nc4dw6RwzFrBNqisCMiwhbuCHBIKcqjxFEecv6VKEwaCywtJg6 zJTBTBVirGaT2JBJtVE7OvEUJWKKOYGSYO08IqsvUbq2ieflqdHL6W+6/T+PIEI//ZZqgHU HntkRYvSPhsH4tT7JkU98HQeuazFyafUxUIE0vsbHKaEVbWQowo+Rfc+tQ6NzWSCKmainNy oxjRhnUt66iiClJ6VlGt9QE2FvV4O3qtlyaOpLkJSRxUbD0Vupzt7LF7EglAmXbfYKBZD9b Y4LuA40+lq2EzuAQs097radgckfNJw73Y8vH1DdWw9o0OEjxW5G5huXv51/w== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 1C7E0F801F5 for ; Sat, 29 Feb 2020 18:47:03 -0500 (EST) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 29 Feb 2020 18:47:02 -0500 Message-ID: <12785741.3Xnv7X5PKb@l5580> In-Reply-To: References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Comment on 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: Sat, 29 Feb 2020 23:47:06 -0000 On Thursday, February 27, 2020 12:30:59 AM EST Murray S. Kucherawy wrote: > On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz wrote: > > First, while I know you've said the needs of external actors won't weigh > > on your decision about moving forward, I would like to mention that > > having a stable reference for PSD DMARC will help us with working towards > > policy changes that would allow us to participate in this experiment. It > > may not be important to the WG Chairs' decision on the draft, but there > > are stakeholders for whom it is important. > > Just to be clear, I don't mean to suggest the restriction you're referring > to is invalid. I'm sympathetic to the idea that some potential > participants in PSD are constrained by policies outside of their control or > ours. But I look at it this way: A series of "X can't happen until Y > happens" assertions have been made over the last while, and the series is > roughly circular. I don't mean to be insensitive to the pain of you or > others under external constraints, yet at the same time, from the > perspective of the IETF, those constraints are very much external and thus > are easier to disqualify as we try (sometimes desperately) to find a way > out of this deadlock we're in. > > I will also be somewhat ashamed to hand Alexey a deadlocked working group > in March. :-) > > With my chair hat on, I'm leaning toward making the following consensus > evaluation: With a completed (and now seven month old) Working Group Last > Call on the PSD document, and as far as I can see no sustained objection, > we should proceed toward publication. Unless someone wants to argue that > this is not the WG's consensus, we'll proceed at the end of next week. > > To be specific: > > Dave raised a post-WGLC concern that DMARC and its use of the PSL really > ought to be teased apart. I have heard no objection to that, and in fact > have seen some support for it, so I consider that also to have consensus. > The part that does not appear to have consensus is that it is mandatory for > this to be done before the PSD work can proceed. > > Dave also suggested that Experimental status is not procedurally > appropriate for this work, and stated some reasons. There appear to be no > others lending support for this assertion either. However, while I > disagree, and I believe I gave an existence proof to the contrary, I will > put this question to the working group: Can we solve this problem by > switching the document to Informational status, and can the working group > accept that outcome? That seems an easy compromise, and I saw it proposed > but not fully discussed yet. This seems quite reasonable as well when one > considers that PSD's proponents could very likely get the thing published > as an RFC via the Independent Stream if they continue to find no progress > here. So, please discuss this option on the list and I'll measure > consensus on it at the end of next week as well when next steps are chosen. > > Mike objected to PSD generally, also long after WGLC completed. This too > does not appear to have swayed consensus. (And he's been cogitating on > that thread for a few weeks now...) > > As a reminder, we still need to do AD evaluation, an IETF-wide last call, > directorate reviews, and IESG evaluation before it lands in the RFC > editor's queue. As editor, I'm happy to update the draft to match whatever the chairs find as consensus. Personally, I think informational is fine. I'll wait for direction from the chairs before doing anything. Scott K Scott K From nobody Sat Feb 29 18:08:53 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4BC3A17BD for ; Sat, 29 Feb 2020 18:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IRri449TmFWA for ; Sat, 29 Feb 2020 18:08:52 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 EE05C3A17BF for ; Sat, 29 Feb 2020 18:08:51 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id c7so2393055uaf.5 for ; Sat, 29 Feb 2020 18:08:51 -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=zuJTbnXn5sZvPaQ0FCSaLQ+uBddE4UTu8Y+Z3SDbSmA=; b=kpG2ZU9Mhdyj/ZJ8i77hp7p/Q1ZbFkJuo2GPQ1Dsxb/c6yPEEoYwZZMw1SCALzflYw OvlZjmAGKxp9y/BTAAxRRYT7KXEMrfz+9jcmtirvloekEBAz7qxRav6HoTuJi4Rnetth lat0Nu2Ty8E2MH1pErZm7vTbeG9/1Aa79vIBvKorXGo3TfUlPgTe06oqYik5qm+3G5mf uev0a92M2yuvdp/lT3IhU+kl80kdqZubreyI2TLxsn+JnviEEryvUpZcK/N9UP4bow3q qIiXJI1GUWL1M3XOGoMMappD2FKN6ufqysP+X4sirz3KkFfhQkp7onQSTUtVD0NTR0W1 EdHw== 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=zuJTbnXn5sZvPaQ0FCSaLQ+uBddE4UTu8Y+Z3SDbSmA=; b=rNtSIM8ei7rm5t0DXD3o/RH6bMX4Lty4qSe6llZ3p8bEWBb3l+3n55vVuwtw1sN+p2 kRzegtsyrrh+jxjQ19pUL7SBRiH8nn0zRExSfTQDbHFEuIq3Qyzr8lhpracJNKKu6ui6 1Vr1rbfwBmiJPKimbn6mkmj5pp826vcTwgS5RAuVDDljAY7Pq46TffnK6eHh/mHb64QJ XguQsoltqLkE/1FC1Ta24DKpLUESQZlds4VgydJO5aU6R6iIrlN8rpE266/AmfjmycjV 4paUzGjEBDy7doyYKOn5QL8OZkTx8YXGs5ZkxrFkTlJFXbGZwli5VQ2D2nXNYXSCh7KK aB6w== X-Gm-Message-State: ANhLgQ18Ogn/CW15TzXfI9o0/oJDL0gXqjFsk1PIkvrd4FW3KfiZ9Oq6 GRswXT/Ss1p9QQQiCsl9guJubfaD8wgh/2lkw8ovXJ4p X-Google-Smtp-Source: ADFU+vuapYwfuta+12YKOeJsnvwAZh0oFuLbgu+kzOCBzBqmd9Z46UQUn9x6auJ8cr7LeefatCzX7m5ONAWPBD/Tfwg= X-Received: by 2002:ab0:432:: with SMTP id 47mr3992698uav.67.1583028530993; Sat, 29 Feb 2020 18:08:50 -0800 (PST) MIME-Version: 1.0 References: <2284143.qfsaAzHM67@l5580> In-Reply-To: <2284143.qfsaAzHM67@l5580> From: "Murray S. Kucherawy" Date: Sat, 29 Feb 2020 18:08:39 -0800 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000425ffa059fc18dbb" Archived-At: Subject: Re: [dmarc-ietf] A tweak to 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: Sun, 01 Mar 2020 02:08:53 -0000 --000000000000425ffa059fc18dbb Content-Type: text/plain; charset="UTF-8" On Sat, Feb 29, 2020 at 3:43 PM Scott Kitterman wrote: > I think the only thing that might be missing is explicitly importing the > term > organizational domain from RFC 7489. I think it wouldn't hurt to add it, > but > I don't think it's needed. As early as the second sentence of the > introduction the draft is discussing organizational domain and clearly in > a > DMARC context (even with an RFC 7489 reference). I don't think there's > any > real risk a reader of the draft would be confused. > OK, but I get to say "I told you so" if it comes up in a DISCUSS comment later. :-) -MSK --000000000000425ffa059fc18dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 29, 2020 at 3:43 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
I think the only thing that might be missing is expl= icitly importing the term
organizational domain from RFC 7489.=C2=A0 I think it wouldn't hurt to = add it, but
I don't think it's needed.=C2=A0 As early as the second sentence of= the
introduction the draft is discussing organizational domain and clearly in a=
DMARC context (even with an RFC 7489 reference).=C2=A0 I don't think th= ere's any
real risk a reader of the draft would be confused.
OK, but I get to say "I told you so" if it comes up i= n a DISCUSS comment later.=C2=A0 :-)

-MSK
--000000000000425ffa059fc18dbb--