From nobody Tue Sep 3 08:58:22 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18B1208F2 for ; Tue, 3 Sep 2019 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 o58WCHb-WfFj for ; Tue, 3 Sep 2019 08:58:12 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 699BA120829 for ; Tue, 3 Sep 2019 08:58:12 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id r17so8785170vso.1 for ; Tue, 03 Sep 2019 08:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nysGGpBiiu2Yz3koZ5feuOpzipzBFe2nHe1Y+sjmWCc=; b=m9p8pkpQ+Pb8vR8Fs3exS+eBuhqnlwI7ooI51HdidLz57dBlSgkYjKNO5j9+7d/tQb oMzB5zJQCGJfbMRXq7fkuyD6biK6TjlrNeRLF8JkZtVB/kvU3ot6Uv7AgFwf1lmLH1UT +hKHUa9Qa1r5tLOwANCf2+Lg1j1aIEwhYi7+E7ElBfOLWA61nHY7Be+bKqABYpQPg81L VLbVkVDw1GeF0+F5rVlmi0Q33e3FZlDIKanYPQVa4x6czax2kwSwEQIW7z2bXBDrk2uk xFgqVp+oYg4bNaTHbhrXaQj9bXDmBDSd0UK9PtwKdAJUpNTud711OhyhZY4nwjlUi1W7 yHWg== 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=nysGGpBiiu2Yz3koZ5feuOpzipzBFe2nHe1Y+sjmWCc=; b=n+ykzYrZNO+8epzRgj8i+EI3/XDV/oEMmEzU8N7mbw1emvLQciupiFzcfQEJ0PD6/3 HphN8fWVvssuhPeBUyK65/zp8xNN6qIalNj92ITpA2tYX5pG9+ghOq7j4nXIxdowlLh9 9Yzgb+R39wdxT81JgTnvwAnxfnAbpHg7i2DAMZaLwLi5NJDmwD7/kGwHW7U5iMAzM0S1 BXszMyBzDD93uM5xTW4QkNuw0r/I88o0GM8FETSCmoFxtgTtFtL2i4jfMyEnFtMvxGEd gzExfcgSsleCRo2F5e7WOULeB4bStfcLHKQw9US8Y/+UBThT4UJ8knGBSu0Jy+0mlo6b cuOQ== X-Gm-Message-State: APjAAAV52APQuy8T0zQPD5YktzAWX9y6Py5IChLyUCymoGC8uNm8BAvM MgzZQ10oSE8C7CHrZliidbxCVqL6q6/m7llTtkg= X-Google-Smtp-Source: APXvYqw/8oq4uwjk2Ofa6p7OucaZku3NPps5ZaatsJhn4EzLxJGKGFpM9BL0CUkpp46KWspv93r/Bsvcp/v2LlEdeF8= X-Received: by 2002:a67:c98d:: with SMTP id y13mr19314925vsk.52.1567526291353; Tue, 03 Sep 2019 08:58:11 -0700 (PDT) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> In-Reply-To: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> From: "Murray S. Kucherawy" Date: Tue, 3 Sep 2019 08:57:59 -0700 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c5cbfb0591a82785" 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, 03 Sep 2019 15:58:22 -0000 --000000000000c5cbfb0591a82785 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker wrote: > Review of: DMARC (Domain-based Message Authentication, Reporting, and > Conformance) Extension For PSDs (Public Suffix Domains) > I-D: draft-ietf-dmarc-psd-06 > Reviewer: D. Crocker > Review Date: 12 August 2019 > Dave, Thanks for your feedback about draft-ietf-dmarc-psd on August 13. Though Working Group Last Call closed on July 17th, the chairs have taken careful consideration of your feedback before allowing the document to proceed. We take these as the main points of your comments (and please correct us if we have missed any): 1. The current design of DMARC observes a clear division of functions between itself and the PSL. Specifically, as you point out, DMARC relie= s on a PSL existing and being available as input, but provides no guidance regarding selection of a PSL source nor of its content management policy= . Also, the only operation available on the list is a test of membership (i.e., =E2=80=9Cis this domain on the list?=E2=80=9D). Both of these ten= ets contribute to simplicity in DMARC=E2=80=99s current design. 2. The PSD proposal attempts to resolve use cases that have appeared since the publication of RFC7489 by prescribing the conditions under which an additional check for a policy record at a new (related) location should = be done. This violates the tenets of (1) above. 3. This additional lookup, in those cases where it is done, increases substantially the complexity of DMARC implementations, and that complexi= ty comes with non-trivial cost. 4. The use case(s) sustained by this change are not clearly substantial or beneficial enough to warrant enshrining this as a change to DMARC, even with only Experimental status. There has also been very little indicati= on of interest for implementation of the experiment. On review (and our apologies for the duration of that review), we believe the current draft does attempt to address your concerns, but does not make this clear in its current form. Given our responses to your points below, and if you agree, perhaps you can help us to compose alternative text that improves that situation. For the first two points, we concur. On the issue of the second violating the tenets of the first, we suggest that the outcome of the experiment can be used to drive an evolution of the PSL into a new form and perhaps new update policies. That is, rather than driving a change to DMARC itself, the experiment=E2=80=99s results (if successful) can drive a change to the = PSL, or perhaps inform development of an alternative to it. >From a higher level view, the experiment can be seen as the temporary construction of an augmented PSL (i.e., the actual PSL coupled with the queryable registry described in Appendix B), which DMARC then can consume to resolve the use cases that have appeared which now need to be addressed. The portion of the experiment comprising an augmentation to DMARC=E2=80=99s algorithm would therefore not be part of DMARC permanently.= Then, if the experiment proves effective, that would become prima facie evidence that the PSL, augmented with this additional information, would enable DMARC to resolve those use cases. Such an augmented PSL would still conform to the desirable separation of functions to which you alluded. The working group originally discussed other alternative ways to augment or even replace the PSL, such as creating a queryable IANA registry controlled under our own terms. The WG did not achieve consensus on such a proposal. Should this experiment bear fruit, that discussion could (and should) be revisited. Also, to be clear, any effort to augment the format, content, or management of the PSL would require collaboration with the Mozilla Foundation, as they are its de facto maintainers; absent such collaboration, or if our proposal is not accepted, we must revisit the notion of creating our own version of it and coming up with workable query and update mechanisms and policies. On the third point, we respectfully disagree. An informal canvassing of some members of the DNS community has been done and the consensus opinion suggests that the additional operational overhead proposed here is negligible. This is, indeed, a far cry from the resistance with which the original DKIM policy work was met, wherein even a one-level tree walk upward drew heavy criticism. Code-wise, DNS queries are well understood processes by now, and adding one more to the implementations of those packages with active representation in the working group has not been seen as costly enough to be a concern. And it seems logical that conducting this experiment will indeed help to confirm whether the additional query is an apparent burden on either implementers or operators. On the final point, we suggest that the WG considers this an intentional part of the experiment=E2=80=99s design. The set of use cases to which the experiment applies is deliberately constrained, which of course will limit the apparent effectiveness of the technique being proposed. However, if it is effective for the small number of domains that are part of the experiment, and with a relatively limited set of implementers, this constitutes evidence that a wider trial involving more prominent PSL entries and larger operators would be warranted as part of the development of DMARCbis. In addition, there are a few very large players in the space who are unfortunately reticent to declare publicly that they are interested in seeing this evolutionary experiment proceed. These include large email providers and operators of sizable TLDs in need of the capabilities pursued here. This provides some weight to the idea that this will not be simply a niche experiment. If none of the above are enough to assuage your concerns, we would appreciate any suggestions you might have about an alternative experiment that might be run to address the use cases both you and the draft have described. Lastly, we note that the idea of =E2=80=9Cwalk up one node=E2=80=9D came fr= om an email thread in December[1] wherein you suggested that approach, and which the PSD draft now follows. We are thus a little surprised by the assertion that it should not proceed at all. Was there some content of that thread that was not taken into account that would make it palatable? -MSK, co-chair [1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI --000000000000c5cbfb0591a82785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2019 at 7:02 PM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
Review of:=C2=A0 =C2=A0 DMARC (Domain-based Message Authent= ication, Reporting, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Conformance) Extensi= on For PSDs (Public Suffix Domains)
I-D:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-dmarc-psd-06
Reviewer:=C2=A0 =C2=A0 =C2=A0D. Crocker
Review Date:=C2=A0 12 August 2019

=C2= =A0

Dave,<= /p>

Tha= nks for your feedback about draft-ietf-dmarc-psd on August 13.=C2=A0 Though= Working Group Last Call closed on July 17th, the chairs have taken careful= consideration of your feedback before allowing the document to proceed.


We take these as the main points of your comments (and please correct us = if we have missed any):


  1. The current design of DMARC observes a clear division of= functions between itself and the PSL.=C2=A0 Specifically, as you point out= , DMARC relies on a PSL existing and being available as input, but provides= no guidance regarding selection of a PSL source nor of its content managem= ent policy.=C2=A0 Also, the only operation available on the list is a test = of membership (i.e., =E2=80=9Cis this domain on the list?=E2=80=9D). Both = of these tenets contribute to simplicity in DMARC=E2=80=99s current design.=

  2. The PSD proposal attempts to resolve use cases tha= t have appeared since the publication of RFC7489 by prescribing the conditi= ons under which an additional check for a policy record at a new (related) = location should be done.=C2=A0 This violates the tenets of (1) above.

  3. This additional lookup, in those cases where it is done,= increases substantially the complexity of DMARC implementations, and that = complexity comes with non-trivial cost.

  4. <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-weight:400;font-style:normal;font-variant:normal;tex= t-decoration:none;vertical-align:baseline;white-space:pre-wrap">The use cas= e(s) sustained by this change are not clearly substantial or beneficial eno= ugh to warrant enshrining this as a change to DMARC, even with only Experim= ental status.=C2=A0 There has also been very little indication of interest = for implementation of the experiment.


On review (and our ap= ologies for the duration of that review), we believe the current draft does= attempt to address your concerns, but does not make this clear in its curr= ent form.=C2=A0 Given our responses to your points below, and if you agree,= perhaps you can help us to compose alternative text that improves that sit= uation.


For the first two points, we concur.=C2=A0 On the issue of the = second violating the tenets of the first, we suggest that the outcome of th= e experiment can be used to drive an evolution of the PSL into a new form a= nd perhaps new update policies.=C2=A0 That is, rather than driving a change= to DMARC itself, the experiment=E2=80=99s results (if successful) can driv= e a change to the PSL, or perhaps inform development of an alternative to i= t.


From a higher level view, the experiment can be seen as the temporar= y construction of an augmented PSL (i.e., the actual PSL coupled with the q= ueryable registry described in Appendix B), which DMARC then can consume to= resolve the use cases that have appeared which now need to be addressed.= =C2=A0 The portion of the experiment comprising an augmentation to DMARC=E2= =80=99s algorithm would therefore not be part of DMARC permanently. Then, = if the experiment proves effective, that would become prima facie evidence = that the PSL, augmented with this additional information, would enable DMAR= C to resolve those use cases.=C2=A0 Such an augmented PSL would still confo= rm to the desirable separation of functions to which you alluded.

The w= orking group originally discussed other alternative ways to augment or even= replace the PSL, such as creating a queryable IANA registry controlled und= er our own terms.=C2=A0 The WG did not achieve consensus on such a proposal= . Should this experiment bear fruit, that discussion could (and should) be= revisited. Also, to be clear, any effort to augment the format, content, = or management of the PSL would require collaboration with the Mozilla Found= ation, as they are its de facto maintainers; absent such collaboration, or = if our proposal is not accepted, we must revisit the notion of creating our= own version of it and coming up with workable query and update mechanisms = and policies.


On the third point, we respectfully disagree.=C2=A0 An in= formal canvassing of some members of the DNS community has been done and th= e consensus opinion suggests that the additional operational overhead propo= sed here is negligible.=C2=A0 This is, indeed, a far cry from the resistanc= e with which the original DKIM policy work was met, wherein even a one-leve= l tree walk upward drew heavy criticism. Code-wise, DNS queries are well u= nderstood processes by now, and adding one more to the implementations of t= hose packages with active representation in the working group has not been = seen as costly enough to be a concern.=C2=A0 And it seems logical that cond= ucting this experiment will indeed help to confirm whether the additional q= uery is an apparent burden on either implementers or operators.

<= br>

On the = final point, we suggest that the WG considers this an intentional part of t= he experiment=E2=80=99s design.=C2=A0 The set of use cases to which the exp= eriment applies is deliberately constrained, which of course will limit the= apparent effectiveness of the technique being proposed.=C2=A0 However, if = it is effective for the small number of domains that are part of the experi= ment, and with a relatively limited set of implementers, this constitutes e= vidence that a wider trial involving more prominent PSL entries and larger = operators would be warranted as part of the development of DMARCbis.=


In= addition, there are a few very large players in the space who are unfortun= ately reticent to declare publicly that they are interested in seeing this = evolutionary experiment proceed.=C2=A0 These include large email providers = and operators of sizable TLDs in need of the capabilities pursued here. Th= is provides some weight to the idea that this will not be simply a niche ex= periment.


If none of the above are enough to assuage your concerns, we = would appreciate any suggestions you might have about an alternative experi= ment that might be run to address the use cases both you and the draft have= described.

Lastly, we note that the idea of =E2=80=9Cwalk up one node=E2=80= =9D came from an email thread in December[1] wherein you suggested that app= roach, and which the PSD draft now follows.=C2=A0 We are thus a little surp= rised by the assertion that it should not proceed at all. Was there some c= ontent of that thread that was not taken into account that would make it pa= latable?


-MSK, co-chair



[1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ= 3mHFayI
--000000000000c5cbfb0591a82785-- From nobody Wed Sep 4 06:28:51 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6871D1200F3 for ; Wed, 4 Sep 2019 06:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 YT-pBvjABkfD for ; Wed, 4 Sep 2019 06:28:47 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0: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 2DF3C1200DB for ; Wed, 4 Sep 2019 06:28:47 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id c7so20622808otp.1 for ; Wed, 04 Sep 2019 06:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n1f99aScuc1KvkE2Q2R8EaCJCqx4i6tJ7SP/gIUN2VI=; b=U5lSAimhgcCNSLNcDEnp3LVneVQCzfbD5G7mSt7JRrPR4sWL63MIgXhZNFQLOxcjPy 0ke8/d+TkH0X1D0gpHF2kahrUfPDDp+REsvgMf6BKzfvuKB5fIYsTKsyLk0TWvc/SADZ L4MdtMrgPUFbfwAjM9s6M+ptAeBR1GQkgo6zLQyXBNIf4ZTfkIUHMB2S1Lljcou7Qskk qCFv1TxTaOI6BrFVamz0BtahGgr6oWSgPmDpAQEQcdkZ9S/Sv0bQqaBOBCgMnYMt1iPk OLjVOAOICssdrj2MVIfO6TDMNN+q5WDRUh//17GMvjHHIGHQUck65mwlTXKhaKywHn0G a+NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n1f99aScuc1KvkE2Q2R8EaCJCqx4i6tJ7SP/gIUN2VI=; b=hpfaxnCjSmqN2I7HrJe9DSWG95+TI9N/tQ41aCfwO6+W1oTAfwDal+Otbu6uewzSAL IINbitC2R/f0twH7r5h4w56jcOtQtRf4OKsB6mme1D0pq8mR5cE0dkm1gXTgu1n+3pj/ KCw36FYDMxmO2CtxaXaWJmekkEhNBxfdLCCgguE49y/TeNhJjVsw60Epuos7a2dwpi9Y shtlU0zYD08bv4e7mJCH2IK2+8kZIAzy29YiUI8FYd4kOEacpJgcyMghkaT5aKaVnbUi xA7kvzMJEeE6KB1v3CVrjuRsnAKFmacKj3WbIF+mxVpUipmyCyXrqRc3dw5Y94kQCNyv ZD/Q== X-Gm-Message-State: APjAAAUUcMDnjcL8a6PHCuVA/mFqFaWwCvJ2yvR7es2lwA/95r4Dg2Zl Ns74XsucUVj5dWg93fqbCwK8Ip/7 X-Google-Smtp-Source: APXvYqxNsQxUtnOGAABFEDDTykpSOTCyR13lkiAz5n/RXix7FjsuINa95jymKnSrNuZeVEdoLrdzdQ== X-Received: by 2002:a9d:634b:: with SMTP id y11mr18755780otk.24.1567603725867; Wed, 04 Sep 2019 06:28:45 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:978:d464:8bc:3684? ([2600:1700:a3a0:4c80:978:d464:8bc:3684]) by smtp.gmail.com with ESMTPSA id l14sm5420944oii.27.2019.09.04.06.28.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2019 06:28:45 -0700 (PDT) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> From: Dave Crocker Message-ID: <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> Date: Wed, 4 Sep 2019 06:28:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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: Wed, 04 Sep 2019 13:28:49 -0000 Murray, Thanks for the diligent reply. (As a matter of etiquette, I will again apologize for not having submitted my concerns earlier. Partially, this was because my assessment of the work did not gel until recently.) Some responses: On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: > From a higher level view, the experiment can be seen as the temporary > construction of an augmented PSL (i.e., the actual PSL coupled with the > queryable registry described in Appendix B), which DMARC then can > consume to resolve the use cases that have appeared which now need to be > addressed.  The portion of the experiment comprising an augmentation to > DMARC’s algorithm would therefore not be part of DMARC permanently. > Then, if the experiment proves effective, that would become prima facie > evidence that the PSL, augmented with this additional information, would > enable DMARC to resolve those use cases.  Such an augmented PSL would > still conform to the desirable separation of functions to which you alluded. This model of iterative design does not match my own sense of IETF work, experimental or otherwise. Simply put, 'temporary' is an appealing but highly misleading construct, in the form and scale of a standards body.[*] The closest reality comes to matching that term is when the 'experiment' fails utterly and the effort must completely restart. When work like this operates over a period of years and at Internet scale, nothing is temporary. If an experiment succeeds, the specified work will have become entrenched and there will be significant resistance to making major changes. With respect to the use of this work as a model for changes to the PSL, unfortunately the spec is not written in a fashion to support that. This really is a core concern, in my view: the work needs to have a basic model that really is expected to be appropriate for the long term; hence my suggestion to highly limit any changes to DMARC and, instead, cast the bulk of the work as augmenting the PSL. That said, and as for getting changes to the PSL, based on my interactions with that community, I think it unlikely. There does not seem to be the interest or resources for such work. Strategically, that's the biggest hurdle to overcome, IMO. > In addition, there are a few very large players in the space who are > unfortunately reticent to declare publicly that they are interested in > seeing this evolutionary experiment proceed.  These include large email > providers and operators of sizable TLDs in need of the capabilities > pursued here. This provides some weight to the idea that this will not > be simply a niche experiment. Good to hear. > Lastly, we note that the idea of “walk up one node” came from an email > thread in December[1] wherein you suggested that approach, and which the > PSD draft now follows.  We are thus a little surprised by the assertion > that it should not proceed at all. Was there some content of that thread > that was not taken into account that would make it palatable? .. > [1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI Sigh. Yeah. Still again, sorry. Mostly this is a case of letting an idea simmer for a while, to think about it more. My feeling is that the idea does not adequately attend to the items 1 and 2 I listed in that note. Hence my current view that: 1. The change to DMARC should be limited to permitting the query for the organization domain to be anywhere in the DNS tree, including a TLD. Within DMARC this would not look like 'extra' mechanism. 2. The mechanism that processes that query should be cast strictly as a PSL enhancement, independent of DMARC. d/ [*] Note the 'obsolete' construct in RFC 5322. It was introduced in RFC 2822, as a revision to RFC 822, 20 years ago. As is obvious, it's intent was to eliminate use of the portions of RFC 822 deemed obsolete. Yet these portions still haven't been eliminated from the specification. Twenty years later. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Sep 4 07:02:29 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF91D120100 for ; Wed, 4 Sep 2019 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 T62Od2LKBUXz for ; Wed, 4 Sep 2019 07:02:26 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 E2BD21200F4 for ; Wed, 4 Sep 2019 07:02:25 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id b136so20304250iof.3 for ; Wed, 04 Sep 2019 07:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=UtD/fJvznqa20ldqMAvvsuT7Wb+wygJm+PGSE/rLwWA=; b=Z20mFYP/hL5yp4oJOSdSJfAj8rxidQlVB9huEbK1puB3AdlznULPA1+9FvkvevewpU U5RnjiLvgzw9/WVMI7sFahdFba2FOHMhKj3YhPe9Wxe8vB4tUM5xQacHOZdcGTPumYiv AqJ1FpyQfWKxXHnzsUTGMtrj9rJKefOWYXB34= 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=UtD/fJvznqa20ldqMAvvsuT7Wb+wygJm+PGSE/rLwWA=; b=gsNPhzjeQq4QqOBRbRdgta3a9O7V8P6EL1G/WJ2oxk7xU1bFOnG5omsNcKH5tOsrIv DpHYEPnhWz/HF9RzFuYBy7RrqTkFUYWyPD6ChYTvIQ81/8kTODTiG2ykuqm3FqiqPcWc v8NdWFiFygfC8JsYViKKPL2Wto97n075QNOa1q07hqGSbeCQ3/kN+cjl/qJ8dY68vtnf EOoZFVhwb0jGp4K6+Jr1oGgqLSzkWvFT7AXrcRrOvWC9PzRB0kLEwk2jP3m1LQdh74X8 NxMK5erqKDywwvcVEDc4rGl5ZA1l2ON3J/RhdEgtY9h0SZcVkuC8Y5ICrOVMG3Mqm19R 2w+w== X-Gm-Message-State: APjAAAWiVopvTILtgMdIF7bIfWTq5LGxmw5HrmkGOSCdwSHqcA68Moc0 yz3ImkPAGRWjANcNewvaMDF+HQFr+u07q9EvZuKTOnatfX8= X-Google-Smtp-Source: APXvYqwnniyoZnl9CvLzG2LX35hmXhMGMn7wGnbWuHPNe77/o6SRWAhgtwfU/PnDx2xamspnSkcg5unlfoSw5U8kR3s= X-Received: by 2002:a02:683:: with SMTP id 125mr31217091jav.132.1567605744562; Wed, 04 Sep 2019 07:02:24 -0700 (PDT) MIME-Version: 1.0 From: Craig Schwartz Date: Wed, 4 Sep 2019 10:02:02 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e08590591baa77d" Archived-At: 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: Wed, 04 Sep 2019 14:02:28 -0000 --0000000000008e08590591baa77d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Murray, Thanks for the thorough summary of where this work stands and the constructive feedback to Dave Crocker=E2=80=99s comment on 14 August 2019 (= see https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg). I previously commented on this work on 15 July 2019 (see https://mailarchive.ietf.org/arch/msg/dmarc/sw50iND6rZqbEEm16rFDKFsgERU) and voiced support for the technical solution outlined in the Internet Draft so will not repeat it again here as it=E2=80=99s not changed. On behalf of fTLD, our internal DMARC Working Group and the thousands of registrants in the .BANK and .INSURANCE TLDs, I support the continuation of this work. Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE --0000000000008e08590591baa77d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Murray,

=C2=A0

Thanks for the thorough summary of where this wor= k stands and the constructive feedback to Dave Crocker=E2=80=99s comment on 14 Augus= t 2019 (see https://mailarchive.ietf= .org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg).

=C2=A0

I previously commented on this work on 15 July 20= 19 (see https://mailarchive.ietf.org= /arch/msg/dmarc/sw50iND6rZqbEEm16rFDKFsgERU) and voiced support for the technical solution outlined in the Internet Draf= t so will not repeat it again here as it=E2=80=99s not changed.

=C2=A0

On behalf of fTLD, our internal DMARC Working Gro= up and the thousands of registrants in the .BANK and .INSURANCE TLDs, I support the continuation of this work.<= /p>

=C2=A0

Craig=C2=A0Schwartz

Managing Director
fTLD Registry Services | .BANK = & .INSURANCE



=
=
--0000000000008e08590591baa77d-- From nobody Wed Sep 4 13:53:48 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6997A120DCF for ; Wed, 4 Sep 2019 13:53:41 -0700 (PDT) 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 oInRW41u408X for ; Wed, 4 Sep 2019 13:53:38 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 8CF75120A9B for ; Wed, 4 Sep 2019 13:53:38 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id c7so22142940otp.1 for ; Wed, 04 Sep 2019 13:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=35Ub6cJCaq1eI5WfdsNQ8awxZ3+XoP44Bzi6NPjUeZE=; b=l4yGhHaSmVQRMq1/FTRB2bUpCvA0e8qJF1+Ln43MdefrHwk+pG8lPJ5+NJLZWyg7u5 2pvzAMCKf3atUuY7It5pnVNH0Fe/VQu1/gr/qCWqYwSAb6fY39yxqVorEu5UW4k0Auyy NfExUVBcGQpq10ymCbThCB6bmHCFqQHzVfQJmlLyqDGBE7+VCKLg6+FPKuU9sQdjCysw ZzdiXYpse9r5i8C9qmi399IKm1cBr48YiOhthyLF6f4rhYi44qjmeNTJZXLacRFZ+bxv dUzl0bhsidgb4i/aeaK2kjneL2aVOUIIKtGKplvBDC4PdcMYOUe95rryQjF6mGAB3+JO CERw== 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=35Ub6cJCaq1eI5WfdsNQ8awxZ3+XoP44Bzi6NPjUeZE=; b=ibguDID10SS6U6TyHvbaSZk11/n3RV9MtROv0tkwDmYSnC2vY0lSVOdNZ0iqtsTgJN 6eSHRX+Tp0/Jsp5WucvD+YBUMzEU9QvDcYLZT2DPMUYvbyHTYNOBUmtFIR7TclD8FQFh D4Fvxi6dabXIe2sC7PPQ+i+N7y7jzJSjmequ9ZfsUFUXnCWnXnqkNf5okd1ExWf1r1mF oHQcouOUFgLZAwVaG/lLppzI3340FiCBjmZDn4lOZ+d0Xk7a/HDm5Bmr+a063JwUqHAr tuAA6DXaOq3gaHMTR6tprNldHjN4WyxsowbjIM8BJMfZP/JMjBTT10reieRbRbhKaLts E9wg== X-Gm-Message-State: APjAAAUwSYuUOy0NvT5DKdmWVMkmSNVIBCcD3ye/Z1mAnGAPcyBwPPKQ Te+kMl9uj29L+YFS0VgeuLt+Fz0sGAHN1//5pyY= X-Google-Smtp-Source: APXvYqy2QTo/2VQJ/802PhgptqKhmHUJ94bSpKJ5iZ6SGzhow64R3xYmQwqLdq9sXlABmeVYRD3GDNkRAazA7Lp4vbw= X-Received: by 2002:a05:6830:1345:: with SMTP id r5mr23961638otq.158.1567630417966; Wed, 04 Sep 2019 13:53:37 -0700 (PDT) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> In-Reply-To: <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> From: Tim Wicinski Date: Wed, 4 Sep 2019 16:53:26 -0400 Message-ID: To: Dave Crocker Cc: "Murray S. Kucherawy" , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000033bb0c0591c0661f" 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, 04 Sep 2019 20:53:46 -0000 --00000000000033bb0c0591c0661f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dave I've had discussions with folks within the W3C on the PSL and the possibility of extending it, and there is always interest in considering requests from the IETF, but they are the final decision makers. The whole idea of running an experiment would be to produce data that can be shared and can help the W3C modify the PSL. Suggesting changes without understanding their effects sounds would concern me. Tim (hats/no hats/I apologize for not knowing) On Wed, Sep 4, 2019 at 9:29 AM Dave Crocker wrote: > Murray, > > Thanks for the diligent reply. > > (As a matter of etiquette, I will again apologize for not having > submitted my concerns earlier. Partially, this was because my > assessment of the work did not gel until recently.) > > > Some responses: > > On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: > > From a higher level view, the experiment can be seen as the temporary > > construction of an augmented PSL (i.e., the actual PSL coupled with the > > queryable registry described in Appendix B), which DMARC then can > > consume to resolve the use cases that have appeared which now need to b= e > > addressed. The portion of the experiment comprising an augmentation to > > DMARC=E2=80=99s algorithm would therefore not be part of DMARC permanen= tly. > > Then, if the experiment proves effective, that would become prima facie > > evidence that the PSL, augmented with this additional information, woul= d > > enable DMARC to resolve those use cases. Such an augmented PSL would > > still conform to the desirable separation of functions to which you > alluded. > > This model of iterative design does not match my own sense of IETF work, > experimental or otherwise. > > Simply put, 'temporary' is an appealing but highly misleading construct, > in the form and scale of a standards body.[*] The closest reality comes > to matching that term is when the 'experiment' fails utterly and the > effort must completely restart. When work like this operates over a > period of years and at Internet scale, nothing is temporary. > > If an experiment succeeds, the specified work will have become > entrenched and there will be significant resistance to making major > changes. > > With respect to the use of this work as a model for changes to the PSL, > unfortunately the spec is not written in a fashion to support that. > This really is a core concern, in my view: the work needs to have a > basic model that really is expected to be appropriate for the long term; > hence my suggestion to highly limit any changes to DMARC and, instead, > cast the bulk of the work as augmenting the PSL. > > That said, and as for getting changes to the PSL, based on my > interactions with that community, I think it unlikely. There does not > seem to be the interest or resources for such work. Strategically, > that's the biggest hurdle to overcome, IMO. > > > > > In addition, there are a few very large players in the space who are > > unfortunately reticent to declare publicly that they are interested in > > seeing this evolutionary experiment proceed. These include large email > > providers and operators of sizable TLDs in need of the capabilities > > pursued here. This provides some weight to the idea that this will not > > be simply a niche experiment. > > Good to hear. > > > > Lastly, we note that the idea of =E2=80=9Cwalk up one node=E2=80=9D cam= e from an email > > thread in December[1] wherein you suggested that approach, and which th= e > > PSD draft now follows. We are thus a little surprised by the assertion > > that it should not proceed at all. Was there some content of that threa= d > > that was not taken into account that would make it palatable? > .. > > [1] > https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI > > Sigh. Yeah. Still again, sorry. Mostly this is a case of letting an > idea simmer for a while, to think about it more. My feeling is that the > idea does not adequately attend to the items 1 and 2 I listed in that not= e. > > Hence my current view that: > > 1. The change to DMARC should be limited to permitting the query for the > organization domain to be anywhere in the DNS tree, including a TLD. > Within DMARC this would not look like 'extra' mechanism. > > 2. The mechanism that processes that query should be cast strictly as a > PSL enhancement, independent of DMARC. > > > d/ > > [*] Note the 'obsolete' construct in RFC 5322. It was introduced in RFC > 2822, as a revision to RFC 822, 20 years ago. As is obvious, it's > intent was to eliminate use of the portions of RFC 822 deemed obsolete. > Yet these portions still haven't been eliminated from the specification. > Twenty years later. > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000033bb0c0591c0661f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave

I've had discussions with folk= s within the W3C on the PSL and the possibility of extending it,=C2=A0
and there is always interest in considering requests from the IETF, b= ut they are the final=C2=A0
decision makers. =C2=A0
The whole idea of running an experiment would be to produce dat= a that can be shared and=C2=A0
can help the W3C modify the PSL.= =C2=A0 Suggesting changes without understanding=C2=A0
their effec= ts sounds would concern me.=C2=A0

Tim
(h= ats/no hats/I apologize for not knowing)


On Wed, Sep 4,= 2019 at 9:29 AM Dave Crocker <dcr= ocker@gmail.com> wrote:
Murray,

Thanks for the diligent reply.

(As a matter of etiquette, I will again apologize for not having
submitted my concerns earlier.=C2=A0 Partially, this was because my
assessment of the work did not gel until recently.)


Some responses:

On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
>=C2=A0 From a higher level view, the experiment can be seen as the temp= orary
> construction of an augmented PSL (i.e., the actual PSL coupled with th= e
> queryable registry described in Appendix B), which DMARC then can
> consume to resolve the use cases that have appeared which now need to = be
> addressed.=C2=A0 The portion of the experiment comprising an augmentat= ion to
> DMARC=E2=80=99s algorithm would therefore not be part of DMARC permane= ntly.
> Then, if the experiment proves effective, that would become prima faci= e
> evidence that the PSL, augmented with this additional information, wou= ld
> enable DMARC to resolve those use cases.=C2=A0 Such an augmented PSL w= ould
> still conform to the desirable separation of functions to which you al= luded.

This model of iterative design does not match my own sense of IETF work, experimental or otherwise.

Simply put, 'temporary' is an appealing but highly misleading const= ruct,
in the form and scale of a standards body.[*]=C2=A0 The closest reality com= es
to matching that term is when the 'experiment' fails utterly and th= e
effort must completely restart. When work like this operates over a
period of years and at Internet scale, nothing is temporary.

If an experiment succeeds, the specified work will have become
entrenched and there will be significant resistance to making major changes= .

With respect to the use of this work as a model for changes to the PSL, unfortunately the spec is not written in a fashion to support that.
This really is a core concern, in my view: the work needs to have a
basic model that really is expected to be appropriate for the long term; hence my suggestion to highly limit any changes to DMARC and, instead,
cast the bulk of the work as augmenting the PSL.

That said, and as for getting changes to the PSL, based on my
interactions with that community, I think it unlikely.=C2=A0 There does not=
seem to be the interest or resources for such work.=C2=A0 Strategically, that's the biggest hurdle to overcome, IMO.



> In addition, there are a few very large players in the space who are <= br> > unfortunately reticent to declare publicly that they are interested in=
> seeing this evolutionary experiment proceed.=C2=A0 These include large= email
> providers and operators of sizable TLDs in need of the capabilities > pursued here. This provides some weight to the idea that this will not=
> be simply a niche experiment.

Good to hear.


> Lastly, we note that the idea of =E2=80=9Cwalk up one node=E2=80=9D ca= me from an email
> thread in December[1] wherein you suggested that approach, and which t= he
> PSD draft now follows.=C2=A0 We are thus a little surprised by the ass= ertion
> that it should not proceed at all. Was there some content of that thre= ad
> that was not taken into account that would make it palatable?
..
> [1] https://mailarchive.= ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI

Sigh.=C2=A0 Yeah.=C2=A0 Still again, sorry.=C2=A0 Mostly this is a case of = letting an
idea simmer for a while, to think about it more.=C2=A0 My feeling is that t= he
idea does not adequately attend to the items 1 and 2 I listed in that note.=

Hence my current view that:

1. The change to DMARC should be limited to permitting the query for the organization domain to be anywhere in the DNS tree, including a TLD.
Within DMARC this would not look like 'extra' mechanism.

2. The mechanism that processes that query should be cast strictly as a PSL enhancement, independent of DMARC.


d/

[*] Note the 'obsolete' construct in RFC 5322.=C2=A0 It was introdu= ced in RFC
2822, as a revision to RFC 822, 20 years ago.=C2=A0 As is obvious, it's=
intent was to eliminate use of the portions of RFC 822 deemed obsolete. Yet these portions still haven't been eliminated from the specification= .
=C2=A0 Twenty years later.

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000033bb0c0591c0661f-- From nobody Wed Sep 4 19:24:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFA6120B9A for ; Wed, 4 Sep 2019 19:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=PAnseLPp; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=nlnirPoh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9jGFeYP82gQ for ; Wed, 4 Sep 2019 19:24:52 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC3120B15 for ; Wed, 4 Sep 2019 19:24:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4913; t=1567650283; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=sQZPO77gP3OnwQMMWL2DFOxIYjA=; b=PAnseLPpQ8qnEEgCC74hTtfHpc/Eu9bV1H9s3pXU67A7PaOx827rVO1g2lr+Wp Ty6OrToO8wV0kpDszBDkAoplWbINtDY1gQTum+lsFHQsQ2ezSWr9fTWlRnC6Gafj jdN6T/G471/hINqROyBPD6YcGOGUPuwoPcHT0IOirpmBI= Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for dmarc@ietf.org; Wed, 04 Sep 2019 22:24:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 4147671219.1.4428; Wed, 04 Sep 2019 22:24:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4913; t=1567650278; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=e3q1fzS UQmWR4kvQxa0HsnZEpFcfz7tM8EUhAjOlfJ0=; b=nlnirPoh7Z4aIiMh8obkPy7 DsTGN0V2n4pKdsAukpPMvWQ2tnBCO3c/6MDH0UUNrCsiq065RMfKiy/+roNQ2+li 2NpBKyOuBwtFkwViVGQHaO1fuUk+D/cyr91fknNOqvJwPA+enkiZ2pUBqCUQu0sn 88+LrdMSEQm3d8/DunHw= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.8) for dmarc@ietf.org; Wed, 04 Sep 2019 22:24:38 -0400 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.8) with ESMTP id 1826502453.15.11888; Wed, 04 Sep 2019 22:24:37 -0400 Message-ID: <5D7071EC.5000908@isdg.net> Date: Wed, 04 Sep 2019 22:24:44 -0400 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: Dave Crocker , "Murray S. Kucherawy" CC: IETF DMARC WG References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> In-Reply-To: <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> 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, 05 Sep 2019 02:24:56 -0000 We need to use the QUERY for the DMARC record to get compliant clients to try (explore) different things. Let the record tell the client what to do. We need an expanded language for the possible tags. SPF was very flexible. DMARC is not because it removed 3rd party capabilities. It is too limited. In the end, this is still about 3rd party AA (authentication/authorization) and in this case what is being labeled PSD domains. Just define/refine the BASE lookup mechanism, and the possible extensions. ATPS offers an extended protocol mechanism for 3rd party domain authorization. This is basically what is wanted for PSD. On 9/4/2019 9:28 AM, Dave Crocker wrote: > Murray, > > Thanks for the diligent reply. > > (As a matter of etiquette, I will again apologize for not having > submitted my concerns earlier. Partially, this was because my > assessment of the work did not gel until recently.) > > > Some responses: > > On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: >> From a higher level view, the experiment can be seen as the >> temporary construction of an augmented PSL (i.e., the actual PSL >> coupled with the queryable registry described in Appendix B), which >> DMARC then can consume to resolve the use cases that have appeared >> which now need to be addressed. The portion of the experiment >> comprising an augmentation to DMARC’s algorithm would therefore not >> be part of DMARC permanently. Then, if the experiment proves >> effective, that would become prima facie evidence that the PSL, >> augmented with this additional information, would enable DMARC to >> resolve those use cases. Such an augmented PSL would still conform >> to the desirable separation of functions to which you alluded. > > This model of iterative design does not match my own sense of IETF > work, experimental or otherwise. > > Simply put, 'temporary' is an appealing but highly misleading > construct, in the form and scale of a standards body.[*] The closest > reality comes to matching that term is when the 'experiment' fails > utterly and the effort must completely restart. When work like this > operates over a period of years and at Internet scale, nothing is > temporary. > > If an experiment succeeds, the specified work will have become > entrenched and there will be significant resistance to making major > changes. > > With respect to the use of this work as a model for changes to the > PSL, unfortunately the spec is not written in a fashion to support > that. This really is a core concern, in my view: the work needs to > have a basic model that really is expected to be appropriate for the > long term; hence my suggestion to highly limit any changes to DMARC > and, instead, cast the bulk of the work as augmenting the PSL. > > That said, and as for getting changes to the PSL, based on my > interactions with that community, I think it unlikely. There does not > seem to be the interest or resources for such work. Strategically, > that's the biggest hurdle to overcome, IMO. > > > >> In addition, there are a few very large players in the space who are >> unfortunately reticent to declare publicly that they are interested >> in seeing this evolutionary experiment proceed. These include large >> email providers and operators of sizable TLDs in need of the >> capabilities pursued here. This provides some weight to the idea >> that this will not be simply a niche experiment. > > Good to hear. > > >> Lastly, we note that the idea of “walk up one node” came from an >> email thread in December[1] wherein you suggested that approach, and >> which the PSD draft now follows. We are thus a little surprised by >> the assertion that it should not proceed at all. Was there some >> content of that thread that was not taken into account that would >> make it palatable? > .. >> [1] >> https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI > > Sigh. Yeah. Still again, sorry. Mostly this is a case of letting an > idea simmer for a while, to think about it more. My feeling is that > the idea does not adequately attend to the items 1 and 2 I listed in > that note. > > Hence my current view that: > > 1. The change to DMARC should be limited to permitting the query for > the organization domain to be anywhere in the DNS tree, including a > TLD. Within DMARC this would not look like 'extra' mechanism. > > 2. The mechanism that processes that query should be cast strictly as > a PSL enhancement, independent of DMARC. > > > d/ > > [*] Note the 'obsolete' construct in RFC 5322. It was introduced in > RFC 2822, as a revision to RFC 822, 20 years ago. As is obvious, it's > intent was to eliminate use of the portions of RFC 822 deemed > obsolete. Yet these portions still haven't been eliminated from the > specification. Twenty years later. > -- HLS From nobody Wed Sep 4 22:16:13 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5747120088 for ; Wed, 4 Sep 2019 22:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kx+FJ2TK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=p5qcwki2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cj6T-tmISjZ for ; Wed, 4 Sep 2019 22:16:09 -0700 (PDT) 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 87829120074 for ; Wed, 4 Sep 2019 22:16:09 -0700 (PDT) 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 652A0F80650 for ; Thu, 5 Sep 2019 01:15:38 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1567660538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BKruqmiaLEKXXaWrjY56Q3HRJ1ZgAZijjnolpdSKTIY=; b=kx+FJ2TKt6ULjiEHhh3+o5UD1rtVVKDec5lQyo5i4mmBKymASyyUIxOL q/61F4hZO1SDYnO730rYWV2r0qlcBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1567660538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BKruqmiaLEKXXaWrjY56Q3HRJ1ZgAZijjnolpdSKTIY=; b=p5qcwki2cGEEPewyvE19OiqS7+YSXl6umREXmBvAcoXb/8tnY5AZcQac Vwe4bw6+PP1H8Qq5pwMe5xseQrwoSH2/tlMwAFnvfqBT6liz6OwBzbnnJE Ooj1dErxjAXsq0udYyMkr13SLeYKsQfab7taUC7UmKy0XXPoG4AMg+9Gf3 8ghcMo2wTlH+mbEZ/tiZsjJCrcXGGrSjoZWsKc3NcF1RCV1cXgjShLrkCz vNyXV6iwMYThFAKFfZ1M/HgpsR1sZRwiUqIzYKKyksTIoVTdc1ipwQ6Z58 sUPzcvIXuiOh6K8RqIsex03AlpjGKn97JE5beTpjWzpcSHfZEyHygw== Received: from l5580.localnet (unknown [IPv6:2600:380:761c:27e7:58aa:8c6d:f7f0:6280]) by interserver.kitterman.com (Postfix) with ESMTPSA id 03D05F80463 for ; Thu, 5 Sep 2019 01:15:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 05 Sep 2019 01:15:35 -0400 Message-ID: <2922527.kgd3cNqxNO@l5580> In-Reply-To: <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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, 05 Sep 2019 05:16:12 -0000 On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote: > Murray, >=20 > Thanks for the diligent reply. >=20 > (As a matter of etiquette, I will again apologize for not having > submitted my concerns earlier. Partially, this was because my > assessment of the work did not gel until recently.) >=20 >=20 > Some responses: >=20 > On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: > > From a higher level view, the experiment can be seen as the temporary > >=20 > > construction of an augmented PSL (i.e., the actual PSL coupled with the > > queryable registry described in Appendix B), which DMARC then can > > consume to resolve the use cases that have appeared which now need to be > > addressed. The portion of the experiment comprising an augmentation to > > DMARC=E2=80=99s algorithm would therefore not be part of DMARC permanen= tly. > > Then, if the experiment proves effective, that would become prima facie > > evidence that the PSL, augmented with this additional information, would > > enable DMARC to resolve those use cases. Such an augmented PSL would > > still conform to the desirable separation of functions to which you > > alluded. > This model of iterative design does not match my own sense of IETF work, > experimental or otherwise. >=20 > Simply put, 'temporary' is an appealing but highly misleading construct, > in the form and scale of a standards body.[*] The closest reality comes > to matching that term is when the 'experiment' fails utterly and the > effort must completely restart. When work like this operates over a > period of years and at Internet scale, nothing is temporary. >=20 > If an experiment succeeds, the specified work will have become > entrenched and there will be significant resistance to making major chang= es. >=20 > With respect to the use of this work as a model for changes to the PSL, > unfortunately the spec is not written in a fashion to support that. > This really is a core concern, in my view: the work needs to have a > basic model that really is expected to be appropriate for the long term; > hence my suggestion to highly limit any changes to DMARC and, instead, > cast the bulk of the work as augmenting the PSL. >=20 > That said, and as for getting changes to the PSL, based on my > interactions with that community, I think it unlikely. There does not > seem to be the interest or resources for such work. Strategically, > that's the biggest hurdle to overcome, IMO. >=20 > > In addition, there are a few very large players in the space who are > > unfortunately reticent to declare publicly that they are interested in > > seeing this evolutionary experiment proceed. These include large email > > providers and operators of sizable TLDs in need of the capabilities > > pursued here. This provides some weight to the idea that this will not > > be simply a niche experiment. >=20 > Good to hear. >=20 > > Lastly, we note that the idea of =E2=80=9Cwalk up one node=E2=80=9D cam= e from an email > > thread in December[1] wherein you suggested that approach, and which the > > PSD draft now follows. We are thus a little surprised by the assertion > > that it should not proceed at all. Was there some content of that thread > > that was not taken into account that would make it palatable? >=20 > .. >=20 > > [1] > > https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI >=20 > Sigh. Yeah. Still again, sorry. Mostly this is a case of letting an > idea simmer for a while, to think about it more. My feeling is that the > idea does not adequately attend to the items 1 and 2 I listed in that not= e. >=20 > Hence my current view that: >=20 > 1. The change to DMARC should be limited to permitting the query for the > organization domain to be anywhere in the DNS tree, including a TLD. > Within DMARC this would not look like 'extra' mechanism. >=20 > 2. The mechanism that processes that query should be cast strictly as a > PSL enhancement, independent of DMARC. I think some related, but distinct issues are conflated in your analysis. The core PSD check doesn't need a PSL change. The current PSL works fine. = The=20 sequence is: 1. Check at the From domain level. 2. If no record, check at the org level. 3. [New] if no record check one level above the org level (PSD). That's all doable with the current PSL. I don't think we want to force=20 additional lookups between 1 and 2 for lower level domains. Currently for= =20 something like: a.b.c.d.org.example where only example is in the PSL the queries would be: 1. a.b.c.d.org.example 2 . org.example 3. example As I read your proposal we've have to add in queries for: b.c.d.org.example c.d.org.example d.org.example I don't think querying anywhere in the DNS treee is an improvement for=20 scalability of DMARC. Adding the single additional PSD lookup works fine with the existing PSL. = =20 There are two reasons to go beyond this: 1. Since most PSDs won't publish DMARC records, as an efficiency, let's no= t do=20 that third lookup unless we have to. 2. PSD DMARC without some constraints on the additional lookup automatical= ly=20 opts in all organizational domains that do not publish DMARC records, which= =20 has privacy implications. This is discussed in Section 4.1 of the draft. As it says at the start of Appendix B, the options proposed there are to=20 mitigate the privacy risks described in Section 4.1. The related requireme= nts=20 discussion is in Appendix A, Section A.1. It is a beneficial side effect that they also reduce the need for DNS looku= ps=20 and thus provide an efficiency enhancement. If we didn't care about privacy, this would be easy. That's the hard part= =20 that does not have a clear solution. One thing that is clear is that it's = not=20 the PSL. PSL is a collector of assertions from operators, so it fails to m= eet=20 the attributes laid out in A.1. Scott K From nobody Thu Sep 5 01:28:11 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965391200A1 for ; Thu, 5 Sep 2019 01:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTuWGU6Gpf6t for ; Thu, 5 Sep 2019 01:28:08 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09C7120058 for ; Thu, 5 Sep 2019 01:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1567672085; bh=blO4uQPWSES/8lc8NJoxjFbD1uwumzCFaIZ6mIbxXgo=; l=4918; h=To:References:From:Date:In-Reply-To; b=DjMp61QrqFabDvFTLZLA+gutgUoDzJl/aVnaUVtLdNBLIc+J1vmk6GL267oTVadw/ nnhYC0U+bFkvooKZ+1Eby7Ce3IS+WT+dfUVgOkL1bGKlPyncNwSRw8dEg//21LKAuN fJnahFwu/UFnTXuimhGjm5sjs0ZTSYUIEffXCUVkgVIZsUgKxRDkgx6GI5uVj Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC083.000000005D70C715.00004E1F; Thu, 05 Sep 2019 10:28:05 +0200 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> <2922527.kgd3cNqxNO@l5580> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it> Date: Thu, 5 Sep 2019 10:28:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2922527.kgd3cNqxNO@l5580> 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: Thu, 05 Sep 2019 08:28:09 -0000 On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote: > On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote: >> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: >>> >>> construction of an augmented PSL (i.e., the actual PSL coupled with the >>> queryable registry described in Appendix B), which DMARC then can >>> consume to resolve the use cases that have appeared which now need to be >>> addressed. The portion of the experiment comprising an augmentation to >>> DMARC’s algorithm would therefore not be part of DMARC permanently. >>> Then, if the experiment proves effective, that would become prima facie >>> evidence that the PSL, augmented with this additional information, would >>> enable DMARC to resolve those use cases. Such an augmented PSL would >>> still conform to the desirable separation of functions to which you >>> alluded. >> >> With respect to the use of this work as a model for changes to the PSL, >> unfortunately the spec is not written in a fashion to support that. >> This really is a core concern, in my view: the work needs to have a >> basic model that really is expected to be appropriate for the long term; >> hence my suggestion to highly limit any changes to DMARC and, instead, >> cast the bulk of the work as augmenting the PSL. >> >> That said, and as for getting changes to the PSL, based on my >> interactions with that community, I think it unlikely. There does not >> seem to be the interest or resources for such work. Strategically, >> that's the biggest hurdle to overcome, IMO. >> >> .. >> >> Hence my current view that: >> >> 1. The change to DMARC should be limited to permitting the query for the >> organization domain to be anywhere in the DNS tree, including a TLD. >> Within DMARC this would not look like 'extra' mechanism. >> >> 2. The mechanism that processes that query should be cast strictly as a >> PSL enhancement, independent of DMARC. > > I think some related, but distinct issues are conflated in your analysis. > > The core PSD check doesn't need a PSL change. The current PSL works fine. The > sequence is: > > 1. Check at the From domain level. > 2. If no record, check at the org level. > 3. [New] if no record check one level above the org level (PSD). > > That's all doable with the current PSL. I don't think we want to force > additional lookups between 1 and 2 for lower level domains. Currently for > something like: > > a.b.c.d.org.example where only example is in the PSL the queries would be: > > 1. a.b.c.d.org.example > 2. org.example > 3. example > > As I read your proposal we've have to add in queries for: > > b.c.d.org.example > c.d.org.example > d.org.example > > I don't think querying anywhere in the DNS treee is an improvement for > scalability of DMARC. Besides scalability, the question is whether b, c, or d have the right to override the DMARC policy of org.example. The current spec clearly says no. My reading of Dave's proposal differs. Modifying the PSL has the implicit objective to skip step 2. That is, to limit queries to: 1. a.b.c.d.org.example 3. example Thereby slashing org.example's privilege to establish its own domain policy. > Adding the single additional PSD lookup works fine with the existing PSL. > There are two reasons to go beyond this: > > 1. Since most PSDs won't publish DMARC records, as an efficiency, let's not do > that third lookup unless we have to. > > 2. PSD DMARC without some constraints on the additional lookup automatically > opts in all organizational domains that do not publish DMARC records, which > has privacy implications. This is discussed in Section 4.1 of the draft. We should also consider updates: How often is/should be the PSL updated at average mail servers? How often would then the extra list at psddmarc.org have to be updated? > As it says at the start of Appendix B, the options proposed there are to > mitigate the privacy risks described in Section 4.1. The related requirements > discussion is in Appendix A, Section A.1. > > It is a beneficial side effect that they also reduce the need for DNS lookups > and thus provide an efficiency enhancement. > > If we didn't care about privacy, this would be easy. That's the hard part > that does not have a clear solution. One thing that is clear is that it's not > the PSL. PSL is a collector of assertions from operators, so it fails to meet > the attributes laid out in A.1. Failure reports are considerably less implemented than aggregate ones. The current spec doesn't mention any privacy risk in its Security Considerations section. However, some concern must exist, otherwise the difference in implementations cannot be easily explained. The I-D at hand touches on this point marginally. A general consideration would better fit in DMARCbis. Best Ale -- From nobody Thu Sep 5 06:36:09 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA431200CD for ; Thu, 5 Sep 2019 06:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=pBFFBHRz; dkim=pass (2048-bit key) header.d=kitterman.com header.b=FNcoyxnv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zz1oQPZGTFh for ; Thu, 5 Sep 2019 06:36:04 -0700 (PDT) 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 0EF87120026 for ; Thu, 5 Sep 2019 06:36:04 -0700 (PDT) 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 D08F0F8066A; Thu, 5 Sep 2019 09:35:32 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=pBFFBHRzPYJnoemLrAsigFT8t8vc4xvKVQXYyNbYQNFGOy2a1tk/uOsC e3vPneiRCUrzyaOX312zu+nojkUXCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1567690532; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=fjnmWVqzvehF1o63CMmnkQP1x8n4c84y/uda7qgCOQQ=; b=FNcoyxnvLYl4Xu8vqMkI6MtPcm9gBMB43A60jdVQCNdDQtKYskJjDvX+ XrNIaw0nAYwI7HbwqSdYW+0U6s85soMlcJXpFAq2m7J+Y3qOtSFpWgFH7/ age+mjeT1mVpzo7l+dOlfGa9XzOlAv1g7RcksTS4Nt8k25NOhbdEx9CKDU LMJAlkX+mrzcmT8la24zeu8iO5AIgD4uzWk4D/mtuQEL6ZWW8ZN98gvWnW c2OUMUEV6PO66y5avkMVYhwyl6r0Zvfx50etWpW+fRNfdl51u0ORJvFWCc hGTaccKfYu2ZBSHegWy/Z2Ae9Se9nffWgmyHKmxK5hinWZ2PvdOdCg== Received: from [10.226.138.197] (mobile-166-171-120-109.mycingular.net [166.171.120.109]) by interserver.kitterman.com (Postfix) with ESMTPSA id 50DE6F80284; Thu, 5 Sep 2019 09:35:32 -0400 (EDT) Date: Thu, 05 Sep 2019 13:35:29 +0000 In-Reply-To: <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> <2922527.kgd3cNqxNO@l5580> <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <7788EC9D-D4F7-4B00-863D-7289E8B2AB41@kitterman.com> 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, 05 Sep 2019 13:36:07 -0000 On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely = wrote: >On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote: >> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote: >>> On 9/3/2019 8:57 AM, Murray S=2E Kucherawy wrote: >>>>=20 >>>> construction of an augmented PSL (i=2Ee=2E, the actual PSL coupled wi= th >the >>>> queryable registry described in Appendix B), which DMARC then can >>>> consume to resolve the use cases that have appeared which now need >to be >>>> addressed=2E The portion of the experiment comprising an >augmentation to >>>> DMARC=E2=80=99s algorithm would therefore not be part of DMARC perman= ently=2E >>>> Then, if the experiment proves effective, that would become prima >facie >>>> evidence that the PSL, augmented with this additional information, >would >>>> enable DMARC to resolve those use cases=2E Such an augmented PSL >would >>>> still conform to the desirable separation of functions to which you >>>> alluded=2E >>>=20 >>> With respect to the use of this work as a model for changes to the >PSL, >>> unfortunately the spec is not written in a fashion to support that=2E >>> This really is a core concern, in my view: the work needs to have a >>> basic model that really is expected to be appropriate for the long >term; >>> hence my suggestion to highly limit any changes to DMARC and, >instead, >>> cast the bulk of the work as augmenting the PSL=2E >>>=20 >>> That said, and as for getting changes to the PSL, based on my >>> interactions with that community, I think it unlikely=2E There does >not >>> seem to be the interest or resources for such work=2E Strategically, >>> that's the biggest hurdle to overcome, IMO=2E >>>=20 >>> =2E=2E >>>=20 >>> Hence my current view that: >>>=20 >>> 1=2E The change to DMARC should be limited to permitting the query for >the >>> organization domain to be anywhere in the DNS tree, including a TLD=2E >>> Within DMARC this would not look like 'extra' mechanism=2E >>>=20 >>> 2=2E The mechanism that processes that query should be cast strictly >as a >>> PSL enhancement, independent of DMARC=2E >>=20 >> I think some related, but distinct issues are conflated in your >analysis=2E >>=20 >> The core PSD check doesn't need a PSL change=2E The current PSL works >fine=2E The=20 >> sequence is: >>=20 >> 1=2E Check at the From domain level=2E >> 2=2E If no record, check at the org level=2E >> 3=2E [New] if no record check one level above the org level (PSD)=2E >>=20 >> That's all doable with the current PSL=2E I don't think we want to >force=20 >> additional lookups between 1 and 2 for lower level domains=2E=20 >Currently for=20 >> something like: >>=20 >> a=2Eb=2Ec=2Ed=2Eorg=2Eexample where only example is in the PSL the quer= ies >would be: >>=20 >> 1=2E a=2Eb=2Ec=2Ed=2Eorg=2Eexample >> 2=2E org=2Eexample >> 3=2E example >>=20 >> As I read your proposal we've have to add in queries for: >>=20 >> b=2Ec=2Ed=2Eorg=2Eexample >> c=2Ed=2Eorg=2Eexample >> d=2Eorg=2Eexample >>=20 >> I don't think querying anywhere in the DNS treee is an improvement >for=20 >> scalability of DMARC=2E > > >Besides scalability, the question is whether b, c, or d have the right >to >override the DMARC policy of org=2Eexample=2E The current spec clearly >says no=2E > >My reading of Dave's proposal differs=2E Modifying the PSL has the >implicit >objective to skip step 2=2E That is, to limit queries to: > >1=2E a=2Eb=2Ec=2Ed=2Eorg=2Eexample >3=2E example > >Thereby slashing org=2Eexample's privilege to establish its own domain >policy=2E > > >> Adding the single additional PSD lookup works fine with the existing >PSL=2E =20 >> There are two reasons to go beyond this: >>=20 >> 1=2E Since most PSDs won't publish DMARC records, as an efficiency, >let's not do=20 >> that third lookup unless we have to=2E >>=20 >> 2=2E PSD DMARC without some constraints on the additional lookup >automatically=20 >> opts in all organizational domains that do not publish DMARC records, >which=20 >> has privacy implications=2E This is discussed in Section 4=2E1 of the >draft=2E > > >We should also consider updates: > >How often is/should be the PSL updated at average mail servers? > >How often would then the extra list at psddmarc=2Eorg have to be updated? > > >> As it says at the start of Appendix B, the options proposed there are >to=20 >> mitigate the privacy risks described in Section 4=2E1=2E The related >requirements=20 >> discussion is in Appendix A, Section A=2E1=2E >>=20 >> It is a beneficial side effect that they also reduce the need for DNS >lookups=20 >> and thus provide an efficiency enhancement=2E >>=20 >> If we didn't care about privacy, this would be easy=2E That's the hard >part=20 >> that does not have a clear solution=2E One thing that is clear is that >it's not=20 >> the PSL=2E PSL is a collector of assertions from operators, so it >fails to meet=20 >> the attributes laid out in A=2E1=2E > > >Failure reports are considerably less implemented than aggregate ones=2E= =20 >The >current spec doesn't mention any privacy risk in its Security >Considerations >section=2E However, some concern must exist, otherwise the difference in >implementations cannot be easily explained=2E The I-D at hand touches on >this >point marginally=2E A general consideration would better fit in >DMARCbis=2E That's because there's an entire separate section on privacy consideration= s=2E Scott K From nobody Thu Sep 5 13:22:36 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45151207FF for ; Thu, 5 Sep 2019 13:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 JFYajjBh4QYn for ; Thu, 5 Sep 2019 13:22:33 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 ED775120271 for ; Thu, 5 Sep 2019 13:22:32 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 100so3587259otn.2 for ; Thu, 05 Sep 2019 13:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fa/qTiPBv7AJRvhVbDKScWjOMzsLzobmyq7GLbdLxJw=; b=R/4aUMle0QsJ7lLBzoBCCxx4MSD/Lpy6P5PNWztV7fITxgzBf0Rj+pQa8Y4I0PwgWm rScMrSjrSmsOIK8Ovk27oYQAAWE+G1vyKEMVVlRi5YwYGZy4BsLb6hYGKtQmxBY05O4c YgUNVs4pTG2V75vGsoEfV2g84rSxXeP7F1iRax/wU7f2CJCLKiUjYTAjbjHmTQHHtFBT V2PMbF9Ydq4+epxp5/HtPbUmGQRf0LJyDWtZJ9w4HjrjTkkmvAxZ2A24XdrZiw3cTeQF M0OGWek/N97iz7u7vDh7cN526e26qkLlkQVIX7cjudmj+KcNogurPmDUaRYNggWO7wjO XT3A== 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:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fa/qTiPBv7AJRvhVbDKScWjOMzsLzobmyq7GLbdLxJw=; b=C14ZU1+jpYCIUP3F3OIrcy7FcsniTWVLMkozPJDInM7nTLx/Q4DgPNOvI+ogLRRjfk tU0oOcykXdmzTXLRnAaUu1DhxaEmSMYGgjNRaVmtpTUgAmTnE3LOKtEwgRwFiPaB/A0Z StqM4+nl2W4/IWIAcqkMITdqL/JwUscN9scH8dJ6TMtCSXNPIxZdsQHwaeFJZ6OFOM+B DPLBDP6w/w+2a6ARNuGzSpaCc9pQh0OCL/EViVEp5w1eaIbAqzG9HAKCyFrd6LY0nWfv bj4ArkuOZerEa8e/DznM6xHaCL2JSIaqVuPZCQIQfynu+kAdGOSvN8neix3C9p8fp3gO 9JgA== X-Gm-Message-State: APjAAAUQfbYfgr9LwwQWlWihsUc+SMdmJa9Iszsa8HLboRtzVYRt+iin zuHVRBsc/KGm0tck5ShgTvlW7BbY X-Google-Smtp-Source: APXvYqxGcgUUUff1nFtGbAj8t5r7GYG3g79p2PSA3IpgVQsN9wiBKg5DNBBCq06JrtJUlHQ3QzZmWw== X-Received: by 2002:a9d:5e11:: with SMTP id d17mr4434603oti.135.1567714951804; Thu, 05 Sep 2019 13:22:31 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:d981:1a68:7c5f:511c? ([2600:1700:a3a0:4c80:d981:1a68:7c5f:511c]) by smtp.gmail.com with ESMTPSA id e22sm1067676otl.33.2019.09.05.13.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 13:22:30 -0700 (PDT) From: Dave Crocker To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> Message-ID: <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> Date: Thu, 5 Sep 2019 13:22:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 05 Sep 2019 20:22:35 -0000 On 9/4/2019 6:28 AM, Dave Crocker wrote: > ence my current view that: > > 1. The change to DMARC should be limited to permitting the query for the > organization domain to be anywhere in the DNS tree, including a TLD. > Within DMARC this would not look like 'extra' mechanism. > > 2. The mechanism that processes that query should be cast strictly as a > PSL enhancement, independent of DMARC. Trying to refine things further: DMARC does not care about the PSL. What DMARC cares about is the Organizational Domain (OD), as a fallback when no DMARC record is found at the desired domain name. That is, PSL is literally outside the scope of DMARC. At the least, therefore, the DMARC specification should define a distinct interface to the outside functionality that tells DMARC where the OD is, which will return what suffix of the full domain name is the OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix The PSL-related side of that interface should be a separate specification, so that changes to its behavior -- such as has been happening with the introduction of ODs that are TLDs or are otherwise 'above' where DMARC has been guessing the OD to be -- are isolated from DMARC. The current problems are that DMARC has embedded too much detail about the PSL world, yet DMARC has no involvement in that world. The current proposal embeds assumptions of PSL knowledge further, rather than separating PSL knowledge out. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Sep 5 14:49:47 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B16120130 for ; Thu, 5 Sep 2019 14:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=8Kn4Vb2M; dkim=pass (2048-bit key) header.d=kitterman.com header.b=BSaZ2/6r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9QFwtC1N5ai for ; Thu, 5 Sep 2019 14:49:44 -0700 (PDT) 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 1ECC21200D5 for ; Thu, 5 Sep 2019 14:49:44 -0700 (PDT) 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 01E58F8066A; Thu, 5 Sep 2019 17:49:13 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1567720152; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=WaEL4LtJAojj884v8mOTpqjsjWrWekrDxSb2HcFou7k=; b=8Kn4Vb2McvCDSyD1u7hybSfSDYq3BD8SibczsoewtXClZ8gZs7oqxNZv oIpNWVZ2I3z3JXH3oC3Mv9qbU1S5Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1567720152; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=WaEL4LtJAojj884v8mOTpqjsjWrWekrDxSb2HcFou7k=; b=BSaZ2/6rw6bSf06nD3wN8L6DNNAkC5Vp+CksmcKRnghANjU9YDoGXq77 4TfjD7MIQ6MBi6sWkiUWKcy2wFnc8eqhjAmdXIAFCFaKNCnOyqd9Zo46r5 gB5SGZ4pPrMJo6d5eUCEOKhPn8Ru0OY3z56oNuAlys1XOxzKLs+a3r3GTY DlYvRYJ1PWRvLnJkXXxV0dYjsrtpOSPJ7GUj0oNM/JlBncjIxAxBSeMKZW p3zfoAe9xO79FZfsHYGw+BUf6QR5Fvq4SdV5odyKKPG3N1eSkGLHpVNeVB IMxf2C78VRyXaqvLOrY0SWOQeN2NPXH3Z5SulU+hXf8b2MmMdodD8w== Received: from [10.150.39.182] (mobile-166-176-59-150.mycingular.net [166.176.59.150]) by interserver.kitterman.com (Postfix) with ESMTPSA id 683CCF80284; Thu, 5 Sep 2019 17:49:12 -0400 (EDT) Date: Thu, 05 Sep 2019 21:49:09 +0000 In-Reply-To: <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: 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, 05 Sep 2019 21:49:46 -0000 On September 5, 2019 8:22:27 PM UTC, Dave Crocker w= rote: >On 9/4/2019 6:28 AM, Dave Crocker wrote: >> ence my current view that: >>=20 >> 1=2E The change to DMARC should be limited to permitting the query for >the=20 >> organization domain to be anywhere in the DNS tree, including a TLD=2E= =20 >> Within DMARC this would not look like 'extra' mechanism=2E >>=20 >> 2=2E The mechanism that processes that query should be cast strictly as >a=20 >> PSL enhancement, independent of DMARC=2E > > >Trying to refine things further: > > > DMARC does not care about the PSL=2E > > What DMARC cares about is the Organizational Domain (OD), as a=20 >fallback when no DMARC record is found at the desired domain name=2E > > That is, PSL is literally outside the scope of DMARC=2E > > At the least, therefore, the DMARC specification should define a=20 >distinct interface to the outside functionality that tells DMARC where=20 >the OD is, which will return what suffix of the full domain name is the > >OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix > > The PSL-related side of that interface should be a separate=20 >specification, so that changes to its behavior -- such as has been=20 >happening with the introduction of ODs that are TLDs or are otherwise=20 >'above' where DMARC has been guessing the OD to be -- are isolated from > >DMARC=2E > > The current problems are that DMARC has embedded too much detail=20 >about the PSL world, yet DMARC has no involvement in that world=2E The=20 >current proposal embeds assumptions of PSL knowledge further, rather=20 >than separating PSL knowledge out=2E I don't think so=2E The draft defines PSD as org - 1=2E However you figu= re out org (currently PSL, but whatever)=2E If there's some place in the d= raft that doesn't say that, it's a mistake to fix=2E I'm currently writing on my phone, so draft review isn't easy=2E I'll loo= k at it again later today and report back on details=2E If you have specif= ic suggestions on making this clearer, please let me know=2E Scott K From nobody Thu Sep 5 18:02:52 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95A8120044 for ; Thu, 5 Sep 2019 18:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 G35EHenYnQlE for ; Thu, 5 Sep 2019 18:02:49 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 67B8F120043 for ; Thu, 5 Sep 2019 18:02:49 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 21so4162116otj.11 for ; Thu, 05 Sep 2019 18:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=bnvtTh+VJKyfvStw0Tfh52qrJFb9H5hlYa256w8V/P0=; b=KBoW9bdV1LXYc2T7XFmgSkkUrKaedF5oWH/qom9XS3DpfZYQf5f4+gY/TwudG7yvOg E75aWUbopAW/UpEvqvjsYGx0zt0IGHHldsHZujrwFcCv4l+U6UymWoeC++HDJxmvAtxw X6QNJYK2sAi4BXvZ6dNTCVcqqNZFP9S5DnPgMp9SIxPcraz+79tPRUAUNAh6u8rruOJM PRdtyAWs+DXc15Gw/311BBT0MrYcWoKvesTfA4Y1Ao0pquReDovUyxPTE2pzUFRR6BV5 HXVs00QSpK7c8+PRpu2/xyrRTFE6xMH2mzvbgI2lcNfoiJ2EoigzRbLIufNz7KBuc3vF qM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bnvtTh+VJKyfvStw0Tfh52qrJFb9H5hlYa256w8V/P0=; b=lfHKMK7aj7T36exEhWWRh9AfXuCDY7vJ8nGO5d0Guyob/SWYVi5UjPfmffTHD97CoK kujhZxwUIAgr386tQYUe00ic095jaOZFK9d+Aqc+A2o4G0mqVpuLZybMaDdQ5Mc3hGRJ do/n8pUB2ni7PXAwZWDn8xJCfD8pB1oOS9m76Y8S7tijdEURnAqPEC0ugQHxRPbsB7F1 AEPOI2S99eJ8Lm294emX/cl6opyJQK36BWqntmeyMEfY7DPsdaRz8DM39eYGcUlRLuNP PORMtTr34JoLSWJ06G/cSiBU6DZzA7X/BeOauv2MpwhR6P3TVyPy2bre07ILUf1ygroW M2XQ== X-Gm-Message-State: APjAAAWk7YZD1Y2BP62YrQAaroGFOY3OGaSk5vxYO/uYfwK/y5SifmjR jPFv6wXL6UDITr6I+o4KEEsJr04l X-Google-Smtp-Source: APXvYqw1iMPboE4sMXrLl9Rz8b2EN0hcUZ3SGKAI9Arc0KBeqWOtK8V+HhVh3vcrjwNXSAx2cribDw== X-Received: by 2002:a9d:152:: with SMTP id 76mr5368195otu.18.1567731768426; Thu, 05 Sep 2019 18:02:48 -0700 (PDT) Received: from ?IPv6:2600:1700:a3a0:4c80:d981:1a68:7c5f:511c? ([2600:1700:a3a0:4c80:d981:1a68:7c5f:511c]) by smtp.gmail.com with ESMTPSA id n22sm1290375otk.28.2019.09.05.18.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 18:02:47 -0700 (PDT) To: Scott Kitterman , dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> From: Dave Crocker Message-ID: <1e1aa6bd-82cb-5ce0-290c-c3eaf8566c4d@gmail.com> Date: Thu, 5 Sep 2019 18:02:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 06 Sep 2019 01:02:51 -0000 On 9/5/2019 2:49 PM, Scott Kitterman wrote: > I don't think so. The draft defines PSD as org - 1. Writing a definition for something you don't control and that can (and has) change tends to be problematic. As it is here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Sep 5 18:28:50 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6833F1200A3 for ; Thu, 5 Sep 2019 18:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=JXfQs96P; dkim=pass (2048-bit key) header.d=kitterman.com header.b=DUVGX0Zu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZMct54Pbhpc for ; Thu, 5 Sep 2019 18:28:47 -0700 (PDT) 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 151CB120043 for ; Thu, 5 Sep 2019 18:28:47 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 062E3F8066A for ; Thu, 5 Sep 2019 21:28:16 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1567733295; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=9jr4hcU/DiZcAR/Znu4Nw6JLZ2P7l2bv6K6sVFMeFOE=; b=JXfQs96PPw5A4AJGwONTomEQDe0DbjLpErymShjAMAjy63kJxyrDf5D7 eeKTPJPERwJ+E5BM6WL+94c7qw5TCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1567733295; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=9jr4hcU/DiZcAR/Znu4Nw6JLZ2P7l2bv6K6sVFMeFOE=; b=DUVGX0ZubLn6fuQ9JlhPM9L89KJPnLl1+nXmfab08fMcay2Kc9cg3qki lcti21xQ26ozU2zKX0u5Z7c4G8mMfGTZNdsW4ibW73sbbJSjQn8dFlU3ss 22/Wc0+6kqvgSdCrYNHduhyITV91DVRtZgdZQx2r7bA+dmfzS/WxDaL0ZP FBYz1tOvX5Qdglx3gK1f75wHdJ5lpE3tq735k/Cy4BMzhkLsZQ85hlpdD3 dJXL1D84aTNPXy3ZY2qjkAvYAeSx2W1KPkRPhrfC81d7Nk8GpRyPavkZtY 8aHzo7TT2Jb2xO7hluYx1NJF5gXG9eHzvIwCKYSR2Idm/5hiKWqDLw== Received: from l5580.localnet (unknown [IPv6:2600:380:763d:e46:d882:bd7e:9619:debb]) by interserver.kitterman.com (Postfix) with ESMTPSA id 5F6E0F801E5 for ; Thu, 5 Sep 2019 21:28:15 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 05 Sep 2019 21:28:16 -0400 Message-ID: <2071051.MakTsmbkZq@l5580> In-Reply-To: <1e1aa6bd-82cb-5ce0-290c-c3eaf8566c4d@gmail.com> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <1e1aa6bd-82cb-5ce0-290c-c3eaf8566c4d@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: Fri, 06 Sep 2019 01:28:49 -0000 On Thursday, September 5, 2019 9:02:45 PM EDT Dave Crocker wrote: > On 9/5/2019 2:49 PM, Scott Kitterman wrote: > > I don't think so. The draft defines PSD as org - 1. > > Writing a definition for something you don't control and that can (and > has) change tends to be problematic. > > As it is here. Now that I'm at a computer where I can review the draft as it stands (as opposed to the draft as I remember it), I agree the current definition is problematic. However, I think it's easily fixable. Here's where I see a problem: > 2.3. Longest PSD > > The longest PSD is the PSD matching more labels in the domain name > under evaluation than any other public suffix list entry. As you suggest, it leverages PSL in a way that's sub-optimal at best. Fortunately I think we can fix it. I'd suggest this instead: 2.3. Longest PSD The longest PSD is the Organizational Domain with one label removed. With that change, PSD DMARC makes no claims based on use of the PSL that aren't inherited from DMARC. How's that? Scott K From nobody Sun Sep 8 04:22:36 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674F12008A for ; Sun, 8 Sep 2019 04:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AD4b4eLrgVv for ; Sun, 8 Sep 2019 04:22:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F98120074 for ; Sun, 8 Sep 2019 04:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1567941751; bh=SeONTV7IqBtKNxqoxUNptMJTcod+QS9q3l4uk8V0Dpg=; l=893; h=To:References:From:Date:In-Reply-To; b=DgzVd6TZ2WCl42Ju0pqwghtFaC6M/jPuUr4veniE2PmR+4rGaIfzUCJVB7+IFxild tV4jYPNTt1H6COyz3wzdhZ7vi3RQmHaz7hyXWEWyCaLvHKhJ6Rzp+Yja77yiqXKGeq hg9pPEFmAMW9pgB9goxDsZtcOFi84MEVU2ROBPScRM0tX5eb9iZ0lIN2p8L/Q Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC081.000000005D74E476.000052AD; Sun, 08 Sep 2019 13:22:30 +0200 To: dmarc@ietf.org References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <51219bbd-3785-e6bb-414a-bd564b6c856d@gmail.com> <2922527.kgd3cNqxNO@l5580> <3d886a18-7dc2-2c7a-4d0a-8c1ae0bfb4c5@tana.it> <7788EC9D-D4F7-4B00-863D-7289E8B2AB41@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Sun, 8 Sep 2019 13:22:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <7788EC9D-D4F7-4B00-863D-7289E8B2AB41@kitterman.com> 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: Sun, 08 Sep 2019 11:22:35 -0000 On Thu 05/Sep/2019 15:35:29 +0200 Scott Kitterman wrote: >>> If we didn't care about privacy, this would be easy. That's the hard >>> part that does not have a clear solution. One thing that is clear is >>> that it's not the PSL. PSL is a collector of assertions from operators, >>> so it fails to meet the attributes laid out in A.1.>> >> Failure reports are considerably less implemented than aggregate ones. >> The current spec doesn't mention any privacy risk in its Security >> Considerations section. However, some concern must exist, otherwise the >> difference in implementations cannot be easily explained. The I-D at hand >> touches on this point marginally. A general consideration would better >> fit in DMARCbis.> > That's because there's an entire separate section on privacy considerations. My bad English. By "current spec" I meant rfc7489. Best Ale -- From nobody Mon Sep 9 11:30:04 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AF312022D for ; Mon, 9 Sep 2019 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 8s0qxUYZt5vD for ; Mon, 9 Sep 2019 11:30:00 -0700 (PDT) Received: from USAT19PA23.eemsg.mail.mil (USAT19PA23.eemsg.mail.mil [214.24.22.197]) (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 39F591200A4 for ; Mon, 9 Sep 2019 11:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1568053800; x=1599589800; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/JzAp+GDfu0IvOt5kbdpT6YD3lhLkrdVvIivwo1ZF+k=; b=QjyhY4ZZuUPqsB4qPh5frLDCVUOTktH5to4eMycgBlcfKWR8N6mRIsXB Fuq/p3NUfo7wwO14U6ZTrxc/zKFtOvPEK7R3Zi+JwQ3rW4gwQ8f5zuBd6 oJkQBEHseGjktWfbHDvf4kOxvloVMB4Rw83B1aJxszfMUrfVGlAv0ds6O y4QMxdxDJE1vjmWrjBL2C8pDTydsjFyXtnAIVp339Zi67mQUrvKBfenJB tGVx2EiGorH5xN3JT9OeoPtIYvpUR51fU6wjM9+kZay0W5Zm3rfL+JR7i D2qGg2bEfm1rmyHX8CAQ7pPokX98fv9xmuDgLdib5i5+4PxrU81sQ0U5k Q==; X-EEMSG-check-017: 25807616|USAT19PA23_ESA_OUT04.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.64,486,1559520000"; d="scan'208";a="25807616" Received: from edge-mech02.mail.mil ([214.21.130.231]) by USAT19PA23.eemsg.mail.mil with ESMTP; 09 Sep 2019 18:29:54 +0000 Received: from UMECHPAOR.easf.csd.disa.mil (214.21.130.161) by edge-mech02.mail.mil (214.21.130.231) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 9 Sep 2019 18:29:40 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.227]) by umechpaor.easf.csd.disa.mil ([214.21.130.161]) with mapi id 14.03.0468.000; Mon, 9 Sep 2019 18:29:40 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: "'dmarc@ietf.org'" Thread-Topic: [dmarc-ietf] Comment on draft-ietf-dmarc-psd Thread-Index: AQHVZOWUCCpheWHDpkmEkg0ixDoLvKcjqQ/g Date: Mon, 9 Sep 2019 18:29:40 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC0311DED960D@UMECHPA7D.easf.csd.disa.mil> References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@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: Mon, 09 Sep 2019 18:30:02 -0000 T24gU2VwdGVtYmVyIDUsIDIwMTkgODoyMjoyNyBQTSBVVEMsIERhdmUgQ3JvY2tlciA8ZGNyb2Nr ZXJAZ21haWwuY29tPiB3cm90ZToNCj5PbiA5LzQvMjAxOSA2OjI4IEFNLCBEYXZlIENyb2NrZXIg d3JvdGU6DQo+PiBlbmNlIG15IGN1cnJlbnQgdmlldyB0aGF0Og0KPj4gDQo+PiAxLiBUaGUgY2hh bmdlIHRvIERNQVJDIHNob3VsZCBiZSBsaW1pdGVkIHRvIHBlcm1pdHRpbmcgdGhlIHF1ZXJ5IGZv cg0KPnRoZQ0KPj4gb3JnYW5pemF0aW9uIGRvbWFpbiB0byBiZSBhbnl3aGVyZSBpbiB0aGUgRE5T IHRyZWUsIGluY2x1ZGluZyBhIFRMRC4gDQo+PiBXaXRoaW4gRE1BUkMgdGhpcyB3b3VsZCBub3Qg bG9vayBsaWtlICdleHRyYScgbWVjaGFuaXNtLg0KPj4gDQoNCkFuIGFkZGl0aW9uYWwgRE1BUkMg cXVlcnkgYXQgb25lIGxldmVsIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBkb21haW4gc2hvdWxk IGJlIGFuIGFkZGl0aW9uYWwgcXVlcnksIHJhdGhlciB0aGFuIG1vcmUgc2ltcGx5IGJlaW5nIGFi bGUgdG8gaGF2ZSB0aGUgb3JnYW5pemF0aW9uYWwgZG9tYWluIGhpZ2hlciB1cCB0aGUgRE5TIHRy ZWUgYW5kIG5vdCBoYXZpbmcgYW4gZXh0cmEgRE1BUkMgcXVlcnkuICBUaGlzIGlzIHBhcnRpY3Vs YXJseSB0aGUgY2FzZSBmb3IgcmVwb3J0aW5nIHNvIHRoYXQgZXZlbiBpZiB0aGUgb3JnYW5pemF0 aW9uYWwgZG9tYWluIGFuZCB0aGUgUFNEIGRvbWFpbiBvbmUgbGV2ZWwgYWJvdmUgdGhlIG9yZ2Fu aXphdGlvbmFsIGRvbWFpbiBoYXZlIHRoZSBzYW1lIERNQVJDIHJlcXVlc3RlZCBoYW5kbGluZyBw b2xpY3ksIHRoZXkgY2FuIGhhdmUgZGlmZmVyZW50IERNQVJDIHJlcG9ydGluZyBhZGRyZXNzZXMu DQoNCkZvciBEb0QgYW5kIHRoZSAubWlsIFRMRCwgd2Ugc3VwcG9ydCB0aGlzIFBTRCBETUFSQyBl ZmZvcnQgYW5kIGJlbGlldmUgdGhhdCBpdCB3b3VsZCBiZSBiZW5lZmljaWFsIHRvIGhhdmUgYW4g YWRkaXRpb25hbCBETUFSQyBxdWVyeSBhdCB0aGUgUFNEIGxldmVsLg0KDQpUaGFua3MsDQotRXJp Yw0KDQpFcmljIENodWRvdw0KRG9EIEN5YmVyc2VjdXJpdHkgTWl0aWdhdGlvbnMNCmVyaWMuYi5j aHVkb3cuY2l2QG1haWwubWlsDQoNCg0K From nobody Mon Sep 9 15:15:38 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6420C12087C for ; Mon, 9 Sep 2019 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2bjiHf99mt8 for ; Mon, 9 Sep 2019 15:15:31 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 A11BD12086B for ; Mon, 9 Sep 2019 15:15:31 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id n6so4885721uaq.3 for ; Mon, 09 Sep 2019 15:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9nUCS7R3L0wUEo6bbcO4R9sklIgZPXJQsOz412nNAHk=; b=Z1vIZdVZkEriUJepCxMLBy1YEON+FvsM7svau8NlHVf0eD9pxhNBDn+ui8Q5JNWGwi h7lLjBwEOVQhvRK6K9VVFUbc+cpHYaAJQhLcl5y2GwEs4U2JXEuXTkRYhRog3k0tGLLG NDYEncyxF/DdbCme/Dx+4eervMa/V7ChhpAQU5IU47KjnGRFE6CT6TV8lnGbylXGFgVI z1B4nMJ88wFqzMLR8jEMhZIcmFAvHzXfg5QNKFDqYxE3Ury6iRPBKeF+zwhd3TydVnq2 Wnj1hkVXBTnSlUiaXSWENXzXS2nJ/oDZeaQDji10Kx2yw2QzT2dAhpbDhB9ufFljEhyn V+8A== 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=9nUCS7R3L0wUEo6bbcO4R9sklIgZPXJQsOz412nNAHk=; b=FbEqBu4v2ZV4ss/ShOhceQnvwxmAQf76ecNLEBMvV8EZUewaygRBYYg9HYJbnEOLF1 aaERVpyeFyfEm9YcygUC1k1/g4OzFYgq6iFmMOtHJrn8/YxRu2FjEBZFQpcg/ZW0oRvc xps8ExlHBkucLVEnrsvNjnM+SNxsU1OaDoKowrH3AobwTRrnyKtjlNd8RUCfCxvAtarR B62S/LVIFVypPeymnYrqfmyFqRSPwPM/Rd9DWKjoOCojcrFcOMra0MAir1OzJL2LNBIT NdCE8tPLMP7m2od84KZyMl1AHN8UWcwONPy2qa/Qm/p4BDjlfQ8/mJ6Ha0LqKzEQKax+ Wn8g== X-Gm-Message-State: APjAAAWRRQQiowY+w1A/Av8gOofQGtE4hE8ep9d8QAwCZHaKobiSMRUq z3TufyxaGO3YTX+A9jVey0wBOQHpbbEFDzlT5eEDKx+h1w== X-Google-Smtp-Source: APXvYqyzWXgWMD/TgHtGhuXWJrYeiJTEgnoAqf7GAvOkAvbX784hk5SEjrnQSJrt/AIyp7HaD9/eniOemC4zAE8dQiA= X-Received: by 2002:ab0:270a:: with SMTP id s10mr11766322uao.66.1568067329862; Mon, 09 Sep 2019 15:15:29 -0700 (PDT) MIME-Version: 1.0 From: Brandon Long Date: Mon, 9 Sep 2019 15:15:19 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002e9315059226204f" Archived-At: Subject: [dmarc-ietf] PSL thoughts 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, 09 Sep 2019 22:15:37 -0000 --0000000000002e9315059226204f Content-Type: text/plain; charset="UTF-8" Given that DMARC depends on PSL and the ongoing discussion about it in the PSD threads, I thought this doc would be of interest: https://github.com/sleevi/psl-problems/blob/master/README.md Given we're dealing with trying to close something that's default open, I'm not sure there's a great alternative solution, but it at least puts into perspective some of the web folk's thinking on the subject, since they maintain the PSL. Brandon --0000000000002e9315059226204f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002e9315059226204f-- From nobody Tue Sep 24 07:16:15 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9C12008D for ; Tue, 24 Sep 2019 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hx80eVH--6Z for ; Tue, 24 Sep 2019 07:16:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493A5120072 for ; Tue, 24 Sep 2019 07:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1569334569; bh=buDv11Ey+HWV2yX6hL1V+yuSvGdph34uTnlP0n0OJn0=; l=1831; h=To:From:Date; b=ApN8nP0mil/QSieP1OQ3Ut0CUVN2mvy+DFmxYE+7fqxBjRji5tpNq2wQCjtaibuBA ia8doWFDMKYUIamhCNcC9hSsgePI8EyS4cZQwHT4RaUB1WI9e25F/m3r4gxwTfOOx6 ScnxC9MX/qqN3SayUY4dJ7L3+XR/91ZWPkzbWljUd1yPs+5wWdj6/aEuN4kmZ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC079.000000005D8A2528.000002AE; Tue, 24 Sep 2019 16:16:08 +0200 To: dmarc@ietf.org From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <4103172c-108a-e146-b660-d7a72e24a42b@tana.it> Date: Tue, 24 Sep 2019 16:16:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-686-1569334568-0001-2" Content-Language: en-US Archived-At: Subject: [dmarc-ietf] Implementing psddmarc 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, 24 Sep 2019 14:16:13 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-686-1569334568-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I added psddmarc to the latest zdkimfilter. After some thought, I chose to use and distribute a file like the one attached. Two reasons for doing so are as follows: 1. Avoid to invent yet another file format, specifying header line, initial dot, comments, and the like. 2. Reuse the library calls already available for parsing and searching the PSL. On the second call, the software passes the organizational domain resulting from the first call, and thus retrieves the "super organizational" domain, if any. The file only contains the domain from psddmarc.org registry which actually sports a DMARC record. While the experiment is ongoing, the file will have to be updated. It would be convenient, if more implementations will find the above reasons convincing, if such a list would be maintained and distributed by psddmarc.org along with (or instead of) the csv format. After all, since this list extends the PSL, keeping the same format may make some sense. Best Ale -- --=_north-686-1569334568-0001-2 Content-Type: text/plain; charset=utf-8; name="tentative-psddmarc-list.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tentative-psddmarc-list.txt" Ly8gcHNkZG1hcmMub3JnCi8vCi8vIFRoaXMgbGlzdCBmb2xsb3dzIHRoZSBzYW1lIHJ1bGVz IHNwZWNpZmllZCBmb3IgUFNMOgovLyBodHRwczovL3B1YmxpY3N1ZmZpeC5vcmcvbGlzdC8K Ly8gCgoKLy8gbG9uZ2VzdCBwdWJsaWMgc3VmZml4IGhhdmUgNSBsYWJlbHMKLy8gKGUuZy4g YXBwLm9zLnN0Zy5mZWRvcmFwcm9qZWN0Lm9yZykKCiouKi4qLiouKi4qLiouKgohZ292LnVr Cg== --=_north-686-1569334568-0001-2-- From nobody Wed Sep 25 14:23:09 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6B6120026 for ; Wed, 25 Sep 2019 14:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=AnKDqb6J; dkim=pass (2048-bit key) header.d=kitterman.com header.b=omrRFpvQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p4AEi80x_hP for ; Wed, 25 Sep 2019 14:23:06 -0700 (PDT) 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 5CAB5120018 for ; Wed, 25 Sep 2019 14:23:06 -0700 (PDT) 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 1FB1CF805B3 for ; Wed, 25 Sep 2019 17:23:05 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1569446584; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=QB30GIbRv+HsUMVQ/I6KuAdjuxxbAqbUnV129DW9DlI=; b=AnKDqb6JBTGueWf8Z98dyfU1wGyUbyyFgdwLsQLODsX5td7hliQ7GpSM A5/FgLq78vDIsmalcNLYQPkebeajCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1569446584; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=QB30GIbRv+HsUMVQ/I6KuAdjuxxbAqbUnV129DW9DlI=; b=omrRFpvQaGabOedPASlFZCP+j+WFZmPxCpQYmJggWLYMcTVRy/AeT1ho rO/rR3NCSNARfJCHX4cldze96lGan4Lzvm6TrOrawgp+lHH8x8Trj4kg6O 0wHdhOU1DC1Tdav4EurOqupoV5+IXp0fZX5e55riglO9XEy7U0zzMUHPN1 nf1UMd/8C6JwUF4bR89c8SGmqSY5T6t3WXTQ/6YpfK2FQ/bTZJ3ylnsGQw NLcOoEqdVrQrcaixq8j5a/ldDTHh+xMFQEFr7wPwpH6uUS5gK7YUdQ76vx oM9W/O9yEbF18sZmQcd8fc0kCTsOPeShV5RHh48FNMYrvrKBCEwQfA== 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 D8AB7F8035E for ; Wed, 25 Sep 2019 17:23:04 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 25 Sep 2019 17:23:04 -0400 Message-ID: <9571084.N2IzJBRSXg@l5580> In-Reply-To: <4103172c-108a-e146-b660-d7a72e24a42b@tana.it> References: <4103172c-108a-e146-b660-d7a72e24a42b@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Implementing psddmarc 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, 25 Sep 2019 21:23:08 -0000 On Tuesday, September 24, 2019 10:16:08 AM EDT Alessandro Vesely wrote: > Hi all, > I added psddmarc to the latest zdkimfilter. > > After some thought, I chose to use and distribute a file like the one > attached. Two reasons for doing so are as follows: > > 1. Avoid to invent yet another file format, specifying header line, initial > dot, comments, and the like. > > 2. Reuse the library calls already available for parsing and searching the > PSL. > > On the second call, the software passes the organizational domain resulting > from the first call, and thus retrieves the "super organizational" domain, > if any. The file only contains the domain from psddmarc.org registry which > actually sports a DMARC record. While the experiment is ongoing, the file > will have to be updated. > > It would be convenient, if more implementations will find the above reasons > convincing, if such a list would be maintained and distributed by > psddmarc.org along with (or instead of) the csv format. After all, since > this list extends the PSL, keeping the same format may make some sense. I think we should include this in the options for the experiment about how to keep track of which PSDs are doing PSD DMARC. Can you provide what you'd like me to add about your implementation for Appendix C? Scott K From nobody Fri Sep 27 04:20:11 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97C3120805 for ; Fri, 27 Sep 2019 04:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI3zMrOl_MR8 for ; Fri, 27 Sep 2019 04:20:08 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACCE120801 for ; Fri, 27 Sep 2019 04:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1569583205; bh=Eb4vTrqeHITysa/iH0cBlmIlSuHkXuspv1w5u7SeF5Y=; l=1697; h=To:References:From:Date:In-Reply-To; b=Da5gcI/S5aXdk3h1F9SFHEnqpsGDwor98sOk7Ii/xYtl81KkZt8L+RB4j473p41Z4 BrX3RLXCLuooeIZjLFY3475ATXsqECCfbW6PwsapDG/Lftco168Hq8iRSXYgusfki/ BLszNTsxNE0HjamoEjyzZ5WHX+pDzpb7fOs+aZUq5pMNp75Ew2rdWkvYLfzR0 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.101] ([5.170.70.162]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005D8DF064.00003CDE; Fri, 27 Sep 2019 13:20:04 +0200 To: dmarc@ietf.org References: <4103172c-108a-e146-b660-d7a72e24a42b@tana.it> <9571084.N2IzJBRSXg@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Fri, 27 Sep 2019 13:19:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9571084.N2IzJBRSXg@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Implementing psddmarc 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, 27 Sep 2019 11:20:10 -0000 On Wed 25/Sep/2019 23:23:04 +0200 Scott Kitterman wrote: > On Tuesday, September 24, 2019 10:16:08 AM EDT Alessandro Vesely wrote: >> Hi all, >> I added psddmarc to the latest zdkimfilter. >> >> After some thought, I chose to use and distribute a file like the one >> attached. Two reasons for doing so are as follows: >> >> 1. Avoid to invent yet another file format, specifying header line, initial >> dot, comments, and the like. >> >> 2. Reuse the library calls already available for parsing and searching the >> PSL. >> >> On the second call, the software passes the organizational domain resulting >> from the first call, and thus retrieves the "super organizational" domain, >> if any. The file only contains the domain from psddmarc.org registry which >> actually sports a DMARC record. While the experiment is ongoing, the file >> will have to be updated. >> >> It would be convenient, if more implementations will find the above reasons >> convincing, if such a list would be maintained and distributed by >> psddmarc.org along with (or instead of) the csv format. After all, since >> this list extends the PSL, keeping the same format may make some sense. > > I think we should include this in the options for the experiment about how to > keep track of which PSDs are doing PSD DMARC. > > Can you provide what you'd like me to add about your implementation for > Appendix C? If needed, a short characterization can be as follows: The zdkimfilter module is a separately available add-on to Courier-MTA. Mostly used for DKIM signing, it can be configured to also verify, apply DMARC policies, and send aggregate reports. Best Ale -- From nobody Sat Sep 28 14:38:43 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AA7120025 for ; Sat, 28 Sep 2019 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=rNUqbHUC; dkim=pass (2048-bit key) header.d=kitterman.com header.b=r/j2XE5N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JnFkQ0ZCsxi for ; Sat, 28 Sep 2019 14:38:39 -0700 (PDT) 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 5F33712009E for ; Sat, 28 Sep 2019 14:38:39 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 4077CF8020C for ; Sat, 28 Sep 2019 17:38:38 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1569706718; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=ImFCH6VRykiXaufr0YXeVu1eELadNBTEjGRcFgDXJew=; b=rNUqbHUCUc84doDrPoc9v8T5q3k5LOwyScUyoiAYKSqYX3VgrR5lbzI1 tc80TinljJqJ8jEZkBjqs4uEDZgZAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1569706718; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=ImFCH6VRykiXaufr0YXeVu1eELadNBTEjGRcFgDXJew=; b=r/j2XE5NqC8pGCIJzkAtdeUiYstG2F4n+S18gVhbN4YP8+vmI/zF6LiK h6IOTUil4iUokAA2tf6VAymZHbxaGZrVwyqKVNIUj7+jmHKN4J5Ow+Zwcm DwlL6uGvHacTGH3jjFf9QFFDyqWNGnUHhOThKJ9taWsly3NjlU2egGflcc EhZBFH1XK5xtHtHwlGb5VM7L9vRjBHxAVWbXYf3pMXd6ONe0uwSPJd2//j PGbjta8aznEAcC+osEzaHmP2xlDqqRYBGEcVXnP+fasvWR9ZHOuI3bx1JS X3T9ERO2PepohDjlRis8Q960vSczjPhNRM/QTJYbKkDbxq/wrkELiA== 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 03625F8020B for ; Sat, 28 Sep 2019 17:38:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 28 Sep 2019 17:38:37 -0400 Message-ID: <2080369.Hr1xgu6sVx@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status 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, 28 Sep 2019 21:38:41 -0000 WGLC started on 2019-06-26. It ended 2019-07-17. 2019-06-26: WG Secretary called for additional discussion on three topics: 1. What further context is needed in the introduction 2. If explicit call outs to ICANN/limited operator capacity to implement are needed 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs By the end of the WGLC period, after a slow start, there was a vigorous discussion on all these issues and (with a few days post-WGLC for the np= tag discussion to finish) moved towards what was in my judgment a reasonably solid consensus. All issues that people brought up were addressed by the WG (including inclusion of some recommended editorial changes made before WGLC that hadn't made it into the draft). A new revision addressing the WGLC discussion (-05) and document shepherd comments was uploaded 2019-07-27. Post WGLC discussion: 2019-07-22: A question was brought up if the draft should include hard requirements to forbid mail from non-existent domains. The WG concluded that independent of the wisdom of such a rule, it was out of scope for the WG. 2019-07-27: A set of editorial nits were provided against -05. 2019-07-31: Additional document shepherd feedback based on revisions provided in -05 and earlier comments. 2019-08-09: New revision (-06) published fixing editorial nits and incorporating additional changes based on document shepherd feedback. 2019-08-10: Comments on -06 from Alessandro Vesely, but no suggested changes. 2019-08-13: Comments on the general PSD DMARC concept from Dave Crocker. 2019-09-03: WG Chair feedback on 2019-08-13 comments, some discussion ensues. 2019-09-09: Discussion concludes. It appears to me that the upshot of the discussion is that the Section 2.3 Longest PSD definition needs to be updated. All other issues have been addressed. 2019-09-24: Alessandro Vesely reports having implemented PSD DMARC in zdkimfilter for Courier MTA using an alternative data format for PSD DMARC participants based on the PSL format. Based on the post-WGLC discussion, I believe an updated draft before IETF last call is appropriate with three changes: 1. Updated Longest PSD definition: > 2.3. Longest PSD > > The longest PSD is the Organizational Domain with one label removed. 2. Addition of the PSL data format to Appendix B (it would be B.3). I haven't drafted text yet, but I don't expect it to be controverisial. 3. Add zdkimfilter to Appendix C (also didn't make text yet). Unless someone tells me otherwise, I plan to go ahead with those changes. Scott K From nobody Sun Sep 29 05:05:22 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4442B120099 for ; Sun, 29 Sep 2019 05:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Lj5lss2vz_2z for ; Sun, 29 Sep 2019 05:05:17 -0700 (PDT) Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) (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 5CE03120018 for ; Sun, 29 Sep 2019 05:05:17 -0700 (PDT) Date: Sun, 29 Sep 2019 12:05:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1569758714; bh=GCrIwrZ1xxkMG1zsHD92EGWilVsD9GZz6PQvs+u6nPc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=RJEobQNZdSx+CEFq+ZnwsjJk4jj89IFsL0GQf7yDYMfNT12R8PRsF5RnFMxnvMDeY Iz+R7BQsoZtOx9UQ4sIT7OEG4ZIHTWmvbIAlUV/HW2vAsRlsNGVXVfoiuG6iJHmei0 UlavSlQ7kysTJwJK094AbBc0KPkhjh0mowYNnjaE= To: "dmarc@ietf.org" From: Jane Moneypenny Reply-To: Jane Moneypenny Message-ID: In-Reply-To: <2080369.Hr1xgu6sVx@l5580> References: <2080369.Hr1xgu6sVx@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] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status 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, 29 Sep 2019 12:05:20 -0000 Regarding: 2.6. Non-existent Domains For DMARC purposes, a non-existent domain is a domain for which there is an= NXDOMAIN or NODATA response for A, AAAA, and MX records. Comments: - sometimes a domain used for mailing purposes does not have a MX record - = I am not sure if 'and' is appropriate word here, - question: what if there is a CNAME record?, - email receivers could/should perform reverse DNS lookup, however they do = not - as a result, an email from (both: Envelope and Mail from), is accepte= d by the MTAs, - today, an email =E2=80=98from=E2=80=99 (Envelope and Mail) NXDOMAIN is ac= cepted by vast majority of MTAs, and SPF check result is =E2=80=9Cspf=3Dneu= tral=E2=80=9D (in general), same with non-existent sub-domains (even if the= re is DMARC in place a message from non-existent sub-domain could be succes= sfully delivered). There is a solution for non-existent subdomains: Wildcard SPF. Wildcard SPF= covers sub-domains (if there is no other RR for such sub-domain), and (in = general) it works with DMARC. For example: *.example.com IN TXT v=3Dspf1 -all together with example.com IN TXT v=3DDMARC1; p=3Dreject; Covers each and every NX-sub-domain, and it works pretty well. Currently proposed solution, even with the 'np' tag, may not work. It could= be rather fatally flawed. That being said, we should consider (for PSDs) a solution similar to a Wild= card SPF, if we want PSD-DMARC work as it should. And, because a Wildcard SPF is a TXT - not A, AAAA, MX - record, and it doe= s not mess with the definition (2.6. Non-Existent Domains). Sincerely, Mnpn. =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 Saturday, September 28, 2019 11:38 PM, Scott Kitterman wrote: > WGLC started on 2019-06-26. It ended 2019-07-17. > > 2019-06-26: WG Secretary called for additional discussion on three topics= : > > 1. What further context is needed in the introduction > 2. If explicit call outs to ICANN/limited operator capacity to implement= are > needed > > 3. If an np=3D tag is needed to allow PSD functioning for only NXDOMAINs > > By the end of the WGLC period, after a slow start, there was a vigoro= us > discussion on all these issues and (with a few days post-WGLC for the= np=3D tag > discussion to finish) moved towards what was in my judgment a reasona= bly solid > consensus. All issues that people brought up were addressed by the WG > (including inclusion of some recommended editorial changes made befor= e WGLC > that hadn't made it into the draft). > > A new revision addressing the WGLC discussion (-05) and document shep= herd > comments was uploaded 2019-07-27. > > Post WGLC discussion: > > 2019-07-22: A question was brought up if the draft should include har= d > requirements to forbid mail from non-existent domains. The WG conclud= ed that > independent of the wisdom of such a rule, it was out of scope for the= WG. > > 2019-07-27: A set of editorial nits were provided against -05. > > 2019-07-31: Additional document shepherd feedback based on revisions = provided > in -05 and earlier comments. > > 2019-08-09: New revision (-06) published fixing editorial nits and > incorporating additional changes based on document shepherd feedback. > > 2019-08-10: Comments on -06 from Alessandro Vesely, but no suggested = changes. > > 2019-08-13: Comments on the general PSD DMARC concept from Dave Crock= er. > > 2019-09-03: WG Chair feedback on 2019-08-13 comments, some discussion= ensues. > > 2019-09-09: Discussion concludes. It appears to me that the upshot of= the > discussion is that the Section 2.3 Longest PSD definition needs to be= updated. > All other issues have been addressed. > > 2019-09-24: Alessandro Vesely reports having implemented PSD DMARC in > zdkimfilter for Courier MTA using an alternative data format for PSD = DMARC > participants based on the PSL format. > > Based on the post-WGLC discussion, I believe an updated draft before = IETF last > call is appropriate with three changes: > > 4. Updated Longest PSD definition: > > > 2.3. Longest PSD > > The longest PSD is the Organizational Domain with one label removed. > > 2. Addition of the PSL data format to Appendix B (it would be B.3). I > haven't drafted text yet, but I don't expect it to be controverisial. > > 3. Add zdkimfilter to Appendix C (also didn't make text yet). > > Unless someone tells me otherwise, I plan to go ahead with those changes. > > Scott K > > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Sep 29 14:14:57 2019 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF312008F for ; Sun, 29 Sep 2019 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Bi71KgcO; dkim=pass (2048-bit key) header.d=kitterman.com header.b=IivyMJb8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYoak6Ri29Ni for ; Sun, 29 Sep 2019 14:14:54 -0700 (PDT) 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 505FE120013 for ; Sun, 29 Sep 2019 14:14:54 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 43F58F805C3 for ; Sun, 29 Sep 2019 17:14:22 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1569791662; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/74ms0XbQreyD9CBM2Av8NNROm+pMlIARueq3VUXxk8=; b=Bi71KgcOSFTcljdkRXPQZJE3D81zyAhWdqQSfhhxbgrNY2hpOj2RAOq7 FEl8G63PhRPW6mNvjq1JrAZiXC+mCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1569791662; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=/74ms0XbQreyD9CBM2Av8NNROm+pMlIARueq3VUXxk8=; b=IivyMJb8yU24+2+TKaVvq8DokOZjm0aMlsvG4NrDiW0vP3agE3hhU/p6 LTta9zuFZ/0g4iNqP5YjlKXTDNqswx5y51C6ddApQBaxsAo/S0/hEm8bUj Y4RTf1nfn/wsch1zSPEYEGC9fzDd2Xwov6i7/hnwG6okRasBCr2eeom2Cr Xooh5kkJAWI7/j1vQ3NwNgrvnnbB7cZUlMlfKGgiHlbJRz9Y7fiRnImJWz 9ozeBJ2MYQSjmbn89FjwZzT/YCjUMvWaspQn0iWhwgXKi/5/S9PwIsrlKF h5MJvi1hTufo1dt6AqRSSvKMjpDR6gr4FCfIfvKXpzbn49uLOHHYhg== 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 037A9F801A6 for ; Sun, 29 Sep 2019 17:14:21 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Sun, 29 Sep 2019 17:14:21 -0400 Message-ID: <1841606.cQK2ovSRYz@l5580> In-Reply-To: References: <2080369.Hr1xgu6sVx@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status 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, 29 Sep 2019 21:14:56 -0000 On Sunday, September 29, 2019 8:05:07 AM EDT Jane Moneypenny wrote: > Regarding: > 2.6. Non-existent Domains > For DMARC purposes, a non-existent domain is a domain for which there is = an > NXDOMAIN or NODATA response for A, AAAA, and MX records. >=20 > Comments: > - sometimes a domain used for mailing purposes does not have a MX record = =2D I > am not sure if 'and' is appropriate word here, - question: what if there = is > a CNAME record?, Yes. The way it's written, if any of A, AAAA, or MX give some answer other= =20 than NXDOMAIN or NODATA, then the domain exists. As previously discussed=20 during WGLC, CNAMES would be followed prior to such a determination, so the= =20 existence check would, correctly, be for the target of the CNAME, no issue. > - email receivers could/should perform reverse DNS lookup, however they do > not - as a result, an email from (both: Envelope and Mail from), is > accepted by the MTAs, - today, an email =E2=80=98from=E2=80=99 (Envelope = and Mail) NXDOMAIN > is accepted by vast majority of MTAs, and SPF check result is =E2=80=9Csp= f=3Dneutral=E2=80=9D > (in general), same with non-existent sub-domains (even if there is DMARC = in > place a message from non-existent sub-domain could be successfully > delivered). >=20 > There is a solution for non-existent subdomains: Wildcard SPF. Wildcard S= PF > covers sub-domains (if there is no other RR for such sub-domain), and (in > general) it works with DMARC. For example: > *.example.com IN TXT v=3Dspf1 -all > together with > example.com IN TXT v=3DDMARC1; p=3Dreject; > Covers each and every NX-sub-domain, and it works pretty well. >=20 > Currently proposed solution, even with the 'np' tag, may not work. It cou= ld > be rather fatally flawed. >=20 > That being said, we should consider (for PSDs) a solution similar to a > Wildcard SPF, if we want PSD-DMARC work as it should. >=20 > And, because a Wildcard SPF is a TXT - not A, AAAA, MX - record, and it d= oes > not mess with the definition (2.6. Non-Existent Domains). We have also discussed making broader recommendations on email processing=20 behavior and concluded they were out of scope. Wild cards aren't so simple= =2E =20 The DMARC record for example.com isn't published at example.com. It's=20 published at _dmarc.example.com and you can't wild card _dmcarc.*.example.c= om. Scott K