From web@spensertruex.com Sun Jun 30 20:28:08 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 C7C211201F0; Sun, 30 Jun 2019 20:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spensertruex.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 Vkz8AM5FMLgC; Sun, 30 Jun 2019 20:28:07 -0700 (PDT) Received: from spensertruex.com (spensertruex.com [66.70.189.182]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C73612019D; Sun, 30 Jun 2019 20:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spensertruex.com; s=myselector; t=1561951678; bh=XVniAjsq7yEPxImOdUVF9MjdinTy0UyivjvqaacZqOI=; h=From:To:Cc:Subject:Date; b=NjwV+/eEh9ZqCfLJjB1/0KGmJyCTNjqgXB6JnqQRfTrUYlPmYIKU0VVYfkdySp3+d 6SsP0cUaaE0pIxKbS0uyQLg7vKRWp52EfHzVGYhnyXAakRBezBr+hk9rRLNTn4Wfpe /SlUd2PyMT4tmFYcAz0mSI+pteQNfLhLzpWNgPYkYSBUMCTmzynZbvWsYrVg8CJvg+ mGYMYyvCvdcwRnXhG4hxHW/7M02NhETb7L0OPfvgeqHgSYXOQ+iqiuaZ+F2a/mZoUl MgtQU1zy8EKmSqsl/TC9uzz58LD2fsmtvbTK4tZKzXW454bIOzypT7aA95BcLFaRGr 755hxeQLwaOHA== From: Spenser Truex To: John R. Levine , draft-ietf-dmarc-eaiauth@ietf.org Cc: dmarc@ietf.org Date: Sun, 30 Jun 2019 20:28:55 -0700 Message-ID: <87a7dymo08.fsf@spensertruex.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Mon, 01 Jul 2019 21:51:25 -0700 Subject: [dmarc-ietf] Mail regarding draft-ietf-dmarc-eaiauth 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, 01 Jul 2019 03:37:44 -0000 > 4. SPF and Internationalized Mail > [...] > SPF macros %{s} and %{l} expand the local part of the sender's > mailbox. If the local part contains non-ASCII characters, terms that > include %{s} or %{l} do not match anything, because non-ASCII local > parts cannot be used as the DNS labels the macros are intended to > match. Since these macros are rarely used, this is unlikely to be an > issue in practice. Wouldn't it be better to suggest the possibility of doing the right thing in that situation? Perhaps: If the local part contains non-ASCII characters, terms that include %{s} or %{l} MAY not match anything but SHOULD match, because non-ASCII local parts cannot be used as the DNS labels the macros are intended to match. A standard for internationalized mail perhaps should have support for internationalized local postmaster addresses, even if weak. -- Spenser Truex https://spensertruex.com/ San Francisco, USA From nobody Tue Jul 2 03:26:08 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 C754A120044 for ; Tue, 2 Jul 2019 03:26:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z344sVSrOGz7 for ; Tue, 2 Jul 2019 03:26:05 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 657C912006B for ; Tue, 2 Jul 2019 03:26:05 -0700 (PDT) Authentication-Results: mail.aegee.org/x62APqR8001098; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1562063156; i=dkim+MSA-tls@aegee.org; r=y; bh=T3dApzY0vcQYClUjLoB4rooZOYCdWkSu6r4Rn6j9l7Q=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=VKFSqTV7DXTFJhUuWjOXbmprIMuTpQUIToNcrhXF+amPe41wQYodYqjjmm7u1q/mE EPL1x91ekrx/QdD+Z+D+OcO1UZfWIdf7a5p7xBrQc1Fhg4q4DCa9sF6KWsH/ni3a4b 4vWept9gDZq7pptxJq4LEkSBzlrNfO5ElCdOEtWjoJV2sCehGtcxxICl3+XYEp9HQ4 HKqQ3+B+80GJQ6NDyhhmFHYNV+rVcUyJHlLhn8xjTd+HkPZhNJ8lFl/GFxwLZuU6+W I/MPAcngNJfVm7CBCuJoPLnkmD/5AQjqZRf0KdJo4zQDOgI4XlxVgUeoutHBsUsAaz X+pu0PgAwmoBbNVtyDeZET4IbcCVB9UnH+7QANaPMpHMRoGSMBhiLT4ulImD8KgvQC U4KDwyu3Zz3mG1mo0hEH9zaS+ghIW4Bql0tqfLA5+Ap1J7eQ88vebBOfO0XAmiZlSR ukCQWNAXJh85STWTJ8yeFEBdOtNRkYmnC62+/upo6yObM2dBirRf5o/3JkjaU/NDBD +4QyWzI569HlsBEEQWbhJAtrmGbQWyy5hh1rSqnc7VWBg67fZaYiyNghFnzWrPHZgW x1xkOko/raFaiFaq3NrHOO5NTNHlkBInXyJ+/jK/6O2wRczrki+nbGaarGPba7zGkm nto/gcXswFggWoToRr8c+hr8= Authentication-Results: mail.aegee.org/x62APqR8001098; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x62APqR8001098 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Jul 2019 10:25:52 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Tomki , dmarc@ietf.org Cc: seth@sethblank.com Date: Tue, 02 Jul 2019 10:25:51 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] spec nit - subdomains reporting clarity 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, 02 Jul 2019 10:26:07 -0000 Hello Tomki, The schema for reports is: first element is , it includes . contains . Do you propose to include in the the base domain, that declared implicitly or explicitly the sp= tag, and then cummulate all data for that domain and subdomains in the same xml.gz report, or do you propose to include several xml.gz files for each domain in a single email? Alternative approaches to reduce the amount of emails are: - include one or more xml reports in a single email, e.g. based on derived policy via the sp= mechanism - group reports for a single domain owner into one email with many xml files, provided that the recipient address of the reports is the same. Here sp= is irrelevant. This is tricky, when the recitient addresses for two domains overlap, but are not identical. - group xml.gz reports for many domain owners (or many distinct second level domains) into a single email, provided that the recipients of the different reports would be the same. Regards Дилян On Fri, 2019-06-21 at 18:04 -0700, Tomki wrote: > The spec appears to be unclear on how subdomains are to be reported - ie > most but not all implementations have performed this as intended, in the > same XML as the top level domain (when the subdomain does not have its > own DMARC TXT record) > > Cisco interpreted the current definition to mean that every subdomain > seen should get its own XML file. (not just the ones with their own > DMARC record) This results in every individual IronPort system [which > has DMARC reporting enabled] generating hundreds to thousands of extra > reports every day. > This can result in corporate reporters like Paypal or Rolls Royce > (IronPort users) sending as many reports in a given day as Google. > > The section which should be referred to in implementing a reporting > engine is 7.2 https://tools.ietf.org/html/rfc7489#section-7.2 > The only relevant bullet that I find here is > " The report SHOULD include the following data:" > .... > "Data for each Domain Owner's subdomain separately from mail from > the sender's Organizational Domain, even if there is no explicit > subdomain policy" > > In trying to find out why Cisco implemented their reporting in the way > that they did, I've actually had a hard time understanding how others > understood that bullet point well enough - I can only imagine that > everybody just implemented by following examples of existing > implementations. > > A suggested rewording for that bullet point: > " Data for each Domain Owner's subdomains as separate records in a > report titled for the Organizational Domain, unless there is an explicit > subdomain policy - in which case a standalone report is generated for > that subdomain" > > --Tomki > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat Jul 6 04:30:21 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 3BEC312015A for ; Sat, 6 Jul 2019 04:30:20 -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 CPPNzy4NBTLG for ; Sat, 6 Jul 2019 04:30:18 -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 82BE612009C for ; Sat, 6 Jul 2019 04:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1562412615; bh=qXK2Q7inchwyfogbQ7N3h1BcMZbdBSATrMxKBe2Xj08=; l=1320; h=To:References:From:Date:In-Reply-To; b=BqTDjXIqFJZq+Io81mjVDoC4l92JDJ58nQpn7Ierzj4iREdpO5tYujQ14oUoUUA5l qF2OkWpY/8W+idgEznPglUDQsex02hPrj5inOKwI1N7FxCUC8Gbk0v9DW3RilVcHJ3 oiQ0hWLL7chDk+Lby7Jj6/0o31FZYlSp0smFRd81CFMqjO3XwrnjhshkHxhld Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.8.185]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC073.000000005D208647.0000440E; Sat, 06 Jul 2019 13:30:15 +0200 To: dmarc@ietf.org References: <20190621184626.AE1B52016298ED@ary.qy> From: Alessandro Vesely Openpgp: preference=signencrypt Autocrypt: addr=vesely@tana.it; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bubuQINBFwOoIQBEADgJ8t4TSiLyRpRd3L6Oy5ezajwkPXG/rvKK8OY YtNy4s3jzrbasm8lq0fIFc12FNqjI+rYiyrVAx2sxv3yVT2MWlFdfpZiNEGS+0tYBim006cc ta3WNoN69PKtPK5t1tpBrhCDMcQwPw2o00WBDvVHJi0zg7HQ9m2c0Hzo2AUTdy7h4vQRyI9K EjhCxVRlBOVZCmKnf2iad/0xHpLz9hjqh3P2mpby8DEw0wEOMCwhABO/GVjBUbxuTwHC1D9F DI7tF7L2+WuKqjHhFonS4Q8QE8nI3IGLhazIe0xpgDSNOFUIpGN5v31Wl8OCQ7tLmc/xR2Pi JD3pdIRevjlAijDLyLx6d3vk3bfA73KtEU/rpmJmWowPWG/P278bvO/xHe1rluYWeXqOOZmy 5CikxeNZ6nTd+Tcd/XPhjusy0bJMwAVoNoxgk6FZyBN4+/zWiEezDSj59gwqSzLnOW8i2WCe 4lJoyP3+A0/mg+PR/2WN1Rg4GfGsHjRgPA+NcfsGaoPRla3eHJ9ALDovaL0HmDGZHEnhqP8O ooEKlrQ3L+SV6Pb4/2S0QNYXLP8rD6YySKSH0Trq/dZ78IWtiHFWWQXgZ3S4XtfZ1txlj2GQ a4EaIrtxcmjN/zmEXaRBDqkcyshJOAQExKt6r7Ig0OKDLPJtuohdz2vi2krqYC4LLdoDjwAR AQABiEkEGBECAAkFAlwOoIQCGwwACgkQtqz0RJDRfACNAACeKreSOjkf3BxAL9dnGeYso2e3 sTsAoL4J4GC64/eh1VthLGkUOWBY2IQN Message-ID: <233c41a5-4072-266c-54eb-e19239949c4a@tana.it> Date: Sat, 6 Jul 2019 13:30:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190621184626.AE1B52016298ED@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] spec nit - which DKIM to report 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, 06 Jul 2019 11:30:20 -0000 >> the spec does not define *which* DKIM signature should be reported in >> the DMARC RUA created by a receiver. >> [... skip proposed order ...] > > This seems overcomplex. How about saying the reports SHOULD include > all valid DKIM reports. If they can't, they can't, and I don't see > any benefit in offering advice on how not to comply. In my implementation, I have two points where I don't comply: *Maximum signatures in a message* That is to avoid silly attacks (but consider the recent SKS attack). It is about 1000, IIRC. The rest is not verified. *Maximum signatures reported in rua* This is much lower, currently 4. It's there because transitive closure is not yet available on a number of SQL products. In particular, MariaDB needs 10.2.2[*], which is not yet in Debian stable. The workaround is to left joint a (finite) number of times the table with itself[†]. How about this: In the presence of multiple signatures, aggregate reports SHOULD mention at most 1000 and at least 4 signatures (if available), in order of decreasing importance. ? Best Ale -- [*] https://mariadb.com/kb/en/library/recursive-common-table-expressions-overview/ [†] search db_sql_dmarc_agg_record in: https://www.tana.it/svn/zdkimfilter/tags/v1.6/odbx_example.conf From nobody Tue Jul 9 17:13:24 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 686411200C3; Tue, 9 Jul 2019 17:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkMl65av3t-e; Tue, 9 Jul 2019 17:13:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F1C120098; Tue, 9 Jul 2019 17:13:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 939E6B8154E; Tue, 9 Jul 2019 17:13:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmarc@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190710001316.939E6B8154E@rfc-editor.org> Date: Tue, 9 Jul 2019 17:13:16 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] =?utf-8?q?RFC_8617_on_The_Authenticated_Received_Ch?= =?utf-8?q?ain_=28ARC=29_Protocol?= 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, 10 Jul 2019 00:13:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8617 Title: The Authenticated Received Chain (ARC) Protocol Author: K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed. Status: Experimental Stream: IETF Date: July 2019 Mailbox: kurt+ietf@drkurt.com, blong@google.com, seth@valimail.com, superuser@gmail.com Pages: 35 Characters: 70573 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dmarc-arc-protocol-23.txt URL: https://www.rfc-editor.org/info/rfc8617 DOI: 10.17487/RFC8617 The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. This document is a product of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jul 10 13:21:24 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 55FE212012A for ; Wed, 10 Jul 2019 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 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, PDS_NO_HELO_DNS=1.295, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROIGeyIFm7Zi for ; Wed, 10 Jul 2019 13:21:21 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4B0AA12004A for ; Wed, 10 Jul 2019 13:21:21 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id a10so3790402wrp.9 for ; Wed, 10 Jul 2019 13:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HOV4nVrZ7v4K5xpGtXTreytEY+MBZKAJZt5PUTwHdtk=; b=d0e1tKA46Ig+z4eWSl8zjhWSsbW2goHUJJGwEbuZCVKqghZiCRFNHf89gFNlRhTBeN NZRjSMdLSw8xKPA8fI2cEjD8/n6IwrU8iZ9zStUCjtTucmZJLx5/Zb2ZahP7+1vDURKa sZzzO04sjej2cezLjMF6udLSDtucyr/k9+vlKJ0itpq4pfe7AAA++wtxGrHtwc9TefYd L64LMeYgpO/46Ti9xKnzh2hetB123CblhdfjGP0UTe8wXGATt+TpWZP18uqDUtURamNP rOcpgDezEzHtnh3x8C5QME/OAvo7+60/X2/ev4IjLfGn8/V5GbE7YVsnFukT1JSgqw/m BPlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HOV4nVrZ7v4K5xpGtXTreytEY+MBZKAJZt5PUTwHdtk=; b=E3+RIWfJXt6l7kwdmfpNp9Rn1OY9aUZ0NAHcfnebLUqKtMx/57/7vnmFhh520QZBMS Ze61lArrvH5flZgBxtxmLhq7a5e17ICz1qJTpU0XyIbKYt0y+MN6Exlo/+rzT4+QsJMK mRN4duYTVjohgOcQoBY04EpnjLJct8o60+T2VdU1Mh4j/vIxi2FFiLseUqm1OHWHeTNG +wTF+1f7eHoGRNXw/tvahLgt0qKfdusXSYPd6Ljm7QvAB0GWmMEQKnvI8/334TjKShX1 Wcz86GmTHqeKhsg0aqbfdi2Ntfi51heOEp9Ta+cwLvPytGRry90ZBoLUB9RSJQdPJ4dS od0w== X-Gm-Message-State: APjAAAUegX5LJ9PaSWwBrCoVa7K2f/d81ULwCbTZQlYTegnmqFFTuDz3 SR6/tgnQUJP2Djxi5IeGtyItWJHamvGrgxbGzG8R8FOl3WY= X-Google-Smtp-Source: APXvYqwsxjxxBFuhm/N8G+aBHbgETerH+pJQoHhdq13k1NEkz7ehlDyKkVZeRbEA8PUnVpqUQDkH8EIWYfurdWy/dAA= X-Received: by 2002:adf:c803:: with SMTP id d3mr33884960wrh.130.1562790079476; Wed, 10 Jul 2019 13:21:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Wed, 10 Jul 2019 13:21:08 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000008bca45058d596b71" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 10 Jul 2019 20:21:23 -0000 --0000000000008bca45058d596b71 Content-Type: text/plain; charset="UTF-8" There is one week left before WGLC closes, and the below three items still need resolution. Please speak up! -- Seth, as Secretary On Wed, Jun 26, 2019 at 2:21 PM Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > > 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 > > Seth > > On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy > wrote: > >> This message begins Working Group Last Call for draft-ietf-dmarc-psd, >> which is currently at version 04. An 05 may appear shortly with some text >> changes that were previously discussed on the list; these do not include >> any technical changes (I believe) so the author is free to update with only >> those changes as planned. >> >> Please review the document and submit your feedback by Wednesday, July >> 17th. We would ideally like to have enough responses to support our claim >> to the IESG that the document clearly has working group consensus. >> >> Note that we will be in pre-meeting draft embargo at that time so a new >> version dealing with any feeback cannot appear until IETF 105 begins on the >> 22nd. >> >> I'm planning to do my own review as the document shepherd with an eye >> toward consumption by readers with only a passing familiarity with DMARC. >> If anyone wants to join me in looking at it through that lens, you'd be >> welcome. >> >> -MSK, co-chairin' >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- *Seth Blank* | Director, Industry Initiatives *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000008bca45058d596b71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is one week left before WGLC closes, and the be= low three items still need resolution. Please speak up!

-- Seth, as Secretary

On Wed, Jun 26, 2019 at 2:21 PM Seth Blank <<= a href=3D"mailto:seth@valimail.com">seth@valimail.com> wrote:
As Se= cretary, there are three items that have not yet reached consensus that mus= t be resolved during WGLC:

1. What further context is needed i= n the introduction
2. If explicit call outs to ICANN/limited oper= ator capacity to implement are needed
3. If an np=3D tag is n= eeded to allow PSD functioning for only NXDOMAINs

= Seth

On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
This message begins Working Group Last Call for dr= aft-ietf-dmarc-psd, which is currently at version 04.=C2=A0 An 05 may appea= r shortly with some text changes that were previously discussed on the list= ; these do not include any technical changes (I believe) so the author is f= ree to update with only those changes as planned.

Please revie= w the document and submit your feedback by Wednesday, July 17th.=C2=A0 We w= ould ideally like to have enough responses to support our claim to the IESG= that the document clearly has working group consensus.

Note that we= will be in pre-meeting draft embargo at that time so a new version dealing= with any feeback cannot appear until IETF 105 begins on the 22nd.

<= /div>
I'm planning to do my own review as the document shepherd wit= h an eye toward consumption by readers with only a passing familiarity with= DMARC.=C2=A0 If anyone wants to join me in looking at it through that lens= , you'd be welcome.

-MSK, co-chairin'
<= /div>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


-- <= br>

Seth Blankp: 415.273.8818



This email and all = data transmitted with it contains confidential

and/or proprietary information intended solely for the use of

individ= ual(s) authorized to receive it. If you are not an intended

and authorized recipient you are hereby notified of any use,

disclosure, copying or distribution of the information included in

this transm= ission is prohibited and may be unlawful. Please

immediatel= y notify the sender by replying to this email and then

dele= te it from your system.

--0000000000008bca45058d596b71-- From nobody Wed Jul 10 16:10: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 C69AF120247 for ; Wed, 10 Jul 2019 16:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 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, PDS_NO_HELO_DNS=1.295, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZGAl-ptFtiG for ; Wed, 10 Jul 2019 16:10:39 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8834120222 for ; Wed, 10 Jul 2019 16:10:38 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t28so3764989lje.9 for ; Wed, 10 Jul 2019 16:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HFwGTTLeBu80h9uLQOPkHydBObprerNUpVvYwfn/MJA=; b=HGTLIYAsEtBY078KFofbfWAFGMoSJYDVJ7bFwGqXVJVAsC/Z8fQDeDsfX3xFpUCiQt f+FPMQBdesmbPl1/HUEHEmBjYNazwXhrRLIa2fBCdAWYPap72dMFSPUxAu7zr6tJIYGQ MqxFpyvRgCzx82ZK8STCFKZbBKssodEM0MA78= 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=HFwGTTLeBu80h9uLQOPkHydBObprerNUpVvYwfn/MJA=; b=gt6el6/KemEdNTspyieL+MxA1ko/tmAVFXQgZ2QcQ+1L1w6Ehe6qpFfDauRuWhXjew iBcD/K6Gf2RFfKHqS/X+NACmSKN15zNRUAT5HBrhbgK4PdgQozbtmS+kZp/IIOgjRaZB vhHranodUBpVu70Zb+KMEEOZUVfkXUSQvDTvinR3hEzlSbk+CBeb3YUUj32M7hdAHqkJ 7HHUz5QN1/M69VCJ8uCiH8tHpzWeaDr5Jyq796bc+NyoFlypYauqkOogneBwIkkZmhLF NhFugAr+MMHotKsVMIKfN7ghxWG+hgJI+7x9lc7vB9hAh/f2NY2GT19gsiTmnMQDbfcC AVuA== X-Gm-Message-State: APjAAAXATDZodgLMf352H8NrgrRPRM/Eigbcadg+44CjdR8pZIcvwKGB 2ORfiW4BR7fmOcNT0j8hjDcarorTKr6TwvzUO98= X-Google-Smtp-Source: APXvYqwP1yyJp1FDwAqgub2uEbHCx398jKa769pmnC5Q2SnNmpex3wKshSqfo+y7Gflxkudr7/bWNUoMZoLm5aCeWHc= X-Received: by 2002:a2e:4e12:: with SMTP id c18mr392995ljb.211.1562800236774; Wed, 10 Jul 2019 16:10:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 10 Jul 2019 16:10:25 -0700 Message-ID: To: Seth Blank Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f7d962058d5bc819" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 10 Jul 2019 23:10:42 -0000 --000000000000f7d962058d5bc819 Content-Type: text/plain; charset="UTF-8" I, for one, would *really* like to see the rumored "next version" from Scott and prefer to comment on that one, rather than an at-best penultimate version. --Kurt On Wed, Jul 10, 2019 at 1:21 PM Seth Blank wrote: > There is one week left before WGLC closes, and the below three items still > need resolution. Please speak up! > > -- Seth, as Secretary > > On Wed, Jun 26, 2019 at 2:21 PM Seth Blank wrote: > >> As Secretary, there are three items that have not yet reached consensus >> that must be resolved during WGLC: >> >> 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 >> >> Seth >> >> On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy >> wrote: >> >>> This message begins Working Group Last Call for draft-ietf-dmarc-psd, >>> which is currently at version 04. An 05 may appear shortly with some text >>> changes that were previously discussed on the list; these do not include >>> any technical changes (I believe) so the author is free to update with only >>> those changes as planned. >>> >>> Please review the document and submit your feedback by Wednesday, July >>> 17th. We would ideally like to have enough responses to support our claim >>> to the IESG that the document clearly has working group consensus. >>> >>> Note that we will be in pre-meeting draft embargo at that time so a new >>> version dealing with any feeback cannot appear until IETF 105 begins on the >>> 22nd. >>> >>> I'm planning to do my own review as the document shepherd with an eye >>> toward consumption by readers with only a passing familiarity with DMARC. >>> If anyone wants to join me in looking at it through that lens, you'd be >>> welcome. >>> >>> -MSK, co-chairin' >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> >> >> -- > > *Seth Blank* | Director, Industry Initiatives > *e:* seth@valimail.com > *p:* 415.273.8818 > > > > This email and all data transmitted with it contains confidential > > and/or proprietary information intended solely for the use of > > individual(s) authorized to receive it. If you are not an intended > > and authorized recipient you are hereby notified of any use, > > disclosure, copying or distribution of the information included in > > this transmission is prohibited and may be unlawful. Please > > immediately notify the sender by replying to this email and then > > delete it from your system. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f7d962058d5bc819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I, for one, would *really* like to see the rumored "n= ext version" from Scott and prefer to comment on that one, rather than= an at-best penultimate version.

--Kurt

<= div class=3D"gmail_quote">
On Wed, Jul= 10, 2019 at 1:21 PM Seth Blank <seth=3D40valimail.com@dmarc.ietf.org> wrote:
There i= s one week left before WGLC closes, and the below three items still need re= solution. Please speak up!

-- Seth, as Secretary
On= Wed, Jun 26, 2019 at 2:21 PM Seth Blank <seth@valimail.com> wrote:
As Secretary, th= ere are three items that have not yet reached consensus that must be resolv= ed during WGLC:

1. What further context is needed in the intro= duction
2. If explicit call outs to ICANN/limited operator capaci= ty to implement are needed
3. If an np=3D tag is needed to al= low PSD functioning for only NXDOMAINs

Seth
<= /div>

On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy <superuser@gmail.com> wrot= e:
This message begins Working Group Last Call for draft-ietf-dm= arc-psd, which is currently at version 04.=C2=A0 An 05 may appear shortly w= ith some text changes that were previously discussed on the list; these do = not include any technical changes (I believe) so the author is free to upda= te with only those changes as planned.

Please review the docum= ent and submit your feedback by Wednesday, July 17th.=C2=A0 We would ideall= y like to have enough responses to support our claim to the IESG that the d= ocument clearly has working group consensus.

Note that we will be in= pre-meeting draft embargo at that time so a new version dealing with any f= eeback cannot appear until IETF 105 begins on the 22nd.

I= 'm planning to do my own review as the document shepherd with an eye to= ward consumption by readers with only a passing familiarity with DMARC.=C2= =A0 If anyone wants to join me in looking at it through that lens, you'= d be welcome.

-MSK, co-chairin'
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


-- <= br>

Seth Blank | Director, Industry Initiatives
=
e: seth@valimail.com<= /span>
p: 415.273.8818



This email and all da= ta transmitted with it contains confidential

and/or proprietary information intended solely for the use of

individua= l(s) authorized to receive it. If you are not an intended

a= nd authorized recipient you are hereby notified of any use,

disclosure, copying or distribution of the information included in

this transmis= sion is prohibited and may be unlawful. Please

immediately = notify the sender by replying to this email and then

delete= it from your system.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f7d962058d5bc819-- From nobody Wed Jul 10 22:12:31 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 F3FAC120048 for ; Wed, 10 Jul 2019 22:12:29 -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=+DB6p7XM; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qqFFCBUC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUFJTjMfaGe9 for ; Wed, 10 Jul 2019 22:12:26 -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 B60B81200CE for ; Wed, 10 Jul 2019 22:12:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id D3A79F8078C; Thu, 11 Jul 2019 01:12:24 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562821944; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=4Sgz3OY6ic6CeEPmY32wBtAlyOhCTF8IdX9P4FUpKew=; b=+DB6p7XMGORORRdw7FCIakb13KJobAUJIR3R9lnbRgpsXhSuuIjJ3Uc9 2UxesbdQkZHVbMP5VfzOUZCB2DDzDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562821944; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=4Sgz3OY6ic6CeEPmY32wBtAlyOhCTF8IdX9P4FUpKew=; b=qqFFCBUCN3yu5JLcWJPWS7ri6uUqKqG6kJZXrihx/cJBxQrvg1Wx59WG 0GPHiUV+tau3GH+5M8jxwxnuOgTsICeceDikBS4VFmWwjncVkQlzZaRmTE iYuXQ2GLCbRE+r67hhooPcWzLu2IpM9tVsH0H3EDOEFYxbYnBFh0xS9nkL oRPPSrdEx5VhSQe1GiTxd5xccN10V0O25vxU1AKc/v00ITtaIxzTlEWWxh FWTcY+deq+mGPElyhvybUaWoKOUdhzgm0oa4Nyc0/vjlz9hOeDZWYDwLC+ ifhWVHIvux9G5Hx1iZI01Gd9oHMtMGg6xR7e9cNiEOTQdjBkMJDIYw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 9F602F8004E; Thu, 11 Jul 2019 01:12:24 -0400 (EDT) Date: Thu, 11 Jul 2019 04:07:56 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <78C64421-261E-4E17-9996-5AD8CBDB0348@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 11 Jul 2019 05:12:30 -0000 I don't plan any changes except for those in response to last call comments= =2E Unless I get direction otherwise, I don't plan any updates until after= last call is over=2E Please review this one=2E Scott K On July 10, 2019 11:10:25 PM UTC, "Kurt Andersen (b)" = wrote: >I, for one, would *really* like to see the rumored "next version" from >Scott and prefer to comment on that one, rather than an at-best >penultimate >version=2E > >--Kurt > >On Wed, Jul 10, 2019 at 1:21 PM Seth Blank 40valimail=2Ecom@dmarc=2Eietf=2Eorg> wrote: > >> There is one week left before WGLC closes, and the below three items >still >> need resolution=2E Please speak up! >> >> -- Seth, as Secretary >> >> On Wed, Jun 26, 2019 at 2:21 PM Seth Blank wrote: >> >>> As Secretary, there are three items that have not yet reached >consensus >>> that must be resolved during WGLC: >>> >>> 1=2E What further context is needed in the introduction >>> 2=2E If explicit call outs to ICANN/limited operator capacity to >implement >>> are needed >>> 3=2E If an np=3D tag is needed to allow PSD functioning for only >NXDOMAINs >>> >>> Seth >>> >>> On Wed, Jun 26, 2019 at 2:08 PM Murray S=2E Kucherawy > >>> wrote: >>> >>>> This message begins Working Group Last Call for >draft-ietf-dmarc-psd, >>>> which is currently at version 04=2E An 05 may appear shortly with >some text >>>> changes that were previously discussed on the list; these do not >include >>>> any technical changes (I believe) so the author is free to update >with only >>>> those changes as planned=2E >>>> >>>> Please review the document and submit your feedback by Wednesday, >July >>>> 17th=2E We would ideally like to have enough responses to support >our claim >>>> to the IESG that the document clearly has working group consensus=2E >>>> >>>> Note that we will be in pre-meeting draft embargo at that time so a >new >>>> version dealing with any feeback cannot appear until IETF 105 >begins on the >>>> 22nd=2E >>>> >>>> I'm planning to do my own review as the document shepherd with an >eye >>>> toward consumption by readers with only a passing familiarity with >DMARC=2E >>>> If anyone wants to join me in looking at it through that lens, >you'd be >>>> welcome=2E >>>> >>>> -MSK, co-chairin' >>>> _______________________________________________ >>>> dmarc mailing list >>>> dmarc@ietf=2Eorg >>>> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc >>>> >>> >>> >>> -- >> >> *Seth Blank* | Director, Industry Initiatives >> *e:* seth@valimail=2Ecom >> *p:* 415=2E273=2E8818 >> >> >> >> This email and all data transmitted with it contains confidential >> >> and/or proprietary information intended solely for the use of >> >> individual(s) authorized to receive it=2E If you are not an intended >> >> and authorized recipient you are hereby notified of any use, >> >> disclosure, copying or distribution of the information included in >> >> this transmission is prohibited and may be unlawful=2E Please >> >> immediately notify the sender by replying to this email and then >> >> delete it from your system=2E >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc >> From nobody Thu Jul 11 03:08:05 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 6245712037F for ; Thu, 11 Jul 2019 03:07:59 -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 S1NlnEv7Bcl5 for ; Thu, 11 Jul 2019 03:07:57 -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 7518B1203F5 for ; Thu, 11 Jul 2019 03:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1562839673; bh=0NNY0IvquUeQRHZ6dcdLI3e+VU2rHqgdQ5Gj0fcX+KA=; l=1767; h=To:References:From:Date:In-Reply-To; b=BrxHxaUCCHvL8dOyBqcPmE5s3MY6dc4AXam5k6rAyVCjQ0PD18aADYx+lIPwHfwsE 0QUH5AM1GF6mQCmN8rerVx3c5ChXxv6hMbGxc/qYzQf8HNsejhYgiJf7wbx/plpdKs 40Tg69uMTlXyZuYfvFMT6X9zD4WXlOLqUZ5Cs22LogzuE7coZlQj+XB++2azb Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.102] ([5.170.8.138]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.000000005D270A78.00007C2E; Thu, 11 Jul 2019 12:07:52 +0200 To: dmarc@ietf.org References: From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <54eac0ab-985e-69be-5985-8a53c51c7580@tana.it> Date: Thu, 11 Jul 2019 12:07:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 11 Jul 2019 10:08:04 -0000 On Wed 10/Jul/2019 22:21:08 +0200 Seth Blank wrote:> There is one week left before WGLC closes, and the below three items > still need resolution. Please speak up! > > -- Seth, as Secretary > > On Wed, Jun 26, 2019 at 2:21 PM Seth Blank > wrote: > > As Secretary, there are three items that have not yet reached > consensus that must be resolved during WGLC: > > 1. What further context is needed in the introduction IMHO, it is clear as is. > 2. If explicit call outs to ICANN/limited operator capacity to > implement are needed Appendix B.1 lacks a criterion to establish enlisting. Couldn't we require an explicit statement about seizing DMARC reports in, say, the delegation report? Alternatively, that policy can be stated in a well-known place under the delegation services URL, so that registrants know what they do. > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs Yes, it would allow p=reject; sp=none; (np=reject by default). Some nits: (In the intro) controls to mitigate potential privacy considerations associated with this extension Don't mitigate considerations. Mitigate risk, danger, whatever. 2.2. Public Suffix Domain (PSD) That paragraph sounds a bit confused. The concepts of "private" vs. "public" are not clear after having defined branded PSDs. Perhaps it is better to distinguish between single, central admin vs. multi-organization, distributed responsibility. The terms of Expert Review,per [RFC5226] (Appendix B.2) refer to a IANA registry. So, shouldn't the term "IANA" be stated in the title? (And a link to this appendix from the last bullet in Appendix A?) jm2c Ale -- From nobody Thu Jul 11 03:29: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 DD4CE1202D1 for ; Thu, 11 Jul 2019 03:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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=verisign.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 d1whyNmsqVAE for ; Thu, 11 Jul 2019 03:29:35 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 DC4A71202C0 for ; Thu, 11 Jul 2019 03:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=591; q=dns/txt; s=VRSN; t=1562840975; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=QsIRVfcTrklBAtJFTP7ohjb/mIHlF6G6ACbTjKD5FgQ=; b=ggFs0VU3IFkt7ascwji7IYhzC/ThgY8p0ECoYcOViQdzGGMsOJO7FkeR Edrj4dradwxS/Q5OUBBXWtD7RJtf9swhQFAg1UPz+dY5mF49tyZAqv7Qi N6JCyhhmgSUV2MGuTLY9MyXwBjqMDY1q2ZztjLrDtdIEvclHtXc/KQO5e 7PpdvvPoUEUIQF3TnglnLj66Bx5a1tOOA5NIScoygaK5f2ouloDW69G5S g3MklXgY17+1Nu6eCfCD8Z0nppP/jopYbOP+NZpmyDSKX5im1YWq8wwSO QnYAcY9IF4n7yPMjgyzpedWamwnJUDxIlWJL7N+Obn8lOwfMX/C8FnNK1 Q==; X-IronPort-AV: E=Sophos;i="5.63,478,1557187200"; d="scan'208";a="10631882" IronPort-PHdr: =?us-ascii?q?9a23=3AF55I6hMTdOt1nMEo3cEl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0I/XzrarrMEGX3/hxlliBBdydt6sezbaG+PqwEUU7or+5+EgYd5JNUx?= =?us-ascii?q?JXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQ?= =?us-ascii?q?viPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCejbb9oIxi7rgrdutcVjIB/Nqs/1x?= =?us-ascii?q?zFr2dSde9L321oP1WTnxj95se04pFu9jlbtuwi+cBdT6j0Zrw0QrNEAjsoNW?= =?us-ascii?q?A1/9DrugLYTQST/HscU34ZnQRODgPY8Rz1RJbxsi/9tupgxCmXOND9QL4oVT?= =?us-ascii?q?i+6apgVRnlgzoFOTEk6mHaksx+grxGrhK9qRJxwIDUb4OUNPVica3ScsgXRX?= =?us-ascii?q?ZYXsZTSyBNHp+wY5UJAuEcPehYtY79p14WoBewBwesA+fvyjtWiX/wxqI1zf?= =?us-ascii?q?guEQLe0Ac9AtwBrHPUrMnpNKscTOu4y7LIzTXEb/NS3Tfy9o7IfQs/rv6QXr?= =?us-ascii?q?J9atTRxlc1FwPElVWQqIPlPzWP2usRtGib6vNtWOSygGAprAFxpyKgxsYqio?= =?us-ascii?q?TRh4Ia1EzE9StjzIYyP924R0h2asOnHptIryyWKpd6Ttk/T2xqtis20KAKtJ?= =?us-ascii?q?61cSQQx5kqxAbTZ+Gbf4SS/x7uVvqdLS1liH9qe7+znQu+/Eu4xu3ySMa500?= =?us-ascii?q?pGoy9An9TOqn8Bywbc582aRvRh4kis3DaC2B3N5eFKJE05kbfUJIM/zbM2i5?= =?us-ascii?q?Edq17MHjXsl0XzlKKWc0Ik9fW25On/ebXmo4OcN5dzigHjLqQigsy/Dvo8Mg?= =?us-ascii?q?gJR2WW5Piy2qX+8UL5WLtEgfw5nrXEvJzAO8QUuqm5AxVN0oo58RmwEi2q0M?= =?us-ascii?q?oCnXkcKlJJYg6Ij4/sO13WIfD4C+mwg0i0nTt22/zKJKDtD5fDI3TZjbvsfb?= =?us-ascii?q?hw51RTxQcw1dxf4ohbCrAFIPL9QE/xs9nYAwciMwy0xObnDNF92Z0YWW2UHK?= =?us-ascii?q?CWLKDSvESW5u0xOemMZZQVuDfyK/gj/fLhkXg5mVoFcamzwZQXcGy4HuhhI0?= =?us-ascii?q?iBenrsgdMBEWYRvgoiV+Hqi1yCUSJPZ3msRaI84ys0CIS8AYjfQYCthaSL3D?= =?us-ascii?q?2nEZ1OemBGFleMHG/1eIWBQfgMcj6dL9RgkjMaSbihRZUt1Ra0tA/1mPJbKb?= =?us-ascii?q?+e4S4ctIn//Nt0+/HejxQ783p/CMHXmzWWTGV1hX8gRD4qwK1lpEV7jFyE1P?= =?us-ascii?q?48y7ZUENVJ7NtIXxs0c5nGwKYyX9z3UxjKVtaEVFjgRc+pV2IfVNU0lpUuZE?= =?us-ascii?q?J5FtOogxvAm2KRCLgJi/bDUIc09abY0n77Ks1+42jLzqg6jlYgBMBIMDv11e?= =?us-ascii?q?ZE6wHPCtuRwA2inKGwePFE0Q=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2EEAADDDidd/zCZrQplGgEBAQEBAgEBAQEHAgEBAQGBU?= =?us-ascii?q?wUBAQEBCwGDAIEsCowujE+YeIF5AgkBAQEBAQEBAQEHASMMAQEChD4Cgnc0C?= =?us-ascii?q?Q4BAwEBAQQBAQEBBAEBAQKGJQyCOiIcTWsBAQEBAQEjAkQsAQEBAQM6SwQCA?= =?us-ascii?q?QgRBAEBHxAyHQgCBAESCIMbghkDrVWEMgGBFIRqBoE0AYlBgjSBQT6BD4MUP?= =?us-ascii?q?oJhAodDBKpXAwYCghmGWI0oI4IcEIcijGKBUY0xh0OQAAIEAgQFAhWBUIIRc?= =?us-ascii?q?IM8i0aFP3KOcYEhAQE?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 11 Jul 2019 06:29:32 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Thu, 11 Jul 2019 06:29:32 -0400 From: "Hollenbeck, Scott" To: "sklist@kitterman.com" , "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVN10TIm40Ebg+9kqQ/osg7is/D6bEvaOAgABTIACAACcUkA== Date: Thu, 11 Jul 2019 10:29:32 +0000 Message-ID: <3a6e6f9ac98c4e60af1075760efde86d@verisign.com> References: <78C64421-261E-4E17-9996-5AD8CBDB0348@kitterman.com> In-Reply-To: <78C64421-261E-4E17-9996-5AD8CBDB0348@kitterman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 11 Jul 2019 10:29:37 -0000 > -----Original Message----- > From: dmarc On Behalf Of Scott Kitterman > Sent: Thursday, July 11, 2019 12:08 AM > To: dmarc@ietf.org > Subject: [EXTERNAL] Re: [dmarc-ietf] Working Group Last Call: draft-ietf- > dmarc-psd > > I don't plan any changes except for those in response to last call commen= ts. > Unless I get direction otherwise, I don't plan any updates until after la= st call is > over. > > Please review this one. Repeating what I suggested earlier: https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk Scott From nobody Thu Jul 11 17:54: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 3BE8D120155 for ; Thu, 11 Jul 2019 17:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=TWcTw6L5; dkim=pass (1536-bit key) header.d=taugh.com header.b=DNZGOgo1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djQjpmZtjRGK for ; Thu, 11 Jul 2019 17:54:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F50E1200C7 for ; Thu, 11 Jul 2019 17:54:45 -0700 (PDT) Received: (qmail 43488 invoked from network); 12 Jul 2019 00:54:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a9de.5d27da53.k1907; i=johnl-iecc.com@submit.iecc.com; bh=x/kE4c+rRYVqARHAD/nwbndCI1q3LLnN0RqwfC8+e2Y=; b=TWcTw6L5uZp+pwBloCBJrRyzI0hK3p65Z4POQgPLvTfy8GFXGploE8W3OTu/RWnMBUMJgUQxOODSz4y3dqn1NIjzNnhys/vjev2oXagszGKSKS97saj81GLtvLxHzpC4j6T2DlZXa6ykd5K3KwVud3U/P75NH3pX1CDDYqj7JgJ6YpDjr/dqLQaPEK+YJr4ay3oChKzZSX7EmmWmJgzNopNWAdd2TMRLFIZQqPmuZBGhOUtH6uSQpPFckD8c7mAO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a9de.5d27da53.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=x/kE4c+rRYVqARHAD/nwbndCI1q3LLnN0RqwfC8+e2Y=; b=DNZGOgo1E47aplxG7GSCY5NsHvnhvGxe91yFiWb2olto+Ffpn5+JUIGNYGNdJ1+Es9legmvnFIdhoaDQplqLXVlVWVHa4TUN1wH3/x3oGMpCzSFp1rw4Dd//4JWkA2F13hmNFRly5An1gB/mQUNeEPtvzRygOoZId8E57+9tBFTewx4blR1CZWdWP0UiQfjq+rPr/198Q0T0q5vIa9y63YE4EVmp8d/4GrpRITkK5xIuFZ/yF7OzUK5DPXPSZXmz Received: from ary.local ([71.59.64.39]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 12 Jul 2019 00:54:43 -0000 Received: by ary.local (Postfix, from userid 501) id 2A664499982; Thu, 11 Jul 2019 20:54:42 -0400 (EDT) Date: 11 Jul 2019 20:54:42 -0400 Message-Id: <20190712005443.2A664499982@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: shollenbeck@verisign.com In-Reply-To: <3a6e6f9ac98c4e60af1075760efde86d@verisign.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 12 Jul 2019 00:54:48 -0000 In article <3a6e6f9ac98c4e60af1075760efde86d@verisign.com> you write: >> I don't plan any changes except for those in response to last call comments. >> Unless I get direction otherwise, I don't plan any updates until after last call is >> over. >> >> Please review this one. > >Repeating what I suggested earlier: > >https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk That seems OK to me. We don't need to say anything specifically to ICANN. Should PSD turn out to be popular, this will be an input to an ICANN process to allow the PSD record at the top of a TLD zone. R's, John From nobody Fri Jul 12 10:22:28 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 AA417120370 for ; Fri, 12 Jul 2019 10:22:25 -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=4Zd7hxHC; dkim=pass (2048-bit key) header.d=kitterman.com header.b=hljBE56g Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-qIUSERljgT for ; Fri, 12 Jul 2019 10:22:23 -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 50F231202F0 for ; Fri, 12 Jul 2019 10:22:23 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 26D1DF80607 for ; Fri, 12 Jul 2019 13:22: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=1562952142; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sq+UCXGPGW+GYY9AhWaWSADGZOoLPXjKTWsFH74O4SM=; b=4Zd7hxHCGhysDleNfSomPBNmfA0l/g957CigmNCdkn7Dw+fcP0+Pxhpf uOSwvdJsmsMGHrG6q4Z7YHZeIFjKBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562952142; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sq+UCXGPGW+GYY9AhWaWSADGZOoLPXjKTWsFH74O4SM=; b=hljBE56gVc74VDahrHTJOM9tH1KhuGQuMuoHKUMaec7kavosLIBVDHgF 4atw4WDU10Dd72ZSbNv2e5Hm7hMZtib9r36MzMqORsplgEn3ahbbGGbc/6 Q1h4Hgx+GNHsMVrJCt6lU3duc60erA3sqTNd2K/9Ds4t/Ef8m4PofMEgz5 Gt2swh9+rW5ngA+NQ8LwYs6DAzEY/cYgosJVkdFz7H6JZxpfT5ygggh8+T 4pBf1AceXAlb+3Vs48pxc5ILHO70yFsk9VtYFZEZXw9TCTVlcnWYAHIkiq ZXVmfpb4XlXpJwuYGXHVkfgRatPmDq1vUBNV/Emt3VX6jCjqqUnxnw== 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 DDC21F80208 for ; Fri, 12 Jul 2019 13:22:21 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:22:21 -0400 Message-ID: <1801771.HRRXnOL2G4@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 12 Jul 2019 17:22:26 -0000 On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > > 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 It's been a pretty quiet last call. I think the document itself is probably in pretty good shape with these questions as outliers. Shortly I plan to send a separate email on each of these with my perspective on both the issue and my read of the discussion so far so we can focus on driving each question to closure. Scott K From nobody Fri Jul 12 10:26:44 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 F1513120370 for ; Fri, 12 Jul 2019 10:26:42 -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=Y/Jzl4bR; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ar8jXR9y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tvwYafZdPzl for ; Fri, 12 Jul 2019 10:26:41 -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 C1C86120311 for ; Fri, 12 Jul 2019 10:26:41 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CBD9BF8071F for ; Fri, 12 Jul 2019 13:26:40 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562952400; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=FadgnU7DWl+qqJAt4CUQiR51vqOY5/ueQT6RAfyocGM=; b=Y/Jzl4bR081WOBUlX7qjJMMDtEjZ+dcLINtCS/kq99FyYNVKA8bXbhsm vTpzAFJPu7F9Dx2n2axQG/nCy/meCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562952400; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=FadgnU7DWl+qqJAt4CUQiR51vqOY5/ueQT6RAfyocGM=; b=ar8jXR9yfxG6Or/oKQpwT1LcYD3pudzsXlb5D6uCgvCK9T9+o2UEUFVH /o+T9d+uu3YLrdQWS1dd7pNb/ijLC5ObQCI+meO7t7LJGM2U+W6MJbjFvR /DxHdGToooNqWNb50HM2BGZuznI6kEseZN2PY7IB97V1GVi0G2uyjkFks0 eCswLrxO6Kn4jaGT53A6fV07MWOhd2gYGba/bCzQNlM99E6+tV1AXTuThA ugERwevq2LhP/jyy2bl3PrqgK2eZycVcjULK6p4sEZmXatuOyLEdwBuwwd lMk7pBRh4Zl1HliqirhIT+9biLlq8SH2uvz/sWIy+eeW57scjWI/SA== 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 9CBCEF80607 for ; Fri, 12 Jul 2019 13:26:40 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:26:40 -0400 Message-ID: <1890995.riJRFoXRoW@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Introduction context was: Re: Working Group Last Call: 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, 12 Jul 2019 17:26:43 -0000 On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > > 1. What further context is needed in the introduction The only comment on this so far during WGLC is that it is clear as is. As the document author, this is one I have a hard time assessing. It's clear to me, but I know what I meant when I wrote it. If anyone is still concerned about this issue, I would strong encourage you to provide suggested text. I think the WG should be pretty open to accepting such changes (as long as they are technically accurate). Even if it makes the document a bit longer, I think clarity is worth it. Standing by for inputs/feedback. Scott K From nobody Fri Jul 12 10:30:41 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 3A0BE1203AF for ; Fri, 12 Jul 2019 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ZsHjhGbX; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Vd2jgS2b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJmWxeWT_eVr for ; Fri, 12 Jul 2019 10:30:37 -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 C031F120310 for ; Fri, 12 Jul 2019 10:30:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 76E15F8071F for ; Fri, 12 Jul 2019 13:30:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562952636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vgbDVDFhro3+N3ens7aL/SC7QGdIXX9m9n1IVTyXZUo=; b=ZsHjhGbXIo0xZVSav5zAc4Axn7ZxLaeNCALqRWczxrzjNvJSBO/pkRDO 2p9hySSeumO+u5l0swWmzrkDgJquAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562952636; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vgbDVDFhro3+N3ens7aL/SC7QGdIXX9m9n1IVTyXZUo=; b=Vd2jgS2bJGW7HA1jRFq4uClLdYZ6V6vOOa5o7Qv/Rh2Xl+/hLLFYdv4/ 21YFP58qZjheps16eTI0cj0LMxvztNcLfcE5TiXRuLoQO9TkQf1FTQtMjW ulwKoIxsQOmapN4uh0HdE99VYtZoeQt9N0KWHVr8pb18LkCHxxBQsjSqzP fWgcKi83+QjspR5JCPhFe8bf1IM/vwmO1OAD+44BoTFYGwPF+yrOpqZQPD XBAy4AK9FP6M3n5YRuq+vJt1WtN/AjNnNoWiIWYsXaiG3Fxpebzkoj0mcr 2VgGMTS9FnmBXnerwcJX4/enNWBpq4t82E6jaDzN1mvczcvh/Ch4Ug== 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 486FDF80607 for ; Fri, 12 Jul 2019 13:30:36 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:30:35 -0400 Message-ID: <1851683.DtEN5jD5Wj@l5580> In-Reply-To: <54eac0ab-985e-69be-5985-8a53c51c7580@tana.it> References: <54eac0ab-985e-69be-5985-8a53c51c7580@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 12 Jul 2019 17:30:39 -0000 On Thursday, July 11, 2019 6:07:50 AM EDT Alessandro Vesely wrote: > > 2. If explicit call outs to ICANN/limited operator capacity to > > implement are needed > > Appendix B.1 lacks a criterion to establish enlisting. Couldn't we > require an explicit statement about seizing DMARC reports in, say, the > delegation report? Alternatively, that policy can be stated in a > well-known place under the delegation services URL, so that > registrants know what they do. It's in the appendix because we don't have a clear path forward. This is part of the experiment. We need to be careful though since different PSDs operate under different authorities and controls, so there is a point beyond which it's not the IETF that decides. Scott K From nobody Fri Jul 12 10:31: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 8329F1203C2 for ; Fri, 12 Jul 2019 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=verisign.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 uy5QDYlLG3UX for ; Fri, 12 Jul 2019 10:31:43 -0700 (PDT) Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 506ED120310 for ; Fri, 12 Jul 2019 10:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1242; q=dns/txt; s=VRSN; t=1562952703; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=vCcM3f2SGCZRmhYsIrJLRK+6HfjeAFDofRVCgHvQkW8=; b=qA/sGRwK7gPpgJ8A7RxlLvuOG1T/d75M6AawDkT167FXMVWwYwZGJI5o 9f0lrDL+B2GhDa2WfgxDADi+Oyh4D2p/Jo/OIoWgn/G215/OVAzTMzvo/ 7gFX6e4ik3PT4jkExdaHe4PzRPYDLX03WCp3SmLLH3g+6ZmhL+ZAoDtN6 Kcl0T9XsYMH8pq+HWjcrxSdJsrq76MyYOrUU6sN0adawsREAcVvFtGf9A KFmSvQTC5qvABxsDyj50Ua/hc0jEJR1JQMF5hdStg2uOuSaKPcAufrrau J75DguUQSlmBXQqd5NkS4yrSa0QXp8F/qCam6fwkaF6QL+/8zViqKZTLL A==; X-IronPort-AV: E=Sophos;i="5.63,483,1557201600"; d="scan'208";a="7960686" IronPort-PHdr: =?us-ascii?q?9a23=3A7gA4zxfDtsqO6RYeyq5nEp93lGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxc26ZBWN2/xhgRfzUJnB7Loc0qyK6vqmBDRLuM/Y+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAiooQnLtsQanYRuJrssxh?= =?us-ascii?q?fUv3BFZ/lYyWR0KFyJgh3y/N2w/Jlt8yRRv/Iu6ctNWrjkcqo7ULJVEi0oP3?= =?us-ascii?q?g668P3uxbDSxCP5mYHXWUNjhVIGQnF4wrkUZr3ryD3q/By2CiePc3xULA0RT?= =?us-ascii?q?Gv5LplRRP0lCsKMSMy/WfKgcJyka1bugqsqRxhzYDJfIGbOvlwfq3fctMbWW?= =?us-ascii?q?VPUcleWjddAoOlbYsDE/YNMfpGo4T7ulAArQG+BQ6pBO73xDNGhHj23ak+0+?= =?us-ascii?q?s/FwHJxxIvEM4NsHjMsd77KbsdUeepzKnUwznIcvRb2Sz96IjPdhAhpe+DXb?= =?us-ascii?q?RrfsXP1UYvFBjIjkuOpoz/PjOVzeUNs2ed7+Z6Se2vjGsnphh3rzOyyMksjY?= =?us-ascii?q?zJiZgUylDC7Sh5wZg6JcG2SEJhZt6kCpRQuieHPIV1WsMvW3xktDogxrEbu5?= =?us-ascii?q?O2cjIGxIknyhPRcfCKfIyF7gr+WOqNOzt0mXBodK6lixqv/kWtyffwWtS33V?= =?us-ascii?q?pSoCpKjNrBumwI2hHW6MWIVudx8V2k1DqSyw/c9uRJLEApmqXFJZ4sx7o9mY?= =?us-ascii?q?cOvkvdGCL9hV/4g7WMdko+/+il8+HnYrL7qZCCL4J0kQT+Mrg2msy4HOQ4Lh?= =?us-ascii?q?ACX2iF9uS4073u5VD0TqlSgPErkqbXqJ/UKsUHqqKnGQNVzJos6xGlDze+yt?= =?us-ascii?q?gXh2QIIEhbeBKdlIjpPUvCL+z/Dfe6m1iskTFryO7aPrD5H5nBMmLPnKrjcL?= =?us-ascii?q?tz8UJQ1Qo+wN5F659bDrwNOPfzVVXwtNzcAB85KQu0w+P/BdVm1oMeXmaPAq?= =?us-ascii?q?uHP6PUqlCH+P4gI+qXaY8Lpjn9Mfkl5+XvjX82n18RZ7Wm3ZwSaHygBPRpP1?= =?us-ascii?q?2ZYWbwgtcGCWoKpQk+TOjriF2ZTT5efHWyX6Mg5jEnFo2mF4LDSZqrgLCbwC?= =?us-ascii?q?i7GZhWbHhcCl+QCXfoa5mEW/AUZS2PJ89uiCYEWqS6Ro8gyx6uqAH6x6BgLu?= =?us-ascii?q?rO9S1L/a7kgZJu5OnSjg0a9j1oE8mH1miLCWpzmylAEyQ12KFkvWR+y0uf3L?= =?us-ascii?q?J9ivoeHttWsbcBGAs/PITX5+13F960XRjONJ/dRFOvWN6OADwtQJQ22dBYMG?= =?us-ascii?q?hnHND3xDDE2y6nBbUYnL/PTKc/9b7AlTClPMZ6z3LL0qMshFoOXMZVNHania?= =?us-ascii?q?g5/A/WUd2a236FnrqnIPxPlBXG832OmDKD?= X-IPAS-Result: =?us-ascii?q?A2EkAAAawyhd/zGZrQplHAEBAQQBAQcEAQGBUwcBAQsBg?= =?us-ascii?q?wCBLAqMLoxWmHqBeQIJAQEBAQEBAQEBBwEjDAEBAoQ+AoJ6NAkOAQMBAQEEA?= =?us-ascii?q?QEBAQQBAQEChiUMgjoiHE1rAQEBAQEBIwJELAEBAQECATpEBwQCAQgRBAEBA?= =?us-ascii?q?R4FCzIdCAIEARIIXoI9gXseA61ChDIBhgEGgTQBiUGCNIFBPoEPAoMSPoJhA?= =?us-ascii?q?odDBKpiAwYCghmGWI0rI5gHjTSHRpAHAgQCBAUCFYFQghFwgzyCeIhOhT9yj?= =?us-ascii?q?0mBIQEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 12 Jul 2019 13:31:41 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Fri, 12 Jul 2019 13:31:41 -0400 From: "Hollenbeck, Scott" To: "sklist@kitterman.com" , "dmarc@ietf.org" Thread-Topic: [EXTERNAL] [dmarc-ietf] Introduction context was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONb/OrgJQ/wgp06bLSZb6msweabHPKwQ Date: Fri, 12 Jul 2019 17:31:40 +0000 Message-ID: <540f8051d1694c5a8f66a705bb26f41b@verisign.com> References: <1890995.riJRFoXRoW@l5580> In-Reply-To: <1890995.riJRFoXRoW@l5580> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Introduction context was: Re: Working Group Last Call: 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, 12 Jul 2019 17:31:46 -0000 > -----Original Message----- > From: dmarc On Behalf Of Scott Kitterman > Sent: Friday, July 12, 2019 1:27 PM > To: dmarc@ietf.org > Subject: [EXTERNAL] [dmarc-ietf] Introduction context was: Re: Working > Group Last Call: draft-ietf-dmarc-psd > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached > > consensus that must be resolved during WGLC: > > > > 1. What further context is needed in the introduction > > The only comment on this so far during WGLC is that it is clear as is. Perhaps you missed this original comment: https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk Last call version: https://mailarchive.ietf.org/arch/msg/dmarc/jzEqKAF_OqxBm35QW3rQoAglm_A Reply from John Levine: https://mailarchive.ietf.org/arch/msg/dmarc/2AIp6oZmPMeqVxGOHcY1ct_iv7E > As the document author, this is one I have a hard time assessing. It's c= lear to > me, but I know what I meant when I wrote it. If anyone is still concerne= d > about this issue, I would strong encourage you to provide suggested text. I included suggested text in the original note described above. Scott From nobody Fri Jul 12 10:33:49 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 A80201203C2 for ; Fri, 12 Jul 2019 10:33:46 -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=ASHiec6h; dkim=pass (2048-bit key) header.d=kitterman.com header.b=nf6XVFdZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-Q5QeGQ95sW for ; Fri, 12 Jul 2019 10:33:45 -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 2516C120310 for ; Fri, 12 Jul 2019 10:33:45 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 1FFF3F8071F for ; Fri, 12 Jul 2019 13:33:44 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562952823; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=+7it8Ie5WIXV+ve8DgKFtW3vFbffpS71mhTtoi3Z7/4=; b=ASHiec6hD/u4uZAgKctVfsEcjXl5prRBjGNWRAPhQEcBiRwJXSW4vxjv zQU7J+ocNEfEzgLfleo13VGgSk+CCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562952823; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=+7it8Ie5WIXV+ve8DgKFtW3vFbffpS71mhTtoi3Z7/4=; b=nf6XVFdZ1hWi+5XEPQHoNiDenh1utD8MybMGT7K8NiPDeZOcPUtWiwbj c0WS46y0gD6X3exNcaEOyfQS8wt8yujw08vhQnmKRQiKzBU9BtMm5ujTIv jg+pONe7ppEyEeXsrCw4lsUTwolAbqX8Pgq2kohqZQtxTdzYRNNm6Swf2j Oh/D+bj/MWZcaEso1QAHnSRytvG8PTAPuxmIktrxLOmdFAGIWVcB5rlBH1 cBHYu83t3c0JP754kxQcrMRWkB8SIN0AHvVLJYetIe2++2W2y3IotPAe1S QgEgPcc8ZiplZPHAyGJDmxHkfK3tMD5ueDqyXwLh5J2JpXABeVKshw== 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 DC218F80607 for ; Fri, 12 Jul 2019 13:33:43 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:33:43 -0400 Message-ID: <3070360.9zhkp9JZm9@l5580> In-Reply-To: <540f8051d1694c5a8f66a705bb26f41b@verisign.com> References: <1890995.riJRFoXRoW@l5580> <540f8051d1694c5a8f66a705bb26f41b@verisign.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Introduction context was: Re: Working Group Last Call: 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, 12 Jul 2019 17:33:47 -0000 On Friday, July 12, 2019 1:31:40 PM EDT Hollenbeck, Scott wrote: > > -----Original Message----- > > From: dmarc On Behalf Of Scott Kitterman > > Sent: Friday, July 12, 2019 1:27 PM > > To: dmarc@ietf.org > > Subject: [EXTERNAL] [dmarc-ietf] Introduction context was: Re: Working > > Group Last Call: draft-ietf-dmarc-psd > > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > As Secretary, there are three items that have not yet reached > > > consensus that must be resolved during WGLC: > > > > > > 1. What further context is needed in the introduction > > > > The only comment on this so far during WGLC is that it is clear as is. > > Perhaps you missed this original comment: ... That's issue #2 in Seth's email. I'm writing that one up right now. Scott K From nobody Fri Jul 12 10:41:23 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 08374120134 for ; Fri, 12 Jul 2019 10:41:21 -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=LpA68/lJ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=h8dSpE9M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxT-yOGBhuSg for ; Fri, 12 Jul 2019 10:41:19 -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 6CE6C1207E2 for ; Fri, 12 Jul 2019 10:41:19 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 0B589F8071F for ; Fri, 12 Jul 2019 13:41:18 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562953277; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eTAzZY1FvDKKDjVyPYNbhQl5nF+FMbOl2sXHUtHZchg=; b=LpA68/lJTKD7V5UUiZrvybrSnDqSpZgFnfIC1MqMXRNKX41O8Q2Rb+io 5lJYrSUIthvjM67MpcnH4rIx8BMjBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562953277; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eTAzZY1FvDKKDjVyPYNbhQl5nF+FMbOl2sXHUtHZchg=; b=h8dSpE9MIZfCXKllLsjRPXOt/GEQ5Ru7t2BtmmwlpjxmiGHY5cIj3Bq6 cIp7v7nnw8mwI72A3C4PnuYWnhHKesG4Hd8YI72uiav81AIt+STtkH0HRP 7rinU6RxTVfzUVLMYquijLdL2bsIJ4MpV2k0nj8dcsDNSIGhcxP6dgSl/v F19txWpXFlZGzaGUktWqvLEgK+1iSnAHV2cLdFZFmoV1ks75eHDAyhxIzJ UIoPxRRUOGgL+ajMjRR/03k1AvPRehYMV2L+P6VTwlPks7EGJV6VB/MkOC pr9ZGo2lYHeT7XNMmmEhWOZznNjJI6+jTSb/dgWtStpKgmVMXAJI2A== 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 CCC85F80607 for ; Fri, 12 Jul 2019 13:41:17 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:41:17 -0400 Message-ID: <1783751.gHVjF1RMII@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 12 Jul 2019 17:41:21 -0000 On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > 2. If explicit call outs to ICANN/limited operator capacity to implement > are needed There has been feedback in favor of adding this and none against so far. The specific proposal is: "Please note that today's operational and policy reality prevents this experiment from being deployed globally. If the experiment shows that PSD solves a real problem at a large scale, the results could prove to be useful in the development of policies outside of the IETF that would permit its ubiquitous deployment." Because RFCs are (approximately) forever, I'm concerned about words like "today's" in protocol documents, even experimental ones. How about this instead: "As of the writing of this document operational and policy constraints prevent this experiment from being deployed globally. If the experiment shows that PSD solves a real problem and can be used at a large scale, the results could prove to be useful in the development of policies outside of the IETF that would permit broader deployment". Also, since this is about ephemera and not protocol, I think it should go in Appendix A. Comments? Scott K From nobody Fri Jul 12 10:49: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 CF2741200E7 for ; Fri, 12 Jul 2019 10:49:50 -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=lwAj03sq; dkim=pass (2048-bit key) header.d=kitterman.com header.b=irLE8HT0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqqzldem3JaN for ; Fri, 12 Jul 2019 10:49:49 -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 6A54912046C for ; Fri, 12 Jul 2019 10:49:49 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id D86DFF8071F for ; Fri, 12 Jul 2019 13:49:17 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562953757; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=359F+mKciJhDMlQ2ZtY7wbHH7lpYBAY2ooTiWg4xcRs=; b=lwAj03sq2/Q9WH4PFCXw8KUvf2CQ/zIenJA8AcHMWL6Tr9e1OV3jnOJ6 QEpkBZZvHAriX1stmNv37FV+2C5vCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562953757; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=359F+mKciJhDMlQ2ZtY7wbHH7lpYBAY2ooTiWg4xcRs=; b=irLE8HT0gzpy6EeRqw8vUznMsYvcyZ4DCvFqOjPZKlid4i0KEp6P7bMY 45nU6RZssdIkUAAdn5T6xcV1OhZOqt8t4zPBPn93//YxaFh89ReF3bVfD0 DcTjCHNgeAz49tU/vjvNeBw6Ospxh9MojmTP9zCFRb/zNdKvpVcu5NbeT0 qanCyC5d9GacfNuomNXNTUKtULj7Clqy9wO4OCylB/FBSBy2Y1vBN5jKJ+ kAW/CzEUPWo4QqATBK/o/Wo7AN7uO4/wILYJOVWfLdkO1Tm3j/qw/yXdWH Jtw8ng62KMUjmssjyk4FjdpPm0c4eOhplW/P+gMPKuHu54I1WPQn0w== 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 A709BF80607 for ; Fri, 12 Jul 2019 13:49:17 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:49:17 -0400 Message-ID: <1893230.9INSBCnb99@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 17:49:51 -0000 On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs The limited feedback during WGLC has been favorable to this. This will require a rather larger change to the document than the other issues, but they are manageable and I believe I have most of the relevant text from earlier revisions. I think we should include this. As discussed in the previous issue, the PSDs that can deploy PSD DMARC today is limited. One of the few that are engaged with this effort that can has specifically requested it as a support to their broader DMARC deployment efforts within their PSD. Additionally, this may have utility for regular DMARC and now is a good time to explore the concept. Unless this is clearly negatively received, I'll propose specific changes to support it later today. I'll also update the existing implementation that's mentioned in Appendix C, but probably not today. Scott K From nobody Fri Jul 12 10:51: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 A388B120733 for ; Fri, 12 Jul 2019 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gZIVDtkA; dkim=pass (2048-bit key) header.d=kitterman.com header.b=DhCQbVVD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7Se-oJBHnWu for ; Fri, 12 Jul 2019 10:51:00 -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 29D8E1204C2 for ; Fri, 12 Jul 2019 10:51:00 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 3966CF8071F for ; Fri, 12 Jul 2019 13:50:59 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562953859; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=C113xN46yiGWGWRuWLQYO5leeJHAcYugbtc3F/UbarI=; b=gZIVDtkAWus/YeJn1uf2uJ0bUdm9497a/kJuFM8xINU7da08o+g9n3w5 +BH5NUzptZ3Kd4I5C30IJgqT8MloBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562953859; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=C113xN46yiGWGWRuWLQYO5leeJHAcYugbtc3F/UbarI=; b=DhCQbVVDh4LhTCoDV71+ZCke58WYl2TYfdM9MGoamWL0yltb3hdXpEN0 e2ES0o5PMvDmGOHzqC172uiCibEIUC8r5SZ5Kt7OesJUtXq0pmWAEi1BcI Rr+Sg2O7rPYHplwhOzbIlHZZzZe0nhFRtGTq601gurWZ+RC14JLrq53Uw3 xGJW519972t+43tahszJJ/EHo4HN4uWnFCcxlExFpOjJtAlVb3RDPcTOvX juiJUuCY+YeWJLhiTb4zDgGUn+ybW9cdUGWq+38jIBHFPvaFyCqUWXuwyT piOj0e1tDTg3kKSZ8HC+JNm3+XXwUC+whORosrQlPEzzLfnQT4t0HQ== 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 0988BF80607 for ; Fri, 12 Jul 2019 13:50:59 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 13:50:58 -0400 Message-ID: <2017232.d4u0W5DkgM@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Implemnetations was: Re: Working Group Last Call: 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, 12 Jul 2019 17:51:02 -0000 On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: ... Additionally, if anyone else has code for this, please let me know so I can update Appendix C. Scott K From nobody Fri Jul 12 10:55: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 513EC1205F6 for ; Fri, 12 Jul 2019 10:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YPcHhV1p9k2 for ; Fri, 12 Jul 2019 10:55:11 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 2688F1200F3 for ; Fri, 12 Jul 2019 10:55:11 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k20so22137357ios.10 for ; Fri, 12 Jul 2019 10:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cinwa9/iNa9F6NiiFHObj/nNSrOfGTt/CUTor6garGs=; b=PokQREbG+oOaaoirDSqBUdQNtpsOINpDRJuAsLkePmhswb0jhw7++eYiO89eFk0QjT DH0+0ep4cBHz/Vb/1x21gKoUSQQBUx0CcnYTO8TwUO5RstYOO3z8eNZbxsSDO8qRhRkp jF3R0cWyUXeyn9GqY6Y/3cSenT4Vz9r5gisaw= 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=Cinwa9/iNa9F6NiiFHObj/nNSrOfGTt/CUTor6garGs=; b=daRzcuMcUV9TrdAHTCKPuDlS6si1UBk/pxluO13qFyxl8F+iWTA+o5VqLUe/81rhmp Qa8Khpe7MGxU7RYfxSJiJqWgfQ00OP4eP/YSNfnJvzQlS4II/dwD+C8nlb5J1+ZPy8N4 FDTNvto9mueEopfoqrqiq658HPfopKOQkrwfQHc5MggUX/gAZpWTYOqgxwFsGfVJ7u+F ADqiYfawr/qc71qZbjV6u1B+cuKjNxhxQBjIVc6rGJ/4phcpWtcAuZEbF6bh3cXDs3/D bq3FVNIi7Jo8/A4JWGVxhe3xfl2X3jSRoae28etQkUlPlxn051ExYU7Iw2X4frLZdSD8 p6ag== X-Gm-Message-State: APjAAAUROG8ketsOm084q3UCUZi68f3JSE6pATTCo+3+F9vS2pGfALB3 fDCDXx7mPOWQxz7enk2Exe2t9U2wAq4xB2/R4BsKG/IH X-Google-Smtp-Source: APXvYqzJ//+RRA73F0aOlmrgxpv2FORxRuoi4g6uyZuwdowjQMkwMOgNjb5hsjhpSAZuA7CCBH83o0Cr21eh9osX/b4= X-Received: by 2002:a5d:948a:: with SMTP id v10mr8066721ioj.103.1562954109715; Fri, 12 Jul 2019 10:55:09 -0700 (PDT) MIME-Version: 1.0 References: <1893230.9INSBCnb99@l5580> In-Reply-To: <1893230.9INSBCnb99@l5580> From: "Kurt Andersen (b)" Date: Fri, 12 Jul 2019 10:54:57 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000082ebf7058d7f9c88" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 17:55:14 -0000 --00000000000082ebf7058d7f9c88 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs > > The limited feedback during WGLC has been favorable to this. > > This will require a rather larger change to the document than the other > issues, but they are manageable and I believe I have most of the relevant > text > from earlier revisions. > > I think we should include this. > I am much more concerned with adding another tag that can only be used in a PSD-DMARC record. I would be much more open to make a "normative" change to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC record, than to make this a special case for PSD-DMARC records. --Kurt --00000000000082ebf7058d7f9c88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2019 at 10:50 AM Scott Kitter= man <sklist@kitterman.com>= ; wrote:
On Wedn= esday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:

> 3. If an np=3D tag is needed to allow PSD functioning for only NXDOMAI= Ns

The limited feedback during WGLC has been favorable to this.

This will require a rather larger change to the document than the other issues, but they are manageable and I believe I have most of the relevant t= ext
from earlier revisions.

I think we should include this.=C2=A0

= I am much more concerned with adding another tag that can only be used in a= PSD-DMARC record. I would be much more open to make a "normative"= ; change to the DMARC tag list (RFC 7489 section 11.4) to define np for any= DMARC record, than to make this a special case for PSD-DMARC records.

--Kurt
--00000000000082ebf7058d7f9c88-- From nobody Fri Jul 12 11:01:19 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 D9A361200F3 for ; Fri, 12 Jul 2019 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=IBEuE2Kh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=trbqXCfy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtqyyQsnOGSj for ; Fri, 12 Jul 2019 11:01:15 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31DA1207D4 for ; Fri, 12 Jul 2019 11:01:13 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 737DB205B8 for ; Fri, 12 Jul 2019 14:01:12 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Fri, 12 Jul 2019 14:01:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=U2LfsYxZOPSH7gQo0C2FEOFgxYpCZOs K6bbxYqiB/Q8=; b=IBEuE2Khck+oCJOfw+DdQZkgBWPy8plPjhL4KsvE73rqv1v eX9Mump1FtzbPUq1RCo7/tlrKlnj9j/86/SKpvwo5ymufxk8Yh1RMpjnEnFfABxC znTXI4eOd64iNuCj76XREmp55/zh5PYkyptIFRI84+sEnhDJitSOZIBp+WlcBssZ Q2yeKw8neJxG4L/HRlHGsEYtOcXW6zuwxrWmAQa17+Mn8uhXQvZ5KAnKo43x2wwz 2nZn91HhlV5qj36kawaSYjN/2y1L50DmfO5msh4gGd1HW3s6lJkmoOBE7LptQln2 cQ4tYTuYJnRQhvx/++upfCu70r6tg3IbKTmmjWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=U2LfsY xZOPSH7gQo0C2FEOFgxYpCZOsK6bbxYqiB/Q8=; b=trbqXCfy7gRRHPoE/fYyLa mo3kw3UxaHKG86YAR2xXJIYHdjKjaY7d7ZWppwnQfmYRx4ylIj4nvCvZW+Loo+IC 9cPWCKv3jtJQUOES6sKInHTxwJcFCFFMwtqT+UhTT2GdliAK6mkwot5Tnf4CkyA1 Q8Sx4E9lnTZ0YEHW9NNbPyHghgmPBhdc8GXaYn53wqQyAWFGDXUeH1ZeUxJAXNZl BRsyQk1cIxTumosozdq8UoxPfL+JnAxM0g3YangGPr8F7tUcY4g7a0BXf1XPks7l 5hWUV4anw85XayJBHYJzWdF8ftVoQ9B01UHxImtOiu04fta1BrL56OMkKI9jNECA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrhedtgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucffohhmrghinhepihgvthhfrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhm rghilhhfohhrtggvrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 12A341400A1; Fri, 12 Jul 2019 14:01:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> In-Reply-To: <1783751.gHVjF1RMII@l5580> References: <1783751.gHVjF1RMII@l5580> Date: Fri, 12 Jul 2019 13:59:55 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=c25385236c6f4b70993a0b6ddec27bf1 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Mention_ICANN/operational_limitations_was?= =?utf-8?q?=3A_Re=3A_Working_Group_Last_Call=3A_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, 12 Jul 2019 18:01:18 -0000 --c25385236c6f4b70993a0b6ddec27bf1 Content-Type: text/plain On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached consensus > > that must be resolved during WGLC: > > > 2. If explicit call outs to ICANN/limited operator capacity to implement > > are needed > > There has been feedback in favor of adding this and none against so far. > > The specific proposal is: > > "Please note that today's operational and policy reality prevents this > experiment from being deployed globally. If the experiment shows that PSD > solves a real problem at a large scale, the results could prove to be useful > in the development of policies outside of the IETF that would permit its > ubiquitous deployment." > > Because RFCs are (approximately) forever, I'm concerned about words like > "today's" in protocol documents, even experimental ones. > > How about this instead: > > "As of the writing of this document operational and policy constraints prevent > this experiment from being deployed globally. If the experiment shows that > PSD solves a real problem and can be used at a large scale, the results could > prove to be useful in the development of policies outside of the IETF that > would permit broader deployment". "[D]evelopment of policies outside of the IETF" strikes me as a little odd since IETF isn't setting policy *per se*, although substitute language that is just as succinct is escaping me at the moment. Thanks, Stan > > Also, since this is about ephemera and not protocol, I think it should go in > Appendix A. > > Comments? > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --c25385236c6f4b70993a0b6ddec27bf1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote:
On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> As Secretary, there are three= items that have not yet reached consensus
> that must be resolved during WGLC:

>= ; 2. If explicit call outs to ICANN/limited operator capacity to impleme= nt
> are needed
<= div style=3D"font-family:Arial;">
There has been feedback in favor of adding this and none against so= far.

The specific proposal is:

"Please no= te that today's operational and policy reality prevents this 
experiment from being deployed glo= bally.  If the experiment shows that PSD 
solves a real problem at a large scale, the results= could prove to be useful 
in the development of policies outside of the IETF that would permit = its 
ubiquitous deployme= nt."

Because RFCs are (approximately) forever, I'm concer= ned about words like 
"t= oday's" in protocol documents, even experimental ones.

Ho= w about this instead:

"As of the writing of this document= operational and policy constraints prevent 
this experiment from being deployed globally. = If the experiment shows that 
PSD solves a real problem and can be used at a large scale, the r= esults could 
prove to b= e useful in the development of policies outside of the IETF that 
would permit broader deploymen= t".

"[D]evelopment of policies outside of th= e IETF" strikes me as a little odd since IETF isn't setting policy *per = se*, although substitute language that is just as succinct is escaping m= e at the moment.


Thanks,
Stan


Also, since this is about ephemera and not protocol, I think it s= hould go in 
Appendix A.=

Comments?
Scott K


____________________________________= ___________
dmarc mailing lis= t
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dma= rc


--c25385236c6f4b70993a0b6ddec27bf1-- From nobody Fri Jul 12 11:16:19 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 A452012085E for ; Fri, 12 Jul 2019 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKXskEiTtSw6 for ; Fri, 12 Jul 2019 11:16:14 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC9212086F for ; Fri, 12 Jul 2019 11:16:08 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id q20so10341057otl.0 for ; Fri, 12 Jul 2019 11:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LhfWeWbhek68YZ8xA3u4LJheJfAEy4+mGhRkXe2iXwg=; b=DaOJ4UcCK5qhaHjordXoOgiC48/ykcdosSYC9bh44Z35no6xZmMd/Vdm710xVss3BE 7pun7DV6lWBevun3JWmoGTkidbds0XYz+qPPjHH80rYgNDoHhWeGn55RrX3Vtxs6d8Yg Dgvxv/4Wje7xF9pc1FrDirj5w+I72yWfxg1byBnMGfWx8MT3CxIwwQJQ43ZAJWYJwxBI l2am9sd7btyfS1S6mS3lNbfjmQjDpSY1wd9zGuHmUaiPt64GNGzk5YSNYRc1QrnRKRAm VJD3usZGQ95Z1YpKaegJFCwcXiOEUWZ6t8J7K10q1srXZCjm7PDfu7GyKvefNXF+Rcum h55A== 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=LhfWeWbhek68YZ8xA3u4LJheJfAEy4+mGhRkXe2iXwg=; b=JCVWsPfkMze6JgcFk7cKFfJcah7l2YoCP+SCgCoKE/lSEJavMV6HaqRwociCKxx4CM LHr91fpiVlV7QlHZvq7lgHwRhh1vb1jb0cmi/DoWtX+ccVCcK8ExO+Joy2CAGHdTWsKt ENfN6BNlp5FaS+JUEQWPynbRdue8F2DGaqPJbrcYrq9NZTI9RzVudX1NoPSHtJ1DfdOb azBLTGFRGuC21Ps8xs/nzYwbzaI6bgJoiE/Oh7l+zzeKo1YR0IPg+g1nL6Ms6gxp4LVQ Igy+PR9nEAys34uj4YcuIKZh+5vOgu0hg035UDKSZT0nW0OY97e2wURO7wOLVQ4+sl+/ P3+Q== X-Gm-Message-State: APjAAAW4vjeef1YOHsdyLJtSiFz+keVR3FlymttxpMJvDnDh7qqLSZmQ HZgJ9UnvzlYYnBs9sBjOovNG+f9abCCGSsC/JOA= X-Google-Smtp-Source: APXvYqy2dCu71Uqjm6uCqW6BwB+kdkVE7Xi9WL2Gq3arGGMYVTHk9d0bQkQr8Nh7mLBUkE7ofxE3WC/frcS4q8RoExs= X-Received: by 2002:a9d:6f09:: with SMTP id n9mr9047849otq.335.1562955366962; Fri, 12 Jul 2019 11:16:06 -0700 (PDT) MIME-Version: 1.0 References: <1893230.9INSBCnb99@l5580> In-Reply-To: From: Seth Blank Date: Fri, 12 Jul 2019 11:15:51 -0700 Message-ID: To: "Kurt Andersen (b)" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000072aeb4058d7fe73d" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 18:16:17 -0000 --00000000000072aeb4058d7fe73d Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote: > I am much more concerned with adding another tag that can only be used in > a PSD-DMARC record. I would be much more open to make a "normative" change > to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > record, than to make this a special case for PSD-DMARC records. > I am also concerned with adding any new policy-related tags, due to the confusion they create that limits adoption. However, a very clear case for an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov and .mil have stated they also want this behavior. Others have shared similar opinions privately. Since PSD is an experiment, I think this is a fine place to test an np= tag. If it gets usage, then we have a clear argument for it being a normal tag for DMARCbis. If not, then it can be jettisoned altogether. Adding this tag for PSD will simply need explanatory text in the Experimental Considerations outlining this. Seth --00000000000072aeb4058d7fe73d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2019 at 10:55 AM Kurt And= ersen (b) <kboth@drkurt.com> = wrote:
I am much mo= re concerned with adding another tag that can only be used in a PSD-DMARC r= ecord. I would be much more open to make a "normative" change to = the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC recor= d, than to make this a special case for PSD-DMARC records.

I am also concerned with adding any new p= olicy-related tags, due to the confusion they create that limits adoption. = However, a very clear case for an NXDOMAIN policy has been made by UK NCSC = for .gov.uk, and both .gov and .mil have stat= ed they also want this behavior. Others have shared similar opinions privat= ely.

Since PSD is an experiment, I think this is a= fine place to test an np=3D tag. If it gets usage, then we have a clear ar= gument for it being a normal tag for DMARCbis. If not, then it can be jetti= soned altogether.

Adding this tag for PSD will sim= ply need explanatory text in the Experimental Considerations outlining this= .

Seth
--00000000000072aeb4058d7fe73d-- From nobody Fri Jul 12 11:25: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 36DF21207EC for ; Fri, 12 Jul 2019 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aw7vYQmXt8kt for ; Fri, 12 Jul 2019 11:25:48 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BCB1207DE for ; Fri, 12 Jul 2019 11:25:48 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id h19so9795720wme.0 for ; Fri, 12 Jul 2019 11:25:48 -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; bh=rhndh1Ib4gPST2gQQqAHKNpykfaiNuNGw701oyrxBdo=; b=ktVQxyE6rM5bbbatFUxnn5kw0irLAFEW+WRa1xFWBPNt2xoxS+t2ELlUyGdQf8ZOIe rBpUnsSu62g5/z6mBX4fkIHatcBL5MH4GApUO7x5mcuugkX3DHJiikEK6ZbVAOZIO+HK s/oaNgMAjR8i0n9mA46iWvvRquUgVf1Q8SDQgF8k0o3pKqWfuYLSYpSfsTHXauAgXuVc /uXKiP2mT9f9zwExZL5PlT58yUEoutEnbbwXHw0EoWgzTgXDSNtpujsMHPHWYBm7ovf7 vd807V7ihdJrkDWaocmJk5RTef/CgF/zTmHoERKtxlFiFOR0X7+MmbcjQKDgYcvxhRuH wIAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rhndh1Ib4gPST2gQQqAHKNpykfaiNuNGw701oyrxBdo=; b=NNbVh9O/fw3t4nIQyojWOTQRtgaWGo4d3UM9sH2bJlrhOyHbCZSr0HZrmddAc8WiaV L5bTSkxwm0G5JjvCP1BRPUOAbtKBxT6rUK5I3VqcsEW2ZEmLiGDaQDvYchyBkzjteAch umSBCqlMUHGMhn7ndJZWrz0AUSmzrMqU5Hz2BnQ5DxQRJ2zCxiXATIPN+PBmV+6HaxVM 2e+bvmA8Q0mwIeTBEzf8+0nN9BKNtftROTAnVh0lsjDfxIZdtGMXYB9tU2D7eylBS76O hv7PMOFn/xNMGadCWf8JKs7oJeP3MYf2HTATdOz4FwyA2/yLpyUz/P4eGgCSqUBqS9pX rnWQ== X-Gm-Message-State: APjAAAXimfv7xSniVHeIfQLIwO0rBhjjxlNTOL0MdEGLH6J9IK/qFvh/ b7WpOt/tY58gKPOR03Qohj1uqjAZ5CKyirPV8BvgGg== X-Google-Smtp-Source: APXvYqym/U/alnPZK5FtiwLq9zu6hiB33jwAY76axhzEtlnUd2faAZp/VqPx25LflLKiOJgK968yALB8N1JVa5no+iQ= X-Received: by 2002:a1c:751a:: with SMTP id o26mr10645591wmc.13.1562955946120; Fri, 12 Jul 2019 11:25:46 -0700 (PDT) MIME-Version: 1.0 References: <1783751.gHVjF1RMII@l5580> In-Reply-To: <1783751.gHVjF1RMII@l5580> From: Dotzero Date: Fri, 12 Jul 2019 14:25:33 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f7dc88058d800983" Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 12 Jul 2019 18:25:50 -0000 --000000000000f7dc88058d800983 Content-Type: text/plain; charset="UTF-8" +1 Your proposed rewording makes sense. Michael Hammer On Fri, Jul 12, 2019 at 1:41 PM Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached consensus > > that must be resolved during WGLC: > > > 2. If explicit call outs to ICANN/limited operator capacity to implement > > are needed > > There has been feedback in favor of adding this and none against so far. > > The specific proposal is: > > "Please note that today's operational and policy reality prevents this > experiment from being deployed globally. If the experiment shows that PSD > solves a real problem at a large scale, the results could prove to be > useful > in the development of policies outside of the IETF that would permit its > ubiquitous deployment." > > Because RFCs are (approximately) forever, I'm concerned about words like > "today's" in protocol documents, even experimental ones. > > How about this instead: > > "As of the writing of this document operational and policy constraints > prevent > this experiment from being deployed globally. If the experiment shows > that > PSD solves a real problem and can be used at a large scale, the results > could > prove to be useful in the development of policies outside of the IETF that > would permit broader deployment". > > Also, since this is about ephemera and not protocol, I think it should go > in > Appendix A. > > Comments? > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f7dc88058d800983 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 Your proposed rewording makes sense.
Michael Hammer

On Fri, Jul 12, 2019 at 1:41 PM Scott Kitte= rman <sklist@kitterman.com&g= t; wrote:
On Wednesday, June 26, 2019 5:21:14 PM = EDT Seth Blank wrote:
> As Secretary, there are three items that have not yet reached consensu= s
> that must be resolved during WGLC:

> 2. If explicit call outs to ICANN/limited operator capacity to impleme= nt
> are needed

There has been feedback in favor of adding this and none against so far.
The specific proposal is:

"Please note that today's operational and policy reality prevents = this
experiment from being deployed globally.=C2=A0 If the experiment shows that= PSD
solves a real problem at a large scale, the results could prove to be usefu= l
in the development of policies outside of the IETF that would permit its ubiquitous deployment."

Because RFCs are (approximately) forever, I'm concerned about words lik= e
"today's" in protocol documents, even experimental ones.

How about this instead:

"As of the writing of this document operational and policy constraints= prevent
this experiment from being deployed globally.=C2=A0 If the experiment shows= that
PSD solves a real problem and can be used at a large scale, the results cou= ld
prove to be useful in the development of policies outside of the IETF that =
would permit broader deployment".

Also, since this is about ephemera and not protocol, I think it should go i= n
Appendix A.

Comments?

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f7dc88058d800983-- From nobody Fri Jul 12 11:27:20 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 4C2EF1207F8 for ; Fri, 12 Jul 2019 11:27:18 -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=GURjmYq/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=e856fMXR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qB59LCLicaU for ; Fri, 12 Jul 2019 11:27:15 -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 9FBE112081F for ; Fri, 12 Jul 2019 11:27:07 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 4CD59F8071F for ; Fri, 12 Jul 2019 14:27:06 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562956026; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BNoqHZZ45tFrm6S6vo75PnXAmY833jXDN0eiUfwvQzM=; b=GURjmYq/wuMsolwFEtcgvTh4MXSaMkNCjhoGtNvEAd39lksEAHjvDlpk TxA6dsJxP6l/D+CXHl8zt9KieJaOAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562956026; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=BNoqHZZ45tFrm6S6vo75PnXAmY833jXDN0eiUfwvQzM=; b=e856fMXR5SVkCu4bURqvjJ5k88KSF4zSTu0PjNHQqyPpXpwenq3UK8x/ XpMp1YBRIdp65hDuF34zGClWz+xeVxv2k6RPYjjSje/K5fKEJD2drrJSEM MUrmU9XgFbviU56up3suYU3MEHeNvweYzTdb02xrwW8c0JHzO3xNPbszRc RxML5J1/huV7zJsF3RwUYM5MO/NzaTSZ9/VV2yfIjRqoRpI9fxY81cJFIR 42LbnnDdjPWwTDnMCzxaYsMpEDKKw5G9FHtRRBNHfbWtX59Z2RjzmwTmFb BRu5tLoRYUMtezeh0t19FIFZ3nmRMzu3rP0Nj0nGNDCuH2zZB25qnA== 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 0E9E9F80607 for ; Fri, 12 Jul 2019 14:27:06 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 14:27:05 -0400 Message-ID: <12139607.XScsT9yxuP@l5580> In-Reply-To: <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> References: <1783751.gHVjF1RMII@l5580> <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 12 Jul 2019 18:27:18 -0000 On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote: > On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > As Secretary, there are three items that have not yet reached consensus > > > that must be resolved during WGLC: > > > > > > 2. If explicit call outs to ICANN/limited operator capacity to implement > > > are needed > > > > There has been feedback in favor of adding this and none against so far. > > > > The specific proposal is: > > > > "Please note that today's operational and policy reality prevents this > > experiment from being deployed globally. If the experiment shows that PSD > > solves a real problem at a large scale, the results could prove to be > > useful in the development of policies outside of the IETF that would > > permit its ubiquitous deployment." > > > > Because RFCs are (approximately) forever, I'm concerned about words like > > "today's" in protocol documents, even experimental ones. > > > > How about this instead: > > > > "As of the writing of this document operational and policy constraints > > prevent this experiment from being deployed globally. If the experiment > > shows that PSD solves a real problem and can be used at a large scale, > > the results could prove to be useful in the development of policies > > outside of the IETF that would permit broader deployment". > > "[D]evelopment of policies outside of the IETF" strikes me as a little odd > since IETF isn't setting policy *per se*, although substitute language that > is just as succinct is escaping me at the moment. ... removal of constraints ... ??? "As of the writing of this document operational and policy constraints prevent this experiment from being deployed globally. If the experiment shows that PSD solves a real problem and can be used at a large scale, the results could prove to be useful in the removal of constraints outside of the IETF that would permit broader deployment". Better? Scott K From nobody Fri Jul 12 11:28:44 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 ACA1A12082E for ; Fri, 12 Jul 2019 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=KHpC18ug; dkim=pass (2048-bit key) header.d=kitterman.com header.b=OGH+O2Cu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCUTPqBMZZ5u for ; Fri, 12 Jul 2019 11:28:41 -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 5129A120820 for ; Fri, 12 Jul 2019 11:28:41 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 5F33AF8071F for ; Fri, 12 Jul 2019 14:28:40 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562956120; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WpjQmmWUEuGJ8mA7vdYjvNCt6cjwKPYTP/l6fKT75OU=; b=KHpC18ugSOFQhKQP5KGzpm1SvHbY+B3xBL2asDnQhivRbfASvFK3U/2I dhM+XeUjbLES7GH5oz3ckXFNaf7wAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562956120; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WpjQmmWUEuGJ8mA7vdYjvNCt6cjwKPYTP/l6fKT75OU=; b=OGH+O2CuXQRNNK0YQ7m2A+z4rrLnXtsBp+gfkKzywcvhnyhHULP10Tm3 7/fYyqsaS52QvFhmPo7RZEMRlVQbqNtyUrmDxJm18twkSyKPzwyalSoqJ/ /MLOI9sES7FHbwanpIzFoYZ4SoXJjDyvEsdN1YQ3o35zgaTmVOruSzCVac tMoXznpT6fbLGZ9fgATk+iAo4x0Kb8a4eOBciLDcE5SGlw++YXGgtwFvGP vH0lQp6ogR3ahP3HQWwHuI42JedLtOjx7a9SrHHJhFjno57bgCbh1tZhxE CTnXk1vcOi+nTZIZoDcM/UuExzdOXMfp8v6OU7NquK1phZRVCwF6UA== 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 32750F80607 for ; Fri, 12 Jul 2019 14:28:40 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 14:28:39 -0400 Message-ID: <1958020.28HeBAo97T@l5580> In-Reply-To: References: <1893230.9INSBCnb99@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 18:28:43 -0000 On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > wrote: > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs > > > > The limited feedback during WGLC has been favorable to this. > > > > This will require a rather larger change to the document than the other > > issues, but they are manageable and I believe I have most of the relevant > > text > > from earlier revisions. > > > > I think we should include this. > > I am much more concerned with adding another tag that can only be used in a > PSD-DMARC record. I would be much more open to make a "normative" change to > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > record, than to make this a special case for PSD-DMARC records. I agree. My intent is to add the tag to be used experimentally for any DMARC record. Part of the experiment is to see if it's useful beyond PSD. Scott K From nobody Fri Jul 12 11:28:59 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 13168120840 for ; Fri, 12 Jul 2019 11:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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=verisign.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 xntVtl_eQCBE for ; Fri, 12 Jul 2019 11:28:48 -0700 (PDT) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 EA0A5120886 for ; Fri, 12 Jul 2019 11:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2475; q=dns/txt; s=VRSN; t=1562956129; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=NSr1A0atmg1mkurJvpGSEPCX7aflnoSVpmBJvxhgMy4=; b=PeX3SQhvbjmO1HIvjvADfgGlP1E0X0d2Q/6xTAaKENEZAgk+KMi+qyiP wPWT5NR1ZYtWoOLYU5MVpPpQb0A70yqEOPi6K6hbXWtArekV23gp6suja xyFgAoinAHTs3EQHUQw97VNZahoGBkfYsrXoCPVV2jcvvfHvS4qOjBauO qBV9v0I8Ok7z6M9pgJhh3e2S6sBFR2p42khFfQUwEZAtcFEgrGw7Sk8vi Z6N4v/l+EGdZjE0C2aaCTiq/OlANDyGXKe1gYSdk26pg5+tRUADsqvCnA 8QFE6DQahuNDC2UkXFdxmoDlHpGf1fJUST0YSi1o+O4l1JJMPanYzBeQG Q==; X-IronPort-AV: E=Sophos;i="5.63,483,1557187200"; d="scan'208";a="8726788" IronPort-PHdr: =?us-ascii?q?9a23=3AQTaTyRaPBp9sg4nQRgqQk8H/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZrsq9bnLW6fgltlLVR4KTs6sC17OM9f24EjVau96oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vMhm6twXcutUZjYd/NKo91A?= =?us-ascii?q?bCr2dVdehR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG?= =?us-ascii?q?87+MPktR/YTQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD?= =?us-ascii?q?+/4apnVAPkhSEaPDM/7WrZiNF/jLhDrRyhuRJx3pLUbo+WOvpwfKzdfM8VS2?= =?us-ascii?q?VOUctKSyxBG4G8Y5cTA+YdI+pVqZT2qVsUrRu5AAmhHO3jxD1Phn/y2a01ze?= =?us-ascii?q?IhHhrY0wM8HNICqGnfosjpO6cVTeC10KfExijEYvNN2Tf974zIchQ/rvGKRr?= =?us-ascii?q?1/b9beyUo0GgPbkFqQs43lPyiU1uQCtWiX9fZvVeWqi2M+rQx6vzuhxt80h4?= =?us-ascii?q?XUmo4Z0E3I+Cd3zYovONG1SEB2bcSrHZZUry2WKpd6Ttk/T2xqpCo20KAKtJ?= =?us-ascii?q?G4cSQQ1ZgqxAbTa/KZfIWL/h7uUeOcLDVki355Yr2yggu+/lS8xeD5VsS7zU?= =?us-ascii?q?hFriRAn9TIq38CygLc586aQfVn5EihwyyA1wXL5+FBJkA7iLTUJoY6wr41ip?= =?us-ascii?q?oTqUPDHjLqmEnujK+ZaEEk+u+w5un6frvovoKQOI9shA/xM6sihtKzDf4mMg?= =?us-ascii?q?cSWGib4/y82Kf58kLkWrlKkOc2krLfsJzAOcsboau5DxdU0oYl9Rm/Ey+r3M?= =?us-ascii?q?kEkXUdMV5IehyKg5L0N1zOLv30F/iyjlC0nDdu3f/GP7nhApvXLnjElbfsZa?= =?us-ascii?q?19605byAo3ydBQ+ZRUBaofL/3vWU/8r8LYAQEjMwy12ObnCdp91oUEVW2TBa?= =?us-ascii?q?+ZNbvesUWU6eI3P+mMeIgVtS7mK/gm4/7ujGQ5mUMGcKmq3JsXdGy4Eep8I0?= =?us-ascii?q?Wce3XshM0NHnsNvgo7VObqkkGNUSZPZ3auWKIx/iw0CIe8AofZWo+gm72B0z?= =?us-ascii?q?mnHp1YfGxGDUqMEXi7P7mDDr0XayaTOdNJkT0YSbW7ToYnkxqpsUWyn6FkKu?= =?us-ascii?q?vP5gUbtI7/2cJw7uuVnhY3o3g8RciY2nuGZ2B5gm1OQCU5lugrrUl00Fyr0K?= =?us-ascii?q?VkjbpfD9MFtN1TVQJvf77by+h3Ddr/UQGFNuyCT0q6CJ3yGjE2StY8xdUDaE?= =?us-ascii?q?VVBdi4jwvC0CzsCLgQwe/YTKco+77RiiCib/12zGzLgfEs?= X-IPAS-Result: =?us-ascii?q?A2EkAAAZ0Shd/zGZrQplHAEBAQQBAQcEAQGBUwcBAQsBh?= =?us-ascii?q?CwKjC6MVph6gXsJAQEBAQEBAQEBBwEvAQGEQAKCejQJDgEDAQEBBAEBAQEEA?= =?us-ascii?q?QEBAoYxgjoigm8BAQEBAzpLBAIBCBEEAQEBHgULMh0IAgQBEgiyfIo8gTQBi?= =?us-ascii?q?3WBQT6BEYMSPoQdhgkEjFGQDI4FAwYCghmUAyOCLIckjjeKCYMrl00CBAIEB?= =?us-ascii?q?QIVgVCCEXCDPIJ4jg1yjhiBMYEhAQE?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 12 Jul 2019 14:28:45 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Fri, 12 Jul 2019 14:28:45 -0400 From: "Hollenbeck, Scott" To: "sklist@kitterman.com" , "dmarc@ietf.org" Thread-Topic: [EXTERNAL] Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONvV+OBKRvuvD0WEdgN0ng60SqbHkCaA//+9P2A= Date: Fri, 12 Jul 2019 18:28:45 +0000 Message-ID: <22d90b3fc0114960b958aee4912ef779@verisign.com> References: <1783751.gHVjF1RMII@l5580> <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> <12139607.XScsT9yxuP@l5580> In-Reply-To: <12139607.XScsT9yxuP@l5580> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 12 Jul 2019 18:28:57 -0000 > -----Original Message----- > From: dmarc On Behalf Of Scott Kitterman > Sent: Friday, July 12, 2019 2:27 PM > To: dmarc@ietf.org > Subject: [EXTERNAL] Re: [dmarc-ietf] Mention ICANN/operational limitation= s > was: Re: Working Group Last Call: draft-ietf-dmarc-psd > > On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote: > > On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > As Secretary, there are three items that have not yet reached > > > > consensus that must be resolved during WGLC: > > > > > > > > 2. If explicit call outs to ICANN/limited operator capacity to > > > > implement are needed > > > > > > There has been feedback in favor of adding this and none against so f= ar. > > > > > > The specific proposal is: > > > > > > "Please note that today's operational and policy reality prevents > > > this experiment from being deployed globally. If the experiment > > > shows that PSD solves a real problem at a large scale, the results > > > could prove to be useful in the development of policies outside of > > > the IETF that would permit its ubiquitous deployment." > > > > > > Because RFCs are (approximately) forever, I'm concerned about words > > > like "today's" in protocol documents, even experimental ones. > > > > > > How about this instead: > > > > > > "As of the writing of this document operational and policy > > > constraints prevent this experiment from being deployed globally. If > > > the experiment shows that PSD solves a real problem and can be used > > > at a large scale, the results could prove to be useful in the > > > development of policies outside of the IETF that would permit broader > deployment". > > > > "[D]evelopment of policies outside of the IETF" strikes me as a little > > odd since IETF isn't setting policy *per se*, although substitute > > language that is just as succinct is escaping me at the moment. > > .... removal of constraints ... ??? > > "As of the writing of this document operational and policy constraints > prevent this experiment from being deployed globally. If the experiment > shows that PSD solves a real problem and can be used at a large scale, th= e > results could prove to be useful in the removal of constraints outside of= the > IETF that would permit broader deployment". > > Better? Either one works for me. Scott From nobody Fri Jul 12 11:33: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 CAF7E12083F for ; Fri, 12 Jul 2019 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=JApPu1VJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zhosjkTb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL0yU_QGfaB4 for ; Fri, 12 Jul 2019 11:33:09 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D97A12083C for ; Fri, 12 Jul 2019 11:32:55 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6BC8722027 for ; Fri, 12 Jul 2019 14:32:54 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Fri, 12 Jul 2019 14:32:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=B9Au9DWJe+Vox53d0apzDorPut0hjfV bmCHCZbQqf+s=; b=JApPu1VJ6nJfl3zCx0+FRuTnJGVSZFC9E3kttBY7nFzDKLl +SWeuZcSSUwV8466lhmKB92AKeA/DKrhPkSkxd8SqAAYdbUqww1lejdcZ5FQy9Dn daOmhNC2zXvrccWNZY44BdsTZig52Auj4IqmE1+Q8BGZD77kgu2lq8qQxzS4xdCs oLRCHfvDa5lVemEHyyhHezvejI1ZgVkl0hF9u9aDA20neB6TWQWAZTLysEyTEtLq /9qs4Dv/cpP03ioK+lJJxc9xwf9AAyeeZ4wZNmu688V/oXBN+OwhqSQjN6OVzIpv aYoN1w3Z723QZrVOx8dXs7uzUxb++oc4D4gxTCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=B9Au9D WJe+Vox53d0apzDorPut0hjfVbmCHCZbQqf+s=; b=zhosjkTbtMKt8IyWaSBYxY eaZk+spL33t72Cxtt/+5qFqH4aTVwFKqOVV1OcwkTOSO2Fcl6zoQcXXh6jJ0h9st FdRFPpYdTlWu41YAvbLiJhNhLVVbfYwiZ+3V3yRuboyxQ/oSpFFYcLkSDcLfCyV6 9jw2ebhXi3dzTrHDDzFpd9vU9xTS4tGUn4X/LrbyvfalcM4C2Y9m+v+urVlWgD/e RtVh2RJPgxqXSDmLyK/BH9HnKlGWgoE+/ht9Pu9RXxyCCfQndjq9OzjJah8UBzdK k153Vm3RmiQiOkHJxQIaa1Oj1Yf7+1HFdb2Kb1+UmhcHrFJCnHrkmcKeLE6mULBQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrhedtgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucffohhmrghinhepihgvthhfrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhm rghilhhfohhrtggvrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B1FFB1400A1; Fri, 12 Jul 2019 14:32:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <22f8a413-1cad-4d14-b57c-10de332f87ff@www.fastmail.com> In-Reply-To: <12139607.XScsT9yxuP@l5580> References: <1783751.gHVjF1RMII@l5580> <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> <12139607.XScsT9yxuP@l5580> Date: Fri, 12 Jul 2019 14:32:33 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=64352c6a74cc49c1abdbc445da9424c3 Archived-At: Subject: Re: [dmarc-ietf] =?utf-8?q?Mention_ICANN/operational_limitations_was?= =?utf-8?q?=3A_Re=3A_Working_Group_Last_Call=3A_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, 12 Jul 2019 18:33:12 -0000 --64352c6a74cc49c1abdbc445da9424c3 Content-Type: text/plain On Fri, Jul 12, 2019, at 2:27 PM, Scott Kitterman wrote: > On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote: > > On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > As Secretary, there are three items that have not yet reached consensus > > > > that must be resolved during WGLC: > > > > > > > > 2. If explicit call outs to ICANN/limited operator capacity to implement > > > > are needed > > > > > > There has been feedback in favor of adding this and none against so far. > > > > > > The specific proposal is: > > > > > > "Please note that today's operational and policy reality prevents this > > > experiment from being deployed globally. If the experiment shows that PSD > > > solves a real problem at a large scale, the results could prove to be > > > useful in the development of policies outside of the IETF that would > > > permit its ubiquitous deployment." > > > > > > Because RFCs are (approximately) forever, I'm concerned about words like > > > "today's" in protocol documents, even experimental ones. > > > > > > How about this instead: > > > > > > "As of the writing of this document operational and policy constraints > > > prevent this experiment from being deployed globally. If the experiment > > > shows that PSD solves a real problem and can be used at a large scale, > > > the results could prove to be useful in the development of policies > > > outside of the IETF that would permit broader deployment". > > > > "[D]evelopment of policies outside of the IETF" strikes me as a little odd > > since IETF isn't setting policy *per se*, although substitute language that > > is just as succinct is escaping me at the moment. > > .... removal of constraints ... ??? > > "As of the writing of this document operational and policy constraints prevent > this experiment from being deployed globally. If the experiment shows that PSD > solves a real problem and can be used at a large scale, the results could > prove to be useful in the removal of constraints outside of the IETF that > would permit broader deployment". > > Better? I think so. "[I]n removing constraints" would flow a little better, but yeah. Thanks, Stan > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --64352c6a74cc49c1abdbc445da9424c3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Jul 12, 2019, at 2:27 PM, Scott Kitterman wrote:
On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote:
> On Fri, Jul 12, 2019, at 1:41 = PM, Scott Kitterman wrote:
&g= t; > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
=
> > > As Secretary, the= re are three items that have not yet reached consensus
> > > that must be resolved during WG= LC:
> > > 
<= /div>
> > > 2. If explicit cal= l outs to ICANN/limited operator capacity to implement
> > > are needed
> > 
> > There has been feedback in favor of adding this and no= ne against so far.
> >&= nbsp;
> > The specific = proposal is:
> > <= br>
> > "Please note that t= oday's operational and policy reality prevents this
> > experiment from being deployed globally. = If the experiment shows that PSD
> > solves a real problem at a large scale, the results could = prove to be
> > useful = in the development of policies outside of the IETF that would
<= div style=3D"font-family:Arial;">> > permit its ubiquitous deploym= ent."
> > 
> > Because RFCs are (approxim= ately) forever, I'm concerned about words like
> > "today's" in protocol documents, even experi= mental ones.
> > <= br>
> > How about this inst= ead:
> > 
> > "As of the writing of this = document operational and policy constraints
> > prevent this experiment from being deployed glo= bally. If the experiment
>= > shows that PSD solves a real problem and can be used at a large sc= ale,
> > the results co= uld prove to be useful in the development of policies
> > outside of the IETF that would permit= broader deployment".
>&nb= sp;
> "[D]evelopment of po= licies outside of the IETF" strikes me as a little odd
> since IETF isn't setting policy *per se*,= although substitute language that
> is just as succinct is escaping me at the moment.

.... removal of constraints ... ???

"As of the writin= g of this document operational and policy constraints prevent 
<= /div>
this experiment from being deploy= ed globally. If the experiment shows that PSD 
solves a real problem and can be used at a large sc= ale, the results could 
= prove to be useful in the removal of constraints outside of the IETF tha= t 
would permit broader = deployment".

Better?

I think = so.  "[I]n removing constraints" would flow a little better, but ye= ah.


Thanks,
Stan


Scott K=


____________= ___________________________________
dmarc mailing list
dma= rc@ietf.org
https://www.ietf.= org/mailman/listinfo/dmarc

= --64352c6a74cc49c1abdbc445da9424c3-- From nobody Fri Jul 12 12:13:58 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 1ADD212097B for ; Fri, 12 Jul 2019 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=noMO6V9U; dkim=pass (1536-bit key) header.d=taugh.com header.b=cceTJQup Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqsFq75ZGCz2 for ; Fri, 12 Jul 2019 12:13:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D875C120977 for ; Fri, 12 Jul 2019 12:13:53 -0700 (PDT) Received: (qmail 56766 invoked from network); 12 Jul 2019 19:13:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ddbc.5d28dbed.k1907; i=johnl-iecc.com@submit.iecc.com; bh=Gy7qTTQ5cIT0rkW/n0l9gq0qqGQWqLmahnDabuo+jcQ=; b=noMO6V9UjeYj7Kok0F75comnXdeMv9hH5xMPCuy10t5tOO6rgVqdiMBaG8brYnuxeYk6VllP+54c4ttODeENyW2npczIxd3YEaOKA+OiJGqpDzB3Jj9s6m3J2i/KBgkyOniukwOiE1XutTIkUffU7aAOPvx64onnLdRfUUKlze+Rqdb20sMe+Dcfv89HzMt+AmHBfbdL7RsxN9pVd9MgKgMl+J8euRnfKwGgPwggpaRuFQYUCLUoIzUud1TXGXTD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ddbc.5d28dbed.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=Gy7qTTQ5cIT0rkW/n0l9gq0qqGQWqLmahnDabuo+jcQ=; b=cceTJQupjgJPM/ohteLBEK1/CfGdNfuMAdVjjuMXSiMU2TPRCBmiwkeFfHLrRs0dZXmqXRIpll/clRDvg/e5F0DrYfvVVeCQ0y3BfOzl4CUFVXxGAe5RQbxORxMt0+d0Xjqq86AMwaYECVuS8ZwTkNdXUjowwB0nI8eiztbtrWaNcZR6VtZf33jRg1vvAFxSiEDJTS6mCl2ZQlR7JNzVjEOjOZ07t5A77TKGEl8S5wUED7uOLJQmQPWLj+dhWdRA Received: from ary.local ([71.59.64.39]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 12 Jul 2019 19:13:49 -0000 Received: by ary.local (Postfix, from userid 501) id B10D94A0F89; Fri, 12 Jul 2019 15:13:48 -0400 (EDT) Date: 12 Jul 2019 15:13:48 -0400 Message-Id: <20190712191348.B10D94A0F89@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: seth@sethblank.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 19:13:56 -0000 In article you write: >-=-=-=-=-=- > >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote: > >> I am much more concerned with adding another tag that can only be used in >> a PSD-DMARC record. I would be much more open to make a "normative" change >> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC >> record, than to make this a special case for PSD-DMARC records. >> > >I am also concerned with adding any new policy-related tags, due to the >confusion they create that limits adoption. However, a very clear case for >an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov and >.mil have stated they also want this behavior. Others have shared similar >opinions privately. How do they feel about NODATA, which is not the same as NXDOMAIN? R's, John From nobody Fri Jul 12 12:34: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 CCA931200D7 for ; Fri, 12 Jul 2019 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 U7vVkiQKYx9u for ; Fri, 12 Jul 2019 12:34:00 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 333F71207D2 for ; Fri, 12 Jul 2019 12:34:00 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id a15so9874911wmj.5 for ; Fri, 12 Jul 2019 12:34:00 -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=+XloU0weJ83y651vQY2ewFoWIbMepy7ahB+JYJjSKMo=; b=qP1yz6sA3+mqolJcDYrKYdgsK7KRXY0pLYRbPbO1nHPtspXjB/mJaK9KQJAwlMu5Pq bcjT4cxKtluMA2QoPENxwXihQwVez3xlI573Xnl9UALez/UjFAFmxILvK2Vbvyr06Utz RwgsOKdmDWGgC9Gi/OvC+cyQLfAeLjofZE3X4oGi4oEzKZLeVWafK62sFtEA2SJT6tP6 1LomP63GpUgQgSgJG299WuFz6NPMODBm0HAc4+3CeyNyZPhfiko6vkA8i7X07njfDQTL E7ULXva+xJJiZsE2Y3MeA/LOi80U6j7I/jSFiuY4aIEA/WIXn/AQg1u9a8I4tnTou3V6 9XwA== 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=+XloU0weJ83y651vQY2ewFoWIbMepy7ahB+JYJjSKMo=; b=EEYIlymw5f20K28CnDc8MG3HHY17VSzk5gV57ldmFJpzazIDc7XV66uOpRefYDPYYq ockZhkau9qF+LaJSd1rK+oH3PpHyUSzCtlDGcfJnH9V7N178h1EQT4Ipokruq0aCaMvv uZasvY9U5Y0fFuU2mmGi66pOUcsi6479zDM8pCtIerNJVrHF0DtU4pO8wpA9If6vJF7V pHVSd1uzkBh3nHDzzPFZRfq4aFqrFWfYq1Zv24H0VcgWOIbQR2d8hoD2PvpOmrhuKq5m oCz5giK/jJymxjLmwa6nBZK2bOS+hnC/1MoYzUBOtVwYAIcDoNyhitUrKaJCcunHZIMd G6Vw== X-Gm-Message-State: APjAAAU4xuhx2QgDTp6zy8C9dRMUTIpzLRUK52zkGWR/l20x3r+svlqZ kaR3vGvhNl9BVpW8oSmCKDdootTBd3n8HFeIJB0= X-Google-Smtp-Source: APXvYqwdK9eCNL3kUrWl6uTp3wpvZE27d6A0a/a3lThDt5aMuhMkHGPCdg80XkLa1YCB1E6LlvxGkM2bgmVKfkq1l40= X-Received: by 2002:a1c:35c2:: with SMTP id c185mr10793137wma.58.1562960038605; Fri, 12 Jul 2019 12:33:58 -0700 (PDT) MIME-Version: 1.0 References: <1893230.9INSBCnb99@l5580> In-Reply-To: From: Dotzero Date: Fri, 12 Jul 2019 15:33:46 -0400 Message-ID: To: Seth Blank Cc: "Kurt Andersen (b)" , "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000e63a21058d80fd88" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 19:34:03 -0000 --000000000000e63a21058d80fd88 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 12, 2019 at 2:16 PM Seth Blank wrote: > On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) > wrote: > >> I am much more concerned with adding another tag that can only be used in >> a PSD-DMARC record. I would be much more open to make a "normative" change >> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC >> record, than to make this a special case for PSD-DMARC records. >> > > I am also concerned with adding any new policy-related tags, due to the > confusion they create that limits adoption. However, a very clear case for > an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov > and .mil have stated they also want this behavior. Others have shared > similar opinions privately. > > Since PSD is an experiment, I think this is a fine place to test an np= > tag. If it gets usage, then we have a clear argument for it being a normal > tag for DMARCbis. If not, then it can be jettisoned altogether. > > Adding this tag for PSD will simply need explanatory text in the > Experimental Considerations outlining this.. > > Seth > I agree with the concern expressed and the approach outline. I do have a concern as to the number of validators which will consider implementing this. Will it be added to OpenDMARC? Michael Hammer --000000000000e63a21058d80fd88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 12, 2019 at 2:16 PM Seth = Blank <seth@sethblank.com> = wrote:
On Fri, = Jul 12, 2019 at 10:55 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
I am much more concerned with adding another tag that can only be u= sed in a PSD-DMARC record. I would be much more open to make a "normat= ive" change to the DMARC tag list (RFC 7489 section 11.4) to define np= for any DMARC record, than to make this a special case for PSD-DMARC recor= ds.

I am also concerned w= ith adding any new policy-related tags, due to the confusion they create th= at limits adoption. However, a very clear case for an NXDOMAIN policy has b= een made by UK NCSC for .gov.uk= , and both .gov and .mil have stated they also want this behavior. Othe= rs have shared similar opinions privately.

Since P= SD is an experiment, I think this is a fine place to test an np=3D tag. If = it gets usage, then we have a clear argument for it being a normal tag for = DMARCbis. If not, then it can be jettisoned altogether.

Adding this tag for PSD will simply need explanatory text in the Expe= rimental Considerations outlining this..

Seth
<= /div>

I agree with the concern = expressed and the approach outline. I do have a concern as to the number of= validators which will consider implementing this. Will it be added to Open= DMARC?

Michael Hammer
--000000000000e63a21058d80fd88-- From nobody Fri Jul 12 13:34:56 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 3345312030D for ; Fri, 12 Jul 2019 13:34: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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Hxh37CUh; dkim=pass (2048-bit key) header.d=kitterman.com header.b=An9tGk4N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV_Azvq2lpGj for ; Fri, 12 Jul 2019 13:34:53 -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 3F37F1202E0 for ; Fri, 12 Jul 2019 13:34:53 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id E030AF8071F for ; Fri, 12 Jul 2019 16:34:21 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562963661; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=CDi5iy96yOEHfPTfL4fFUDEVhBc/27vt1f93uSI9Ff4=; b=Hxh37CUhIiGbgKIzRO/Qooj8GGmp4HJsLT7BWZkgBFEJvmc1nCOHyj/5 JnvNEuFLl0sWna1JxynSxKeWSqSSBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562963661; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=CDi5iy96yOEHfPTfL4fFUDEVhBc/27vt1f93uSI9Ff4=; b=An9tGk4NN9k+ncnI0WInfsA8/6yfF2PNzz5zasjWhkibNVFqtjJ3cYUU 4p6s/pF6M0k/KkL/V5jXWYc8pppbM7aLFYPk/raIC2sCEGALSYeJISmIgG BriVU0BfbQRTKTBCm6en8HdKMbacXP+LSa0bZtLnuG00/V4WafFdse+L9d ZhYnscJmx3REqACU1wxqS4kzYN3I6o0Qc4/HZEQqDyTFtmZMUtDUvBKqSH jCpDpLozZ1DEeexjG3FEyhrL27/7ovaC2M6Mda/jtn3GtmTnbz9l65nQTX KHzUebUXbNJuAurDKn5+OsEMBhGoRKEfc+asyxziemGBH6rDYXxKYg== 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 99389F80607 for ; Fri, 12 Jul 2019 16:34:21 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 16:34:20 -0400 Message-ID: <2902055.CzhLQO0xIX@l5580> In-Reply-To: <20190712191348.B10D94A0F89@ary.local> References: <20190712191348.B10D94A0F89@ary.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 12 Jul 2019 20:34:55 -0000 On Friday, July 12, 2019 3:13:48 PM EDT John Levine wrote: > In article you write: > >-=-=-=-=-=- > > > >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote: > >> I am much more concerned with adding another tag that can only be used in > >> a PSD-DMARC record. I would be much more open to make a "normative" > >> change > >> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > >> record, than to make this a special case for PSD-DMARC records. > > > >I am also concerned with adding any new policy-related tags, due to the > >confusion they create that limits adoption. However, a very clear case for > >an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov and > >.mil have stated they also want this behavior. Others have shared similar > >opinions privately. > > How do they feel about NODATA, which is not the same as NXDOMAIN? Although Seth said NXDOMAIN, he didn't really mean that DNS rcode. Here's the definition we have in the draft now: > 2.6. Non-existent Domains > > For DMARC [RFC7489] purposes, a non-existent domain is a domain name > that publishes none of A, AAAA, or MX records that the receiver is > willing to accept. This is a broader definition than that in > NXDOMAIN [RFC8020]. That's what I was expecting this new tag to apply to (and I think matches their expectation, but they can speak for themselves). Another way to say what's in 2.6 now might be: ... a domain for which there is a NODATA response for A, AAAA, and MX records. We could then drop the second sentence and swap the informative RFC 8020 reference for a normative reference to RFC 2308. The RFC 8020 updates to 2308 don't seem germane to this issue. I think that's equivalent to what's in 2.6 now, but states it more clearly in actionable DNS terminology. Comments? Scott K From nobody Fri Jul 12 15:35: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 5EBF7120112 for ; Fri, 12 Jul 2019 15:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSrpLG_F7hO3 for ; Fri, 12 Jul 2019 15:35:47 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 24B2E12009E for ; Fri, 12 Jul 2019 15:35:46 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j5so19576904ioj.8 for ; Fri, 12 Jul 2019 15:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=Fa396jQHfS5kTG9fbWkiJV7cBHwN6sqayh3VeLNL8Qw=; b=GHkpQoF/GObO/QUNyEYiEB4AakKg/ystLFQ/5/V0sPUf27MX/3IWxZAj0fYfx9c9JZ Vmm4GgThO7FnChRCzsAnU8iWjvqhVr1UsehGLmOjd3rrQxPS5gyQVwgw9P0vhb3cQ4Ba qhpE7KtrWv7hQ51BTf/aYdQEkQaPA6YWoSZNg= 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=Fa396jQHfS5kTG9fbWkiJV7cBHwN6sqayh3VeLNL8Qw=; b=T9j7dLtCeVhdp6qyH8DL64vrdx7jJ0oiC2/geEUHXMSexYEG3Ab8r3Emu5MMvVUV6N J6aumuRE4nObfsmyrLHS5w190CCg7NRcpbjoq9q+3GFgEGrdwQvPMCC8IAP6sq5CPS3U Vs1F0Wg65ntDJx713bVF6mluSAm77IN4lnuHjjfJsq2TzaagTNX8vnQaCSDSuzD6i3mQ xB5kFM5WrW0JEcSz+GfliX8GRy4LQc9t0IqCA1ycsCgMW/8cXwMmhiZnv6Q57okVTx4A 2tdeQb7bnVD+SfPKerpMeHMVoKxrPPVC3ifSQuWAzub94r8M9K5jTbdxMOidFqIuhti1 1+ng== X-Gm-Message-State: APjAAAUOPnXn8FdMc/4soix3u4u2czV70Y0MrGF/uEhWX5Zx1oN+vi9r z/DZHzrpgYfCRCfGYhyM7Hwpgvb+1Xh2DR+An0Wze/NGiBw= X-Google-Smtp-Source: APXvYqz3kHz8WuCBZmKsecRmz2QVbIwkPrZSQLR9IPQI6BctFgooL/XKusQQJd+xru+d2/MQj69YwtMxHJHRLBXC7Yo= X-Received: by 2002:a02:9004:: with SMTP id w4mr14501034jaf.111.1562970944904; Fri, 12 Jul 2019 15:35:44 -0700 (PDT) MIME-Version: 1.0 From: "Kurt Andersen (b)" Date: Fri, 12 Jul 2019 15:35:31 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f73989058d838717" Archived-At: Subject: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04 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, 12 Jul 2019 22:35:49 -0000 --000000000000f73989058d838717 Content-Type: text/plain; charset="UTF-8" Please note that I did not review Tim's comments in detail so some of the following points may have been covered by him previously. *Page 2 contains the following paragraph:* This memo provides a simple extension to DMARC [RFC7489 ] to allow operators of Public Suffix Domains (PSDs) to express policy for groups of subdomains, extends the DMARC [RFC7489 ] policy query functionality to detect and process such a policy, describes receiver feedback for such policies, and provides controls to mitigate potential privacy considerations associated with this extension. This extension does not really allow PSDs to express policy for "groups of subdomains" unless you take the perspective that "all or none" are groups. Perhaps altering the language to say "...to express policy that would apply to subdomains..."? *The very end of section 1 says:* DMARC [RFC7489 ], by design, does not support usage by PSOs. For PSDs that require use of DMARC [RFC7489 ], an extension of DMARC reporting and enforcement capability is needed for PSO to effectively manage and monitor implementation of PSD requirements. I still fail to see how this proposal is necessary (or, potentially even useful) for the PSO to perform enforcement of their policies. I'd recommend either deleting the entire paragraph or refocusing the second sentence around the brand protective role that this proposal brings for abuse of non-existent subdomains below the PSD. *Section 2.2* "PSD DMARC includes all public domains..." --> suggest "PSD DMARC applies to all public domains..." *Section 2.6* "...that a receiver is willing to accept" seems like it opens up a wide area if one applies considerations like DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this topic so I'll defer to that thread. *Section 3* should include the new "np" keyword as an update to the DMARC spec. *Section 3.5* This call-out makes it seem like information about non-existent domains is not desirable and useful for org-level DMARC. Can we modify the language to remove that implication? Perhaps "...is desirable and useful, just as it is for org-level DMARC operators." *Section 4* Neglects the privacy implications of broken "receiver is willing to accept" conditions that may lead to additional leakage. Also in the third bullet point, "it's feedback" should not have an apostrophe. --Kurt --000000000000f73989058d838717 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please note that I did not review Tim's comments = in detail so some of the following points may have been covered by him prev= iously.

Page 2 contains the following paragra= ph:
   This memo provides a simple ext=
ension to DMARC [RFC7489] to allow
   operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489] policy query
   functionality to detect and process such a policy, describes receiver
   feedback for such policies, and provides controls to mitigate
   potential privacy considerations associated with this extension.

This extension does not really allow PSDs=
 to express policy for "groups of subdomains" unless you take the=
 perspective that "all or none" are groups. Perhaps altering the =
language to say "...to express policy that would apply to subdomains..=
."?
The very end of section=
 1 says:
   DMARC [RFC7489], by de=
sign, does not support usage by PSOs.  For PSDs
   that require use of DMARC [RFC7489], an extension of DMARC reporting
   and enforcement capability is needed for PSO to effectively manage
   and monitor implementation of PSD requirements.

I still fail to see how this proposal is =
necessary (or, potentially even useful) for the PSO to perform enforcement =
of their policies. I'd recommend either deleting the entire paragraph o=
r refocusing the second sentence around the brand protective role that this=
 proposal brings for abuse of non-existent subdomains below the PSD.=

Section 2.2 "PSD DMARC includ=
es all public domains..." --> suggest "PSD DMARC applies to al=
l public domains..."
Sectio=
n 2.6 "...that a receiver is willing to accept" seems like it=
 opens up a wide area if one applies considerations like DNSSEC/DANE/MTA-ST=
S/etc. There is a separate conversation on this topic so I'll defer to =
that thread.
Section 3 shoul=
d include the new "np" keyword as an update to the DMARC spec.
Section 3.5 This call-out make=
s it seem like information about non-existent domains is not desirable and =
useful for org-level DMARC. Can we modify the language to remove that impli=
cation? Perhaps "...is desirable and useful, just as it is for org-lev=
el DMARC operators."
Sectio=
n 4 Neglects the privacy implications of broken "receiver is willi=
ng to accept" conditions that may lead to additional leakage. Also in =
the third bullet point, "it's feedback" should not have an ap=
ostrophe.
--Kurt



--000000000000f73989058d838717-- From nobody Fri Jul 12 19:06: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 A92A1120074 for ; Fri, 12 Jul 2019 19:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=VF2DK/Gn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=R01KtZ9X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NU5sN1oSmlm for ; Fri, 12 Jul 2019 19:06:10 -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 355AB12009C for ; Fri, 12 Jul 2019 19:06:10 -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 EBF89F8071F for ; Fri, 12 Jul 2019 22:05: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=1562983538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kr3Q4FTtRwSDxdtZqLLLxkj6z7B+IfrtLXJ9P1789fI=; b=VF2DK/Gnrf8772zkWrQPKlTh83ZodzMuN+D90YkIH+ngdmSaviTjYCIh eLsfdiWoS4ykmVNim6PrB0eXO3TeDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562983538; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=kr3Q4FTtRwSDxdtZqLLLxkj6z7B+IfrtLXJ9P1789fI=; b=R01KtZ9XtAsWGM4YVoIR3c8C/O6i606lXB2gMM+CzZKc9Q6CmYab4/Lr NiXvWOVClDFc5T6OkFlUakwzLDJcK4CD52z6ebh5OZseQMzdZ0g6wRoVVJ SWmP7LkWw6rlsN8w+u4PFMviGvVTcJ0qr3D9v8AM/RMidtu+6P0pshQbRS kh/pcrfc0xwojsLLts9h9EqU7Gq3V5QQ6LWOZjzC+WAKm562gtD0o34mp+ +qN3SsiSGCeI3cH22A+mABp4a/7BObl8E9tYuZU6b/71gMzNnGJ4qEBsaG 96BJEg51nWbMFTRUdwurYc5+UZBPtw03op0I8DD4MwM+I+M3dFz3Vg== 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 B9C03F80607 for ; Fri, 12 Jul 2019 22:05:38 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 22:05:38 -0400 Message-ID: <3567849.MR6BRsP4iS@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04 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, 13 Jul 2019 02:06:14 -0000 On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote: > Please note that I did not review Tim's comments in detail so some of the > following points may have been covered by him previously. Thanks. I'd forgotten about that set of comments. I think they mostly relate to the understandability of the front matter, so I'll discuss that further in that thread. > *Page 2 contains the following paragraph:* > > This memo provides a simple extension to DMARC [RFC7489 > ] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489 > ] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > This extension does not really allow PSDs to express policy for > "groups of subdomains" unless you take the perspective that "all or > none" are groups. Perhaps altering the language to say "...to express > policy that would apply to subdomains..."? I think Tim's suggestions address this concern. > *The very end of section 1 says:* > > DMARC [RFC7489 ], by design, > does not support usage by PSOs. For PSDs > that require use of DMARC [RFC7489 > ], an extension of DMARC > reporting > and enforcement capability is needed for PSO to effectively manage > and monitor implementation of PSD requirements. > > I still fail to see how this proposal is necessary (or, potentially > even useful) for the PSO to perform enforcement of their policies. I'd > recommend either deleting the entire paragraph or refocusing the > second sentence around the brand protective role that this proposal > brings for abuse of non-existent subdomains below the PSD. I think it can be deleted. > *Section 2.2* "PSD DMARC includes all public domains..." --> suggest > "PSD DMARC applies to all public domains..." Seems fine. > *Section 2.6* "...that a receiver is willing to accept" seems like it > opens up a wide area if one applies considerations like > DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this > topic so I'll defer to that thread. > > *Section 3* should include the new "np" keyword as an update to the DMARC > spec. > > *Section 3.5* This call-out makes it seem like information about > non-existent domains is not desirable and useful for org-level DMARC. > Can we modify the language to remove that implication? Perhaps "...is > desirable and useful, just as it is for org-level DMARC operators." There was a desire to say something specific about wanting data on non-existent domains. I agree with your point. What would you suggest saying to make the point that it's definitely desirable at the PSD level without implying it's not otherwise? > *Section 4* Neglects the privacy implications of broken "receiver is > willing to accept" conditions that may lead to additional leakage. > Also in the third bullet point, "it's feedback" should not have an > apostrophe. Typo is fixed in git. Isn't it always true that if local policy prohibits accepting certain DNS data, things will work out differently? Does this need to be called out? Scott K From nobody Fri Jul 12 19:08:23 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 D711E120073 for ; Fri, 12 Jul 2019 19:08:21 -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=And1LjJx; dkim=pass (2048-bit key) header.d=kitterman.com header.b=iz28Vf7O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1VVi63fUc_K for ; Fri, 12 Jul 2019 19:08:20 -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 1314112000E for ; Fri, 12 Jul 2019 19:08:20 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 2FA82F8071F for ; Fri, 12 Jul 2019 22:08:19 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1562983699; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0vvcirSSoRQS7bu/lZAIwmtQxcxneRHJDOUZx1twDyo=; b=And1LjJxeRMXPw34dD022BbCPBrMBmGKVxZJkaEGDRzOo3bHWx1x0KnC lvbuwwf8w1qfzp0KK5fxlJZgEKN5Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562983699; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0vvcirSSoRQS7bu/lZAIwmtQxcxneRHJDOUZx1twDyo=; b=iz28Vf7OgmwIc3t5zYx9Rq0e9S70EVXgDqPrlqqQPbHGcuRgN+fjtwtP qhNnjrv+sVRT8tKOMS1AP9TAOw00Qfg2kKUiEwTdhe2DC+5ibfNNFsHuBw XB/HPiKeanXgYz1VW44tAScZAyWItTSnlkbQCKW6tmrqqppGI44U2KbBcK CH8vMUfx3AvavrJYIRm8dkwMYqFdBdyx1SLjpC8+Pv1MaQ7oosLHcW8yKd EroNqjNdhbUGvRFjNb/juHtvYHNdlFUKHY/S55cdbjBkyRmTu4Sj+NvYU9 laWlZzCCpEwK83OaEdCg7Eok7jQM0mpSoHN9OWHpiJ/yl6O2jk/N9A== 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 F2D8CF80607 for ; Fri, 12 Jul 2019 22:08:18 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Jul 2019 22:08:18 -0400 Message-ID: <2690876.0nFNBlPXtE@l5580> In-Reply-To: <1890995.riJRFoXRoW@l5580> References: <1890995.riJRFoXRoW@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Introduction context was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 02:08:22 -0000 On Friday, July 12, 2019 1:26:40 PM EDT Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached consensus > > that must be resolved during WGLC: > > > > 1. What further context is needed in the introduction > > The only comment on this so far during WGLC is that it is clear as is. > > As the document author, this is one I have a hard time assessing. It's > clear to me, but I know what I meant when I wrote it. If anyone is still > concerned about this issue, I would strong encourage you to provide > suggested text. > > I think the WG should be pretty open to accepting such changes (as long as > they are technically accurate). Even if it makes the document a bit longer, > I think clarity is worth it. > > Standing by for inputs/feedback. I think Tim's suggestions are a good response to this issue: https://mailarchive.ietf.org/arch/msg/dmarc/e7aDFcxDdJPI2Sj4jMqGLmDhmKc Unless someone else has other opinions (I know Kurt brought some things up that this doesn't cover, but we should address those separately), I think these changes should be applied. Scott K From nobody Fri Jul 12 21:34:16 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 0B7AD12004D for ; Fri, 12 Jul 2019 21:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Lf/U7qkG; dkim=pass (1536-bit key) header.d=taugh.com header.b=pPV9EtwF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7J-mZfhn1HG for ; Fri, 12 Jul 2019 21:34:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A51B120019 for ; Fri, 12 Jul 2019 21:34:13 -0700 (PDT) Received: (qmail 62979 invoked from network); 13 Jul 2019 04:34:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f601.5d295f42.k1907; i=johnl-iecc.com@submit.iecc.com; bh=j8keLxaYqvVT9r/LSIfnBTkug7b3onGYIxw3o/FjEgM=; b=Lf/U7qkGmZjkyTqusq528xLqvDxjRlj4KYBeY3NlpNSrlmlWG7oknfQzTEYxFnGUGrVb/FNIKOqoMF0sfytSdsm1/NVeHW93bRQFhbTAzY/bRhBExJY96r8sNvli+8M2q5baTbkSSG0MnKo8kO1LUVQOeRDwlYkHkpgslpZG5yq4Q9yyNqCzROWx0ZPk+XivVWeX1FMg3EgMpR1cQ6AJEsGolk4nN5K/4qM1wIvjf/hccr6n3WRqkJb0jHGPQirw DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f601.5d295f42.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=j8keLxaYqvVT9r/LSIfnBTkug7b3onGYIxw3o/FjEgM=; b=pPV9EtwFNEpKhEdLEdykbOkh0dKb3PVxdYNRl6ylb9hJxVd1OWNnqbSjM21INeXdrBKG1PH0249azl26gq8k+sKbM4xnNaElts8xevLeiryN0UrFLZ11osk9GTJyTV1v0DD2YGi2Ura7mep/ieF8e0uKTWeFZoQTsE9kF1M2t/wd6+r6uqRqHZwT1TrZz5lrnT3413qFA6u7l3zf/NsjGTPwhCWfXef91yD4icZ3hvF0dM+SmfbATCD8W27VActw Received: from ary.local ([73.33.141.87]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 13 Jul 2019 04:34:10 -0000 Received: by ary.local (Postfix, from userid 501) id A5EB64A61C0; Sat, 13 Jul 2019 00:34:09 -0400 (EDT) Date: 13 Jul 2019 00:34:09 -0400 Message-Id: <20190713043409.A5EB64A61C0@ary.local> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2902055.CzhLQO0xIX@l5580> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 04:34:15 -0000 In article <2902055.CzhLQO0xIX@l5580> you write: >Here's the definition we have in the draft now: > >> 2.6. Non-existent Domains >> >> For DMARC [RFC7489] purposes, a non-existent domain is a domain name >> that publishes none of A, AAAA, or MX records that the receiver is >> willing to accept. This is a broader definition than that in >> NXDOMAIN [RFC8020]. > >That's what I was expecting this new tag to apply to (and I think matches >their expectation, but they can speak for themselves). That's OK. >Another way to say what's in 2.6 now might be: > >... a domain for which there is a NODATA response for A, AAAA, and MX records. Not so OK -- if there's no records at all at or below a name you really will get NXDOMAIN. R's, John From nobody Fri Jul 12 23:04:42 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 00E9D120024 for ; Fri, 12 Jul 2019 23:04: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=5BC2DRuY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=RkvN9XS8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogtKG_9-DoJE for ; Fri, 12 Jul 2019 23:04:37 -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 0DF8D120019 for ; Fri, 12 Jul 2019 23:04:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 5FEC0F8071F for ; Sat, 13 Jul 2019 02:04: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=1562997845; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=n9AFmcqj8B85fjXkxO1QX/oRRSoqS765uU+P2WEEHIs=; b=5BC2DRuYeag9UIobsCbxmR306QEkJy+2hOLGqMq6Ls/9hT845G45BUCu 8F8M0nAI56ADzQ2rK84Y6RGL7raeDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1562997845; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=n9AFmcqj8B85fjXkxO1QX/oRRSoqS765uU+P2WEEHIs=; b=RkvN9XS81f/8qHEJchxQ5nPrdUsSqEMIiLFeLZpB3vSJhkJ57aArDNZA omiZrhUl5Xq4ACDBQr3POicXD3H4Hs+nYos43xIDqoWAqYSvlraADLotBt iZ2KfIKFofgDYCPFfXg6cJ6Go1nuXI/kGZMmqrkCBtJlr3Npkmr49EEgCj PepVmpN47r66CdE2RXG0D3766Q8JZGC2Y9y/DvN+FjDTVO4p1oP1AxZI9/ VCBgi2AMXLsdbvuAa6hL0V7J/TV/7ncCactELMl7Rry/892m327lv5Q2pQ L2tWx0pE8DdnTGQD+Dge6Hgq7hXn9/OP+IIHIuXJbX53MQ4JyZgbGA== 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 20CB1F8021A for ; Sat, 13 Jul 2019 02:04:05 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Jul 2019 02:04:04 -0400 Message-ID: <3017917.gKNyNSpcLf@l5580> In-Reply-To: <20190713043409.A5EB64A61C0@ary.local> References: <20190713043409.A5EB64A61C0@ary.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 06:04:41 -0000 On Saturday, July 13, 2019 12:34:09 AM EDT John Levine wrote: > In article <2902055.CzhLQO0xIX@l5580> you write: > >Here's the definition we have in the draft now: > >> 2.6. Non-existent Domains > >> > >> For DMARC [RFC7489] purposes, a non-existent domain is a domain name > >> that publishes none of A, AAAA, or MX records that the receiver is > >> willing to accept. This is a broader definition than that in > >> NXDOMAIN [RFC8020]. > > > >That's what I was expecting this new tag to apply to (and I think matches > >their expectation, but they can speak for themselves). > > That's OK. > > >Another way to say what's in 2.6 now might be: > > > >... a domain for which there is a NODATA response for A, AAAA, and MX > >records. > Not so OK -- if there's no records at all at or below a name you really will > get NXDOMAIN. Good point. Thanks. I'll leave it as is. Scott K From nobody Sat Jul 13 10:21:53 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 206D41200E6 for ; Sat, 13 Jul 2019 10:21:52 -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 dTn96ZUeexDr for ; Sat, 13 Jul 2019 10:21:49 -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 2C41A120115 for ; Sat, 13 Jul 2019 10:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563038502; bh=motTds9Ih2iwl7XOOMyVRHDz94IEhn2IGKMGwmP8KKA=; l=850; h=To:References:From:Date:In-Reply-To; b=AgIGNBuX+qitMBod9bYlYZvnc49cRGf5K8PujLL2fNcyeFkPqYF4F1G4AOATpyQBj NUhinYSobFkIbRlxTRI+r0nm+TtK4AHjkekajW/jeuNIgKCPP2GPUoo81tP+h/QviC dbEzHsep3qSVC3NQ5jtfys7MQESPbPCANLkdrEkk/cLO8GDfMtO9/85oSaCHS Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.9.203]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005D2A1326.00003CD8; Sat, 13 Jul 2019 19:21:40 +0200 To: dmarc@ietf.org References: <1783751.gHVjF1RMII@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <0c52a75d-1a67-d095-f5f6-e74a8a4ff958@tana.it> Date: Sat, 13 Jul 2019 19:21:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1783751.gHVjF1RMII@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 17:21:52 -0000 On Fri 12/Jul/2019 19:41:17 +0200 Scott Kitterman wrote: > How about this instead: > > "As of the writing of this document operational and policy constraints prevent > this experiment from being deployed globally. If the experiment shows that > PSD solves a real problem and can be used at a large scale, the results could > prove to be useful in the development of policies outside of the IETF that > would permit broader deployment". I'm not familiar with operating a TLD. The above text seems to imply that TLD operators cannot just edit their zone files as they like. In that case, couldn't that statement be more explicit? In particular, what does allow the experiment to be deployed locally? > Also, since this is about ephemera and not protocol, I think it should go in > Appendix A. Makes sense. Best Ale -- From nobody Sat Jul 13 10:33:23 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 DD890120115 for ; Sat, 13 Jul 2019 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[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 MslCVaQiOY5G for ; Sat, 13 Jul 2019 10:33:20 -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 9ADA7120108 for ; Sat, 13 Jul 2019 10:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563038535; bh=TXGRl2U76eYm4Uph42q/+ugvgGc4YzbyxKKJt1DHgO0=; l=1305; h=To:References:From:Date:In-Reply-To; b=BkG7Zuw6NiW+8M0ivnd+Dsi/y1+XoUGX8r14qYJLKXCKK/HKCdqOoKPiklWoHq/77 aiov0XnXV9lcDrvh64tCWsddDdGEfgL2J0JD0fhLPXX3hnkOAMPu6MQUvmTKhY626D sJU0R3YBmQGRnpeOihdQfCO8J9EdC9By3MC6DTgAwhpW2AIVeEeYIrTlFlBYp Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.9.203]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005D2A1347.00003D0F; Sat, 13 Jul 2019 19:22:15 +0200 To: dmarc@ietf.org References: <54eac0ab-985e-69be-5985-8a53c51c7580@tana.it> <1851683.DtEN5jD5Wj@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: Date: Sat, 13 Jul 2019 19:22:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1851683.DtEN5jD5Wj@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 17:33:22 -0000 On Fri 12/Jul/2019 19:30:35 +0200 Scott Kitterman wrote: > On Thursday, July 11, 2019 6:07:50 AM EDT Alessandro Vesely wrote: >>> 2. If explicit call outs to ICANN/limited operator capacity to >>> implement are needed >> >> Appendix B.1 lacks a criterion to establish enlisting. Couldn't we >> require an explicit statement about seizing DMARC reports in, say, the >> delegation report? Alternatively, that policy can be stated in a >> well-known place under the delegation services URL, so that >> registrants know what they do. > > It's in the appendix because we don't have a clear path forward. This is part > of the experiment. We need to be careful though since different PSDs operate > under different authorities and controls, so there is a point beyond which it's > not the IETF that decides. I should have written more clearly the two issues. One is the criterion. I hypothesized that all what is needed to gran enlistment to a PSO is that its policy to seize DMARC at PSD level be published, so that registrant can learn about is before registering. Is that correct? I mean does a public statement suffice? The second issue is how to publish. In case the answer to the 1st question is yes, would https://PSO.tld/.well-known/dmarc-psd/policy do? Best Ale -- From nobody Sat Jul 13 11:42:40 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 8F17412017E for ; Sat, 13 Jul 2019 11:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=76ECPtom; dkim=pass (2048-bit key) header.d=kitterman.com header.b=kKaQhhgS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwOslPkUueJu for ; Sat, 13 Jul 2019 11:42:36 -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 4CEAC120157 for ; Sat, 13 Jul 2019 11:42:36 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 2EA88F80689; Sat, 13 Jul 2019 14:42: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=1563043325; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=CvqUBauFOBgLCxz1+DsWtNfyz+7s82FN8yuIivY7/ak=; b=76ECPtomW3G29eY+o2pH+yDzuedpIE81usglJYTDbJF4g5eaAip/LERu 84UuWaQDkDVcQD/3ysSt767hByanAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563043325; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=CvqUBauFOBgLCxz1+DsWtNfyz+7s82FN8yuIivY7/ak=; b=kKaQhhgSslE8BwAv8cep+tA6doSwWCGrnmpIjlvZ7KDxfpQgW+u5fAvl uAMhY/TN5/dM1UzvUxvRmtwrV6jLPOtEem8Vuzug+Mr7mKZZG87ZUIvh6f tETMnw4xYWHORbcK/wgKLb9jot3nVTr5ceUfVsBKWCP11gJymxJ3Go4We9 EeOx1AGWR6qAFtfXGneMaBBWUnzvqe7TuZSEiwRyhrhJ/8vmAYl6j6SQ99 /TtJhattYVkVJCmHqyoA4qFX3RiS7G9zcpcgFAnk1wmvpqx8kIcaboJGIt 85xc63UVeobAkTZdIylMWVVTvE/el66km00x6w5HQUu85tNo2HXTkw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id D6090F80607; Sat, 13 Jul 2019 14:42:04 -0400 (EDT) Date: Sat, 13 Jul 2019 18:42:03 +0000 In-Reply-To: <0c52a75d-1a67-d095-f5f6-e74a8a4ff958@tana.it> References: <1783751.gHVjF1RMII@l5580> <0c52a75d-1a67-d095-f5f6-e74a8a4ff958@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 18:42:38 -0000 On July 13, 2019 5:21:31 PM UTC, Alessandro Vesely wrot= e: >On Fri 12/Jul/2019 19:41:17 +0200 Scott Kitterman wrote: >> How about this instead: >>=20 >> "As of the writing of this document operational and policy >constraints prevent=20 >> this experiment from being deployed globally=2E If the experiment >shows that=20 >> PSD solves a real problem and can be used at a large scale, the >results could=20 >> prove to be useful in the development of policies outside of the IETF >that=20 >> would permit broader deployment"=2E > > >I'm not familiar with operating a TLD=2E The above text seems to imply >that TLD operators cannot just edit their zone files as they like=2E In >that case, couldn't that statement be more explicit? In particular, >what does allow the experiment to be deployed locally? Some can, some can't=2E It's complicated and it's nothing to do with IETF= protocol, so I don't think it's on topic to go into any details=2E Scott K From nobody Sat Jul 13 12:06:06 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 723B412017E for ; Sat, 13 Jul 2019 12:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=68FxRLTp; dkim=pass (2048-bit key) header.d=kitterman.com header.b=kZknTAaZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzICxb4dKNC0 for ; Sat, 13 Jul 2019 12:06:02 -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 6B23A120157 for ; Sat, 13 Jul 2019 12:06:02 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 5D875F80689 for ; Sat, 13 Jul 2019 15:06:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563044761; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=GBW+yGjcZd6tKqQVKSrdT4afqyr2hFybKo1oc1ESFHI=; b=68FxRLTpglE8QzYH3h9ZLDc+sLamEVSb1NcGRJuh1BbFH2lcjoNlceMe VX6U1ei4fi/NKy23USz25im/tUCoBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563044761; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=GBW+yGjcZd6tKqQVKSrdT4afqyr2hFybKo1oc1ESFHI=; b=kZknTAaZxiAdwJhiatIqlPgUqUTeRH0p20J/Lo5zORI4Cn8SuN+1HhR2 D89N/DmMpZgAaTEm9BzqLo7zI6icQQbxhyHaZ7ZkaWKBv2M3O+ENiSNsKF Z4aGZE/lKBzMCRU8nb0E9tjESa8aqIm+695BhN51L2MzYMIxrhuf3sKdy0 wooFROY79mVzfeXQz6H5vg56wUwY0pKkN8w+tbjrxpSPTXMFKth1DpIlv6 Dml2MBPVwVyUlw3P8tYmIRmBE4FIWDTA84cAZ+kyDcvtufE027VGA0uVVo RIaMjV6gSERYxh73kb3EQGxJc8wfoBn15RERQwDArMJzZjU1EcVDDw== 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 2D096F80607 for ; Sat, 13 Jul 2019 15:06:01 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Jul 2019 15:06:00 -0400 Message-ID: <1834844.gVztEOuzS9@l5580> In-Reply-To: References: <1851683.DtEN5jD5Wj@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 19:06:04 -0000 On Saturday, July 13, 2019 1:22:15 PM EDT Alessandro Vesely wrote: > On Fri 12/Jul/2019 19:30:35 +0200 Scott Kitterman wrote: > > On Thursday, July 11, 2019 6:07:50 AM EDT Alessandro Vesely wrote: > >>> 2. If explicit call outs to ICANN/limited operator capacity to > >>> implement are needed > >> > >> Appendix B.1 lacks a criterion to establish enlisting. Couldn't we > >> require an explicit statement about seizing DMARC reports in, say, the > >> delegation report? Alternatively, that policy can be stated in a > >> well-known place under the delegation services URL, so that > >> registrants know what they do. > > > > It's in the appendix because we don't have a clear path forward. This is > > part of the experiment. We need to be careful though since different > > PSDs operate under different authorities and controls, so there is a > > point beyond which it's not the IETF that decides. > > I should have written more clearly the two issues. One is the > criterion. I hypothesized that all what is needed to gran enlistment > to a PSO is that its policy to seize DMARC at PSD level be published, > so that registrant can learn about is before registering. Is that > correct? I mean does a public statement suffice? > > > The second issue is how to publish. In case the answer to the 1st > question is yes, would https://PSO.tld/.well-known/dmarc-psd/policy do? I don't think we want a novel policy record location for PSD. We did discuss this and concluded _dmarc.PSD is appropriate to remain aligned to DMARC. In my view the challenge around which PSDs receivers should check for a PSD DMARC record needs to be external to the PSD (i.e. not a self-assertion). Some options are presented in Appendix A. If, as a result of the experiment, it's concluded that self-assertion is acceptable, then all that's needed is to publish the record. I don't think we need a second place to look up to tell receivers to do the record lookup. Scott K From nobody Sat Jul 13 12:35:27 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 87F381200F3 for ; Sat, 13 Jul 2019 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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=vJ3cofgm; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bvAKTkM+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znFUAJhX1qcv for ; Sat, 13 Jul 2019 12:35:24 -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 CA42512003E for ; Sat, 13 Jul 2019 12:35:23 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 9C76FF80689 for ; Sat, 13 Jul 2019 15:34:52 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563046492; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=3Dmv1rKWmXd8bl/a+NshL0B1tRsRY3WRR3wZeRIZaJc=; b=vJ3cofgmapWySZnlYvO3ZftFM7gsVcmJVVkAEvZ8770fWUU0QeaV9/6V XT1hErVvKqkGF8rIq5XZmBQdCVTcDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563046492; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=3Dmv1rKWmXd8bl/a+NshL0B1tRsRY3WRR3wZeRIZaJc=; b=bvAKTkM+iuOfMyy6Z5umfAVA1V51egzNbupIF2LsZZJlch83CiRgLti6 BqpsMpOs1CCaZhgcTwb0hNwkFw91rQzLTfDJflSqJjFohJTnlFhGQNqIVX EnvNmnaFnsJ3/8IZOY5d2FHHGBWkKVfRe0zQtOPNexfAb9zzVgD1QoUZ4y /WeUYssCqjkr8o5s73XEHNLVUSKqEvK1T4EZnhIMje4wmyVgY2K+tyGIZ7 4owcQ9VJV1vN72AnnepF8GvG2LFWK+biJldKQRYchUuCimEunCQCJoSiCP CW1Ud9ZMED79iKozGibpFTyt5m/H6XCHBimeys6Wivz5IDiU7bbB+Q== Received: from l5580.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 44D5AF80607 for ; Sat, 13 Jul 2019 15:34:52 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 13 Jul 2019 15:34:51 -0400 Message-ID: <4789054.Ip9ilXyiH0@l5580> In-Reply-To: <1958020.28HeBAo97T@l5580> References: <1958020.28HeBAo97T@l5580> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2182572.SKLRh5PmXv" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 19:35:26 -0000 This is a multi-part message in MIME format. --nextPart2182572.SKLRh5PmXv Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote: > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > > > wrote: > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs > > > > > > The limited feedback during WGLC has been favorable to this. > > > > > > This will require a rather larger change to the document than the other > > > issues, but they are manageable and I believe I have most of the > > > relevant > > > text > > > from earlier revisions. > > > > > > I think we should include this. > > > > I am much more concerned with adding another tag that can only be used in > > a > > PSD-DMARC record. I would be much more open to make a "normative" change > > to > > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > > record, than to make this a special case for PSD-DMARC records. > > I agree. My intent is to add the tag to be used experimentally for any > DMARC record. Part of the experiment is to see if it's useful beyond PSD. Attached is my proposed text to add the np tag. Based on the discussion to date, I assume I'll be asked to add something like this after last call is complete, so please let me know how to make it better. Scott K --nextPart2182572.SKLRh5PmXv Content-Disposition: attachment; filename="draft-ietf-dmarc-psd-05-from-4.diff.html" Content-Transfer-Encoding: base64 Content-Type: application/xhtml+xml; name="draft-ietf-dmarc-psd-05-from-4.diff.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQxOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogTGludXggbDU1ODAgNC4xOS4wLTUtYW1kNjQgIzEgU01Q IERlYmlhbiA0LjE5LjM3LTMgKDIwMTktMDUtMTUpIHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0t IFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjIuMSwgQVBJOiAyLjAgKEdOVSBN UEZSIDQuMC4yLCBHTlUgTVAgNi4xLjIpIC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9k aWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjcgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNy L2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjIgLS0+IAo8aHRtbD4gCjxoZWFkPiAK ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5 cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1kbWFy Yy1wc2QtMDQudHh0IC0gZHJhZnQtaWV0Zi1kbWFyYy1wc2QtMDUudHh0PC90aXRsZT4gCiAgPHN0 eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2lu LXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3Bh Y2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9u dC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAg IC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFt aWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0g CiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5s aW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAu N2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sg YmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5y YmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICA8L3N0eWxlPiAKPC9o ZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPiAKICA8dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+Jm5ic3A7ZHJh ZnQtaWV0Zi1kbWFyYy1wc2QtMDQudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwO2Ry YWZ0LWlldGYtZG1hcmMtcHNkLTA1LnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRlbmRlZCBzdGF0dXM6IEV4cGVyaW1l bnRhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5N YXkgMjcsPC9zcGFuPiAyMDE5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkludGVu ZGVkIHN0YXR1czogRXhwZXJpbWVudGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNw YW4gY2xhc3M9Imluc2VydCI+SnVseSAxMyw8L3NwYW4+IDIwMTk8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFz cz0iZGVsZXRlIj5Ob3ZlbWJlciAyOCwgMjAxOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSAxNCwgMjAy MDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkRNQVJDIChEb21haW4tYmFzZWQg TWVzc2FnZSBBdXRoZW50aWNhdGlvbiwgUmVwb3J0aW5nLCBhbmQgQ29uZm9ybWFuY2UpPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+RE1BUkMgKERvbWFpbi1iYXNlZCBNZXNzYWdlIEF1 dGhlbnRpY2F0aW9uLCBSZXBvcnRpbmcsIGFuZCBDb25mb3JtYW5jZSk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgRXh0 ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMgU3VmZml4IERvbWFpbnMpPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgRXh0ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMg U3VmZml4IERvbWFpbnMpPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZG1hcmMtcHNkLTA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRtYXJjLXBzZC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERNQVJDIChEb21haW4tYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiwg UmVwb3J0aW5nLCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBETUFSQyAo RG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbmZv cm1hbmNlKSBpcyBhIHNjYWxhYmxlIG1lY2hhbmlzbSBieSB3aGljaCBhIG1haWwtb3JpZ2luYXRp bmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb25mb3JtYW5jZSkgaXMgYSBz Y2FsYWJsZSBtZWNoYW5pc20gYnkgd2hpY2ggYSBtYWlsLW9yaWdpbmF0aW5nPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9yZ2FuaXphdGlv biBjYW4gZXhwcmVzcyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yZ2FuaXphdGlvbiBjYW4gZXhwcmVz cyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZXNzYWdlIHZhbGlk YXRpb24sIGRpc3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZXNzYWdlIHZhbGlkYXRpb24sIGRp c3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3JnYW5pemF0 aW9uIGNhbiB1c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2Fu IGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uIGNhbiB1 c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2FuIGJlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFwcGxp ZWQgYXQgdGhlIGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5z IGF0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFwcGxpZWQgYXQgdGhl IGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5zIGF0IHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv cmdhbml6YXRpb25hbCBsZXZlbC4gIFRoZSBkZXNpZ24gb2YgRE1BUkMgcHJlY2x1ZGVzIGdyb3Vw aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uYWwgbGV2 ZWwuICBUaGUgZGVzaWduIG9mIERNQVJDIHByZWNsdWRlcyBncm91cGluZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9 ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMiIgLz48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwv dGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGVtPiBwYWdlIDEsIGxpbmUgNDM8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDMiIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJkZWxl dGUiPk5vdmVtYmVyIDI4LCAyMDE5PC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5KYW51YXJ5IDE0LCAyMDIwPC9zcGFuPi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5 cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmlnaHQgKGMp IDIwMTkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMTkgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFs bCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0 cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl IHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJs ZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDA0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMS4gIEludHJvZHVjdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFz cz0iZGVsZXRlIj4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBUZXJtaW5vbG9neSBh bmQgRGVmaW5pdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDIuICBUZXJtaW5vbG9neSBhbmQgRGVmaW5p dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIENvbnZl bnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIENvbnZlbnRpb25zIFVz ZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDA1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAyLjIuICBQdWJsaWMgU3Vm Zml4IERvbWFpbiAoUFNEKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgIDIuMi4gIFB1YmxpYyBTdWZmaXggRG9tYWluIChQU0QpICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMi4zLiAgTG9uZ2Vz dCBQU0QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4zLiAgTG9uZ2VzdCBQU0QgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuNC4gIFB1 YmxpYyBTdWZmaXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuNC4gIFB1YmxpYyBTdWZm aXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjUu ICBQU08gQ29udHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjUuICBQU08gQ29u dHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Mi42LiAgTm9uLWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi42LiAgTm9u LWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAzLiAgUFNEIERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgUFNE IERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAzLjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAz LjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgMy4yLiAgU2VjdGlvbiA2LjEgRE1BUkMgUG9saWN5IFJlY29yZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjIuICBTZWN0aW9uIDYuMSBETUFSQyBQb2xpY3kgUmVj b3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgMy4zLiAgU2VjdGlvbiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjMuICBTZWN0aW9uIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjYuMyBHZW5lcmFsIFJlY29yZCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgMy40Ljwvc3Bhbj4gIFNlY3Rpb24g Ni42LjMuICBQb2xpY3kgRGlzY292ZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAz LjQuICBTZWN0aW9uPC9zcGFuPiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPjMuNS48L3NwYW4+ICBTZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjayAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgIDMuNS48L3NwYW4+ICBTZWN0aW9uIDYuNi4zLiAgUG9saWN5IERpc2NvdmVyeSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgNC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPjMuNi48L3NwYW4+ICBTZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjayAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgNC4xLiAgRmVlZGJhY2sgbGVha2FnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgNC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA0LjEuICBGZWVkYmFjayBsZWFrYWdlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij43PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA1LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDci IC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA3LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUi Pjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgPHNwYW4gY2xh c3M9Imluc2VydCI+Ni4xLiAgU3ViZG9tYWluIFBvbGljeSBUYWcgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJk ZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDcuICBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDcuMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBcHBlbmRpeCBBLiAg VGhlIEV4cGVyaW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPjk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBcHBlbmRp eCBCLiAgRE1BUkMgUFNEIFJlZ2lzdHJ5IEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIEFwcGVuZGl4IEEuICBUaGUgRXhwZXJpbWVudCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg IEIuMS4gIERNQVJDIFBTRCBETlMgUXVlcnkgU2VydmljZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIEFwcGVuZGl4IEIuICBETUFSQyBQU0QgUmVnaXN0cnkgRXhhbXBs ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMTwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgIEIuMi4gIERNQVJDIFB1YmxpYyBTdWZmaXggRG9tYWluIChQU0QpIFJlZ2lzdHJ5IC4g LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgQi4xLiAgRE1BUkMgUFNEIEROUyBRdWVyeSBTZXJ2 aWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4x MTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBBcHBlbmRpeCBDLiAgSW1wbGVtZW50YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgQi4yLiAgRE1BUkMgUHVibGljIFN1ZmZp eCBEb21haW4gKFBTRCkgUmVnaXN0cnkgLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4xMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgIEMuMS4gIEF1dGhoZWFkZXJzIE1vZHVsZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEFwcGVuZGl4IEMuICBJbXBsZW1l bnRhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgQy4xLiAgQXV0aGhl YWRlcnMgTW9kdWxlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEFja25vd2xl ZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIERNQVJDIFtSRkM3NDg5XSBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgcHVibGlzaGlu ZyBvcmdhbml6YXRpb25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERNQVJD IFtSRkM3NDg5XSBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgcHVibGlzaGluZyBvcmdhbml6YXRp b25hbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBwb2xpY3kgaW5mb3JtYXRpb24gdG8gZW1haWwgcmVjZWl2ZXJzLiAgRE1BUkMgW1JGQzc0 ODldIGFsbG93cyBwb2xpY3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwb2xp Y3kgaW5mb3JtYXRpb24gdG8gZW1haWwgcmVjZWl2ZXJzLiAgRE1BUkMgW1JGQzc0ODldIGFsbG93 cyBwb2xpY3k8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdG8gYmUgc3BlY2lmaWVkIGZvciBib3RoIGluZGl2aWR1YWwgZG9tYWlucyBhbmQg c2V0cyBvZiBkb21haW5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gYmUg c3BlY2lmaWVkIGZvciBib3RoIGluZGl2aWR1YWwgZG9tYWlucyBhbmQgc2V0cyBvZiBkb21haW5z PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHdpdGhpbiBhIHNpbmdsZSBvcmdhbml6YXRpb24uICBGb3IgZG9tYWlucyBhYm92ZSB0aGUgb3Jn YW5pemF0aW9uYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXRoaW4gYSBz aW5nbGUgb3JnYW5pemF0aW9uLiAgRm9yIGRvbWFpbnMgYWJvdmUgdGhlIG9yZ2FuaXphdGlvbmFs PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGxldmVsIGluIHRoZSBETlMgdHJlZSwgcG9saWN5IGNhbiBvbmx5IGJlIHB1Ymxpc2hlZCBmb3Ig dGhlIGV4YWN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGV2ZWwgaW4gdGhl IEROUyB0cmVlLCBwb2xpY3kgY2FuIG9ubHkgYmUgcHVibGlzaGVkIGZvciB0aGUgZXhhY3Q8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9t YWluLiAgVGhlcmUgaXMgbm8gbWV0aG9kIGF2YWlsYWJsZSB0byBzdWNoIGRvbWFpbnMgdG8gZXhw cmVzczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvbWFpbi4gIFRoZXJlIGlz IG5vIG1ldGhvZCBhdmFpbGFibGUgdG8gc3VjaCBkb21haW5zIHRvIGV4cHJlc3M8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbG93ZXIgbGV2 ZWwgcG9saWN5IG9yIHJlY2VpdmUgZmVlZGJhY2sgcmVwb3J0aW5nIGZvciBzZXRzIG9mIGRvbWFp bnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbG93ZXIgbGV2ZWwgcG9saWN5 IG9yIHJlY2VpdmUgZmVlZGJhY2sgcmVwb3J0aW5nIGZvciBzZXRzIG9mIGRvbWFpbnMuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg Ymdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwzIiAvPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAzLCBsaW5lIDM4PC9lbT48L3Ro Pjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hh bmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMywgbGluZSA0NTwvZW0+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgaW4gYSBtYWlsIGRlbGl2ZXJ5IGRlY2lzaW9uLCBidXQgaXMgbm90IGdlbmVy YWxseSB0cmVhdGVkIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW4gYSBt YWlsIGRlbGl2ZXJ5IGRlY2lzaW9uLCBidXQgaXMgbm90IGdlbmVyYWxseSB0cmVhdGVkIGFzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRl ZmluaXRpdmUgb24gaXRzIG93bi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBk ZWZpbml0aXZlIG9uIGl0cyBvd24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlz IG1lbW8gcHJvdmlkZXMgYSBzaW1wbGUgZXh0ZW5zaW9uIHRvIERNQVJDIFtSRkM3NDg5XSB0byBh bGxvdzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgbWVtbyBwcm92aWRl cyBhIHNpbXBsZSBleHRlbnNpb24gdG8gRE1BUkMgW1JGQzc0ODldIHRvIGFsbG93PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9wZXJhdG9y cyBvZiBQdWJsaWMgU3VmZml4IERvbWFpbnMgKFBTRHMpIHRvIGV4cHJlc3MgcG9saWN5IGZvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdG9ycyBvZiBQdWJsaWMgU3Vm Zml4IERvbWFpbnMgKFBTRHMpIHRvIGV4cHJlc3MgcG9saWN5IGZvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBncm91cHMgb2Ygc3ViZG9t YWlucywgZXh0ZW5kcyB0aGUgRE1BUkMgW1JGQzc0ODldIHBvbGljeSBxdWVyeTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGdyb3VwcyBvZiBzdWJkb21haW5zLCBleHRlbmRzIHRo ZSBETUFSQyBbUkZDNzQ4OV0gcG9saWN5IHF1ZXJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZ1bmN0aW9uYWxpdHkgdG8gZGV0ZWN0IGFu ZCBwcm9jZXNzIHN1Y2ggYSBwb2xpY3ksIGRlc2NyaWJlcyByZWNlaXZlcjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZ1bmN0aW9uYWxpdHkgdG8gZGV0ZWN0IGFuZCBwcm9jZXNz IHN1Y2ggYSBwb2xpY3ksIGRlc2NyaWJlcyByZWNlaXZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmZWVkYmFjayBmb3Igc3VjaCBwb2xp Y2llcywgYW5kIHByb3ZpZGVzIGNvbnRyb2xzIHRvIG1pdGlnYXRlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgZmVlZGJhY2sgZm9yIHN1Y2ggcG9saWNpZXMsIGFuZCBwcm92aWRl cyBjb250cm9scyB0byBtaXRpZ2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwb3RlbnRpYWwgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBh c3NvY2lhdGVkIHdpdGggdGhpcyBleHRlbnNpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcG90ZW50aWFsIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB3aXRo IHRoaXMgZXh0ZW5zaW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDA4IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgbWVtbyBhbHNvIHByb3Zp ZGVzIGEgbmV3IERNQVJDIFtSRkM3NDg5XSB0YWcgdG8gaW5kaWNhdGU8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHJlcXVlc3Rl ZCBoYW5kbGluZyBwb2xpY3kgZm9yIG5vbi1leGlzdGVudCBzdWJkb21tYWlucy4gIFRoaXMgaXM8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIHByb3ZpZGVkIHNwZWNpZmljYWxseSB0byBzdXBwb3J0IHBoYXNlZCBkZXBsb3ltZW50 IG9mIFBTRCBETUFSQywgYnV0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpcyBleHBlY3RlZCB0byBiZSB1c2VmdWwgbW9yZSBn ZW5lcmFsbHkuICBVbmRlc2lyZWQgcmVqZWN0aW9uIHJpc2tzPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBmb3IgbWFpbCBwdXJw b3J0aW5nIHRvIGJlIGZyb20gZG9tYWlucyB0aGF0IGRvIG5vdCBleGlzdCBhcmU8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHN1 YnN0YW50aWFsbHkgbG93ZXIgdGhhbiBmb3IgdGhvc2UgdGhhdCBkbywgc28gdGhlIG9wZXJhdGlv bmFsIHJpc2s8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIG9mIHJlcXVlc3RpbmcgaGFyc2ggcG9saWN5IHRyZWF0bWVudCAoZS5n LiByZWplY3QpIGlzIGxvd2VyLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBBcyBhbiBhZGRpdGlvbmFsIGJlbmVmaXQsIHRoZSBQU0QgRE1B UkMgZXh0ZW5zaW9uIHdpbGwgY2xhcmlmeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEFzIGFuIGFkZGl0aW9uYWwgYmVuZWZpdCwgdGhlIFBTRCBETUFSQyBleHRlbnNpb24gd2ls bCBjbGFyaWZ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGV4aXN0aW5nIHJlcXVpcmVtZW50cy4gIEJhc2VkIG9uIHRoZSByZXF1aXJlbWVu dHMgb2YgRE1BUkMgW1JGQzc0ODldLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGV4aXN0aW5nIHJlcXVpcmVtZW50cy4gIEJhc2VkIG9uIHRoZSByZXF1aXJlbWVudHMgb2YgRE1B UkMgW1JGQzc0ODldLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBETUFSQyBzaG91bGQgZnVuY3Rpb24gYWJvdmUgdGhlIG9yZ2FuaXphdGlv bmFsIGxldmVsIGZvciBleGFjdCBkb21haW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBETUFSQyBzaG91bGQgZnVuY3Rpb24gYWJvdmUgdGhlIG9yZ2FuaXphdGlvbmFsIGxldmVs IGZvciBleGFjdCBkb21haW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgbWF0Y2hlcyAoaS5lLiBpZiBhIERNQVJDIHJlY29yZCB3ZXJlIHB1 Ymxpc2hlZCBmb3IgJ2V4YW1wbGUnLCB0aGVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgbWF0Y2hlcyAoaS5lLiBpZiBhIERNQVJDIHJlY29yZCB3ZXJlIHB1Ymxpc2hlZCBmb3Ig J2V4YW1wbGUnLCB0aGVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG1haWwgZnJvbSBleGFtcGxlQGV4YW1wbGUgc2hvdWxkIGJlIHN1Ympl Y3QgdG8gRE1BUkMgcHJvY2Vzc2luZykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbWFpbCBmcm9tIGV4YW1wbGVAZXhhbXBsZSBzaG91bGQgYmUgc3ViamVjdCB0byBETUFSQyBw cm9jZXNzaW5nKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVGVzdGluZyBoYWQgcmV2ZWFsZWQgdGhhdCB0aGlzIGlzIG5vdCBjb25zaXN0 ZW50bHkgYXBwbGllZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRlc3Rp bmcgaGFkIHJldmVhbGVkIHRoYXQgdGhpcyBpcyBub3QgY29uc2lzdGVudGx5IGFwcGxpZWQgaW48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4gIFBTRCBETUFSQyB3aWxsIGhlbHAgY2xhcmlmeSB0 aGF0IERNQVJDIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGlmZmVyZW50 IGltcGxlbWVudGF0aW9ucy4gIFBTRCBETUFSQyB3aWxsIGhlbHAgY2xhcmlmeSB0aGF0IERNQVJD IGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIG5vdCBsaW1pdGVkIHRvIG9yZ2FuaXphdGlvbmFsIGRvbWFpbnMgYW5kIHRoZWlyIHN1Yi1k b21haW5zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vdCBsaW1pdGVkIHRv IG9yZ2FuaXphdGlvbmFsIGRvbWFpbnMgYW5kIHRoZWlyIHN1Yi1kb21haW5zLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlcmUgYXJlIHR3byB0eXBlcyBvZiBQdWJsaWMgU3VmZml4 IE9wZXJhdG9ycyAoUFNPcykgZm9yIHdoaWNoIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBUaGVyZSBhcmUgdHdvIHR5cGVzIG9mIFB1YmxpYyBTdWZmaXggT3BlcmF0b3Jz IChQU09zKSBmb3Igd2hpY2ggdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+ PGEgbmFtZT0icGFydC1sNCIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 ZW0+IHBhZ2UgNSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQt cjQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYsIGxp bmUgMTE8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuMS4gIEdlbmVyYWwgVXBkYXRl czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuMS4gIEdlbmVyYWwgVXBkYXRlczwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVmZXJlbmNlcyB0byAiRG9tYWluIE93bmVy cyIgYWxzbyBhcHBseSB0byBQU09zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFJlZmVyZW5jZXMgdG8gIkRvbWFpbiBPd25lcnMiIGFsc28gYXBwbHkgdG8gUFNPcy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuMi4gIFNlY3Rpb24gNi4xIERNQVJDIFBvbGljeSBSZWNv cmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjIuICBTZWN0aW9uIDYuMSBETUFS QyBQb2xpY3kgUmVjb3JkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQU0QgRE1BUkMg cmVjb3JkcyBhcmUgcHVibGlzaGVkIGFzIGEgc3ViZG9tYWluIG9mIHRoZSBQU0QuICBGb3IgdGhl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFNEIERNQVJDIHJlY29yZHMgYXJl IHB1Ymxpc2hlZCBhcyBhIHN1YmRvbWFpbiBvZiB0aGUgUFNELiAgRm9yIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQU0QgIi5leGFt cGxlIiwgdGhlIFBTTyB3b3VsZCBwb3N0IERNQVJDIHBvbGljeSBpbiBhIFRYVCByZWNvcmQgYXQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQU0QgIi5leGFtcGxlIiwgdGhlIFBT TyB3b3VsZCBwb3N0IERNQVJDIHBvbGljeSBpbiBhIFRYVCByZWNvcmQgYXQ8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIl9kbWFyYy5leGFt cGxlIi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAiX2RtYXJjLmV4YW1wbGUi LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5IiAv PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+My4zLiAgU2VjdGlvbiA2LjUuICBEb21haW4gT3duZXIgQWN0 aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4zLjMuICBTZWN0aW9uIDxzcGFu IGNsYXNzPSJpbnNlcnQiPjYuMyBHZW5lcmFsIFJlY29yZCBGb3JtYXQ8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgQSBu ZXcgdGFnIGlzIGFkZGVkIGFmdGVyIGZvOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzcDogIFJlcXVlc3RlZCBNYWls IFJlY2VpdmVyIHBvbGljeSBmb3Igbm9uLWV4aXN0ZW50IHN1YmRvbWFpbnM8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIChw bGFpbi10ZXh0OyBPUFRJT05BTCkuICBJbmRpY2F0ZXMgdGhlIHBvbGljeSB0byBiZSBlbmFjdGVk IGJ5IHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgUmVjZWl2ZXIgYXQgdGhlIHJlcXVlc3Qgb2YgdGhlIERvbWFpbiBP d25lci4gIEl0IGFwcGxpZXMgb25seSB0bzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgbm9uLWV4aXN0ZW50IHN1YmRvbWFp bnMgb2YgdGhlIGRvbWFpbiBxdWVyaWVkIGFuZCBub3QgdG8gZWl0aGVyPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBleGlz dGluZyBzdWJkb21haW5zIG9yIHRoZSBkb21haW4gaXRzZWxmLiAgSXRzIHN5bnRheCBpcyBpZGVu dGljYWw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICAgIHRvIHRoYXQgb2YgdGhlICJwIiB0YWcgZGVmaW5lZCBiZWxvdy4gIElm IGFic2VudCwgdGhlIHBvbGljeTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgc3BlY2lmaWVkIGJ5IHRoZSAic3AiIChpZiBw cmVzZW50KSBhbmQgdGhlbiB0aGUgInAiIHRhZywgaWYgbm90LDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgTVVTVCBiZSBh cHBsaWVkIGZvciBub24tZXhpc3RlbnQgc3ViZG9tYWlucy4gIE5vdGUgdGhhdCAibnAiIHdpbGw8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgICAgIGJlIGlnbm9yZWQgZm9yIERNQVJDIHJlY29yZHMgcHVibGlzaGVkIG9uIHN1YmRv bWFpbnMgb2Y8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMgYW5kIFBTRHMgZHVlIHRv IHRoZSBlZmZlY3Qgb2YgdGhlIERNQVJDPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBwb2xpY3kgZGlzY292ZXJ5IG1lY2hh bmlzbSBkZXNjcmliZWQgaW4gRE1BUkMgW1JGQzc0ODldPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBTZWN0aW9uIDYuNi4z Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4zLjQuICBTZWN0aW9uPC9zcGFuPiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9u czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW4gYWRkaXRpb24gdG8gdGhlIERNQVJD IFtSRkM3NDg5XSBkb21haW4gb3duZXIgYWN0aW9ucywgUFNPcyB0aGF0PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gYWRkaXRpb24gdG8gdGhlIERNQVJDIFtSRkM3NDg5XSBk b21haW4gb3duZXIgYWN0aW9ucywgUFNPcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcXVpcmUgdXNlIG9mIERNQVJDIG91Z2h0 IHRvIG1ha2UgdGhhdCBpbmZvcm1hdGlvbiBhdmFpbGFibGUgdG88L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICByZXF1aXJlIHVzZSBvZiBETUFSQyBvdWdodCB0byBtYWtlIHRoYXQg aW5mb3JtYXRpb24gYXZhaWxhYmxlIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlY2VpdmVycy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICByZWNlaXZlcnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMTAiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4zLjxzcGFuIGNsYXNz PSJkZWxldGUiPjQ8L3NwYW4+LiAgU2VjdGlvbiA2LjYuMy4gIFBvbGljeSBEaXNjb3Zlcnk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+My48c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9z cGFuPi4gIFNlY3Rpb24gNi42LjMuICBQb2xpY3kgRGlzY292ZXJ5PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBBIG5ldyBzdGVwIGJldHdlZW4gc3RlcCAzIGFuZCA0IGlzIGFkZGVkOjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEgbmV3IHN0ZXAgYmV0d2VlbiBzdGVw IDMgYW5kIDQgaXMgYWRkZWQ6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzQS4gIElm IHRoZSBzZXQgaXMgbm93IGVtcHR5IGFuZCB0aGUgbG9uZ2VzdCBQU0QgKFNlY3Rpb24gMi4zKSBv ZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzQS4gIElmIHRoZSBzZXQg aXMgbm93IGVtcHR5IGFuZCB0aGUgbG9uZ2VzdCBQU0QgKFNlY3Rpb24gMi4zKSBvZiB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg T3JnYW5pemF0aW9uYWwgRG9tYWluIGlzIG9uZSB0aGF0IHRoZSByZWNlaXZlciBoYXMgZGV0ZXJt aW5lZCBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE9yZ2FuaXphdGlv bmFsIERvbWFpbiBpcyBvbmUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGRldGVybWluZWQgaXM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg YWNjZXB0YWJsZSBmb3IgUFNEIERNQVJDLCB0aGUgTWFpbCBSZWNlaXZlciBNVVNUIHF1ZXJ5IHRo ZSBETlMgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYWNjZXB0YWJs ZSBmb3IgUFNEIERNQVJDLCB0aGUgTWFpbCBSZWNlaXZlciBNVVNUIHF1ZXJ5IHRoZSBETlMgZm9y PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGEgRE1BUkMgVFhUIHJlY29yZCBhdCB0aGUgRE5TIGRvbWFpbiBtYXRjaGluZyB0aGUgbG9u Z2VzdCBQU0Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBhIERNQVJDIFRY VCByZWNvcmQgYXQgdGhlIEROUyBkb21haW4gbWF0Y2hpbmcgdGhlIGxvbmdlc3QgUFNEPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIChT ZWN0aW9uIDIuMykgaW4gcGxhY2Ugb2YgdGhlIFJGQzUzMjIuRnJvbSBkb21haW4gaW4gdGhlIG1l c3NhZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAoU2VjdGlvbiAyLjMp IGluIHBsYWNlIG9mIHRoZSBSRkM1MzIyLkZyb20gZG9tYWluIGluIHRoZSBtZXNzYWdlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIChp ZiBkaWZmZXJlbnQpLiAgQSBwb3NzaWJseSBlbXB0eSBzZXQgb2YgcmVjb3JkcyBpcyByZXR1cm5l ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAoaWYgZGlmZmVyZW50KS4g IEEgcG9zc2libHkgZW1wdHkgc2V0IG9mIHJlY29yZHMgaXMgcmV0dXJuZWQuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEg bmFtZT0icGFydC1sNSIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgNiwgbGluZSAyOTwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjUi IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDcsIGxpbmUg MTE8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChTZWN0aW9uIDIuMykuICBUaGUg cmVjZWl2ZXIgd291bGQgY2hlY2sgdG8gc2VlIGlmIHRoYXQgUFNEIGlzIGxpc3RlZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChTZWN0aW9uIDIuMykuICBUaGUgcmVjZWl2ZXIg d291bGQgY2hlY2sgdG8gc2VlIGlmIHRoYXQgUFNEIGlzIGxpc3RlZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiB0aGUgRE1BUkMgUFNE IFJlZ2lzdHJ5LCBhbmQgaWYgc28sIHBlcmZvcm0gdGhlIHBvbGljeSBsb29rdXAgYXQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbiB0aGUgRE1BUkMgUFNEIFJlZ2lzdHJ5LCBh bmQgaWYgc28sIHBlcmZvcm0gdGhlIHBvbGljeSBsb29rdXAgYXQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIl9kbWFyYy5jb21wdXRlLmNs b3VkY29tcGFueS5jb20uY2N0bGQiLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICJfZG1hcmMuY29tcHV0ZS5jbG91ZGNvbXBhbnkuY29tLmNjdGxkIi48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIE5vdGU6IEJlY2F1c2UgdGhlIFBTRCBwb2xpY3kgcXVlcnkgY29tZXMg YWZ0ZXIgdGhlIE9yZ2FuaXphdGlvbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgTm90ZTogQmVjYXVzZSB0aGUgUFNEIHBvbGljeSBxdWVyeSBjb21lcyBhZnRlciB0aGUgT3Jn YW5pemF0aW9uYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRG9tYWluIHBvbGljeSBxdWVyeSwgUFNEIHBvbGljeSBpcyBub3QgdXNlZCBm b3IgT3JnYW5pemF0aW9uYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEb21h aW4gcG9saWN5IHF1ZXJ5LCBQU0QgcG9saWN5IGlzIG5vdCB1c2VkIGZvciBPcmdhbml6YXRpb25h bDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBkb21haW5zIHRoYXQgaGF2ZSBwdWJsaXNoZWQgYSBETUFSQyBbUkZDNzQ4OV0gcG9saWN5LiAg U3BlY2lmaWNhbGx5LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvbWFpbnMg dGhhdCBoYXZlIHB1Ymxpc2hlZCBhIERNQVJDIFtSRkM3NDg5XSBwb2xpY3kuICBTcGVjaWZpY2Fs bHksPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRoaXMgaXMgbm90IGEgbWVjaGFuaXNtIHRvIHByb3ZpZGUgZmVlZGJhY2sgYWRkcmVzc2Vz IChSVUEvUlVGKSB3aGVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhpcyBp cyBub3QgYSBtZWNoYW5pc20gdG8gcHJvdmlkZSBmZWVkYmFjayBhZGRyZXNzZXMgKFJVQS9SVUYp IHdoZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYW4gT3JnYW5pemF0aW9uYWwgRG9tYWluIGhhcyBkZWNsaW5lZCB0byBkbyBzby48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbiBPcmdhbml6YXRpb25hbCBEb21haW4g aGFzIGRlY2xpbmVkIHRvIGRvIHNvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk PjxhIG5hbWU9ImRpZmYwMDExIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+My48c3BhbiBjbGFzcz0i ZGVsZXRlIj41PC9zcGFuPi4gIFNlY3Rpb24gNy4gIERNQVJDIEZlZWRiYWNrPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjMuPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj4uICBT ZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg T3BlcmF0aW9uYWwgbm90ZSBmb3IgUFNEIERNQVJDOiBGb3IgUFNPcywgZmVlZGJhY2sgZm9yIG5v bi1leGlzdGVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE9wZXJhdGlvbmFs IG5vdGUgZm9yIFBTRCBETUFSQzogRm9yIFBTT3MsIGZlZWRiYWNrIGZvciBub24tZXhpc3RlbnQ8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ZG9tYWlucyBpcyBkZXNpcmVkIGFuZCB1c2VmdWwuICBTZWUgU2VjdGlvbiA0IGZvciBkaXNjdXNz aW9uIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9tYWlucyBpcyBkZXNp cmVkIGFuZCB1c2VmdWwuICBTZWUgU2VjdGlvbiA0IGZvciBkaXNjdXNzaW9uIG9mPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByaXZhY3kg Q29uc2lkZXJhdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJpdmFj eSBDb25zaWRlcmF0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBQcml2YWN5 IENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIFByaXZh Y3kgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZXNlIHBy aXZhY3kgY29uc2lkZXJhdGlvbnMgYXJlIGRldmVsb3BlZCBiYXNlZCBvbiB0aGUgcmVxdWlyZW1l dG5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlc2UgcHJpdmFjeSBjb25z aWRlcmF0aW9ucyBhcmUgZGV2ZWxvcGVkIGJhc2VkIG9uIHRoZSByZXF1aXJlbWV0bnM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgW1JG QzY5NzNdLiAgVGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgb2YgW1JGQzc0ODldIGFwcGx5IHRv IHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvZiBbUkZDNjk3M10uICBU aGUgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBvZiBbUkZDNzQ4OV0gYXBwbHkgdG8gdGhpczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1 bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBi Z2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDYiIC8+PHNtYWxsPnNr aXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDcsIGxpbmUgMjQ8L2VtPjwvdGg+ PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI2IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA4LCBsaW5lIDY8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIGNvbXBsaWFuY2Ugd2l0aCBQU0QgcG9saWN5LiAgRGF0YSBvbiBub24tZXhp c3RlbnQgY291c2luIGRvbWFpbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBjb21wbGlhbmNlIHdpdGggUFNEIHBvbGljeS4gIERhdGEgb24gbm9uLWV4aXN0ZW50IGNvdXNp biBkb21haW5zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIHdvdWxkIGJlIHNlbnQgdG8gdGhlIFBTTy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICB3b3VsZCBiZSBzZW50IHRvIHRoZSBQU08uPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBNdWx0aS1vcmdhbml6YXRpb24gUFNEcyAoZS5nLiwgIi5j b20iKSB0aGF0IGRvIG5vdCBtYW5kYXRlIERNQVJDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgTXVsdGktb3JnYW5pemF0aW9uIFBTRHMgKGUuZy4sICIuY29tIikgdGhhdCBk byBub3QgbWFuZGF0ZSBETUFSQzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB1c2FnZTogUHJpdmFjeSByaXNrcyBmb3IgT3JnYW5pemF0 aW9uYWwgRG9tYWlucyB0aGF0IGhhdmUgbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgdXNhZ2U6IFByaXZhY3kgcmlza3MgZm9yIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMg dGhhdCBoYXZlIG5vdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBkZXBsb3llZCBETUFSQyB3aXRoaW4gc3VjaCBQU0RzIGFyZSBzaWdu aWZpY2FudC4gIEZvciBub24tRE1BUkM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICBkZXBsb3llZCBETUFSQyB3aXRoaW4gc3VjaCBQU0RzIGFyZSBzaWduaWZpY2FudC4gIEZv ciBub24tRE1BUkM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgT3JnYW5pemF0aW9uYWwgRG9tYWlucywgYWxsIERNQVJDIGZlZWRiYWNr IHdpbGwgYmUgZGlyZWN0ZWQgdG8gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgT3JnYW5pemF0aW9uYWwgRG9tYWlucywgYWxsIERNQVJDIGZlZWRiYWNrIHdpbGwgYmUg ZGlyZWN0ZWQgdG8gdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIFBTTy4gIFBTRCBETUFSQyBpcyBvcHQtb3V0IChieSBwdWJsaXNo aW5nIGEgRE1BUkMgcmVjb3JkIGF0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIFBTTy4gIFBTRCBETUFSQyBpcyBvcHQtb3V0IChieSBwdWJsaXNoaW5nIGEgRE1BUkMg cmVjb3JkIGF0IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBPcmdhbml6YXRpb25hbCBEb21haW4gbGV2ZWwpIHZpY2Ugb3B0LWlu LCB3aGljaCB3b3VsZCBiZSB0aGUgbW9yZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbiBsZXZlbCkgdmljZSBvcHQtaW4sIHdoaWNoIHdv dWxkIGJlIHRoZSBtb3JlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3RpYy4gIFRoaXMgbWVhbnMg dGhhdCBhbnkgbm9uLURNQVJDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ZGVzaXJhYmxlIGNoYXJhY3RlcmlzdGljLiAgVGhpcyBtZWFucyB0aGF0IGFueSBub24tRE1BUkM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDEyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgb3JnYW5p emF0aW9uYWwgZG9tYWluIHdvdWxkIGhhdmUgaXQ8c3BhbiBjbGFzcz0iZGVsZXRlIj4nPC9zcGFu PnMgZmVlZGJhY2sgcmVwb3J0cyByZWRpcmVjdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiB3b3VsZCBoYXZlIGl0cyBmZWVkYmFj ayByZXBvcnRzIHJlZGlyZWN0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdG8gdGhlIFBTTy4gIFRoZSBjb250ZW50IG9mIHN1Y2gg cmVwb3J0cywgcGFydGljdWxhcmx5IGZvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIHRvIHRoZSBQU08uICBUaGUgY29udGVudCBvZiBzdWNoIHJlcG9ydHMsIHBhcnRpY3Vs YXJseSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgZXhpc3RpbmcgZG9tYWlucywgaXMgcHJpdmFjeSBzZW5zaXRpdmUuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZXhpc3RpbmcgZG9tYWlucywgaXMgcHJp dmFjeSBzZW5zaXRpdmUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQU09zIHdpbGwg cmVjZWl2ZSBmZWVkYmFjayBvbiBub24tZXhpc3RlbnQgZG9tYWlucywgd2hpY2ggbWF5IGJlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFNPcyB3aWxsIHJlY2VpdmUgZmVlZGJh Y2sgb24gbm9uLWV4aXN0ZW50IGRvbWFpbnMsIHdoaWNoIG1heSBiZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzaW1pbGFyIHRvIGV4aXN0 aW5nIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMuICBGZWVkYmFjayByZWxhdGVkIHRvIHN1Y2g8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzaW1pbGFyIHRvIGV4aXN0aW5nIE9yZ2Fu aXphdGlvbmFsIERvbWFpbnMuICBGZWVkYmFjayByZWxhdGVkIHRvIHN1Y2g8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY291c2luIGRvbWFp bnMgaGF2ZSBhIHNtYWxsIHJpc2sgb2YgY2FycnlpbmcgaW5mb3JtYXRpb24gcmVsYXRlZCB0bzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvdXNpbiBkb21haW5zIGhhdmUgYSBz bWFsbCByaXNrIG9mIGNhcnJ5aW5nIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG88L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW4gYWN0dWFsIE9y Z2FuaXphdGlvbmFsIERvbWFpbi4gIFRvIG1pbmltaXplIHRoaXMgcG90ZW50aWFsIGNvbmNlcm4s PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW4gYWN0dWFsIE9yZ2FuaXphdGlv bmFsIERvbWFpbi4gIFRvIG1pbmltaXplIHRoaXMgcG90ZW50aWFsIGNvbmNlcm4sPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBTRCBETUFS QyBmZWVkYmFjayBpcyBiZXN0IGxpbWl0ZWQgdG8gQWdncmVnYXRlIFJlcG9ydHMuICBGZWVkYmFj azwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTRCBETUFSQyBmZWVkYmFjayBp cyBiZXN0IGxpbWl0ZWQgdG8gQWdncmVnYXRlIFJlcG9ydHMuICBGZWVkYmFjazwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSZXBvcnRzIGNh cnJ5IG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gYW5kIHByZXNlbnQgYSBncmVhdGVyIHJpc2su PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmVwb3J0cyBjYXJyeSBtb3JlIGRl dGFpbGVkIGluZm9ybWF0aW9uIGFuZCBwcmVzZW50IGEgZ3JlYXRlciByaXNrLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxh IG5hbWU9InBhcnQtbDciIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVt PiBwYWdlIDgsIGxpbmUgNzwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjci IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDgsIGxpbmUg Mzc8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3NDg5XSBhbmQgW1JGQzc5 NjBdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM3NDg5XSBhbmQgW1JG Qzc5NjBdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHJpc2tzIG9mIHRoZSBp c3N1ZXMgaWRlbnRpZmllZCBpbiBbUkZDNzQ4OV0sIFNlY3Rpb24gMTIuNSw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcmlza3Mgb2YgdGhlIGlzc3VlcyBpZGVudGlmaWVk IGluIFtSRkM3NDg5XSwgU2VjdGlvbiAxMi41LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFeHRlcm5hbCBSZXBvcnRpbmcgQWRkcmVzc2Vz LCBhcmUgYW1wbGlmaWVkIGJ5IFBTRCBETUFSQy4gIEJ5IGRlc2lnbiw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHRlcm5hbCBSZXBvcnRpbmcgQWRkcmVzc2VzLCBhcmUgYW1w bGlmaWVkIGJ5IFBTRCBETUFSQy4gIEJ5IGRlc2lnbiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEIERNQVJDIGNhdXNlcyB1bnJlcXVl c3RlZCByZXBvcnRpbmcgb2YgZmVlZGJhY2sgdG8gZW50aXRpZXM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBQU0QgRE1BUkMgY2F1c2VzIHVucmVxdWVzdGVkIHJlcG9ydGluZyBv ZiBmZWVkYmFjayB0byBlbnRpdGllczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHRlcm5hbCB0byB0aGUgT3JnYW5pemF0aW9uYWwgRG9t YWluLiAgVGhpcyBpcyBkaXNjdXNzZWQgaW4gbW9yZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGV4dGVybmFsIHRvIHRoZSBPcmdhbml6YXRpb25hbCBEb21haW4uICBUaGlzIGlz IGRpc2N1c3NlZCBpbiBtb3JlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGRldGFpbCBpbiBTZWN0aW9uIDQuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgZGV0YWlsIGluIFNlY3Rpb24gNC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjYuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+Ni4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRo aXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZG9jdW1lbnQgZG9lcyBub3QgcmVxdWlyZSBhbnk8L3Nw YW4+IElBTkEgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YWN0aW9ucy48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgPHNwYW4gY2xhc3M9Imluc2VydCI+c2VjdGlv biBkZXNjcmliZXMgYWN0aW9ucyByZXF1ZXN0ZWQgdG8gYmUgY29tcGxldGVkIGJ5IElBTkEuPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPjYuMS4gIFN1YmRvbWFpbiBQb2xpY3kgVGFnPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIElBTkEgPHNwYW4gY2xhc3M9Imluc2VydCI+aXMgcmVxdWVzdGVkIHRvIGFk ZCBhIG5ldyB0YWcgdG8gRE1BUkMgVGFnIFJlZ2lzdHJ5IGluIHRoZTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgRG9tYWluLWJh c2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywgYW5kIENvbmZvcm1hbmNlPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAoRE1BUkMpIFBhcmFtZXRlcnMgUmVnaXN0cnkuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoZSBlbnRyeSBp cyBhcyBmb2xsb3dzOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgVGFnIE5hbWUgfCBS ZWZlcmVuY2UgfCBTdGF0dXMgIHwgRGVzY3JpcHRpb24gICAgICAgICAgICAgICAgICAgfDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICB8IG5wICAgICAgIHwgdGhpcyAgICAgIHwgY3VycmVudCB8IFJl cXVlc3RlZCBoYW5kbGluZyBwb2xpY3kgZm9yIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAgICAgICAgfCBkb2N1bWVu dCAgfCAgICAgICAgIHwgbm9uLWV4aXN0ZW50IHN1YmRvbWFpbnMgICAgICAgfDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgKy0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4gIFJlZmVyZW5jZXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij43LiAgUmVmZXJlbmNlczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+Ny4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij43LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0 byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIx MTksPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9S RkMyMTE5LCBNYXJjaCAxOTk3LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0 O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmMyMTE5Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KCiAgICAgPHRy Pjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bh bj0iNSIgYWxpZ249ImNlbnRlciI+PGEgbmFtZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4g MTMgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3Rh dHMiPjx0ZD48L3RkPjx0aD48aT4yOSBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48 dGg+PGk+IDwvaT48L3RoPjx0aD48aT43MSBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+ PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNs YXNzPSJzbWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAx LjQxLiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDov L3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9y Zy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAg IDwvaHRtbD4K --nextPart2182572.SKLRh5PmXv-- From nobody Sun Jul 14 03:12: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 4E4441200E5 for ; Sun, 14 Jul 2019 03:12:51 -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 7-jVUtsRV34p for ; Sun, 14 Jul 2019 03:12:49 -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 33581120077 for ; Sun, 14 Jul 2019 03:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563099166; bh=sb56tIj858m4ocEhcSce98+mktKtWNLDSWVWj7R6GdI=; l=3092; h=To:References:From:Date:In-Reply-To; b=BfizFUS0J4qNc4YuiF8je93r+a+rqarmNtwxsWI4wqKOD1vRj9mm3D3CHIg5LSc4t EOLQOfGra7nTZjgPTdVriOl8PuGnp3A1G+UxKZTudHWXqJB5LdjwiEemy1/f3/5yXt RhZ6xe1GD8LJ+dZPzZF23proFleQk5ghpA4b4zsJikLdHtb98WyK/q/oNf8ko Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.9.184]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005D2B001E.00004618; Sun, 14 Jul 2019 12:12:46 +0200 To: dmarc@ietf.org References: <1783751.gHVjF1RMII@l5580> <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> <12139607.XScsT9yxuP@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <672143c9-f0e3-de1a-1c91-a223965554c8@tana.it> Date: Sun, 14 Jul 2019 12:12:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <12139607.XScsT9yxuP@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 14 Jul 2019 10:12:52 -0000 On Fri 12/Jul/2019 20:27:05 +0200 Scott Kitterman wrote: > On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote: >> On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: >>> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: >>>> As Secretary, there are three items that have not yet reached consensus >>>> that must be resolved during WGLC: >>>> >>>> 2. If explicit call outs to ICANN/limited operator capacity to implement >>>> are needed >>> >>> There has been feedback in favor of adding this and none against so far. >>> >>> The specific proposal is: >>> >>> "Please note that today's operational and policy reality prevents this >>> experiment from being deployed globally. If the experiment shows that PSD >>> solves a real problem at a large scale, the results could prove to be >>> useful in the development of policies outside of the IETF that would >>> permit its ubiquitous deployment." >>> >>> Because RFCs are (approximately) forever, I'm concerned about words like >>> "today's" in protocol documents, even experimental ones. >>> >>> How about this instead: >>> >>> "As of the writing of this document operational and policy constraints >>> prevent this experiment from being deployed globally. If the experiment >>> shows that PSD solves a real problem and can be used at a large scale, >>> the results could prove to be useful in the development of policies >>> outside of the IETF that would permit broader deployment". >> >> "[D]evelopment of policies outside of the IETF" strikes me as a little odd >> since IETF isn't setting policy *per se*, although substitute language that >> is just as succinct is escaping me at the moment. > > .... removal of constraints ... ??? > > "As of the writing of this document operational and policy constraints prevent > this experiment from being deployed globally. If the experiment shows that PSD > solves a real problem and can be used at a large scale, the results could > prove to be useful in the removal of constraints outside of the IETF that > would permit broader deployment". > > Better? I reply here to the other thread,[*] where you said "Some can, some can't." For the sake of comprehensibility, could that be spelled out a little bit more clearly? For example like so: As of the writing of this document, there are operational and policy constraints which prevent this experiment from being deployed globally. While it is beyond the scope of this document to delve into the details, be it enough to mention that not all PSOs are actually able to publish DMARC records as needed. Those who are able to do so and wish to participate in the experiment should contact DMARC-PSD.org in order to have their PSD enlisted. If the experiment shows that DMARC-PSD solves a real problem and can be used at a large scale, the results could prove to be useful in removing those constraints, so as to permit broader deployment. Best Ale -- [*] Archived-At: From nobody Sun Jul 14 03:19:58 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 8ED1D1200F4 for ; Sun, 14 Jul 2019 03:19:56 -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 uA0lPpGMKvAU for ; Sun, 14 Jul 2019 03:19:55 -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 30FA81200E5 for ; Sun, 14 Jul 2019 03:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563099593; bh=ffJWAe78xm7Dw+7WkJ6fUPH/LB2J7B6jH9N3Wjjekq0=; l=2383; h=To:References:From:Date:In-Reply-To; b=DKpj3c7a7KR7yWJzAvdWYQJx/UtugbIFrDLyeJdpGs1jJSMuuxB/xY/+B09WJmfHH AEkm5T5Kso/KfMAUNC9zmfKwHt3PbnCtCx1IJjBZQG0fhrGtYLiOSGq9qb9gOFY0jI zd+ddQI7oedlJaE4rcRCVHzqqEpotryaZfKKRegS7LaM+Ny89/0w2IMzUxzJ3 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.9.184]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC050.000000005D2B01C8.000046E9; Sun, 14 Jul 2019 12:19:52 +0200 To: dmarc@ietf.org References: <1851683.DtEN5jD5Wj@l5580> <1834844.gVztEOuzS9@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <7d6e1a79-2de1-fbdd-d4e1-295681afeeac@tana.it> Date: Sun, 14 Jul 2019 12:19:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1834844.gVztEOuzS9@l5580> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 14 Jul 2019 10:19:57 -0000 On Sat 13/Jul/2019 21:06:00 +0200 Scott Kitterman wrote: > On Saturday, July 13, 2019 1:22:15 PM EDT Alessandro Vesely wrote: >> On Fri 12/Jul/2019 19:30:35 +0200 Scott Kitterman wrote: >>> On Thursday, July 11, 2019 6:07:50 AM EDT Alessandro Vesely wrote: >>>> >>>> Appendix B.1 lacks a criterion to establish enlisting. Couldn't we >>>> require an explicit statement about seizing DMARC reports in, say, the >>>> delegation report? Alternatively, that policy can be stated in a >>>> well-known place under the delegation services URL, so that >>>> registrants know what they do. >>> >>> It's in the appendix because we don't have a clear path forward. This is >>> part of the experiment. We need to be careful though since different >>> PSDs operate under different authorities and controls, so there is a >>> point beyond which it's not the IETF that decides. >> >> I hypothesized that all what is needed to gran enlistment to a >> PSO is that its policy to seize DMARC at PSD level be published, >> so that registrant can learn about is before registering. Is >> that correct? I mean does a public statement suffice?>> > > In my view the challenge around which PSDs receivers should check for a PSD > DMARC record needs to be external to the PSD (i.e. not a self-assertion). Agreed. However, even if it were written in the delegation record at IANA, it would still have to have been initiated by the PSO. So the requirement is a sort of validated/ agreed upon self-assertion. > Some options are presented in Appendix A. If, as a result of the experiment, > it's concluded that self-assertion is acceptable, then all that's needed is to > publish the record. I don't think we need a second place to look up to tell > receivers to do the record lookup. >From an implementer's POV, having a short list to complement the PSL, to be updated not very often, sounds convenient. For the algorithm, a few extra string comparisons are still quicker than one more DNS lookup. In addition, the organization who publishes that list qualifies as an authority for monitoring those self-assertions. It can tell when a PSO first published its policy, and hence which registrants could have operated their 2nd or 3rd level domain without being aware of that. If it's important to preserve mail site operators' rights, that is. Best Ale -- From nobody Sun Jul 14 08:51: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 D75A212003F for ; Sun, 14 Jul 2019 08:51:55 -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 5Lg2sqGh3FGH for ; Sun, 14 Jul 2019 08:51:53 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63739120026 for ; Sun, 14 Jul 2019 08:51:53 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id v186so10858790oie.5 for ; Sun, 14 Jul 2019 08:51:53 -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; bh=ejAeMpXWRm3j+APjC4oW56V26bgVulM1N0sZOxf8Zuk=; b=DnQffwhM6NaHUHu4vpJp8Uu/eAUVSO+CU/uLC5TbytKKrnt/1FLtV65fD+Q2G53YX9 nQIUbAjkgl9jxL+I10GZbZSDGmkIzClIhl2in3IWipjv9cGWkP43Fl9FSqS2P7xdrMoX yp6fR/63IeCf4yeBjpI6q2JBru963eq5NxLlanxfqpc3UCeHKWTpTvel43f/G6Q3EGRJ dP1xhLAn0b1JEPOOnWK8BKEHoxPGsW4NJZsLWXarvA+GcrqQuU1p7AjAWkns3JRwedFK BjZ+ijzLYUlzBwvRHIEwQm79IZR2OLCyg5HfhixK9cVWAr5gROzSd6QbX8OPGz18NCh+ ZQGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ejAeMpXWRm3j+APjC4oW56V26bgVulM1N0sZOxf8Zuk=; b=T6JxL912pOAmubhcK1OyzbiR1s1ebypHyx/81I/UBuVmKALynwHCVEAM5lifLH29Go hJThq2FUgEryMVNugY7oKohzb8myXc+hpNgt07hKTcxcaKWAkoZrZnqwScj+fEgu/KzZ 7T7EycFI+n5OJlOBk0Kks2jORUAk66Pbic94/rsF0Ta1GGJbNmWtyDQ5tF57zXOxML/V ca+EbHd9hNiE3Zbjqb4GlySJ3rLuxwj1v6Lan6kQjmudwxTJWHd6HXFm7C4ZHZqG/SZm 0QHkk0nNz3fJ5joshUtmCAhsKTlxyusgr1LX0UuPEcD5QDhdqEPw9aQErCy/cqb8+0ZN 11yw== X-Gm-Message-State: APjAAAVL05ADOPPZu7aQt4R5TCv+jU5J+v5O4pbQZfx8nQY0XJ32RCcd EeRtXkpICsyxPKttCP2HKgTDX75mgZbPl6kQhmQ17Q== X-Google-Smtp-Source: APXvYqx5Az224EwsWC2RQpgk1t3od5kJoMXFiOI+PREwsavAFNIleQZKwT+9GjJjkYLTBg6QD2DtcK4anukskanVX+g= X-Received: by 2002:aca:b406:: with SMTP id d6mr10847706oif.173.1563119512347; Sun, 14 Jul 2019 08:51:52 -0700 (PDT) MIME-Version: 1.0 References: <1783751.gHVjF1RMII@l5580> <53901c28-8542-40a0-87c1-a11e935e6afd@www.fastmail.com> <12139607.XScsT9yxuP@l5580> <672143c9-f0e3-de1a-1c91-a223965554c8@tana.it> In-Reply-To: <672143c9-f0e3-de1a-1c91-a223965554c8@tana.it> From: Tim Wicinski Date: Sun, 14 Jul 2019 11:51:40 -0400 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004669a8058da61f4a" Archived-At: Subject: Re: [dmarc-ietf] Mention ICANN/operational limitations was: Re: Working Group Last Call: 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, 14 Jul 2019 15:51:56 -0000 --0000000000004669a8058da61f4a Content-Type: text/plain; charset="UTF-8" I'm good with either of Scott's wordings on this. I guess I'm making an assumption that the TLD operators know what they can and can't do (but that may be a horrible assumption). Tim (no hats) On Sun, Jul 14, 2019 at 6:13 AM Alessandro Vesely wrote: > On Fri 12/Jul/2019 20:27:05 +0200 Scott Kitterman wrote: > > On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote: > >> On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote: > >>> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > >>>> As Secretary, there are three items that have not yet reached > consensus > >>>> that must be resolved during WGLC: > >>>> > >>>> 2. If explicit call outs to ICANN/limited operator capacity to > implement > >>>> are needed > >>> > >>> There has been feedback in favor of adding this and none against so > far. > >>> > >>> The specific proposal is: > >>> > >>> "Please note that today's operational and policy reality prevents this > >>> experiment from being deployed globally. If the experiment shows that > PSD > >>> solves a real problem at a large scale, the results could prove to be > >>> useful in the development of policies outside of the IETF that would > >>> permit its ubiquitous deployment." > >>> > >>> Because RFCs are (approximately) forever, I'm concerned about words > like > >>> "today's" in protocol documents, even experimental ones. > >>> > >>> How about this instead: > >>> > >>> "As of the writing of this document operational and policy constraints > >>> prevent this experiment from being deployed globally. If the experiment > >>> shows that PSD solves a real problem and can be used at a large scale, > >>> the results could prove to be useful in the development of policies > >>> outside of the IETF that would permit broader deployment". > >> > >> "[D]evelopment of policies outside of the IETF" strikes me as a little > odd > >> since IETF isn't setting policy *per se*, although substitute language > that > >> is just as succinct is escaping me at the moment. > > > > .... removal of constraints ... ??? > > > > "As of the writing of this document operational and policy constraints > prevent > > this experiment from being deployed globally. If the experiment shows > that PSD > > solves a real problem and can be used at a large scale, the results > could > > prove to be useful in the removal of constraints outside of the IETF > that > > would permit broader deployment". > > > > Better? > > > I reply here to the other thread,[*] where you said "Some can, some > can't." For the sake of comprehensibility, could that be spelled out a > little bit more clearly? For example like so: > > As of the writing of this document, there are operational > and policy constraints which prevent this experiment from > being deployed globally. While it is beyond the scope of > this document to delve into the details, be it enough to > mention that not all PSOs are actually able to publish > DMARC records as needed. Those who are able to do so and > wish to participate in the experiment should contact > DMARC-PSD.org in order to have their PSD enlisted. If the > experiment shows that DMARC-PSD solves a real problem and > can be used at a large scale, the results could prove to > be useful in removing those constraints, so as to permit > broader deployment. > > > Best > Ale > -- > > [*] Archived-At: < > https://mailarchive.ietf.org/arch/msg/dmarc/_WjDZj17qySDLcIWlcCIan54s0A> > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004669a8058da61f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm good with either of Scott's wor= dings on this.=C2=A0

I guess I'm making an assumptio= n that the TLD operators know what they can and can't do
(but= that may be a horrible assumption).=C2=A0

Tim
(no hats)


On S= un, Jul 14, 2019 at 6:13 AM Alessandro Vesely <vesely@tana.it> wrote:
On Fri 12/= Jul/2019 20:27:05 +0200 Scott Kitterman wrote:
> On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote:
>> On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote:
>>> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: >>>> As Secretary, there are three items that have not yet reac= hed consensus
>>>> that must be resolved during WGLC:
>>>>
>>>> 2. If explicit call outs to ICANN/limited operator capacit= y to implement
>>>> are needed
>>>
>>> There has been feedback in favor of adding this and none again= st so far.
>>>
>>> The specific proposal is:
>>>
>>> "Please note that today's operational and policy real= ity prevents this
>>> experiment from being deployed globally. If the experiment sho= ws that PSD
>>> solves a real problem at a large scale, the results could prov= e to be
>>> useful in the development of policies outside of the IETF that= would
>>> permit its ubiquitous deployment."
>>>
>>> Because RFCs are (approximately) forever, I'm concerned ab= out words like
>>> "today's" in protocol documents, even experiment= al ones.
>>>
>>> How about this instead:
>>>
>>> "As of the writing of this document operational and polic= y constraints
>>> prevent this experiment from being deployed globally. If the e= xperiment
>>> shows that PSD solves a real problem and can be used at a larg= e scale,
>>> the results could prove to be useful in the development of pol= icies
>>> outside of the IETF that would permit broader deployment"= .
>>
>> "[D]evelopment of policies outside of the IETF" strikes = me as a little odd
>> since IETF isn't setting policy *per se*, although substitute = language that
>> is just as succinct is escaping me at the moment.
>
> .... removal of constraints ... ???
>
> "As of the writing of this document operational and policy constr= aints prevent
> this experiment from being deployed globally. If the experiment shows = that PSD
> solves a real problem and can be used at a large scale, the results co= uld
> prove to be useful in the removal of constraints outside of the IETF t= hat
> would permit broader deployment".
>
> Better?


I reply here to the other thread,[*] where you said "Some can, some ca= n't."=C2=A0 For the sake of comprehensibility, could that be spell= ed out a little bit more clearly?=C2=A0 For example like so:

=C2=A0 =C2=A0 As of the writing of this document, there are operational
=C2=A0 =C2=A0 and policy constraints which prevent this experiment from
=C2=A0 =C2=A0 being deployed globally.=C2=A0 While it is beyond the scope o= f
=C2=A0 =C2=A0 this document to delve into the details,=C2=A0 be it enough t= o
=C2=A0 =C2=A0 mention that not all PSOs are actually able to publish
=C2=A0 =C2=A0 DMARC records as needed.=C2=A0 Those who are able to do so an= d
=C2=A0 =C2=A0 wish to participate in the experiment should contact
=C2=A0 =C2=A0 DMARC-PSD.org in order to have their PSD enlisted.=C2=A0 If t= he
=C2=A0 =C2=A0 experiment shows that DMARC-PSD solves a real problem and
=C2=A0 =C2=A0 can be used at a large scale, the results could prove to
=C2=A0 =C2=A0 be useful in removing those constraints, so as to permit
=C2=A0 =C2=A0 broader deployment.


Best
Ale
--

[*] Archived-At: <https://= mailarchive.ietf.org/arch/msg/dmarc/_WjDZj17qySDLcIWlcCIan54s0A>













_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000004669a8058da61f4a-- From nobody Mon Jul 15 00:08:10 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 C1CC21200B8 for ; Mon, 15 Jul 2019 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-bBx9r0ZRAA for ; Mon, 15 Jul 2019 00:08:06 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110122.outbound.protection.outlook.com [40.107.11.122]) (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 8E77712001E for ; Mon, 15 Jul 2019 00:08:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JCEDKXF8HQfoz03FOgDQqGr9fKrls8qyMZKJAfTlh+bM6RT2d/iE6Evd2knCmAoZuzlp9MNP136OrgqlnchA0G+/A/tm5u4c4Mfqt1Vn9tXj2mkm38pp0peLqxVtDADwzFmaVAAq5BSQPo7EDAFsb5ga7yjQCoA0paxojc3f/rxdt4KQ0pCIULpaefvNfi1jHOxstp5FrnhxLZup7WSyZMKYzjIG828ZcNB4DLSeQTMEzvSgF0EsVg6Si1xBCs3c8+cv33gHqyNhL4ETiEdPrC+fOwxxxLfoHJ/Vi0C2upisWPnRA97iXoLaSquQRBQ4IZHN3OuSP2SiuQ88eUtgkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FNcaRaUdxOIctmu/SDpsci6lTWunneJ5rcL7Ire4Xzk=; b=EFWozfirH6m7OouyC1Y4B6Z64Z+XIZXjSOTMoDAXXlvnbxD5kF2hSfqjI0iaGnbhbHxzgl+deQO3vekui1jIoh9TTdg4aFvKTIO80QPv8g+6wsqY7pKU4EL20NALucSnPmZVrPE/Nu2zH/8g4H8RwX+VxV+MZdbaFZvWaIGfEx1VfQJMED1GmUtJJtjh378osI2WvaYmShYlIaZKFhQx92r7YwaAdcFQKWwTXJlpV+Hz0ifWl8xU0mHG8pom+jUQ/RoK717KEihJS+IIvlMkB1NUCVyeynsCCn3yot2cdQPxjnyHQazX4u7tHCjBd44ODGZjP0U18g4qtWZUnh/JOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FNcaRaUdxOIctmu/SDpsci6lTWunneJ5rcL7Ire4Xzk=; b=Y2k0jd5YtdaSjKn+bNvDDROJGWxVUlCdjYnDN45kUmW57MmafOnL4ZWWsmD89UNpp6CDNnJZNQI20K5kbxk7aBeIXJ2peY60y7BIbaDX6P/UTAeDxbceQ0E0w4jDFwztYg89npNz0URYR84G8tU430OMTNmCLWz4F60JPWaGjaw= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2030.GBRP123.PROD.OUTLOOK.COM (20.176.157.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 07:08:04 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 07:08:04 +0000 From: Ian Levy To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAF1oCAABAxAIAAFoEAgACGD4CAABkfAIACPhxA Date: Mon, 15 Jul 2019 07:08:04 +0000 Message-ID: References: <20190713043409.A5EB64A61C0@ary.local> <3017917.gKNyNSpcLf@l5580> In-Reply-To: <3017917.gKNyNSpcLf@l5580> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a852776-87d7-4a90-f4c5-08d708f32e4d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2030; x-ms-traffictypediagnostic: LO2P123MB2030: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(346002)(39840400004)(366004)(136003)(376002)(13464003)(189003)(199004)(229853002)(25786009)(14454004)(68736007)(2906002)(446003)(186003)(3846002)(6116002)(11346002)(6436002)(9686003)(6306002)(55016002)(26005)(45080400002)(478600001)(33656002)(2501003)(8936002)(14444005)(44832011)(256004)(966005)(8676002)(486006)(81156014)(81166006)(76116006)(66946007)(5660300002)(66476007)(66556008)(64756008)(66446008)(305945005)(66066001)(74316002)(7736002)(476003)(71200400001)(52536014)(71190400001)(76176011)(110136005)(6246003)(316002)(53546011)(7696005)(86362001)(53936002)(55236004)(6506007)(99286004)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2030; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fuw1FgvioVWsXGSV1v1C5iwFDC+M/sCs1dHJVrt/BCiLitgSqoDWl+xoqH1Mi3+kZHfM/QiWnfZIEMa6NoOsarteovX9SdJERBuCE8UO3YAuyxjaHNY6EqOnoNU2nYGHa1NSd7q2ZHI2P+CTkHFBkKx+HbuNStt3KtfwHWMZJeMKJaXSTwmWukg5U11r1GR6cQz/aguw6ohVJN2qQx8+ozyapvEW8I1U57SZKnB97WR7mTDiamB8EBN6YN6fqyQocFuIPUQ4l3IqTaIBWHN6rv5DD6DxmvRsUGnCbxMmHbIGwA7zXOl9M0HyV6YRjUxtsMkjWZCQMd1uNwNp9Bnk+gnI8AMjyIlWbVIxeqrsu4O4L6BpHSHKj15jcC19WElJcSeBnzPBa1obr6NdDZol4s5OLypuZkjP6l98TTLTi7k= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 0a852776-87d7-4a90-f4c5-08d708f32e4d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 07:08:04.2480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2030 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 15 Jul 2019 07:08:10 -0000 Sorry for not contributing more to this thread - please don't take it as an= y indication of lack of interest. For UK NCSC specifically, I think we'd pr= efer NXDOMAIN rather than NODATA, given it's more constrained and this is a= n experiment. My view would be that if we've published a name under gov.uk,= even with no valid (in the eyes of the receiver) associated records, then = *someone* is responsible for it and we can go find and educate them. They m= ay even believe they have a valid reason for doing so that may outweigh any= email authentication concerns. But there's a conversation to be had. If th= ere's no published name, then there's no-one responsible, so it should defa= ult to the top-level policy.=20 =20 We've learned a lot running our DMARC processing for gov.uk over the last c= ouple of years and a lot about the consistency of how non-existent domains = are treated, or lack thereof more to the point. If I'm honest, we see a lot= of inconsistency in how DMARC is processed more generally that makes analy= sis harder than it needs to be. A lot of receivers have obviously made opti= mizations for their own specific circumstances. I'm just a little nervous o= f starting an experiment on a live and (some may argue) quite important PSD= in anything other than a constrained manner.=20 Incidentally, we *should* be publishing on ncsc.gov.uk our 2nd annual repor= t on our Active Cyber Defence programme tomorrow (Tuesday). This includes a= chapter on our DMARC experiences, including a bit of data relevant to this= discussion, as well as some novel data science work on our DMARC report ar= chive. As a preview, from July when we set the 'synthetic DMARC' record to = p=3Dreject, we've had this many reports :=20 Month (2018) Total reports July 5,764 August 274,532=20 September 127,901=20 October 17,553=20 November 17,191=20 December 105,078=20 We'll also publish a couple of examples of where synthesizing DMARC/SPF rec= ords for non-existent domains has helped stop abuse. However, it's clear th= at this method isn't universally accepted.=20 Here's the volume of reports received on our normal DMARC processing chain = in January 2019 (noting Microsoft are one of the bigger providers in the UK= and *still* don't generate any reports):=20 Reporter Total Reports=20 google.com 61,363,605=20 Yahoo! Inc. 18,876,201=20 Mail.Ru 699,554=20 sercoglobal.com 227,587=20 AMAZON-SES 178,262 And here's the volume for the same month for the synthetic DMARC reports := =20 Reporter Total Reports=20 google.com 23,745=20 Yahoo! Inc. 1,060=20 emailsrvr.com 64=20 dev.johnlewis.co.uk 37=20 bridgend.gov.uk 30 Just from that, it's pretty clear that the synthesized DMARC records are no= t universally processed, which gives weight to completing this work and sta= rting to try things out. Given the level of inconsistency we see in receive= r behaviour, I think it'd be easier to start with NXDOMAIN and see what tha= t actually achieves.=20 I may well be missing something subtle, so please correct me if I've got th= is wrong.=20 Ta. I. =20 -- Dr Ian Levy Technical Director National Cyber Security Centre ian@ncsc.gov.uk Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If th= is arrives outside your normal working hours, don't feel compelled to respo= nd immediately!) -----Original Message----- From: dmarc On Behalf Of Scott Kitterman Sent: 13 July 2019 07:04 To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group = Last Call: draft-ietf-dmarc-psd On Saturday, July 13, 2019 12:34:09 AM EDT John Levine wrote: > In article <2902055.CzhLQO0xIX@l5580> you write: > >Here's the definition we have in the draft now: > >> 2.6. Non-existent Domains > >> > >> For DMARC [RFC7489] purposes, a non-existent domain is a domain nam= e > >> that publishes none of A, AAAA, or MX records that the receiver is > >> willing to accept. This is a broader definition than that in > >> NXDOMAIN [RFC8020]. > > > >That's what I was expecting this new tag to apply to (and I think=20 > >matches their expectation, but they can speak for themselves). > > That's OK. > > >Another way to say what's in 2.6 now might be: > > > >... a domain for which there is a NODATA response for A, AAAA, and MX=20 > >records. > Not so OK -- if there's no records at all at or below a name you=20 > really will get NXDOMAIN. Good point. Thanks. I'll leave it as is. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Cian.levy%40ncsc.gov= .uk%7C347777d406d8456ee39d08d70758084b%7C14aa5744ece1474ea2d734f46dda64a1%7= C0%7C0%7C636985946991033447&sdata=3DS1HHVXL4ftxSYbFhTgxx1pXVcOT2o0S1PM%= 2B7sUCL9eo%3D&reserved=3D0 This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk From nobody Mon Jul 15 05:30: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 76221120112 for ; Mon, 15 Jul 2019 05:30: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml-xk9g8_9_8 for ; Mon, 15 Jul 2019 05:30:47 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A891200F4 for ; Mon, 15 Jul 2019 05:30:47 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id a127so12477519oii.2 for ; Mon, 15 Jul 2019 05:30:47 -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=cHfVSiT0ADyX6T2hi4wqmpEZLC3/Yd0afVlwAj9u6/0=; b=VUEE91zGdeOiTHJNf6dQGuIo8iaHtgVTqaVsGFYpmmtSSqs+Q8Zi/d8CVlkt0nqBPi 3rSBxXxQNx+/UfIEo4JSLwXAf0l7YFiiJ4whzQ3y8drF398LuVtgjQ33bfgucFERlFIZ zr7MNLvWJo6+pI52v+GjUPLkFI8TcsckJfPbRhFAZlQtPRiG/Fr55y8FXZ1Acq3uBY4T AsaJUDwxGOIggezyL301vVfvx0N5ct+TJMarg6RNEATfbJ4HYMIFyZ/10IV16nIWCMoo UMZ+1+bKPb0M16CqbBb74nTOv7aSvpSAz2BwyvC1FG7rSZbdWQxgY8gt23zwRQ7QTCoH wv4A== 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=cHfVSiT0ADyX6T2hi4wqmpEZLC3/Yd0afVlwAj9u6/0=; b=F5ZLFzANi/iVkwZ6KHhP0n637cI23cSGAgEA26D446dBJ/Sb2elJMVdP+tSoyWejEj ei/6xF2M8ayE9dq/5XOiLEJ8RHzLKuPdPL6Ap8gbNKLeHb/WJ7sQqXMk2oH9G92JT/OR WNbGLby4+kGI2H58KRHkileCaAYXf76uQ7CwUyb4M5RH9YV8S62xJtEoc72nkSuhycSh BDVF+ZZXdrX4kMjXfVX8DPOivoV508ieXzjh8ZpNlV+gXxHdlLVRFa544x6+b1L6fP1p rt71MdhvuYIFAwiZmVT8JsQuf3z3G4Ltxp1GcS6haCud1yVSUTmOh1rp0ez8hB7oujwo aGxQ== X-Gm-Message-State: APjAAAUe9aGn1wdhUNcZLoBZAfWeRiq7fokGLV/nCtYiHr4sdloIld6O u4LRugksmtDN789dqge2gdRRRX1q8r2wKQO6FtJTlW8z X-Google-Smtp-Source: APXvYqzqr6V0PG5QHXK87zf9ThmxlSKDH+Fo8v1JpZ22vWYzlOFsKIwpX6nLIFCcEPNB0PRBCTE/75dC93WP/t1wO+w= X-Received: by 2002:aca:4255:: with SMTP id p82mr13264537oia.6.1563193846721; Mon, 15 Jul 2019 05:30:46 -0700 (PDT) MIME-Version: 1.0 References: <1893230.9INSBCnb99@l5580> <1958020.28HeBAo97T@l5580> In-Reply-To: <1958020.28HeBAo97T@l5580> From: Tim Wicinski Date: Mon, 15 Jul 2019 08:30:35 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f2f10c058db76d0b" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 15 Jul 2019 12:30:50 -0000 --000000000000f2f10c058db76d0b Content-Type: text/plain; charset="UTF-8" I totally agree with the logic behind the experiment. >From a document point of view, should we not document the 'np' part of the experiment? "The experiment will also evaluate the effectiveness of the 'np' tag for non-existent subdomains. " Tim On Fri, Jul 12, 2019 at 2:28 PM Scott Kitterman wrote: > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > > > wrote: > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > 3. If an np= tag is needed to allow PSD functioning for only > NXDOMAINs > > > > > > The limited feedback during WGLC has been favorable to this. > > > > > > This will require a rather larger change to the document than the other > > > issues, but they are manageable and I believe I have most of the > relevant > > > text > > > from earlier revisions. > > > > > > I think we should include this. > > > > I am much more concerned with adding another tag that can only be used > in a > > PSD-DMARC record. I would be much more open to make a "normative" change > to > > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > > record, than to make this a special case for PSD-DMARC records. > > I agree. My intent is to add the tag to be used experimentally for any > DMARC > record. Part of the experiment is to see if it's useful beyond PSD. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f2f10c058db76d0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I totally agree with the logic behind the experim= ent.=C2=A0

From a document point of view, should w= e not document the 'np' part of the experiment?

"The experiment will also evaluate the effectiveness of the '= ;np' tag for non-existent subdomains. "

T= im



=
On Fri, Jul 12, 2019 at 2:28 PM Scott= Kitterman <sklist@kitterman.com= > wrote:
On Friday, July 12, 2019 1:54:57 = PM EDT Kurt Andersen (b) wrote:
> On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> > > 3. If an np=3D tag is needed to allow PSD functioning for on= ly NXDOMAINs
> >
> > The limited feedback during WGLC has been favorable to this.
> >
> > This will require a rather larger change to the document than the= other
> > issues, but they are manageable and I believe I have most of the = relevant
> > text
> > from earlier revisions.
> >
> > I think we should include this.
>
> I am much more concerned with adding another tag that can only be used= in a
> PSD-DMARC record. I would be much more open to make a "normative&= quot; change to
> the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC<= br> > record, than to make this a special case for PSD-DMARC records.

I agree.=C2=A0 My intent is to add the tag to be used experimentally for an= y DMARC
record.=C2=A0 Part of the experiment is to see if it's useful beyond PS= D.

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f2f10c058db76d0b-- From nobody Mon Jul 15 09:24:49 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 53772120176 for ; Mon, 15 Jul 2019 09:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ftld.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X6GXkjtJTeB for ; Mon, 15 Jul 2019 09:24:43 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDC412011C for ; Mon, 15 Jul 2019 09:24:42 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id 190so11773950vsf.9 for ; Mon, 15 Jul 2019 09:24:42 -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=lTb4lYYwZBeNP2hTXPM3xUM7P+s4CzHc3a03+6an8UE=; b=eIA0kYZME3qMASJA/jVwnaWURLLBRhcWuzQ1sIZN4dbDKcElFLb1QZePLCItOW0KZX dTj0ekX6C7il+VjT6cZ0WSowukhklg7nyYtgGMkdtIWzhteoV2K/VrmalbHoWUooHc+A UQyoxnGHKvr2aANLTXvrfs8zkmDzppgsJxcOE= 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=lTb4lYYwZBeNP2hTXPM3xUM7P+s4CzHc3a03+6an8UE=; b=H3AwfGJMA7bDSZ18c7POaONnPbgcUuzf+9hDfNRqrkvPvQeACPtGLI2iTLvGTt65Lm 3Y+5Mcay66yXndDw5lASzb/yibPg6BEMusqLrblLk5g0a5lcY+B782+nwkltAcFfECNb JaIhXya4+1PLjLzOdO9kj9rGU1JNGAHEE+pc+vRYGvHBYJE2JaWLPT5uw8uRXRMTovjV VwGImRkxEBesWXhO62YvcvVcn1NarMh7if1KLlBQAtGjwADQjl6Gsre20D4o/UcMc4Rg 7BbyZAgGUE4k25adYHcSwUtsmch7jMjF04bzY4ZT/i0UpswRiNoe8waYpWbJ8cE8TAg6 MSlg== X-Gm-Message-State: APjAAAWZ7TbtNGm8Ic0Fmls+5xNbopvnCvdh6m+kgEbIAtTDwUTkDq7k iO483vUaP6mMDZlxKiPd5QaSMWqTwcONjzar1A+JRljgfrE= X-Google-Smtp-Source: APXvYqwAeZ/EN9g8gSVG7syer+xMTXN8zCu2lNMjHxJE7hOX73BPovjJgKtFQghII7ibARuj+gvyS/xA/Xd0Zy9oREI= X-Received: by 2002:a67:f941:: with SMTP id u1mr10434750vsq.60.1563207881463; Mon, 15 Jul 2019 09:24:41 -0700 (PDT) MIME-Version: 1.0 From: Craig Schwartz Date: Mon, 15 Jul 2019 12:24:29 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="0000000000007c3c44058dbab2e7" Archived-At: Subject: [dmarc-ietf] Working Group Last Call: 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, 15 Jul 2019 16:24:45 -0000 --0000000000007c3c44058dbab2e7 Content-Type: text/plain; charset="UTF-8" On behalf of fTLD Registry Services (fTLD), Registry Operator (RO) of the .BANK and .INSURANCE gTLDs, I am grateful for the work Scott Kitterman has done for us with draft-ietf-dmarc-psd and others who have worked diligently to advance this effort. fTLD started discussing DMARC for gTLDs/PSDs with an internal working group in June 2018, which led to the publication of the first Internet-Draft (ID) in October 2018. We continue to meet regularly to evolve the ID inclusive of comments and concerns raised by members of the IETF DMARC Working Group. As the RO for two of the most trusted and secure gTLDs on the Internet, we have and continue to explore ways to enhance security for registrants using .BANK and .INSURANCE and the consumers they serve. Prior to the launch of our TLDs in 2015 and 2016 respectively, we specified several Security Requirements, accessible at https://www.ftld.com/security/, that must be implemented for domains in our zones inclusive of Email Authentication (i.e., DMARC plus SPF and/or DKIM (though we advocate both). fTLD regularly monitors for compliance with all requirements and takes enforcement action when necessary. fTLD began our exploratory work more than a year ago and believe DMARC for PSDs will provide a variety of benefits including, but not limited to: - Threat intelligence into sources of abuse; - Protection for NXDOMAINs against nefarious e-mail borne activities; - Brand protection; and - Compliance enforcement for PSDs that have policy control for their zone(s). We appreciate that for PSDs under contract with ICANN there is currently a prohibition of the activity presented in the ID. Notwithstanding this, there are other types of PSDs (e.g., country-code Top-Level Domains (ccTLDs), TLDs not governed by ICANN contract (e.g., .MIL, .GOV, .EDU)) that can experiment with DMARC for PSDs. When the IETF work is sufficiently advanced, fTLD anticipates pursuing permission from ICANN to implement DMARC at the TLD level as soon as practicable. Sincerely, Craig *--* Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Office: +1 202 589 2532 Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com --0000000000007c3c44058dbab2e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On behalf of fTLD Registry Services (fTLD), Registry Ope= rator (RO) of the .BANK and .INSURANCE gTLDs, I am grateful for the work Scott Kitterman has done for us with draft-ietf-dmarc-psd and others who have wor= ked diligently to advance this effort. =C2=A0fTLD started discussing DMARC for gTLDs/PSDs with an internal working group in J= une 2018, which led to the publication of the first Internet-Draft (ID) in Octo= ber 2018. We continue to meet regularly to evolve the ID inclusive of comments = and concerns raised by members of the IETF DMARC Working Group.

=C2=A0

As the RO for two of the most trusted and secure = gTLDs on the Internet, we have and continue to explore ways to enhance security for = registrants using .BANK and .INSURANCE and the consumers they serve. Prior = to the launch of our TLDs in 2015 and 2016 respectively, we specified several Security Requirements, accessible at https://www.ftld.com/security/, that must be implemented for domains in our zones inclusive of Email Authen= tication (i.e., DMARC plus SPF and/or DKIM (though we advocate both). fTLD regularly= monitors for compliance with all requirements and takes enforcement action when necessary.

=C2=A0

fTLD began our exploratory work more than a year = ago and believe DMARC for PSDs will provide a variety of benefits including, but not limite= d to:

- Threat intelligence i= nto sources of abuse;

- Pro= tection for NXDOMAINs against nefarious e-mail borne activities;

- Brand p= rotection; and

- Compliance= enforcement for PSDs that have policy control for their zone(s).

=C2=A0

We appreciate that for PSDs under contract with I= CANN there is currently a prohibition of the activity presented in the ID. Notwi= thstanding this, there are other types of PSDs (e.g., country-code Top-Level Domains (= ccTLDs), TLDs not governed by ICANN contract (e.g., .MIL, .GOV, .EDU)) that can expe= riment with DMARC for PSDs. When the IETF work is sufficiently advanced, fTLD anticipates pursuing permission from ICANN to implement DMARC at the TLD le= vel as soon as practicable.=C2=A0


Sincerely,=

Craig

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

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




<= /div>
--0000000000007c3c44058dbab2e7-- From nobody Tue Jul 16 01:20:18 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 0F99E120182 for ; Tue, 16 Jul 2019 01:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIoz3EsmsreR for ; Tue, 16 Jul 2019 01:20:14 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100119.outbound.protection.outlook.com [40.107.10.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69FB120086 for ; Tue, 16 Jul 2019 01:20:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZcCz0DrntzR9W/1Ma0EFagLWo7cvplYd+eqLVFGbJceXk+Xgat21xUZ7imQCGCveQaXhDUxnQpHWv8yhZM4U/j+X6oxSmnUwTv0vwIcLBIkUHiREu4pBh0zaaeoKVvGPr+jWLZ2sBDtGqJgzP14TFNRfHLwkWt+3hZ3CYaw4MwSut67ApfItewknUFbNoMp3PqTsqTlfAIrPKp+6X8RzUHYhRn4bgo/HzW1kpJzRsiE7S6suyI1lYuc3VOaBl9VxdWgq+aM7498enNH6r1zDCh1qO3h310RNu5NbTcGGTW1uUQzu24WN1HXzpBa+Fvyq3irolG/cVPl85fRJB9TrNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vaKIbAQ6yVSKztdkW3GF1rH0vw9AdWjTWaHsDTK+mYw=; b=QlUoUZJJppkadyujNT19RliS9pEEPXi8X6z0CHvdyvdGweE1Noi5kfhqDmIN23iZ7mumQgJB2LnNH44xZTPGdYB5i9vElifH2iD9D9atz8jePuFcmwtKpjqUaFHGXPibXLv8uUUN2v2tA4bZH39UfJmyH8HpzP5AJzutdTGmsyFwLAAcwl0E0fNBMpAUWlZXKhUDusYMTI3JmDmyhbZC1fQDwPGQh2MRW1Yc57V1loQ9WskV/22e8F2lf4BK9u3GMTep4AocM3agw04jX1l4477sMNsKDEM3tZd313StuD2GSGd2GSIV0a5Om3Sa/Ae6T8NhvtMgKLGg+y7kcEtiIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vaKIbAQ6yVSKztdkW3GF1rH0vw9AdWjTWaHsDTK+mYw=; b=DnC8A4In8zKWnU1Vk/FuvUwedXIDBdsdCcKtvjDVQQN4rMMxCAYN3eLaIKC+twIj+aYX3so4I+v2kInw+YmbPNQedFwfLmjd4kWIwJ2+4GuNV5Pp/wDM1sQg4+j+rDC7C58RcelK7CRwYabsSj2vaIG/Sp2EbxfZj/EuseQwj2Q= Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM (20.176.156.23) by LO2P123MB2480.GBRP123.PROD.OUTLOOK.COM (20.176.154.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Tue, 16 Jul 2019 08:20:12 +0000 Received: from LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::ac27:d82f:6587:ed57]) by LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM ([fe80::ac27:d82f:6587:ed57%4]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 08:20:12 +0000 From: Richard C To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONo/C1M9vqX+30Cy04bGzMOWd6bHRCGAgAAJaoCAAaTUgIAD+axA Date: Tue, 16 Jul 2019 08:20:12 +0000 Message-ID: References: <1958020.28HeBAo97T@l5580> <4789054.Ip9ilXyiH0@l5580> In-Reply-To: <4789054.Ip9ilXyiH0@l5580> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Richard.C@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33ce1bff-5e97-4072-246d-08d709c66c8c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2480; x-ms-traffictypediagnostic: LO2P123MB2480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(396003)(346002)(136003)(366004)(39850400004)(199004)(189003)(13464003)(5660300002)(52536014)(66066001)(6116002)(33656002)(5024004)(3846002)(256004)(6916009)(5640700003)(76176011)(2351001)(6436002)(55016002)(561944003)(55236004)(186003)(229853002)(53546011)(26005)(102836004)(6506007)(53936002)(446003)(11346002)(476003)(14454004)(9686003)(6246003)(486006)(305945005)(71200400001)(2906002)(99286004)(71190400001)(7736002)(2501003)(74316002)(25786009)(1730700003)(81166006)(81156014)(86362001)(8936002)(478600001)(76116006)(8676002)(316002)(66446008)(66946007)(64756008)(66556008)(66476007)(7696005)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2480; H:LO2P123MB2334.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QFwA1qth2k1pSAS5kfn5uKdeHYa1IwZyvsyotlsUDyvRseTNQc/3V2iEYXJaJxNNCaiuhQan5Hvc/OAiAw9tOxmg6AUclGy0YV/q3VPW04Ha/QE5nu/e2ZmI1qgn+wJGGjneZcB+3YlxK/Q8wVAojan6JtstqiPulYcTZ0p+gKT/OderZo3yizWd9TDwIXBcLnCtB4Jo3PlMpJVBT8YHsKY5FrCeAVFlIlnhqkBPkdKLti37Z2zd285C8UPFn3Bb+EFPeDLYx27z6SD1nd4a669PRDwb7nNgF9P3ArzVFlpLLt9w/snofJIzu4lSRWVghmfnCUhyZamjZ84DJ6KAZkt8yPHXaPt//kkrGpMJIi5LH0AeIWH3CgdyJHgYy6vYM9Fd4uOWDMRsBVkYcy/NEicZO/ymeb9G4ZlUbjDvaj8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 33ce1bff-5e97-4072-246d-08d709c66c8c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 08:20:12.4263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: richard49955@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2480 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 16 Jul 2019 08:20:17 -0000 I'm happy with the proposal but just wanted to flag that you have a typo fo= r the tag name in section 3.3 - you use 'sp' rather than 'np' Thanks Richard | -----Original Message----- | From: dmarc On Behalf Of Scott Kitterman | Sent: 13 July 2019 20:35 | To: dmarc@ietf.org | Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Grou= p | Last Call: draft-ietf-dmarc-psd | | On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote: | > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: | > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman | > > | > > | > > wrote: | > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: | > > > > 3. If an np=3D tag is needed to allow PSD functioning for only | > > > > NXDOMAINs | > > > | > > > The limited feedback during WGLC has been favorable to this. | > > > | > > > This will require a rather larger change to the document than the | > > > other issues, but they are manageable and I believe I have most of | > > > the relevant text from earlier revisions. | > > > | > > > I think we should include this. | > > | > > I am much more concerned with adding another tag that can only be | > > used in a PSD-DMARC record. I would be much more open to make a | > > "normative" change to the DMARC tag list (RFC 7489 section 11.4) to | > > define np for any DMARC record, than to make this a special case for | > > PSD-DMARC records. | > | > I agree. My intent is to add the tag to be used experimentally for | > any DMARC record. Part of the experiment is to see if it's useful beyo= nd | PSD. | | Attached is my proposed text to add the np tag. Based on the discussion = to | date, I assume I'll be asked to add something like this after last call i= s | complete, so please let me know how to make it better. | | Scott K | This information is exempt under the Freedom of Information Act 2000 (FOI= A) | and may be exempt under other UK information legislation. Refer any FOIA | queries to ncscinfoleg@ncsc.gov.uk This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk From nobody Tue Jul 16 07:53:28 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 9E24B12061C for ; Tue, 16 Jul 2019 07:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Um7-RE-geRqb for ; Tue, 16 Jul 2019 07:53:24 -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 79FD712064D for ; Tue, 16 Jul 2019 07:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563288787; bh=ZBabvkqn06BrLanNkZe6KDhDNtPrCJpuX0CVHMP+nH4=; l=10946; h=To:References:From:Date:In-Reply-To; b=BWe7oiLuHtdeQF2cAACiA9wc4W03uU0SeBusjtj5OvlmowZJYKUn2rFuzn24NQim6 lMV3VSrCN6iAA619detmDQQOATGYDbxd2QYO57KT/ZMHTTZ/HrsNE4niny6om/uDFa VYGVDvSk+Llv8bzKHD5ikuub0ffWBwkBwnDBKsswaP2Jv9QdgZ5Et1TGPskf+ Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.100] ([5.170.10.39]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07B.000000005D2DE4D2.00005C18; Tue, 16 Jul 2019 16:53:06 +0200 To: dmarc@ietf.org References: <20190713043409.A5EB64A61C0@ary.local> <3017917.gKNyNSpcLf@l5580> From: Alessandro Vesely Openpgp: preference=signencrypt Message-ID: <51e6b971-270e-a54f-bfb1-4a5d0ba8a94f@tana.it> Date: Tue, 16 Jul 2019 16:53:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-23576-1563288786-0001-2" In-Reply-To: Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 16 Jul 2019 14:53:27 -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-23576-1563288786-0001-2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote: > Sorry for not contributing more to this thread - please don't take it as any indication of lack of interest. For UK NCSC specifically, I think we'd prefer NXDOMAIN rather than NODATA, given it's more constrained and this is an experiment. My view would be that if we've published a name under gov.uk, even with no valid (in the eyes of the receiver) associated records, then *someone* is responsible for it and we can go find and educate them. They may even believe they have a valid reason for doing so that may outweigh any email authentication concerns. But there's a conversation to be had. If there's no published name, then there's no-one responsible, so it should default to the top-level policy. I agree that np should default to p. The original wording for sp is also simpler than''If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.'' (BTW, mind that "sp" instead of "np" in the new tag's definition.) > [...] > Here's the volume of reports received on our normal DMARC processing chain in January 2019 (noting Microsoft are one of the bigger providers in the UK and *still* don't generate any reports): > > Reporter Total Reports > google.com 61,363,605 > Yahoo! Inc. 18,876,201 > Mail.Ru 699,554 > sercoglobal.com 227,587 > AMAZON-SES 178,262 That is at odds with the order reported by dmarcian: NetEase (163.com, 126.com, yeah.net) Google * Yahoo! Microsoft AOL cisco Systems DHL Comcast * Tencent (qq.com) Mail.ru ... https://dmarc.org/stats/dmarc-reporting/ (That used to be on dmarcian, but couldn't find it any more) > And here's the volume for the same month for the synthetic DMARC reports : > Reporter Total Reports > google.com 23,745 > Yahoo! Inc. 1,060 > emailsrvr.com 64 > dev.johnlewis.co.uk 37 > bridgend.gov.uk 30 > > Just from that, it's pretty clear that the synthesized DMARC records are not universally processed, which gives weight to completing this work and starting to try things out. Given the level of inconsistency we see in receiver behaviour, I think it'd be easier to start with NXDOMAIN and see what that actually achieves. > > I may well be missing something subtle, so please correct me if I've got this wrong. Hmm... Mail.ru reports seem to be missing from non-existing domains. My experience differs slightly. Yesterday I sent a few messages to mail.ru. Five of them from a nonext domain (IP 5.170.8.66), all of which were rejected, two of which were reported in the aggregate report attached. However risible these numbers may sound when compared to yours, it is clear that not all messages are reported. It is possible that some cases of non-existent domain are treated as a short-cut, skipping message registration and DMARC verification altogether, even if the reject always came after DATA... Just mumbling. Considering that most DMARC packages work as mail filters, I'd expect messages filtered out before will never make their way to aggregate reports. Is that a DMARC violation? Best Ale -- --=_north-23576-1563288786-0001-2 Content-Type: message/rfc822; name="Report Domain: tana.it; Submitter: Mail.Ru; Report-ID: 68064799912189070641563148800.eml" Content-Disposition: attachment; filename*0="Report Domain: tana.it; Submitter: Mail.Ru; Report-ID: 68064"; filename*1="799912189070641563148800.eml" Delivered-To: ale-dmarc@tana.it Return-Path: Received: from localhost (localhost [127.0.0.1]) (forwarded by dmarcaggr@tana.it) by wmail.tana.it with local id 00000000005DC079.000000005D2D1259.00005C8C; Tue, 16 Jul 2019 01:55:05 +0200 Delivered-To: dmarcaggr@tana.it Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=corp.mail.ru; dkim=pass (whitelisted) header.i=@corp.mail.ru; dmarc=pass header.from=corp.mail.ru Received-SPF: pass (Address passes the Sender Policy Framework) SPF=HELO; sender=relay4.m.smailru.net; remoteip=217.69.129.140; remotehost=relay4.m.smailru.net; helo=relay4.m.smailru.net; receiver=wmail.tana.it; Received-SPF: pass (Address passes the Sender Policy Framework) SPF=MAILFROM; sender=dmarc_support@corp.mail.ru; remoteip=217.69.129.140; remotehost=relay4.m.smailru.net; helo=relay4.m.smailru.net; receiver=wmail.tana.it; Received: from relay4.m.smailru.net (relay4.m.smailru.net [217.69.129.140]) (TLS: TLSv1.2,256bits,ECDHE-RSA-AES256-GCM-SHA384) by wmail.tana.it with ESMTPS id 00000000005DC073.000000005D2D1259.00005C76; Tue, 16 Jul 2019 01:55:05 +0200 Authentication-Results: wmail.tana.it; dnswl=pass dns.zone=list.dnswl.org policy.ip=127.0.5.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Date:Message-ID:To:From:Subject:MIME-Version:Content-Type; bh=vsfVf4DwdpTifqRPD66uE1EhrM48XbMWi6TSIrw0lJ4=; b=M0ABXb//eJ6FNyyg3RaxutgavNl+mfgw7HRGAQjQ/3SoAe/UMkIlhEIDb7c6XQ9mrxvxiPckd3QyrRjjf8BB0pIlDUI3UCQW1kni8H4lq4HnPDw/4Sz0uC/8BMI2QexLirpEX+agwlpmmZT91WhLU0EkTpb/cULK8qfHCFpjOCY=; Received: from [10.161.4.115] (port=41439 helo=60) by relay4.m.smailru.net with esmtp (envelope-from ) id 1hnAoA-0001aM-TP for dmarcaggr@tana.it; Tue, 16 Jul 2019 02:55:02 +0300 Subject: Report Domain: tana.it; Submitter: Mail.Ru; Report-ID: 68064799912189070641563148800 From: dmarc_support@corp.mail.ru To: dmarcaggr@tana.it Message-ID: Date: Tue, 16 Jul 2019 02:55:02 +0300 Auto-Submitted: auto-generated Old-Authentication-Results: relay4.m.smailru.net; auth=pass smtp.auth=dmarc_support@corp.mail.ru smtp.mailfrom=dmarc_support@corp.mail.ru; iprev=pass policy.iprev=10.161.4.115 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-23576-1563288786-0001-3" 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-23576-1563288786-0001-3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Feedback from Mail.Ru

Feedback from Mail.Ru

Id: 68064799912189070641563148800; begin: 2019-07-15T00:00:00Z; end: 2019-07-16T00:00:00Z
Domain: tana.it; DKIM: relaxed; SPF: relaxed; policy published: none none 100

Relaying IP message count reason and disposition From header
(opt. envelope) 		SPF DKIM
5.170.8.661nonext.tana.itme
5.170.8.661nonext.tana.ittana.it
82.195.75.1007tana.itlists.debian.org tana.it
62.94.243.2261tana.ittana.it tana.it

Legend
disposition: quarantine, reject.
spf: pass, fail, softfail, temperror or permerror.
dkim: pass, fail, policy.

--=_north-23576-1563288786-0001-3 Content-Type: multipart/mixed; boundary="=_north-23576-1563288786-0001-4" 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-23576-1563288786-0001-4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhpcyBpcyBhbiBhZ2dyZWdhdGUgcmVwb3J0IGZyb20gTWFpbC5SdS4= --=_north-23576-1563288786-0001-4 Content-Type: application/gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mail.ru!tana.it!1563148800!1563235200.xml.gz" H4sICFYSLV0C/21haWwucnUhdGFuYS5pdCExNTYzMTQ4ODAwITE1NjMyMzUyMDAueG1sAO1VzXKb MBC+9yly8ymSwTaGjqL0BXrpCzCyWGxNQNJIInXfvitksGO3mWaSXjq9oN1lf779dgXs8dh3d8/g vDL6YZGR5eIOtDSN0vuHxRDa+3LxyD+xFqDZCfnEmQNrXKh7CKIRQXBm3L7Wogf+VaiOfBsYnS0M erTxphdO1n6wMfKLNM6SaCcOfZMHg2NwopZGByFDrXRr+CEE+5nSA3SzO43nfbRg4G3EhE01vCiX xXpbVVWWZ2W13KKWbYpVti7L5ZLRsyPDJqB2Qu8R7g72SvNLx2RhoJvRnK82eTRHndHLUHrDizWd kj9qO+w65Q8QSxnEr3kQWhAVMD7pTDRPqueO0SQw4W07qvFklmujgVHLmZ9kFJiVgWcRTBTweVPO AVIdT/MdQ83gJNTK8g3JtktSkqLAPLOVSTNoTMhoEib48Cy6AfuM8JW3xquAm3KCcWlhI/YWB4T2 sY2IPuljH/Q2Ix2hqQZ0UK3CJeTsAKIBV7fO9GORYyAzX5fvGH0RJoZwqB34oQs+VZ7Y7uFMtJfG Asf9MYhplFmKOfVzUibAL5PSmc//vP5qixOhfcxyzW5C+y52y5xk1YZskeW48zcEb99JsBXefxjB b2c2Ff4ttdCBDMbxBrogENakTwQn9DPB5zamlPhNCJ40sFNCE/w+/9HYPuBSFDmp1iRfr0ie/417 cT22pP8zY3vLJbtK9uq06Pw//wmXedwbAQgAAA== --=_north-23576-1563288786-0001-4-- --=_north-23576-1563288786-0001-3-- --=_north-23576-1563288786-0001-2-- From nobody Tue Jul 16 09:15:49 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 11F411208C4 for ; Tue, 16 Jul 2019 09:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4USYkplxG50x for ; Tue, 16 Jul 2019 09:15:45 -0700 (PDT) Received: from USAT19PA24.eemsg.mail.mil (USAT19PA24.eemsg.mail.mil [214.24.22.198]) (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 B78691208C0 for ; Tue, 16 Jul 2019 09:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1563293745; x=1594829745; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C0D2eiy4HEqaQaNNZFx31eFtYcROabUEr8h9SMWWQWU=; b=gtwnMPG0VlAabW+/NpU2xHCR1FdRo11u3x1QHhNDHhCp07KHx4n5XXee JBxTKJbKmACcPDLIEbT0wAEcTbAgrMXh/vfmeSYcr29AHRBk2PbHeJdms j7P2xFpjVttc+/iITieHaQpKpOWY0XT9JLixS9SkY8ZotRC/doJWqi9yc AkDDOOMRnQGUFZw3DS1Q0kr6xftdP3Hg4ATHD7P0ktrguWmstZNk2ECZg lA4N07wt3wNZrNtJqAZ6Cd7kv2qtqOOSTrnzKzwd1RFAZHbP1yH2eavFd P/Iq45pdaeENPAPA1zcwqMbsQieADl1TYt7D8doFkVZg2uQ1lMxrIsxnn Q==; X-EEMSG-check-017: 8544732|USAT19PA24_ESA_OUT05.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.63,498,1557187200"; d="scan'208,217";a="8544732" Received: from edge-mech02.mail.mil ([214.21.130.230]) by USAT19PA24.eemsg.mail.mil with ESMTP; 16 Jul 2019 16:15:43 +0000 Received: from UMECHPAOR.easf.csd.disa.mil (214.21.130.161) by edge-mech02.mail.mil (214.21.130.230) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jul 2019 16:14:55 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.5.81]) by umechpaor.easf.csd.disa.mil ([214.21.130.161]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 16:14:54 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVObIrPnhyNfLOXkqHxVonBg/kBabNZIpTgAALRhg= Date: Tue, 16 Jul 2019 16:14:54 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil> References: <1958020.28HeBAo97T@l5580>,<4789054.Ip9ilXyiH0@l5580> In-Reply-To: <4789054.Ip9ilXyiH0@l5580> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.97.89] Content-Type: multipart/alternative; boundary="_000_553D43C8D961C14BB27C614AC48FC0311CAA91FEUMECHPA7Deasfcs_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 16 Jul 2019 16:15:48 -0000 --_000_553D43C8D961C14BB27C614AC48FC0311CAA91FEUMECHPA7Deasfcs_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I recently joined this working group from the United States Department of D= efense (DoD), which runs the .mil TLD. We appreciate all the work that has = been done so far on DMARC and are currently investing significant efforts t= o implement DMARC broadly across DoD domains. We value and support this PS= D DMARC draft and experiment and see how it will complement the existing DM= ARC effort for us and many others by being able to broadly apply DMARC at T= LDs and PSDs when subdomains are missing their own DMARC records and for no= n-existent subdomains, which are significant gaps today. I agree with the suggestion below that the default policy for non-existent = sub-domains should be the domain's policy if the "np" tag is absent, rather= than defaulting to the "sp" tag's policy. A few minor suggestions: In section 4, "requiremetns" should be "requirements". In section 4.1, there is an extra "be", so "This leakage could be potential= ly be utilized ..." should be "This leakage could potentially be utilized .= ..". In appendix B, "faciliate" should be "facilitate". Sincerely, -Eric ________________________________ Eric Chudow DoD Cybersecurity Mitigations ________________________________ From: Alessandro Vesely Sent: Tue, 16 July 2019 14:53 UTC To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group = Last Call: draft-ietf-dmarc-psd > Sorry for not contributing more to this thread - please don't take it as = any indication of lack of interest. For UK NCSC specifically, I think we'd = prefer NXDOMAIN rather than NODATA, given it's more constrained and this is= an experiment. My view would be that if we've published a name under gov.u= k, even with no valid (in the eyes of the receiver) associated records, the= n *someone* is responsible for it and we can go find and educate them. They= may even believe they have a valid reason for doing so that may outweigh a= ny email authentication concerns. But there's a conversation to be had. If = there's no published name, then there's no-one responsible, so it should de= fault to the top-level policy. I agree that np should default to p. The original wording for sp is also s= impler than''If absent, the policy specified by the "sp" (if present) and t= hen the "p" tag, if not, MUST be applied for non-existent subdomains.'' (B= TW, mind that "sp" instead of "np" in the new tag's definition.) --_000_553D43C8D961C14BB27C614AC48FC0311CAA91FEUMECHPA7Deasfcs_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

I recently joined this working group from the United States Departm= ent of Defense (DoD), which runs the .mil TLD. We appreciate all the w= ork that has been done so far on DMARC and are currently investing signific= ant efforts to implement DMARC broadly across DoD domains.  We value and support this PSD DMARC draft and= experiment and see how it will complement the existing DMARC eff= ort for us and many others by being able to broadly apply DMARC at TLDs and= PSDs when subdomains are missing their own DMARC recor= ds and for non-existent subdomains, which are significant gaps today.  =

 

I agree with the suggestion below that the default policy for non-existe= nt sub-domains should be the domain's policy if the "np" tag is a= bsent, rather than defaulting to the "sp" tag's policy.

 

A few minor suggestions:

 

In section 4, "requiremetns" should be "requirements"= ;.

In section 4.1, there is an extra "be", so "This leakage = could be potentially be utilized ..." should be "This leakage cou= ld potentially be utilized ...".

In appendix B, "faciliate" should be "facilitate".

 

Sincerely,

-Eric  

Eric Chudow

DoD Cybersecurity Mitigations

 

--_000_553D43C8D961C14BB27C614AC48FC0311CAA91FEUMECHPA7Deasfcs_-- From nobody Tue Jul 16 10:34:18 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 32E2B120A90 for ; Tue, 16 Jul 2019 10:34:17 -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, 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_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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHRH79GHaPCT for ; Tue, 16 Jul 2019 10:34:14 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110122.outbound.protection.outlook.com [40.107.11.122]) (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 0FE35120ABF for ; Tue, 16 Jul 2019 10:34:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AXs7Yu4zRAi8lFb1zroSwNyxaob1eiebjBprfEGuS7rWbPmG5D84BPgHXgtZmh87eFzMopttTOSWv5udcJeKCEexyWbl6uLz5jk70snYm9i0hP/5obrF0vcXN7R9qrxEuX0IInYN5gRBdhC63vM9U8s7T8xbKWZA0SwYfehVUO7GkoLSLwfhaj7vKS+qK/IckwnPMpx08eSXKYHASejfQq1bLFqLvQ+nKlpe+EYsSoLUt15I2rjrLlfnraoSZ5x9sLzE8Dzc96llYH+HyzkrHQSkDWKL2jHchKF1gncKK7ypoEKjNEQSmPwV6w7s1IshIBk/yqktX05YRyVDwUON7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iy7du59A47RpVdstudFK5+z0jDdYOQSqOQsWkcjcP/Q=; b=BJhGDSIEdKdwZe2n2KfwVyVw4Kwvg2qKzfOOKwrXoZXCRNEWU+o3zO4+5rYUQRlTY5ehGc9LYgYFCqpPvTj7/JdHhiuS15ZHL1kavztpW6AtwK3bXCBQEVMVOFxQ1JAyYWHomee/1EGafDuZAzA9j35J8WpLftTqQNNyQzHuCALlrcKnPoxBP3uLcI+WNhAe5vje8gEzZkR8M1DglNcjjJjXD0VaF3xMoqQ0ofSFYKV/9MpU3cugiLNIG0XqKFvdizhHJ/+CUeZyQbUKS39RkzAncAxb4FNCHFUFjKfDAryBC/CuM5CWil8P1d+jIIutwjwWH8nWN5FZVOfqRP0OxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iy7du59A47RpVdstudFK5+z0jDdYOQSqOQsWkcjcP/Q=; b=B6PtvudnN0UknUO6RZQUbkmkYqZnBQQXj09SES3pYYuNwXT/jK5XqotLjD0H1q95bQFL7YT0RpG1j/yKXaciarvYpnX6LjEnn9eaA/fLOArQZ7RU1uOMQfRkAkiZjsSPndV7Zd2HYQ63kDq19/3Utxv7mip2V0Kvpav/gDRmZfs= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2462.GBRP123.PROD.OUTLOOK.COM (20.176.157.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Tue, 16 Jul 2019 17:34:10 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 17:34:10 +0000 From: Ian Levy To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAF1oCAABAxAIAAFoEAgACGD4CAABkfAIACPhxAgAMMsYCAACoh8A== Date: Tue, 16 Jul 2019 17:34:10 +0000 Message-ID: References: <20190713043409.A5EB64A61C0@ary.local> <3017917.gKNyNSpcLf@l5580> <51e6b971-270e-a54f-bfb1-4a5d0ba8a94f@tana.it> In-Reply-To: <51e6b971-270e-a54f-bfb1-4a5d0ba8a94f@tana.it> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5a05338-84c6-4cf8-ea6f-08d70a13d018 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2462; x-ms-traffictypediagnostic: LO2P123MB2462: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(346002)(376002)(136003)(39850400004)(189003)(199004)(13464003)(14454004)(7696005)(476003)(66066001)(52536014)(76176011)(305945005)(7736002)(11346002)(446003)(86362001)(2501003)(66476007)(71200400001)(71190400001)(8676002)(66446008)(66556008)(64756008)(76116006)(186003)(81166006)(81156014)(486006)(44832011)(6246003)(8936002)(102836004)(53936002)(9686003)(2906002)(55016002)(6306002)(6436002)(966005)(256004)(3846002)(6116002)(14444005)(6506007)(229853002)(5024004)(26005)(99286004)(5660300002)(316002)(110136005)(66946007)(74316002)(478600001)(33656002)(45080400002)(68736007)(55236004)(4000180100002)(25786009)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2462; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7UtNC20ovVt97nVLS0FlD/nNxWpszUKPacjY6c37x6XcgJSHe0gxV8GkmFBLJtWeTYYjQjNE2uiXkiV6un5miBcpxrbY6mWk1FwD6cfMtmjO6olN/UVW1HT/k8qKoaqS+XvQom4AGW1ZVsEf2AkIDnDHWi9WWQUJy9vTvPiUAilltO9NuO2ikpVzgFrS+SBvjPyHWPTuDZmJFlNMUeKrDLTyvmz5NG01x0FW7ntzfMwiQkxE5FjKkdhz/Vs2ATosrAK71+iiylkefNXdyXlZ6fzu5EOFaq2gP56Y3qlM8pJtg/qrhzESl2Cd666DOb7EIAZyGuFkHWD/t7Zkjut4ylSdKbfxUqHo7mnHBzLKHEpjc8JK24zVGG5Q/yHOoLBR61kx6bK//rHVYqdiHFtGJLlyHA4wrjPoRU5EU5Nfc/A= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: a5a05338-84c6-4cf8-ea6f-08d70a13d018 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 17:34:10.6135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2462 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 16 Jul 2019 17:34:17 -0000 PiBNYWlsLnJ1IHJlcG9ydHMgc2VlbSB0byBiZSBtaXNzaW5nIGZyb20gbm9uLWV4aXN0aW5nIGRv bWFpbnMuICANCg0KWWVwLCB0aGF0J3Mgb3VyIGV4cGVyaWVuY2UuIFdlIGdldCBwbGVudHkgb2Yg RE1BUkMgcmVwb3J0cyBmcm9tIG1haWwucnUgaW4gdGhlIGNvdXJzZSBvZiBub3JtYWwgYnVzaW5l c3M7IGp1c3Qgbm90IGluIHRoZSBub24tZXhpc3RlbnQgZG9tYWluIGNhc2UuIEludGVyZXN0aW5n IHRoYXQgeW91ciBleHBlcmllbmNlIHdhcyBkaWZmZXJlbnQsIHRob3VnaC4gDQoNCj4gSXQgaXMg cG9zc2libGUgdGhhdCBzb21lIGNhc2VzIG9mIG5vbi1leGlzdGVudCBkb21haW4gYXJlIHRyZWF0 ZWQgYXMgYSBzaG9ydC1jdXQNCg0KVGhhdCdzIGNlcnRhaW5seSBteSBhc3N1bXB0aW9uLg0KDQpJ IHRoaW5rIHRoZSBwb2ludCBpcyB0aGF0IHRoZSBjdXJyZW50IGJlaGF2aW91ciBpcyBpbmNvbnNp c3RlbnQgKGV2ZW4gbW9yZSBpbmNvbnNpc3RlbnQgdGhhbiAncmVhbCBETUFSQycpLCBoZW5jZSB0 aGUgbmVlZCBmb3IgdGhpcyBleHBlcmltZW50LiBJIG1lbnRpb25lZCB0aGUgcmVwb3J0IHllc3Rl cmRheS4gSXQncyBub3cgcHVibGlzaGVkIGFuZCBsaW5rZWQgb2ZmIGhlcmUgOiBodHRwczovL3d3 dy5uY3NjLmdvdi51ay9ibG9nLXBvc3QvYWN0aXZlLWN5YmVyLWRlZmVuY2UtLWFjZC0tLXRoZS1z ZWNvbmQteWVhcg0KDQpUaGVyZSdzIGEgd2hvbGUgc2VjdGlvbiBvbiBvdXIgZXhwZXJpZW5jZSBh bmQgd29yayBvbiBETUFSQyB0aGF0IG1heSBiZSBpbnRlcmVzdGluZyB0byB0aGUgZ3JvdXAsIGlu Y2x1ZGluZyBzb21lIG9mIHRoZSBlZmZlY3RzIG9mIHRoZSBzcGVjaWZpYyBwcm9ibGVtIHdlJ3Jl IHRhbGtpbmcgYWJvdXQgaGVyZS4gDQoNClRhLg0KDQpJLg0KDQotLQ0KRHIgSWFuIExldnkNClRl Y2huaWNhbCBEaXJlY3Rvcg0KTmF0aW9uYWwgQ3liZXIgU2VjdXJpdHkgQ2VudHJlDQppYW5AbmNz Yy5nb3YudWsNCg0KU3RhZmYgT2ZmaWNlciA6IEthdGUgQXRraW5zLCBrYXRlLmFAbmNzYy5nb3Yu dWsNCg0KKEkgd29yayBzdHVwaWQgaG91cnMgYW5kIHdlaXJkIHRpbWVzIOKAkyB0aGF0IGRvZXNu 4oCZdCBtZWFuIHlvdSBoYXZlIHRvLiBJZiB0aGlzIGFycml2ZXMgb3V0c2lkZSB5b3VyIG5vcm1h bCB3b3JraW5nIGhvdXJzLCBkb27igJl0IGZlZWwgY29tcGVsbGVkIHRvIHJlc3BvbmQgaW1tZWRp YXRlbHkhKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZG1hcmMgPGRtYXJj LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBbGVzc2FuZHJvIFZlc2VseQ0KU2VudDog MTYgSnVseSAyMDE5IDE1OjUzDQpUbzogZG1hcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG1h cmMtaWV0Zl0gTm9uZXhpc3RlbnQgRG9tYWluIFBvbGljeSB3YXM6IFJlOiBXb3JraW5nIEdyb3Vw IExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1kbWFyYy1wc2QNCg0KT24gTW9uIDE1L0p1bC8yMDE5IDA5 OjA4OjA0ICswMjAwIElhbiBMZXZ5IHdyb3RlOg0KDQo+IFNvcnJ5IGZvciBub3QgY29udHJpYnV0 aW5nIG1vcmUgdG8gdGhpcyB0aHJlYWQgLSBwbGVhc2UgZG9uJ3QgdGFrZSBpdCBhcyBhbnkgaW5k aWNhdGlvbiBvZiBsYWNrIG9mIGludGVyZXN0LiBGb3IgVUsgTkNTQyBzcGVjaWZpY2FsbHksIEkg dGhpbmsgd2UnZCBwcmVmZXIgTlhET01BSU4gcmF0aGVyIHRoYW4gTk9EQVRBLCBnaXZlbiBpdCdz IG1vcmUgY29uc3RyYWluZWQgYW5kIHRoaXMgaXMgYW4gZXhwZXJpbWVudC4gTXkgdmlldyB3b3Vs ZCBiZSB0aGF0IGlmIHdlJ3ZlIHB1Ymxpc2hlZCBhIG5hbWUgdW5kZXIgZ292LnVrLCBldmVuIHdp dGggbm8gdmFsaWQgKGluIHRoZSBleWVzIG9mIHRoZSByZWNlaXZlcikgYXNzb2NpYXRlZCByZWNv cmRzLCB0aGVuICpzb21lb25lKiBpcyByZXNwb25zaWJsZSBmb3IgaXQgYW5kIHdlIGNhbiBnbyBm aW5kIGFuZCBlZHVjYXRlIHRoZW0uIFRoZXkgbWF5IGV2ZW4gYmVsaWV2ZSB0aGV5IGhhdmUgYSB2 YWxpZCByZWFzb24gZm9yIGRvaW5nIHNvIHRoYXQgbWF5IG91dHdlaWdoIGFueSBlbWFpbCBhdXRo ZW50aWNhdGlvbiBjb25jZXJucy4gQnV0IHRoZXJlJ3MgYSBjb252ZXJzYXRpb24gdG8gYmUgaGFk LiBJZiB0aGVyZSdzIG5vIHB1Ymxpc2hlZCBuYW1lLCB0aGVuIHRoZXJlJ3Mgbm8tb25lIHJlc3Bv bnNpYmxlLCBzbyBpdCBzaG91bGQgZGVmYXVsdCB0byB0aGUgdG9wLWxldmVsIHBvbGljeS4NCg0K DQpJIGFncmVlIHRoYXQgbnAgc2hvdWxkIGRlZmF1bHQgdG8gcC4gIFRoZSBvcmlnaW5hbCB3b3Jk aW5nIGZvciBzcCBpcyBhbHNvIHNpbXBsZXIgdGhhbicnSWYgYWJzZW50LCB0aGUgcG9saWN5IHNw ZWNpZmllZCBieSB0aGUgInNwIiAoaWYgcHJlc2VudCkgYW5kIHRoZW4gdGhlICJwIiB0YWcsIGlm IG5vdCwgTVVTVCBiZSBhcHBsaWVkIGZvciBub24tZXhpc3RlbnQgc3ViZG9tYWlucy4nJyAgKEJU VywgbWluZCB0aGF0ICJzcCIgaW5zdGVhZCBvZiAibnAiIGluIHRoZSBuZXcgdGFnJ3MgZGVmaW5p dGlvbi4pDQoNCg0KPiBbLi4uXQ0KPiBIZXJlJ3MgdGhlIHZvbHVtZSBvZiByZXBvcnRzIHJlY2Vp dmVkIG9uIG91ciBub3JtYWwgRE1BUkMgcHJvY2Vzc2luZyBjaGFpbiBpbiBKYW51YXJ5IDIwMTkg KG5vdGluZyBNaWNyb3NvZnQgYXJlIG9uZSBvZiB0aGUgYmlnZ2VyIHByb3ZpZGVycyBpbiB0aGUg VUsgYW5kICpzdGlsbCogZG9uJ3QgZ2VuZXJhdGUgYW55IHJlcG9ydHMpOg0KPg0KPiBSZXBvcnRl ciAgICAgIFRvdGFsIFJlcG9ydHMNCj4gZ29vZ2xlLmNvbSAgICA2MSwzNjMsNjA1DQo+IFlhaG9v ISBJbmMuICAgMTgsODc2LDIwMQ0KPiBNYWlsLlJ1ICAgICAgIDY5OSw1NTQNCj4gc2VyY29nbG9i YWwuY29tIDIyNyw1ODcNCj4gQU1BWk9OLVNFUyAgICAxNzgsMjYyDQoNCg0KVGhhdCBpcyBhdCBv ZGRzIHdpdGggdGhlIG9yZGVyIHJlcG9ydGVkIGJ5IGRtYXJjaWFuOg0KDQpOZXRFYXNlICgxNjMu Y29tLCAxMjYuY29tLCB5ZWFoLm5ldCkNCkdvb2dsZSAqDQpZYWhvbyENCk1pY3Jvc29mdA0KQU9M DQpjaXNjbyBTeXN0ZW1zDQpESEwNCkNvbWNhc3QgKg0KVGVuY2VudCAocXEuY29tKQ0KTWFpbC5y dQ0KLi4uLiBodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkbWFyYy5vcmclMkZzdGF0cyUyRmRtYXJjLXJlcG9ydGluZyUyRiZh bXA7ZGF0YT0wMiU3QzAxJTdDaWFuLmxldnklNDBuY3NjLmdvdi51ayU3Q2I0MjJkZDU4N2Q1NTQz YzYxNDI5MDhkNzA5ZmQ2MzAwJTdDMTRhYTU3NDRlY2UxNDc0ZWEyZDczNGY0NmRkYTY0YTElN0Mw JTdDMCU3QzYzNjk4ODg1NjgyMDExNDM4MyZhbXA7c2RhdGE9OGlrRnF3SFFEa0VhT1FWSnNsdGky dllOcDhqWVdVNEM3b21NN1NKQUF1WSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KKFRoYXQgdXNlZCB0byBi ZSBvbiBkbWFyY2lhbiwgYnV0IGNvdWxkbid0IGZpbmQgaXQgYW55IG1vcmUpDQoNCg0KPiBBbmQg aGVyZSdzIHRoZSB2b2x1bWUgZm9yIHRoZSBzYW1lIG1vbnRoIGZvciB0aGUgc3ludGhldGljIERN QVJDIHJlcG9ydHMgOg0KPiBSZXBvcnRlciAgICAgICAgICAgICAgVG90YWwgUmVwb3J0cw0KPiBn b29nbGUuY29tICAgICAgICAgICAgMjMsNzQ1DQo+IFlhaG9vISBJbmMuICAgICAgICAgICAxLDA2 MA0KPiBlbWFpbHNydnIuY29tICAgICAgICAgICAgICAgICA2NA0KPiBkZXYuam9obmxld2lzLmNv LnVrICAgMzcNCj4gYnJpZGdlbmQuZ292LnVrICAgICAgIDMwDQo+DQo+IEp1c3QgZnJvbSB0aGF0 LCBpdCdzIHByZXR0eSBjbGVhciB0aGF0IHRoZSBzeW50aGVzaXplZCBETUFSQyByZWNvcmRzIGFy ZSBub3QgdW5pdmVyc2FsbHkgcHJvY2Vzc2VkLCB3aGljaCBnaXZlcyB3ZWlnaHQgdG8gY29tcGxl dGluZyB0aGlzIHdvcmsgYW5kIHN0YXJ0aW5nIHRvIHRyeSB0aGluZ3Mgb3V0LiBHaXZlbiB0aGUg bGV2ZWwgb2YgaW5jb25zaXN0ZW5jeSB3ZSBzZWUgaW4gcmVjZWl2ZXIgYmVoYXZpb3VyLCBJIHRo aW5rIGl0J2QgYmUgZWFzaWVyIHRvIHN0YXJ0IHdpdGggTlhET01BSU4gYW5kIHNlZSB3aGF0IHRo YXQgYWN0dWFsbHkgYWNoaWV2ZXMuDQo+DQo+IEkgbWF5IHdlbGwgYmUgbWlzc2luZyBzb21ldGhp bmcgc3VidGxlLCBzbyBwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ3ZlIGdvdCB0aGlzIHdyb25nLg0K DQoNCkhtbS4uLiAgTWFpbC5ydSByZXBvcnRzIHNlZW0gdG8gYmUgbWlzc2luZyBmcm9tIG5vbi1l eGlzdGluZyBkb21haW5zLiAgTXkgZXhwZXJpZW5jZSBkaWZmZXJzIHNsaWdodGx5LiAgWWVzdGVy ZGF5IEkgc2VudCBhIGZldyBtZXNzYWdlcyB0byBtYWlsLnJ1LiAgRml2ZSBvZiB0aGVtIGZyb20g YSBub25leHQgZG9tYWluIChJUCA1LjE3MC44LjY2KSwgYWxsIG9mIHdoaWNoIHdlcmUgcmVqZWN0 ZWQsIHR3byBvZiB3aGljaCB3ZXJlIHJlcG9ydGVkIGluIHRoZSBhZ2dyZWdhdGUgcmVwb3J0IGF0 dGFjaGVkLiAgSG93ZXZlciByaXNpYmxlIHRoZXNlIG51bWJlcnMgbWF5IHNvdW5kIHdoZW4gY29t cGFyZWQgdG8geW91cnMsIGl0IGlzIGNsZWFyIHRoYXQgbm90IGFsbCBtZXNzYWdlcyBhcmUgcmVw b3J0ZWQuDQoNCkl0IGlzIHBvc3NpYmxlIHRoYXQgc29tZSBjYXNlcyBvZiBub24tZXhpc3RlbnQg ZG9tYWluIGFyZSB0cmVhdGVkIGFzIGEgc2hvcnQtY3V0LCBza2lwcGluZyBtZXNzYWdlIHJlZ2lz dHJhdGlvbiBhbmQgRE1BUkMgdmVyaWZpY2F0aW9uIGFsdG9nZXRoZXIsIGV2ZW4gaWYgdGhlIHJl amVjdCBhbHdheXMgY2FtZSBhZnRlciBEQVRBLi4uICBKdXN0IG11bWJsaW5nLiAgQ29uc2lkZXJp bmcgdGhhdCBtb3N0IERNQVJDIHBhY2thZ2VzIHdvcmsgYXMgbWFpbCBmaWx0ZXJzLCBJJ2QgZXhw ZWN0IG1lc3NhZ2VzIGZpbHRlcmVkIG91dCBiZWZvcmUgd2lsbCBuZXZlciBtYWtlIHRoZWlyIHdh eSB0byBhZ2dyZWdhdGUgcmVwb3J0cy4gIElzIHRoYXQgYSBETUFSQyB2aW9sYXRpb24/DQoNCg0K QmVzdA0KQWxlDQotLQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVGhpcyBpbmZvcm1hdGlvbiBp cyBleGVtcHQgdW5kZXIgdGhlIEZyZWVkb20gb2YgSW5mb3JtYXRpb24gQWN0IDIwMDAgKEZPSUEp IGFuZCBtYXkgYmUgZXhlbXB0IHVuZGVyIG90aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9u LiBSZWZlciBhbnkgRk9JQSBxdWVyaWVzIHRvIG5jc2NpbmZvbGVnQG5jc2MuZ292LnVrLiBBbGwg bWF0ZXJpYWwgaXMgVUsgQ3Jvd24gQ29weXJpZ2h0IMKpDQo= From nobody Tue Jul 16 21:15:07 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 9A247120058 for ; Tue, 16 Jul 2019 21:15:05 -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=E/lFvAnJ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=AmROEdW5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PEoZOGQapEO for ; Tue, 16 Jul 2019 21:15:02 -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 F1F41120125 for ; Tue, 16 Jul 2019 21:15:01 -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 2DDB2F805B5 for ; Wed, 17 Jul 2019 00:15:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563336900; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=FUBeTlaqtiHu8HmReliilmzUBvkpLmitVl0W20o0tdM=; b=E/lFvAnJRsLOKNvXJMiPbwj2P8/wgbzGCr2n3MrWrgtxm6p1ZpnLU6lD ZMo/udUc73fWG23wJRuSpnVolhM7Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563336900; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=FUBeTlaqtiHu8HmReliilmzUBvkpLmitVl0W20o0tdM=; b=AmROEdW5pgW56mH0d4F/0spKVZo+z58nwd5xm6hBxRXomeF08oeOVRYA 3AxHY/Bb8GWyJxMtWnwEqtf/o8JGYhgfnkluu3FOGNhlBY+70jYMj51fkr gzY8YaGAsh8F1ywNTkbDxc32Tx96APJKXp/ye0ipYtxd0oUwDxKUNiOXYf w0vQR6mlo080WYKA1I//mKIzFV5ttabYTFZQb8PZlAi671Y304S7A72EXj GWDInEQoAfL6hbi1RTC+bP6D6ivHV2mUXxZlrzHqRYP8sH5HOQeeQvVUnV /im7AhsbhU06Je9cvFZlgvXUu4fo6Cpu4DtVsRnc5v4jZ6aysD/dcw== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id C08D7F8008C for ; Wed, 17 Jul 2019 00:15:00 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 00:14:55 -0400 Message-ID: <2709814.l7omtmZ8hE@l5580> In-Reply-To: References: <1958020.28HeBAo97T@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 04:15:06 -0000 I was slightly more verbose. I'll send the updated diff for 'np' once I get through my email backlog. Scott K On Monday, July 15, 2019 8:30:35 AM EDT Tim Wicinski wrote: > I totally agree with the logic behind the experiment. > > >From a document point of view, should we not document the 'np' part of the > > experiment? > > "The experiment will also evaluate the effectiveness of the 'np' tag for > non-existent subdomains. " > > Tim > > > > On Fri, Jul 12, 2019 at 2:28 PM Scott Kitterman > > wrote: > > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > > > > > wrote: > > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > > 3. If an np= tag is needed to allow PSD functioning for only > > > > NXDOMAINs > > > > > > The limited feedback during WGLC has been favorable to this. > > > > > > > > This will require a rather larger change to the document than the > > > > other > > > > issues, but they are manageable and I believe I have most of the > > > > relevant > > > > > > text > > > > from earlier revisions. > > > > > > > > I think we should include this. > > > > > > I am much more concerned with adding another tag that can only be used > > > > in a > > > > > PSD-DMARC record. I would be much more open to make a "normative" change > > > > to > > > > > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > > > record, than to make this a special case for PSD-DMARC records. > > > > I agree. My intent is to add the tag to be used experimentally for any > > DMARC > > record. Part of the experiment is to see if it's useful beyond PSD. > > > > Scott K > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 16 21:41:07 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 B80D512000F for ; Tue, 16 Jul 2019 21:41:05 -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=WVrEj3o/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qd8DAgrE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8beJ324ZvNw for ; Tue, 16 Jul 2019 21:41:02 -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 6D409120058 for ; Tue, 16 Jul 2019 21:41:02 -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 8E5D4F805B5 for ; Wed, 17 Jul 2019 00:40:31 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563338431; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=TtXe8oFJ7lhKSXbVAICPMKCHtdQsHbfdFBRKK4W+loU=; b=WVrEj3o/xcx9kbOZPm2sIhMICDWxwPCgehUjOpgz3Dj9HZk4ACboZnqX +6Hc841sPJ73XxPI3QbCpA1J9+QCAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563338431; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=TtXe8oFJ7lhKSXbVAICPMKCHtdQsHbfdFBRKK4W+loU=; b=qd8DAgrEi8jAliwJCK0Mjjjr7k8kNti+Il1nxxwB8D4fLPy/oohPmQ+r twnvO+8wg9seIl+XofrHc8NN6ZsJNQXhWpw4WnsyX4TqwjL1l9ZtvSfFdV dE2Ya5Em/yZa1chvgDDFxzn82OOFza46KdMkRykOr8KNZwvML5qas+BkVu 1FKUq7L1ioqOBGr3VKH0f1yAqmckW9q4SeFhJqkLjOI6FgEdDhc8omtr9/ IShGrOM9mmR5198QEFOZRfB0H5zds0fsrhqC8ijk4mNZC2/Uq50QlajfOf a9BzhrO1nxdfFlQXCUh6hwlpTub5u+JYv9pvPGkxw6Vxiv3H5UTkNw== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 3B297F8008C for ; Wed, 17 Jul 2019 00:40:31 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 00:40:29 -0400 Message-ID: <5967921.XLnl7RJ6Z0@l5580> In-Reply-To: References: <4789054.Ip9ilXyiH0@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 04:41:06 -0000 Fixed. Thanks. Scott K On Tuesday, July 16, 2019 4:20:12 AM EDT Richard C wrote: > I'm happy with the proposal but just wanted to flag that you have a typo for > the tag name in section 3.3 - you use 'sp' rather than 'np' > > Thanks > > Richard > > | -----Original Message----- > | From: dmarc On Behalf Of Scott Kitterman > | Sent: 13 July 2019 20:35 > | To: dmarc@ietf.org > | Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group > | Last Call: draft-ietf-dmarc-psd > | > | On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote: > | > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > | > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > | > > > | > > > | > > wrote: > | > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > | > > > > 3. If an np= tag is needed to allow PSD functioning for only > | > > > > NXDOMAINs > | > > > > | > > > The limited feedback during WGLC has been favorable to this. > | > > > > | > > > This will require a rather larger change to the document than the > | > > > other issues, but they are manageable and I believe I have most of > | > > > the relevant text from earlier revisions. > | > > > > | > > > I think we should include this. > | > > > | > > I am much more concerned with adding another tag that can only be > | > > used in a PSD-DMARC record. I would be much more open to make a > | > > "normative" change to the DMARC tag list (RFC 7489 section 11.4) to > | > > define np for any DMARC record, than to make this a special case for > | > > PSD-DMARC records. > | > > | > I agree. My intent is to add the tag to be used experimentally for > | > any DMARC record. Part of the experiment is to see if it's useful > | > beyond > | > | PSD. > | > | Attached is my proposed text to add the np tag. Based on the discussion > | to > | date, I assume I'll be asked to add something like this after last call is > | complete, so please let me know how to make it better. > | > | Scott K > | This information is exempt under the Freedom of Information Act 2000 > | (FOIA) > | and may be exempt under other UK information legislation. Refer any FOIA > | queries to ncscinfoleg@ncsc.gov.uk > > This information is exempt under the Freedom of Information Act 2000 (FOIA) > and may be exempt under other UK information legislation. Refer any FOIA > queries to ncscinfoleg@ncsc.gov.uk > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 16 22:04:55 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 A3E66120125 for ; Tue, 16 Jul 2019 22:04:53 -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=ayBDe6Kq; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ZrO1iwA2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuYh71xQ6JnN for ; Tue, 16 Jul 2019 22:04:52 -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 DD7501200B7 for ; Tue, 16 Jul 2019 22:04:51 -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 01A78F805B5 for ; Wed, 17 Jul 2019 01:04:51 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563339890; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sVrczwhtEkuHvh5XEwrzwYEV3L7TY4bazdcemkivVv0=; b=ayBDe6Kqa3tYwFfNCCTWaiS4LjKEYUvP/ML/WzA3MnpCJWM7LuVqI+Ih jtHsZGQpu6jLar1Pe1KvPeyZJrjIAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563339890; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=sVrczwhtEkuHvh5XEwrzwYEV3L7TY4bazdcemkivVv0=; b=ZrO1iwA2N3oDpEQ70J7Ayog5GMawHdhI0Ol7on6t1MxVf6lIx3JVhJwG ndKRqmTjjiRs+ETCxnW8x16z1T73sFgpcjsdjXpGVn4SHnzFObl79C9dAp AcZIBVBDkEWWNhi0ObL6zVCvnGUC0+kLPwlwZL9TGtyU1xfv/6fVadEebS TD/bSnzePqdoQk2mhEPFWHAtik35vmq08MuxbeDLe+2oF25I8jidnenFfe VmEZtf7o5KgmiqBvDjopq8u0R8Xyl8Q0KQ1+Bf8QW4qLIjkF/afS+nlgTS JQ0jBEuwZ/knaGi8y4ijYRmiZ2ro1scUYEkA6H310rLa7Kdu+5Lnng== Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 77BE5F8008C for ; Wed, 17 Jul 2019 01:04:50 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 01:00:47 -0400 Message-ID: <1808303.aIhlromXIS@l5580> In-Reply-To: <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil> References: <4789054.Ip9ilXyiH0@l5580> <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 05:04:54 -0000 On Tuesday, July 16, 2019 12:14:54 PM EDT Chudow, Eric B CIV NSA DSAW (USA) wrote: > I recently joined this working group from the United States Department of > Defense (DoD), which runs the .mil TLD. We appreciate all the work that has > been done so far on DMARC and are currently investing significant efforts > to implement DMARC broadly across DoD domains. We value and support this > PSD DMARC draft and experiment and see how it will complement the existing > DMARC effort for us and many others by being able to broadly apply DMARC at > TLDs and PSDs when subdomains are missing their own DMARC records and for > non-existent subdomains, which are significant gaps today. > > > > I agree with the suggestion below that the default policy for non-existent > sub-domains should be the domain's policy if the "np" tag is absent, rather > than defaulting to the "sp" tag's policy. Although a few people have suggested this, I think it would be a mistake because it would cause a gratuitous incompatibility with RFC 7468. Current behavior (where np is not defined) is for sp to apply to all domains, existing or not. No distinction is made. Consider the effect of the two different approaches: Example: p=reject sp=none np=quarantine A receiver that is not a participant in the experiment will process the policy for a non-existent subdomain as none (since they don't recognize np). This is equivalent to: p=reject sp=none I think it is a desirable characteristic that the addition of np not disturb existing expectations. If a recipient that is a participant in the experiment attempts to determine policy for a sub-domain without 'np', then the result should match what a non-participant gets. If no 'np' falls back to 'p', then the policy is reject, which will have a negative interaction with non-participants. If the policy falls back to 'sp', then the result is the same whether the recipient is a participant or not. Also, keep in mind, that if 'sp' is not present, it falls back to 'p', so falling back to 'sp' first is not a dead end. > > A few minor suggestions: > > > > In section 4, "requiremetns" should be "requirements". Fixed. Thanks. > In section 4.1, there is an extra "be", so "This leakage could be > potentially be utilized ..." should be "This leakage could potentially be > utilized ....". Fixed. Thanks. > In appendix B, "faciliate" should be "facilitate". Fixed. Thanks, ... Scott K From nobody Tue Jul 16 22:07:17 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 C578E120114 for ; Tue, 16 Jul 2019 22:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_HTML_ATTACH=0.01, 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=a4o7iZq7; dkim=pass (2048-bit key) header.d=kitterman.com header.b=WZlmf3qy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aV2ntOx8Y82q for ; Tue, 16 Jul 2019 22:07:12 -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 9CB22120058 for ; Tue, 16 Jul 2019 22:07:12 -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 F0F72F805B5 for ; Wed, 17 Jul 2019 01:07:11 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563340031; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=9B9eR6CHfnJZzlfm76UCIKZa8DwVCT2SsmIi5K2c3bc=; b=a4o7iZq7zhQ8kHUS6tgv6lkbdvDx/3jcd3bGq8Frc2v0gdsUNRwceGP8 IoNY4v3BhbFX4fPK/RJikWM8otGZAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563340031; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=9B9eR6CHfnJZzlfm76UCIKZa8DwVCT2SsmIi5K2c3bc=; b=WZlmf3qyCnDZ+mhV8F3WpGx+TJL/w/FXosg2Mt+S/X/QBKEUaU0a7MqY MkzmCZ6vKGHCBtL98EMfHieK0iUuIc3yiLG9PyyrOe5b0iABJ9VHibmcAy tFQkQQeXAeIVMG5jRwPTNTHQNbOfrGfSwjEm+lkJl3aAxu0XOoKma30Nw7 cxVsI5OyfLKLdLrAUcEUaDviyMmUNoXJ4dGvK/qWVpOBwLQuIfG+kdiBl3 LBol4yMPvNGQ+t/rin0saBc+fFVRSboiVaqpwC27QKFToK3RLvSX/2WXD1 OUI7LFZUsHh+QMewcl4C9S9omHT96isVNrTt6dwjdJIFGKIcuoB4IQ== Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 254F3F8008C for ; Wed, 17 Jul 2019 01:07:07 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 01:07:05 -0400 Message-ID: <7295017.bxVsTnSgkA@l5580> In-Reply-To: <4789054.Ip9ilXyiH0@l5580> References: <1958020.28HeBAo97T@l5580> <4789054.Ip9ilXyiH0@l5580> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart10805324.Ar2neLQE0L" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 05:07:15 -0000 This is a multi-part message in MIME format. --nextPart10805324.Ar2neLQE0L Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote: > On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote: > > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > > > > > wrote: > > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > > 3. If an np= tag is needed to allow PSD functioning for only > > > > > NXDOMAINs > > > > > > > > The limited feedback during WGLC has been favorable to this. > > > > > > > > This will require a rather larger change to the document than the > > > > other > > > > issues, but they are manageable and I believe I have most of the > > > > relevant > > > > text > > > > from earlier revisions. > > > > > > > > I think we should include this. > > > > > > I am much more concerned with adding another tag that can only be used > > > in > > > a > > > PSD-DMARC record. I would be much more open to make a "normative" change > > > to > > > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > > > record, than to make this a special case for PSD-DMARC records. > > > > I agree. My intent is to add the tag to be used experimentally for any > > DMARC record. Part of the experiment is to see if it's useful beyond PSD. > > Attached is my proposed text to add the np tag. Based on the discussion to > date, I assume I'll be asked to add something like this after last call is > complete, so please let me know how to make it better. > > Scott K Updated rfcdiff attached. The only change other than typos is to add mention of 'np' to Appendix A. Scott K --nextPart10805324.Ar2neLQE0L Content-Disposition: attachment; filename="draft-ietf-dmarc-psd-05-from-4.diff.html" Content-Transfer-Encoding: base64 Content-Type: application/xhtml+xml; name="draft-ietf-dmarc-psd-05-from-4.diff.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQxOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogTGludXggbDU1ODAgNC4xOS4wLTUtYW1kNjQgIzEgU01Q IERlYmlhbiA0LjE5LjM3LTMgKDIwMTktMDUtMTUpIHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0t IFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjIuMSwgQVBJOiAyLjAgKEdOVSBN UEZSIDQuMC4yLCBHTlUgTVAgNi4xLjIpIC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9k aWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjcgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNy L2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjIgLS0+IAo8aHRtbD4gCjxoZWFkPiAK ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5 cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1kbWFy Yy1wc2QtMDQudHh0IC0gZHJhZnQtaWV0Zi1kbWFyYy1wc2QtMDUudHh0PC90aXRsZT4gCiAgPHN0 eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2lu LXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3Bh Y2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9u dC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAg IC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFt aWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0g CiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5s aW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAu N2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sg YmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5y YmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICA8L3N0eWxlPiAKPC9o ZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPiAKICA8dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+Jm5ic3A7ZHJh ZnQtaWV0Zi1kbWFyYy1wc2QtMDQudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwO2Ry YWZ0LWlldGYtZG1hcmMtcHNkLTA1LnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRlbmRlZCBzdGF0dXM6IEV4cGVyaW1l bnRhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5N YXkgMjcsPC9zcGFuPiAyMDE5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkludGVu ZGVkIHN0YXR1czogRXhwZXJpbWVudGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNw YW4gY2xhc3M9Imluc2VydCI+SnVseSAxNyw8L3NwYW4+IDIwMTk8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFz cz0iZGVsZXRlIj5Ob3ZlbWJlciAyOCwgMjAxOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSAxOCwgMjAy MDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkRNQVJDIChEb21haW4tYmFzZWQg TWVzc2FnZSBBdXRoZW50aWNhdGlvbiwgUmVwb3J0aW5nLCBhbmQgQ29uZm9ybWFuY2UpPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+RE1BUkMgKERvbWFpbi1iYXNlZCBNZXNzYWdlIEF1 dGhlbnRpY2F0aW9uLCBSZXBvcnRpbmcsIGFuZCBDb25mb3JtYW5jZSk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgRXh0 ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMgU3VmZml4IERvbWFpbnMpPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgRXh0ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMg U3VmZml4IERvbWFpbnMpPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZG1hcmMtcHNkLTA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRtYXJjLXBzZC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERNQVJDIChEb21haW4tYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiwg UmVwb3J0aW5nLCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBETUFSQyAo RG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbmZv cm1hbmNlKSBpcyBhIHNjYWxhYmxlIG1lY2hhbmlzbSBieSB3aGljaCBhIG1haWwtb3JpZ2luYXRp bmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb25mb3JtYW5jZSkgaXMgYSBz Y2FsYWJsZSBtZWNoYW5pc20gYnkgd2hpY2ggYSBtYWlsLW9yaWdpbmF0aW5nPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9yZ2FuaXphdGlv biBjYW4gZXhwcmVzcyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yZ2FuaXphdGlvbiBjYW4gZXhwcmVz cyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZXNzYWdlIHZhbGlk YXRpb24sIGRpc3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZXNzYWdlIHZhbGlkYXRpb24sIGRp c3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3JnYW5pemF0 aW9uIGNhbiB1c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2Fu IGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uIGNhbiB1 c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2FuIGJlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFwcGxp ZWQgYXQgdGhlIGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5z IGF0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFwcGxpZWQgYXQgdGhl IGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5zIGF0IHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv cmdhbml6YXRpb25hbCBsZXZlbC4gIFRoZSBkZXNpZ24gb2YgRE1BUkMgcHJlY2x1ZGVzIGdyb3Vw aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uYWwgbGV2 ZWwuICBUaGUgZGVzaWduIG9mIERNQVJDIHByZWNsdWRlcyBncm91cGluZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9 ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMiIgLz48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwv dGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGVtPiBwYWdlIDEsIGxpbmUgNDM8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDMiIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJkZWxl dGUiPk5vdmVtYmVyIDI4LCAyMDE5PC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5KYW51YXJ5IDE4LCAyMDIwPC9zcGFuPi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5 cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmlnaHQgKGMp IDIwMTkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMTkgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFs bCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0 cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl IHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJs ZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDA0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMS4gIEludHJvZHVjdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFz cz0iZGVsZXRlIj4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBUZXJtaW5vbG9neSBh bmQgRGVmaW5pdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDIuICBUZXJtaW5vbG9neSBhbmQgRGVmaW5p dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIENvbnZl bnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIENvbnZlbnRpb25zIFVz ZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDA1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAyLjIuICBQdWJsaWMgU3Vm Zml4IERvbWFpbiAoUFNEKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgIDIuMi4gIFB1YmxpYyBTdWZmaXggRG9tYWluIChQU0QpICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMi4zLiAgTG9uZ2Vz dCBQU0QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4zLiAgTG9uZ2VzdCBQU0QgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuNC4gIFB1 YmxpYyBTdWZmaXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuNC4gIFB1YmxpYyBTdWZm aXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjUu ICBQU08gQ29udHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjUuICBQU08gQ29u dHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Mi42LiAgTm9uLWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi42LiAgTm9u LWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAzLiAgUFNEIERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgUFNE IERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAzLjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAz LjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgMy4yLiAgU2VjdGlvbiA2LjEgRE1BUkMgUG9saWN5IFJlY29yZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjIuICBTZWN0aW9uIDYuMSBETUFSQyBQb2xpY3kgUmVj b3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgMy4zLiAgU2VjdGlvbiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjMuICBTZWN0aW9uIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjYuMyBHZW5lcmFsIFJlY29yZCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgMy40Ljwvc3Bhbj4gIFNlY3Rpb24g Ni42LjMuICBQb2xpY3kgRGlzY292ZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAz LjQuICBTZWN0aW9uPC9zcGFuPiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPjMuNS48L3NwYW4+ICBTZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjayAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgIDMuNS48L3NwYW4+ICBTZWN0aW9uIDYuNi4zLiAgUG9saWN5IERpc2NvdmVyeSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgNC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPjMuNi48L3NwYW4+ICBTZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjayAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgNC4xLiAgRmVlZGJhY2sgbGVha2FnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgNC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij43PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA0LjEuICBGZWVkYmFjayBsZWFrYWdlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij43PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA1LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDci IC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA3LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUi Pjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgPHNwYW4gY2xh c3M9Imluc2VydCI+Ni4xLiAgU3ViZG9tYWluIFBvbGljeSBUYWcgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJk ZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDcuICBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDcuMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBcHBlbmRpeCBBLiAg VGhlIEV4cGVyaW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPjk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBcHBlbmRp eCBCLiAgRE1BUkMgUFNEIFJlZ2lzdHJ5IEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIEFwcGVuZGl4IEEuICBUaGUgRXhwZXJpbWVudCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg IEIuMS4gIERNQVJDIFBTRCBETlMgUXVlcnkgU2VydmljZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgQS4xLiAgUFNEIERNQVJD IFByaXZhY3kgQ29uY2VybiBNaXRpZ2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgIEIuMi4gIERNQVJDIFB1YmxpYyBTdWZmaXggRG9tYWluIChQU0QpIFJlZ2lzdHJ5IC4g LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTA8L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgQS4yLiAgTm9u LUV4aXN0ZW50IFN1YmRvbWFpbiBQb2xpY3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBBcHBlbmRpeCBDLiAgSW1wbGVtZW50YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEFwcGVuZGl4IEIuICBETUFSQyBQU0QgUmVn aXN0cnkgRXhhbXBsZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4xMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgIEMuMS4gIEF1dGhoZWFkZXJzIE1vZHVsZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgQi4xLiAgRE1BUkMgUFNEIERO UyBRdWVyeSBTZXJ2aWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4xMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgQi4yLiAgRE1BUkMg UHVibGljIFN1ZmZpeCBEb21haW4gKFBTRCkgUmVnaXN0cnkgLiAuIC4gLiAuIC4gLiAuICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij4xMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEFwcGVuZGl4 IEMuICBJbXBsZW1lbnRhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICBDLjEuICBBdXRoaGVhZGVycyBNb2R1bGUgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imlu c2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEF1dGhv cidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4x LiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBETUFSQyBbUkZD NzQ4OV0gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIHB1Ymxpc2hpbmcgb3JnYW5pemF0aW9uYWw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBETUFSQyBbUkZDNzQ4OV0gcHJvdmlk ZXMgYSBtZWNoYW5pc20gZm9yIHB1Ymxpc2hpbmcgb3JnYW5pemF0aW9uYWw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcG9saWN5IGluZm9y bWF0aW9uIHRvIGVtYWlsIHJlY2VpdmVycy4gIERNQVJDIFtSRkM3NDg5XSBhbGxvd3MgcG9saWN5 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcG9saWN5IGluZm9ybWF0aW9uIHRv IGVtYWlsIHJlY2VpdmVycy4gIERNQVJDIFtSRkM3NDg5XSBhbGxvd3MgcG9saWN5PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIGJlIHNw ZWNpZmllZCBmb3IgYm90aCBpbmRpdmlkdWFsIGRvbWFpbnMgYW5kIHNldHMgb2YgZG9tYWluczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGJlIHNwZWNpZmllZCBmb3IgYm90 aCBpbmRpdmlkdWFsIGRvbWFpbnMgYW5kIHNldHMgb2YgZG9tYWluczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXRoaW4gYSBzaW5nbGUg b3JnYW5pemF0aW9uLiAgRm9yIGRvbWFpbnMgYWJvdmUgdGhlIG9yZ2FuaXphdGlvbmFsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2l0aGluIGEgc2luZ2xlIG9yZ2FuaXphdGlv bi4gIEZvciBkb21haW5zIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBsZXZlbCBpbiB0aGUgRE5T IHRyZWUsIHBvbGljeSBjYW4gb25seSBiZSBwdWJsaXNoZWQgZm9yIHRoZSBleGFjdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxldmVsIGluIHRoZSBETlMgdHJlZSwgcG9saWN5 IGNhbiBvbmx5IGJlIHB1Ymxpc2hlZCBmb3IgdGhlIGV4YWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvbWFpbi4gIFRoZXJlIGlzIG5v IG1ldGhvZCBhdmFpbGFibGUgdG8gc3VjaCBkb21haW5zIHRvIGV4cHJlc3M8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb21haW4uICBUaGVyZSBpcyBubyBtZXRob2QgYXZhaWxh YmxlIHRvIHN1Y2ggZG9tYWlucyB0byBleHByZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxvd2VyIGxldmVsIHBvbGljeSBvciByZWNl aXZlIGZlZWRiYWNrIHJlcG9ydGluZyBmb3Igc2V0cyBvZiBkb21haW5zLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxvd2VyIGxldmVsIHBvbGljeSBvciByZWNlaXZlIGZlZWRi YWNrIHJlcG9ydGluZyBmb3Igc2V0cyBvZiBkb21haW5zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48 dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48ZW0+IHBhZ2UgMywgbGluZSAzODwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxh IG5hbWU9InBhcnQtcjMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVt PiBwYWdlIDMsIGxpbmUgNDU8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluIGEg bWFpbCBkZWxpdmVyeSBkZWNpc2lvbiwgYnV0IGlzIG5vdCBnZW5lcmFsbHkgdHJlYXRlZCBhczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluIGEgbWFpbCBkZWxpdmVyeSBkZWNp c2lvbiwgYnV0IGlzIG5vdCBnZW5lcmFsbHkgdHJlYXRlZCBhczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbml0aXZlIG9uIGl0cyBv d24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmaW5pdGl2ZSBvbiBpdHMg b3duLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBtZW1vIHByb3ZpZGVzIGEg c2ltcGxlIGV4dGVuc2lvbiB0byBETUFSQyBbUkZDNzQ4OV0gdG8gYWxsb3c8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIG1lbW8gcHJvdmlkZXMgYSBzaW1wbGUgZXh0ZW5z aW9uIHRvIERNQVJDIFtSRkM3NDg5XSB0byBhbGxvdzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRvcnMgb2YgUHVibGljIFN1ZmZp eCBEb21haW5zIChQU0RzKSB0byBleHByZXNzIHBvbGljeSBmb3I8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBvcGVyYXRvcnMgb2YgUHVibGljIFN1ZmZpeCBEb21haW5zIChQU0Rz KSB0byBleHByZXNzIHBvbGljeSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZ3JvdXBzIG9mIHN1YmRvbWFpbnMsIGV4dGVuZHMgdGhl IERNQVJDIFtSRkM3NDg5XSBwb2xpY3kgcXVlcnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBncm91cHMgb2Ygc3ViZG9tYWlucywgZXh0ZW5kcyB0aGUgRE1BUkMgW1JGQzc0ODld IHBvbGljeSBxdWVyeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBhbmQgcHJvY2VzcyBzdWNoIGEg cG9saWN5LCBkZXNjcmliZXMgcmVjZWl2ZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBhbmQgcHJvY2VzcyBzdWNoIGEgcG9saWN5LCBk ZXNjcmliZXMgcmVjZWl2ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgZmVlZGJhY2sgZm9yIHN1Y2ggcG9saWNpZXMsIGFuZCBwcm92aWRl cyBjb250cm9scyB0byBtaXRpZ2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGZlZWRiYWNrIGZvciBzdWNoIHBvbGljaWVzLCBhbmQgcHJvdmlkZXMgY29udHJvbHMgdG8gbWl0 aWdhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgcG90ZW50aWFsIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRo aXMgZXh0ZW5zaW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBvdGVudGlh bCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGV4dGVuc2lvbi48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOCIgLz48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIG1lbW8gYWxzbyBwcm92aWRlcyBhIG5ldyBETUFSQyBb UkZDNzQ4OV0gdGFnIHRvIGluZGljYXRlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZXF1ZXN0ZWQgaGFuZGxpbmcgcG9saWN5 IGZvciBub24tZXhpc3RlbnQgc3ViZG9tbWFpbnMuICBUaGlzIGlzPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwcm92aWRlZCBz cGVjaWZpY2FsbHkgdG8gc3VwcG9ydCBwaGFzZWQgZGVwbG95bWVudCBvZiBQU0QgRE1BUkMsIGJ1 dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgaXMgZXhwZWN0ZWQgdG8gYmUgdXNlZnVsIG1vcmUgZ2VuZXJhbGx5LiAgVW5kZXNp cmVkIHJlamVjdGlvbiByaXNrczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZm9yIG1haWwgcHVycG9ydGluZyB0byBiZSBmcm9t IGRvbWFpbnMgdGhhdCBkbyBub3QgZXhpc3QgYXJlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzdWJzdGFudGlhbGx5IGxvd2Vy IHRoYW4gZm9yIHRob3NlIHRoYXQgZG8sIHNvIHRoZSBvcGVyYXRpb25hbCByaXNrPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBv ZiByZXF1ZXN0aW5nIGhhcnNoIHBvbGljeSB0cmVhdG1lbnQgKGUuZy4gcmVqZWN0KSBpcyBsb3dl ci48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgQXMgYW4gYWRkaXRpb25hbCBiZW5lZml0LCB0aGUgUFNEIERNQVJDIGV4dGVuc2lvbiB3aWxs IGNsYXJpZnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBcyBhbiBhZGRpdGlv bmFsIGJlbmVmaXQsIHRoZSBQU0QgRE1BUkMgZXh0ZW5zaW9uIHdpbGwgY2xhcmlmeTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleGlzdGlu ZyByZXF1aXJlbWVudHMuICBCYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIG9mIERNQVJDIFtSRkM3 NDg5XSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleGlzdGluZyByZXF1aXJl bWVudHMuICBCYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIG9mIERNQVJDIFtSRkM3NDg5XSw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRE1B UkMgc2hvdWxkIGZ1bmN0aW9uIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBsZXZlbCBmb3IgZXhh Y3QgZG9tYWluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRE1BUkMgc2hvdWxk IGZ1bmN0aW9uIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBsZXZlbCBmb3IgZXhhY3QgZG9tYWlu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG1hdGNoZXMgKGkuZS4gaWYgYSBETUFSQyByZWNvcmQgd2VyZSBwdWJsaXNoZWQgZm9yICdleGFt cGxlJywgdGhlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGNoZXMgKGku ZS4gaWYgYSBETUFSQyByZWNvcmQgd2VyZSBwdWJsaXNoZWQgZm9yICdleGFtcGxlJywgdGhlbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBt YWlsIGZyb20gZXhhbXBsZUBleGFtcGxlIHNob3VsZCBiZSBzdWJqZWN0IHRvIERNQVJDIHByb2Nl c3NpbmcpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1haWwgZnJvbSBleGFt cGxlQGV4YW1wbGUgc2hvdWxkIGJlIHN1YmplY3QgdG8gRE1BUkMgcHJvY2Vzc2luZykuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRlc3Rp bmcgaGFkIHJldmVhbGVkIHRoYXQgdGhpcyBpcyBub3QgY29uc2lzdGVudGx5IGFwcGxpZWQgaW48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUZXN0aW5nIGhhZCByZXZlYWxlZCB0 aGF0IHRoaXMgaXMgbm90IGNvbnNpc3RlbnRseSBhcHBsaWVkIGluPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRpZmZlcmVudCBpbXBsZW1l bnRhdGlvbnMuICBQU0QgRE1BUkMgd2lsbCBoZWxwIGNsYXJpZnkgdGhhdCBETUFSQyBpczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMu ICBQU0QgRE1BUkMgd2lsbCBoZWxwIGNsYXJpZnkgdGhhdCBETUFSQyBpczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBub3QgbGltaXRlZCB0 byBvcmdhbml6YXRpb25hbCBkb21haW5zIGFuZCB0aGVpciBzdWItZG9tYWlucy48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub3QgbGltaXRlZCB0byBvcmdhbml6YXRpb25hbCBk b21haW5zIGFuZCB0aGVpciBzdWItZG9tYWlucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFRoZXJlIGFyZSB0d28gdHlwZXMgb2YgUHVibGljIFN1ZmZpeCBPcGVyYXRvcnMgKFBTT3Mp IGZvciB3aGljaCB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlcmUg YXJlIHR3byB0eXBlcyBvZiBQdWJsaWMgU3VmZml4IE9wZXJhdG9ycyAoUFNPcykgZm9yIHdoaWNo IHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDQi IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxpbmUg NDM8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI0IiAvPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA2LCBsaW5lIDExPC9lbT48L3RoPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjEuICBHZW5lcmFsIFVwZGF0ZXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4zLjEuICBHZW5lcmFsIFVwZGF0ZXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFJlZmVyZW5jZXMgdG8gIkRvbWFpbiBPd25lcnMiIGFsc28gYXBwbHkgdG8g UFNPcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBSZWZlcmVuY2VzIHRvICJE b21haW4gT3duZXJzIiBhbHNvIGFwcGx5IHRvIFBTT3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4zLjIuICBTZWN0aW9uIDYuMSBETUFSQyBQb2xpY3kgUmVjb3JkPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+My4yLiAgU2VjdGlvbiA2LjEgRE1BUkMgUG9saWN5IFJlY29yZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEIERNQVJDIHJlY29yZHMgYXJlIHB1Ymxp c2hlZCBhcyBhIHN1YmRvbWFpbiBvZiB0aGUgUFNELiAgRm9yIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFBTRCBETUFSQyByZWNvcmRzIGFyZSBwdWJsaXNoZWQgYXMgYSBz dWJkb21haW4gb2YgdGhlIFBTRC4gIEZvciB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEICIuZXhhbXBsZSIsIHRoZSBQU08gd291 bGQgcG9zdCBETUFSQyBwb2xpY3kgaW4gYSBUWFQgcmVjb3JkIGF0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgUFNEICIuZXhhbXBsZSIsIHRoZSBQU08gd291bGQgcG9zdCBETUFS QyBwb2xpY3kgaW4gYSBUWFQgcmVjb3JkIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJfZG1hcmMuZXhhbXBsZSIuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIl9kbWFyYy5leGFtcGxlIi48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOSIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjMuMy4gIFNlY3Rpb24gNi41LiAgRG9tYWluIE93bmVyIEFjdGlvbnM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+My4zLiAgU2VjdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42 LjMgR2VuZXJhbCBSZWNvcmQgRm9ybWF0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIEEgbmV3IHRhZyBpcyBhZGRlZCBh ZnRlciBmbzo8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgbnA6ICBSZXF1ZXN0ZWQgTWFpbCBSZWNlaXZlciBwb2xpY3kg Zm9yIG5vbi1leGlzdGVudCBzdWJkb21haW5zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAocGxhaW4tdGV4dDsgT1BUSU9O QUwpLiAgSW5kaWNhdGVzIHRoZSBwb2xpY3kgdG8gYmUgZW5hY3RlZCBieSB0aGU8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg IFJlY2VpdmVyIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBEb21haW4gT3duZXIuICBJdCBhcHBsaWVz IG9ubHkgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgICAgIG5vbi1leGlzdGVudCBzdWJkb21haW5zIG9mIHRoZSBkb21haW4g cXVlcmllZCBhbmQgbm90IHRvIGVpdGhlcjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgZXhpc3Rpbmcgc3ViZG9tYWlucyBv ciB0aGUgZG9tYWluIGl0c2VsZi4gIEl0cyBzeW50YXggaXMgaWRlbnRpY2FsPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICB0 byB0aGF0IG9mIHRoZSAicCIgdGFnIGRlZmluZWQgYmVsb3cuICBJZiBhYnNlbnQsIHRoZSBwb2xp Y3k8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgICAgIHNwZWNpZmllZCBieSB0aGUgInNwIiAoaWYgcHJlc2VudCkgYW5kIHRoZW4g dGhlICJwIiB0YWcsIGlmIG5vdCw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIE1VU1QgYmUgYXBwbGllZCBmb3Igbm9uLWV4 aXN0ZW50IHN1YmRvbWFpbnMuICBOb3RlIHRoYXQgIm5wIiB3aWxsPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBiZSBpZ25v cmVkIGZvciBETUFSQyByZWNvcmRzIHB1Ymxpc2hlZCBvbiBzdWJkb21haW5zIG9mPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg ICBPcmdhbml6YXRpb25hbCBEb21haW5zIGFuZCBQU0RzIGR1ZSB0byB0aGUgZWZmZWN0IG9mIHRo ZSBETUFSQzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgcG9saWN5IGRpc2NvdmVyeSBtZWNoYW5pc20gZGVzY3JpYmVkIGlu IERNQVJDIFtSRkM3NDg5XTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgU2VjdGlvbiA2LjYuMy48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+My40LiAg U2VjdGlvbjwvc3Bhbj4gNi41LiAgRG9tYWluIE93bmVyIEFjdGlvbnM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEluIGFkZGl0aW9uIHRvIHRoZSBETUFSQyBbUkZDNzQ4OV0gZG9tYWlu IG93bmVyIGFjdGlvbnMsIFBTT3MgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEluIGFkZGl0aW9uIHRvIHRoZSBETUFSQyBbUkZDNzQ4OV0gZG9tYWluIG93bmVyIGFjdGlv bnMsIFBTT3MgdGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICByZXF1aXJlIHVzZSBvZiBETUFSQyBvdWdodCB0byBtYWtlIHRoYXQgaW5m b3JtYXRpb24gYXZhaWxhYmxlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg cmVxdWlyZSB1c2Ugb2YgRE1BUkMgb3VnaHQgdG8gbWFrZSB0aGF0IGluZm9ybWF0aW9uIGF2YWls YWJsZSB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICByZWNlaXZlcnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVj ZWl2ZXJzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDEwIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+My48c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFu Pi4gIFNlY3Rpb24gNi42LjMuICBQb2xpY3kgRGlzY292ZXJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjMuPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj4uICBTZWN0aW9uIDYu Ni4zLiAgUG9saWN5IERpc2NvdmVyeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBu ZXcgc3RlcCBiZXR3ZWVuIHN0ZXAgMyBhbmQgNCBpcyBhZGRlZDo8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBBIG5ldyBzdGVwIGJldHdlZW4gc3RlcCAzIGFuZCA0IGlzIGFkZGVk OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgM0EuICBJZiB0aGUgc2V0IGlzIG5vdyBl bXB0eSBhbmQgdGhlIGxvbmdlc3QgUFNEIChTZWN0aW9uIDIuMykgb2YgdGhlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgM0EuICBJZiB0aGUgc2V0IGlzIG5vdyBlbXB0eSBhbmQg dGhlIGxvbmdlc3QgUFNEIChTZWN0aW9uIDIuMykgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERv bWFpbiBpcyBvbmUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGRldGVybWluZWQgaXM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBPcmdhbml6YXRpb25hbCBEb21haW4gaXMgb25l IHRoYXQgdGhlIHJlY2VpdmVyIGhhcyBkZXRlcm1pbmVkIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGFjY2VwdGFibGUgZm9yIFBT RCBETUFSQywgdGhlIE1haWwgUmVjZWl2ZXIgTVVTVCBxdWVyeSB0aGUgRE5TIGZvcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGFjY2VwdGFibGUgZm9yIFBTRCBETUFSQywg dGhlIE1haWwgUmVjZWl2ZXIgTVVTVCBxdWVyeSB0aGUgRE5TIGZvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBhIERNQVJDIFRYVCBy ZWNvcmQgYXQgdGhlIEROUyBkb21haW4gbWF0Y2hpbmcgdGhlIGxvbmdlc3QgUFNEPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYSBETUFSQyBUWFQgcmVjb3JkIGF0IHRoZSBE TlMgZG9tYWluIG1hdGNoaW5nIHRoZSBsb25nZXN0IFBTRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAoU2VjdGlvbiAyLjMpIGluIHBs YWNlIG9mIHRoZSBSRkM1MzIyLkZyb20gZG9tYWluIGluIHRoZSBtZXNzYWdlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKFNlY3Rpb24gMi4zKSBpbiBwbGFjZSBvZiB0aGUg UkZDNTMyMi5Gcm9tIGRvbWFpbiBpbiB0aGUgbWVzc2FnZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAoaWYgZGlmZmVyZW50KS4gIEEg cG9zc2libHkgZW1wdHkgc2V0IG9mIHJlY29yZHMgaXMgcmV0dXJuZWQuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKGlmIGRpZmZlcmVudCkuICBBIHBvc3NpYmx5IGVtcHR5 IHNldCBvZiByZWNvcmRzIGlzIHJldHVybmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDUiIC8+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYsIGxpbmUgMjk8 L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI1IiAvPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA3LCBsaW5lIDExPC9lbT48L3RoPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAoU2VjdGlvbiAyLjMpLiAgVGhlIHJlY2VpdmVyIHdvdWxkIGNo ZWNrIHRvIHNlZSBpZiB0aGF0IFBTRCBpcyBsaXN0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAoU2VjdGlvbiAyLjMpLiAgVGhlIHJlY2VpdmVyIHdvdWxkIGNoZWNrIHRvIHNl ZSBpZiB0aGF0IFBTRCBpcyBsaXN0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW4gdGhlIERNQVJDIFBTRCBSZWdpc3RyeSwgYW5kIGlm IHNvLCBwZXJmb3JtIHRoZSBwb2xpY3kgbG9va3VwIGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgaW4gdGhlIERNQVJDIFBTRCBSZWdpc3RyeSwgYW5kIGlmIHNvLCBwZXJmb3Jt IHRoZSBwb2xpY3kgbG9va3VwIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJfZG1hcmMuY29tcHV0ZS5jbG91ZGNvbXBhbnkuY29tLmNj dGxkIi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAiX2RtYXJjLmNvbXB1dGUu Y2xvdWRjb21wYW55LmNvbS5jY3RsZCIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBO b3RlOiBCZWNhdXNlIHRoZSBQU0QgcG9saWN5IHF1ZXJ5IGNvbWVzIGFmdGVyIHRoZSBPcmdhbml6 YXRpb25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE5vdGU6IEJlY2F1c2Ug dGhlIFBTRCBwb2xpY3kgcXVlcnkgY29tZXMgYWZ0ZXIgdGhlIE9yZ2FuaXphdGlvbmFsPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERvbWFp biBwb2xpY3kgcXVlcnksIFBTRCBwb2xpY3kgaXMgbm90IHVzZWQgZm9yIE9yZ2FuaXphdGlvbmFs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRG9tYWluIHBvbGljeSBxdWVyeSwg UFNEIHBvbGljeSBpcyBub3QgdXNlZCBmb3IgT3JnYW5pemF0aW9uYWw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9tYWlucyB0aGF0IGhh dmUgcHVibGlzaGVkIGEgRE1BUkMgW1JGQzc0ODldIHBvbGljeS4gIFNwZWNpZmljYWxseSw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb21haW5zIHRoYXQgaGF2ZSBwdWJsaXNo ZWQgYSBETUFSQyBbUkZDNzQ4OV0gcG9saWN5LiAgU3BlY2lmaWNhbGx5LDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGlzIGlzIG5vdCBh IG1lY2hhbmlzbSB0byBwcm92aWRlIGZlZWRiYWNrIGFkZHJlc3NlcyAoUlVBL1JVRikgd2hlbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoaXMgaXMgbm90IGEgbWVjaGFuaXNt IHRvIHByb3ZpZGUgZmVlZGJhY2sgYWRkcmVzc2VzIChSVUEvUlVGKSB3aGVuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuIE9yZ2FuaXph dGlvbmFsIERvbWFpbiBoYXMgZGVjbGluZWQgdG8gZG8gc28uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgYW4gT3JnYW5pemF0aW9uYWwgRG9tYWluIGhhcyBkZWNsaW5lZCB0byBk byBzby48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAx MSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjMuPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj4u ICBTZWN0aW9uIDcuICBETUFSQyBGZWVkYmFjazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4zLjxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+LiAgU2VjdGlvbiA3LiAgRE1BUkMg RmVlZGJhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE9wZXJhdGlvbmFsIG5vdGUg Zm9yIFBTRCBETUFSQzogRm9yIFBTT3MsIGZlZWRiYWNrIGZvciBub24tZXhpc3RlbnQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPcGVyYXRpb25hbCBub3RlIGZvciBQU0QgRE1B UkM6IEZvciBQU09zLCBmZWVkYmFjayBmb3Igbm9uLWV4aXN0ZW50PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvbWFpbnMgaXMgZGVzaXJl ZCBhbmQgdXNlZnVsLiAgU2VlIFNlY3Rpb24gNCBmb3IgZGlzY3Vzc2lvbiBvZjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvbWFpbnMgaXMgZGVzaXJlZCBhbmQgdXNlZnVsLiAg U2VlIFNlY3Rpb24gNCBmb3IgZGlzY3Vzc2lvbiBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcml2YWN5IENvbnNpZGVyYXRpb25zLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9uczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuICBQcml2YWN5IENvbnNpZGVyYXRpb25z PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIiIC8+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGVzZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFyZSBk ZXZlbG9wZWQgYmFzZWQgb24gdGhlIHJlcXVpcmVtZTxzcGFuIGNsYXNzPSJkZWxldGUiPnRuPC9z cGFuPnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhlc2UgcHJpdmFjeSBj b25zaWRlcmF0aW9ucyBhcmUgZGV2ZWxvcGVkIGJhc2VkIG9uIHRoZSByZXF1aXJlbWU8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5udDwvc3Bhbj5zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIFtSRkM2OTczXS4gIFRoZSBQcml2YWN5IENvbnNp ZGVyYXRpb25zIG9mIFtSRkM3NDg5XSBhcHBseSB0byB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgb2YgW1JGQzY5NzNdLiAgVGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMg b2YgW1JGQzc0ODldIGFwcGx5IHRvIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZG9jdW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjEu ICBGZWVkYmFjayBsZWFrYWdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4xLiAg RmVlZGJhY2sgbGVha2FnZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlkaW5n IGZlZWRiYWNrIHJlcG9ydGluZyB0byBQU09zIGNhbiwgaW4gc29tZSBjYXNlcywgY3JlYXRlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlkaW5nIGZlZWRiYWNrIHJlcG9y dGluZyB0byBQU09zIGNhbiwgaW4gc29tZSBjYXNlcywgY3JlYXRlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxlYWthZ2Ugb2YgaW5mb3Jt YXRpb24gb3V0c2lkZSBvZiBhbiBvcmdhbml6YXRpb24gdG8gdGhlIFBTTy4gIFRoaXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBsZWFrYWdlIG9mIGluZm9ybWF0aW9uIG91dHNp ZGUgb2YgYW4gb3JnYW5pemF0aW9uIHRvIHRoZSBQU08uICBUaGlzPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZm MDAxMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGxlYWthZ2UgY291bGQgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+YmUgPC9zcGFuPnBvdGVudGlhbGx5IGJlIHV0aWxpemVkIGFzIHBhcnQgb2YgYSBw cm9ncmFtIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGxlYWthZ2UgY291 bGQgcG90ZW50aWFsbHkgYmUgdXRpbGl6ZWQgYXMgcGFydCBvZiBhIHByb2dyYW0gb2Y8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcGVydmFz aXZlIHN1cnZlaWxsYW5jZSAoU2VlIFtSRkM3NjI0XSkuICBUaGVyZSBhcmUgcm91Z2hseSB0aHJl ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBlcnZhc2l2ZSBzdXJ2ZWlsbGFu Y2UgKFNlZSBbUkZDNzYyNF0pLiAgVGhlcmUgYXJlIHJvdWdobHkgdGhyZWU8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FzZXMgdG8gY29u c2lkZXI6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FzZXMgdG8gY29uc2lk ZXI6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTaW5nbGUgT3JnYW5pemF0aW9u IFBTRHMgKGUuZy4sICIuZ29vZ2xlIiksIFJVQSBhbmQgUlVGIHJlcG9ydHM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBTaW5nbGUgT3JnYW5pemF0aW9uIFBTRHMgKGUuZy4s ICIuZ29vZ2xlIiksIFJVQSBhbmQgUlVGIHJlcG9ydHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYmFzZWQgb24gUFNEIERNQVJDIGhh dmUgdGhlIHBvdGVudGlhbCB0byBjb250YWluIGluZm9ybWF0aW9uIGFib3V0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYmFzZWQgb24gUFNEIERNQVJDIGhhdmUgdGhlIHBv dGVudGlhbCB0byBjb250YWluIGluZm9ybWF0aW9uIGFib3V0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGVtYWlscyByZWxhdGVkIHRv IGVudGl0aWVzIG1hbmFnZWQgYnkgdGhlIG9yZ2FuaXphdGlvbi4gIFNpbmNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZW1haWxzIHJlbGF0ZWQgdG8gZW50aXRpZXMgbWFu YWdlZCBieSB0aGUgb3JnYW5pemF0aW9uLiAgU2luY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYm90aCB0aGUgUFNPIGFuZCB0aGUg T3JnYW5pemF0aW9uYWwgRG9tYWluIG93bmVycyBhcmUgY29tbW9uLDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIGJvdGggdGhlIFBTTyBhbmQgdGhlIE9yZ2FuaXphdGlvbmFs IERvbWFpbiBvd25lcnMgYXJlIGNvbW1vbiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdGhlcmUgaXMgbm8gYWRkaXRpb25hbCBwcml2 YWN5IHJpc2sgZm9yIGVpdGhlciBub3JtYWwgb3Igbm9uLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIHRoZXJlIGlzIG5vIGFkZGl0aW9uYWwgcHJpdmFjeSByaXNrIGZvciBl aXRoZXIgbm9ybWFsIG9yIG5vbi08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZXhpc3RlbnQgRG9tYWluIHJlcG9ydGluZyBkdWUgdG8g UFNEIERNQVJDLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGV4aXN0ZW50 IERvbWFpbiByZXBvcnRpbmcgZHVlIHRvIFBTRCBETUFSQy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0 LWw2IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA3LCBs aW5lIDI0PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNiIgLz48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgOCwgbGluZSA2PC9lbT48L3Ro Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBjb21wbGlhbmNlIHdpdGggUFNEIHBvbGljeS4g IERhdGEgb24gbm9uLWV4aXN0ZW50IGNvdXNpbiBkb21haW5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgY29tcGxpYW5jZSB3aXRoIFBTRCBwb2xpY3kuICBEYXRhIG9uIG5v bi1leGlzdGVudCBjb3VzaW4gZG9tYWluczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB3b3VsZCBiZSBzZW50IHRvIHRoZSBQU08uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgd291bGQgYmUgc2VudCB0byB0aGUg UFNPLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTXVsdGktb3JnYW5pemF0aW9u IFBTRHMgKGUuZy4sICIuY29tIikgdGhhdCBkbyBub3QgbWFuZGF0ZSBETUFSQzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIE11bHRpLW9yZ2FuaXphdGlvbiBQU0RzIChlLmcu LCAiLmNvbSIpIHRoYXQgZG8gbm90IG1hbmRhdGUgRE1BUkM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdXNhZ2U6IFByaXZhY3kgcmlz a3MgZm9yIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMgdGhhdCBoYXZlIG5vdDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHVzYWdlOiBQcml2YWN5IHJpc2tzIGZvciBPcmdhbml6 YXRpb25hbCBEb21haW5zIHRoYXQgaGF2ZSBub3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZGVwbG95ZWQgRE1BUkMgd2l0aGluIHN1 Y2ggUFNEcyBhcmUgc2lnbmlmaWNhbnQuICBGb3Igbm9uLURNQVJDPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgZGVwbG95ZWQgRE1BUkMgd2l0aGluIHN1Y2ggUFNEcyBhcmUg c2lnbmlmaWNhbnQuICBGb3Igbm9uLURNQVJDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMsIGFs bCBETUFSQyBmZWVkYmFjayB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMsIGFsbCBETUFSQyBm ZWVkYmFjayB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBQU08uICBQU0QgRE1BUkMgaXMgb3B0 LW91dCAoYnkgcHVibGlzaGluZyBhIERNQVJDIHJlY29yZCBhdCB0aGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBQU08uICBQU0QgRE1BUkMgaXMgb3B0LW91dCAoYnkgcHVi bGlzaGluZyBhIERNQVJDIHJlY29yZCBhdCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgT3JnYW5pemF0aW9uYWwgRG9tYWluIGxl dmVsKSB2aWNlIG9wdC1pbiwgd2hpY2ggd291bGQgYmUgdGhlIG1vcmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBPcmdhbml6YXRpb25hbCBEb21haW4gbGV2ZWwpIHZpY2Ug b3B0LWluLCB3aGljaCB3b3VsZCBiZSB0aGUgbW9yZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBkZXNpcmFibGUgY2hhcmFjdGVyaXN0 aWMuICBUaGlzIG1lYW5zIHRoYXQgYW55IG5vbi1ETUFSQzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3RpYy4gIFRoaXMgbWVhbnMgdGhh dCBhbnkgbm9uLURNQVJDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNCIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiB3b3VsZCBoYXZlIGl0PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Jzwvc3Bhbj5zIGZlZWRiYWNrIHJlcG9ydHMgcmVkaXJlY3RlZDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBvcmdhbml6YXRpb25hbCBkb21haW4gd291bGQg aGF2ZSBpdHMgZmVlZGJhY2sgcmVwb3J0cyByZWRpcmVjdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRvIHRoZSBQU08uICBUaGUg Y29udGVudCBvZiBzdWNoIHJlcG9ydHMsIHBhcnRpY3VsYXJseSBmb3I8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0byB0aGUgUFNPLiAgVGhlIGNvbnRlbnQgb2Ygc3VjaCBy ZXBvcnRzLCBwYXJ0aWN1bGFybHkgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGV4aXN0aW5nIGRvbWFpbnMsIGlzIHByaXZhY3kg c2Vuc2l0aXZlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGV4aXN0aW5n IGRvbWFpbnMsIGlzIHByaXZhY3kgc2Vuc2l0aXZlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUFNPcyB3aWxsIHJlY2VpdmUgZmVlZGJhY2sgb24gbm9uLWV4aXN0ZW50IGRvbWFpbnMs IHdoaWNoIG1heSBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTT3Mgd2ls bCByZWNlaXZlIGZlZWRiYWNrIG9uIG5vbi1leGlzdGVudCBkb21haW5zLCB3aGljaCBtYXkgYmU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg c2ltaWxhciB0byBleGlzdGluZyBPcmdhbml6YXRpb25hbCBEb21haW5zLiAgRmVlZGJhY2sgcmVs YXRlZCB0byBzdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2ltaWxhciB0 byBleGlzdGluZyBPcmdhbml6YXRpb25hbCBEb21haW5zLiAgRmVlZGJhY2sgcmVsYXRlZCB0byBz dWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGNvdXNpbiBkb21haW5zIGhhdmUgYSBzbWFsbCByaXNrIG9mIGNhcnJ5aW5nIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb3VzaW4g ZG9tYWlucyBoYXZlIGEgc21hbGwgcmlzayBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiByZWxhdGVk IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGFuIGFjdHVhbCBPcmdhbml6YXRpb25hbCBEb21haW4uICBUbyBtaW5pbWl6ZSB0aGlzIHBv dGVudGlhbCBjb25jZXJuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuIGFj dHVhbCBPcmdhbml6YXRpb25hbCBEb21haW4uICBUbyBtaW5pbWl6ZSB0aGlzIHBvdGVudGlhbCBj b25jZXJuLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBQU0QgRE1BUkMgZmVlZGJhY2sgaXMgYmVzdCBsaW1pdGVkIHRvIEFnZ3JlZ2F0ZSBS ZXBvcnRzLiAgRmVlZGJhY2s8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQU0Qg RE1BUkMgZmVlZGJhY2sgaXMgYmVzdCBsaW1pdGVkIHRvIEFnZ3JlZ2F0ZSBSZXBvcnRzLiAgRmVl ZGJhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUmVwb3J0cyBjYXJyeSBtb3JlIGRldGFpbGVkIGluZm9ybWF0aW9uIGFuZCBwcmVzZW50 IGEgZ3JlYXRlciByaXNrLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlcG9y dHMgY2FycnkgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhbmQgcHJlc2VudCBhIGdyZWF0ZXIg cmlzay48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIg Pjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw3IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA4LCBsaW5lIDc8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48 YSBuYW1lPSJwYXJ0LXI3IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl bT4gcGFnZSA4LCBsaW5lIDM3PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZD NzQ4OV0gYW5kIFtSRkM3OTYwXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UkZDNzQ4OV0gYW5kIFtSRkM3OTYwXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo ZSByaXNrcyBvZiB0aGUgaXNzdWVzIGlkZW50aWZpZWQgaW4gW1JGQzc0ODldLCBTZWN0aW9uIDEy LjUsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHJpc2tzIG9mIHRoZSBp c3N1ZXMgaWRlbnRpZmllZCBpbiBbUkZDNzQ4OV0sIFNlY3Rpb24gMTIuNSw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRXh0ZXJuYWwgUmVw b3J0aW5nIEFkZHJlc3NlcywgYXJlIGFtcGxpZmllZCBieSBQU0QgRE1BUkMuICBCeSBkZXNpZ24s PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRXh0ZXJuYWwgUmVwb3J0aW5nIEFk ZHJlc3NlcywgYXJlIGFtcGxpZmllZCBieSBQU0QgRE1BUkMuICBCeSBkZXNpZ24sPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBTRCBETUFS QyBjYXVzZXMgdW5yZXF1ZXN0ZWQgcmVwb3J0aW5nIG9mIGZlZWRiYWNrIHRvIGVudGl0aWVzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFNEIERNQVJDIGNhdXNlcyB1bnJlcXVl c3RlZCByZXBvcnRpbmcgb2YgZmVlZGJhY2sgdG8gZW50aXRpZXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXh0ZXJuYWwgdG8gdGhlIE9y Z2FuaXphdGlvbmFsIERvbWFpbi4gIFRoaXMgaXMgZGlzY3Vzc2VkIGluIG1vcmU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHRlcm5hbCB0byB0aGUgT3JnYW5pemF0aW9uYWwg RG9tYWluLiAgVGhpcyBpcyBkaXNjdXNzZWQgaW4gbW9yZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXRhaWwgaW4gU2VjdGlvbiA0Ljwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRldGFpbCBpbiBTZWN0aW9uIDQuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjYuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTUiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBUaGlzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmRvY3VtZW50IGRvZXMgbm90 IHJlcXVpcmUgYW55PC9zcGFuPiBJQU5BIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFjdGlvbnMuPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIDxzcGFuIGNsYXNz PSJpbnNlcnQiPnNlY3Rpb24gZGVzY3JpYmVzIGFjdGlvbnMgcmVxdWVzdGVkIHRvIGJlIGNvbXBs ZXRlZCBieSBJQU5BLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij42LjEuICBTdWJkb21haW4gUG9saWN5IFRhZzwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBJQU5BIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmlz IHJlcXVlc3RlZCB0byBhZGQgYSBuZXcgdGFnIHRvIERNQVJDIFRhZyBSZWdpc3RyeSBpbiB0aGU8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIERvbWFpbi1iYXNlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uLCBSZXBvcnRpbmcsIGFu ZCBDb25mb3JtYW5jZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgKERNQVJDKSBQYXJhbWV0ZXJzIFJlZ2lzdHJ5Ljwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICBUaGUgZW50cnkgaXMgYXMgZm9sbG93czo8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgKy0tLS0tLS0tLS0rLS0t LS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICB8IFRhZyBOYW1lIHwgUmVmZXJlbmNlIHwgU3RhdHVzICB8IERlc2NyaXB0aW9uICAgICAgICAg ICAgICAgICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgfCBucCAgICAgICB8IHRoaXMgICAg ICB8IGN1cnJlbnQgfCBSZXF1ZXN0ZWQgaGFuZGxpbmcgcG9saWN5IGZvciB8PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8ICAg ICAgICAgIHwgZG9jdW1lbnQgIHwgICAgICAgICB8IG5vbi1leGlzdGVudCBzdWJkb21haW5zICAg ICAgIHw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjcuICBSZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ny4gIFJlZmVy ZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ny4xLiAgTm9ybWF0aXZlIFJlZmVy ZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkMyMTE5XSAgQnJhZG5lciwg Uy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi LCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAg ICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5Nyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3 LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTkm Z3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgJmx0O2h0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFt ZT0icGFydC1sOCIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBh Z2UgOSwgbGluZSAyNTwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjgiIC8+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEwLCBsaW5lIDI1 PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIGFuZCBDb25mb3Jt YW5jZSAoRE1BUkMpIGFuZCBJbmRpcmVjdCBFbWFpbCBGbG93cyIsPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBhbmQgQ29uZm9ybWFuY2UgKERNQVJDKSBhbmQg SW5kaXJlY3QgRW1haWwgRmxvd3MiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIFJGQyA3OTYwLCBET0kgMTAuMTc0ODcv UkZDNzk2MCwgU2VwdGVtYmVyIDIwMTYsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICBSRkMgNzk2MCwgRE9JIDEwLjE3NDg3L1JGQzc5NjAsIFNlcHRlbWJlciAy MDE2LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc5 NjAmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgJmx0 O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk2MCZndDsuPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDODAyMF0gIEJvcnR6bWV5ZXIsIFMuIGFuZCBTLiBIdXF1 ZSwgIk5YRE9NQUlOOiBUaGVyZSBSZWFsbHkgSXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBbUkZDODAyMF0gIEJvcnR6bWV5ZXIsIFMuIGFuZCBTLiBIdXF1ZSwgIk5YRE9NQUlO OiBUaGVyZSBSZWFsbHkgSXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBOb3RoaW5nIFVuZGVybmVhdGgiLCBSRkMgODAy MCwgRE9JIDEwLjE3NDg3L1JGQzgwMjAsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICBOb3RoaW5nIFVuZGVybmVhdGgiLCBSRkMgODAyMCwgRE9JIDEwLjE3NDg3 L1JGQzgwMjAsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxNiwgJmx0O2h0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjODAyMCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDE2LCAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM4MDIwJmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFwcGVu ZGl4IEEuICBUaGUgRXhwZXJpbWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFw cGVuZGl4IEEuICBUaGUgRXhwZXJpbWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDE2IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZXJlIGFyZSB0 d28gZXhwZXJpbWVudGFsIHF1ZXN0aW9ucyBhZGRyZXNzZWQgaW4gdGhpcyBkb2N1bWVudDogb25l PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICByZWdhcmRpbmcgbWl0aWdhdGlvbiBvZiBQU0QgcmVsYXRlZCBwcml2YWN5IGNvbmNl cm5zIGFuZCB0aGUgb3RoZXIgb248L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoZSB1dGlsaXR5IG9mIHNwZWNpZnlpbmcgc2Vw YXJhdGUgRE1BUkMgcG9saWNpZXMgZm9yIG5vbi1leGlzdGVudDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgc3ViLWRvbWFpbnMu PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPkEuMS4gIFBTRCBETUFSQyBQcml2YWN5IENvbmNlcm4gTWl0aWdhdGlvbjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBt aXRpZ2F0ZSB0aGUgcHJpdmFjeSBjb25jZXJucyBhc3NvY2lhdGVkIHdpdGggTXVsdGktb3JnYW5p emF0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVG8gbWl0aWdhdGUgdGhl IHByaXZhY3kgY29uY2VybnMgYXNzb2NpYXRlZCB3aXRoIE11bHRpLW9yZ2FuaXphdGlvbjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQU0Rz IHRoYXQgZG8gbm90IG1hbmRhdGUgRE1BUkMgdXNhZ2UsIHNlZSBTZWN0aW9uIDQuMSwgYSBtZWNo YW5pc20gdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQU0RzIHRoYXQgZG8g bm90IG1hbmRhdGUgRE1BUkMgdXNhZ2UsIHNlZSBTZWN0aW9uIDQuMSwgYSBtZWNoYW5pc20gdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg aW5kaWNhdGUgd2hpY2ggUFNEcyBkbyBub3QgcHJlc2VudCB0aGlzIHByaXZhY3kgcmlzayBpcyBh cHByb3ByaWF0ZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmRpY2F0ZSB3 aGljaCBQU0RzIGRvIG5vdCBwcmVzZW50IHRoaXMgcHJpdmFjeSByaXNrIGlzIGFwcHJvcHJpYXRl LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGVyZSBhcmUgbXVsdGlwbGUgYXBwcm9hY2hlcyB0aGF0IGFyZSBwb3NzaWJsZS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGVyZSBhcmUgbXVsdGlwbGUgYXBwcm9hY2hl cyB0aGF0IGFyZSBwb3NzaWJsZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBl eHBlcmltZW50IGlzIHRvIGV2YWx1YXRlIGRpZmZlcmVudCBwb3NzaWJsZSBhcHByb2FjaGVzLiAg VGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGV4cGVyaW1lbnQgaXMg dG8gZXZhbHVhdGUgZGlmZmVyZW50IHBvc3NpYmxlIGFwcHJvYWNoZXMuICBUaGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXhwZXJpbWVu dCB3aWxsIGJlIGNvbXBsZXRlIHdoZW4gdGhlcmUgaXMgcm91Z2ggY29uc2Vuc3VzIG9uIGE8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleHBlcmltZW50IHdpbGwgYmUgY29tcGxl dGUgd2hlbiB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMgb24gYTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0ZWNobmljYWwgYXBwcm9hY2gg dGhhdCBpcyBkZW1vbnN0cmF0ZWQgdG8gYmUgb3BlcmF0aW9uYWxseSB1c2FibGU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0ZWNobmljYWwgYXBwcm9hY2ggdGhhdCBpcyBkZW1v bnN0cmF0ZWQgdG8gYmUgb3BlcmF0aW9uYWxseSB1c2FibGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIGVmZmVjdGl2ZSBhdCBtaXRp Z2F0aW5nIHRoZSBwcml2YWN5IGNvbmNlcm4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgYW5kIGVmZmVjdGl2ZSBhdCBtaXRpZ2F0aW5nIHRoZSBwcml2YWN5IGNvbmNlcm4uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90 ZD48dGg+PGEgbmFtZT0icGFydC1sOSIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9z bWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgMTU8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1l PSJwYXJ0LXI5IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFn ZSAxMSwgbGluZSAyMjwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQXMgb2YgdGhp cyB3cml0aW5nLCB0aHJlZSBhcHByb2FjaGVzIGhhdmUgYmVlbiBwcm9wb3NlZC4gIE5vbmUgb2Y8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBcyBvZiB0aGlzIHdyaXRpbmcsIHRo cmVlIGFwcHJvYWNoZXMgaGF2ZSBiZWVuIHByb3Bvc2VkLiAgTm9uZSBvZjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGVtIGFyZSBpZGVh bDo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGVtIGFyZSBpZGVhbDo8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEFuIGV4dGVuc2lvbiB0byB0aGUgUHVibGlj IFN1ZmZpeCBMaXN0IGF0IFtQU0xdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg byAgQW4gZXh0ZW5zaW9uIHRvIHRoZSBQdWJsaWMgU3VmZml4IExpc3QgYXQgW1BTTF08L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEEgZGVkaWNhdGVkIHJlZ2lzdHJ5IHF1ZXJpZWQg dmlhIEROUyAtIGFuIGV4YW1wbGUgb2Ygc3VjaCBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgQSBkZWRpY2F0ZWQgcmVnaXN0cnkgcXVlcmllZCB2aWEgRE5TIC0gYW4gZXhh bXBsZSBvZiBzdWNoIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgc2VydmljZSBpcyBkZXNjcmliZWQgaW4gQXBwZW5kaXggQi4xIGJl bG93PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgc2VydmljZSBpcyBkZXNj cmliZWQgaW4gQXBwZW5kaXggQi4xIGJlbG93PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBBbiBJQU5BIHJlZ2lzdHJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg byAgQW4gSUFOQSByZWdpc3RyeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxh IG5hbWU9ImRpZmYwMDE3IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPkEuMi4gIE5vbi1FeGlzdGVudCBT dWJkb21haW4gUG9saWN5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFBTT3MgdGhhdCBwbGFuIHRvIGltcGxlbWVudCBQ U0QgRE1BUkMgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGUgYWJpbGl0eTwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdG8gZGVzY3Jp YmUgZGlzdGluY3QgcG9saWNpZXMgZm9yIGV4aXN0aW5nIGFuZCBub24tIGV4aXN0aW5nIHN1Yi08 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGRvbWFpbnMgd291bGQgZmFjaWxpdGF0ZSBQU0QgRE1BUkMgZGVwbG95bWVudC4gIFRo ZXJlIGFyZSBhbHNvPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBzdWdnZXN0aW9ucyB0aGF0IGl0IHdvdWxkIGJlIG1vcmUgZ2Vu ZXJhbGx5IHVzZWZ1bCBmb3IgRE1BUkMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIER1cmluZyB0aGUgcGVyaW9kIG9m IHRoZSBleHBlcmltZW50LCB1cHRha2Ugb2YgdGhlIG5ldyAnbnAnIHRhZyB3aWxsPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBi ZSBldmFsdWF0ZWQgdG8gc3VwcG9ydCBhc3Nlc3NtZW50IG9mIHRoZSB1dGlsaXR5IG9mIGluY2x1 ZGluZyAnbnAnPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBpbiBhIGZ1dHVyZSwgbm9uLWV4cGVyaW1lbnRhbCB1cGRhdGUuPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFwcGVu ZGl4IEIuICBETUFSQyBQU0QgUmVnaXN0cnkgRXhhbXBsZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij5BcHBlbmRpeCBCLiAgRE1BUkMgUFNEIFJlZ2lzdHJ5IEV4YW1wbGVzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTgiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBUbyBmYWNpbGlhdGUgZXhwZXJpbWVudGF0aW9uIGFyb3VuZCBkYXRh IGxlYWthZ2UgbWl0aWdhdGlvbiwgc2FtcGxlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBUbyBmYWNpbGk8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50PC9zcGFuPmF0ZSBleHBlcmlt ZW50YXRpb24gYXJvdW5kIGRhdGEgbGVha2FnZSBtaXRpZ2F0aW9uLCBzYW1wbGVzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIHRoZSBE TlMgYmFzZWQgYW5kIElBTkEgbGlrZSByZWdpc3RyaWVzIGFyZSBhdmFpbGFibGUgYXQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvZiB0aGUgRE5TIGJhc2VkIGFuZCBJQU5BIGxp a2UgcmVnaXN0cmllcyBhcmUgYXZhaWxhYmxlIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtwc2RkbWFyYy5vcmddLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtwc2RkbWFyYy5vcmddLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+Qi4xLiAgRE1BUkMgUFNEIEROUyBRdWVyeSBTZXJ2aWNlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+Qi4xLiAgRE1BUkMgUFNEIEROUyBRdWVyeSBTZXJ2aWNlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBIHNhbXBsZSBzdGFuZC1hbG9uZSBETlMgcXVl cnkgc2VydmljZSBpcyBhdmFpbGFibGUgYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBBIHNhbXBsZSBzdGFuZC1hbG9uZSBETlMgcXVlcnkgc2VydmljZSBpcyBhdmFpbGFibGUg YXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgW3BzZGRtYXJjLm9yZ10uICBJdCB3YXMgZGV2ZWxvcGVkIGJhc2VkIG9uIHRoZSBjb250ZW50 cyBzdWdnZXN0ZWQgZm9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW3BzZGRt YXJjLm9yZ10uICBJdCB3YXMgZGV2ZWxvcGVkIGJhc2VkIG9uIHRoZSBjb250ZW50cyBzdWdnZXN0 ZWQgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGFuIElBTkEgcmVnaXN0cnkgaW4gYW4gZWFybGllciByZXZpc2lvbiBvZiB0aGlzIGRy YWZ0LiAgVXNhZ2Ugb2YgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW4g SUFOQSByZWdpc3RyeSBpbiBhbiBlYXJsaWVyIHJldmlzaW9uIG9mIHRoaXMgZHJhZnQuICBVc2Fn ZSBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgc2VydmljZSBpcyBkZXNjcmliZWQgb24gdGhlIHdlYiBzaXRlLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlcnZpY2UgaXMgZGVzY3JpYmVkIG9uIHRoZSB3ZWIg c2l0ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3Ry PgogICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+ PGEgbmFtZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMTggY2hhbmdlIGJsb2Nrcy4mbmJz cDs8L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT4z MiBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48 aT45NCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8 dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlz IGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQxLiBUaGUgbGF0ZXN0IHZlcnNp b24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90 b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4g PC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAgIDwvaHRtbD4K --nextPart10805324.Ar2neLQE0L-- From nobody Tue Jul 16 22:18:56 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 B7032120125 for ; Tue, 16 Jul 2019 22:18: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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=BnyiUTDg; dkim=pass (2048-bit key) header.d=kitterman.com header.b=op4OQYc9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEkHbFjXDLYn for ; Tue, 16 Jul 2019 22:18:53 -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 4EF45120058 for ; Tue, 16 Jul 2019 22:18:53 -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 58B41F805B5 for ; Wed, 17 Jul 2019 01:18:52 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563340732; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UvjsoFuOUhmtGiFKY0oRQpBinl3tg9adQb5q8oYQ3Tg=; b=BnyiUTDg/Z1oRVDau1Xo9DNY2YsE9b2Js3VG1PJl0mB01KpDR+0SWJC+ jxWXj3an7jrflrHqV4h7RT8fxE49CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563340732; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UvjsoFuOUhmtGiFKY0oRQpBinl3tg9adQb5q8oYQ3Tg=; b=op4OQYc9UuMGdCfAgr9DGfldmTBWECLeQxz5+aGwlj9adHCaW0IY+a6f DhtopYIZl368lH6VZVrcXzScLiWCHR42smPgLQQdMg4YTuLkMWxNururnY M7Vzevh51XlKtc9SsxrQ+JTNQa6CMS9cwJm0OwBbDBtE+4i2+N+dBWuXxH gIqQoUI59/WpClh5lfsQwLZbnYuTqu3ZfQN+HTxqh3QTlZSxtnvp5Q1+cq /jT8hhLBrETjsBtS89jUY6c21U9M+UMxCGzzRYgjl11WW6YP4BcUYxqzqo EIQ2wccC3WKEYXm6PPgCs1TAUi/HrZ5prMtSKikUPzQBiusKQ+ibdQ== Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id E1254F8008C for ; Wed, 17 Jul 2019 01:18:51 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 01:18:50 -0400 Message-ID: <4893889.n8NqrlkhcF@l5580> In-Reply-To: <1801771.HRRXnOL2G4@l5580> References: <1801771.HRRXnOL2G4@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 17 Jul 2019 05:18:56 -0000 On Friday, July 12, 2019 1:22:21 PM EDT Scott Kitterman wrote: > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > As Secretary, there are three items that have not yet reached consensus > > that must be resolved during WGLC: > > > > 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 > > It's been a pretty quiet last call. I think the document itself is probably > in pretty good shape with these questions as outliers. Shortly I plan to > send a separate email on each of these with my perspective on both the > issue and my read of the discussion so far so we can focus on driving each > question to closure. I think we've had some good discussion since Friday. Here's where I think we are now: #1. I think we incorporate both the specific suggestions Tim Draegen made earlier in the month and we should incorporate changes from Kurt Andersen in https://mailarchive.ietf.org/arch/msg/dmarc/7Qjo6oEoUpPGvCWVFZHyBeCDI44 : Drop the sentence from section 1, make the 2.2 change, drop willing to accept in 2.6 (which I think cures the section 4 comment), and make the 3.5 change. Addition of np is covered in #3. #2. I think we've worked out text and we just need to add it. #3. I think we're close on text with the only open questions being does np fall back to sp or p and do people agree with the Appendix A words. Pretty close. If the group accepts my rationale for the sp fallback, then I think it's pretty clear what changes the document needs after last call. Scott K From nobody Tue Jul 16 22:19: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 1F2AE120178 for ; Tue, 16 Jul 2019 22:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkm264bHfd0d for ; Tue, 16 Jul 2019 22:19:07 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 6ECFC1201CC for ; Tue, 16 Jul 2019 22:19:07 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id s20so23678133otp.4 for ; Tue, 16 Jul 2019 22:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3CrPOH8vAftdPzQ3izPoFshAuxFETPgMCdfKLam7a2s=; b=tZZ+k40SPuR86m00C44ZmDGUv/p+zVyWHbZ7WOXt1CLEoZMzW2zLiqUTl8KGIKye25 AjZ/1LRQ2+EFC9b6k6zzjUyuPGgQGY6PjJp7Nsx7fl0Cs2dT7nRYQ5A9ErhbikWNPGF+ XB7DPbxawb/NiKS0XiUI/tz5C0Z8aDHrem0v4eAMcc4a7Nb5066w+ejCs3BwFaDA0GhU TjehcyoDzkdy3n/Bhg0tX573X2MTF9Fw8KFP4VS/fM9P4WKbgxbAtn6Jm13lGwGYEHYT i138wIr3mmO/WdUQALGClPVX3HAjClaWEN70XZQ5tbssXOwJ0HfXJtWfJlALCPHF/r2Y NYUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3CrPOH8vAftdPzQ3izPoFshAuxFETPgMCdfKLam7a2s=; b=gBPPDKROGAjkD1CXNYoD/dk6bnS0NJZd9jKAbjdoNgdsX/gWVPF0GdfA08opWRSbyq C2F5kxD4PapskGUXQuvmQihwaHpjh+avU38O709jQm8vvGTPHeq7aWBAlH0lpU1EVf8O 6bLKonuqYK8ZypaVgchAPDo2eXzvpMTEe1Ln4xG0Z8GL13eyUI5hp/LyQkjrNybtVZRV L3RRd3ydUBN309V+ueyPSl80YiyRHP9/jehlbSkzQ+MowJpTCMaQ8Tg1kQAMrLXkDccG XnOlfLOYKkftmF01KFpyV8I/TAB6VihMAB1vI97TnmZvrESLuuNGiTs+yCAFqo8IpwGy f3FA== X-Gm-Message-State: APjAAAWMHXmiK9w6We00cEvasI2uq0XoRZAr+v3F81bM3eON8XHZ5fM2 6oQtA5ml39WeYZVAJzS9rLtq3PGWmrOYGT2MvkYqgvPI X-Google-Smtp-Source: APXvYqzSKPLXaGAxNY/FeseVSK9Aa2LsnDPld/6oHVX6XxcSWcGI24K2qN4THl3EgaZPPxZ428iQi+/llBCJ4N8eBh0= X-Received: by 2002:a9d:6f09:: with SMTP id n9mr26385076otq.335.1563340746406; Tue, 16 Jul 2019 22:19:06 -0700 (PDT) MIME-Version: 1.0 References: <4789054.Ip9ilXyiH0@l5580> <553D43C8D961C14BB27C614AC48FC0311CAA91FE@UMECHPA7D.easf.csd.disa.mil> <1808303.aIhlromXIS@l5580> In-Reply-To: <1808303.aIhlromXIS@l5580> From: Seth Blank Date: Tue, 16 Jul 2019 22:18:50 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000da552f058dd9a1e5" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 05:19:12 -0000 --000000000000da552f058dd9a1e5 Content-Type: text/plain; charset="UTF-8" As an individual- On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman wrote: > Although a few people have suggested this, I think it would be a mistake > because it would cause a gratuitous incompatibility with RFC 7468. > The people suggesting this are the people asking for np= in the first place. > I think it is a desirable characteristic that the addition of np not > disturb > existing expectations. If a recipient that is a participant in the > experiment > attempts to determine policy for a sub-domain without 'np', then the > result > should match what a non-participant gets. > I'm not certain this is desirable for PSD in the context of an experiment around np=. Specifically, the point of np= is for strict enforcement for non-existent domains while the remainder of the zone gets its act together moving registered domains to policies more strict than none. Since, a) nearly all sp= policies in the world are set to "none", and b) sp= is meaningless at the PSD level anyway, I concur that np= should default to p=. Or put a different way, the tags serve very different use cases, and in the wild, sp= will generally be none, whereas np= will generally be reject/quarantine. p= is the the meaningful tie-breaker here at the PSD level if no np= is set. This (np='s default) should also be called out as part of the experiment around np if the group doesn't reach consensus before WGLC ends tomorrow. --000000000000da552f058dd9a1e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual-

On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman <sklist@kitterman.com> wrote:
Although a few people have suggested this, I think it would be a mista= ke
because it would cause a gratuitous incompatibility with RFC 7468.

The people suggesting this are the people askin= g for np=3D in the first place.
=C2=A0
I think it is a desirable characteristic that = the addition of np not disturb
existing expectations.=C2=A0 If a recipient that is a participant in the ex= periment
attempts to determine policy for a sub-domain without 'np', then th= e result
should match what a non-participant gets.

I'm not certain this is desirable for PSD in the context of an exper= iment around np=3D.

Specifically, the point of np= =3D is for strict enforcement for non-existent domains while the remainder = of the zone gets its act together moving registered domains to policies mor= e strict than none. Since, a) nearly all sp=3D policies in the world are se= t to "none", and b) sp=3D is meaningless at the PSD level anyway,= I concur that np=3D should default to p=3D.

Or pu= t a different way, the tags serve very different use cases, and in the wild= , sp=3D will generally be none, whereas np=3D will generally be reject/quar= antine. p=3D is the the meaningful tie-breaker here at the PSD level if no = np=3D is set.

This (np=3D's default) should al= so be called out as part of the experiment around np if the group doesn'= ;t reach consensus before WGLC ends tomorrow.

--000000000000da552f058dd9a1e5-- From nobody Tue Jul 16 22:40:17 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 00C6D120148 for ; Tue, 16 Jul 2019 22:40:16 -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=8GvSH3cG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=MLs2CX1P Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCLoLjYtAjk1 for ; Tue, 16 Jul 2019 22:40:14 -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 6ABF812006B for ; Tue, 16 Jul 2019 22:40:14 -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 74F37F80045 for ; Wed, 17 Jul 2019 01:39:43 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563341983; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UZ8ZYFeL6wXtxMD9CFt4YIsUlwM0zTnFCahIhUGVnsw=; b=8GvSH3cGy6WwKS9JD1Oo7540NTzHgn7ybIDBsPUvhCOQa6xMLCbgcBqK ccJGEIlmzTX6Ntst1FLBYtiaP8fyAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563341983; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=UZ8ZYFeL6wXtxMD9CFt4YIsUlwM0zTnFCahIhUGVnsw=; b=MLs2CX1PpO08L/vg+/OsVIJMoXs3dSlfAP354SWmj30a8f3OB1L/Y/fX OE5OsMcrVzoTpzAvNqz6Mgk9SsltHfsTD4IlHAiswOPf+FGAjE0GCvku0K yt4Obt7ipJ8UvZR3QGJQlQ2htHsDykbArFKpQ+x2gM9p/vzDDzR/o+pAOS mil3Jxq72XK5C0WX+FayJQ0bzxmhbWCjIQAjBDGT1R7ALmyvSffImjvlwf pd2TIDA3nmN8HsrB65FaabL82U4phUo4LtQhrBYCN642GpgEZjfIIMx9GF WXP4/jOgJkQmvu5exh8ZIUG+yrEktwTElxHHl1NomMbsdwNnii0M2w== Received: from l5580.localnet (unknown [IPv6:2600:380:4a72:99c3:ca:14c:24f3:8d22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 139AAF80042 for ; Wed, 17 Jul 2019 01:39:42 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 01:39:41 -0400 Message-ID: <1692123.ljdY5SVR4M@l5580> In-Reply-To: References: <1808303.aIhlromXIS@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 05:40:16 -0000 On Wednesday, July 17, 2019 1:18:50 AM EDT Seth Blank wrote: > As an individual- > > On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman > > wrote: > > Although a few people have suggested this, I think it would be a mistake > > because it would cause a gratuitous incompatibility with RFC 7468. > > The people suggesting this are the people asking for np= in the first place. > > I think it is a desirable characteristic that the addition of np not > > disturb > > existing expectations. If a recipient that is a participant in the > > experiment > > attempts to determine policy for a sub-domain without 'np', then the > > result > > should match what a non-participant gets. > > I'm not certain this is desirable for PSD in the context of an experiment > around np=. > > Specifically, the point of np= is for strict enforcement for non-existent > domains while the remainder of the zone gets its act together moving > registered domains to policies more strict than none. Since, a) nearly all > sp= policies in the world are set to "none", and b) sp= is meaningless at > the PSD level anyway, I concur that np= should default to p=. > > Or put a different way, the tags serve very different use cases, and in the > wild, sp= will generally be none, whereas np= will generally be > reject/quarantine. p= is the the meaningful tie-breaker here at the PSD > level if no np= is set. > > This (np='s default) should also be called out as part of the experiment > around np if the group doesn't reach consensus before WGLC ends tomorrow. Let's be clear: If the experiment around 'np' is successful and it is included in a future non-experimental update, then it will have enough deployment that changing its behavior will almost certainly fall into the too hard bucket without an amazingly good reason. While the experiment may conclude 'np' isn't worth doing, I think we should assume that if it is carried forward, then it will be the way we define it in this document. So, "It's an experiment" is not, in my view, a useful reason to accept interoperability issues we can avoid. I think you are reading the request backwards. Yes, the point of 'np' is to allow for a stricter sub-domain policy, but that's to support early deployment of strict PSD level policies without breaking org domains that are still deploying/have not deployed DMARC. Case: PSO mandates all orgs deploy DMARC, but that's not done yet. PSO wants to deploy PSD DMARC for reject at the PSD level and for non-existent domains, but leave non-DMARC deployed existing domains at none. PSO publishes these policieis for the PSD: p=reject, sp=none, np=reject Results (for org domains) Org domain with DMARC: Use org policy Org domain with no DMARC: Regular DMARC: No DMARC policy, no feedback PSD DMARC receiver: policy is none, feedback to PSO if requested Non-existent domain: Regular DMARC: No DMARC policy, no feedback PSD DMARC receiver: policy is reject, feedback to PSO if requested Having 'np' fall back to 'p' doesn't actually solve the problem you claim to be solving since it only affects non-implementers. I believe that's the exact requested case and the changeset I've provided supports that without creating a situation where every implementer of the experiment suddenly starts processing existing DMARC records differently (which I think would be very bad). Scott K From nobody Tue Jul 16 22:55:03 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 1617412015B for ; Tue, 16 Jul 2019 22:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94KbmYzqnCb9 for ; Tue, 16 Jul 2019 22:54:58 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 8E97A120140 for ; Tue, 16 Jul 2019 22:54:58 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id z23so23708013ote.13 for ; Tue, 16 Jul 2019 22:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CL5QSqZXjs2xEMZP+4XW03fXt3Nw7EkVS8giwHAqjyY=; b=PJlJlKTJDWED0xR+fKgkaxURwmwEC0DNYLiziyu4tlbLS+WjdYPtAeRZl764+aIqPB Pi8iUUWoSQZhhraWpv2dcJEPeM/8xxcEYti+hANbpezbOOVOrkFPAJXc+FZ86AHF/6Kj ATm2s42l6DoarczEWvSSLq8l2/6XJhz2kmCVf4g1WDwR7xkTLXWAUGJdByp0DKq/uMeO IgqW4TalboB/cmDaKtcW8psejwRniKYHRhP/Y1wWyoaISb6f/7FJwsj4irBmPTOIyuoS 9WAXre5eOUATwokAYJ6UwSRKSRanH0QrIQzwDdJLgMdnx9GCstr3dvRjdgZqvZ4k3J6G McAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CL5QSqZXjs2xEMZP+4XW03fXt3Nw7EkVS8giwHAqjyY=; b=nrkNhfAJzsstEx6o01fuLW1oVzpaydvDt67On37HnMohP5HwpcBCo+OtZJkP+Fy0Gb OZYd47Ff7vyJkNxJIxkV17o1XpS+DGSsqknUCgcMZeyd7fIG+ufJ9LsUc8SHBqhHHsNF /Z8J6I70M9aPd7upVY33a3vKlcBCeRrQrieBPa22MQxj++3xVwZ5AJkT1CUJ+X8Fwcda cN/XcZovDTLyThr1pnIIZwUCCqYJXiZLtj1gKu7RXpPkrRMDkNtF1/A3Jc1alrxtXQO/ 4zIljNHhCgjvKSEuqsmjbr6lPSdYLZP4ymfbyIpB67Nl/6HX5Q+V+XwE0HmDHLkZ7l0d cpaA== X-Gm-Message-State: APjAAAVFKooXD/FpjhPsDuffJafL+rERAop+LWyCFc8IO7Bb48jcNGRF 1ToZZXfHBzjBToNK5vr7UoSNs77DyRpWDWoQvvfEoJbQ X-Google-Smtp-Source: APXvYqwtq6F5xKXEOShPcScIFxdDgsfiMkPzVss/y3MR7gT641ZrBM1k1hIBVBUGvpM3YDnyAMdv1y8uKqQt+u/LYzA= X-Received: by 2002:a9d:7643:: with SMTP id o3mr26013335otl.49.1563342897361; Tue, 16 Jul 2019 22:54:57 -0700 (PDT) MIME-Version: 1.0 References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> In-Reply-To: <1692123.ljdY5SVR4M@l5580> From: Seth Blank Date: Tue, 16 Jul 2019 22:54:41 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000000f92fc058dda2257" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 05:55:01 -0000 --0000000000000f92fc058dda2257 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman wrote: > Yes, the point of 'np' is to allow for a stricter sub-domain policy, but > that's to support early deployment of strict PSD level policies without > breaking org domains that are still deploying/have not deployed DMARC. > I absolutely agree with this. > Case: > > PSO mandates all orgs deploy DMARC, but that's not done yet. PSO wants to > deploy PSD DMARC for reject at the PSD level and for non-existent domains, > but > leave non-DMARC deployed existing domains at none. PSO publishes these > policieis for the PSD: > > p=reject, sp=none, np=reject > Ah, I see what you're saying here. I honestly couldn't understand why you were talking about sp=none at all within a PSD context. I thought the solution to this scenario was to do as the PSO p=none; np=reject. I actually like p=reject; sp=none; better here, because that lets the PSD lock itself down as a sending domain. But to me, this also makes it clear that np= should use the p= not the sp= as its default. That said, I feel less strongly about this now, and can see merit in inheritance from either side (or from a hard default of none, for that matter, although I'd strongly argue against that personally...). > Having 'np' fall back to 'p' doesn't actually solve the problem you claim > to > be solving since it only affects non-implementers. > This I don't understand. The results you outlined are exactly what I think should happen. > I believe that's the exact requested case and the changeset I've provided > supports that without creating a situation where every implementer of the > experiment suddenly starts processing existing DMARC records differently > (which > I think would be very bad). > I don't think I properly understand what you're saying. Can you clarify this point? Thanks! S --0000000000000f92fc058dda2257 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2019 at 10:40 PM Scott Ki= tterman <sklis= t@kitterman.com> wrote:
Yes, the point of 'np' is= to allow for a stricter sub-domain policy, but
that's to support early deployment of strict PSD level policies without=
breaking org domains that are still deploying/have not deployed DMARC.
<= /blockquote>

I absolutely agree with this.
=C2= =A0
Case:

PSO mandates all orgs deploy DMARC, but that's not done yet.=C2=A0 PSO = wants to
deploy PSD DMARC for reject at the PSD level and for non-existent domains, = but
leave non-DMARC deployed existing domains at none.=C2=A0 PSO publishes thes= e
policieis for the PSD:

p=3Dreject, sp=3Dnone, np=3Dreject

Ah, = I see what you're saying here. I honestly couldn't understand why y= ou were talking about sp=3Dnone at all within a PSD context. I thought the = solution to this scenario was to do as the PSO p=3Dnone; np=3Dreject. I act= ually like p=3Dreject; sp=3Dnone; better here, because that lets the PSD lo= ck itself down as a sending domain. But to me, this also makes it clear tha= t np=3D should use the p=3D not the sp=3D as its default.

That said, I feel less strongly about this now, and can see merit i= n inheritance from either side (or from a hard default of none, for that ma= tter, although I'd strongly argue against that personally...).
=C2=A0
Having '= ;np' fall back to 'p' doesn't actually solve the problem yo= u claim to
be solving since it only affects non-implementers.
This I don't understand. The results you outlined are exact= ly what I think should happen.
=C2=A0
I believe that's the exact requested case a= nd the changeset I've provided
supports that without creating a situation where every implementer of the <= br> experiment suddenly starts processing existing DMARC records differently (w= hich
I think would be very bad).

I don't= think I properly understand what you're saying. Can you clarify this p= oint?

Thanks!

S
--0000000000000f92fc058dda2257-- From nobody Tue Jul 16 23:27:03 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 C0E3B120140 for ; Tue, 16 Jul 2019 23:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=0WgtKjsc; dkim=pass (2048-bit key) header.d=kitterman.com header.b=N2V1kvNk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0_HTjY_5549 for ; Tue, 16 Jul 2019 23:27:00 -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 D0E7012006D for ; Tue, 16 Jul 2019 23:26:59 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CE050F80045; Wed, 17 Jul 2019 02:26:28 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563344788; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u0maflmLf6p28POLogAyignKfZ312y30A6WGNYaIKME=; b=0WgtKjsceMbuz76YiiDycwLeSWYXzz2UzMaSdSsFucOxtE9CnixUXmOK DWS3WFwhuEQuQ8asAsYet/L/Ota1Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563344788; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=u0maflmLf6p28POLogAyignKfZ312y30A6WGNYaIKME=; b=N2V1kvNkZK4U6wdXmNGu/ubqMJjp5S8BFDbrRASuRWBuJPkFMF7hu4QH RA+4SkJ9o/+XPslXMCXSgQDclDmhUCSKu0Jqqo6F91F60ZPiLbSWks3D7M aab00+IXPsMIzf1G+7HRnms7vo/Wet9FAoHreHUfKxZg7FYgPX9UuC0DCX PeE+qLryfUKSLWxlZ0on4Ft/qlw6fm7Fn5rwcw95au7QUDNKB2jwD6OupV ld7386pCJahtjMiQI7+7qtTN+y91RVZhsWHHWkwf478p1XDS5+kQ3/dBXe oqPGDEsVvPJ5+2qbYhzSxRo2GRBxB9X+XLJGIbb/oAYwOqHziGqivw== Received: from [10.56.245.58] (mobile-166-170-45-222.mycingular.net [166.170.45.222]) by interserver.kitterman.com (Postfix) with ESMTPSA id D28EBF80042; Wed, 17 Jul 2019 02:26:27 -0400 (EDT) Date: Wed, 17 Jul 2019 06:26:25 +0000 In-Reply-To: References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> 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] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 06:27:02 -0000 On July 17, 2019 5:54:41 AM UTC, Seth Blank wrote: >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman >wrote: > >> Yes, the point of 'np' is to allow for a stricter sub-domain policy, >but >> that's to support early deployment of strict PSD level policies >without >> breaking org domains that are still deploying/have not deployed >DMARC=2E >> > >I absolutely agree with this=2E > > >> Case: >> >> PSO mandates all orgs deploy DMARC, but that's not done yet=2E PSO >wants to >> deploy PSD DMARC for reject at the PSD level and for non-existent >domains, >> but >> leave non-DMARC deployed existing domains at none=2E PSO publishes >these >> policieis for the PSD: >> >> p=3Dreject, sp=3Dnone, np=3Dreject >> > >Ah, I see what you're saying here=2E I honestly couldn't understand why >you >were talking about sp=3Dnone at all within a PSD context=2E I thought the >solution to this scenario was to do as the PSO p=3Dnone; np=3Dreject=2E I >actually like p=3Dreject; sp=3Dnone; better here, because that lets the P= SD >lock itself down as a sending domain=2E But to me, this also makes it >clear >that np=3D should use the p=3D not the sp=3D as its default=2E See if you still feel that way after considering backward compatibility = =2E=2E=2E >That said, I feel less strongly about this now, and can see merit in >inheritance from either side (or from a hard default of none, for that >matter, although I'd strongly argue against that personally=2E=2E=2E)=2E > > >> Having 'np' fall back to 'p' doesn't actually solve the problem you >claim >> to >> be solving since it only affects non-implementers=2E >> > >This I don't understand=2E The results you outlined are exactly what I >think >should happen=2E I think we agree on the goal, the difference is only about implementation = details and impact on non-particpants in the experiment=2E > >> I believe that's the exact requested case and the changeset I've >provided >> supports that without creating a situation where every implementer of >the >> experiment suddenly starts processing existing DMARC records >differently >> (which >> I think would be very bad)=2E >> > >I don't think I properly understand what you're saying=2E Can you clarify >this point? Keep in mind that senders do send from what we call non-existent domains f= or reasons that seem good and sufficient to them=2E Let's take that as a f= act, whether it makes sense to us or not=2E Sender (who knows nothing of our experiment) has published a DMARC record = that includes: p=3Dreject, sp=3Dnone When a DMARC compliant receiver receives mail from a subdomain of that org= anization domain, the policy to apply is none=2E If our experiment has 'np' fall back to 'sp', then the non-particpant gets= the same result=2E An experiment participating receiver would use 'sp' di= rectly (none) for an existing sub-domain and also use 'sp' (none - 'np' fal= lback) for a non-existing sub-domain=2E If our experiment has 'np' fall back to 'p', then the non-particpant gets = a different result=2E An experiment participating receiver would use 'sp' = directly (none) for an existing sub-domain and also use 'p' (reject - 'p' f= allback) for a non-existing sub-domain=2E Keep in mind, this isn't just about receiver processing=2E The policy app= lied is also in the aggregate reports=2E I think changing existing defined behavior for non-participants in an expe= riment is not appropriate=2E It's even more unacceptable in a case like th= is where we absolutely don't need it to achieve the desired behavior within= the experiment=2E Scott K From nobody Wed Jul 17 00:45:24 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 B014812009C for ; Wed, 17 Jul 2019 00:45:19 -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 zHU69QJA2dNe for ; Wed, 17 Jul 2019 00:45:17 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCDF12019F for ; Wed, 17 Jul 2019 00:45:16 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id r15so10807759lfm.11 for ; Wed, 17 Jul 2019 00:45:16 -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=rNeR1eumoHToT5DxmdZRvKUO4sTjqVLZDYYon5zoAtc=; b=bDNjnWAsj7OgjaymD5Fg5abim43Rft7dCtVAMkmJy0jNjKgGM9zpjPUNCsTNpya1Ws OOKkhNS7bCdIhkINJOZZsmXc/lL9Wy47MVaQTb986OK0pWDjzq7D3IDauWJ6/VIAha1x GSzNWRb3PWw3HeO3P0MtidjMGTtNidFjrk1N8K3z1NC425JXyapb386dDZcdiLYmjtIM /iBPio5Hi/kGF6FAH9BB21cTohbKKAVijxrRcopte/R0d1M2wVGqlFjwS8qg/y9Jn8XQ Nl7nSS0xNz/4jA49do78LMOoecMrO4CsWTamxXD6/XPzuQRuY9r5WAIEnoT9FilcWskK V8JA== 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=rNeR1eumoHToT5DxmdZRvKUO4sTjqVLZDYYon5zoAtc=; b=BSAY+w+FlkxTWBAAd1qzLbffhRnEReTXdrVF88X2W9yoHugEoHXf0s+atdrkH8P6Yo EuwPOalTB7DluqoQuDqxJ6fMQECpnZq90RLdjZVHPKfEgqtlULUomTreJ1hGM5U6vFOE ThCeWYMJMlFtZm9fSy7X0i5WMnlNt6Zl53cXCZRZE6+TCSZ9We3Mi8AQWU6fDZID3hDV HiMLNH04C4nChxdG47qxhxVb8XzyfepVI1ZZ39ETpsd6O5C2OXI3SjYd//N0aAOzN+DL meCKANYUWJdvDg71e806jNax2EKb+lzqOE5qlzq2IRfrZfJrYKIC+B3sdqSK2uvdVOlL V3aQ== X-Gm-Message-State: APjAAAWKi4gIdGcFHEnK9ayBNDZiYfoSQ1yLmMcnT0HeBmV5cg2s0f0n ZC4XiEquSuBmR/4pIGmyX5lX40SFEg/aZG8tlMc= X-Google-Smtp-Source: APXvYqy03M/rRL/C30Y6ZAZB+2+hg5lWRRJ0sEIHchIgjRxcYNhmzBq6i15lt4FHw0hfaoRjZAw89zEDNxK3cUvlFBU= X-Received: by 2002:a19:7006:: with SMTP id h6mr16916547lfc.5.1563349515102; Wed, 17 Jul 2019 00:45:15 -0700 (PDT) MIME-Version: 1.0 References: <3a6e6f9ac98c4e60af1075760efde86d@verisign.com> <20190712005443.2A664499982@ary.local> In-Reply-To: <20190712005443.2A664499982@ary.local> From: "Murray S. Kucherawy" Date: Wed, 17 Jul 2019 00:45:02 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary="00000000000081ef60058ddbacac" Archived-At: Subject: Re: [dmarc-ietf] Working Group Last Call: 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, 17 Jul 2019 07:45:20 -0000 --00000000000081ef60058ddbacac Content-Type: text/plain; charset="UTF-8" On Thu, Jul 11, 2019 at 5:54 PM John Levine wrote: > In article <3a6e6f9ac98c4e60af1075760efde86d@verisign.com> you write: > >> I don't plan any changes except for those in response to last call > comments. > >> Unless I get direction otherwise, I don't plan any updates until after > last call is > >> over. > >> > >> Please review this one. > > > >Repeating what I suggested earlier: > > > >https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk > > That seems OK to me. We don't need to say anything specifically to > ICANN. Should PSD turn out to be popular, this will be an input to an > ICANN process to allow the PSD record at the top of a TLD zone. > +1. -MSK, participatin' --00000000000081ef60058ddbacac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 11, 2019 at 5:54 PM John Levi= ne <johnl@taugh.com> wrote:
In article <3a6e6f9ac98c4e60af1075760efde86d@verisign= .com> you write:
>> I don't plan any changes except for those in response to last = call comments.
>> Unless I get direction otherwise, I don't plan any updates unt= il after last call is
>> over.
>>
>> Please review this one.
>
>Repeating what I suggested earlier:
>
>https://mailarchive.ietf.= org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk

That seems OK to me.=C2=A0 We don't need to say anything specifically t= o
ICANN.=C2=A0 Should PSD turn out to be popular, this will be an input to an=
ICANN process to allow the PSD record at the top of a TLD zone.

+1.

-MSK, participatin= 9;
--00000000000081ef60058ddbacac-- From nobody Wed Jul 17 03:22:42 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 F38F01201C6 for ; Wed, 17 Jul 2019 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8kBSm0Pl587 for ; Wed, 17 Jul 2019 03:22:39 -0700 (PDT) Received: from nova5.metanet.ch (nova5.metanet.ch [80.74.156.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7353120183 for ; Wed, 17 Jul 2019 03:22:38 -0700 (PDT) Received: from webmail.mex.trade (localhost [127.0.0.1]) by nova5.metanet.ch (Postfix) with ESMTPSA id 7AA5344E1163 for ; Wed, 17 Jul 2019 12:22:35 +0200 (CEST) Authentication-Results: nova.metanet.ch; spf=pass (sender IP is 127.0.0.1) smtp.mailfrom=gd@mex.trade smtp.helo=webmail.mex.trade Received-SPF: pass (nova.metanet.ch: connection is authenticated) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 17 Jul 2019 12:22:35 +0200 From: gd@mex.trade To: dmarc@ietf.org In-Reply-To: References: Message-ID: <951345c1d0b5c8b664f2ba70c9b06de7@mex.trade> X-Sender: gd@mex.trade User-Agent: Roundcube Webmail/1.3.8 Archived-At: Subject: [dmarc-ietf] dmarc Digest, Vol 76, Issue 19 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 10:22:41 -0000 Dear all, Congrats for all the great work done so far. Regarding the topics below, 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 1) No further info ... 2) indeed there should be a TEXT but only very general and only informative more than anything else. 3) I vote to make it NP tag as mandatory, or fall back on SP either way should be very explicit, to enforce the purpose. Best Regards Gustavo Damy From nobody Wed Jul 17 05:29:32 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 998CA1200C3 for ; Wed, 17 Jul 2019 05:29:31 -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 AozRw1bY23Ec for ; Wed, 17 Jul 2019 05:29:29 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AD912008F for ; Wed, 17 Jul 2019 05:29:29 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id w196so18318098oie.7 for ; Wed, 17 Jul 2019 05:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7CYpLR0bXOvnFQXVmZoaCkOjDfqRjiOrHJLAynjWMmw=; b=aLqbVR0AK9JDQ0jjoJZiqZbL9hLfBHgsPyiY8ZocQnX/FekeQd/6Q9WtwiNuE0h35a cr1d0AbVGaTH+Og/c+v43MHyM+IWwPWX+mKNxTh3jiIXaYTwNY+gpyZmtppA5dy0Mc/q LjzNXgFxsNo4LXf3t+wREc9CA0b40lF8Sn8Nu6qXPkjy3VFDlmQQW1kEzoOmnpOnyHF9 tFSBF1PonIyFYrXhL944tRWBmWqHf2ssxbW+emP7CkeOrlmxpKjYxdF4gPaUXsUHHFIt SDX24LiZZO1TAvgHZB02hEhq8tOklOGk5zP/BVbmJ+hx2PP93dai57U0vFMzhBhma8oB rI3w== 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=7CYpLR0bXOvnFQXVmZoaCkOjDfqRjiOrHJLAynjWMmw=; b=RHvNDs6humzJZ7uCWS1b/PWc0QPhKjZ2O20VwY0MrZYshGtmSwpO9gJPhFz79Jl1vA 0tUwUq1oUcUlSvdwR1LRz1aHYw9cI5Czg2dGfD6ka2Is8xizStrd4mgis1y1ZmztVN/j eqfUG3k2AdmlnuxV8cSGRzUZUzIBVtE4pzxbb+mLmusCO5J+f17ngoN9pp/Oq9RNtk79 +cMuK39XPnxk3IBYaL1FjRl3vvXtFFmJNFLYnfbcP3vDuK1Cj4p5/7snySz5GKSeePcl 2ubWbbj6G/ymd5QwmZiph7N1FCA7VPE4WDCXAPf4HkuE+uGjLjyz6BGyW6QZRbiumb2+ ZiVg== X-Gm-Message-State: APjAAAVtQ5huU5tZEAtPiCsHBuzDRTGoXIinaRTf3qbXo7H5/qFtfa+3 PdI89Tj6IAFtSfXzuQ0J4c0arUlROiAdfhERDhI3TkgF X-Google-Smtp-Source: APXvYqxPRIL8RBQqkiJtkx7TTvumKLgGt6nWyOGek5bYaF8iEjRFlW0gYXHLy7L2e9jEfeQIgmi+VDNTYSnpxSkwnC0= X-Received: by 2002:aca:b406:: with SMTP id d6mr19325794oif.173.1563366568423; Wed, 17 Jul 2019 05:29:28 -0700 (PDT) MIME-Version: 1.0 References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> In-Reply-To: From: Tim Wicinski Date: Wed, 17 Jul 2019 08:29:17 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f6f585058ddfa4bd" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 12:29:32 -0000 --000000000000f6f585058ddfa4bd Content-Type: text/plain; charset="UTF-8" Thanks for the update Scott, and your wording on the 'np' tag in the Appendix works. I just want to call out your statement: I think changing existing defined behavior for non-participants in an experiment is not appropriate. It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment. I agree very strongly on this, and this is the right way to view this. While we all are confident that the 'np' tag will be a wild success, there is the case this is not true, and we need to not upset current working behavior. Tim (probably chair'ing a little here) On Wed, Jul 17, 2019 at 2:27 AM Scott Kitterman wrote: > > > On July 17, 2019 5:54:41 AM UTC, Seth Blank wrote: > >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman > >wrote: > > > >> Yes, the point of 'np' is to allow for a stricter sub-domain policy, > >but > >> that's to support early deployment of strict PSD level policies > >without > >> breaking org domains that are still deploying/have not deployed > >DMARC. > >> > > > >I absolutely agree with this. > > > > > >> Case: > >> > >> PSO mandates all orgs deploy DMARC, but that's not done yet. PSO > >wants to > >> deploy PSD DMARC for reject at the PSD level and for non-existent > >domains, > >> but > >> leave non-DMARC deployed existing domains at none. PSO publishes > >these > >> policieis for the PSD: > >> > >> p=reject, sp=none, np=reject > >> > > > >Ah, I see what you're saying here. I honestly couldn't understand why > >you > >were talking about sp=none at all within a PSD context. I thought the > >solution to this scenario was to do as the PSO p=none; np=reject. I > >actually like p=reject; sp=none; better here, because that lets the PSD > >lock itself down as a sending domain. But to me, this also makes it > >clear > >that np= should use the p= not the sp= as its default. > > See if you still feel that way after considering backward compatibility ... > > >That said, I feel less strongly about this now, and can see merit in > >inheritance from either side (or from a hard default of none, for that > >matter, although I'd strongly argue against that personally...). > > > > > >> Having 'np' fall back to 'p' doesn't actually solve the problem you > >claim > >> to > >> be solving since it only affects non-implementers. > >> > > > >This I don't understand. The results you outlined are exactly what I > >think > >should happen. > > I think we agree on the goal, the difference is only about implementation > details and impact on non-particpants in the experiment. > > > >> I believe that's the exact requested case and the changeset I've > >provided > >> supports that without creating a situation where every implementer of > >the > >> experiment suddenly starts processing existing DMARC records > >differently > >> (which > >> I think would be very bad). > >> > > > >I don't think I properly understand what you're saying. Can you clarify > >this point? > > Keep in mind that senders do send from what we call non-existent domains > for reasons that seem good and sufficient to them. Let's take that as a > fact, whether it makes sense to us or not. > > Sender (who knows nothing of our experiment) has published a DMARC record > that includes: > > p=reject, sp=none > > When a DMARC compliant receiver receives mail from a subdomain of that > organization domain, the policy to apply is none. > > If our experiment has 'np' fall back to 'sp', then the non-particpant gets > the same result. An experiment participating receiver would use 'sp' > directly (none) for an existing sub-domain and also use 'sp' (none - 'np' > fallback) for a non-existing sub-domain. > > If our experiment has 'np' fall back to 'p', then the non-particpant gets > a different result. An experiment participating receiver would use 'sp' > directly (none) for an existing sub-domain and also use 'p' (reject - 'p' > fallback) for a non-existing sub-domain. > > Keep in mind, this isn't just about receiver processing. The policy > applied is also in the aggregate reports. > > I think changing existing defined behavior for non-participants in an > experiment is not appropriate. It's even more unacceptable in a case like > this where we absolutely don't need it to achieve the desired behavior > within the experiment. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f6f585058ddfa4bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the update Scott, and your wor= ding on the 'np' tag in the Appendix works.

I ju= st want to call out your statement:

I = think changing existing defined behavior for non-participants in an experim= ent is not appropriate.=C2=A0 It's even more unacceptable in a case lik= e this where we absolutely don't need it to achieve the desired behavio= r within the experiment.

I agree ver= y strongly on this, and this is the right way to view this.=C2=A0 While we = all are confident that the 'np' tag will be a wild success,=C2=A0there is the case this is not true, and we need to not upset current wor= king behavior.=C2=A0

Tim

= (probably chair'ing a little here)

On Wed, Jul 17, 2019 at 2:27 AM= Scott Kitterman <sklist@kitterm= an.com> wrote:


On July 17, 2019 5:54:41 AM UTC, Seth Blank <seth@sethblank.com> wrote:
>On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> Yes, the point of 'np' is to allow for a stricter sub-doma= in policy,
>but
>> that's to support early deployment of strict PSD level policie= s
>without
>> breaking org domains that are still deploying/have not deployed >DMARC.
>>
>
>I absolutely agree with this.
>
>
>> Case:
>>
>> PSO mandates all orgs deploy DMARC, but that's not done yet.= =C2=A0 PSO
>wants to
>> deploy PSD DMARC for reject at the PSD level and for non-existent<= br> >domains,
>> but
>> leave non-DMARC deployed existing domains at none.=C2=A0 PSO publi= shes
>these
>> policieis for the PSD:
>>
>> p=3Dreject, sp=3Dnone, np=3Dreject
>>
>
>Ah, I see what you're saying here. I honestly couldn't understa= nd why
>you
>were talking about sp=3Dnone at all within a PSD context. I thought the=
>solution to this scenario was to do as the PSO p=3Dnone; np=3Dreject. I=
>actually like p=3Dreject; sp=3Dnone; better here, because that lets the= PSD
>lock itself down as a sending domain. But to me, this also makes it
>clear
>that np=3D should use the p=3D not the sp=3D as its default.

See if you still feel that way after considering backward compatibility ...=

>That said, I feel less strongly about this now, and can see merit in >inheritance from either side (or from a hard default of none, for that<= br> >matter, although I'd strongly argue against that personally...). >
>
>> Having 'np' fall back to 'p' doesn't actually = solve the problem you
>claim
>> to
>> be solving since it only affects non-implementers.
>>
>
>This I don't understand. The results you outlined are exactly what = I
>think
>should happen.

I think we agree on the goal, the difference is only about implementation d= etails and impact on non-particpants in the experiment.
>
>> I believe that's the exact requested case and the changeset I&= #39;ve
>provided
>> supports that without creating a situation where every implementer= of
>the
>> experiment suddenly starts processing existing DMARC records
>differently
>> (which
>> I think would be very bad).
>>
>
>I don't think I properly understand what you're saying. Can you= clarify
>this point?

Keep in mind that senders do send from what we call non-existent domains fo= r reasons that seem good and sufficient to them.=C2=A0 Let's take that = as a fact, whether it makes sense to us or not.

Sender (who knows nothing of our experiment) has published a DMARC record t= hat includes:

p=3Dreject, sp=3Dnone

When a DMARC compliant receiver receives mail from a subdomain of that orga= nization domain, the policy to apply is none.

If our experiment has 'np' fall back to 'sp', then the non-= particpant gets the same result.=C2=A0 An experiment participating receiver= would use 'sp' directly (none) for an existing sub-domain and also= use 'sp' (none - 'np' fallback) for a non-existing sub-dom= ain.

If our experiment has 'np' fall back to 'p', then the non-p= articpant gets a different result.=C2=A0 An experiment participating receiv= er would use 'sp' directly (none) for an existing sub-domain and al= so use 'p' (reject - 'p' fallback) for a non-existing sub-d= omain.

Keep in mind, this isn't just about receiver processing.=C2=A0 The poli= cy applied is also in the aggregate reports.

I think changing existing defined behavior for non-participants in an exper= iment is not appropriate.=C2=A0 It's even more unacceptable in a case l= ike this where we absolutely don't need it to achieve the desired behav= ior within the experiment.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f6f585058ddfa4bd-- From nobody Wed Jul 17 07:03:00 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 3CD4612041B for ; Wed, 17 Jul 2019 07:02:59 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 5ekf0N761nKo for ; Wed, 17 Jul 2019 07:02:56 -0700 (PDT) Received: from upbd19pa10.eemsg.mail.mil (upbd19pa10.eemsg.mail.mil [214.24.27.85]) (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 7602C120074 for ; Wed, 17 Jul 2019 07:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1563372175; x=1594908175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sKDHP766cGKVAIel8ikiLdiTp7hAOmnXDpTGefbwvuw=; b=WAzPi0SWlYA0T6fehJGIVfQm5Cx1rJiT2Od0Lhu3lOrUfhlJvV32tc78 lM6yC9jm3VyXpXLQZPETXZMpSI5Y56rkQJLGGL+SbQX8/1KlaCuxg/qq0 dx2Yvf6yUi06d+mFMIs73c5Z5E+HB34bq8gbBBA0kZ2KlD+NgeUjcNoFs ppWENd+eMscW0rbeH6MHUY3jKWjdNB5ZaHNr7PkVrgJP1VpIRGtHDDUK0 YMqf2q19bGeAMZRY/DFlfbMKNrFniITUFHtJmc3l8YnUHtwbS1GHkNWbn dIJUndTN1tmvjufWGOaGJB9ynGDJPWtDIkUcxcfSCEGClq7xAMymvMx5+ w==; X-EEMSG-check-017: 241092365|UPBD19PA10_EEMSG_MP10.csd.disa.mil Received: from edge-mech02.mail.mil ([214.21.130.229]) by upbd19pa10.eemsg.mail.mil with ESMTP; 17 Jul 2019 14:02:42 +0000 Received: from UMECHPAOT.easf.csd.disa.mil (214.21.130.163) by edge-mech02.mail.mil (214.21.130.229) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jul 2019 14:01:02 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.5.94]) by umechpaot.easf.csd.disa.mil ([214.21.130.163]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 14:01:02 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: 'Tim Wicinski' , 'Scott Kitterman' CC: 'IETF DMARC WG' Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVPJtogk+jTKmNW0yXASeJeK/2F6bO0Nnw Date: Wed, 17 Jul 2019 14:01:01 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC0311CAB37BC@UMECHPA7D.easf.csd.disa.mil> References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> 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] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 14:03:00 -0000 U2NvdHQsIGdvb2QgcG9pbnQgYWJvdXQgdGhlIGludGVyb3BlcmFiaWxpdHkgaXNzdWUgZm9yIHRo ZSDigJhucOKAmSB0YWcuICBJIGhhZG7igJl0IHJlYWxseSB0aG91Z2h0IGFib3V0IHRoYXQuICBT aW5jZSB3aGF0IHdlIGRvIGhlcmUgZm9yIFBTRCBETUFSQyB3aWxsIGhvcGVmdWxseSBiZSBpbmNs dWRlZCBpbiByZWd1bGFyIERNQVJDIGZvciB0aGUgZnV0dXJlIGFzIHdlbGwsIEkgYWdyZWUgdGhh dCBpdCBtYWtlcyB0aGF0IHdlIHNob3VsZCBub3QgaGF2ZSB0aGUgZGVmYXVsdCBiZWhhdmlvciBi ZSBkaWZmZXJlbnQgdGhhbiBjdXJyZW50IGltcGxlbWVudGF0aW9ucywgc28gd2Ugc2hvdWxkIGtl ZXAgeW91ciBvcmlnaW5hbCBpbnRlbnQgdG8gaGF2ZSDigJhucOKAmSBkZWZhdWx0IHRvIOKAmHNw 4oCZIGZpcnN0IGlmIOKAmG5w4oCZIGlzIGFic2VudC4gIA0KDQpGcm9tIGEgcHVyaXN0IHBlcnNw ZWN0aXZlLCBJIGFncmVlIHdpdGggSWFuIHRoYXQgbm9uLWV4aXN0ZW50IHN1Yi1kb21haW5zIGFy ZSByZWFsbHkgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoYXQgZG9tYWluIGFuZCBzbyB0aGF0IGRv bWFpbuKAmXMgcG9saWN5IHNob3VsZCBhcHBseSBieSBkZWZhdWx0LiBCdXQgdGhlIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgaXMgbW9yZSBpbXBvcnRhbnQuICBFdmVuIHdpdGhvdXQgaGF2aW5nIOKA mHDigJkgYXMgdGhlIGRlZmF1bHQsIGl04oCZcyBlYXN5IGZvciBhIGRvbWFpbiB0byBhY2hpZXZl IHRoaXMgYnkgYWRkaW5nIHRoZSDigJhucOKAmSB0YWcgZXhwbGljaXRseS4gDQoNCkZvciB0aGUg Y3VycmVudCB3b3JkaW5nLCBJIHRoaW5rIHRoZSDigJxpZiBub3TigJ0gaXMgdW5jbGVhciBpbiB0 aGUg4oCcSWYgYWJzZW50LCB0aGUgcG9saWN5IHNwZWNpZmllZCBieSB0aGUgInNwIiAoaWYgcHJl c2VudCkgYW5kIHRoZW4gdGhlICJwIiB0YWcsIGlmIG5vdCwgTVVTVCBiZSBhcHBsaWVkIGZvciBu b24tZXhpc3RlbnQgc3ViZG9tYWlucy7igJ0gIERvZXMgdGhlIOKAnGlmIG5vdOKAnSBtZWFuIGlm IHRoZSBzcCB0YWcgaXMgbm90IHByZXNlbnQ/ICBJZiBzbywgdGhlbiBJIHRoaW5rIGl0IHNob3Vs ZCBiZSBpbiBwYXJlbnRoZXNlcyB0byBtYXRjaCB0aGUg4oCcKGlmIHByZXNlbnQp4oCdIGFuZCBw cm9iYWJseSBjb3VsZCBiZSBhIGxpdHRsZSBjbGVhcmVyIGJ5IHNheWluZyDigJwoaWYgdGhlIOKA nHNw4oCdIHRhZyBpcyBub3QgcHJlc2VudCnigJ0uDQoNClRoYW5rcywNCi1FcmljDQpfX19fX19f X19fX19fX19fX19fX19fX19fDQpFcmljIENodWRvdw0KRG9EIEN5YmVyc2VjdXJpdHkgTWl0aWdh dGlvbnMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogVGltIFdpY2luc2tpIDx0ancuaWV0ZkBnbWFpbC5jb20+IA0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDE3LCAyMDE5IDg6MjkgQU0NClRvOiBTY290dCBLaXR0ZXJtYW4gPHNr bGlzdEBraXR0ZXJtYW4uY29tPg0KQ2M6IElFVEYgRE1BUkMgV0cgPGRtYXJjQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBOb25leGlzdGVudCBEb21haW4gUG9saWN5IHdhczog UmU6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLWRtYXJjLXBzZA0KDQpUaGFu a3MgZm9yIHRoZSB1cGRhdGUgU2NvdHQsIGFuZCB5b3VyIHdvcmRpbmcgb24gdGhlICducCcgdGFn IGluIHRoZSBBcHBlbmRpeCB3b3Jrcy4NCg0KSSBqdXN0IHdhbnQgdG8gY2FsbCBvdXQgeW91ciBz dGF0ZW1lbnQ6DQoNCkkgdGhpbmsgY2hhbmdpbmcgZXhpc3RpbmcgZGVmaW5lZCBiZWhhdmlvciBm b3Igbm9uLXBhcnRpY2lwYW50cyBpbiBhbiBleHBlcmltZW50IGlzIG5vdCBhcHByb3ByaWF0ZS7C oCBJdCdzIGV2ZW4gbW9yZSB1bmFjY2VwdGFibGUgaW4gYSBjYXNlIGxpa2UgdGhpcyB3aGVyZSB3 ZSBhYnNvbHV0ZWx5IGRvbid0IG5lZWQgaXQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBiZWhhdmlv ciB3aXRoaW4gdGhlIGV4cGVyaW1lbnQuDQoNCkkgYWdyZWUgdmVyeSBzdHJvbmdseSBvbiB0aGlz LCBhbmQgdGhpcyBpcyB0aGUgcmlnaHQgd2F5IHRvIHZpZXcgdGhpcy7CoCBXaGlsZSB3ZSBhbGwg YXJlIGNvbmZpZGVudCB0aGF0IHRoZSAnbnAnIHRhZyB3aWxsIGJlIGEgd2lsZCBzdWNjZXNzLMKg DQp0aGVyZSBpcyB0aGUgY2FzZSB0aGlzIGlzIG5vdCB0cnVlLCBhbmQgd2UgbmVlZCB0byBub3Qg dXBzZXQgY3VycmVudCB3b3JraW5nIGJlaGF2aW9yLsKgDQoNClRpbQ0KDQoocHJvYmFibHkgY2hh aXInaW5nIGEgbGl0dGxlIGhlcmUpDQoNCk9uIFdlZCwgSnVsIDE3LCAyMDE5IGF0IDI6MjcgQU0g U2NvdHQgS2l0dGVybWFuIDxtYWlsdG86c2tsaXN0QGtpdHRlcm1hbi5jb20+IHdyb3RlOg0KDQoN Ck9uIEp1bHkgMTcsIDIwMTkgNTo1NDo0MSBBTSBVVEMsIFNldGggQmxhbmsgPG1haWx0bzpzZXRo QHNldGhibGFuay5jb20+IHdyb3RlOg0KPk9uIFR1ZSwgSnVsIDE2LCAyMDE5IGF0IDEwOjQwIFBN IFNjb3R0IEtpdHRlcm1hbiA8bWFpbHRvOnNrbGlzdEBraXR0ZXJtYW4uY29tPg0KPndyb3RlOg0K Pg0KPj4gWWVzLCB0aGUgcG9pbnQgb2YgJ25wJyBpcyB0byBhbGxvdyBmb3IgYSBzdHJpY3RlciBz dWItZG9tYWluIHBvbGljeSwNCj5idXQNCj4+IHRoYXQncyB0byBzdXBwb3J0IGVhcmx5IGRlcGxv eW1lbnQgb2Ygc3RyaWN0IFBTRCBsZXZlbCBwb2xpY2llcw0KPndpdGhvdXQNCj4+IGJyZWFraW5n IG9yZyBkb21haW5zIHRoYXQgYXJlIHN0aWxsIGRlcGxveWluZy9oYXZlIG5vdCBkZXBsb3llZA0K PkRNQVJDLg0KPj4NCj4NCj5JIGFic29sdXRlbHkgYWdyZWUgd2l0aCB0aGlzLg0KPg0KPg0KPj4g Q2FzZToNCj4+DQo+PiBQU08gbWFuZGF0ZXMgYWxsIG9yZ3MgZGVwbG95IERNQVJDLCBidXQgdGhh dCdzIG5vdCBkb25lIHlldC7CoCBQU08NCj53YW50cyB0bw0KPj4gZGVwbG95IFBTRCBETUFSQyBm b3IgcmVqZWN0IGF0IHRoZSBQU0QgbGV2ZWwgYW5kIGZvciBub24tZXhpc3RlbnQNCj5kb21haW5z LA0KPj4gYnV0DQo+PiBsZWF2ZSBub24tRE1BUkMgZGVwbG95ZWQgZXhpc3RpbmcgZG9tYWlucyBh dCBub25lLsKgIFBTTyBwdWJsaXNoZXMNCj50aGVzZQ0KPj4gcG9saWNpZWlzIGZvciB0aGUgUFNE Og0KPj4NCj4+IHA9cmVqZWN0LCBzcD1ub25lLCBucD1yZWplY3QNCj4+DQo+DQo+QWgsIEkgc2Vl IHdoYXQgeW91J3JlIHNheWluZyBoZXJlLiBJIGhvbmVzdGx5IGNvdWxkbid0IHVuZGVyc3RhbmQg d2h5DQo+eW91DQo+d2VyZSB0YWxraW5nIGFib3V0IHNwPW5vbmUgYXQgYWxsIHdpdGhpbiBhIFBT RCBjb250ZXh0LiBJIHRob3VnaHQgdGhlDQo+c29sdXRpb24gdG8gdGhpcyBzY2VuYXJpbyB3YXMg dG8gZG8gYXMgdGhlIFBTTyBwPW5vbmU7IG5wPXJlamVjdC4gSQ0KPmFjdHVhbGx5IGxpa2UgcD1y ZWplY3Q7IHNwPW5vbmU7IGJldHRlciBoZXJlLCBiZWNhdXNlIHRoYXQgbGV0cyB0aGUgUFNEDQo+ bG9jayBpdHNlbGYgZG93biBhcyBhIHNlbmRpbmcgZG9tYWluLiBCdXQgdG8gbWUsIHRoaXMgYWxz byBtYWtlcyBpdA0KPmNsZWFyDQo+dGhhdCBucD0gc2hvdWxkIHVzZSB0aGUgcD0gbm90IHRoZSBz cD0gYXMgaXRzIGRlZmF1bHQuDQoNClNlZSBpZiB5b3Ugc3RpbGwgZmVlbCB0aGF0IHdheSBhZnRl ciBjb25zaWRlcmluZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IC4uLg0KDQo+VGhhdCBzYWlkLCBJ IGZlZWwgbGVzcyBzdHJvbmdseSBhYm91dCB0aGlzIG5vdywgYW5kIGNhbiBzZWUgbWVyaXQgaW4N Cj5pbmhlcml0YW5jZSBmcm9tIGVpdGhlciBzaWRlIChvciBmcm9tIGEgaGFyZCBkZWZhdWx0IG9m IG5vbmUsIGZvciB0aGF0DQo+bWF0dGVyLCBhbHRob3VnaCBJJ2Qgc3Ryb25nbHkgYXJndWUgYWdh aW5zdCB0aGF0IHBlcnNvbmFsbHkuLi4pLg0KPg0KPg0KPj4gSGF2aW5nICducCcgZmFsbCBiYWNr IHRvICdwJyBkb2Vzbid0IGFjdHVhbGx5IHNvbHZlIHRoZSBwcm9ibGVtIHlvdQ0KPmNsYWltDQo+ PiB0bw0KPj4gYmUgc29sdmluZyBzaW5jZSBpdCBvbmx5IGFmZmVjdHMgbm9uLWltcGxlbWVudGVy cy4NCj4+DQo+DQo+VGhpcyBJIGRvbid0IHVuZGVyc3RhbmQuIFRoZSByZXN1bHRzIHlvdSBvdXRs aW5lZCBhcmUgZXhhY3RseSB3aGF0IEkNCj50aGluaw0KPnNob3VsZCBoYXBwZW4uDQoNCkkgdGhp bmsgd2UgYWdyZWUgb24gdGhlIGdvYWwsIHRoZSBkaWZmZXJlbmNlIGlzIG9ubHkgYWJvdXQgaW1w bGVtZW50YXRpb24gZGV0YWlscyBhbmQgaW1wYWN0IG9uIG5vbi1wYXJ0aWNwYW50cyBpbiB0aGUg ZXhwZXJpbWVudC4NCj4NCj4+IEkgYmVsaWV2ZSB0aGF0J3MgdGhlIGV4YWN0IHJlcXVlc3RlZCBj YXNlIGFuZCB0aGUgY2hhbmdlc2V0IEkndmUNCj5wcm92aWRlZA0KPj4gc3VwcG9ydHMgdGhhdCB3 aXRob3V0IGNyZWF0aW5nIGEgc2l0dWF0aW9uIHdoZXJlIGV2ZXJ5IGltcGxlbWVudGVyIG9mDQo+ dGhlDQo+PiBleHBlcmltZW50IHN1ZGRlbmx5IHN0YXJ0cyBwcm9jZXNzaW5nIGV4aXN0aW5nIERN QVJDIHJlY29yZHMNCj5kaWZmZXJlbnRseQ0KPj4gKHdoaWNoDQo+PiBJIHRoaW5rIHdvdWxkIGJl IHZlcnkgYmFkKS4NCj4+DQo+DQo+SSBkb24ndCB0aGluayBJIHByb3Blcmx5IHVuZGVyc3RhbmQg d2hhdCB5b3UncmUgc2F5aW5nLiBDYW4geW91IGNsYXJpZnkNCj50aGlzIHBvaW50Pw0KDQpLZWVw IGluIG1pbmQgdGhhdCBzZW5kZXJzIGRvIHNlbmQgZnJvbSB3aGF0IHdlIGNhbGwgbm9uLWV4aXN0 ZW50IGRvbWFpbnMgZm9yIHJlYXNvbnMgdGhhdCBzZWVtIGdvb2QgYW5kIHN1ZmZpY2llbnQgdG8g dGhlbS7CoCBMZXQncyB0YWtlIHRoYXQgYXMgYSBmYWN0LCB3aGV0aGVyIGl0IG1ha2VzIHNlbnNl IHRvIHVzIG9yIG5vdC4NCg0KU2VuZGVyICh3aG8ga25vd3Mgbm90aGluZyBvZiBvdXIgZXhwZXJp bWVudCkgaGFzIHB1Ymxpc2hlZCBhIERNQVJDIHJlY29yZCB0aGF0IGluY2x1ZGVzOg0KDQpwPXJl amVjdCwgc3A9bm9uZQ0KDQpXaGVuIGEgRE1BUkMgY29tcGxpYW50IHJlY2VpdmVyIHJlY2VpdmVz IG1haWwgZnJvbSBhIHN1YmRvbWFpbiBvZiB0aGF0IG9yZ2FuaXphdGlvbiBkb21haW4sIHRoZSBw b2xpY3kgdG8gYXBwbHkgaXMgbm9uZS4NCg0KSWYgb3VyIGV4cGVyaW1lbnQgaGFzICducCcgZmFs bCBiYWNrIHRvICdzcCcsIHRoZW4gdGhlIG5vbi1wYXJ0aWNwYW50IGdldHMgdGhlIHNhbWUgcmVz dWx0LsKgIEFuIGV4cGVyaW1lbnQgcGFydGljaXBhdGluZyByZWNlaXZlciB3b3VsZCB1c2UgJ3Nw JyBkaXJlY3RseSAobm9uZSkgZm9yIGFuIGV4aXN0aW5nIHN1Yi1kb21haW4gYW5kIGFsc28gdXNl ICdzcCcgKG5vbmUgLSAnbnAnIGZhbGxiYWNrKSBmb3IgYSBub24tZXhpc3Rpbmcgc3ViLWRvbWFp bi4NCg0KSWYgb3VyIGV4cGVyaW1lbnQgaGFzICducCcgZmFsbCBiYWNrIHRvICdwJywgdGhlbiB0 aGUgbm9uLXBhcnRpY3BhbnQgZ2V0cyBhIGRpZmZlcmVudCByZXN1bHQuwqAgQW4gZXhwZXJpbWVu dCBwYXJ0aWNpcGF0aW5nIHJlY2VpdmVyIHdvdWxkIHVzZSAnc3AnIGRpcmVjdGx5IChub25lKSBm b3IgYW4gZXhpc3Rpbmcgc3ViLWRvbWFpbiBhbmQgYWxzbyB1c2UgJ3AnIChyZWplY3QgLSAncCcg ZmFsbGJhY2spIGZvciBhIG5vbi1leGlzdGluZyBzdWItZG9tYWluLg0KDQpLZWVwIGluIG1pbmQs IHRoaXMgaXNuJ3QganVzdCBhYm91dCByZWNlaXZlciBwcm9jZXNzaW5nLsKgIFRoZSBwb2xpY3kg YXBwbGllZCBpcyBhbHNvIGluIHRoZSBhZ2dyZWdhdGUgcmVwb3J0cy4NCg0KSSB0aGluayBjaGFu Z2luZyBleGlzdGluZyBkZWZpbmVkIGJlaGF2aW9yIGZvciBub24tcGFydGljaXBhbnRzIGluIGFu IGV4cGVyaW1lbnQgaXMgbm90IGFwcHJvcHJpYXRlLsKgIEl0J3MgZXZlbiBtb3JlIHVuYWNjZXB0 YWJsZSBpbiBhIGNhc2UgbGlrZSB0aGlzIHdoZXJlIHdlIGFic29sdXRlbHkgZG9uJ3QgbmVlZCBp dCB0byBhY2hpZXZlIHRoZSBkZXNpcmVkIGJlaGF2aW9yIHdpdGhpbiB0aGUgZXhwZXJpbWVudC4N Cg0KU2NvdHQgSw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KZG1hcmMgbWFpbGluZyBsaXN0DQptYWlsdG86ZG1hcmNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMNCg== From nobody Wed Jul 17 13:15:14 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 F2C27120047 for ; Wed, 17 Jul 2019 13:15:12 -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=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxKe2OqtxXLL for ; Wed, 17 Jul 2019 13:15:10 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB805120018 for ; Wed, 17 Jul 2019 13:15:10 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id k8so47887792iot.1 for ; Wed, 17 Jul 2019 13:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nlJVBWRMgG34HUb32eah7Oqwkwo4oKREW+FyCemavuY=; b=e11diZBg1vO5x1V2vxvoVuzP7ALJtP/EWUEg5qYOqiujfBEsieyjo5nr1Xnu2/mHob xXb6SquRWcmuvjtbG2pT5iuyPt1IZPAXEoVssjSXlxEHFTE2Jkn3lPHDtmMmfrK+aLHK WGpZyyREJQdS3UGp2/0YR2IXkW5KAbsFjp4mE= 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=nlJVBWRMgG34HUb32eah7Oqwkwo4oKREW+FyCemavuY=; b=WlIY+wlN62yiRVtFSa3ZwxJ2e5RhZF3iVJIhlCc6xQTMAe+YYhoDDGOnBj9dRg/N2t WgA5xIMdAVNayjpx80Swwc/cwQYB+yZF7W4jUmcbQMndmJcmUx14TD3Hjh5X+GjiMqY2 vjB2hQTCWFvfZJ+5bHe2pO2jOlK4f04CmeWytKIRvCBaxqmc1fDb3D6wedb+A32nDbXZ ItbOX5BYaLR2SRYFDgjm4xJK+A3EiEa0rnD+5UqDBSqKDblHgJRlc2Os2rjoZmp+sV+8 kInTmHTdfz3lLLtT2aytjW1Ia1lak10A8EYTTDH8KFP2foEHURSndyGnqElhTsnko9Td 3JIA== X-Gm-Message-State: APjAAAVFdgwqu7COHNPaeaGKPwEXx8iFMT9d9V3sjg0s3DPJktS/dxUA HW/9TbLz3GRmEaWIneVyJDPT50crWkeC1wolYxZyi5hPi7w= X-Google-Smtp-Source: APXvYqyF3aI+Qi+Igwqt7F06G5YSmDyFl8dbruSDY1cwgk4Kfl34Lc/Hc/CVt3H6QQGVNkkFMg30uQSBAMImp5AceWA= X-Received: by 2002:a5d:948a:: with SMTP id v10mr9183898ioj.103.1563394509773; Wed, 17 Jul 2019 13:15:09 -0700 (PDT) MIME-Version: 1.0 References: <1958020.28HeBAo97T@l5580> <4789054.Ip9ilXyiH0@l5580> <7295017.bxVsTnSgkA@l5580> In-Reply-To: <7295017.bxVsTnSgkA@l5580> From: "Kurt Andersen (b)" Date: Wed, 17 Jul 2019 13:14:54 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000664b5e058de6269a" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 20:15:13 -0000 --000000000000664b5e058de6269a Content-Type: text/plain; charset="UTF-8" On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman wrote: > > Updated rfcdiff attached. The only change other than typos is to add > mention > of 'np' to Appendix A. > Having reviewed the thread and the diff insofar as it pertains to the "np" tag, I'm in favor of the "np defaults to sp" approach. Generally, I think that the proposed text works, but have two concerns: Firstly, I'm a little concerned with the sentence which says 'Note that "np" will be ignored for DMARC records published on subdomains of Organizational Domains and PSDs due to the effect of the DMARC policy discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't think that is an accurate portrayal. When DMARC evaluation libraries are updated to do both PSD lookups and handle the np tag, I would expect the presence of np tags below the PSD level would be processed exactly the way that any other tag in a DMARC record is processed. np will only be ignored (per the terms of the DMARC spec) when it is an "unrecognized" tag. I realized that this text is sort of picked up from the current description of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't publish an np record on a non-existent Org domain or any subdomain thereof :-) Secondly, I think that we need to update the "p" and "sp" descriptions in both 7489 sections 6.3 & 11.4: - p --> 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag.' change to 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" or "np" tags.' - sp --> 'Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself.' change to 'Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried if they exist or if there is not an "np" tag published. "sp" does not apply to the domain itself." --Kurt --000000000000664b5e058de6269a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2019 at 10:07 PM Scott Ki= tterman <sklist@kitterman.com> wrote:

Updated rfcdiff attached.=C2=A0 The only change other than typos is to add = mention
of 'np' to Appendix A.



Firstly, I'm a littl= e concerned with the sentence which says 'Note that "np" will= be ignored for DMARC records published on subdomains of Organizational Dom= ains and PSDs due to the effect of the DMARC policy discovery mechanism des= cribed in DMARC [RFC7489] Section 6.6.3.' I don't think that is an = accurate portrayal. When DMARC evaluation libraries are updated to do both = PSD lookups and handle the np tag, I would expect the presence of np tags b= elow the PSD level would be processed exactly the way that any other tag in= a DMARC record is processed. np will only be ignored (per the terms of the= DMARC spec) when it is an "unrecognized" tag. I realized that th= is text is sort of picked up from the current description of "sp"= , but the inclusion of "and PSDs" makes it inaccurate. You can= 9;t publish an np record on a non-existent Org domain or any subdomain ther= eof :-)


--000000000000664b5e058de6269a-- From nobody Wed Jul 17 14:40:28 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 A41F312011A for ; Wed, 17 Jul 2019 14:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=GedhSktf; dkim=pass (1536-bit key) header.d=taugh.com header.b=IAmoKNMz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pScUZ4gkgy1D for ; Wed, 17 Jul 2019 14:40:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46986120116 for ; Wed, 17 Jul 2019 14:40:25 -0700 (PDT) Received: (qmail 91759 invoked from network); 17 Jul 2019 21:40:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1666b.5d2f95c6.k1907; i=johnl-iecc.com@submit.iecc.com; bh=LPMTYVsVhZ1nhvT/2bJ2VLm4tTl0fV2P/j/8kRBEi6k=; b=GedhSktfV+EVktkwFqufVmKARcpQQTCiqnFdXlPb6cicW0CwmodcGNSUUnsLFwM+IeGApzQcPssxgsFmCbv12UmdTzASuBOL53myjXhLcFvF9Evd2+wdyfLQ5lT4ykfXLwge4l4Gg/KKenXDNlhS36cyDnIlNtIquGIhmR8dV8wHpz7KwXWmf0rHIOP7toQOyN6lEqyz+32figCTD/dUwkeqkMYiasaPqK1rPhFZTCQbiy6aWlEWQ0vKH3HwijZi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1666b.5d2f95c6.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=LPMTYVsVhZ1nhvT/2bJ2VLm4tTl0fV2P/j/8kRBEi6k=; b=IAmoKNMzbiRpnCIThy6yInJDrQwU8G9V0YD30ekha0kNR2KhcxK4Cqw/+fnYmNfb1I2wMDzcTLsVWZQc9bHhrQPoq7HantMcU8XX4zG/0tvPJmiuchpXeOTtMoxzVqWnpADRjSkgf+ZtnT8xKgJ/350vjNX38+RzBfX1aETCIJJPESSRwZQ2N/2UeNRgbi3FXHUaQAXRZv9tT8IsgeIWFq54lWc/c+h4YUYzs3lgRKygXjqvcQxRuwsQwfoliwFZ Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 17 Jul 2019 21:40:21 -0000 Received: by ary.qy (Postfix, from userid 501) id A4DEE50EC1E; Wed, 17 Jul 2019 17:40:20 -0400 (EDT) Date: 17 Jul 2019 17:40:20 -0400 Message-Id: <20190717214021.A4DEE50EC1E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 21:40:27 -0000 In article you write: >Firstly, I'm a little concerned with the sentence which says 'Note that >"np" will be ignored for DMARC records published on subdomains of >Organizational Domains and PSDs due to the effect of the DMARC policy >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't >think that is an accurate portrayal. ... I think what it means is that if there's a DMARC record on a subdomain, it won't see any np= in the org domain or the PSD. I agree the wording could be better. I also don't understand what possible meaning an np= on a subdomain record would have. R's, John From nobody Wed Jul 17 14:55:31 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 7E7F11204BE for ; Wed, 17 Jul 2019 14:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nywEe2tQ0Abn for ; Wed, 17 Jul 2019 14:55:27 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 78B281205CC for ; Wed, 17 Jul 2019 14:55:27 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id m24so48272058ioo.2 for ; Wed, 17 Jul 2019 14:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rKNLWXvB8j1QJ88ut4tYRVVtXZAu9ef9pUZP8j8CJD4=; b=DgBYyP4JS/DYfLMkhgMC2dvqvIEX1ydvZ2+ra6tieF6MsNyn9KFB9IQzSpO+OTJy/C 4AhbQG1B8nJ5P6nPEX7NMJr17Z4C/EqBIqomM90UHFJtw6l8uhR90ItFN3GjG+xH4kGf A2T27bXdye2uNWgm4waQwQcsRDnLRM93liOOM= 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=rKNLWXvB8j1QJ88ut4tYRVVtXZAu9ef9pUZP8j8CJD4=; b=sCUQHnVm6bXdT/2tHZs7NAv4LH0w3rn6DoHEmhni5/95kRth0blyvywvsVx/nVAaa1 wOVeAI4TBxSbbdfnR04cOyENK9UKp0LEOrIOpDplcFMZ2L8m+vCD4nb9nsMlfCLBGrqH X/eEPqPhszZmX1um76TQzXVV37STpXKWQ/GvSvLTdl54axMty9H17KAiyLeaQbdzTWeY FqU1/Tybtg3JkV3S0suP6l3Vy5Nio8Lje4+vMwbRIFVbXGRd7Ho1FzAZK8vB/vum7ajf 2LzGkRLKIXzUVX/p6LeMcUDbqLRg5EzsmFyntvBtKujg9gDWKpXZw/8Vq7PulotRzr1M rhHA== X-Gm-Message-State: APjAAAUy90lxWq+5CpxpMWONgkrrTXH6OKEamVi6d4e24lCmSOtxaTZS v6YaKeyIYDzqHtkgDPEVdQlRJ46g0EkcjQgGYHWDcNFpRZY= X-Google-Smtp-Source: APXvYqxLh7m3q1FFg2gFT+hBq6HWwxCMIAz1qcHGlydvYlrOmkunLyE+Xp8uDArTMyVzqEowic5P9cxPYPY6LKts6mU= X-Received: by 2002:a6b:f607:: with SMTP id n7mr1224854ioh.263.1563400526671; Wed, 17 Jul 2019 14:55:26 -0700 (PDT) MIME-Version: 1.0 References: <20190717214021.A4DEE50EC1E@ary.qy> In-Reply-To: <20190717214021.A4DEE50EC1E@ary.qy> From: "Kurt Andersen (b)" Date: Wed, 17 Jul 2019 14:55:12 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000008bcb8058de78de8" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 21:55:30 -0000 --00000000000008bcb8058de78de8 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 17, 2019 at 2:40 PM John Levine wrote: > In article ZsDWzVRAgQ@mail.gmail.com> you write: > >Firstly, I'm a little concerned with the sentence which says 'Note that > >"np" will be ignored for DMARC records published on subdomains of > >Organizational Domains and PSDs due to the effect of the DMARC policy > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I don't > >think that is an accurate portrayal. ... > > I think what it means is that if there's a DMARC record on a > subdomain, it won't see any np= in the org domain or the PSD. I agree > the wording could be better. I also don't understand what possible > meaning an np= on a subdomain record would have. np on a subdomain doesn't make any sense; np on an org domain would. I think that just omitting the "and PSDs" would solve my concern unless the use case of concern has to do with PSD subdomains that are still in the public space. It's a question of distinguishing between LPD (longest public domain) and PSDs in general. --Kurt --00000000000008bcb8058de78de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In article <CABuGu1rSyifv0B9RtD3_R2ex-sh+nVrh4Q3H=3DkU=3DZsDWzVRAgQ@mail.= gmail.com> you write:
>Firstly, I'm a little concerned with the sentence which says 'N= ote that
>"np" will be ignored for DMARC records published on subdomain= s of
>Organizational Domains and PSDs due to the effect of the DMARC policy >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I = don't
>think that is an accurate portrayal. ...

I think what it means is that if there's a DMARC record on a
subdomain, it won't see any np=3D in the org domain or the PSD.=C2=A0 I= agree
the wording could be better.=C2=A0 I also don't understand what possibl= e
meaning an np=3D on a subdomain record would have.

np on a subdomain doesn't make any sense; np on an org domain w= ould. I think that just omitting the "and PSDs" would solve my co= ncern unless the use case of concern has to do with PSD subdomains that are= still in the public space. It's a question of distinguishing between L= PD (longest public domain) and PSDs in general.

--= Kurt
--00000000000008bcb8058de78de8-- From prvs=094886937=flaim@amazon.com Wed Jul 17 15:23:23 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 86F0A120168 for ; Wed, 17 Jul 2019 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 3KN1ZAirzr9k for ; Wed, 17 Jul 2019 15:23:21 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9F01200F9 for ; Wed, 17 Jul 2019 15:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1563402201; x=1594938201; h=from:to:subject:date:message-id:mime-version; bh=+a7xhf3GCzGS6W3ha50Xs2YsOyPMBOOI7uhtEMpBF2M=; b=qh3SzWDg33zoI482LuTna9/TQndwBU5Ey/FeIFsyvX8EG2O1q75vXFK2 Pk4oH5STH119jXWgzC3zupXkxAgSuD/gZZJLBRHu0jZRwJvi4lMGaIVUE qxC2K+QRKuLnJe2/SoQ/6KBjKj7TQEZMiJbd6SINmPC6wr4gQNKH72ESd U=; X-IronPort-AV: E=Sophos;i="5.64,275,1559520000"; d="scan'208,217";a="811856152" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 17 Jul 2019 22:23:14 +0000 Received: from EX13MTAUWA001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id C71E6A1C5D for ; Wed, 17 Jul 2019 22:23:13 +0000 (UTC) Received: from EX13D21UWA004.ant.amazon.com (10.43.160.252) by EX13MTAUWA001.ant.amazon.com (10.43.160.118) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Jul 2019 22:23:13 +0000 Received: from EX13D06UEE001.ant.amazon.com (10.43.62.79) by EX13D21UWA004.ant.amazon.com (10.43.160.252) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 17 Jul 2019 22:23:12 +0000 Received: from EX13D06UEE001.ant.amazon.com ([10.43.62.79]) by EX13D06UEE001.ant.amazon.com ([10.43.62.79]) with mapi id 15.00.1367.000; Wed, 17 Jul 2019 22:23:11 +0000 From: "Flaim, Bobby" To: "dmarc@ietf.org" Thread-Topic: Amazon Comments to DMARC Extension to PSD Thread-Index: AQHVPO44YsRAt9WVs0a2kY1gnuZlEA== Date: Wed, 17 Jul 2019 22:23:11 +0000 Message-ID: <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.b.190609 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.60.14] Content-Type: multipart/alternative; boundary="_000_132DD4E4616A47F5A4A3681067C86DA6amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: X-Mailman-Approved-At: Wed, 17 Jul 2019 15:44:44 -0700 Subject: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 22:26:36 -0000 --_000_132DD4E4616A47F5A4A3681067C86DA6amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW1hem9uIHN1cHBvcnRzIHRoaXMgZHJhZnQgYW5kIGVmZm9ydCAuDQoNClRoaXMgY3VycmVudCBE TUFSQyBleHRlbnNpb24gKElFVEYgRE1BUkMgUFNEKSBkcmFmdDxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtYXJjLXBzZC8+IHdvdWxkIG1ha2UgaXQgZWFzaWVy IGZvciBvdXIgZGlyZWN0IGN1c3RvbWVycyAocmVnaXN0cmFudHMpIHRvIHNldHVwIGEgY29tbW9u IERNQVJDIHBvbGljeSBmb3IgYWxsIHRoZWlyIHN1YmRvbWFpbnMuIFdpdGggdGhpcyBleHRlbnNp b24gdGhleSBjYW4gc2V0IHVwIHRoZSBwb2xpY3kgaW4gb25lIHBsYWNlLCBzdWNoIGFzIHRoZSBT TEQgbGV2ZWwgKHNlY29uZCBsZXZlbCBkb21haW4pIGFuZCBpdCB3aWxsIGFwcGx5IHRvIGFueSBz dWJkb21haW4gdGhleSBjcmVhdGUuICBIb3dldmVyLCBzaW5jZSBmZWVkYmFjayBsZWFrYWdlIGNh biBoYXBwZW4gZHVlIHRvIHRoZSBuYXR1cmUgb2YgdGhlIElFVEYgRE1BUkMgUFNEIHNvbHV0aW9u LCB0aGUgZm9sbG93aW5nIHByb3Bvc2VkIGFsdGVybmF0aXZlIGNvdWxkIGJlIGVtcGxveWVkIHRv IGFkZHJlc3MgdGhpcyBpc3N1ZS4NCg0KSXMgdGhlIERFTUFSQyBkZWZpbmVkIGZvciBkb2cuYW5p bWFscy5jb208aHR0cDovL2RvZy5hbmltYWxzLmNvbT4/DQoNCmEuICAgICAgWWVzOiB0aGVuIHVz ZSBpdA0KDQpiLiAgICAgIE5vOiB0aGVuIGxvb2sgZm9yIERNQVJDIG9uIGFuaW1hbHMuY29tPGh0 dHA6Ly9hbmltYWxzLmNvbT4NCg0KUHJvcG9zZWQgRGVmYXVsdCBBbHRlcm5hdGl2ZToNCmEuICAg ICAgSXMgdGhlIERFTUFSQyBkZWZpbmVkIGZvciBkb2cuYW5pbWFscy5jb208aHR0cDovL2RvZy5h bmltYWxzLmNvbT4/DQoNCmEuICAgICAgWWVzOiBUaGVuIHVzZSBpdA0KDQpiLiAgICAgIE5vOiBJ cyB1c2luZyB0aGUgUFNEIERNQVJDIGV4cGxpY2l0bHkgcGVybWl0dGVkIGJ5IHRoZSBkb2cuYW5p bWFscy5jb208aHR0cDovL2RvZy5hbmltYWxzLmNvbT4gb3duZXIgaW4gc29tZSBUWFQgcmVjb3Jk IChtZWFucyDigJxkZWxlZ2F0ZWQgZXhwbGljaXRseSB0byB0aGUgUFNE4oCdKT8NCjEuICAgICAg WWVzOiB0aGVuIGxvb2sgZm9yIERNQVJDIG9uYW5pbWFscy5jb208aHR0cDovL2FuaW1hbHMuY29t Pg0KMS4gICAgICBObzogdGVybWluYXRlDQoNClRoZSBhbHRlcm5hdGl2ZSBwcm9wb3NhbCByZXF1 aXJlcyB0aGUgcmVnaXN0cmFudCB0byBleHBsaWNpdGx5IHNldCB1cCB0aGUgZGVmYXVsdC4NCg0K --_000_132DD4E4616A47F5A4A3681067C86DA6amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <73DA57C79905C0488851F38C34CC9D62@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkFtYXpvbiBzdXBwb3J0cyB0aGlzIGRyYWZ0IGFuZCBlZmZvcnQgLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIGN1cnJlbnQgRE1BUkMgZXh0ZW5z aW9uIChJRVRGIERNQVJDIFBTRCkNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZG1hcmMtcHNkLyI+ZHJhZnQ8L2E+IHdvdWxkIG1ha2UgaXQgZWFz aWVyIGZvciBvdXIgZGlyZWN0IGN1c3RvbWVycyAocmVnaXN0cmFudHMpIHRvIHNldHVwIGEgY29t bW9uIERNQVJDIHBvbGljeSBmb3IgYWxsIHRoZWlyIHN1YmRvbWFpbnMuIFdpdGggdGhpcyBleHRl bnNpb24gdGhleSBjYW4gc2V0IHVwIHRoZSBwb2xpY3kgaW4gb25lIHBsYWNlLCBzdWNoDQogYXMg dGhlIFNMRCBsZXZlbCAoc2Vjb25kIGxldmVsIGRvbWFpbikgYW5kIGl0IHdpbGwgYXBwbHkgdG8g YW55IHN1YmRvbWFpbiB0aGV5IGNyZWF0ZS4gJm5ic3A7SG93ZXZlciwgc2luY2UgZmVlZGJhY2sg bGVha2FnZSBjYW4gaGFwcGVuIGR1ZSB0byB0aGUgbmF0dXJlIG9mIHRoZSBJRVRGIERNQVJDIFBT RCBzb2x1dGlvbiwgdGhlIGZvbGxvd2luZyBwcm9wb3NlZCBhbHRlcm5hdGl2ZSBjb3VsZCBiZSBl bXBsb3llZCB0byBhZGRyZXNzIHRoaXMgaXNzdWUuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5JcyB0aGUgREVNQVJDIGRlZmluZWQgZm9yPC9zcGFuPjwvdT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vZG9n LmFuaW1hbHMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ZG9nLmFuaW1hbHMuY29t PC9zcGFuPjwvYT4/PC9zcGFuPjwvdT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdp bi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+YS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5ZZXM6IHRoZW4gdXNlIGl0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDoxLjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4 dC1pbmRlbnQ6LS4yNWluO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmIuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Tm86IHRoZW4gbG9vayBmb3IgRE1BUkMgb248c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2Fu aW1hbHMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+YW5pbWFscy5jb208L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z cGFjaW5nOjBweCI+DQo8dT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlByb3Bvc2VkIERlZmF1 bHQgQWx0ZXJuYXRpdmU6PC9zcGFuPjwvdT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNzVpbjt0ZXh0LWluZGVudDotLjI1aW47Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmEuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+SXMgdGhlIERFTUFSQyBkZWZpbmVkIGZvcjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vZG9nLmFuaW1h bHMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ZG9nLmFuaW1hbHMuY29tPC9zcGFu PjwvYT4/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MS41 aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0uMjVpbjtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5hLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlllczogVGhl biB1c2UgaXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 MGluO21hcmdpbi1sZWZ0OjEuNWluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDot LjI1aW47Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Yi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5ObzogSXMgdXNpbmcgdGhlIFBTRCBETUFSQyBleHBsaWNpdGx5IHBlcm1p dHRlZA0KIGJ5IHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vZG9nLmFuaW1hbHMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+ZG9nLmFuaW1hbHMuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+b3duZXIgaW4gc29tZSBUWFQgcmVjb3JkIChtZWFu cyDigJxkZWxlZ2F0ZWQgZXhwbGljaXRseSB0byB0aGUgUFNE4oCdKT88L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNWluO3RleHQt aW5kZW50Oi0uMjVpbjtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5ZZXM6IHRoZW4gbG9vayBmb3IgRE1BUkMgb248YSBocmVmPSJodHRwOi8vYW5pbWFscy5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5hbmltYWxzLmNvbTwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVpbjt0ZXh0LWluZGVudDotLjI1 aW47Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3Rh cnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tm86IHRl cm1pbmF0ZTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGFsdGVybmF0aXZlIHByb3Bvc2FsIHJl cXVpcmVzIHRoZSByZWdpc3RyYW50IHRvIGV4cGxpY2l0bHkgc2V0IHVwIHRoZSBkZWZhdWx0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_132DD4E4616A47F5A4A3681067C86DA6amazoncom_-- From nobody Wed Jul 17 16:45:17 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 7D4CD120173 for ; Wed, 17 Jul 2019 16:45:15 -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=CvtbDx9P; dkim=pass (2048-bit key) header.d=kitterman.com header.b=qZiF8axf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5_T5W9JWYRm for ; Wed, 17 Jul 2019 16:45:13 -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 9761E120170 for ; Wed, 17 Jul 2019 16:45:12 -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 BBDE8F805D5; Wed, 17 Jul 2019 19:45:11 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563407111; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=EcJw1TR0RJ/7tU3rX+CgtsVod5z2Ure3OluWkXN6xwQ=; b=CvtbDx9PDJAQ0KbbvXe1UZXT4W+r4so1jPLiqbr0CnYiZSO8r0JEJfVw fcLYuRiu7D7L7YUBJxdj+Sj7wbSACA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563407111; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=EcJw1TR0RJ/7tU3rX+CgtsVod5z2Ure3OluWkXN6xwQ=; b=qZiF8axfT2WIvthTN/rfc+Qj+cti9J8Op0MQMk+wdahBuCITiuj/Gr+J BkIjHXeiHJvF033Dqnubo1x4IuXXbDc6dpCigKdCyDNYtbqR0PpP1lqKlL Fk5diMCXd7lXI1DeS4UeHSK888qsdaR8Tpe5UsOizvUcIDo4pP2+nkTnTK Wv1IRSdaWKacFITtqoIWbjfQnQWqoMw/FS+kHTeE9jsKX5/HR5H6CfMB1g vPYsy1d+8JKp9XD9dcB4qOLAYmQ7JIAC4EJfRsw5YpamETzcH/mbNfVacH riIHBl1gEghCmRTuOFKM62Di6aJsZmnJklAIj+QuBmGgkf48ejBTzw== Received: from [10.65.244.24] (mobile-166-170-51-136.mycingular.net [166.170.51.136]) by interserver.kitterman.com (Postfix) with ESMTPSA id 250E5F80042; Wed, 17 Jul 2019 19:45:11 -0400 (EDT) Date: Wed, 17 Jul 2019 23:45:08 +0000 In-Reply-To: References: <1958020.28HeBAo97T@l5580> <4789054.Ip9ilXyiH0@l5580> <7295017.bxVsTnSgkA@l5580> 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] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 17 Jul 2019 23:45:15 -0000 On your first point, I'll go double check=2E I copied that text from the '= sp' definition=2E I'm not sure why 'np' would be different=2E On the second, I'm slightly reluctant to present redefine existing terms i= n an experimental document, but it is clearer and more explicit the way you= suggest=2E I'm curious what others think? Scott K On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" = wrote: >On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman >wrote: > >> >> Updated rfcdiff attached=2E The only change other than typos is to add >> mention >> of 'np' to Appendix A=2E >> > >Having reviewed the thread and the diff insofar as it pertains to the >"np" >tag, I'm in favor of the "np defaults to sp" approach=2E > >Generally, I think that the proposed text works, but have two concerns: > >Firstly, I'm a little concerned with the sentence which says 'Note that >"np" will be ignored for DMARC records published on subdomains of >Organizational Domains and PSDs due to the effect of the DMARC policy >discovery mechanism described in DMARC [RFC7489] Section 6=2E6=2E3=2E' I >don't >think that is an accurate portrayal=2E When DMARC evaluation libraries >are >updated to do both PSD lookups and handle the np tag, I would expect >the >presence of np tags below the PSD level would be processed exactly the >way >that any other tag in a DMARC record is processed=2E np will only be >ignored >(per the terms of the DMARC spec) when it is an "unrecognized" tag=2E I >realized that this text is sort of picked up from the current >description >of "sp", but the inclusion of "and PSDs" makes it inaccurate=2E You can't >publish an np record on a non-existent Org domain or any subdomain >thereof >:-) > >Secondly, I think that we need to update the "p" and "sp" descriptions >in >both 7489 sections 6=2E3 & 11=2E4: > >- p --> 'Policy applies to the domain queried and to subdomains, unless >subdomain policy is explicitly described using the "sp" tag=2E' change to >'Policy applies to the domain queried and to subdomains, unless >subdomain > policy is explicitly described using the "sp" or "np" tags=2E' > - sp --> 'Requested Mail Receiver policy for all subdomains >(plain-text; OPTIONAL)=2E Indicates the policy to be enacted by the >Receiver >at the request of the Domain Owner=2E It applies only to subdomains of >the >domain queried and not to the domain itself=2E' change to 'Requested Mail >Receiver policy for all subdomains (plain-text; OPTIONAL)=2E Indicates >the >policy to be enacted by the Receiver at the request of the Domain >Owner=2E >It applies only to subdomains of the domain queried if they exist or if > there is not an "np" tag published=2E "sp" does not apply to the domain > itself=2E" > >--Kurt From nobody Wed Jul 17 16:50:58 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 B7BB41201B5 for ; Wed, 17 Jul 2019 16:50:57 -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=B6e4s03w; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q1pmLl/y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrnkHjn-ptpN for ; Wed, 17 Jul 2019 16:50:56 -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 E78FF1201A2 for ; Wed, 17 Jul 2019 16:50:55 -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 C4F45F805D5; Wed, 17 Jul 2019 19:50:24 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563407424; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=SpnHvf0Pu+KOBDaY04SICw71Bmwr1EOEw7YnLr0upjk=; b=B6e4s03w0+l9pgbkbKRsGaIGQelprHmJ4opTyyZvZoWpry6uRsjYIEx6 9N94Wcm/MAZ+0sihc17DdCzn2zrNCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563407424; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=SpnHvf0Pu+KOBDaY04SICw71Bmwr1EOEw7YnLr0upjk=; b=Q1pmLl/yr7qHvgbZAaH5KiwH0C4OuGN8CEfnQ3OQaQvmBNw2ybhXQleU HENqheKeO6myb6C6Bkw01O3pHJmO+jB5/jmyLFqMi9Ui65WYXxdHUxldhd fMYxH2lVzOWJgyUzVDy8DY5hWXhviQeJG+AbMYO99VanWqzYcmdwKGrzrx g11n+BFg/gSSDxD4LrcHlOm3oIC4VxUPOp21TWqZa3J/sqk+1ECm5pHEGb fB6TsUzbChT+5lIzN/RgcVXt/JjEjezUGFS2zkE2RhHw1u93pg5tCkRz/9 AvdQvuQkviRy8gv1axEaLMOdusl19DgrUTIwgEX4aio4euPhegBWdw== Received: from [10.65.244.24] (mobile-166-170-51-136.mycingular.net [166.170.51.136]) by interserver.kitterman.com (Postfix) with ESMTPSA id 4AEBFF80042; Wed, 17 Jul 2019 19:50:24 -0400 (EDT) Date: Wed, 17 Jul 2019 23:50:21 +0000 In-Reply-To: <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.com> References: <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.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: <67D6F75C-3884-47A8-8AB6-F19088C03547@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Amazon Comments to DMARC Extension to 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, 17 Jul 2019 23:50:58 -0000 On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" wrote: >Amazon supports this draft and effort =2E > >This current DMARC extension (IETF DMARC PSD) >draft would >make it easier for our direct customers (registrants) to setup a common >DMARC policy for all their subdomains=2E With this extension they can set >up the policy in one place, such as the SLD level (second level domain) >and it will apply to any subdomain they create=2E However, since >feedback leakage can happen due to the nature of the IETF DMARC PSD >solution, the following proposed alternative could be employed to >address this issue=2E > >Is the DEMARC defined for dog=2Eanimals=2Ecom= ? > >a=2E Yes: then use it > >b=2E No: then look for DMARC on animals=2Ecom > >Proposed Default Alternative: >a=2E Is the DEMARC defined for >dog=2Eanimals=2Ecom? > >a=2E Yes: Then use it > >b=2E No: Is using the PSD DMARC explicitly permitted by the >dog=2Eanimals=2Ecom owner in some TXT record = (means >=E2=80=9Cdelegated explicitly to the PSD=E2=80=9D)? >1=2E Yes: then look for DMARC onanimals=2Ecom >1=2E No: terminate > >The alternative proposal requires the registrant to explicitly set up >the default=2E How would that work for non-existent domains? Appendix B describes options to address the issues=2E I like that your su= ggestion doesn't leave it in the hands of the PSO to self assert if PSD DMA= RC is appropriate, but I wonder why dog=2Eanimals=2Ecom doesn't just publis= h a DMARC record? Scott K From nobody Wed Jul 17 17:10:37 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 A30F7120230 for ; Wed, 17 Jul 2019 17:10:35 -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 T2nT6W9jyjPe for ; Wed, 17 Jul 2019 17:10:33 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B91012003E for ; Wed, 17 Jul 2019 17:10:33 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id n9so1586890wrr.4 for ; Wed, 17 Jul 2019 17:10:33 -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=SV3+TWAcJh+LJqWU1olTty2CqhyEO2TeI15YfJM2Pf4=; b=F5jsaAteoPuYtJmBDPZRZ1CLooKprYPq3RC5A37Cw6ksTXMLlwzCi3a4eYmm9+esGf 0nw+G9vO85kh+pt/gsYbHTDym6pifJxDs7wPJGF4CKcyB6RN1BksGR+bTnP4jFmptJIR nDCqyiX9joY1w52LdAz0whCE9qF0HlocWB0UfhAd23lJRMpzUsrPgx9oAJHCWj82vdaW 0qadIKwJgKkF/CkJqAj0P9s17BJFeOpIxksdBqJFJoS2KYWQz7GBs9YZSDQvtWX4jf7w o6tOS+sHocZlS7kVmkryq9fkzS0mZ5ALGetTzg32Tm9prwOX1AKhcJrAYEezv8f9suLA LPbg== 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=SV3+TWAcJh+LJqWU1olTty2CqhyEO2TeI15YfJM2Pf4=; b=s+7692RqvF+NIz+DZEFb5V9A8sNTUh8BDbycsFJqY2TzbAXWrhl31k/dnMtU8KCMg0 3q4PrOPXaMiZuIr7Z2b53o3dS4cJlZaIUq5/FUKIWLBvLiTa99WVPoBLX1qEuKsGpxPi DlsDMHL1WpuCsf5jRF8pouIHIkAB3FBVTZhr9it2AiiSGmVn0xFY7npuU9GbFm4lEneG CLaUf9+GHOLEuQxqsA4afv1dpcQsuiDqs61b3VgR+9wnxWudvGVaQB4RKE5+eQxQjhBW 77BvVtesQsrN0fTsW5bVuUD+6zW3vjejUUgtjdX5aXugV+vWBBn4/2dYs3IeGhp22Gzm Qd2g== X-Gm-Message-State: APjAAAXSpKxhePxI6RHbGKZvM1mJm3/nITv2YO+7Zzq0+7PIUZrrsZBW 0JIt0ceJJYw5D6YwZ0PERVjYuGClUIAzvRDGW/h6zA== X-Google-Smtp-Source: APXvYqyslKzzKyPziWqdbeSxjzzJkztAz899jzvkXLuSfUcULfAi2N4EU0ej77Zwz/IF3ZL3F/ar+KO4pQbHcueCTJ8= X-Received: by 2002:adf:ed0e:: with SMTP id a14mr44712842wro.259.1563408631761; Wed, 17 Jul 2019 17:10:31 -0700 (PDT) MIME-Version: 1.0 References: <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.com> <67D6F75C-3884-47A8-8AB6-F19088C03547@kitterman.com> In-Reply-To: <67D6F75C-3884-47A8-8AB6-F19088C03547@kitterman.com> From: Dotzero Date: Wed, 17 Jul 2019 20:10:20 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000228ee0058de97041" Archived-At: Subject: Re: [dmarc-ietf] Amazon Comments to DMARC Extension to 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, 18 Jul 2019 00:10:36 -0000 --000000000000228ee0058de97041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2019 at 7:51 PM Scott Kitterman wrote: > > > On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" 40amazon.com@dmarc.ietf.org> wrote: > >Amazon supports this draft and effort . > > > >This current DMARC extension (IETF DMARC PSD) > >draft would > >make it easier for our direct customers (registrants) to setup a common > >DMARC policy for all their subdomains. With this extension they can set > >up the policy in one place, such as the SLD level (second level domain) > >and it will apply to any subdomain they create. However, since > >feedback leakage can happen due to the nature of the IETF DMARC PSD > >solution, the following proposed alternative could be employed to > >address this issue. > > > >Is the DEMARC defined for dog.animals.com? > > > >a. Yes: then use it > > > >b. No: then look for DMARC on animals.com > > > >Proposed Default Alternative: > >a. Is the DEMARC defined for > >dog.animals.com? > > > >a. Yes: Then use it > > > >b. No: Is using the PSD DMARC explicitly permitted by the > >dog.animals.com owner in some TXT record (means > >=E2=80=9Cdelegated explicitly to the PSD=E2=80=9D)? > >1. Yes: then look for DMARC onanimals.com > >1. No: terminate > > > >The alternative proposal requires the registrant to explicitly set up > >the default. > > How would that work for non-existent domains? > > Appendix B describes options to address the issues. I like that your > suggestion doesn't leave it in the hands of the PSO to self assert if PSD > DMARC is appropriate, but I wonder why dog.animals.com doesn't just > publish a DMARC record? > > Scott K > > I have to wonder if the Amazon example is the general rule or the exception? For example, .bank requires all domains to have P=3Dreject. In their case they wouldn't want the (sub) domain to be able to override the .bank policy. I'm not sure that enabling a (sub) domain to disable the DMARC policy up the tree is a good idea. As Scott points out, all the (sub) domain has to do is publish their own DMARC record/policy and then it simply becomes a contractual issue. Michael Hammer --000000000000228ee0058de97041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 17, 2019 at 7:51 PM Scott= Kitterman <sklist@kitterman.com= > wrote:


On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" <flaim=3D40amazon.com@d= marc.ietf.org> wrote:
>Amazon supports this draft and effort .
>
>This current DMARC extension (IETF DMARC PSD)
>draft<https://datatracker.ietf.org/doc/= draft-ietf-dmarc-psd/> would
>make it easier for our direct customers (registrants) to setup a common=
>DMARC policy for all their subdomains. With this extension they can set=
>up the policy in one place, such as the SLD level (second level domain)=
>and it will apply to any subdomain they create.=C2=A0 However, since >feedback leakage can happen due to the nature of the IETF DMARC PSD
>solution, the following proposed alternative could be employed to
>address this issue.
>
>Is the DEMARC defined for dog.animals.com<http://dog.animals.com&g= t;?
>
>a.=C2=A0 =C2=A0 =C2=A0 Yes: then use it
>
>b.=C2=A0 =C2=A0 =C2=A0 No: then look for DMARC on animals.com<http://animals= .com>
>
>Proposed Default Alternative:
>a.=C2=A0 =C2=A0 =C2=A0 Is the DEMARC defined for
>dog.animals.com<http://dog.animals.com>?
>
>a.=C2=A0 =C2=A0 =C2=A0 Yes: Then use it
>
>b.=C2=A0 =C2=A0 =C2=A0 No: Is using the PSD DMARC explicitly permitted = by the
>dog.animals.com<http://dog.animals.com> owner in some TXT recor= d (means
>=E2=80=9Cdelegated explicitly to the PSD=E2=80=9D)?
>1.=C2=A0 =C2=A0 =C2=A0 Yes: then look for DMARC onanimals.com<http://animals= .com>
>1.=C2=A0 =C2=A0 =C2=A0 No: terminate
>
>The alternative proposal requires the registrant to explicitly set up >the default.

How would that work for non-existent domains?

Appendix B describes options to address the issues.=C2=A0 I like that your = suggestion doesn't leave it in the hands of the PSO to self assert if P= SD DMARC is appropriate, but I wonder why dog.animals.com doesn't just= publish a DMARC record?

Scott K


I have to wonder if the Amazon example= is the general rule or the exception? For example, .bank requires all doma= ins to have P=3Dreject. In their case they wouldn't want the (sub) doma= in to be able to override the .bank policy. I'm not sure that enabling = a (sub) domain to disable the DMARC policy up the tree is a good idea. As S= cott points out, all the (sub) domain has to do is publish their own DMARC = record/policy and then it simply becomes a contractual issue.
Michael Hammer

--000000000000228ee0058de97041-- From nobody Wed Jul 17 19:34: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 9534312062A for ; Wed, 17 Jul 2019 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=5SgwYxR2; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CeX1MTmW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86BcnRmWDajE for ; Wed, 17 Jul 2019 19:34:48 -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 C24D912060B for ; Wed, 17 Jul 2019 19:34:47 -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 EBDC3F805D5 for ; Wed, 17 Jul 2019 22:34:46 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563417286; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m15bpI1qoRUuT9SD8XsL9O1lTFUw3hevyNC6ih/94OM=; b=5SgwYxR2t9WPCtlU/CjHH2W5athbKGEUlITjTId6atPrf/JSo0+n292x 9kVA/O6rK2WzP84RxJkNX0+kazp8Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563417286; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m15bpI1qoRUuT9SD8XsL9O1lTFUw3hevyNC6ih/94OM=; b=CeX1MTmWKK4RjEejrkwI8ybam7EftGPPGF+gAUN19R/XvLlL8u+FLfiC F2ViX48j8JAkc9m+te6NvB8b7WrzUTgqWBMO7RLckoPstw8BlGoOIaEhnM dPXivPgnfhaPO9mc3aqZ2fnNy5VqdNOEC2oZiX72HqYLdaA+Mwuhypbpat 9/7pYqtFqGJiYS+sfyhBugecDhxBWfDSWMyw6NqIJtGtHoqmHSAKV7bxtV uAnB5amhjAN7tyoovHfiqvmOSEXHXhd+ZgSVT64Hn9f8ndGnsdbAnmy6lx YYCDasEh8cLiFXh3J316O9jRYkRHitJisyHGif4GpEPm1PHYxUQWFw== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 52DE9F80042 for ; Wed, 17 Jul 2019 22:34:45 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 17 Jul 2019 22:34:43 -0400 Message-ID: <4249121.lBB2AW0kmB@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 18 Jul 2019 02:34:50 -0000 > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" > wrote: > >Firstly, I'm a little concerned with the sentence which says 'Note that > >"np" will be ignored for DMARC records published on subdomains of > >Organizational Domains and PSDs due to the effect of the DMARC policy > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I > >don't > >think that is an accurate portrayal. When DMARC evaluation libraries > >are > >updated to do both PSD lookups and handle the np tag, I would expect > >the > >presence of np tags below the PSD level would be processed exactly the > >way > >that any other tag in a DMARC record is processed. np will only be > >ignored > >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I > >realized that this text is sort of picked up from the current > >description > >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't > >publish an np record on a non-existent Org domain or any subdomain > >thereof At first, I thought Kurt was right, but after further thought, I don't think so. To review the 'sp' definition that I took this from: Imagine sub.sub.example.com where example.com is the org domain. If sub.sub.example.com has no DMARC record, then the next lookup is for a DMARC record at the org domain (example.com). If sub.example.com has a DMARC record with an 'sp' tag, it's never retrieved. The same thing would apply to 'np' when used in a non--PSD context. No different. Keeping in mind that our definition of non-existent is a domain that has none of A, AAAA, or MX. It could have other types. It could also have subdomains called "_dmarc" that have TXT records. Non-existent domains (in our context) can have DMARC records, so I think the description is correct, but narrowly focused. Modifying the example I used above slightly: Imagine sub2.sub1.org.example where example has a PSD DMARC record with 'np', org.example has no DMARC record, sub1.org.example also has a DMARC record with 'np', and sub2.sub1.org.example has no DMARC record. In this case, the policy lookup is for sub2.sub1.org.example (exact domain), org.example (org domain), and then example (PSD). Just as with 'sp' and regular DMARC, 'np' (or 'sp') in non-org subdomains of PSDs don't get discovered. Scott K From nobody Wed Jul 17 22:28:27 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 13E26120144 for ; Wed, 17 Jul 2019 22:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=Uop+IbXr; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=jrp1G/EC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmQeTjqyT-tA for ; Wed, 17 Jul 2019 22:28:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7792120141 for ; Wed, 17 Jul 2019 22:28:24 -0700 (PDT) Received: (qmail 76434 invoked by uid 100); 18 Jul 2019 05:28:22 -0000 Date: 18 Jul 2019 05:28:22 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:cleverness; s=12a8a.5d300376.k1907; i=news@user.iecc.com; bh=gQIvLPHZ2NhULBnpaWzGfF18uaLwEgv3HZgyuLcxFy4=; b=Uop+IbXrsDxOkTe0qpavox/6KFHEb/VtPygCPgRRYM/Dv0kfQddxqKmigL/9tt+IGpGSsHoLenVaLZ3L+enGUL51mpbz9bSF4Drd9LwHh0mRogttrQSGvRkHPDBJD16u0aHpCTUKQC2305x56HGZd5HfvuPsl9rTfWthPxF0s7mjuCih6OMi85VrmgI2yfzhlLK57FOaF+qb/ndhcaIJvK1sPNvH0gJfx5Mts17hi/S6C3HAhKO+UX+NqL1xy5ZK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:cleverness; s=12a8a.5d300376.k1907; olt=news@user.iecc.com; bh=gQIvLPHZ2NhULBnpaWzGfF18uaLwEgv3HZgyuLcxFy4=; b=jrp1G/EC6OySJVW+nmXfaNmH/7wZlFig521bd2PzqWBZpvvmYsD/GGW8v2Nz2XcqPq6ZHSt2xUnkmZxgWnLnP7DP0M5TWIDUbX6uRN4UuoRLRczfuWMWGXygKO1Msz5rzVOkzYKTw4MCss33EMuGZmdnvjLI07E1dBHQtKIpPQ0bJpSVTZPqck4y9EsmuZcW5Jd21j05IWIVCM9pOU2ebX0BVh5zouK1T+eWAKQCta9nYyQDypqatgLXJMuJhOfD Organization: Taughannock Networks References: <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] Amazon Comments to DMARC Extension to 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, 18 Jul 2019 05:28:26 -0000 In article <132DD4E4-616A-47F5-A4A3-681067C86DA6@amazon.com>, Flaim, Bobby wrote: >-=-=-=-=-=- >Amazon supports this draft and effort . > >This current DMARC extension (IETF DMARC PSD) draft would make it >easier for our direct customers (registrants) to setup a common DMARC policy for all their subdomains. It looks like you may be misunderstanding what PSD is. If someone registers, say, pickle.deal, right now they can put an sp= tag in the record at _dmarc.pickle.deal which sets the policy for .pickle.deal. That's the way that organizational domains work. PSD lets you publish _dmarc.deal and have that apply by default to the whole TLD, .deal and ..deal and so forth. R's, John -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jul 18 08:42:55 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 D96081200E3 for ; Thu, 18 Jul 2019 08:42:53 -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=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyTgQD1S3Q6j for ; Thu, 18 Jul 2019 08:42:51 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 7088312008B for ; Thu, 18 Jul 2019 08:42:51 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id o9so52225179iom.3 for ; Thu, 18 Jul 2019 08:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWIm5L6kr37zCOm2u+Bcfa2HP4OZBIQGlOmmtFVLjjE=; b=fs8NbyOmZFM/70uw2Zk+3/MmoeirSSMAX64tg7SpdDI8nd5I3c29eDiH/p1wNcrwNi +7t3xi89Z0Ydji4Cg3UUzpOjVRdjtEbc/JRpEy5bLlRPwgwP018MY+YkB8WAuTRzN17d SJ8KWU5iVnZmmkGko/NOdscxMONyc/RC36ZAM= 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=yWIm5L6kr37zCOm2u+Bcfa2HP4OZBIQGlOmmtFVLjjE=; b=nsYk1QYNbGLHB4dqeyicdAQaWmpEGGdmN9PS8fh1YvKus8JbfD1K2MZg8x0MZS2BoU UiuGGME0+k8qbCA8icEXIqzSBHgcB3bhhkhoWuLcvvTBNqzPGwYThcBoz3rgcFviN00p jY+LxXCliQ+uGLogEyty//wQqrbjcCthefcARPlrJcV75qGJEAgAzNwtUHZaQWWL69i5 vsv+F8S9MfKvVPorR7jne3+6416uesnTkuhi5/hVovgiVQO7DARERDFHIZ/q1OgS584p TaFGIRqrjBZQQHa4wUbAhivtrHFCNAK20Bobx5rtMOH7qPFDresOnReapP1fAT2xFKlh Qx4Q== X-Gm-Message-State: APjAAAU+1zSt7HwLs84XnU0uSO7Iy2GU3HCk8OpZhgFVvdhb/fzjq3UO /UO7E2FmggxehmIVwbi4rF1wK6AvQEDSo+dMnkyU05gXK+g= X-Google-Smtp-Source: APXvYqw10Ao+p680Iv7/wDWVTicLlrpxBRJvLudvWFepjCl8vCEgwGmEQSU0netVmMrp/WqFRvHRXTcnqICVXXwaaHk= X-Received: by 2002:a6b:fb10:: with SMTP id h16mr34196590iog.195.1563464570409; Thu, 18 Jul 2019 08:42:50 -0700 (PDT) MIME-Version: 1.0 References: <4249121.lBB2AW0kmB@l5580> In-Reply-To: <4249121.lBB2AW0kmB@l5580> From: "Kurt Andersen (b)" Date: Thu, 18 Jul 2019 08:42:36 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000056af92058df67622" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 18 Jul 2019 15:42:54 -0000 --00000000000056af92058df67622 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman wrote: > > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" > > wrote: > > >Firstly, I'm a little concerned with the sentence which says 'Note that > > >"np" will be ignored for DMARC records published on subdomains of > > >Organizational Domains and PSDs due to the effect of the DMARC policy > > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I > > >don't > > >think that is an accurate portrayal. When DMARC evaluation libraries > > >are > > >updated to do both PSD lookups and handle the np tag, I would expect > > >the > > >presence of np tags below the PSD level would be processed exactly the > > >way > > >that any other tag in a DMARC record is processed. np will only be > > >ignored > > >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I > > >realized that this text is sort of picked up from the current > > >description > > >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't > > >publish an np record on a non-existent Org domain or any subdomain > > >thereof > > At first, I thought Kurt was right, but after further thought, I don't > think > so. > > To review the 'sp' definition that I took this from: > > Imagine sub.sub.example.com where example.com is the org domain. If > sub.sub.example.com has no DMARC record, then the next lookup is for a > DMARC > record at the org domain (example.com). If sub.example.com has a DMARC > record > with an 'sp' tag, it's never retrieved. > > The same thing would apply to 'np' when used in a non--PSD context. No > different. > > Keeping in mind that our definition of non-existent is a domain that has > none > of A, AAAA, or MX. It could have other types. It could also have > subdomains > called "_dmarc" that have TXT records. Non-existent domains (in our > context) > can have DMARC records, so I think the description is correct, but > narrowly > focused. > Most MTAs will also follow CNAMEs. Should they be included (along with other things like DNAME records) within the scope of existence? I'm a little concerned that we are making a special definition of "non-existence" which differs from the standard DNS concepts of NODATA and NXDOMAIN without having a correspondingly special name. > Modifying the example I used above slightly: > > Imagine sub2.sub1.org.example where example has a PSD DMARC record with > 'np', > org.example has no DMARC record, sub1.org.example also has a DMARC record > with > 'np', and sub2.sub1.org.example has no DMARC record. In this case, the > policy > lookup is for sub2.sub1.org.example (exact domain), org.example (org > domain), > and then example (PSD). Just as with 'sp' and regular DMARC, 'np' (or > 'sp') > in non-org subdomains of PSDs don't get discovered. > I was considering the case of a domain such as subX.sub1.org.pub2.pub1.example: * subX (and sub1) domains would only have direct lookup DMARC records applied if they exist and would fall back to org * org would be direct unless it doesn't have a record in which case if fall back to LPD (pub2's record) * pub2, pub1, and example would only have direct lookups since they are already above the PSL line <-- this is where my concern with the "and PSDs" phrase resides I'm not sure how well this maps to what we describe. I'm also concerned that a wildcard null MX record at the org level would end up having all subdomains "exist", but the policy that should be applied would be the more restrictive "np" policy, not the (possibly) more permissive "sp" policy. --Kurt --00000000000056af92058df67622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2019 at 7:35 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
> On July 17, 2019 8:14:54 PM UTC, "Kurt And= ersen (b)" <k= both@drkurt.com>
> wrote:
> >Firstly, I'm a little concerned with the sentence which says &= #39;Note that
> >"np" will be ignored for DMARC records published on subd= omains of
> >Organizational Domains and PSDs due to the effect of the DMARC pol= icy
> >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.= 9; I
> >don't
> >think that is an accurate portrayal. When DMARC evaluation librari= es
> >are
> >updated to do both PSD lookups and handle the np tag, I would expe= ct
> >the
> >presence of np tags below the PSD level would be processed exactly= the
> >way
> >that any other tag in a DMARC record is processed. np will only be=
> >ignored
> >(per the terms of the DMARC spec) when it is an "unrecognized= " tag. I
> >realized that this text is sort of picked up from the current
> >description
> >of "sp", but the inclusion of "and PSDs" makes= it inaccurate. You can't
> >publish an np record on a non-existent Org domain or any subdomain=
> >thereof

At first, I thought Kurt was right, but after further thought, I don't = think
so.

To review the 'sp' definition that I took this from:

Imagine sub.sub.example.com where example.com is the org domain.=C2=A0 = If
sub.sub.example.com has no DMARC record, then the next lookup is for a= DMARC
record at the org domain (example.com).=C2=A0 If sub.example.com has a DMARC = record
with an 'sp' tag, it's never retrieved.

The same thing would apply to 'np' when used in a non--PSD context.= =C2=A0 No
different.

Keeping in mind that our definition of non-existent is a domain that has no= ne
of A, AAAA, or MX.=C2=A0 It could have other types.=C2=A0 It could also hav= e subdomains
called "_dmarc" that have TXT records.=C2=A0 Non-existent domains= (in our context)
can have DMARC records, so I think the description is correct, but narrowly=
focused.

Most MTAs will also follow CNA= MEs. Should they be included (along with other things like DNAME records) w= ithin the scope of existence? I'm a little concerned that we are making= a special definition of "non-existence" which differs from the s= tandard DNS concepts of NODATA and NXDOMAIN without having a correspondingl= y special name.
=C2=A0
Modifying the example I used above slightly:

Imagine sub2.sub1.org.example where example has a PSD DMARC record with = 9;np',
org.example has no DMARC record, sub1.org.example also has a DMARC record w= ith
'np', and sub2.sub1.org.example has no DMARC record.=C2=A0 In this = case, the policy
lookup is for sub2.sub1.org.example (exact domain), org.example (org domain= ),
and then example (PSD).=C2=A0 Just as with 'sp' and regular DMARC, = 'np' (or 'sp')
in non-org subdomains of PSDs don't get discovered.

I was considering the case of a domain such as subX.sub1.o= rg.pub2.pub1.example:
* subX (and sub1) domains would only have d= irect lookup DMARC records applied if they exist and would fall back to org=
* org would be direct unless it doesn't have a record in whi= ch case if fall back to LPD (pub2's record)
* pub2, pub1, and= example would only have direct lookups since they are already above the PS= L line <-- this is where my concern with the "and PSDs" phrase= resides

I'm not sure how well this maps to wh= at we describe. I'm also concerned that a wildcard null MX record at th= e org level would end up having all subdomains "exist", but the p= olicy that should be applied would be the more restrictive "np" p= olicy, not the (possibly) more permissive "sp" policy.=C2=A0

--Kurt=C2=A0
--00000000000056af92058df67622-- From nobody Thu Jul 18 22:42:08 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 33C23120110 for ; Thu, 18 Jul 2019 22:42:06 -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=kwnrAonk; dkim=pass (2048-bit key) header.d=kitterman.com header.b=BkEd28KF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxoOcaF_pTpJ for ; Thu, 18 Jul 2019 22:42:02 -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 C154B120043 for ; Thu, 18 Jul 2019 22:42:02 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id A823CF8008C for ; Fri, 19 Jul 2019 01:41:31 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563514891; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=bxPQ4lMEt1LT3W5BOH1QR95judfcmk25dJrkOR5Nh3g=; b=kwnrAonkE8e1Ujd9CowQyOICFuQCBb7pbLZylPZfTvhtji2uTTeVmwqW 8AwwEmq42lLc0vwZ5lDnam6gcx0JBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563514891; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=bxPQ4lMEt1LT3W5BOH1QR95judfcmk25dJrkOR5Nh3g=; b=BkEd28KF+WiFz2gCF5AAbBPCdRfHVOIEHsaDNNFpj2+gkZ481RzydPfr HICWZaqUvgNNml4tWvnirD0VQw6ItI9j3sRQtrNn3KUjuA+bBzgzbAOQaf tC+zR/XziR1a1GuEt8nlPyv75APo5pqwIS9qwyXlGG6sHbb7JftLitm+7l YQHfhX/wA85iU3XJ2Ih5Px+k0U+qg5YJ09iXpHSG+ZvHdHIY3SLKzlLRg7 dRC4bHtNUL6tvBE6h3ELH3EubNBo2Qo3owAeeKhD10eOwWtidRhQBePLHm 4EsfOV0vKvEV616xyQKlXxQLl6W9SL+Yr9i0H3Oz4HbUxSotTNG7pQ== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id EF266F80042 for ; Fri, 19 Jul 2019 01:41:30 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Jul 2019 01:41:28 -0400 Message-ID: <3280991.vD5HP6B0ME@l5580> In-Reply-To: References: <4249121.lBB2AW0kmB@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 19 Jul 2019 05:42:06 -0000 On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote: > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > wrote: > > > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" > > > > > > wrote: > > > >Firstly, I'm a little concerned with the sentence which says 'Note that > > > >"np" will be ignored for DMARC records published on subdomains of > > > >Organizational Domains and PSDs due to the effect of the DMARC policy > > > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I > > > >don't > > > >think that is an accurate portrayal. When DMARC evaluation libraries > > > >are > > > >updated to do both PSD lookups and handle the np tag, I would expect > > > >the > > > >presence of np tags below the PSD level would be processed exactly the > > > >way > > > >that any other tag in a DMARC record is processed. np will only be > > > >ignored > > > >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I > > > >realized that this text is sort of picked up from the current > > > >description > > > >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't > > > >publish an np record on a non-existent Org domain or any subdomain > > > >thereof > > > > At first, I thought Kurt was right, but after further thought, I don't > > think > > so. > > > > To review the 'sp' definition that I took this from: > > > > Imagine sub.sub.example.com where example.com is the org domain. If > > sub.sub.example.com has no DMARC record, then the next lookup is for a > > DMARC > > record at the org domain (example.com). If sub.example.com has a DMARC > > record > > with an 'sp' tag, it's never retrieved. > > > > The same thing would apply to 'np' when used in a non--PSD context. No > > different. > > > > Keeping in mind that our definition of non-existent is a domain that has > > none > > of A, AAAA, or MX. It could have other types. It could also have > > subdomains > > called "_dmarc" that have TXT records. Non-existent domains (in our > > context) > > can have DMARC records, so I think the description is correct, but > > narrowly > > focused. > > Most MTAs will also follow CNAMEs. Should they be included (along with > other things like DNAME records) within the scope of existence? I'm a > little concerned that we are making a special definition of "non-existence" > which differs from the standard DNS concepts of NODATA and NXDOMAIN without > having a correspondingly special name. OK. I wish you'd jumped in earlier when we were discussing that exact topic. https://mailarchive.ietf.org/arch/msg/dmarc/44sVJzvPkXkdT7Np-0ANr9Wm2Zc If we want to take another run at this and put it in more standard DNS terminology, then maybe: ... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. I think that cures John's concern with my last proposal and addresses yours as well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are correctly followed). > > Modifying the example I used above slightly: > > > > Imagine sub2.sub1.org.example where example has a PSD DMARC record with > > 'np', > > org.example has no DMARC record, sub1.org.example also has a DMARC record > > with > > 'np', and sub2.sub1.org.example has no DMARC record. In this case, the > > policy > > lookup is for sub2.sub1.org.example (exact domain), org.example (org > > domain), > > and then example (PSD). Just as with 'sp' and regular DMARC, 'np' (or > > 'sp') > > in non-org subdomains of PSDs don't get discovered. > > I was considering the case of a domain such as > subX.sub1.org.pub2.pub1.example: > * subX (and sub1) domains would only have direct lookup DMARC records > applied if they exist and would fall back to org > * org would be direct unless it doesn't have a record in which case if fall > back to LPD (pub2's record) > * pub2, pub1, and example would only have direct lookups since they are > already above the PSL line <-- this is where my concern with the "and PSDs" > phrase resides It's possible that could happen, but it's not the most general case. There are probably a nearly infinite variety of ways this could work or not work, I don't think we have to describe them all. > I'm not sure how well this maps to what we describe. I'm also concerned > that a wildcard null MX record at the org level would end up having all > subdomains "exist", but the policy that should be applied would be the more > restrictive "np" policy, not the (possibly) more permissive "sp" policy. I think this is one of those "you must be this tall to ride on this ride" situations. DNS comes equipped with multiple footguns and you have to know a bit about what you're doing to make sure you get the effects you're after. Scott K From nobody Fri Jul 19 00:29: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 49FB912012E for ; Fri, 19 Jul 2019 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97uw0lanh3KS for ; Fri, 19 Jul 2019 00:29:06 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110138.outbound.protection.outlook.com [40.107.11.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5761120125 for ; Fri, 19 Jul 2019 00:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hwkmOA02CdEeDKmwgnHks3hTPTBOOZ9Z6zT6wejmjF4cGLRZuAa7KxbAGkPw0Tyt8jeGWYtMBeEwjCWB/Z1HPYHeFlRih6r7oR7y4+Bztq9fWVuz2eMIloDPM4N0f5eXAJAjwcZfrJUtay5AnDcljSe6Mn/byBa6h/DKd0SVppX3k3tfhoFxJmEimMvLFv35tjmHigZeQ1sGNsbU3u4XZpJKJY49WApqrY2SOJjdG1BCh5rFzXKEPtM1Ej1fHeyASsPmG7BeFcQ2D27pflvnTSxQjgpa97bxRK8Y4G4dWEVcW/2mhmdwZLuwAh9mZHHLAfVCirBI1iJxDkwTuHgDfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IUyEv6VDQ2mL00b6+WewH7ha5KXZClHJX+KLFERAVHg=; b=TSI4gKYc9aIV6ABdktGC4eSY2PGLSIsfmV+M54ewY9/wd52ZrN/6eluBsoIixYnynRC3xeCj1xeU+Eo118DMviEPmn7ey5PBshrdtw7h/yW035wlZykI/30AtCjAd3xs4YtlZ4ePSrha9QtTeejOchuUyorGPhYL6UV1fJxJwaHaXKMvLrEoRqguyXsrlAuNCu0qKUXCJ/f7YvupY0UErjZ7BQ+I7hZhjIwyWzRYppcK5mxSPmmJTft00TkMgsOzlG2p1OcrTaBxC4z4Sy14ENGcwx6GFoRGsaTPOmY/wWtYtmmV0039LF3ZQSz9jdLsUx0k3p4roixzTAKUZuZDFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IUyEv6VDQ2mL00b6+WewH7ha5KXZClHJX+KLFERAVHg=; b=gDHu6E+TQaMKYly1VrGQE+IW3qBSBxIXXg4J2YyFKUnYTZl7S6BtE43/JQDbUm6KV8W5E2xmq07aS0AGJLzRWtNfTruua9ZTvjb4CVx5BYFJiZWt39OlMfmqfs+/oKP+TZMl+xLrt3L7gVENMzyLFmUdqNFrff3E4W6RWzZ672g= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2544.GBRP123.PROD.OUTLOOK.COM (20.176.157.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 07:29:03 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 07:29:03 +0000 From: Ian Levy To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAJaoCAAaTUgIAFVuCAgAD9pACAADq9AIAAL2GAgADcIgCAAOphAIAACBSg Date: Fri, 19 Jul 2019 07:29:03 +0000 Message-ID: References: <4249121.lBB2AW0kmB@l5580> <3280991.vD5HP6B0ME@l5580> In-Reply-To: <3280991.vD5HP6B0ME@l5580> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.140.114.144] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa36305d-2066-40f4-6b6a-08d70c1ac67e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2544; x-ms-traffictypediagnostic: LO2P123MB2544: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(39850400004)(136003)(396003)(366004)(189003)(199004)(51444003)(13464003)(66066001)(14444005)(86362001)(53546011)(76176011)(44832011)(102836004)(186003)(7696005)(71200400001)(26005)(6506007)(6436002)(53936002)(316002)(476003)(6246003)(486006)(99286004)(9686003)(71190400001)(6306002)(446003)(11346002)(55016002)(66446008)(25786009)(55236004)(64756008)(81156014)(7736002)(478600001)(5660300002)(2906002)(561944003)(966005)(45080400002)(66476007)(81166006)(6116002)(14454004)(256004)(229853002)(8936002)(76116006)(8676002)(33656002)(68736007)(66556008)(3846002)(110136005)(74316002)(52536014)(305945005)(2501003)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2544; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qMEuubfZQcU0mJ/+VDLs7fRIcvFH6jDRs8s39wr6ZQvVZx1Q2JzRAqt6s7SMD5ENc35SFs9vzeT1HzY3su9ii1eW4TeOSp72St3Xsx/iZ7Rq8PONQVzZqb9hMxOv66PSo0L7QUmnhK+H5Dk6h7TR7siVpWlGwAE7DYkAUAtBc9G+PiARTp1JPoT/Yb2ewb1P6TWFTlosi5oTAuejdZVAbYCAWuElYucjfVyFiBYrFb/CpKBDK+QrbQpYGqidiqntfJDcaLW8bw4a7/lKLKS7WmUDnghUWMlZtL2fL7CSzA0l9ekcbibC8H6LnGGtAFZpXfG384zg6T1S/D2ScjPTQ9JHBbSHrUNJnPpLNFrt2mo/l8F3s5jaEjHi4YqF4EdkC3+2jK4R2zpdpW1ZBv+tLwI+WjUnXBa9wY8GntpJaIU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: aa36305d-2066-40f4-6b6a-08d70c1ac67e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 07:29:03.2802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2544 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 19 Jul 2019 07:29:09 -0000 PiBJIHRoaW5rIHRoaXMgaXMgb25lIG9mIHRob3NlICJ5b3UgbXVzdCBiZSB0aGlzIHRhbGwgdG8g cmlkZSBvbiB0aGlzIHJpZGUiDQo+IHNpdHVhdGlvbnMuICBETlMgY29tZXMgZXF1aXBwZWQgd2l0 aCBtdWx0aXBsZSBmb290Z3VucyBhbmQgeW91IGhhdmUgdG8ga25vdyBhIGJpdCBhYm91dCB3aGF0 IHlvdSdyZSBkb2luZyB0byBtYWtlIHN1cmUgeW91IGdldCB0aGUgZWZmZWN0cyB5b3UncmUgYWZ0 ZXIuDQoNClRoaXMuIERNQVJDIHRvZGF5IGFsbG93cyBwZW9wbGUgdG8gZGlzY29ubmVjdCB0aGVp ciBvdXRnb2luZyBtYWlsIGZyb20gdGhlIHJlc3Qgb2YgdGhlIHdvcmxkLiBBZG1pdHRlZGx5LCB0 aGUgUFNELWxldmVsIHBvbGljaWVzIHdvdWxkIGhhdmUgYSBtdWNoIGdyZWF0ZXIgZWZmZWN0LCBi dXQgeW91ciBQU0QvVExEIG9wZXJhdG9yIGNhbiBhbHJlYWR5IGJvcmsgeW91IGlmIHRoZXkncmUg bm90IGNvbXBldGVudC4gDQpUaGVyZSBhcmUgdHdvIGRpZmZlcmVudCBidWNrZXRzIG9mIHJpc2sg aW4gbXkgdmlldywgdGhvdWdoIDoNCjEpIE5ldyBUTERzIGFyZSBlZmZlY3RpdmVseSBncmVlbmZp ZWxkIHNpdGVzIGFuZCBjYW4gZW5mb3JjZSBhcHByb3ByaWF0ZSByZXF1aXJlbWVudHMgb24gdGhl aXIgY3VzdG9tZXJzIGZyb20gdGhlIHN0YXJ0IHRvIG1pbmltaXplIHRoZSBjaGFuY2Ugb2YgdW5p bnRlbmRlZCBjb25zZXF1ZW5jZXMgKGZvciBleGFtcGxlLCBieSByZXF1aXJpbmcgZG9tYWluIERN QVJDIGxhYmVscykuIA0KMikgRXhpc3RpbmcgVExEcywgd2hlcmUgdGhlcmUgYXJlIG1hbnkgc3Vi ZG9tYWlucyB3aXRoIHdpbGRseSB2YXJpYWJsZSBpbXBsZW1lbnRhdGlvbnMsIHBvbGljaWVzIGFu ZCB1c2UgYW5kIGhlcmUgd2UgYXJlIGdvaW5nIHRvIGhhdmUgdG8gYmUgcmVhbGx5IGNhcmVmdWwu IENhcmVmdWwgYW5kIG1ldGhvZGljYWwgdGVzdGluZyB3aWxsIGJlIG5lY2Vzc2FyeSB0byBtYWtl IHN1cmUgdGhhdCBpbnRyb2R1Y3Rpb24gb2YgdGhlIFBTRC1sZXZlbCBwb2xpY2llcyBkb2Vzbid0 IGJyZWFrIGFueXRoaW5nIGltcG9ydGFudC4gSXQgdG9vayB1cyA2IG1vbnRocyB0byBnZXQgdG8g c3ludGhlc2l6aW5nIHA9cmVqZWN0IGZvciBub24tZXhpc3RlbnQgc3ViZG9tYWlucyBvZiAuZ292 LnVrLiBBIGxvdCBvZiB0aGF0IHdhcyBhbmFseXNpbmcgdGhlIGRhdGEgd2UgZ290IGJhY2sgYW5k IGZpeGluZyBzdHVmZiB0aGF0IHdlIG5ldmVyIGV4cGVjdGVkIChsaWtlIEtlcmJlcm9zIC0gZG9u J3QgYXNrISkuIEkgZG9uJ3Qgc2VlIHdoeSBpdCB3b3VsZCBiZSBkaWZmZXJlbnQgd2l0aCB0aGUg bnA9IHRhZywgYnV0IGl0IHdpbGwgaG9wZWZ1bGx5IGJlIG11Y2ggbW9yZSBsaW1pdGVkIGluIHdo YXQgd2UgY291bGQgbWVzcyB1cC4NCiANCkkgdGhpbmsgd2UncmUgcmVhbGx5IGFsbCB3b3JyaWVk IGFib3V0IHRoZSBzZWNvbmQgb2YgdGhlc2UgY2FzZXMuIElmIHRoYXQncyB0cnVlLCB0aGVuIEkn bSB3aXRoIFNjb3R0IC0gaWYgeW91IGRvbid0IHVuZGVyc3RhbmQgdGhpcyBzdHVmZiwgZG9uJ3Qg Z28gYW5kIHNldCBhbiBucCB0YWcgb24geW91ciBQU0QgYW5kIGNyb3NzIHlvdXIgZmluZ2Vycy4g SXQncyBnb2luZyB0byBlbmQgYmFkbHkuIE9uZSBvZiB0aGUgdGhpbmdzIGFib3V0IGRvaW5nIHRo ZSBleHBlcmltZW50IGlzIHN1cmVseSB0byBoZWxwIHVzIHVuZGVyc3RhbmQgaG93IGJhZGx5IHRo ZXNlIGNhbiBnbyB3cm9uZywgc28gd2UgY2FuIHdyaXRlIGRvd24gYSBidW5jaCBvZiB3YXlzIG5v dCB0byBkbyB0aGluZ3MuDQoNCldlIGNhbiB3cml0ZSBpbiB0aGUgZG9jdW1lbnQgdGhhdCBzY2lz c29ycyBhcmUgc2hhcnAgYW5kIHJ1bm5pbmcgd2l0aCBzaGFycCB0aGluZ3MgY2FuIGNhdXNlIHBy b2JsZW1zLiBCdXQgaW4gdGhlIGVuZCwgc29tZW9uZSBpcyBnb2luZyB0byBydW4gd2l0aCBzY2lz c29ycyBhbmQgZ2V0IGh1cnQuIFdlIGNhbid0IGNvZGUgZm9yIGV2ZXJ5IHNpbmdsZSBjYXNlIGhl cmUgYW5kIHdlIHN1cmVseSBtdXN0IGFzc3VtZSBhIGxldmVsIG9mIGNvbXBldGVuY2Ugb2YgcGVv cGxlIGltcGxlbWVudGluZyBzb21ldGhpbmcgbGlrZSB0aGlzLg0KDQpUYS4NCg0KSS4NCiANCi0t DQpEciBJYW4gTGV2eQ0KVGVjaG5pY2FsIERpcmVjdG9yDQpOYXRpb25hbCBDeWJlciBTZWN1cml0 eSBDZW50cmUNCmlhbkBuY3NjLmdvdi51aw0KDQpTdGFmZiBPZmZpY2VyIDogS2F0ZSBBdGtpbnMs IGthdGUuYUBuY3NjLmdvdi51aw0KDQooSSB3b3JrIHN0dXBpZCBob3VycyBhbmQgd2VpcmQgdGlt ZXMg4oCTIHRoYXQgZG9lc27igJl0IG1lYW4geW91IGhhdmUgdG8uIElmIHRoaXMgYXJyaXZlcyBv dXRzaWRlIHlvdXIgbm9ybWFsIHdvcmtpbmcgaG91cnMsIGRvbuKAmXQgZmVlbCBjb21wZWxsZWQg dG8gcmVzcG9uZCBpbW1lZGlhdGVseSEpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBkbWFyYyA8ZG1hcmMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFNjb3R0IEtp dHRlcm1hbg0KU2VudDogMTkgSnVseSAyMDE5IDA2OjQxDQpUbzogZG1hcmNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gTm9uZXhpc3RlbnQgRG9tYWluIFBvbGljeSB3YXM6IFJl OiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1kbWFyYy1wc2QNCg0KT24gVGh1 cnNkYXksIEp1bHkgMTgsIDIwMTkgMTE6NDI6MzYgQU0gRURUIEt1cnQgQW5kZXJzZW4gKGIpIHdy b3RlOg0KPiBPbiBXZWQsIEp1bCAxNywgMjAxOSBhdCA3OjM1IFBNIFNjb3R0IEtpdHRlcm1hbiA8 c2tsaXN0QGtpdHRlcm1hbi5jb20+DQo+DQo+IHdyb3RlOg0KPiA+ID4gT24gSnVseSAxNywgMjAx OSA4OjE0OjU0IFBNIFVUQywgIkt1cnQgQW5kZXJzZW4gKGIpIiANCj4gPiA+IDxrYm90aEBkcmt1 cnQuY29tPg0KPiA+ID4NCj4gPiA+IHdyb3RlOg0KPiA+ID4gPkZpcnN0bHksIEknbSBhIGxpdHRs ZSBjb25jZXJuZWQgd2l0aCB0aGUgc2VudGVuY2Ugd2hpY2ggc2F5cyANCj4gPiA+ID4nTm90ZSB0 aGF0ICJucCIgd2lsbCBiZSBpZ25vcmVkIGZvciBETUFSQyByZWNvcmRzIHB1Ymxpc2hlZCBvbiAN Cj4gPiA+ID5zdWJkb21haW5zIG9mIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMgYW5kIFBTRHMgZHVl IHRvIHRoZSBlZmZlY3QgDQo+ID4gPiA+b2YgdGhlIERNQVJDIHBvbGljeSBkaXNjb3ZlcnkgbWVj aGFuaXNtIGRlc2NyaWJlZCBpbiBETUFSQyANCj4gPiA+ID5bUkZDNzQ4OV0gU2VjdGlvbiA2LjYu My4nIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhbiBhY2N1cmF0ZSANCj4gPiA+ID5wb3J0cmF5YWwu IFdoZW4gRE1BUkMgZXZhbHVhdGlvbiBsaWJyYXJpZXMgYXJlIHVwZGF0ZWQgdG8gZG8gYm90aCAN Cj4gPiA+ID5QU0QgbG9va3VwcyBhbmQgaGFuZGxlIHRoZSBucCB0YWcsIEkgd291bGQgZXhwZWN0 IHRoZSBwcmVzZW5jZSBvZiANCj4gPiA+ID5ucCB0YWdzIGJlbG93IHRoZSBQU0QgbGV2ZWwgd291 bGQgYmUgcHJvY2Vzc2VkIGV4YWN0bHkgdGhlIHdheSANCj4gPiA+ID50aGF0IGFueSBvdGhlciB0 YWcgaW4gYSBETUFSQyByZWNvcmQgaXMgcHJvY2Vzc2VkLiBucCB3aWxsIG9ubHkgDQo+ID4gPiA+ YmUgaWdub3JlZCAocGVyIHRoZSB0ZXJtcyBvZiB0aGUgRE1BUkMgc3BlYykgd2hlbiBpdCBpcyBh biANCj4gPiA+ID4idW5yZWNvZ25pemVkIiB0YWcuIEkgcmVhbGl6ZWQgdGhhdCB0aGlzIHRleHQg aXMgc29ydCBvZiBwaWNrZWQgDQo+ID4gPiA+dXAgZnJvbSB0aGUgY3VycmVudCBkZXNjcmlwdGlv biBvZiAic3AiLCBidXQgdGhlIGluY2x1c2lvbiBvZiANCj4gPiA+ID4iYW5kIFBTRHMiIG1ha2Vz IGl0IGluYWNjdXJhdGUuIFlvdSBjYW4ndCBwdWJsaXNoIGFuIG5wIHJlY29yZCBvbiANCj4gPiA+ ID5hIG5vbi1leGlzdGVudCBPcmcgZG9tYWluIG9yIGFueSBzdWJkb21haW4gdGhlcmVvZg0KPiA+ DQo+ID4gQXQgZmlyc3QsIEkgdGhvdWdodCBLdXJ0IHdhcyByaWdodCwgYnV0IGFmdGVyIGZ1cnRo ZXIgdGhvdWdodCwgSSANCj4gPiBkb24ndCB0aGluayBzby4NCj4gPg0KPiA+IFRvIHJldmlldyB0 aGUgJ3NwJyBkZWZpbml0aW9uIHRoYXQgSSB0b29rIHRoaXMgZnJvbToNCj4gPg0KPiA+IEltYWdp bmUgc3ViLnN1Yi5leGFtcGxlLmNvbSB3aGVyZSBleGFtcGxlLmNvbSBpcyB0aGUgb3JnIGRvbWFp bi4gIElmIA0KPiA+IHN1Yi5zdWIuZXhhbXBsZS5jb20gaGFzIG5vIERNQVJDIHJlY29yZCwgdGhl biB0aGUgbmV4dCBsb29rdXAgaXMgZm9yIA0KPiA+IGEgRE1BUkMgcmVjb3JkIGF0IHRoZSBvcmcg ZG9tYWluIChleGFtcGxlLmNvbSkuICBJZiBzdWIuZXhhbXBsZS5jb20gDQo+ID4gaGFzIGEgRE1B UkMgcmVjb3JkIHdpdGggYW4gJ3NwJyB0YWcsIGl0J3MgbmV2ZXIgcmV0cmlldmVkLg0KPiA+DQo+ ID4gVGhlIHNhbWUgdGhpbmcgd291bGQgYXBwbHkgdG8gJ25wJyB3aGVuIHVzZWQgaW4gYSBub24t LVBTRCBjb250ZXh0LiAgDQo+ID4gTm8gZGlmZmVyZW50Lg0KPiA+DQo+ID4gS2VlcGluZyBpbiBt aW5kIHRoYXQgb3VyIGRlZmluaXRpb24gb2Ygbm9uLWV4aXN0ZW50IGlzIGEgZG9tYWluIHRoYXQg DQo+ID4gaGFzIG5vbmUgb2YgQSwgQUFBQSwgb3IgTVguICBJdCBjb3VsZCBoYXZlIG90aGVyIHR5 cGVzLiAgSXQgY291bGQgDQo+ID4gYWxzbyBoYXZlIHN1YmRvbWFpbnMgY2FsbGVkICJfZG1hcmMi IHRoYXQgaGF2ZSBUWFQgcmVjb3Jkcy4gIA0KPiA+IE5vbi1leGlzdGVudCBkb21haW5zIChpbiBv dXINCj4gPiBjb250ZXh0KQ0KPiA+IGNhbiBoYXZlIERNQVJDIHJlY29yZHMsIHNvIEkgdGhpbmsg dGhlIGRlc2NyaXB0aW9uIGlzIGNvcnJlY3QsIGJ1dCANCj4gPiBuYXJyb3dseSBmb2N1c2VkLg0K Pg0KPiBNb3N0IE1UQXMgd2lsbCBhbHNvIGZvbGxvdyBDTkFNRXMuIFNob3VsZCB0aGV5IGJlIGlu Y2x1ZGVkIChhbG9uZyB3aXRoIA0KPiBvdGhlciB0aGluZ3MgbGlrZSBETkFNRSByZWNvcmRzKSB3 aXRoaW4gdGhlIHNjb3BlIG9mIGV4aXN0ZW5jZT8gSSdtIGEgDQo+IGxpdHRsZSBjb25jZXJuZWQg dGhhdCB3ZSBhcmUgbWFraW5nIGEgc3BlY2lhbCBkZWZpbml0aW9uIG9mICJub24tZXhpc3RlbmNl Ig0KPiB3aGljaCBkaWZmZXJzIGZyb20gdGhlIHN0YW5kYXJkIEROUyBjb25jZXB0cyBvZiBOT0RB VEEgYW5kIE5YRE9NQUlOIA0KPiB3aXRob3V0IGhhdmluZyBhIGNvcnJlc3BvbmRpbmdseSBzcGVj aWFsIG5hbWUuDQoNCk9LLiAgSSB3aXNoIHlvdSdkIGp1bXBlZCBpbiBlYXJsaWVyIHdoZW4gd2Ug d2VyZSBkaXNjdXNzaW5nIHRoYXQgZXhhY3QgdG9waWMuDQoNCmh0dHBzOi8vZXVyMDMuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZl LmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRmRtYXJjJTJGNDRzVkp6dlBrWGtkVDdOcC0wQU5yOVdt MlpjJmFtcDtkYXRhPTAyJTdDMDElN0NpYW4ubGV2eSU0MG5jc2MuZ292LnVrJTdDZmQwNGE1ODRm MzM5NGFkY2FlYmEwOGQ3MGMwYmRlYmQlN0MxNGFhNTc0NGVjZTE0NzRlYTJkNzM0ZjQ2ZGRhNjRh MSU3QzAlN0MwJTdDNjM2OTkxMTE3NDQxNTIzOTczJmFtcDtzZGF0YT1VWm9rNWlXRjRrS3V0cEUl MkY2JTJGTjQzQ3dMUEFndEdQYmFSYUxHaDRHZSUyQnowJTNEJmFtcDtyZXNlcnZlZD0wDQoNCklm IHdlIHdhbnQgdG8gdGFrZSBhbm90aGVyIHJ1biBhdCB0aGlzIGFuZCBwdXQgaXQgaW4gbW9yZSBz dGFuZGFyZCBETlMgdGVybWlub2xvZ3ksIHRoZW4gbWF5YmU6DQoNCi4uLi4gYSBkb21haW4gZm9y IHdoaWNoIHRoZXJlIGlzIGFuIE5YRE9NQUlOIG9yIE5PREFUQSByZXNwb25zZSBmb3IgQSwgQUFB QSwgYW5kIE1YIHJlY29yZHMuDQoNCkkgdGhpbmsgdGhhdCBjdXJlcyBKb2huJ3MgY29uY2VybiB3 aXRoIG15IGxhc3QgcHJvcG9zYWwgYW5kIGFkZHJlc3NlcyB5b3VycyBhcyB3ZWxsICh0aGUgcmVz cG9uc2UgdG8gYSBDTkFNRS9ETkFNRSBpcyBub3QgTk9EQVRBL05YRE9NQUlOLCBzbyB0aGV5IGFy ZSBjb3JyZWN0bHkgZm9sbG93ZWQpLg0KDQo+ID4gTW9kaWZ5aW5nIHRoZSBleGFtcGxlIEkgdXNl ZCBhYm92ZSBzbGlnaHRseToNCj4gPg0KPiA+IEltYWdpbmUgc3ViMi5zdWIxLm9yZy5leGFtcGxl IHdoZXJlIGV4YW1wbGUgaGFzIGEgUFNEIERNQVJDIHJlY29yZCANCj4gPiB3aXRoICducCcsIG9y Zy5leGFtcGxlIGhhcyBubyBETUFSQyByZWNvcmQsIHN1YjEub3JnLmV4YW1wbGUgYWxzbyANCj4g PiBoYXMgYSBETUFSQyByZWNvcmQgd2l0aCAnbnAnLCBhbmQgc3ViMi5zdWIxLm9yZy5leGFtcGxl IGhhcyBubyBETUFSQyANCj4gPiByZWNvcmQuICBJbiB0aGlzIGNhc2UsIHRoZSBwb2xpY3kgbG9v a3VwIGlzIGZvciANCj4gPiBzdWIyLnN1YjEub3JnLmV4YW1wbGUgKGV4YWN0IGRvbWFpbiksIG9y Zy5leGFtcGxlIChvcmcgZG9tYWluKSwgYW5kIA0KPiA+IHRoZW4gZXhhbXBsZSAoUFNEKS4gIEp1 c3QgYXMgd2l0aCAnc3AnIGFuZCByZWd1bGFyIERNQVJDLCAnbnAnIChvcg0KPiA+ICdzcCcpDQo+ ID4gaW4gbm9uLW9yZyBzdWJkb21haW5zIG9mIFBTRHMgZG9uJ3QgZ2V0IGRpc2NvdmVyZWQuDQo+ DQo+IEkgd2FzIGNvbnNpZGVyaW5nIHRoZSBjYXNlIG9mIGEgZG9tYWluIHN1Y2ggYXMNCj4gc3Vi WC5zdWIxLm9yZy5wdWIyLnB1YjEuZXhhbXBsZToNCj4gKiBzdWJYIChhbmQgc3ViMSkgZG9tYWlu cyB3b3VsZCBvbmx5IGhhdmUgZGlyZWN0IGxvb2t1cCBETUFSQyByZWNvcmRzIA0KPiBhcHBsaWVk IGlmIHRoZXkgZXhpc3QgYW5kIHdvdWxkIGZhbGwgYmFjayB0byBvcmcNCj4gKiBvcmcgd291bGQg YmUgZGlyZWN0IHVubGVzcyBpdCBkb2Vzbid0IGhhdmUgYSByZWNvcmQgaW4gd2hpY2ggY2FzZSBp ZiANCj4gZmFsbCBiYWNrIHRvIExQRCAocHViMidzIHJlY29yZCkNCj4gKiBwdWIyLCBwdWIxLCBh bmQgZXhhbXBsZSB3b3VsZCBvbmx5IGhhdmUgZGlyZWN0IGxvb2t1cHMgc2luY2UgdGhleSANCj4g YXJlIGFscmVhZHkgYWJvdmUgdGhlIFBTTCBsaW5lIDwtLSB0aGlzIGlzIHdoZXJlIG15IGNvbmNl cm4gd2l0aCB0aGUgImFuZCBQU0RzIg0KPiBwaHJhc2UgcmVzaWRlcw0KDQpJdCdzIHBvc3NpYmxl IHRoYXQgY291bGQgaGFwcGVuLCBidXQgaXQncyBub3QgdGhlIG1vc3QgZ2VuZXJhbCBjYXNlLiAg VGhlcmUgYXJlIHByb2JhYmx5IGEgbmVhcmx5IGluZmluaXRlIHZhcmlldHkgb2Ygd2F5cyB0aGlz IGNvdWxkIHdvcmsgb3Igbm90IHdvcmssIEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSB0byBkZXNjcmli ZSB0aGVtIGFsbC4NCg0KPiBJJ20gbm90IHN1cmUgaG93IHdlbGwgdGhpcyBtYXBzIHRvIHdoYXQg d2UgZGVzY3JpYmUuIEknbSBhbHNvIA0KPiBjb25jZXJuZWQgdGhhdCBhIHdpbGRjYXJkIG51bGwg TVggcmVjb3JkIGF0IHRoZSBvcmcgbGV2ZWwgd291bGQgZW5kIHVwIA0KPiBoYXZpbmcgYWxsIHN1 YmRvbWFpbnMgImV4aXN0IiwgYnV0IHRoZSBwb2xpY3kgdGhhdCBzaG91bGQgYmUgYXBwbGllZCAN Cj4gd291bGQgYmUgdGhlIG1vcmUgcmVzdHJpY3RpdmUgIm5wIiBwb2xpY3ksIG5vdCB0aGUgKHBv c3NpYmx5KSBtb3JlIHBlcm1pc3NpdmUgInNwIiBwb2xpY3kuDQoNCkkgdGhpbmsgdGhpcyBpcyBv bmUgb2YgdGhvc2UgInlvdSBtdXN0IGJlIHRoaXMgdGFsbCB0byByaWRlIG9uIHRoaXMgcmlkZSIN CnNpdHVhdGlvbnMuICBETlMgY29tZXMgZXF1aXBwZWQgd2l0aCBtdWx0aXBsZSBmb290Z3VucyBh bmQgeW91IGhhdmUgdG8ga25vdyBhIGJpdCBhYm91dCB3aGF0IHlvdSdyZSBkb2luZyB0byBtYWtl IHN1cmUgeW91IGdldCB0aGUgZWZmZWN0cyB5b3UncmUgYWZ0ZXIuDQoNClNjb3R0IEsNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFp bGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGZG1hcmMmYW1wO2RhdGE9MDIlN0MwMSU3Q2lhbi5sZXZ5JTQwbmNzYy5n b3YudWslN0NmZDA0YTU4NGYzMzk0YWRjYWViYTA4ZDcwYzBiZGViZCU3QzE0YWE1NzQ0ZWNlMTQ3 NGVhMmQ3MzRmNDZkZGE2NGExJTdDMCU3QzAlN0M2MzY5OTExMTc0NDE1MjM5NzMmYW1wO3NkYXRh PXpUR0ZzJTJCTEZWT1BGTHIlMkJ4NXc1JTJCSWJjU205Q1F2Q1dQa0FlNzdvN2phT2MlM0QmYW1w O3Jlc2VydmVkPTANClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRoZSBGcmVlZG9t IG9mIEluZm9ybWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1wdCB1bmRlciBv dGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEgcXVlcmllcyB0 byBuY3NjaW5mb2xlZ0BuY3NjLmdvdi51ay4gQWxsIG1hdGVyaWFsIGlzIFVLIENyb3duIENvcHly aWdodCDCqQ0K From nobody Fri Jul 19 05:04: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 5FA05120089 for ; Fri, 19 Jul 2019 05:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIf2Rrxy3qNv for ; Fri, 19 Jul 2019 05:04:34 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE0F120019 for ; Fri, 19 Jul 2019 05:04:33 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id y4so32036010wrm.2 for ; Fri, 19 Jul 2019 05:04:33 -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=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=l3PBVWtdIgJ32tyFdyepRfngRJmZtem3lusL7URZ6Uj2/s1hm5Jbp3Jcxgv73nvw5x FHo3B+wdrRCHJhehhC0K6KKBjcTDAhs5DuYZzZLNuqZ3t7ygJpLWwW2XjUKD10/YvsZC VI77dc1RkpFgv/+WwI31PmxxE6XScSwUFoip33bdjS//GiYAKcO6CHE4x7fyZoct0epZ 2zjx8hwDazEIpE+29xdHNx9c9J0cBALzCWZBca+eWC4u1mZC6crcg+JjctTqEKK45sJi OUoEPzYo9nSpG+OtIy2JPbY5j1kOoH1Ea5Y2tl9MOS3LuKE/ZEs4u7m75E2jMY3JJtjZ dbzw== 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=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=Ubg32yMzG+JgND6WkxflAOuungxuEEJRSBceNg4qpoSNDsBWfQR4+E2WuqCEOlzRlE avqep7g/WxtvXkOdARkpkoL4uLGBer8d1bEg6j137T6drAPPSolU08JjQDOzM8LCmsrb hY2HXTx+iq1GGF57lTuYuItj5dfktqousUxg9hQqy7lEXGNv3Wfb1tpW/UXuSy1CxhXH PNYPv6W6kOFRduL1DaHN+LI/JR5UkM6Pnk8AvFmq13j/LxATPZdmNsHALg2aAVI5einO Ha1/GEob/LijvKIg741UILbyAV2Ha1t/ZIIPvt1Axwq1czoKJ2LxPIfGiGX9eRFUl317 DBDg== X-Gm-Message-State: APjAAAWKBHz2eIxmNJIa0q7jvpxKdibACW0MbeiqD+YYU6PeDYs0/Wkg 2sL75/JZx9WwhjbssAANdnhs2vQePg3DePB6Op7rng== X-Google-Smtp-Source: APXvYqwHoSzOS+DDK63Uabhj0QX0USzfOc23uH0wrMvTX8qQtJwE7Oh4xq3Yk+B/gy7imRsFxNqZnXj4lmRbdqX+OxU= X-Received: by 2002:a5d:4484:: with SMTP id j4mr56280342wrq.143.1563537872336; Fri, 19 Jul 2019 05:04:32 -0700 (PDT) MIME-Version: 1.0 References: <4249121.lBB2AW0kmB@l5580> <3280991.vD5HP6B0ME@l5580> In-Reply-To: From: Dotzero Date: Fri, 19 Jul 2019 08:04:20 -0400 Message-ID: To: Ian Levy Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000793cb9058e07874a" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 19 Jul 2019 12:04:37 -0000 --000000000000793cb9058e07874a Content-Type: text/plain; charset="UTF-8" I've been following the discussion but haven't contributed anything until this point. Comment below. On Fri, Jul 19, 2019 at 3:29 AM Ian Levy wrote: > > I think this is one of those "you must be this tall to ride on this ride" > > situations. DNS comes equipped with multiple footguns and you have to > know a bit about what you're doing to make sure you get the effects you're > after. > > This. DMARC today allows people to disconnect their outgoing mail from the > rest of the world. Admittedly, the PSD-level policies would have a much > greater effect, but your PSD/TLD operator can already bork you if they're > not competent. > There are two different buckets of risk in my view, though : > 1) New TLDs are effectively greenfield sites and can enforce appropriate > requirements on their customers from the start to minimize the chance of > unintended consequences (for example, by requiring domain DMARC labels). > 2) Existing TLDs, where there are many subdomains with wildly variable > implementations, policies and use and here we are going to have to be > really careful. Careful and methodical testing will be necessary to make > sure that introduction of the PSD-level policies doesn't break anything > important. It took us 6 months to get to synthesizing p=reject for > non-existent subdomains of .gov.uk. A lot of that was analysing the data > we got back and fixing stuff that we never expected (like Kerberos - don't > ask!). I don't see why it would be different with the np= tag, but it will > hopefully be much more limited in what we could mess up. > > I think we're really all worried about the second of these cases. If > that's true, then I'm with Scott - if you don't understand this stuff, > don't go and set an np tag on your PSD and cross your fingers. It's going > to end badly. One of the things about doing the experiment is surely to > help us understand how badly these can go wrong, so we can write down a > bunch of ways not to do things. > > We can write in the document that scissors are sharp and running with > sharp things can cause problems. But in the end, someone is going to run > with scissors and get hurt. We can't code for every single case here and we > surely must assume a level of competence of people implementing something > like this. > > The problem, which we know or should know, is that DNS records are apparently difficult to get right. We have a large corpus of data points to back this up based on decades of experience. Even large, supposedly experienced and technically qualified organizations shoot themselves in the foot. Speaking as an original participant in the dmarc.org team, I can't emphasize enough the education and evangelization effort involved related to adoption (and misunderstanding of how it works... or doesn't work). I think you are incorrect with your assumption regarding scenario #1. I recently had a discussion with an owner/operator of a number of "new" TLDs. They have no clue regarding this effort. So even if a TLD is new, that does not mean it will implement from day 1. This means scenario #2 is more likely the scenario to be dealt with (default) rather than #1. Perhaps after some extended period of pain or if ICANN mandates something, #1 will become the default, but I wouldn't hold my breath. With regard to scenario #2, it is not enough to simply say "don't run with scissors". Some group, M3AAWG or ICANN or ISOC, will need to educate and evangelize those outside the inner circle, so to speak. I'm sure that companies like Agari, Dmarcian, Valimail, etc. will gladly provide assistance., That TLD owner/operator I mentioned earlier is not overly familiar with the space or those vendors. It is not enough for the creators of a proposed standard to state it's technical validity. This implies a deployment document based on the experiences of early adopters. Just a few thoughts. Michael Hammer --000000000000793cb9058e07874a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've been followi= ng the discussion but haven't contributed anything until this point. Co= mment below.

On Fri, Jul 19, 2019 at 3:29 AM Ian Levy <ian.levy=3D<= a href=3D"mailto:40ncsc.gov.uk@dmarc.ietf.org">40ncsc.gov.uk@dmarc.ietf.org= > wrote:
> I think this is one of those= "you must be this tall to ride on this ride"
> situations.=C2=A0 DNS comes equipped with multiple footguns and you ha= ve to know a bit about what you're doing to make sure you get the effec= ts you're after.

This. DMARC today allows people to disconnect their outgoing mail from the = rest of the world. Admittedly, the PSD-level policies would have a much gre= ater effect, but your PSD/TLD operator can already bork you if they're = not competent.
There are two different buckets of risk in my view, though :
1) New TLDs are effectively greenfield sites and can enforce appropriate re= quirements on their customers from the start to minimize the chance of unin= tended consequences (for example, by requiring domain DMARC labels).
2) Existing TLDs, where there are many subdomains with wildly variable impl= ementations, policies and use and here we are going to have to be really ca= reful. Careful and methodical testing will be necessary to make sure that i= ntroduction of the PSD-level policies doesn't break anything important.= It took us 6 months to get to synthesizing p=3Dreject for non-existent sub= domains of .= gov.uk. A lot of that was analysing the data we got back and fixing stu= ff that we never expected (like Kerberos - don't ask!). I don't see= why it would be different with the np=3D tag, but it will hopefully be muc= h more limited in what we could mess up.

I think we're really all worried about the second of these cases. If th= at's true, then I'm with Scott - if you don't understand this s= tuff, don't go and set an np tag on your PSD and cross your fingers. It= 's going to end badly. One of the things about doing the experiment is = surely to help us understand how badly these can go wrong, so we can write = down a bunch of ways not to do things.

We can write in the document that scissors are sharp and running with sharp= things can cause problems. But in the end, someone is going to run with sc= issors and get hurt. We can't code for every single case here and we su= rely must assume a level of competence of people implementing something lik= e this.


The problem, which we know = or should know, is that DNS records are apparently difficult to get right. = We have a large corpus of data points to back this up based on decades of e= xperience. Even large, supposedly experienced and technically qualified org= anizations shoot themselves in the foot. Speaking as an original participan= t in the dmarc.org team, I can't empha= size enough the education and evangelization effort involved related to ado= ption (and misunderstanding of how it works... or doesn't work).
<= div>
I think you are incorrect with your assumption regarding= scenario #1. I recently had a discussion with an owner/operator of a numbe= r of "new" TLDs. They have no clue regarding this effort. So even= if a TLD is new, that does not mean it will implement from day 1. This mea= ns scenario #2 is more likely the scenario to be dealt with (default) rathe= r than #1. Perhaps after some extended period of pain or if ICANN mandates = something, #1 will become the default, but I wouldn't hold my breath.

With regard to scenario #2, it is not enough to sim= ply say "don't run with scissors". Some group, M3AAWG or ICAN= N or ISOC, will need to educate and evangelize those outside the inner circ= le, so to speak. I'm sure that companies like Agari, Dmarcian, Valimail= , etc. will gladly provide assistance., That TLD owner/operator I mentioned= earlier is not overly familiar with the space or those vendors.
=
It is not enough for the creators of a proposed standard to = state it's technical validity. This implies a deployment document based= on the experiences of early adopters.=C2=A0

Just = a few thoughts.

Michael Hammer
--000000000000793cb9058e07874a-- From nobody Fri Jul 19 08:30:21 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 8D9EE1206B3 for ; Fri, 19 Jul 2019 08:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTUQyS4noo2z for ; Fri, 19 Jul 2019 08:30:17 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435A01206B1 for ; Fri, 19 Jul 2019 08:30:17 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id j6so26940494ioa.5 for ; Fri, 19 Jul 2019 08:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iHA02wPI7HU378onXgBYUzDhCkgB/ouFjNpsV36gWA4=; b=LPKhj+JB4rguFyMOzuiTVoVNZcjMJbCWcltXYEk7IBe11y0olq5xKwR8sG0eirGtmY JXEgwvxwDn1bN40CIQ23R8HWe3cpQveqCzCugcYSWCSwkduD6W2jzMABOzJhuf2K0Pg4 93T5a7UKCaSqCR7RW2ooDnOrEDiTlT2UomyBM= 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=iHA02wPI7HU378onXgBYUzDhCkgB/ouFjNpsV36gWA4=; b=Cvr3GOGxxLKGk7jMBHRrVrj6blNBYqrlaHlS1sHDCU9HLFLwjY6j5/6rR367pfad9L pAebYMrWHXFQrXoyEd2JJo0j6cYBeRHghcYSA/3N6Gf0UzLWKBrPYKVca9+mGtxnAwGx 1VjoUuzv9hsoOzHZjxrFJ5PIbDMoOMuOjhmzO5cfgguafKrvgFOtf0aboPfQJ2lops2W z0LUsw4UDkwLuvpqD/g3VE8HKZOVM2Nl9Et3MxZHYqdIs0hPu4VyNb5LWbWIFXu7AA0O TPBbCQYmoGtp8lw1hs8piflBcF2QEQQX+SOcjh1p2j2UxpmdWF5e+hWJRicQwYHCsgbv CbNg== X-Gm-Message-State: APjAAAVYW04Duaf9ddy/7ZAg3sdC5fbWvnIpNanlhLUFZCkOrFBUkQEd jF/Tmzms5BsW0bLRrnPMuX37W4YZHpqPAygKxt8j6Mgk X-Google-Smtp-Source: APXvYqyJU4XpxETWvKD11NdgKed5Wt7btwjCJrVgMnPm03J7dNkRoLr64hfnPNwNiNuhdkLWtrXc3qxxD8wyeBazZQo= X-Received: by 2002:a5e:9917:: with SMTP id t23mr50628005ioj.23.1563550216259; Fri, 19 Jul 2019 08:30:16 -0700 (PDT) MIME-Version: 1.0 References: <4249121.lBB2AW0kmB@l5580> <3280991.vD5HP6B0ME@l5580> In-Reply-To: <3280991.vD5HP6B0ME@l5580> From: "Kurt Andersen (b)" Date: Fri, 19 Jul 2019 08:30:01 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003aabe2058e0a6727" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 19 Jul 2019 15:30:20 -0000 --0000000000003aabe2058e0a6727 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman wrote: > On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote: > > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > > > Most MTAs will also follow CNAMEs. Should they be included (along with > > other things like DNAME records) within the scope of existence? I'm a > > little concerned that we are making a special definition of > "non-existence" > > which differs from the standard DNS concepts of NODATA and NXDOMAIN > without > > having a correspondingly special name. > > OK. I wish you'd jumped in earlier when we were discussing that exact > topic. > > https://mailarchive.ietf.org/arch/msg/dmarc/44sVJzvPkXkdT7Np-0ANr9Wm2Zc > > If we want to take another run at this and put it in more standard DNS > terminology, then maybe: > > .... a domain for which there is an NXDOMAIN or NODATA response for A, > AAAA, > and MX records. > > I think that cures John's concern with my last proposal and addresses > yours as > well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are > correctly followed). > Yes - I think that will fix my concerns (and John's too). > > I'm also concerned > > that a wildcard null MX record at the org level would end up having all > > subdomains "exist", but the policy that should be applied would be the > more > > restrictive "np" policy, not the (possibly) more permissive "sp" policy. > > I think this is one of those "you must be this tall to ride on this ride" > situations. DNS comes equipped with multiple footguns and you have to > know a > bit about what you're doing to make sure you get the effects you're after. > Perhaps a reminder in the text related to "np" that wildcards may cause undesired results and leave it as an exercise for the implementor to learn from that warning. --Kurt --0000000000003aabe2058e0a6727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 18, 2019 at 10:42 PM Scott Ki= tterman <sklist@kitterman.com> wrote:
On Thursday, July 18, 2019 11:42:36 AM EDT Kurt And= ersen (b) wrote:
> On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman <sklist@kitterman.com>
>
> Most MTAs will also follow CNAMEs. Should they be included (along with=
> other things like DNAME records) within the scope of existence? I'= m a
> little concerned that we are making a special definition of "non-= existence"
> which differs from the standard DNS concepts of NODATA and NXDOMAIN wi= thout
> having a correspondingly special name.

OK.=C2=A0 I wish you'd jumped in earlier when we were discussing that e= xact topic.

https://mailarchive.ietf.org/= arch/msg/dmarc/44sVJzvPkXkdT7Np-0ANr9Wm2Zc

If we want to take another run at this and put it in more standard DNS
terminology, then maybe:

.... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA= ,
and MX records.

I think that cures John's concern with my last proposal and addresses y= ours as
well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are correctly followed).

Yes - I think that= will fix my concerns (and John's too).
=C2=A0
> I'm also concerned
> that a wildcard null MX record at the org level would end up having al= l
> subdomains "exist", but the policy that should be applied wo= uld be the more
> restrictive "np" policy, not the (possibly) more permissive = "sp" policy.

I think this is one of those "you must be this tall to ride on this ri= de"
situations.=C2=A0 DNS comes equipped with multiple footguns and you have to= know a
bit about what you're doing to make sure you get the effects you're= after.

Perhaps a reminder in the text = related to "np" that wildcards may cause undesired results and le= ave it as an exercise for the implementor to learn from that warning.
=

--Kurt=C2=A0
--0000000000003aabe2058e0a6727-- From nobody Fri Jul 19 08:33: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 66AC1120404 for ; Fri, 19 Jul 2019 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzorFjbFfPq1 for ; Fri, 19 Jul 2019 08:33:53 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 8D15A1206B1 for ; Fri, 19 Jul 2019 08:33:53 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id e20so28910029iob.9 for ; Fri, 19 Jul 2019 08:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NCFKLXs8iZ8oA3tL4jmO9MD4BIn0LW3s9ZcuqB/eAuI=; b=EQsAJyRdjqIwg1daSr8hMbX4QqVb1cPR16NTLbi8dojNCHqvhhSQ8k9kRcz3MVQuTO clZhG1dMyAvJZqo7g8+Mn4L+WotWOVE+rre+l/+XmdzWpkTaYU24pWhSdxE3elge/TSh WwB4jGxdDh4DgopcgysgWpqkRF7N4Xhw2+kok= 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=NCFKLXs8iZ8oA3tL4jmO9MD4BIn0LW3s9ZcuqB/eAuI=; b=EmxByxsls+RBSkontpLNi6a4bD5x6oOdxcqx8WdeBq0eGnYYEhkwuihx/ZKX6tVL3U jBt6ko3rqHpSJr6+o+ISmuUi6kKLw+Ytiok7LpMDRa29CLtp68IrC0x21Zfjf/khAL7l 1w8xFANl57fl6zl0R+oY54jNygxMB1UnoLcsLb1wuXu5it5QKkYI2PE9q9up98cl8RUT jGu+NDUxMAh0ImhE72jzjb0tyv+zoLN4f24UhTfnLXM2rFvMe2JIsHcHWTduSD2P5CXt KVgQW3i2qxsT3oZa/7pAGNPkS7dHDkR+LylL4MMbMEXLIDPy4XPADq6oWxetNcdjnh+W w6yA== X-Gm-Message-State: APjAAAVxhojiWZ9Ojb43TtTPOkZZz8kYJp77tn5taGzVfrRDJs4xhj64 n9V/ZFWLUfpIIHBnRlvqc5cZDX8O5SZ93JwbuM+E7YEv X-Google-Smtp-Source: APXvYqzum3USJzWC8TbtEKDVQTFJQ/N0PUc/rCJlTieVV8m7i+BVfrYeouGgB4ezxo0bNoXWjBdbo6azuT13HEM29RQ= X-Received: by 2002:a6b:fb10:: with SMTP id h16mr40353552iog.195.1563550432648; Fri, 19 Jul 2019 08:33:52 -0700 (PDT) MIME-Version: 1.0 References: <4249121.lBB2AW0kmB@l5580> <3280991.vD5HP6B0ME@l5580> In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 19 Jul 2019 08:33:38 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000020759e058e0a74a9" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 19 Jul 2019 15:33:56 -0000 --00000000000020759e058e0a74a9 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote: > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman > wrote: > >> >> If we want to take another run at this and put it in more standard DNS >> terminology, then maybe: >> >> .... a domain for which there is an NXDOMAIN or NODATA response for A, >> AAAA, >> and MX records. >> >> I think that cures John's concern with my last proposal and addresses >> yours as >> well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are >> correctly followed). >> > > Yes - I think that will fix my concerns (and John's too). > Thinking about this from a reporting POV, where would a receiver categorize messages which ended up with SERVFAIL during the process of DMARC (regular or PSD)? Would "sp" handling or "np" handling be invoked for SERVFAIL (such as a broken DNSSEC implementation)? --Kurt --00000000000020759e058e0a74a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2019 at 8:30 AM Kurt Ande= rsen (b) <kboth@drkurt.com> w= rote:
On Thu, Jul 18, 2019 at = 10:42 PM Scott Kitterman <sklist@kitterman.com> wrote:

If we want to take another run at this and put it in more standard DNS
terminology, then maybe:

.... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA= ,
and MX records.

I think that cures John's concern with my last proposal and addresses y= ours as
well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are correctly followed).

Yes - I think that= will fix my concerns (and John's too).
<= div>
Thinking about this from a reporting POV, where would a = receiver categorize messages which ended up with SERVFAIL during the proces= s of DMARC (regular or PSD)? Would "sp" handling or "np"= ; handling be invoked for SERVFAIL (such as a broken DNSSEC implementation)= ?
=C2=A0
--Kurt
--00000000000020759e058e0a74a9-- From nobody Fri Jul 19 20:13:33 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 DEB4A12004E for ; Fri, 19 Jul 2019 20:13:30 -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=QLA0Tx3t; dkim=pass (2048-bit key) header.d=kitterman.com header.b=OMYYq3Fx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsYJlHHDiwa9 for ; Fri, 19 Jul 2019 20:13:29 -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 05D42120044 for ; Fri, 19 Jul 2019 20:13:28 -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 E9ED6F80499 for ; Fri, 19 Jul 2019 23:13:26 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563592406; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=EbKa8CbMw2ueL8bEFmD2TOp0nCkXq6nG8nzV0K7Jhho=; b=QLA0Tx3tehS0OYUUVZQwdxtcNbHcu+vPOxtQi6ys4aeMmm/1KIqWuP2T omLP4bYZlAh/iY2BwNEzkJTwoE4DDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563592406; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=EbKa8CbMw2ueL8bEFmD2TOp0nCkXq6nG8nzV0K7Jhho=; b=OMYYq3FxC0XWi4sNfASNQqEQzHwW8/8gqGRTBRj7KuXxDHixoCkCcaQg Ikpv9r8UQkhDDQHm5q0BRG/cbBcPvUA/P/4IssxM2FzaVFjebBiV/agtDg xkK+XkcO0YUCh1M/VrU6ct+8VLA/VLRXitAryVmOM6yMSAUddAB2n8/Ek6 YBbQwq/6V96pMAtiwYZVYcacZopbiw5WId9Sr70tG/AKzfb5AqOeJItgMb YTazPkKo5muZmkONs8oUZELMQ8ToHrTwgukRAUPLyMyt/4o6hbF4jndqlx cuG/5HLDwnjUF+V0WKXjY5jHKcZiBoFUJiXfN1WCKoQn8tAeA1h1Kg== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 9407FF80042 for ; Fri, 19 Jul 2019 23:13:26 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Fri, 19 Jul 2019 23:13:25 -0400 Message-ID: <2002899.ZhquKih7Hz@l5580> In-Reply-To: References: <3280991.vD5HP6B0ME@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:13:31 -0000 On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote: ... > > > I'm also concerned > > > that a wildcard null MX record at the org level would end up having all > > > subdomains "exist", but the policy that should be applied would be the > > > > more > > > > > restrictive "np" policy, not the (possibly) more permissive "sp" policy. > > > > I think this is one of those "you must be this tall to ride on this ride" > > situations. DNS comes equipped with multiple footguns and you have to > > know a > > bit about what you're doing to make sure you get the effects you're after. > > Perhaps a reminder in the text related to "np" that wildcards may cause > undesired results and leave it as an exercise for the implementor to learn > from that warning. It seems like either too much or not enough. This at least slightly concerns me because I don't want to warn about the implication of one DNS feature without being comprehensive. DMARC deployment in any non-trivial organization is an inter-disciplinary task, even more so PSD DMARC. I don't think we want to take on being a deployment guide, so I'd leave it out. Let's see what others think. Scott K From nobody Fri Jul 19 20:15:40 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 64E561200E7 for ; Fri, 19 Jul 2019 20:15:39 -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=Kmoz8cTK; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NFOSi0rl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvl7rB7HkwUz for ; Fri, 19 Jul 2019 20:15:37 -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 9455C12004E for ; Fri, 19 Jul 2019 20:15:37 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id E2534F80499 for ; Fri, 19 Jul 2019 23:15:06 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=Kmoz8cTKTC95Wo+eeYuW8KGT1MpG+x2/n25OjxzHMyH6SS3QBiTaszEs 9AX1pbCMzC7z6LRIwUl0gUVDdihiCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=NFOSi0rlkOo1kvaeAbyB88WCwO3D3KLKcTRRdEv3sYmXwfX2r9UPZU/E 6NTK0r4RwKlm6LA9XvW9+H7xOfkeA9ZkjB3GuHHmB22Z3b8jQbIDcmFU/g Pnb8MPJ6efpeVrVYTsVDiQLkobnDTJeh4hu5Rcw38y3vgKBJ/qf90Pjp07 0oG+RcFT6tQcvG/wGzltnuaqdYS2St0aePL6QOy8nbc5ordaauiHDORfcB tRNGIPLg3gJffXKj46svYRI4Bj7ubEm+3HP4+tMVI3IzLhp5+IBy7Y6wDq 13UpAXVfbZAgr3S4IDojO2LYUhk4KfHbvy5Aqr8mCZ1CWR27HrxzwA== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 84255F80042 for ; Fri, 19 Jul 2019 23:15:06 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Fri, 19 Jul 2019 23:15:04 -0400 Message-ID: <2333259.aoXCTIVaPC@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:15:40 -0000 On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote: > I've been following the discussion but haven't contributed anything until > this point. Comment below. > > On Fri, Jul 19, 2019 at 3:29 AM Ian Levy > 40ncsc.gov.uk@dmarc.ietf.org> wrote: > > > I think this is one of those "you must be this tall to ride on this > > > ride" > > > situations. DNS comes equipped with multiple footguns and you have to > > > > know a bit about what you're doing to make sure you get the effects you're > > after. > > > > This. DMARC today allows people to disconnect their outgoing mail from the > > rest of the world. Admittedly, the PSD-level policies would have a much > > greater effect, but your PSD/TLD operator can already bork you if they're > > not competent. > > There are two different buckets of risk in my view, though : > > 1) New TLDs are effectively greenfield sites and can enforce appropriate > > requirements on their customers from the start to minimize the chance of > > unintended consequences (for example, by requiring domain DMARC labels). > > 2) Existing TLDs, where there are many subdomains with wildly variable > > implementations, policies and use and here we are going to have to be > > really careful. Careful and methodical testing will be necessary to make > > sure that introduction of the PSD-level policies doesn't break anything > > important. It took us 6 months to get to synthesizing p=reject for > > non-existent subdomains of .gov.uk. A lot of that was analysing the data > > we got back and fixing stuff that we never expected (like Kerberos - don't > > ask!). I don't see why it would be different with the np= tag, but it will > > hopefully be much more limited in what we could mess up. > > > > I think we're really all worried about the second of these cases. If > > that's true, then I'm with Scott - if you don't understand this stuff, > > don't go and set an np tag on your PSD and cross your fingers. It's going > > to end badly. One of the things about doing the experiment is surely to > > help us understand how badly these can go wrong, so we can write down a > > bunch of ways not to do things. > > > > We can write in the document that scissors are sharp and running with > > sharp things can cause problems. But in the end, someone is going to run > > with scissors and get hurt. We can't code for every single case here and > > we > > surely must assume a level of competence of people implementing something > > like this. > > The problem, which we know or should know, is that DNS records are > apparently difficult to get right. We have a large corpus of data points to > back this up based on decades of experience. Even large, supposedly > experienced and technically qualified organizations shoot themselves in the > foot. Speaking as an original participant in the dmarc.org team, I can't > emphasize enough the education and evangelization effort involved related > to adoption (and misunderstanding of how it works... or doesn't work). > > I think you are incorrect with your assumption regarding scenario #1. I > recently had a discussion with an owner/operator of a number of "new" TLDs. > They have no clue regarding this effort. So even if a TLD is new, that does > not mean it will implement from day 1. This means scenario #2 is more > likely the scenario to be dealt with (default) rather than #1. Perhaps > after some extended period of pain or if ICANN mandates something, #1 will > become the default, but I wouldn't hold my breath. > > With regard to scenario #2, it is not enough to simply say "don't run with > scissors". Some group, M3AAWG or ICANN or ISOC, will need to educate and > evangelize those outside the inner circle, so to speak. I'm sure that > companies like Agari, Dmarcian, Valimail, etc. will gladly provide > assistance., That TLD owner/operator I mentioned earlier is not overly > familiar with the space or those vendors. > > It is not enough for the creators of a proposed standard to state it's > technical validity. This implies a deployment document based on the > experiences of early adopters. I agree, but I think solving that is outside the scope of the current document. Scott K From nobody Fri Jul 19 20:16:41 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 758E512004E for ; Fri, 19 Jul 2019 20:16:40 -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 eRIVQYNtpDzN for ; Fri, 19 Jul 2019 20:16:38 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73210120044 for ; Fri, 19 Jul 2019 20:16:38 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id m202so25745639oig.6 for ; Fri, 19 Jul 2019 20:16: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=Kp/e5XHcGVMNalyTIjKp7JWFX2c8k+n/CCB2xIZweI8=; b=BbEZdGJ9zM/uHYKuzwn0Pmp3sfjRQNQ5lxkH2NlXyKyVnxzLIeoE3v7mKf8AQVl9BX DwQ2QPPpbfv1n5s7Wd4XJ0n2zGK7bh26p6P162N76f/2JpZK2l+6k1uaW1N4LiQM455n eLONVmD4E+UBv1ORjZh2/8YP1HzPPq8Xnd6JKvzwYUZ0S/vC+1vTbp1WeuETQb4un7ZY PJwHvTY7jJEB1sY9jZ8Fiak3bK8Blbbyj44A864EyMWh0YedBPsk/81aUEugitspXW1i cqnrMkM7EomthL/Xch/oaEXfj6sShhGIKpip+cFHrF67Ht+ntE9BmYh6R9ZPYs4xjlZa UtIQ== 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=Kp/e5XHcGVMNalyTIjKp7JWFX2c8k+n/CCB2xIZweI8=; b=FP9GjrYxUzonrXtljH3PqCNGvZXvbb+87nXwArWTp8l0qDz/c7wN0czXQXORRg7TMJ GLqLgUAnPqnX5mQ1YWCMonykcQW2LD4Fy3dkZzmbL++nfU5s1BjbZHaz8KhwyFc4inB6 co8C71J+j7MeZB7sbgPTyDXShC09UFSBYcdRvzO8/fhX/dVkU8vnRxfNYXRJFKg6IwtZ gbjjF8uWF4BLRpuKUbzwREStQIxB2YqtuEgRYdZRmR38KNwN5NVcc6zqe8auF/dt4QHr sIiP9s9tQGer4Uv8LpInJ05GD/b5iDuOFVR2C6lYJIQo+eAssjsc1TahLEQJKCYE51qB AMxg== X-Gm-Message-State: APjAAAUp2CDAvhWnDXkjd0CQvWSWZg+xZ6wjPbjiYe3ck7lFmTR124X1 o0m7HrDAqpIqE8ROJNrm2hD5q5ssLGyRY8n6DHKC4w== X-Google-Smtp-Source: APXvYqw+Imkj5bwngoz9lMuN5wvidfejx92rByvcjcDzGrMZeUhXsY9qBItG8Rkht6i0e1+0+cJqyI/yhzAQbuFrB9w= X-Received: by 2002:aca:b406:: with SMTP id d6mr27848933oif.173.1563592597751; Fri, 19 Jul 2019 20:16:37 -0700 (PDT) MIME-Version: 1.0 References: <3280991.vD5HP6B0ME@l5580> <2002899.ZhquKih7Hz@l5580> In-Reply-To: <2002899.ZhquKih7Hz@l5580> From: Tim Wicinski Date: Fri, 19 Jul 2019 23:16:26 -0400 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005cca77058e144502" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:16:40 -0000 --0000000000005cca77058e144502 Content-Type: text/plain; charset="UTF-8" An experimental draft isn't the best place for a deployment guide. an operational document that discusses deployment among other things is a different story On Fri, Jul 19, 2019 at 11:13 PM Scott Kitterman wrote: > On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote: > .... > > > > I'm also concerned > > > > that a wildcard null MX record at the org level would end up having > all > > > > subdomains "exist", but the policy that should be applied would be > the > > > > > > more > > > > > > > restrictive "np" policy, not the (possibly) more permissive "sp" > policy. > > > > > > I think this is one of those "you must be this tall to ride on this > ride" > > > situations. DNS comes equipped with multiple footguns and you have to > > > know a > > > bit about what you're doing to make sure you get the effects you're > after. > > > > Perhaps a reminder in the text related to "np" that wildcards may cause > > undesired results and leave it as an exercise for the implementor to > learn > > from that warning. > > It seems like either too much or not enough. This at least slightly > concerns > me because I don't want to warn about the implication of one DNS feature > without being comprehensive. DMARC deployment in any non-trivial > organization > is an inter-disciplinary task, even more so PSD DMARC. I don't think we > want > to take on being a deployment guide, so I'd leave it out. > > Let's see what others think. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000005cca77058e144502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An experimental draft isn't the best place for a deplo= yment guide.=C2=A0

an operational document that discusse= s deployment among other things is a different story

On Fri, Jul 19, 2= 019 at 11:13 PM Scott Kitterman <sklist@kitterman.com> wrote:
On Friday, J= uly 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote:
....
> > > I'm also concerned
> > > that a wildcard null MX record at the org level would end up= having all
> > > subdomains "exist", but the policy that should be = applied would be the
> >
> > more
> >
> > > restrictive "np" policy, not the (possibly) more p= ermissive "sp" policy.
> >
> > I think this is one of those "you must be this tall to ride = on this ride"
> > situations.=C2=A0 DNS comes equipped with multiple footguns and y= ou have to
> > know a
> > bit about what you're doing to make sure you get the effects = you're after.
>
> Perhaps a reminder in the text related to "np" that wildcard= s may cause
> undesired results and leave it as an exercise for the implementor to l= earn
> from that warning.

It seems like either too much or not enough.=C2=A0 This at least slightly c= oncerns
me because I don't want to warn about the implication of one DNS featur= e
without being comprehensive.=C2=A0 DMARC deployment in any non-trivial orga= nization
is an inter-disciplinary task, even more so PSD DMARC.=C2=A0 I don't th= ink we want
to take on being a deployment guide, so I'd leave it out.

Let's see what others think.

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000005cca77058e144502-- From nobody Fri Jul 19 20:23:07 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 2CD69120044 for ; Fri, 19 Jul 2019 20:23:06 -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=txfzc72L; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Nyx2vS7Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb3taMfPmalB for ; Fri, 19 Jul 2019 20:23:05 -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 EBA4312004C for ; Fri, 19 Jul 2019 20:23:04 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 0E4C3F80499 for ; Fri, 19 Jul 2019 23:22:34 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563592953; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=qIA5yyZLU8b1WhOY/J9F1N2Q9T4TojT4m32sPa6bYcE=; b=txfzc72LKWbHLd5dy8H5Pbdmcn8NWAOa8huS/OC2mbvVlfre/6vnKiBT ZqVBUTAWwCXzizdMXdN5crOPnsINAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563592953; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=qIA5yyZLU8b1WhOY/J9F1N2Q9T4TojT4m32sPa6bYcE=; b=Nyx2vS7QoFEUQpRZ8EcV+r0T9Qn65ALznv4joJqD8WF1SpJ/f4+syIR5 8N9jzIXyZdrfkYF9vYHRnqzcdj08UTnCrqN4z0AZSBBuBYwIFlYQJb8bZF rIpSXClY5swIO/8nRdG1YRIa9qXZDljlpUDyCPDyX2PKesJ4ENc5Qe1mzY Tb/EhmSYtXL+ApWuJlBaBKrG/VOCr7+qn8eRDU9AkK2G3f7j2DKqe1Ctp6 +R6pxG9Ivvt6ggFacaTRpDyXScO0mey9gzvypaaIJIN+tGQYLX0aaw9ydg mPB8dKxi8SknclgW//ZiMac3OHWHjyFmR+cybkpPQYqOz+tgE3om/g== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 98080F80042 for ; Fri, 19 Jul 2019 23:22:33 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Fri, 19 Jul 2019 23:22:32 -0400 Message-ID: <3922903.tbmhPv1YJC@l5580> In-Reply-To: <553D43C8D961C14BB27C614AC48FC0311CAB37BC@UMECHPA7D.easf.csd.disa.mil> References: <553D43C8D961C14BB27C614AC48FC0311CAB37BC@UMECHPA7D.easf.csd.disa.mil> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:23:06 -0000 On Wednesday, July 17, 2019 10:01:01 AM EDT Chudow, Eric B CIV NSA DSAW (US= A)=20 wrote: =2E.. > For the current wording, I think the =E2=80=9Cif not=E2=80=9D is unclear = in the =E2=80=9CIf absent, > the policy specified by the "sp" (if present) and then the "p" tag, if no= t, > MUST be applied for non-existent subdomains.=E2=80=9D Does the =E2=80=9C= if not=E2=80=9D mean if > the sp tag is not present? If so, then I think it should be in parenthes= es > to match the =E2=80=9C(if present)=E2=80=9D and probably could be a littl= e clearer by > saying =E2=80=9C(if the =E2=80=9Csp=E2=80=9D tag is not present)=E2=80=9D. =2E.. Thanks, I'm going to post an update shortly to the proposed 'np' section that=20 (hopefully) addresses this concern. Scott K From nobody Fri Jul 19 20:32:05 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 070BD12004C for ; Fri, 19 Jul 2019 20:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=QEhKvTaY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dnztQExZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyrHId5vIHjr for ; Fri, 19 Jul 2019 20:32:02 -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 6FDD6120044 for ; Fri, 19 Jul 2019 20:32:02 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 77A29F80499 for ; Fri, 19 Jul 2019 23:32:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563593521; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Io0q09er8Xgq4c/QEWgkcNstP9zpXPRYefzNzs3HJnI=; b=QEhKvTaYG6QGgVve/NbM1cfzRAV7VM9A8nsEZrGdJMhjP987hF549dHB 1iMPvZpQ7ibDm6bQ41ry3veSEuq7AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563593521; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Io0q09er8Xgq4c/QEWgkcNstP9zpXPRYefzNzs3HJnI=; b=dnztQExZhzwAZ0wpX19WJX2G9u0dERGwjLwFGAGYDAPuVleZePq5mJAU BefWXCug1Lhi/TDPtH7N0jC6xf2/8Y/jhP9cgLX5U5xw7vtOdDaTXC5Dfn O7vWuz25TtYWhBm5qJHJmyRjXtfkI/lHcJeCd4h1CUjvLWDsNYLgjOdmvC DX+rYGrIMrPEyupYDVqCWPM53ijgUs0Gh/JhswxxBdIBa/rA7wnz7muKMU 6PXgDv6nWDzCFhvyrA8rzvM7tClkTRXtHlSJBqWGvBMouK35WxVbQRnZ1E Hq0RbUm19PudnV907BnGsOojxp2TTuWsEcSouwP5d3vjMTHDzND//w== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 19893F80042 for ; Fri, 19 Jul 2019 23:32:01 -0400 (EDT) From: Scott Kitterman To: "dmarc@ietf.org" Date: Fri, 19 Jul 2019 23:32:00 -0400 Message-ID: <1843917.iXBqJGTaWb@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:32:04 -0000 On Friday, July 19, 2019 11:33:38 AM EDT Kurt Andersen (b) wrote: > On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote: > > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman > > > > wrote: > >> If we want to take another run at this and put it in more standard DNS > >> terminology, then maybe: > >> > >> .... a domain for which there is an NXDOMAIN or NODATA response for A, > >> AAAA, > >> and MX records. > >> > >> I think that cures John's concern with my last proposal and addresses > >> yours as > >> well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are > >> correctly followed). > > > > Yes - I think that will fix my concerns (and John's too). > > Thinking about this from a reporting POV, where would a receiver categorize > messages which ended up with SERVFAIL during the process of DMARC (regular > or PSD)? Would "sp" handling or "np" handling be invoked for SERVFAIL (such > as a broken DNSSEC implementation)? RFC 7489 says: > Handling of DNS errors when querying for the DMARC policy record is > left to the discretion of the Mail Receiver. In every case where it discusses DNS errors, it leaves it to the receiver to decide. I think it's out of scope for us to do differently. Scott K From nobody Fri Jul 19 20:47: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 6491412004C for ; Fri, 19 Jul 2019 20:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, T_HTML_ATTACH=0.01, 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=keu/+ZKh; dkim=pass (2048-bit key) header.d=kitterman.com header.b=YZewurHi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shtnyxt03HSg for ; Fri, 19 Jul 2019 20:47:12 -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 31F43120044 for ; Fri, 19 Jul 2019 20:47:12 -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 25E0BF80499 for ; Fri, 19 Jul 2019 23:47:11 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563594431; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=89lJWGDz7P6KEyTZOJEDZ4bL5zsAdJGHJQhtTTuwgRM=; b=keu/+ZKhaU6KHvgafDylW8vJJxQfrv/9QePTXq89XJqSe0qFueE3PCaC fqi/cG9i11Ec9CQPZre1hNv7HuN/CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563594431; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding : from; bh=89lJWGDz7P6KEyTZOJEDZ4bL5zsAdJGHJQhtTTuwgRM=; b=YZewurHiHg+eGByxFSHonb+HDv254q4sDiaLHeH1KTOdpKLwLG9+nxkR teFWwRMJ3j5WF7MPfeGVV3adk46uO1Yp7NFUguHu9BpKYfumy4H25Eodjx T7OCJsnjDZDwZhTphJLmPl/QYJhb/9Qb80s0UAKx32EAbnL3lHjhXBn2bf C1m9i1evrM6jEraJuF9+OBSS9SXDZlsEbljAp7QLKpphL7Sx/g0XxBBIGz z+3bMXVPEzCtB6NGW3p/ySqxyqaDzlLg/uEDwA0Yfpy28KVc+8m9sA9Q4+ P+mAYPZHexzGD6jK9bCcfn4W34zwKWpzidEc5ivQjDYDp6DJqmQuBw== Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 2CE81F80042 for ; Fri, 19 Jul 2019 23:47:10 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 19 Jul 2019 23:47:08 -0400 Message-ID: <2329855.3qHDJPs8v9@l5580> In-Reply-To: <7295017.bxVsTnSgkA@l5580> References: <4789054.Ip9ilXyiH0@l5580> <7295017.bxVsTnSgkA@l5580> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1878466.arYzq08ld2" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 03:47:14 -0000 This is a multi-part message in MIME format. --nextPart1878466.arYzq08ld2 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, July 17, 2019 1:07:05 AM EDT Scott Kitterman wrote: > On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote: > > On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote: > > > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote: > > > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman > > > > > > > > > > > > wrote: > > > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > > > > > > 3. If an np= tag is needed to allow PSD functioning for only > > > > > > NXDOMAINs > > > > > > > > > > The limited feedback during WGLC has been favorable to this. > > > > > > > > > > This will require a rather larger change to the document than the > > > > > other > > > > > issues, but they are manageable and I believe I have most of the > > > > > relevant > > > > > text > > > > > from earlier revisions. > > > > > > > > > > I think we should include this. > > > > > > > > I am much more concerned with adding another tag that can only be used > > > > in > > > > a > > > > PSD-DMARC record. I would be much more open to make a "normative" > > > > change > > > > to > > > > the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC > > > > record, than to make this a special case for PSD-DMARC records. > > > > > > I agree. My intent is to add the tag to be used experimentally for any > > > DMARC record. Part of the experiment is to see if it's useful beyond > > > PSD. > > > > Attached is my proposed text to add the np tag. Based on the discussion > > to > > date, I assume I'll be asked to add something like this after last call is > > complete, so please let me know how to make it better. > > > > Scott K > > Updated rfcdiff attached. The only change other than typos is to add > mention of 'np' to Appendix A. Updated again. I believe this addresses all the 'np' related last call discussion. Shortly I'll move on to what I think the group wanted on the other topics. Scott K Note: I'm not planning on publishing diffs on every topic. I only did it for 'np' because it required me to write more new text that no one else had reviewed. --nextPart1878466.arYzq08ld2 Content-Disposition: attachment; filename="draft-ietf-dmarc-psd-05-from-4.diff.html" Content-Transfer-Encoding: base64 Content-Type: application/xhtml+xml; name="draft-ietf-dmarc-psd-05-from-4.diff.html" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQxOiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogTGludXggbDU1ODAgNC4xOS4wLTUtYW1kNjQgIzEgU01Q IERlYmlhbiA0LjE5LjM3LTMgKDIwMTktMDUtMTUpIHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0t IFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjIuMSwgQVBJOiAyLjAgKEdOVSBN UEZSIDQuMC4yLCBHTlUgTVAgNi4xLjIpIC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNyL2Jpbi9k aWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAzLjcgLS0+IAo8IS0tIFVzaW5nIHdkaWZmOiAvdXNy L2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjIgLS0+IAo8aHRtbD4gCjxoZWFkPiAK ICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5 cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1kbWFy Yy1wc2QtMDQudHh0IC0gZHJhZnQtaWV0Zi1kbWFyYy1wc2QtMDUudHh0PC90aXRsZT4gCiAgPHN0 eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2lu LXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3Bh Y2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9u dC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAg IC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFt aWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0g CiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6 ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5s aW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAu N2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sg YmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5y YmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsgfSAKICA8L3N0eWxlPiAKPC9o ZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPiAKICA8dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+Jm5ic3A7ZHJh ZnQtaWV0Zi1kbWFyYy1wc2QtMDQudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwO2Ry YWZ0LWlldGYtZG1hcmMtcHNkLTA1LnR4dCZuYnNwOzwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gS2l0dGVybWFuPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZlRMRCBSZWdpc3RyeSBTZXJ2aWNlczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0i ZGlmZjAwMDEiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5JbnRlbmRlZCBzdGF0dXM6IEV4cGVyaW1l bnRhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5N YXkgMjcsPC9zcGFuPiAyMDE5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkludGVu ZGVkIHN0YXR1czogRXhwZXJpbWVudGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNw YW4gY2xhc3M9Imluc2VydCI+SnVseSAxOSw8L3NwYW4+IDIwMTk8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFz cz0iZGVsZXRlIj5Ob3ZlbWJlciAyOCwgMjAxOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+SmFudWFyeSAyMCwgMjAy MDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkRNQVJDIChEb21haW4tYmFzZWQg TWVzc2FnZSBBdXRoZW50aWNhdGlvbiwgUmVwb3J0aW5nLCBhbmQgQ29uZm9ybWFuY2UpPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+RE1BUkMgKERvbWFpbi1iYXNlZCBNZXNzYWdlIEF1 dGhlbnRpY2F0aW9uLCBSZXBvcnRpbmcsIGFuZCBDb25mb3JtYW5jZSk8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgRXh0 ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMgU3VmZml4IERvbWFpbnMpPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgRXh0ZW5zaW9uIEZvciBQU0RzIChQdWJsaWMg U3VmZml4IERvbWFpbnMpPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZG1hcmMtcHNkLTA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRtYXJjLXBzZC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERNQVJDIChEb21haW4tYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiwg UmVwb3J0aW5nLCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBETUFSQyAo RG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbmZv cm1hbmNlKSBpcyBhIHNjYWxhYmxlIG1lY2hhbmlzbSBieSB3aGljaCBhIG1haWwtb3JpZ2luYXRp bmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb25mb3JtYW5jZSkgaXMgYSBz Y2FsYWJsZSBtZWNoYW5pc20gYnkgd2hpY2ggYSBtYWlsLW9yaWdpbmF0aW5nPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9yZ2FuaXphdGlv biBjYW4gZXhwcmVzcyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yZ2FuaXphdGlvbiBjYW4gZXhwcmVz cyBkb21haW4tbGV2ZWwgcG9saWNpZXMgYW5kIHByZWZlcmVuY2VzIGZvcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtZXNzYWdlIHZhbGlk YXRpb24sIGRpc3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtZXNzYWdlIHZhbGlkYXRpb24sIGRp c3Bvc2l0aW9uLCBhbmQgcmVwb3J0aW5nLCB0aGF0IGEgbWFpbC1yZWNlaXZpbmc8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3JnYW5pemF0 aW9uIGNhbiB1c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2Fu IGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uIGNhbiB1 c2UgdG8gaW1wcm92ZSBtYWlsIGhhbmRsaW5nLiAgRE1BUkMgcG9saWNpZXMgY2FuIGJlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFwcGxp ZWQgYXQgdGhlIGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5z IGF0IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFwcGxpZWQgYXQgdGhl IGluZGl2aWR1YWwgZG9tYWluIGxldmVsIG9yIGZvciBhIHNldCBvZiBkb21haW5zIGF0IHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBv cmdhbml6YXRpb25hbCBsZXZlbC4gIFRoZSBkZXNpZ24gb2YgRE1BUkMgcHJlY2x1ZGVzIGdyb3Vw aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JnYW5pemF0aW9uYWwgbGV2 ZWwuICBUaGUgZGVzaWduIG9mIERNQVJDIHByZWNsdWRlcyBncm91cGluZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9 ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMiIgLz48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMSwgbGluZSA0MzwvZW0+PC90aD48dGg+IDwv dGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGVtPiBwYWdlIDEsIGxpbmUgNDM8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry aWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDMiIC8+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJkZWxl dGUiPk5vdmVtYmVyIDI4LCAyMDE5PC9zcGFuPi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5KYW51YXJ5IDIwLCAyMDIwPC9zcGFuPi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5 cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmlnaHQgKGMp IDIwMTkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMTkgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFs bCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9j dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0 cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50 LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2Ny aWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNl IHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92 aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+VGFibGUgb2YgQ29udGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJs ZSBvZiBDb250ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDA0IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgMS4gIEludHJvZHVjdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFz cz0iZGVsZXRlIj4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDIuICBUZXJtaW5vbG9neSBh bmQgRGVmaW5pdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDIuICBUZXJtaW5vbG9neSBhbmQgRGVmaW5p dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIENvbnZl bnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIENvbnZlbnRpb25zIFVz ZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5h bWU9ImRpZmYwMDA1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAyLjIuICBQdWJsaWMgU3Vm Zml4IERvbWFpbiAoUFNEKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBj bGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgIDIuMi4gIFB1YmxpYyBTdWZmaXggRG9tYWluIChQU0QpICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMi4zLiAgTG9uZ2Vz dCBQU0QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4zLiAgTG9uZ2VzdCBQU0QgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuNC4gIFB1 YmxpYyBTdWZmaXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuNC4gIFB1YmxpYyBTdWZm aXggT3BlcmF0b3IgKFBTTykgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjUu ICBQU08gQ29udHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjUuICBQU08gQ29u dHJvbGxlZCBEb21haW4gTmFtZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Mi42LiAgTm9uLWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi42LiAgTm9u LWV4aXN0ZW50IERvbWFpbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAzLiAgUFNEIERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgUFNE IERNQVJDIFVwZGF0ZXMgdG8gRE1BUkMgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAzLjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAz LjEuICBHZW5lcmFsIFVwZGF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA1PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgMy4yLiAgU2VjdGlvbiA2LjEgRE1BUkMgUG9saWN5IFJlY29yZCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjIuICBTZWN0aW9uIDYuMSBETUFSQyBQb2xpY3kgUmVj b3JkIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgMy4zLiAgU2VjdGlvbiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAzLjMuICBTZWN0aW9uIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjYuMyBHZW5lcmFsIFJlY29yZCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgMy40Ljwvc3Bhbj4gIFNlY3Rpb24g Ni42LjMuICBQb2xpY3kgRGlzY292ZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgMy40LiAgU2VjdGlvbjwvc3Bhbj4gNi41LiAgRG9t YWluIE93bmVyIEFjdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAzLjUuPC9zcGFuPiAgU2Vj dGlvbiA3LiAgRE1BUkMgRmVlZGJhY2sgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAzLjUuPC9zcGFuPiAgU2VjdGlvbiA2LjYu My4gIFBvbGljeSBEaXNjb3ZlcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgPHNwYW4gY2xh c3M9Imluc2VydCI+Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA0LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgICAgMy42Ljwvc3Bhbj4gIFNlY3Rpb24gNy4gIERNQVJDIEZlZWRiYWNrICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjc8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICA0LjEuICBGZWVkYmFjayBsZWFrYWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj42PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA0LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjc8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDQuMS4gIEZlZWRiYWNrIGxlYWthZ2UgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQi Pjc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgNy4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA2LiAgSUFOQSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNs YXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj44 PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAgIDYuMS4gIFN1YmRvbWFpbiBQb2xpY3kgVGFnICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj44PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA3LiAgUmVm ZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXBwZW5kaXggQS4gIFRoZSBFeHBl cmltZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFz cz0iZGVsZXRlIj45PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAg IDcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXBwZW5kaXggQi4gIERN QVJDIFBTRCBSZWdpc3RyeSBFeGFtcGxlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFu IGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgIDcuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICBCLjEuICBE TUFSQyBQU0QgRE5TIFF1ZXJ5IFNlcnZpY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDxzcGFuIGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBBcHBlbmRpeCBBLiAgVGhlIEV4cGVyaW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTA8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICBC LjIuICBETUFSQyBQdWJsaWMgU3VmZml4IERvbWFpbiAoUFNEKSBSZWdpc3RyeSAuIC4gLiAuIC4g LiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgIEEuMS4gIFBTRCBETUFSQyBQ cml2YWN5IENvbmNlcm4gTWl0aWdhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTA8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgQXBwZW5kaXggQy4gIEltcGxlbWVudGF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgIEEuMi4gIE5vbi1F eGlzdGVudCBTdWJkb21haW4gUG9saWN5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTE8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICBDLjEuICBBdXRoaGVhZGVycyBNb2R1bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBcHBlbmRpeCBCLiAgRE1BUkMgUFNEIFJlZ2lz dHJ5IEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIEIuMS4gIERNQVJDIFBTRCBETlMg UXVlcnkgU2VydmljZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjExPC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIEIuMi4gIERNQVJDIFB1 YmxpYyBTdWZmaXggRG9tYWluIChQU0QpIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g Y2xhc3M9Imluc2VydCI+MTI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIEFwcGVuZGl4IEMuICBJbXBsZW1lbnRhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICBDLjEuICBBdXRoaGVhZGVycyBNb2R1bGUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEz PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBY2tub3dsZWRnZW1l bnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNw YW4gY2xhc3M9Imluc2VydCI+MTM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMzwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBETUFSQyBbUkZDNzQ4OV0gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIHB1Ymxpc2hpbmcgb3Jn YW5pemF0aW9uYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBETUFSQyBbUkZD NzQ4OV0gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIHB1Ymxpc2hpbmcgb3JnYW5pemF0aW9uYWw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg cG9saWN5IGluZm9ybWF0aW9uIHRvIGVtYWlsIHJlY2VpdmVycy4gIERNQVJDIFtSRkM3NDg5XSBh bGxvd3MgcG9saWN5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcG9saWN5IGlu Zm9ybWF0aW9uIHRvIGVtYWlsIHJlY2VpdmVycy4gIERNQVJDIFtSRkM3NDg5XSBhbGxvd3MgcG9s aWN5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRvIGJlIHNwZWNpZmllZCBmb3IgYm90aCBpbmRpdmlkdWFsIGRvbWFpbnMgYW5kIHNldHMg b2YgZG9tYWluczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGJlIHNwZWNp ZmllZCBmb3IgYm90aCBpbmRpdmlkdWFsIGRvbWFpbnMgYW5kIHNldHMgb2YgZG9tYWluczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aXRo aW4gYSBzaW5nbGUgb3JnYW5pemF0aW9uLiAgRm9yIGRvbWFpbnMgYWJvdmUgdGhlIG9yZ2FuaXph dGlvbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2l0aGluIGEgc2luZ2xl IG9yZ2FuaXphdGlvbi4gIEZvciBkb21haW5zIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBsZXZl bCBpbiB0aGUgRE5TIHRyZWUsIHBvbGljeSBjYW4gb25seSBiZSBwdWJsaXNoZWQgZm9yIHRoZSBl eGFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxldmVsIGluIHRoZSBETlMg dHJlZSwgcG9saWN5IGNhbiBvbmx5IGJlIHB1Ymxpc2hlZCBmb3IgdGhlIGV4YWN0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvbWFpbi4g IFRoZXJlIGlzIG5vIG1ldGhvZCBhdmFpbGFibGUgdG8gc3VjaCBkb21haW5zIHRvIGV4cHJlc3M8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb21haW4uICBUaGVyZSBpcyBubyBt ZXRob2QgYXZhaWxhYmxlIHRvIHN1Y2ggZG9tYWlucyB0byBleHByZXNzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxvd2VyIGxldmVsIHBv bGljeSBvciByZWNlaXZlIGZlZWRiYWNrIHJlcG9ydGluZyBmb3Igc2V0cyBvZiBkb21haW5zLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxvd2VyIGxldmVsIHBvbGljeSBvciBy ZWNlaXZlIGZlZWRiYWNrIHJlcG9ydGluZyBmb3Igc2V0cyBvZiBkb21haW5zLjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29s b3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyIgLz48c21hbGw+c2tpcHBp bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMywgbGluZSAzODwvZW0+PC90aD48dGg+ IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDMsIGxpbmUgNDU8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGluIGEgbWFpbCBkZWxpdmVyeSBkZWNpc2lvbiwgYnV0IGlzIG5vdCBnZW5lcmFsbHkg dHJlYXRlZCBhczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluIGEgbWFpbCBk ZWxpdmVyeSBkZWNpc2lvbiwgYnV0IGlzIG5vdCBnZW5lcmFsbHkgdHJlYXRlZCBhczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbml0 aXZlIG9uIGl0cyBvd24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVmaW5p dGl2ZSBvbiBpdHMgb3duLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBtZW1v IHByb3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lvbiB0byBETUFSQyBbUkZDNzQ4OV0gdG8gYWxsb3c8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIG1lbW8gcHJvdmlkZXMgYSBz aW1wbGUgZXh0ZW5zaW9uIHRvIERNQVJDIFtSRkM3NDg5XSB0byBhbGxvdzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRvcnMgb2Yg UHVibGljIFN1ZmZpeCBEb21haW5zIChQU0RzKSB0byBleHByZXNzIHBvbGljeSBmb3I8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvcGVyYXRvcnMgb2YgUHVibGljIFN1ZmZpeCBE b21haW5zIChQU0RzKSB0byBleHByZXNzIHBvbGljeSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZ3JvdXBzIG9mIHN1YmRvbWFpbnMs IGV4dGVuZHMgdGhlIERNQVJDIFtSRkM3NDg5XSBwb2xpY3kgcXVlcnk8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBncm91cHMgb2Ygc3ViZG9tYWlucywgZXh0ZW5kcyB0aGUgRE1B UkMgW1JGQzc0ODldIHBvbGljeSBxdWVyeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBhbmQgcHJv Y2VzcyBzdWNoIGEgcG9saWN5LCBkZXNjcmliZXMgcmVjZWl2ZXI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBmdW5jdGlvbmFsaXR5IHRvIGRldGVjdCBhbmQgcHJvY2VzcyBzdWNo IGEgcG9saWN5LCBkZXNjcmliZXMgcmVjZWl2ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZmVlZGJhY2sgZm9yIHN1Y2ggcG9saWNpZXMs IGFuZCBwcm92aWRlcyBjb250cm9scyB0byBtaXRpZ2F0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGZlZWRiYWNrIGZvciBzdWNoIHBvbGljaWVzLCBhbmQgcHJvdmlkZXMgY29u dHJvbHMgdG8gbWl0aWdhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgcG90ZW50aWFsIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXNzb2Np YXRlZCB3aXRoIHRoaXMgZXh0ZW5zaW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHBvdGVudGlhbCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGlz IGV4dGVuc2lvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDAwNyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIG1lbW8gYWxzbyBwcm92aWRlcyBh IG5ldyBETUFSQyBbUkZDNzQ4OV0gdGFnIHRvIGluZGljYXRlPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZXF1ZXN0ZWQgaGFu ZGxpbmcgcG9saWN5IGZvciBub24tZXhpc3RlbnQgc3ViZG9tbWFpbnMuICBUaGlzIGlzPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBwcm92aWRlZCBzcGVjaWZpY2FsbHkgdG8gc3VwcG9ydCBwaGFzZWQgZGVwbG95bWVudCBvZiBQ U0QgRE1BUkMsIGJ1dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgaXMgZXhwZWN0ZWQgdG8gYmUgdXNlZnVsIG1vcmUgZ2VuZXJh bGx5LiAgVW5kZXNpcmVkIHJlamVjdGlvbiByaXNrczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZm9yIG1haWwgcHVycG9ydGlu ZyB0byBiZSBmcm9tIGRvbWFpbnMgdGhhdCBkbyBub3QgZXhpc3QgYXJlPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzdWJzdGFu dGlhbGx5IGxvd2VyIHRoYW4gZm9yIHRob3NlIHRoYXQgZG8sIHNvIHRoZSBvcGVyYXRpb25hbCBy aXNrPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBvZiByZXF1ZXN0aW5nIGhhcnNoIHBvbGljeSB0cmVhdG1lbnQgKGUuZy4gcmVq ZWN0KSBpcyBsb3dlci48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgQXMgYW4gYWRkaXRpb25hbCBiZW5lZml0LCB0aGUgUFNEIERNQVJDIGV4 dGVuc2lvbiB3aWxsIGNsYXJpZnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBB cyBhbiBhZGRpdGlvbmFsIGJlbmVmaXQsIHRoZSBQU0QgRE1BUkMgZXh0ZW5zaW9uIHdpbGwgY2xh cmlmeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBleGlzdGluZyByZXF1aXJlbWVudHMuICBCYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIG9m IERNQVJDIFtSRkM3NDg5XSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleGlz dGluZyByZXF1aXJlbWVudHMuICBCYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIG9mIERNQVJDIFtS RkM3NDg5XSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgRE1BUkMgc2hvdWxkIGZ1bmN0aW9uIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBs ZXZlbCBmb3IgZXhhY3QgZG9tYWluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg RE1BUkMgc2hvdWxkIGZ1bmN0aW9uIGFib3ZlIHRoZSBvcmdhbml6YXRpb25hbCBsZXZlbCBmb3Ig ZXhhY3QgZG9tYWluPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG1hdGNoZXMgKGkuZS4gaWYgYSBETUFSQyByZWNvcmQgd2VyZSBwdWJsaXNo ZWQgZm9yICdleGFtcGxlJywgdGhlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG1hdGNoZXMgKGkuZS4gaWYgYSBETUFSQyByZWNvcmQgd2VyZSBwdWJsaXNoZWQgZm9yICdleGFt cGxlJywgdGhlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBtYWlsIGZyb20gZXhhbXBsZUBleGFtcGxlIHNob3VsZCBiZSBzdWJqZWN0IHRv IERNQVJDIHByb2Nlc3NpbmcpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1h aWwgZnJvbSBleGFtcGxlQGV4YW1wbGUgc2hvdWxkIGJlIHN1YmplY3QgdG8gRE1BUkMgcHJvY2Vz c2luZykuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFRlc3RpbmcgaGFkIHJldmVhbGVkIHRoYXQgdGhpcyBpcyBub3QgY29uc2lzdGVudGx5 IGFwcGxpZWQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUZXN0aW5nIGhh ZCByZXZlYWxlZCB0aGF0IHRoaXMgaXMgbm90IGNvbnNpc3RlbnRseSBhcHBsaWVkIGluPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRpZmZl cmVudCBpbXBsZW1lbnRhdGlvbnMuICBQU0QgRE1BUkMgd2lsbCBoZWxwIGNsYXJpZnkgdGhhdCBE TUFSQyBpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRpZmZlcmVudCBpbXBs ZW1lbnRhdGlvbnMuICBQU0QgRE1BUkMgd2lsbCBoZWxwIGNsYXJpZnkgdGhhdCBETUFSQyBpczwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBu b3QgbGltaXRlZCB0byBvcmdhbml6YXRpb25hbCBkb21haW5zIGFuZCB0aGVpciBzdWItZG9tYWlu cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub3QgbGltaXRlZCB0byBvcmdh bml6YXRpb25hbCBkb21haW5zIGFuZCB0aGVpciBzdWItZG9tYWlucy48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRoZXJlIGFyZSB0d28gdHlwZXMgb2YgUHVibGljIFN1ZmZpeCBPcGVy YXRvcnMgKFBTT3MpIGZvciB3aGljaCB0aGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgVGhlcmUgYXJlIHR3byB0eXBlcyBvZiBQdWJsaWMgU3VmZml4IE9wZXJhdG9ycyAoUFNP cykgZm9yIHdoaWNoIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5h bWU9InBhcnQtbDQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw YWdlIDUsIGxpbmUgMjQ8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI0IiAv PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA1LCBsaW5lIDM2 PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4yLjUuICBQU08gQ29udHJvbGxlZCBEb21h aW4gTmFtZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLjUuICBQU08gQ29udHJv bGxlZCBEb21haW4gTmFtZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBTTyBDb250 cm9sbGVkIERvbWFpbiBOYW1lcyBhcmUgbmFtZXMgaW4gdGhlIEROUyB0aGF0IGFyZSBtYW5hZ2Vk IGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFNPIENvbnRyb2xsZWQgRG9t YWluIE5hbWVzIGFyZSBuYW1lcyBpbiB0aGUgRE5TIHRoYXQgYXJlIG1hbmFnZWQgYnk8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYSBQU08g YW5kIGFyZSBub3QgYXZhaWxhYmxlIGZvciB1c2UgYXMgT3JnYW5pemF0aW9uYWwgRG9tYWlucyAo dGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYSBQU08gYW5kIGFyZSBub3Qg YXZhaWxhYmxlIGZvciB1c2UgYXMgT3JnYW5pemF0aW9uYWwgRG9tYWlucyAodGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRlcm0gT3Jn YW5pemF0aW9uYWwgRG9tYWlucyBpcyBkZWZpbmVkIGluIERNQVJDIFtSRkM3NDg5XTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRlcm0gT3JnYW5pemF0aW9uYWwgRG9tYWlucyBp cyBkZWZpbmVkIGluIERNQVJDIFtSRkM3NDg5XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTZWN0aW9uIDMuMikuICBEZXBlbmRpbmcgb24g UFNEIHBvbGljeSwgdGhlc2Ugd2lsbCBoYXZlIG9uZSAoZS5nLiw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBTZWN0aW9uIDMuMikuICBEZXBlbmRpbmcgb24gUFNEIHBvbGljeSwg dGhlc2Ugd2lsbCBoYXZlIG9uZSAoZS5nLiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIi5jb20iKSBvciBtb3JlIChlLmcuLCAiLmNvLnVr IikgbmFtZSBjb21wb25lbnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICIu Y29tIikgb3IgbW9yZSAoZS5nLiwgIi5jby51ayIpIG5hbWUgY29tcG9uZW50cy48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjIuNi4gIE5vbi1leGlzdGVudCBEb21haW5zPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi42LiAgTm9uLWV4aXN0ZW50IERvbWFpbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOCIgLz48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIEZvciBETUFSQyBbUkZDNzQ4OV0gcHVycG9zZXMsIGEgbm9uLWV4aXN0ZW50 IGRvbWFpbiBpcyBhIGRvbWFpbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5uYW1lPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBGb3IgRE1BUkMgW1JGQzc0ODldIHB1cnBv c2VzLCBhIG5vbi1leGlzdGVudCBkb21haW4gaXMgYSBkb21haW4gPHNwYW4gY2xhc3M9Imluc2Vy dCI+Zm9yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHRoYXQgcHVibGlzaGVzIG5vbmUg b2Y8L3NwYW4+IEEsIEFBQUEsIDxzcGFuIGNsYXNzPSJkZWxldGUiPm9yPC9zcGFuPiBNWCA8c3Bh biBjbGFzcz0iZGVsZXRlIj5yZWNvcmRzIHRoYXQgdGhlIHJlY2VpdmVyIGlzPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB3aGlj aCB0aGVyZSBpcyBhbiBOWERPTUFJTiBvciBOT0RBVEEgcmVzcG9uc2UgZm9yPC9zcGFuPiBBLCBB QUFBLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbmQ8L3NwYW4+IE1YPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0 ZSI+ICAgd2lsbGluZyB0byBhY2NlcHQuPC9zcGFuPiAgVGhpcyBpcyBhIGJyb2FkZXIgZGVmaW5p dGlvbiB0aGFuIHRoYXQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNw YW4gY2xhc3M9Imluc2VydCI+cmVjb3Jkcy48L3NwYW4+ICBUaGlzIGlzIGEgYnJvYWRlciBkZWZp bml0aW9uIHRoYW4gdGhhdCBpbiBOWERPTUFJTjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIE5YRE9NQUlOIFtSRkM4MDIwXS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgW1JGQzgwMjBdLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+My4gIFBTRCBETUFSQyBVcGRhdGVzIHRvIERNQVJDIFJlcXVpcmVtZW50czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuICBQU0QgRE1BUkMgVXBkYXRlcyB0byBE TUFSQyBSZXF1aXJlbWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9j dW1lbnQgdXBkYXRlcyBETUFSQyBbUkZDNzQ4OV0gYXMgZm9sbG93czo8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgRE1BUkMgW1JGQzc0ODld IGFzIGZvbGxvd3M6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjEuICBHZW5lcmFsIFVw ZGF0ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLjEuICBHZW5lcmFsIFVwZGF0 ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlZmVyZW5jZXMgdG8gIkRvbWFpbiBP d25lcnMiIGFsc28gYXBwbHkgdG8gUFNPcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBSZWZlcmVuY2VzIHRvICJEb21haW4gT3duZXJzIiBhbHNvIGFwcGx5IHRvIFBTT3MuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4zLjIuICBTZWN0aW9uIDYuMSBETUFSQyBQb2xpY3kg UmVjb3JkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+My4yLiAgU2VjdGlvbiA2LjEg RE1BUkMgUG9saWN5IFJlY29yZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEIERN QVJDIHJlY29yZHMgYXJlIHB1Ymxpc2hlZCBhcyBhIHN1YmRvbWFpbiBvZiB0aGUgUFNELiAgRm9y IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTRCBETUFSQyByZWNvcmRz IGFyZSBwdWJsaXNoZWQgYXMgYSBzdWJkb21haW4gb2YgdGhlIFBTRC4gIEZvciB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEICIu ZXhhbXBsZSIsIHRoZSBQU08gd291bGQgcG9zdCBETUFSQyBwb2xpY3kgaW4gYSBUWFQgcmVjb3Jk IGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUFNEICIuZXhhbXBsZSIsIHRo ZSBQU08gd291bGQgcG9zdCBETUFSQyBwb2xpY3kgaW4gYSBUWFQgcmVjb3JkIGF0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJfZG1hcmMu ZXhhbXBsZSIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIl9kbWFyYy5leGFt cGxlIi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAw OSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjMuMy4gIFNlY3Rpb24gNi41LiAgRG9tYWluIE93bmVy IEFjdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+My4zLiAgU2VjdGlvbiA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij42LjMgR2VuZXJhbCBSZWNvcmQgRm9ybWF0PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IEEgbmV3IHRhZyBpcyBhZGRlZCBhZnRlciBmbzo8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbnA6ICBSZXF1ZXN0ZWQg TWFpbCBSZWNlaXZlciBwb2xpY3kgZm9yIG5vbi1leGlzdGVudCBzdWJkb21haW5zPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAg ICAocGxhaW4tdGV4dDsgT1BUSU9OQUwpLiAgSW5kaWNhdGVzIHRoZSBwb2xpY3kgdG8gYmUgZW5h Y3RlZCBieSB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgIFJlY2VpdmVyIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBEb21h aW4gT3duZXIuICBJdCBhcHBsaWVzIG9ubHkgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIG5vbi1leGlzdGVudCBzdWJk b21haW5zIG9mIHRoZSBkb21haW4gcXVlcmllZCBhbmQgbm90IHRvIGVpdGhlcjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg ZXhpc3Rpbmcgc3ViZG9tYWlucyBvciB0aGUgZG9tYWluIGl0c2VsZi4gIEl0cyBzeW50YXggaXMg aWRlbnRpY2FsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICB0byB0aGF0IG9mIHRoZSAicCIgdGFnIGRlZmluZWQgYmVsb3cu ICBJZiB0aGUgJ25wJyB0YWcgaXMgYWJzZW50LDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgdGhlIHBvbGljeSBzcGVjaWZp ZWQgYnkgdGhlICJzcCIgdGFnIChpZiB0aGUgJ3NwJyB0YWcgaXMgcHJlc2VudCk8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAg IG9yIHRoZSBwb2xpY3kgc3BlY2lmaWVkIGJ5IHRoZSAicCIgdGFnLCBpZiB0aGUgJ3NwJyB0YWcg aXMgbm90PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICBwcmVzZW50LCBNVVNUIGJlIGFwcGxpZWQgZm9yIG5vbi1leGlzdGVu dCBzdWJkb21haW5zLiAgTm90ZSB0aGF0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAibnAiIHdpbGwgYmUgaWdub3JlZCBm b3IgRE1BUkMgcmVjb3JkcyBwdWJsaXNoZWQgb24gc3ViZG9tYWlucyBvZjwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgT3Jn YW5pemF0aW9uYWwgRG9tYWlucyBhbmQgUFNEcyBkdWUgdG8gdGhlIGVmZmVjdCBvZiB0aGUgRE1B UkM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgICAgIHBvbGljeSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBETUFS QyBbUkZDNzQ4OV08L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgICAgIFNlY3Rpb24gNi42LjMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRoZSBmb2xs b3dpbmcgdGFnIGRlZmluaXRpb25zIGZyb20gRE1BUkMgW1JGQzc0ODldIGFyZSB1cGRhdGVkOjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBwOiBUaGUgc2VudGVuY2UgJ1BvbGljeSBhcHBsaWVzIHRvIHRoZSBkb21haW4g cXVlcmllZCBhbmQgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHN1YmRvbWFpbnMsIHVubGVzcyBzdWJkb21haW4gcG9s aWN5IGlzIGV4cGxpY2l0bHkgZGVzY3JpYmVkIHVzaW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICB0aGUgInNwIiB0YWcn IGlzIHVwZGF0ZWQgdG8gcmVhZCAnUG9saWN5IGFwcGxpZXMgdG8gdGhlIGRvbWFpbjwvc3Bhbj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg ICAgcXVlcmllZCBhbmQgdG8gc3ViZG9tYWlucywgdW5sZXNzIHN1YmRvbWFpbiBwb2xpY3kgaXMg ZXhwbGljaXRseTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgICAgZGVzY3JpYmVkIHVzaW5nIHRoZSAic3AiIG9yICJucCIgdGFn cy4nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIHNwOiAgVGhlIHNlbnRlbmNlICdJZiBhYnNlbnQsIHRoZSBwb2xpY3kg c3BlY2lmaWVkIGJ5IHRoZSAicCIgdGFnPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBNVVNUIGJlIGFwcGxpZWQgZm9yIHN1 YmRvbWFpbnMnIGlzIHVwZGF0ZWQgdG8gcmVhZCAnSWYgYm90aCB0aGU8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICdzcCcg dGFnIGlzIGFic2VudCBhbmQgdGhlICducCcgdGFnIGlzIGVpdGhlciBhYnNlbnQgb3Igbm90PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICAgICBhcHBsaWNhYmxlLCB0aGUgcG9saWN5IHNwZWNpZmllZCBieSB0aGUgInAiIHRhZyBN VVNUIGJlIGFwcGxpZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIGZvciBzdWJkb21haW5zLjwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zLjQuICBT ZWN0aW9uPC9zcGFuPiA2LjUuICBEb21haW4gT3duZXIgQWN0aW9uczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgSW4gYWRkaXRpb24gdG8gdGhlIERNQVJDIFtSRkM3NDg5XSBkb21haW4g b3duZXIgYWN0aW9ucywgUFNPcyB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgSW4gYWRkaXRpb24gdG8gdGhlIERNQVJDIFtSRkM3NDg5XSBkb21haW4gb3duZXIgYWN0aW9u cywgUFNPcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHJlcXVpcmUgdXNlIG9mIERNQVJDIG91Z2h0IHRvIG1ha2UgdGhhdCBpbmZv cm1hdGlvbiBhdmFpbGFibGUgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBy ZXF1aXJlIHVzZSBvZiBETUFSQyBvdWdodCB0byBtYWtlIHRoYXQgaW5mb3JtYXRpb24gYXZhaWxh YmxlIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHJlY2VpdmVycy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZWNl aXZlcnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MTAiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4zLjxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+ LiAgU2VjdGlvbiA2LjYuMy4gIFBvbGljeSBEaXNjb3Zlcnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+My48c3BhbiBjbGFzcz0iaW5zZXJ0Ij41PC9zcGFuPi4gIFNlY3Rpb24gNi42 LjMuICBQb2xpY3kgRGlzY292ZXJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBIG5l dyBzdGVwIGJldHdlZW4gc3RlcCAzIGFuZCA0IGlzIGFkZGVkOjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEEgbmV3IHN0ZXAgYmV0d2VlbiBzdGVwIDMgYW5kIDQgaXMgYWRkZWQ6 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzQS4gIElmIHRoZSBzZXQgaXMgbm93IGVt cHR5IGFuZCB0aGUgbG9uZ2VzdCBQU0QgKFNlY3Rpb24gMi4zKSBvZiB0aGU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzQS4gIElmIHRoZSBzZXQgaXMgbm93IGVtcHR5IGFuZCB0 aGUgbG9uZ2VzdCBQU0QgKFNlY3Rpb24gMi4zKSBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgT3JnYW5pemF0aW9uYWwgRG9t YWluIGlzIG9uZSB0aGF0IHRoZSByZWNlaXZlciBoYXMgZGV0ZXJtaW5lZCBpczwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbiBpcyBvbmUg dGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGRldGVybWluZWQgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgYWNjZXB0YWJsZSBmb3IgUFNE IERNQVJDLCB0aGUgTWFpbCBSZWNlaXZlciBNVVNUIHF1ZXJ5IHRoZSBETlMgZm9yPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYWNjZXB0YWJsZSBmb3IgUFNEIERNQVJDLCB0 aGUgTWFpbCBSZWNlaXZlciBNVVNUIHF1ZXJ5IHRoZSBETlMgZm9yPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGEgRE1BUkMgVFhUIHJl Y29yZCBhdCB0aGUgRE5TIGRvbWFpbiBtYXRjaGluZyB0aGUgbG9uZ2VzdCBQU0Q8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBhIERNQVJDIFRYVCByZWNvcmQgYXQgdGhlIERO UyBkb21haW4gbWF0Y2hpbmcgdGhlIGxvbmdlc3QgUFNEPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIChTZWN0aW9uIDIuMykgaW4gcGxh Y2Ugb2YgdGhlIFJGQzUzMjIuRnJvbSBkb21haW4gaW4gdGhlIG1lc3NhZ2U8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAoU2VjdGlvbiAyLjMpIGluIHBsYWNlIG9mIHRoZSBS RkM1MzIyLkZyb20gZG9tYWluIGluIHRoZSBtZXNzYWdlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIChpZiBkaWZmZXJlbnQpLiAgQSBw b3NzaWJseSBlbXB0eSBzZXQgb2YgcmVjb3JkcyBpcyByZXR1cm5lZC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAoaWYgZGlmZmVyZW50KS4gIEEgcG9zc2libHkgZW1wdHkg c2V0IG9mIHJlY29yZHMgaXMgcmV0dXJuZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNSIgLz48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNiwgbGluZSAyOTwv ZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjUiIC8+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDcsIGxpbmUgMjk8L2VtPjwvdGg+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIChTZWN0aW9uIDIuMykuICBUaGUgcmVjZWl2ZXIgd291bGQgY2hl Y2sgdG8gc2VlIGlmIHRoYXQgUFNEIGlzIGxpc3RlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIChTZWN0aW9uIDIuMykuICBUaGUgcmVjZWl2ZXIgd291bGQgY2hlY2sgdG8gc2Vl IGlmIHRoYXQgUFNEIGlzIGxpc3RlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbiB0aGUgRE1BUkMgUFNEIFJlZ2lzdHJ5LCBhbmQgaWYg c28sIHBlcmZvcm0gdGhlIHBvbGljeSBsb29rdXAgYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBpbiB0aGUgRE1BUkMgUFNEIFJlZ2lzdHJ5LCBhbmQgaWYgc28sIHBlcmZvcm0g dGhlIHBvbGljeSBsb29rdXAgYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgIl9kbWFyYy5jb21wdXRlLmNsb3VkY29tcGFueS5jb20uY2N0 bGQiLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJfZG1hcmMuY29tcHV0ZS5j bG91ZGNvbXBhbnkuY29tLmNjdGxkIi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5v dGU6IEJlY2F1c2UgdGhlIFBTRCBwb2xpY3kgcXVlcnkgY29tZXMgYWZ0ZXIgdGhlIE9yZ2FuaXph dGlvbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTm90ZTogQmVjYXVzZSB0 aGUgUFNEIHBvbGljeSBxdWVyeSBjb21lcyBhZnRlciB0aGUgT3JnYW5pemF0aW9uYWw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRG9tYWlu IHBvbGljeSBxdWVyeSwgUFNEIHBvbGljeSBpcyBub3QgdXNlZCBmb3IgT3JnYW5pemF0aW9uYWw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEb21haW4gcG9saWN5IHF1ZXJ5LCBQ U0QgcG9saWN5IGlzIG5vdCB1c2VkIGZvciBPcmdhbml6YXRpb25hbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb21haW5zIHRoYXQgaGF2 ZSBwdWJsaXNoZWQgYSBETUFSQyBbUkZDNzQ4OV0gcG9saWN5LiAgU3BlY2lmaWNhbGx5LDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRvbWFpbnMgdGhhdCBoYXZlIHB1Ymxpc2hl ZCBhIERNQVJDIFtSRkM3NDg5XSBwb2xpY3kuICBTcGVjaWZpY2FsbHksPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoaXMgaXMgbm90IGEg bWVjaGFuaXNtIHRvIHByb3ZpZGUgZmVlZGJhY2sgYWRkcmVzc2VzIChSVUEvUlVGKSB3aGVuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhpcyBpcyBub3QgYSBtZWNoYW5pc20g dG8gcHJvdmlkZSBmZWVkYmFjayBhZGRyZXNzZXMgKFJVQS9SVUYpIHdoZW48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW4gT3JnYW5pemF0 aW9uYWwgRG9tYWluIGhhcyBkZWNsaW5lZCB0byBkbyBzby48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhbiBPcmdhbml6YXRpb25hbCBEb21haW4gaGFzIGRlY2xpbmVkIHRvIGRv IHNvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEx IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+My48c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9zcGFuPi4g IFNlY3Rpb24gNy4gIERNQVJDIEZlZWRiYWNrPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjMuPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj4uICBTZWN0aW9uIDcuICBETUFSQyBG ZWVkYmFjazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT3BlcmF0aW9uYWwgbm90ZSBm b3IgUFNEIERNQVJDOiBGb3IgUFNPcywgZmVlZGJhY2sgZm9yIG5vbi1leGlzdGVudDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE9wZXJhdGlvbmFsIG5vdGUgZm9yIFBTRCBETUFS QzogRm9yIFBTT3MsIGZlZWRiYWNrIGZvciBub24tZXhpc3RlbnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9tYWlucyBpcyBkZXNpcmVk IGFuZCB1c2VmdWwuICBTZWUgU2VjdGlvbiA0IGZvciBkaXNjdXNzaW9uIG9mPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9tYWlucyBpcyBkZXNpcmVkIGFuZCB1c2VmdWwuICBT ZWUgU2VjdGlvbiA0IGZvciBkaXNjdXNzaW9uIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBQcml2YWN5IENvbnNpZGVyYXRpb25zPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxMiIgLz48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoZXNlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXJlIGRl dmVsb3BlZCBiYXNlZCBvbiB0aGUgcmVxdWlyZW1lPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dG48L3Nw YW4+czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGVzZSBwcml2YWN5IGNv bnNpZGVyYXRpb25zIGFyZSBkZXZlbG9wZWQgYmFzZWQgb24gdGhlIHJlcXVpcmVtZTxzcGFuIGNs YXNzPSJpbnNlcnQiPm50PC9zcGFuPnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgW1JGQzY5NzNdLiAgVGhlIFByaXZhY3kgQ29uc2lk ZXJhdGlvbnMgb2YgW1JGQzc0ODldIGFwcGx5IHRvIHRoaXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBvZiBbUkZDNjk3M10uICBUaGUgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBv ZiBbUkZDNzQ4OV0gYXBwbHkgdG8gdGhpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuMS4g IEZlZWRiYWNrIGxlYWthZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjEuICBG ZWVkYmFjayBsZWFrYWdlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aWRpbmcg ZmVlZGJhY2sgcmVwb3J0aW5nIHRvIFBTT3MgY2FuLCBpbiBzb21lIGNhc2VzLCBjcmVhdGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aWRpbmcgZmVlZGJhY2sgcmVwb3J0 aW5nIHRvIFBTT3MgY2FuLCBpbiBzb21lIGNhc2VzLCBjcmVhdGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGVha2FnZSBvZiBpbmZvcm1h dGlvbiBvdXRzaWRlIG9mIGFuIG9yZ2FuaXphdGlvbiB0byB0aGUgUFNPLiAgVGhpczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxlYWthZ2Ugb2YgaW5mb3JtYXRpb24gb3V0c2lk ZSBvZiBhbiBvcmdhbml6YXRpb24gdG8gdGhlIFBTTy4gIFRoaXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYw MDEzIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbGVha2FnZSBjb3VsZCA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5iZSA8L3NwYW4+cG90ZW50aWFsbHkgYmUgdXRpbGl6ZWQgYXMgcGFydCBvZiBhIHBy b2dyYW0gb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgbGVha2FnZSBjb3Vs ZCBwb3RlbnRpYWxseSBiZSB1dGlsaXplZCBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSBvZjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwZXJ2YXNp dmUgc3VydmVpbGxhbmNlIChTZWUgW1JGQzc2MjRdKS4gIFRoZXJlIGFyZSByb3VnaGx5IHRocmVl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcGVydmFzaXZlIHN1cnZlaWxsYW5j ZSAoU2VlIFtSRkM3NjI0XSkuICBUaGVyZSBhcmUgcm91Z2hseSB0aHJlZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYXNlcyB0byBjb25z aWRlcjo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjYXNlcyB0byBjb25zaWRl cjo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFNpbmdsZSBPcmdhbml6YXRpb24g UFNEcyAoZS5nLiwgIi5nb29nbGUiKSwgUlVBIGFuZCBSVUYgcmVwb3J0czwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFNpbmdsZSBPcmdhbml6YXRpb24gUFNEcyAoZS5nLiwg Ii5nb29nbGUiKSwgUlVBIGFuZCBSVUYgcmVwb3J0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBiYXNlZCBvbiBQU0QgRE1BUkMgaGF2 ZSB0aGUgcG90ZW50aWFsIHRvIGNvbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBiYXNlZCBvbiBQU0QgRE1BUkMgaGF2ZSB0aGUgcG90 ZW50aWFsIHRvIGNvbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZW1haWxzIHJlbGF0ZWQgdG8g ZW50aXRpZXMgbWFuYWdlZCBieSB0aGUgb3JnYW5pemF0aW9uLiAgU2luY2U8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBlbWFpbHMgcmVsYXRlZCB0byBlbnRpdGllcyBtYW5h Z2VkIGJ5IHRoZSBvcmdhbml6YXRpb24uICBTaW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBib3RoIHRoZSBQU08gYW5kIHRoZSBP cmdhbml6YXRpb25hbCBEb21haW4gb3duZXJzIGFyZSBjb21tb24sPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgYm90aCB0aGUgUFNPIGFuZCB0aGUgT3JnYW5pemF0aW9uYWwg RG9tYWluIG93bmVycyBhcmUgY29tbW9uLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB0aGVyZSBpcyBubyBhZGRpdGlvbmFsIHByaXZh Y3kgcmlzayBmb3IgZWl0aGVyIG5vcm1hbCBvciBub24tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgdGhlcmUgaXMgbm8gYWRkaXRpb25hbCBwcml2YWN5IHJpc2sgZm9yIGVp dGhlciBub3JtYWwgb3Igbm9uLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBleGlzdGVudCBEb21haW4gcmVwb3J0aW5nIGR1ZSB0byBQ U0QgRE1BUkMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZXhpc3RlbnQg RG9tYWluIHJlcG9ydGluZyBkdWUgdG8gUFNEIERNQVJDLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQt bDYiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDcsIGxp bmUgMjQ8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI2IiAvPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA4LCBsaW5lIDI0PC9lbT48L3Ro Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBjb21wbGlhbmNlIHdpdGggUFNEIHBvbGljeS4g IERhdGEgb24gbm9uLWV4aXN0ZW50IGNvdXNpbiBkb21haW5zPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgY29tcGxpYW5jZSB3aXRoIFBTRCBwb2xpY3kuICBEYXRhIG9uIG5v bi1leGlzdGVudCBjb3VzaW4gZG9tYWluczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB3b3VsZCBiZSBzZW50IHRvIHRoZSBQU08uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgd291bGQgYmUgc2VudCB0byB0aGUg UFNPLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTXVsdGktb3JnYW5pemF0aW9u IFBTRHMgKGUuZy4sICIuY29tIikgdGhhdCBkbyBub3QgbWFuZGF0ZSBETUFSQzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIE11bHRpLW9yZ2FuaXphdGlvbiBQU0RzIChlLmcu LCAiLmNvbSIpIHRoYXQgZG8gbm90IG1hbmRhdGUgRE1BUkM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdXNhZ2U6IFByaXZhY3kgcmlz a3MgZm9yIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMgdGhhdCBoYXZlIG5vdDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHVzYWdlOiBQcml2YWN5IHJpc2tzIGZvciBPcmdhbml6 YXRpb25hbCBEb21haW5zIHRoYXQgaGF2ZSBub3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZGVwbG95ZWQgRE1BUkMgd2l0aGluIHN1 Y2ggUFNEcyBhcmUgc2lnbmlmaWNhbnQuICBGb3Igbm9uLURNQVJDPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgZGVwbG95ZWQgRE1BUkMgd2l0aGluIHN1Y2ggUFNEcyBhcmUg c2lnbmlmaWNhbnQuICBGb3Igbm9uLURNQVJDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMsIGFs bCBETUFSQyBmZWVkYmFjayB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIE9yZ2FuaXphdGlvbmFsIERvbWFpbnMsIGFsbCBETUFSQyBm ZWVkYmFjayB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBQU08uICBQU0QgRE1BUkMgaXMgb3B0 LW91dCAoYnkgcHVibGlzaGluZyBhIERNQVJDIHJlY29yZCBhdCB0aGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBQU08uICBQU0QgRE1BUkMgaXMgb3B0LW91dCAoYnkgcHVi bGlzaGluZyBhIERNQVJDIHJlY29yZCBhdCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgT3JnYW5pemF0aW9uYWwgRG9tYWluIGxl dmVsKSB2aWNlIG9wdC1pbiwgd2hpY2ggd291bGQgYmUgdGhlIG1vcmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBPcmdhbml6YXRpb25hbCBEb21haW4gbGV2ZWwpIHZpY2Ug b3B0LWluLCB3aGljaCB3b3VsZCBiZSB0aGUgbW9yZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBkZXNpcmFibGUgY2hhcmFjdGVyaXN0 aWMuICBUaGlzIG1lYW5zIHRoYXQgYW55IG5vbi1ETUFSQzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3RpYy4gIFRoaXMgbWVhbnMgdGhh dCBhbnkgbm9uLURNQVJDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNCIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgICAgIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiB3b3VsZCBoYXZlIGl0PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Jzwvc3Bhbj5zIGZlZWRiYWNrIHJlcG9ydHMgcmVkaXJlY3RlZDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBvcmdhbml6YXRpb25hbCBkb21haW4gd291bGQg aGF2ZSBpdHMgZmVlZGJhY2sgcmVwb3J0cyByZWRpcmVjdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRvIHRoZSBQU08uICBUaGUg Y29udGVudCBvZiBzdWNoIHJlcG9ydHMsIHBhcnRpY3VsYXJseSBmb3I8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB0byB0aGUgUFNPLiAgVGhlIGNvbnRlbnQgb2Ygc3VjaCBy ZXBvcnRzLCBwYXJ0aWN1bGFybHkgZm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGV4aXN0aW5nIGRvbWFpbnMsIGlzIHByaXZhY3kg c2Vuc2l0aXZlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGV4aXN0aW5n IGRvbWFpbnMsIGlzIHByaXZhY3kgc2Vuc2l0aXZlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUFNPcyB3aWxsIHJlY2VpdmUgZmVlZGJhY2sgb24gbm9uLWV4aXN0ZW50IGRvbWFpbnMs IHdoaWNoIG1heSBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTT3Mgd2ls bCByZWNlaXZlIGZlZWRiYWNrIG9uIG5vbi1leGlzdGVudCBkb21haW5zLCB3aGljaCBtYXkgYmU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg c2ltaWxhciB0byBleGlzdGluZyBPcmdhbml6YXRpb25hbCBEb21haW5zLiAgRmVlZGJhY2sgcmVs YXRlZCB0byBzdWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2ltaWxhciB0 byBleGlzdGluZyBPcmdhbml6YXRpb25hbCBEb21haW5zLiAgRmVlZGJhY2sgcmVsYXRlZCB0byBz dWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGNvdXNpbiBkb21haW5zIGhhdmUgYSBzbWFsbCByaXNrIG9mIGNhcnJ5aW5nIGluZm9ybWF0 aW9uIHJlbGF0ZWQgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb3VzaW4g ZG9tYWlucyBoYXZlIGEgc21hbGwgcmlzayBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiByZWxhdGVk IHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGFuIGFjdHVhbCBPcmdhbml6YXRpb25hbCBEb21haW4uICBUbyBtaW5pbWl6ZSB0aGlzIHBv dGVudGlhbCBjb25jZXJuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuIGFj dHVhbCBPcmdhbml6YXRpb25hbCBEb21haW4uICBUbyBtaW5pbWl6ZSB0aGlzIHBvdGVudGlhbCBj b25jZXJuLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBQU0QgRE1BUkMgZmVlZGJhY2sgaXMgYmVzdCBsaW1pdGVkIHRvIEFnZ3JlZ2F0ZSBS ZXBvcnRzLiAgRmVlZGJhY2s8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQU0Qg RE1BUkMgZmVlZGJhY2sgaXMgYmVzdCBsaW1pdGVkIHRvIEFnZ3JlZ2F0ZSBSZXBvcnRzLiAgRmVl ZGJhY2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUmVwb3J0cyBjYXJyeSBtb3JlIGRldGFpbGVkIGluZm9ybWF0aW9uIGFuZCBwcmVzZW50 IGEgZ3JlYXRlciByaXNrLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJlcG9y dHMgY2FycnkgbW9yZSBkZXRhaWxlZCBpbmZvcm1hdGlvbiBhbmQgcHJlc2VudCBhIGdyZWF0ZXIg cmlzay48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIg Pjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw3IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA4LCBsaW5lIDc8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48 YSBuYW1lPSJwYXJ0LXI3IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl bT4gcGFnZSA5LCBsaW5lIDc8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3 NDg5XSBhbmQgW1JGQzc5NjBdLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtS RkM3NDg5XSBhbmQgW1JGQzc5NjBdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IHJpc2tzIG9mIHRoZSBpc3N1ZXMgaWRlbnRpZmllZCBpbiBbUkZDNzQ4OV0sIFNlY3Rpb24gMTIu NSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcmlza3Mgb2YgdGhlIGlz c3VlcyBpZGVudGlmaWVkIGluIFtSRkM3NDg5XSwgU2VjdGlvbiAxMi41LDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFeHRlcm5hbCBSZXBv cnRpbmcgQWRkcmVzc2VzLCBhcmUgYW1wbGlmaWVkIGJ5IFBTRCBETUFSQy4gIEJ5IGRlc2lnbiw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFeHRlcm5hbCBSZXBvcnRpbmcgQWRk cmVzc2VzLCBhcmUgYW1wbGlmaWVkIGJ5IFBTRCBETUFSQy4gIEJ5IGRlc2lnbiw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUFNEIERNQVJD IGNhdXNlcyB1bnJlcXVlc3RlZCByZXBvcnRpbmcgb2YgZmVlZGJhY2sgdG8gZW50aXRpZXM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQU0QgRE1BUkMgY2F1c2VzIHVucmVxdWVz dGVkIHJlcG9ydGluZyBvZiBmZWVkYmFjayB0byBlbnRpdGllczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHRlcm5hbCB0byB0aGUgT3Jn YW5pemF0aW9uYWwgRG9tYWluLiAgVGhpcyBpcyBkaXNjdXNzZWQgaW4gbW9yZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4dGVybmFsIHRvIHRoZSBPcmdhbml6YXRpb25hbCBE b21haW4uICBUaGlzIGlzIGRpc2N1c3NlZCBpbiBtb3JlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRldGFpbCBpbiBTZWN0aW9uIDQuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGV0YWlsIGluIFNlY3Rpb24gNC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ni4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNSIgLz48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIFRoaXMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZG9jdW1lbnQgZG9lcyBub3Qg cmVxdWlyZSBhbnk8L3NwYW4+IElBTkEgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YWN0aW9ucy48L3Nw YW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgPHNwYW4gY2xhc3M9 Imluc2VydCI+c2VjdGlvbiBkZXNjcmliZXMgYWN0aW9ucyByZXF1ZXN0ZWQgdG8gYmUgY29tcGxl dGVkIGJ5IElBTkEuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPjYuMS4gIFN1YmRvbWFpbiBQb2xpY3kgVGFnPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIElBTkEgPHNwYW4gY2xhc3M9Imluc2VydCI+aXMg cmVxdWVzdGVkIHRvIGFkZCBhIG5ldyB0YWcgdG8gRE1BUkMgVGFnIFJlZ2lzdHJ5IGluIHRoZTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgRG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywgYW5k IENvbmZvcm1hbmNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICAoRE1BUkMpIFBhcmFtZXRlcnMgUmVnaXN0cnkuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIFRoZSBlbnRyeSBpcyBhcyBmb2xsb3dzOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IHwgVGFnIE5hbWUgfCBSZWZlcmVuY2UgfCBTdGF0dXMgIHwgRGVzY3JpcHRpb24gICAgICAgICAg ICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB8IG5wICAgICAgIHwgdGhpcyAgICAg IHwgY3VycmVudCB8IFJlcXVlc3RlZCBoYW5kbGluZyBwb2xpY3kgZm9yIHw8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHwgICAg ICAgICAgfCBkb2N1bWVudCAgfCAgICAgICAgIHwgbm9uLWV4aXN0ZW50IHN1YmRvbWFpbnMgICAg ICAgfDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ Ny4gIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij43LiAgUmVmZXJl bmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Ny4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij43LjEuICBOb3JtYXRpdmUgUmVmZXJl bmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIs IEJDUCAxNCwgUkZDIDIxMTksPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcs PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZn dDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Jmd0Oy48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1l PSJwYXJ0LWw4IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFn ZSA5LCBsaW5lIDI1PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yOCIgLz48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgNDA8 L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgYW5kIENvbmZvcm1h bmNlIChETUFSQykgYW5kIEluZGlyZWN0IEVtYWlsIEZsb3dzIiw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIGFuZCBDb25mb3JtYW5jZSAoRE1BUkMpIGFuZCBJ bmRpcmVjdCBFbWFpbCBGbG93cyIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgUkZDIDc5NjAsIERPSSAxMC4xNzQ4Ny9S RkM3OTYwLCBTZXB0ZW1iZXIgMjAxNiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIFJGQyA3OTYwLCBET0kgMTAuMTc0ODcvUkZDNzk2MCwgU2VwdGVtYmVyIDIw MTYsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzk2 MCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7 aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3OTYwJmd0Oy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM4MDIwXSAgQm9ydHptZXllciwgUy4gYW5kIFMuIEh1cXVl LCAiTlhET01BSU46IFRoZXJlIFJlYWxseSBJczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFtSRkM4MDIwXSAgQm9ydHptZXllciwgUy4gYW5kIFMuIEh1cXVlLCAiTlhET01BSU46 IFRoZXJlIFJlYWxseSBJczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIE5vdGhpbmcgVW5kZXJuZWF0aCIsIFJGQyA4MDIw LCBET0kgMTAuMTc0ODcvUkZDODAyMCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIE5vdGhpbmcgVW5kZXJuZWF0aCIsIFJGQyA4MDIwLCBET0kgMTAuMTc0ODcv UkZDODAyMCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDE2LCAmbHQ7aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM4MDIwJmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTYsICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzgwMjAmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QXBwZW5k aXggQS4gIFRoZSBFeHBlcmltZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QXBw ZW5kaXggQS4gIFRoZSBFeHBlcmltZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMTYiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhlcmUgYXJlIHR3 byBleHBlcmltZW50YWwgcXVlc3Rpb25zIGFkZHJlc3NlZCBpbiB0aGlzIGRvY3VtZW50OiBvbmU8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIHJlZ2FyZGluZyBtaXRpZ2F0aW9uIG9mIFBTRCByZWxhdGVkIHByaXZhY3kgY29uY2Vy bnMgYW5kIHRoZSBvdGhlciBvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhlIHV0aWxpdHkgb2Ygc3BlY2lmeWluZyBzZXBh cmF0ZSBETUFSQyBwb2xpY2llcyBmb3Igbm9uLWV4aXN0ZW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzdWItZG9tYWlucy48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+QS4xLiAgUFNEIERNQVJDIFByaXZhY3kgQ29uY2VybiBNaXRpZ2F0aW9uPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRvIG1p dGlnYXRlIHRoZSBwcml2YWN5IGNvbmNlcm5zIGFzc29jaWF0ZWQgd2l0aCBNdWx0aS1vcmdhbml6 YXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUbyBtaXRpZ2F0ZSB0aGUg cHJpdmFjeSBjb25jZXJucyBhc3NvY2lhdGVkIHdpdGggTXVsdGktb3JnYW5pemF0aW9uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBTRHMg dGhhdCBkbyBub3QgbWFuZGF0ZSBETUFSQyB1c2FnZSwgc2VlIFNlY3Rpb24gNC4xLCBhIG1lY2hh bmlzbSB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTRHMgdGhhdCBkbyBu b3QgbWFuZGF0ZSBETUFSQyB1c2FnZSwgc2VlIFNlY3Rpb24gNC4xLCBhIG1lY2hhbmlzbSB0bzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBp bmRpY2F0ZSB3aGljaCBQU0RzIGRvIG5vdCBwcmVzZW50IHRoaXMgcHJpdmFjeSByaXNrIGlzIGFw cHJvcHJpYXRlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluZGljYXRlIHdo aWNoIFBTRHMgZG8gbm90IHByZXNlbnQgdGhpcyBwcml2YWN5IHJpc2sgaXMgYXBwcm9wcmlhdGUu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoZXJlIGFyZSBtdWx0aXBsZSBhcHByb2FjaGVzIHRoYXQgYXJlIHBvc3NpYmxlLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZXJlIGFyZSBtdWx0aXBsZSBhcHByb2FjaGVz IHRoYXQgYXJlIHBvc3NpYmxlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGV4 cGVyaW1lbnQgaXMgdG8gZXZhbHVhdGUgZGlmZmVyZW50IHBvc3NpYmxlIGFwcHJvYWNoZXMuICBU aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZXhwZXJpbWVudCBpcyB0 byBldmFsdWF0ZSBkaWZmZXJlbnQgcG9zc2libGUgYXBwcm9hY2hlcy4gIFRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBleHBlcmltZW50 IHdpbGwgYmUgY29tcGxldGUgd2hlbiB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMgb24gYTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4cGVyaW1lbnQgd2lsbCBiZSBjb21wbGV0 ZSB3aGVuIHRoZXJlIGlzIHJvdWdoIGNvbnNlbnN1cyBvbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRlY2huaWNhbCBhcHByb2FjaCB0 aGF0IGlzIGRlbW9uc3RyYXRlZCB0byBiZSBvcGVyYXRpb25hbGx5IHVzYWJsZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRlY2huaWNhbCBhcHByb2FjaCB0aGF0IGlzIGRlbW9u c3RyYXRlZCB0byBiZSBvcGVyYXRpb25hbGx5IHVzYWJsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgZWZmZWN0aXZlIGF0IG1pdGln YXRpbmcgdGhlIHByaXZhY3kgY29uY2Vybi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBhbmQgZWZmZWN0aXZlIGF0IG1pdGlnYXRpbmcgdGhlIHByaXZhY3kgY29uY2Vybi48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3Rk Pjx0aD48YSBuYW1lPSJwYXJ0LWw5IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxlbT4gcGFnZSAxMCwgbGluZSAxNTwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9 InBhcnQtcjkiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdl IDExLCBsaW5lIDM4PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBcyBvZiB0aGlz IHdyaXRpbmcsIHRocmVlIGFwcHJvYWNoZXMgaGF2ZSBiZWVuIHByb3Bvc2VkLiAgTm9uZSBvZjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFzIG9mIHRoaXMgd3JpdGluZywgdGhy ZWUgYXBwcm9hY2hlcyBoYXZlIGJlZW4gcHJvcG9zZWQuICBOb25lIG9mPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZW0gYXJlIGlkZWFs OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZW0gYXJlIGlkZWFsOjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgQW4gZXh0ZW5zaW9uIHRvIHRoZSBQdWJsaWMg U3VmZml4IExpc3QgYXQgW1BTTF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBv ICBBbiBleHRlbnNpb24gdG8gdGhlIFB1YmxpYyBTdWZmaXggTGlzdCBhdCBbUFNMXTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgQSBkZWRpY2F0ZWQgcmVnaXN0cnkgcXVlcmllZCB2 aWEgRE5TIC0gYW4gZXhhbXBsZSBvZiBzdWNoIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBvICBBIGRlZGljYXRlZCByZWdpc3RyeSBxdWVyaWVkIHZpYSBETlMgLSBhbiBleGFt cGxlIG9mIHN1Y2ggYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBzZXJ2aWNlIGlzIGRlc2NyaWJlZCBpbiBBcHBlbmRpeCBCLjEgYmVs b3c8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBzZXJ2aWNlIGlzIGRlc2Ny aWJlZCBpbiBBcHBlbmRpeCBCLjEgYmVsb3c8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG8gIEFuIElBTkEgcmVnaXN0cnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBv ICBBbiBJQU5BIHJlZ2lzdHJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwMTciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+QS4yLiAgTm9uLUV4aXN0ZW50IFN1 YmRvbWFpbiBQb2xpY3k8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgUFNPcyB0aGF0IHBsYW4gdG8gaW1wbGVtZW50IFBT RCBETUFSQyBoYXZlIGluZGljYXRlZCB0aGF0IHRoZSBhYmlsaXR5PC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0byBkZXNjcmli ZSBkaXN0aW5jdCBwb2xpY2llcyBmb3IgZXhpc3RpbmcgYW5kIG5vbi0gZXhpc3Rpbmcgc3ViLTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgZG9tYWlucyB3b3VsZCBmYWNpbGl0YXRlIFBTRCBETUFSQyBkZXBsb3ltZW50LiAgVGhl cmUgYXJlIGFsc288L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIHN1Z2dlc3Rpb25zIHRoYXQgaXQgd291bGQgYmUgbW9yZSBnZW5l cmFsbHkgdXNlZnVsIGZvciBETUFSQy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgRHVyaW5nIHRoZSBwZXJpb2Qgb2Yg dGhlIGV4cGVyaW1lbnQsIHVwdGFrZSBvZiB0aGUgbmV3ICducCcgdGFnIHdpbGw8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGJl IGV2YWx1YXRlZCB0byBzdXBwb3J0IGFzc2Vzc21lbnQgb2YgdGhlIHV0aWxpdHkgb2YgaW5jbHVk aW5nICducCc8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs YXNzPSJpbnNlcnQiPiAgIGluIGEgZnV0dXJlLCBub24tZXhwZXJpbWVudGFsIHVwZGF0ZS48L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QXBwZW5k aXggQi4gIERNQVJDIFBTRCBSZWdpc3RyeSBFeGFtcGxlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPkFwcGVuZGl4IEIuICBETUFSQyBQU0QgUmVnaXN0cnkgRXhhbXBsZXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxOCIgLz48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIFRvIGZhY2lsaWF0ZSBleHBlcmltZW50YXRpb24gYXJvdW5kIGRhdGEg bGVha2FnZSBtaXRpZ2F0aW9uLCBzYW1wbGVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIFRvIGZhY2lsaTxzcGFuIGNsYXNzPSJpbnNlcnQiPnQ8L3NwYW4+YXRlIGV4cGVyaW1l bnRhdGlvbiBhcm91bmQgZGF0YSBsZWFrYWdlIG1pdGlnYXRpb24sIHNhbXBsZXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIERO UyBiYXNlZCBhbmQgSUFOQSBsaWtlIHJlZ2lzdHJpZXMgYXJlIGF2YWlsYWJsZSBhdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIHRoZSBETlMgYmFzZWQgYW5kIElBTkEgbGlr ZSByZWdpc3RyaWVzIGFyZSBhdmFpbGFibGUgYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW3BzZGRtYXJjLm9yZ10uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW3BzZGRtYXJjLm9yZ10uPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij5CLjEuICBETUFSQyBQU0QgRE5TIFF1ZXJ5IFNlcnZpY2U8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij5CLjEuICBETUFSQyBQU0QgRE5TIFF1ZXJ5IFNlcnZpY2U8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgc2FtcGxlIHN0YW5kLWFsb25lIEROUyBxdWVy eSBzZXJ2aWNlIGlzIGF2YWlsYWJsZSBhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEEgc2FtcGxlIHN0YW5kLWFsb25lIEROUyBxdWVyeSBzZXJ2aWNlIGlzIGF2YWlsYWJsZSBh dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBbcHNkZG1hcmMub3JnXS4gIEl0IHdhcyBkZXZlbG9wZWQgYmFzZWQgb24gdGhlIGNvbnRlbnRz IHN1Z2dlc3RlZCBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbcHNkZG1h cmMub3JnXS4gIEl0IHdhcyBkZXZlbG9wZWQgYmFzZWQgb24gdGhlIGNvbnRlbnRzIHN1Z2dlc3Rl ZCBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgYW4gSUFOQSByZWdpc3RyeSBpbiBhbiBlYXJsaWVyIHJldmlzaW9uIG9mIHRoaXMgZHJh ZnQuICBVc2FnZSBvZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbiBJ QU5BIHJlZ2lzdHJ5IGluIGFuIGVhcmxpZXIgcmV2aXNpb24gb2YgdGhpcyBkcmFmdC4gIFVzYWdl IG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBzZXJ2aWNlIGlzIGRlc2NyaWJlZCBvbiB0aGUgd2ViIHNpdGUuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc2VydmljZSBpcyBkZXNjcmliZWQgb24gdGhlIHdlYiBz aXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgoKICAgICA8dHI+PHRkPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZD48L3RkPjwvdHI+ CiAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIj48 YSBuYW1lPSJlbmQiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAxOCBjaGFuZ2UgYmxvY2tzLiZuYnNw OzwvYT48L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjM3 IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxp PjExNCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8 dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyLz5UaGlz IGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQxLiBUaGUgbGF0ZXN0IHZlcnNp b24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90 b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4g PC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAgIDwvaHRtbD4K --nextPart1878466.arYzq08ld2-- From nobody Fri Jul 19 22:08: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 9DF6C12008D for ; Fri, 19 Jul 2019 22:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=CncJKFGw; dkim=pass (1536-bit key) header.d=taugh.com header.b=lkUR3jCc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCGxfLzHCzVl for ; Fri, 19 Jul 2019 22:08:54 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33045120044 for ; Fri, 19 Jul 2019 22:08:54 -0700 (PDT) Received: (qmail 20464 invoked from network); 20 Jul 2019 05:08:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4fed.5d32a1e5.k1907; i=johnl-iecc.com@submit.iecc.com; bh=GBV8nN5SeqeljuQ9W6p3NPVJVSX2zQ4MS1Hzp4xq4eU=; b=CncJKFGwPpkpl0qdgqURw/0ZA/tlAPwFUTiRR4zvLPnIFjErd39iWbiB2W1et3IPiDI8/8FQ1+invR/HMMYzT20SyhpUv0BKBLgVSUw+oP9FOaQ5mictxI/0vJjOyUjykn4cR+SfV0wwypUtmem/Su8eTNQByOWaLJ1rAQSwSqDKlVA4hBcJ9JJx/3Ax8RqwuoIWOXhDHvqkATC7wfmdRI8jlTsl2rA/xSFdn2Y/zohYEYhumKkWqGv3oBz747EU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4fed.5d32a1e5.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=GBV8nN5SeqeljuQ9W6p3NPVJVSX2zQ4MS1Hzp4xq4eU=; b=lkUR3jCchHu0wNglQPRNGwha0/UUs3hJzhaDhp5tYdr50ljQyg6IVS5cNEhhm2w9pFfrzozRtCL8zrwVGsKa6xJgM8whcdtMbs99OiBRMsYgeePwuxP/66E0i5FQyIfwaoSlcEi4thRkcaJHz/+afXJmaoBXyypR8+K8RBboEbjgYf0NaZHG0p4oxzwSjerMMBR1GEUPxMF+MTsY/UHDfEGno9Ys3cxRKE1rQ7HEQi/ldrrVWSXVeiOFb9GgUVo5 Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 20 Jul 2019 05:08:53 -0000 Received: by ary.qy (Postfix, from userid 501) id BFC22525572; Sat, 20 Jul 2019 01:08:52 -0400 (EDT) Date: 20 Jul 2019 01:08:52 -0400 Message-Id: <20190720050852.BFC22525572@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 05:08:56 -0000 In article you write: >Most MTAs will also follow CNAMEs. Should they be included (along with >other things like DNAME records) within the scope of existence? I'm a >little concerned that we are making a special definition of "non-existence" >which differs from the standard DNS concepts of NODATA and NXDOMAIN without >having a correspondingly special name. Good catch, you have to chase CNAME and DNAME before deciding whether you've found A/AAAA/MX. >I'm not sure how well this maps to what we describe. I'm also concerned >that a wildcard null MX record at the org level would end up having all >subdomains "exist", but the policy that should be applied would be the more >restrictive "np" policy, not the (possibly) more permissive "sp" policy. That sounds fairly deep into "don't do that" territory. If you are clever enough to publish a wild card MX, you should be clever enough to publish an appropriate DMARC record. Keep in mind that wildcards don't work the way many people think they do, so if you have *.foo.com along with a.foo.com, then the wildcard will match b.foo.com, but not b.a.foo.com. R's, John From nobody Sat Jul 20 02:05: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 77FBC120134 for ; Sat, 20 Jul 2019 02:05:03 -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, 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_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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KleRhleUv2AU for ; Sat, 20 Jul 2019 02:05:00 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100122.outbound.protection.outlook.com [40.107.10.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02081120058 for ; Sat, 20 Jul 2019 02:04:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BynThPBcOZvIkAtVqVpLieWzLe+isfvFyFnX2Yshv+9qtIwdoV/wbNjaCgi7Cjlp2BBTR2feStbVciNcG/HEOga4wUTff2E3QCpFMd9qs9ZvU54FukxwVKu9FPusouMhe7oi517zrINK+35ZlBzpfFno1be61tNJJ0YRF7gZG/7ROaBc3mNyf1t5yvS+KhQZ/htPUY7zfsrnDQq+FFvHRGjWlQWQvzUho3I2MDb08bD9z9jrvo9EzOXq+7Y8plS2qroIH1+i7+i6hXgviJa52KrjNW6BPVnZBXi6edmG4gCgqyvKY7eHYTTTe475o0KoxyMuUCx9/BjR25DFPniUqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=SuXI337wX6Cv8eYBW8scLYKogqPUE+nDLM8BxpY5Ku/fYz6wZKFAYaXLY5nGqAjRJzUOO5S0FJStvVy72qBiBfXc7bUrVuvONDA8fZ1S1AZ7bI6S4lFnLzeOVga2fPB+X50G1X3Z+bC6DsiFcNEmM8DCa7ljyRqkn1q5vC0J5dzSMxe0wqPB/QQZziXwajjl0wYcuWI4fJxKvJswJ+sBBxZ8TgtyNOCXJcuRZPvblKjyOFiygjpJiAPUOAPs+BPeMVVoTMTprLc58n7ra1dE7kghDUuoGXyJ05WUz+T4v3ec9xTgEfhgImKExdLrX3bhzIF2LS3KLghuRvAqSYHoEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=C9bT8oE9tyC6uGmjMlRct/FPclGOkg+2OV1cG/5s+i9DI30t9ajY6KmdqzxVocu/r2qFHj0y73t3SVeqHqc4KVbSFDLzWpqOoiqkuiBHjwvFqdquy8SWQ4qUuFBUfiDJc6EnJtQwYHTQpu48pidkSyHApednOoJRdKpmhxmyuFo= Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM (20.176.155.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.14; Sat, 20 Jul 2019 09:04:57 +0000 Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2094.013; Sat, 20 Jul 2019 09:04:57 +0000 From: Ian Levy To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAJaoCAAaTUgIAFVuCAgAD9pACAADq9AIAAL2GAgADcIgCAAOphAIAACBSggABi5ACAAP51AIAAYX5g Date: Sat, 20 Jul 2019 09:04:57 +0000 Message-ID: References: <2333259.aoXCTIVaPC@l5580> In-Reply-To: <2333259.aoXCTIVaPC@l5580> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk; x-originating-ip: [51.141.34.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2239; x-ms-traffictypediagnostic: LO2P123MB2239: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-forefront-prvs: 0104247462 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(136003)(39850400004)(366004)(189003)(199004)(13464003)(66946007)(76116006)(8676002)(66446008)(68736007)(14454004)(52536014)(33656002)(66476007)(478600001)(66556008)(64756008)(86362001)(25786009)(74316002)(66066001)(966005)(7736002)(305945005)(45080400002)(2906002)(229853002)(256004)(14444005)(44832011)(486006)(81156014)(8936002)(81166006)(55016002)(6306002)(9686003)(6436002)(5660300002)(6246003)(99286004)(316002)(110136005)(53936002)(102836004)(476003)(6506007)(55236004)(53546011)(71190400001)(71200400001)(2501003)(7696005)(76176011)(3846002)(6116002)(26005)(11346002)(446003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2239; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GQztNrE+RhzfMFJHSmc2f+/t8S7TWgqCe0wE0I+H6azzvElufDfPWazWycpSl+o0UfZlFhnymPh4/jNzTaC2kZJVddx/4dXrHXnYt1uSLhFuuCZR618g9iIXd/fdgn5Hg3hwQK0/6NO7PKDa9WvwTw3t4UoJ16oDJBqS0ELMSnMsrzwZGSAfB//7W1N45TZCCJx+4k9mGibz35o2ziu1dgiFusnMJEU9FvSDGcs5NNh0Pm+Q39rP+XAjV83zkBU4DTOXWJqdSd6c4euxQTU3EgbBuuvGpdT7K4hYhezqUVYbTFErAf+cQJpN42tjDcDjZtnxGrm4lu4OkMqcNreVCD/+2rqp6Mg8qnPO+/75tfKBh0Yy+DHxgJayiPcLZkkAS5ZSmu47fpm69stCz5qE0ml3EKlSJIIS1IFlJOJcbg4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2019 09:04:57.6016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2239 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 09:05:03 -0000 Pj4gVGhpcyBpbXBsaWVzIGEgZGVwbG95bWVudCBkb2N1bWVudCBiYXNlZCBvbiB0aGUgZXhwZXJp ZW5jZXMgb2YgZWFybHkgYWRvcHRlcnMuDQoNCj4gSSBhZ3JlZSwgYnV0IEkgdGhpbmsgc29sdmlu ZyB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50IGRvY3VtZW50Lg0KDQor MS4NCg0KVGEuDQoNCkkuDQoNCg0KLS0NCkRyIElhbiBMZXZ5DQpUZWNobmljYWwgRGlyZWN0b3IN Ck5hdGlvbmFsIEN5YmVyIFNlY3VyaXR5IENlbnRyZQ0KaWFuQG5jc2MuZ292LnVrDQoNClN0YWZm IE9mZmljZXIgOiBLYXRlIEF0a2lucywga2F0ZS5hQG5jc2MuZ292LnVrDQoNCihJIHdvcmsgc3R1 cGlkIGhvdXJzIGFuZCB3ZWlyZCB0aW1lcyDigJMgdGhhdCBkb2VzbuKAmXQgbWVhbiB5b3UgaGF2 ZSB0by4gSWYgdGhpcyBhcnJpdmVzIG91dHNpZGUgeW91ciBub3JtYWwgd29ya2luZyBob3Vycywg ZG9u4oCZdCBmZWVsIGNvbXBlbGxlZCB0byByZXNwb25kIGltbWVkaWF0ZWx5ISkNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtYXJjIDxkbWFyYy1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgU2NvdHQgS2l0dGVybWFuDQpTZW50OiAyMCBKdWx5IDIwMTkgMDQ6MTUN ClRvOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBOb25leGlzdGVu dCBEb21haW4gUG9saWN5IHdhczogUmU6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsOiBkcmFmdC1p ZXRmLWRtYXJjLXBzZA0KDQpPbiBGcmlkYXksIEp1bHkgMTksIDIwMTkgODowNDoyMCBBTSBFRFQg RG90emVybyB3cm90ZToNCj4gSSd2ZSBiZWVuIGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBidXQg aGF2ZW4ndCBjb250cmlidXRlZCBhbnl0aGluZyANCj4gdW50aWwgdGhpcyBwb2ludC4gQ29tbWVu dCBiZWxvdy4NCj4NCj4gT24gRnJpLCBKdWwgMTksIDIwMTkgYXQgMzoyOSBBTSBJYW4gTGV2eSA8 aWFuLmxldnk9DQo+DQo+IDQwbmNzYy5nb3YudWtAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ ID4gSSB0aGluayB0aGlzIGlzIG9uZSBvZiB0aG9zZSAieW91IG11c3QgYmUgdGhpcyB0YWxsIHRv IHJpZGUgb24gDQo+ID4gPiB0aGlzIHJpZGUiDQo+ID4gPiBzaXR1YXRpb25zLiAgRE5TIGNvbWVz IGVxdWlwcGVkIHdpdGggbXVsdGlwbGUgZm9vdGd1bnMgYW5kIHlvdSANCj4gPiA+IGhhdmUgdG8N Cj4gPg0KPiA+IGtub3cgYSBiaXQgYWJvdXQgd2hhdCB5b3UncmUgZG9pbmcgdG8gbWFrZSBzdXJl IHlvdSBnZXQgdGhlIGVmZmVjdHMgDQo+ID4geW91J3JlIGFmdGVyLg0KPiA+DQo+ID4gVGhpcy4g RE1BUkMgdG9kYXkgYWxsb3dzIHBlb3BsZSB0byBkaXNjb25uZWN0IHRoZWlyIG91dGdvaW5nIG1h aWwgDQo+ID4gZnJvbSB0aGUgcmVzdCBvZiB0aGUgd29ybGQuIEFkbWl0dGVkbHksIHRoZSBQU0Qt bGV2ZWwgcG9saWNpZXMgd291bGQgDQo+ID4gaGF2ZSBhIG11Y2ggZ3JlYXRlciBlZmZlY3QsIGJ1 dCB5b3VyIFBTRC9UTEQgb3BlcmF0b3IgY2FuIGFscmVhZHkgDQo+ID4gYm9yayB5b3UgaWYgdGhl eSdyZSBub3QgY29tcGV0ZW50Lg0KPiA+IFRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGJ1Y2tldHMg b2YgcmlzayBpbiBteSB2aWV3LCB0aG91Z2ggOg0KPiA+IDEpIE5ldyBUTERzIGFyZSBlZmZlY3Rp dmVseSBncmVlbmZpZWxkIHNpdGVzIGFuZCBjYW4gZW5mb3JjZSANCj4gPiBhcHByb3ByaWF0ZSBy ZXF1aXJlbWVudHMgb24gdGhlaXIgY3VzdG9tZXJzIGZyb20gdGhlIHN0YXJ0IHRvIA0KPiA+IG1p bmltaXplIHRoZSBjaGFuY2Ugb2YgdW5pbnRlbmRlZCBjb25zZXF1ZW5jZXMgKGZvciBleGFtcGxl LCBieSByZXF1aXJpbmcgZG9tYWluIERNQVJDIGxhYmVscykuDQo+ID4gMikgRXhpc3RpbmcgVExE cywgd2hlcmUgdGhlcmUgYXJlIG1hbnkgc3ViZG9tYWlucyB3aXRoIHdpbGRseSANCj4gPiB2YXJp YWJsZSBpbXBsZW1lbnRhdGlvbnMsIHBvbGljaWVzIGFuZCB1c2UgYW5kIGhlcmUgd2UgYXJlIGdv aW5nIHRvIA0KPiA+IGhhdmUgdG8gYmUgcmVhbGx5IGNhcmVmdWwuIENhcmVmdWwgYW5kIG1ldGhv ZGljYWwgdGVzdGluZyB3aWxsIGJlIA0KPiA+IG5lY2Vzc2FyeSB0byBtYWtlIHN1cmUgdGhhdCBp bnRyb2R1Y3Rpb24gb2YgdGhlIFBTRC1sZXZlbCBwb2xpY2llcyANCj4gPiBkb2Vzbid0IGJyZWFr IGFueXRoaW5nIGltcG9ydGFudC4gSXQgdG9vayB1cyA2IG1vbnRocyB0byBnZXQgdG8gDQo+ID4g c3ludGhlc2l6aW5nIHA9cmVqZWN0IGZvciBub24tZXhpc3RlbnQgc3ViZG9tYWlucyBvZiAuZ292 LnVrLiBBIGxvdCANCj4gPiBvZiB0aGF0IHdhcyBhbmFseXNpbmcgdGhlIGRhdGEgd2UgZ290IGJh Y2sgYW5kIGZpeGluZyBzdHVmZiB0aGF0IHdlIA0KPiA+IG5ldmVyIGV4cGVjdGVkIChsaWtlIEtl cmJlcm9zIC0gZG9uJ3QgYXNrISkuIEkgZG9uJ3Qgc2VlIHdoeSBpdCANCj4gPiB3b3VsZCBiZSBk aWZmZXJlbnQgd2l0aCB0aGUgbnA9IHRhZywgYnV0IGl0IHdpbGwgaG9wZWZ1bGx5IGJlIG11Y2gg bW9yZSBsaW1pdGVkIGluIHdoYXQgd2UgY291bGQgbWVzcyB1cC4NCj4gPg0KPiA+IEkgdGhpbmsg d2UncmUgcmVhbGx5IGFsbCB3b3JyaWVkIGFib3V0IHRoZSBzZWNvbmQgb2YgdGhlc2UgY2FzZXMu IElmIA0KPiA+IHRoYXQncyB0cnVlLCB0aGVuIEknbSB3aXRoIFNjb3R0IC0gaWYgeW91IGRvbid0 IHVuZGVyc3RhbmQgdGhpcyANCj4gPiBzdHVmZiwgZG9uJ3QgZ28gYW5kIHNldCBhbiBucCB0YWcg b24geW91ciBQU0QgYW5kIGNyb3NzIHlvdXIgDQo+ID4gZmluZ2Vycy4gSXQncyBnb2luZyB0byBl bmQgYmFkbHkuIE9uZSBvZiB0aGUgdGhpbmdzIGFib3V0IGRvaW5nIHRoZSANCj4gPiBleHBlcmlt ZW50IGlzIHN1cmVseSB0byBoZWxwIHVzIHVuZGVyc3RhbmQgaG93IGJhZGx5IHRoZXNlIGNhbiBn byANCj4gPiB3cm9uZywgc28gd2UgY2FuIHdyaXRlIGRvd24gYSBidW5jaCBvZiB3YXlzIG5vdCB0 byBkbyB0aGluZ3MuDQo+ID4NCj4gPiBXZSBjYW4gd3JpdGUgaW4gdGhlIGRvY3VtZW50IHRoYXQg c2Npc3NvcnMgYXJlIHNoYXJwIGFuZCBydW5uaW5nIA0KPiA+IHdpdGggc2hhcnAgdGhpbmdzIGNh biBjYXVzZSBwcm9ibGVtcy4gQnV0IGluIHRoZSBlbmQsIHNvbWVvbmUgaXMgDQo+ID4gZ29pbmcg dG8gcnVuIHdpdGggc2Npc3NvcnMgYW5kIGdldCBodXJ0LiBXZSBjYW4ndCBjb2RlIGZvciBldmVy eSANCj4gPiBzaW5nbGUgY2FzZSBoZXJlIGFuZCB3ZSBzdXJlbHkgbXVzdCBhc3N1bWUgYSBsZXZl bCBvZiBjb21wZXRlbmNlIG9mIA0KPiA+IHBlb3BsZSBpbXBsZW1lbnRpbmcgc29tZXRoaW5nIGxp a2UgdGhpcy4NCj4NCj4gVGhlIHByb2JsZW0sIHdoaWNoIHdlIGtub3cgb3Igc2hvdWxkIGtub3cs IGlzIHRoYXQgRE5TIHJlY29yZHMgYXJlIA0KPiBhcHBhcmVudGx5IGRpZmZpY3VsdCB0byBnZXQg cmlnaHQuIFdlIGhhdmUgYSBsYXJnZSBjb3JwdXMgb2YgZGF0YSANCj4gcG9pbnRzIHRvIGJhY2sg dGhpcyB1cCBiYXNlZCBvbiBkZWNhZGVzIG9mIGV4cGVyaWVuY2UuIEV2ZW4gbGFyZ2UsIA0KPiBz dXBwb3NlZGx5IGV4cGVyaWVuY2VkIGFuZCB0ZWNobmljYWxseSBxdWFsaWZpZWQgb3JnYW5pemF0 aW9ucyBzaG9vdCANCj4gdGhlbXNlbHZlcyBpbiB0aGUgZm9vdC4gU3BlYWtpbmcgYXMgYW4gb3Jp Z2luYWwgcGFydGljaXBhbnQgaW4gdGhlIA0KPiBkbWFyYy5vcmcgdGVhbSwgSSBjYW4ndCBlbXBo YXNpemUgZW5vdWdoIHRoZSBlZHVjYXRpb24gYW5kIA0KPiBldmFuZ2VsaXphdGlvbiBlZmZvcnQg aW52b2x2ZWQgcmVsYXRlZCB0byBhZG9wdGlvbiAoYW5kIG1pc3VuZGVyc3RhbmRpbmcgb2YgaG93 IGl0IHdvcmtzLi4uIG9yIGRvZXNuJ3Qgd29yaykuDQo+DQo+IEkgdGhpbmsgeW91IGFyZSBpbmNv cnJlY3Qgd2l0aCB5b3VyIGFzc3VtcHRpb24gcmVnYXJkaW5nIHNjZW5hcmlvICMxLiANCj4gSSBy ZWNlbnRseSBoYWQgYSBkaXNjdXNzaW9uIHdpdGggYW4gb3duZXIvb3BlcmF0b3Igb2YgYSBudW1i ZXIgb2YgIm5ldyIgVExEcy4NCj4gVGhleSBoYXZlIG5vIGNsdWUgcmVnYXJkaW5nIHRoaXMgZWZm b3J0LiBTbyBldmVuIGlmIGEgVExEIGlzIG5ldywgdGhhdCANCj4gZG9lcyBub3QgbWVhbiBpdCB3 aWxsIGltcGxlbWVudCBmcm9tIGRheSAxLiBUaGlzIG1lYW5zIHNjZW5hcmlvICMyIGlzIA0KPiBt b3JlIGxpa2VseSB0aGUgc2NlbmFyaW8gdG8gYmUgZGVhbHQgd2l0aCAoZGVmYXVsdCkgcmF0aGVy IHRoYW4gIzEuIA0KPiBQZXJoYXBzIGFmdGVyIHNvbWUgZXh0ZW5kZWQgcGVyaW9kIG9mIHBhaW4g b3IgaWYgSUNBTk4gbWFuZGF0ZXMgDQo+IHNvbWV0aGluZywgIzEgd2lsbCBiZWNvbWUgdGhlIGRl ZmF1bHQsIGJ1dCBJIHdvdWxkbid0IGhvbGQgbXkgYnJlYXRoLg0KPg0KPiBXaXRoIHJlZ2FyZCB0 byBzY2VuYXJpbyAjMiwgaXQgaXMgbm90IGVub3VnaCB0byBzaW1wbHkgc2F5ICJkb24ndCBydW4g DQo+IHdpdGggc2Npc3NvcnMiLiBTb21lIGdyb3VwLCBNM0FBV0cgb3IgSUNBTk4gb3IgSVNPQywg d2lsbCBuZWVkIHRvIA0KPiBlZHVjYXRlIGFuZCBldmFuZ2VsaXplIHRob3NlIG91dHNpZGUgdGhl IGlubmVyIGNpcmNsZSwgc28gdG8gc3BlYWsuIA0KPiBJJ20gc3VyZSB0aGF0IGNvbXBhbmllcyBs aWtlIEFnYXJpLCBEbWFyY2lhbiwgVmFsaW1haWwsIGV0Yy4gd2lsbCANCj4gZ2xhZGx5IHByb3Zp ZGUgYXNzaXN0YW5jZS4sIFRoYXQgVExEIG93bmVyL29wZXJhdG9yIEkgbWVudGlvbmVkIA0KPiBl YXJsaWVyIGlzIG5vdCBvdmVybHkgZmFtaWxpYXIgd2l0aCB0aGUgc3BhY2Ugb3IgdGhvc2UgdmVu ZG9ycy4NCj4NCj4gSXQgaXMgbm90IGVub3VnaCBmb3IgdGhlIGNyZWF0b3JzIG9mIGEgcHJvcG9z ZWQgc3RhbmRhcmQgdG8gc3RhdGUgaXQncyANCj4gdGVjaG5pY2FsIHZhbGlkaXR5LiBUaGlzIGlt cGxpZXMgYSBkZXBsb3ltZW50IGRvY3VtZW50IGJhc2VkIG9uIHRoZSANCj4gZXhwZXJpZW5jZXMg b2YgZWFybHkgYWRvcHRlcnMuDQoNCkkgYWdyZWUsIGJ1dCBJIHRoaW5rIHNvbHZpbmcgdGhhdCBp cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgY3VycmVudCBkb2N1bWVudC4NCg0KU2NvdHQgSw0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRt YXJjIG1haWxpbmcgbGlzdA0KZG1hcmNAaWV0Zi5vcmcNCmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRmRtYXJjJmFtcDtkYXRhPTAyJTdDMDElN0NpYW4ubGV2eSU0 MG5jc2MuZ292LnVrJTdDN2M3YjQxMDcwYjVhNDQ5ZWRiYzAwOGQ3MGNjMDkwOGYlN0MxNGFhNTc0 NGVjZTE0NzRlYTJkNzM0ZjQ2ZGRhNjRhMSU3QzAlN0MwJTdDNjM2OTkxODkzNTExODc4NjU0JmFt cDtzZGF0YT1OZzlmcyUyRkphOFI5T3JtJTJCUHF0aXE3SWRMVVh6MEslMkZ5eUZMUVJ0R3clMkZs SjQlM0QmYW1wO3Jlc2VydmVkPTANClRoaXMgaW5mb3JtYXRpb24gaXMgZXhlbXB0IHVuZGVyIHRo ZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdCAyMDAwIChGT0lBKSBhbmQgbWF5IGJlIGV4ZW1w dCB1bmRlciBvdGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgYW55IEZPSUEg cXVlcmllcyB0byBuY3NjaW5mb2xlZ0BuY3NjLmdvdi51ay4gQWxsIG1hdGVyaWFsIGlzIFVLIENy b3duIENvcHlyaWdodCDCqQ0K From nobody Sun Jul 21 09:40:56 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 276E51201CD for ; Sun, 21 Jul 2019 09:40:54 -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 y27iQjERRcGX for ; Sun, 21 Jul 2019 09:40:52 -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 68F641201A2 for ; Sun, 21 Jul 2019 09:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563727249; bh=nVvNcVIg2GWV3WHM2iu65nTAZ4og1h1w+BX5gGq+u5w=; l=1274; h=To:References:From:Date:In-Reply-To; b=A8P/TxN8jVYXr5u5sxayEnsTvqfOG8dpq7v4R6QBsf87JPxNuiXbNQE3wvRi/s+a4 AH8LLs6oqK7ZTZXNQW+7uuohFhfmtcMYqHeH6ixmUkiIVHr+k6hzLGQjkuWMqMDfYq 3XMJhX6ggf1Csbx7MzRHKIC1upSj9N95RyW2ruP2LcVey/5cfoMR884m72Teg 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 00000000005DC050.000000005D349591.00005E3E; Sun, 21 Jul 2019 18:40:49 +0200 To: dmarc@ietf.org References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> Date: Sun, 21 Jul 2019 18:40:49 +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: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 21 Jul 2019 16:40:54 -0000 On Wed 17/Jul/2019 08:26:25 +0200 Scott Kitterman wrote: > Keep in mind that senders do send from what we call non-existent domains for > reasons that seem good and sufficient to them. Let's take that as a fact, > whether it makes sense to us or not. Fair enough. Let me quote the current spec: A.4. Domain Existence Test A common practice among MTA operators, and indeed one documented in [ADSP], is a test to determine domain existence prior to any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated and assuming that the domain is nonexistent if it could be determined that no such records were published for that domain name. The original pre-standardization version of this protocol included a mandatory check of this nature. It was ultimately removed, as the method's error rate was too high without substantial manual tuning and heuristic work. There are indeed use cases this work needs to address where such a method would return a negative result about a domain for which reporting is desired, such as a registered domain name that never sends legitimate mail and thus has none of these records present in the DNS. Best Ale -- From nobody Sun Jul 21 09:53: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 E863712026F for ; Sun, 21 Jul 2019 09:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=srHzYKPk; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Zkeyj8mr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLZkiUCdKjSJ for ; Sun, 21 Jul 2019 09:53:38 -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 BFA25120229 for ; Sun, 21 Jul 2019 09:53:37 -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 D1BBCF80721; Sun, 21 Jul 2019 12:53:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563728016; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=51OaT/oOQM/+eAZL8MjzpWPPcBqKkQJqF1PfGpxWcLM=; b=srHzYKPkMnLrqaRHgsAjL5WuqiOfU+UUwlz0gkqOa5fze01fPXAPpD9C 4EAAE5S+pUtezJJlIfvNH4Ew01RMDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563728016; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=51OaT/oOQM/+eAZL8MjzpWPPcBqKkQJqF1PfGpxWcLM=; b=Zkeyj8mrCeg14C7Wv5CRFyNm3AFnJKjYMK8eqFJ4NTv6EpHReWuzCpC9 JSPclcfd2Srxc4Gf53qc6yeWqDkDNfz1ppN+Sba2Y9095gtzwiwX8vVAqS LBBxd1DPEXBfe6NKZgiw1kZEHsF0ffrpc8jmp9eEJWo1J8hJyv6zyK6lK1 apanrFNQYwI67upKiQgPuitFkvVa7tEXTWAIIYpiwcmfvz0W/QUHDHZ3PJ xUTuW4SSUYpZGLc1Gm4jB5sZMlzYWu7fS9r8vOpsSfg1rqFea2cxwQcsEZ pUrEyd2pjv0JuazKIQLCjdA4Ee+7niyE6gBpgpDqQpNi59weXkg8uw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 9526FF804B2; Sun, 21 Jul 2019 12:53:36 -0400 (EDT) Date: Sun, 21 Jul 2019 16:53:35 +0000 In-Reply-To: <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@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: <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 21 Jul 2019 16:53:41 -0000 On July 21, 2019 4:40:49 PM UTC, Alessandro Vesely wrot= e: >On Wed 17/Jul/2019 08:26:25 +0200 Scott Kitterman wrote: > >> Keep in mind that senders do send from what we call non-existent >domains for >> reasons that seem good and sufficient to them=2E Let's take that as a >fact, >> whether it makes sense to us or not=2E > > >Fair enough=2E Let me quote the current spec: > >A=2E4=2E Domain Existence Test > > A common practice among MTA operators, and indeed one documented in > [ADSP], is a test to determine domain existence prior to any more > expensive processing=2E This is typically done by querying the DNS for > MX, A, or AAAA resource records for the name being evaluated and > assuming that the domain is nonexistent if it could be determined > that no such records were published for that domain name=2E > > The original pre-standardization version of this protocol included a > mandatory check of this nature=2E It was ultimately removed, as the > method's error rate was too high without substantial manual tuning > and heuristic work=2E There are indeed use cases this work needs to > address where such a method would return a negative result about a > domain for which reporting is desired, such as a registered domain > name that never sends legitimate mail and thus has none of these > records present in the DNS=2E Yes, but that was for a different use case=2E It was , AIUI, considered t= hat reporting could be skipped on such 'non-existant' domains, but that pro= ved problematic since such domains as these are used in mail=2E 'np' doesn't have the same issue=2E It uses non-existence in a positive (= do some processing) not a negative sense (reporting can be skipped for thes= e), so the problems described in that paragraph are not only not relevant, = the paragraph supports the case for 'np'=2E Scott K From nobody Sun Jul 21 11:01: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 DDB9E120165 for ; Sun, 21 Jul 2019 11:01:09 -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 RZisUq_hP5ab for ; Sun, 21 Jul 2019 11:01: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 33FE412015F for ; Sun, 21 Jul 2019 11:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1563732065; bh=N2ooXE3O2U0lMqaPelTweF+AbiQvGNjFW9GeLAH1jUw=; l=2184; h=To:References:From:Date:In-Reply-To; b=A/hxfR8SB/GFQa/7UJFmIC3ECMm91M+ZqdF44ysFvVWpllZHYsA1Uw+iqfOW9dKzp sXE/1BM49eM0ReUp3w4HSoC6hbz5Ns5fd7ZoqT3vAoOICuuvxYDM0878GpUBpWsHt9 s+qtEIPM74QkEhSbcUTZMEDDsBlC9obIgN1VJilVyqA/WG9F5k9Tx80HYAggc 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 00000000005DC07B.000000005D34A861.0000666B; Sun, 21 Jul 2019 20:01:05 +0200 To: dmarc@ietf.org References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <855283a4-ece7-019b-f075-04eee82b0614@tana.it> Date: Sun, 21 Jul 2019 20:01: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: <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 21 Jul 2019 18:01:10 -0000 On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote: >> >>> Keep in mind that senders do send from what we call non-existent domains for >>> reasons that seem good and sufficient to them. Let's take that as a fact, >>> whether it makes sense to us or not. >> >> >> Fair enough. Let me quote the current spec: >> >> A.4. Domain Existence Test >> >> A common practice among MTA operators, and indeed one documented in >> [ADSP], is a test to determine domain existence prior to any more >> expensive processing. This is typically done by querying the DNS for >> MX, A, or AAAA resource records for the name being evaluated and >> assuming that the domain is nonexistent if it could be determined >> that no such records were published for that domain name. >> >> The original pre-standardization version of this protocol included a >> mandatory check of this nature. It was ultimately removed, as the >> method's error rate was too high without substantial manual tuning >> and heuristic work. There are indeed use cases this work needs to >> address where such a method would return a negative result about a >> domain for which reporting is desired, such as a registered domain >> name that never sends legitimate mail and thus has none of these >> records present in the DNS. > > Yes, but that was for a different use case. It was , AIUI, considered that > reporting could be skipped on such 'non-existant' domains, but that proved > problematic since such domains as these are used in mail. Wasn't it for rejecting non-existent domains? That is, IIRC, as if there were a root DMARC record (_dmarc.) with np=reject. > 'np' doesn't have the same issue. It uses non-existence in a positive (do > some processing) not a negative sense (reporting can be skipped for these), > so the problems described in that paragraph are not only not relevant, the > paragraph supports the case for 'np'. Uh? (I don't understand your parenthesized phrase...) At any rate, the first paragraph gives a definition of non-existence equal to the one we've been discussing these days, doesn't it? Best Ale -- From nobody Sun Jul 21 12:42:35 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 BF5F4120110 for ; Sun, 21 Jul 2019 12:42:34 -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=QlePSHzt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=bQ1lvJqx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvJZmNlGC8x7 for ; Sun, 21 Jul 2019 12:42:32 -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 EF0CE1200CE for ; Sun, 21 Jul 2019 12:42:31 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id C6F34F80721; Sun, 21 Jul 2019 15:42:00 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563738120; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=MeyEid982M8p9udna0INjQR2tBtwyyMVXVlZy8dWdqI=; b=QlePSHzt6fNk0KnkgyJLG6eFCiXA+uG9kXE6/bxza3fVa/314/Y0c4ka 2PCnY6tH/YlA44lbz7fEgiJLZ1cAAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563738120; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=MeyEid982M8p9udna0INjQR2tBtwyyMVXVlZy8dWdqI=; b=bQ1lvJqxBHwY/CuTVdZ/lgO2l5bNt271mXt4rb0mh/I8fNHZuUl/7Yjj agJR0h9Q/+Du/0GjWq7Hngti0tCLa62rHzmZEGCbCfncP0mQKomRCLVSwE 9k/Um5H5jF6qGacRoReXTF1K/JVoGW+1H1tm83BOmBllzWoPVq53DhGpfZ 7j5W1jDdZ9i/3bPrSAARhM21d4lDwSoixq3OtbUyXPMl3xNg4KuRYyF7vC /wC49u8VV0uE3quLEpqClOho/r3HG7RXX2HjmrbcxSDlW8u9SkT5NgygVv 6fqCGq6k7YWh5sD3vuzACUs/MiOTsRO4PdPZy/RrQGQjC4OHG+pEGA== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 93178F804B2; Sun, 21 Jul 2019 15:42:00 -0400 (EDT) Date: Sun, 21 Jul 2019 19:41:59 +0000 In-Reply-To: <855283a4-ece7-019b-f075-04eee82b0614@tana.it> References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <5949BCE3-52DA-41D0-8DCA-E2D06973F798@kitterman.com> <855283a4-ece7-019b-f075-04eee82b0614@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: 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, 21 Jul 2019 19:42:35 -0000 On July 21, 2019 6:01:05 PM UTC, Alessandro Vesely wrot= e: >On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote: >>> >>>> Keep in mind that senders do send from what we call non-existent >domains for >>>> reasons that seem good and sufficient to them=2E Let's take that as >a fact, >>>> whether it makes sense to us or not=2E >>> >>> >>> Fair enough=2E Let me quote the current spec: >>> >>> A=2E4=2E Domain Existence Test >>> >>> A common practice among MTA operators, and indeed one documented >in >>> [ADSP], is a test to determine domain existence prior to any more >>> expensive processing=2E This is typically done by querying the DNS >for >>> MX, A, or AAAA resource records for the name being evaluated and >>> assuming that the domain is nonexistent if it could be determined >>> that no such records were published for that domain name=2E >>> >>> The original pre-standardization version of this protocol included >a >>> mandatory check of this nature=2E It was ultimately removed, as the >>> method's error rate was too high without substantial manual tuning >>> and heuristic work=2E There are indeed use cases this work needs to >>> address where such a method would return a negative result about a >>> domain for which reporting is desired, such as a registered domain >>> name that never sends legitimate mail and thus has none of these >>> records present in the DNS=2E >>=20 >> Yes, but that was for a different use case=2E It was , AIUI, >considered that >> reporting could be skipped on such 'non-existant' domains, but that >proved >> problematic since such domains as these are used in mail=2E > >Wasn't it for rejecting non-existent domains? That is, IIRC, > >as if there were a root DMARC record (_dmarc=2E) with >np=3Dreject=2E I think no=2E I think it was about skipping reporting on 'non-existant' d= omains=2E Perhaps someone who was more involved at that point can clarify= =2E >> 'np' doesn't have the same issue=2E It uses non-existence in a >positive (do >> some processing) not a negative sense (reporting can be skipped for >these), >> so the problems described in that paragraph are not only not >relevant, the >> paragraph supports the case for 'np'=2E > > >Uh? (I don't understand your parenthesized phrase=2E=2E=2E) > > >At any rate, the first paragraph gives a definition of non-existence >equal to >the one we've been discussing these days, doesn't it? > Yes, but since we're using it for a different, opt-in, purpose, the cautio= n doesn't apply=2E Scott K From btv1==1063ccfea48==fosterd@bayviewphysicians.com Sun Jul 21 21:31: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 2C11E1201B4 for ; Sun, 21 Jul 2019 21:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.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 LnFB6rI14stS for ; Sun, 21 Jul 2019 21:31:50 -0700 (PDT) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C61120186 for ; Sun, 21 Jul 2019 21:31:50 -0700 (PDT) X-ASG-Debug-ID: 1563769908-11fa3101dd2fcbe0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id t1lMJHiyEOVi9B33 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 00:31:48 -0400 (EDT) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-ASG-Whitelist: Client X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=/fiWL8GR5wdZ5qYr/mzyEXQVCTWfi2BhBEik/X42n5c=; b=gm1r7L2k3O3G2jtofZ0gb2/y1TgZF7uqPlkfY0JQNMZddwYUTOdVSGiNBO31rk1p9 X9NVjGrUwvGk9etNerpckznXAHpH8mLsE23STNaR7fiOsbTr3d0pFEQ+USYOzYUl1 WK4gpRpxbsZzFF0PBjcLPq1+rG1cxJ8yDaI2bjiBg= Received: by webmail.bayviewphysicians.com via HTTP; Mon, 22 Jul 2019 00:31:40 -0400 From: "Douglas E. Foster" To: , "Alessandro Vesely" Date: Mon, 22 Jul 2019 00:31:40 -0400 X-ASG-Orig-Subj: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: draft-ietf-dmarc-psd Reply-To: fosterd@bayviewphysicians.com Message-ID: <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=0da137096a8a416aa2e413e6162d3b65 X-Originating-IP: [192.168.72.10] In-Reply-To: <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> X-Exim-Id: 83f0b1ffbf0c466eb3bc66e3510738f0 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1563769908 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 3610 X-Barracuda-BRTS-Status: 1 Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: 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, 22 Jul 2019 10:30:58 -0000 This is a multipart message in MIME format. --0da137096a8a416aa2e413e6162d3b65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit About this paragraph: >> The original pre-standardization version of this protocol included a >> mandatory check of this nature. It was ultimately removed, as the >> method's error rate was too high without substantial manual tuning >> and heuristic work. There are indeed use cases this work needs to >> address where such a method would return a negative result about a >> domain for which reporting is desired, such as a registered domain >> name that never sends legitimate mail and thus has none of these >> records present in the DNS. This section seems to give a free pass to senders who use non-existent domains, as if such behavior had no impact on the risk posture of the recipient. It seems to say, "You can keep doing this, because so is everyone else." I would think better language would be along the following lines: "Senders SHOULD register all domains in DNS, as MTA operators MAY block messages that appear to come from non-existent domains. Developers of MTA filtering software SHOULD provide MTA operators with the ability to block non-existent domains. If such ability is provided, the MTA filtering system MUST provide a mechanism for overriding the filter rule for messages that are acceptable to the recipient organization." In short, the evaluation of whether manual tuning is worthwhile should be left to the discretion of the MTA operator, based on his organization's risk tolerance and message characteristics. --0da137096a8a416aa2e413e6162d3b65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
About this paragraph:
 
>> The original pre-standardization version of this protoco= l included a
>> mandatory check of this nature. It was ultimately removed, as= the
>> method's error rate was too high without substantial manual t= uning
>> and heuristic work. There are indeed use cases this work need= s to
>> address where such a method would return a negative result ab= out a
>> domain for which reporting is desired, such as a registered d= omain
>> name that never sends legitimate mail and thus has none of th= ese
>> records present in the DNS.
 
This section seems to give a free pass to senders who use non-exi= stent domains, as if such behavior had no impact on the risk posture o= f the recipient. 
It seems to say, "You can keep doing this, because so is everyone= else."
 
I would think better language would be along the following lines:
 
"Senders SHOULD register all domains in DNS, as MTA operators MAY=  block messages that appear to come from non-existent domains.
Developers of MTA filtering software SHOULD provide MTA operators= with the ability to block non-existent domains.
If such ability is provided, the MTA filtering system MUST provide a m= echanism for overriding the filter rule for messages that are acceptab= le to the recipient organization."
 
In short, the evaluation of whether manual tuning is worthwhile should= be left to the discretion of the MTA operator, based on his organization's= risk tolerance and message characteristics.
 
 
--0da137096a8a416aa2e413e6162d3b65-- From nobody Mon Jul 22 03:44:23 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 C53F212023C for ; Mon, 22 Jul 2019 03:44:22 -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=gcZ4VTnR; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mAgkWx7A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttRBOoaIWRwP for ; Mon, 22 Jul 2019 03:44:20 -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 34A4F120220 for ; Mon, 22 Jul 2019 03:44:20 -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 3F229F80698; Mon, 22 Jul 2019 06:43:49 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563792229; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=aQJknw78ZRY/7B4nF8a+fTS5USsCsWS1nU6w4TFq3o4=; b=gcZ4VTnRohdiGtp1HKvWkxrGwErMphkmXwNWxqHSK4UNXHGfATRRtcdq SnlQdOflsPyaCRViiVeldwwtM+4kAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563792229; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=aQJknw78ZRY/7B4nF8a+fTS5USsCsWS1nU6w4TFq3o4=; b=mAgkWx7Aey8MMqYJjX9BMGAeoLzwItQMrXmbDz3Aq/jMHhtYl+whxpND S+HoOVQEQNAEjUw3/fAW/XChq2Sb4zvrx6BabtSnQSZ4t1Nc4txYVvKeHQ mU7XWS8HjUJuRFSD+HRpehXhr73xttCvs15vSmcRGijhHOQt3dcxHP53/+ 5dDUeKCxyYzw5X4mIviCB7ukXPLB3psd4MaZ+qpXdYGT8AD35c4kKJ+5PI kWNbAx+NlAndG7yLO/UDSS3g9c2XZvykA4+LXkjRzNMfByx54SAPLNrSrp IrgzvnpxhDDnSULPpBNgB8SpY6/hdNRLO15JaE1b5AFYy+ZQUSu3bg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 0F8A5F80618; Mon, 22 Jul 2019 06:43:49 -0400 (EDT) Date: Mon, 22 Jul 2019 10:43:47 +0000 In-Reply-To: <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.com> References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.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: <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: 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, 22 Jul 2019 10:44:23 -0000 On July 22, 2019 4:31:40 AM UTC, "Douglas E=2E Foster" wrote: >About this paragraph: > =20 >>> The original pre-standardization version of this protocol included a > >> mandatory check of this nature=2E It was ultimately removed, as the >>> method's error rate was too high without substantial manual tuning >>> and heuristic work=2E There are indeed use cases this work needs to >>> address where such a method would return a negative result about a >>> domain for which reporting is desired, such as a registered domain >>> name that never sends legitimate mail and thus has none of these >>> records present in the DNS=2E > =20 >This section seems to give a free pass to senders who use non-existent=20 >domains, as if such behavior had no impact on the risk posture of the=20 >recipient=2E=20 >It seems to say, "You can keep doing this, because so is everyone >else=2E" > =20 > I would think better language would be along the following lines: > > =20 > >"Senders SHOULD register all domains in DNS, as MTA operators MAY block > >messages that appear to come from non-existent domains=2E >Developers of MTA filtering software SHOULD provide MTA operators with >the=20 >ability to block non-existent domains=2E > If such ability is provided, the MTA filtering system MUST provide a=20 >mechanism for overriding the filter rule for messages that are >acceptable=20 >to the recipient organization=2E" > =20 >In short, the evaluation of whether manual tuning is worthwhile should >be=20 >left to the discretion of the MTA operator, based on his organization's >risk tolerance and message characteristics=2E I think that it is well outside the scope of this document to impose such = a requirement=2E Scott K From nobody Mon Jul 22 04:45: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 1B75E120233 for ; Mon, 22 Jul 2019 04:45:46 -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 qvCMuD9G_JKw for ; Mon, 22 Jul 2019 04:45:43 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 9312512006F for ; Mon, 22 Jul 2019 04:45:43 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id l2so34996040wmg.0 for ; Mon, 22 Jul 2019 04:45:43 -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=YKM+9vspnp4ZBLi1yVVOpD9oRbQ2Ahnrp4OB+A3oUNI=; b=D6Z2D9s+oTNcasvE7WILnShYUSUU7psEpavw/kg4FiaIht5G+EoVQX6q71ZheEzZKg D0YOeWNgn5FR3A8hsH81+ny9wBIdBrjfLVOJTPNIoFtIoaD06tPZRinJVTrm1Y2tG1fQ 8WIhmWW+TZAKygdx4b+rDm2s8L7hlXQFuY+MR6JPxfk7up5j1z+YFHwN/ltj7LLBVLBj 0tFCv1O8H29jj7HjkEEa7kA4mbh22McUt5ZB1M7eboD3mPRmpS2wjkUb0+4ESq8KBni/ NcnwXa8Ud+pJCqfVciUDeai4O0iLj7W+E5Fx9TF5DXiYtcwI9InqB2DpeNAY/bC9XSS7 H6qA== 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=YKM+9vspnp4ZBLi1yVVOpD9oRbQ2Ahnrp4OB+A3oUNI=; b=p5V6243zgvzPReT0uoz9qrbOtcsLsfF1W2NDlhyYIVBnDE3am4iys2QE8ul36yOSrl M2ImqqeLldHnnG9SrUXdqIJTZI9mfGxNPeZMlrAa/ZfBoz4xXxjRxC2hOfJoG7vWGdl6 leMk3cXroM1kpELiyBoVAN1moxqTd6U7uV6X+zxIFMyzo6VepGw1Mq1/usrFfCb3ogTh hWaK/ey2K86llQqUvSgMrOv+QDosMaxLqvn1mGX+dBZrtktGsoVr1+xQb3LB6s4sdrEr xNgBj+yda5OjKla3Rn6NN9RGXdcXAEYFPlCCNyI649Yl73+68hM5YbSW3tBgWrGo7esQ 7L2g== X-Gm-Message-State: APjAAAWW0CHBnvx8wBQHcQApSmXcbI48F64dxn9ZOFK39WxGSEl+GhdF bFSgCswZ3mksyOJ1JE6NJ97TD1ziHcr2mRv2wEoJOw== X-Google-Smtp-Source: APXvYqwoVTfb/y/tiGycC1AoJ8qyp1rav6eU3Mvi6K39rd5UZh/twx0SEzT4+kPTMEtI/Q0PVR92mcgNG/1lurfw/T8= X-Received: by 2002:a1c:35c2:: with SMTP id c185mr62614505wma.58.1563795942064; Mon, 22 Jul 2019 04:45:42 -0700 (PDT) MIME-Version: 1.0 References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.com> <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com> In-Reply-To: <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com> From: Dotzero Date: Mon, 22 Jul 2019 07:45:31 -0400 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a0c6a8058e439de0" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: 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, 22 Jul 2019 11:45:46 -0000 --000000000000a0c6a8058e439de0 Content-Type: text/plain; charset="UTF-8" +1 on Scott's comment. Michael Hammer On Mon, Jul 22, 2019 at 6:44 AM Scott Kitterman wrote: > > > On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" < > fosterd@bayviewphysicians.com> wrote: > >About this paragraph: > > > >>> The original pre-standardization version of this protocol included a > > >> mandatory check of this nature. It was ultimately removed, as the > >>> method's error rate was too high without substantial manual tuning > >>> and heuristic work. There are indeed use cases this work needs to > >>> address where such a method would return a negative result about a > >>> domain for which reporting is desired, such as a registered domain > >>> name that never sends legitimate mail and thus has none of these > >>> records present in the DNS. > > > >This section seems to give a free pass to senders who use non-existent > >domains, as if such behavior had no impact on the risk posture of the > >recipient. > >It seems to say, "You can keep doing this, because so is everyone > >else." > > > > I would think better language would be along the following lines: > > > > > > > >"Senders SHOULD register all domains in DNS, as MTA operators MAY block > > > >messages that appear to come from non-existent domains. > >Developers of MTA filtering software SHOULD provide MTA operators with > >the > >ability to block non-existent domains. > > If such ability is provided, the MTA filtering system MUST provide a > >mechanism for overriding the filter rule for messages that are > >acceptable > >to the recipient organization." > > > >In short, the evaluation of whether manual tuning is worthwhile should > >be > >left to the discretion of the MTA operator, based on his organization's > >risk tolerance and message characteristics. > > I think that it is well outside the scope of this document to impose such > a requirement. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000a0c6a8058e439de0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on Scott's comment.

M= ichael Hammer

On Mon, Jul 22, 2019 at 6:44 AM Scott Kitterman <sklist@kitterman.com> wrote:
=


On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <fosterd@bayview= physicians.com> wrote:
>About this paragraph:
>=C2=A0
>>> The original pre-standardization version of this protocol incl= uded a
>=C2=A0 >> mandatory check of this nature. It was ultimately remov= ed, as the
>>> method's error rate was too high without substantial manua= l tuning
>>> and heuristic work. There are indeed use cases this work needs= to
>>> address where such a method would return a negative result abo= ut a
>>> domain for which reporting is desired, such as a registered do= main
>>> name that never sends legitimate mail and thus has none of the= se
>>> records present in the DNS.
>=C2=A0
>This section seems to give a free pass to senders who use non-existent =
>domains, as if such behavior had no impact on the risk posture of the <= br> >recipient.
>It seems to say, "You can keep doing this, because so is everyone<= br> >else."
>=C2=A0
> I would think better language would be along the following lines:
>
>=C2=A0
>
>"Senders SHOULD register all domains in DNS, as MTA operators MAY = block
>
>messages that appear to come from non-existent domains.
>Developers of MTA filtering software SHOULD provide MTA operators with<= br> >the
>ability to block non-existent domains.
> If such ability is provided, the MTA filtering system MUST provide a <= br> >mechanism for overriding the filter rule for messages that are
>acceptable
>to the recipient organization."
>=C2=A0
>In short, the evaluation of whether manual tuning is worthwhile should<= br> >be
>left to the discretion of the MTA operator, based on his organization&#= 39;s
>risk tolerance and message characteristics.

I think that it is well outside the scope of this document to impose such a= requirement.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000a0c6a8058e439de0-- From nobody Mon Jul 22 07:35:49 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 B976E120314 for ; Mon, 22 Jul 2019 07:35:35 -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=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dR99eU27GyQ for ; Mon, 22 Jul 2019 07:35:32 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8BA120328 for ; Mon, 22 Jul 2019 07:35:28 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q22so74380949iog.4 for ; Mon, 22 Jul 2019 07:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+rIWRC5w4xyUhWXXDkBjp9ssJqNoJ/PQfM7fsp5yBx8=; b=SX2O840AkBgE1Hp5v//acg6vyjSQqaUr7fDZrFUQsVa11qnQWs96pQ5rni/0//Cljb nNl7LAyNwljUdT6bTFnNW1ykSSYkYctm85U4OYRsUtaW8kXG+NGVPciuwAbuzGmjiIaQ Vkf3VZRnqnLWE6j63SPjAD3YDkuO1eJwhH0UY= 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=+rIWRC5w4xyUhWXXDkBjp9ssJqNoJ/PQfM7fsp5yBx8=; b=HPpGRySX7pDM4ryYwU2sRXHl/MJ52zw1V8FJBOFuu3MLXOHJ1gKoHwwbPJ/E72nxEP lH8ZKqKZYKHMhbYIcoHfacBMwfOPPN2ZaMlRRdii8G5OVhiKw8QLSiPXBuF4Wg4/3irq d5zHxwzku1CbiTZwUDof9GSeNGM4z1FwpTYnSirHrZDrU3eLuXRaIwQaWbocdWRnRv6o epvHQy4UX2BJo4oHZZkIIGPg2g/RNkLhfS8o2lrCfh+DLeC3gNjFmScDWyXigrTbkDMW HEJizYBI3XmC6SGmRBfw20t1eDZ3DbU/5/rHi5RLSk1x/bE8FAnImVj+UMjhFBBjB7Us 708w== X-Gm-Message-State: APjAAAWixtn71jRAzKKot/wR4I8EqZylaBcbl+jspMJC7DrF/wuc/8YV wouND9KO3+Sad7HyKyEfrP5KE5/WV9tLjEMBqKpXtjsQWqE= X-Google-Smtp-Source: APXvYqxri92Pj1Mks7+vAImDFyraK5eFh3giyvF2B9bjJWMOEkXUlAQfQErySsDILlXs8ef56Olyf4p/a7eNI8wd050= X-Received: by 2002:a6b:5b01:: with SMTP id v1mr61462192ioh.120.1563806127684; Mon, 22 Jul 2019 07:35:27 -0700 (PDT) MIME-Version: 1.0 References: <1808303.aIhlromXIS@l5580> <1692123.ljdY5SVR4M@l5580> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.com> <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com> In-Reply-To: <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com> From: Kurt Andersen Date: Mon, 22 Jul 2019 08:35:15 -0600 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd13d1058e45fc31" Archived-At: Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast Call: 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, 22 Jul 2019 14:35:36 -0000 --000000000000bd13d1058e45fc31 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 22, 2019, 04:44 Scott Kitterman wrote: > > On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" < > fosterd@bayviewphysicians.com> wrote: > > >"Senders SHOULD register all domains in DNS, as MTA operators MAY block... > > I think that it is well outside the scope of this document to impose such > a requirement. > > Scott K Agreed --Kurt --000000000000bd13d1058e45fc31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2019, 04:44 Scott Kitterm= an <sklist@kit= terman.com> wrote:

On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <fosterd@bayviewphysicians.com> wrote:

>"Senders SHOULD register all domains in DNS, as MTA operators MAY = block...

I think that it is well outside the scope of this document to impose such a= requirement.

Scott=C2=A0 K

Agreed

--Kurt=C2=A0
--000000000000bd13d1058e45fc31-- From nobody Mon Jul 22 09:23: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 AE997120168 for ; Mon, 22 Jul 2019 09:23:36 -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 zM4x4OPtHnMu for ; Mon, 22 Jul 2019 09:23:31 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03E4120052 for ; Mon, 22 Jul 2019 09:23:30 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id k18so38191918ljc.11 for ; Mon, 22 Jul 2019 09:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v4VCQgyXnY6cLCiAsv51jY9yX9+tFktpfXdhSkQ0Hpw=; b=NajjXtRgAnDoVp+wWz7haL82Wb5vWHE8sh3mmDW/Xs6U6zaXda5L6HXeBLBQ3BGCaB pACxVXVK32W+BF7i9+IA2xLUhg9dyN6/jJGAMf3fl27rofCqIyI/JLvjrbNrHKii+gbC FGHkdNJcvDLNlrNyU7DfNlB2Q7Hcf0e/jTdVXkdkDJE/4d+X3L9mI3DC64i8VUAT84yv 59HpHbK9nOqg+EWEHP8R3U4Pp0yV/qf5b/BouR3AviQqbvV5VX8jsAV8H9f1Nw7Gpe+l cfFSeCHr7XQWLeduz1J6S9Nkb3BSb6wFM+J+W0angeij9iSmdbvzqC4yiblTqgpSx0aJ ToHw== 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=v4VCQgyXnY6cLCiAsv51jY9yX9+tFktpfXdhSkQ0Hpw=; b=QVOPzF1g+uyk63CmJ3Xf3HNlax9MxS1RQkoDAbVUS2o7jn7YS7glpb8ReNMIizaA/4 lzoHVZpbZ+XEnA9JbzNznaXyV1sq0on26ZOpsMD1J9qRBaFRy1RSC5/HiTlEYm7YkoZ+ lKPMoTY3DX7o4zLNPR5HGUddd46At5WdhXmpXBJlordZSLiu3yBRC/sc9nCWmfKNNi2r g0w8LG7lEyFDkydnfVIJdD884AyjQa7OPdN5xYZ4JsdzdMfle7LdBEaGESdkr2QUBIOI mCqoHWQJZsgJoyfHEZsyrgzKChz/HrIdGEVEWhNBW3kig3XSyJkhquRat8FdAO1pFmFp 3hww== X-Gm-Message-State: APjAAAWBQHr3sTK5ZnHScH5/hIYuofb4w22Pu8ETP3VUdhbpOv9sLOck wxvuySeOA54taRtIl7saqze+1uwGhKwHSmITQjMvE+YQi/5KbA== X-Google-Smtp-Source: APXvYqwn5bsWhuxntpl5hTvRRPH8T4Sq42WBGBTF0Uk6NiLYOaOy/MshFjalayodZqEndrEzFoJv7lKgHAzxqrLep/o= X-Received: by 2002:a2e:870f:: with SMTP id m15mr37015341lji.223.1563812608334; Mon, 22 Jul 2019 09:23:28 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Mon, 22 Jul 2019 09:23:15 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000003df6d058e477fa0" Archived-At: Subject: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 22 Jul 2019 16:23:37 -0000 --00000000000003df6d058e477fa0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reviewing as the document shepherd: Abstract [...] organization can use to improve mail handling. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level. I think the abstract is a bit too abstract. Which set of domains? The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). Is that the same set? These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). What "types" are there? For the subset of PSDs that require DMARC usage, this memo describes an extension to DMARC to enable DMARC functionality for such domains. What's the requirement? 1. Introduction DMARC [RFC7489] provides a mechanism for publishing organizational policy information to email receivers. DMARC [RFC7489] allows policy to be specified for both individual domains and sets of domains Which sets? within a single organization. For domains above the organizational level in the DNS tree, policy can only be published for the exact domain. There is no method available to such domains to express lower level policy or receive feedback reporting for sets of domains. Still too abstract. I don't know what sort of set groupings you might be after here. This prevents policy application to non-existent domains and identification of domain abuse in email, which can be important for brand and consumer protection. As an example, imagine a country code TLD (ccTLD) which has public subdomains for government and commercial use (.gov.example and .com.example). Within the .gov.example public suffix, use of DMARC [RFC7489] has been mandated and .gov.example has published its own DMARC [RFC7489] record: "v=3DDMARC1;p=3Dreject;rua=3Dmailto:dmarc@dmarc.service.gov.example" Can we add spaces after the semicolons? I know this is legal format but it would be more readable. This memo provides a simple extension to DMARC [RFC7489] to allow s/memo/document/g operators of Public Suffix Domains (PSDs) to express policy for groups of subdomains, extends the DMARC [RFC7489] policy query "groups of subdomains" suggests the capability of creating a policy that applies to parts of the subtree only, or different policies for different parts of the subtree. If that's not what we're actually defining here, this should be reworded. As an additional benefit, the PSD DMARC extension will clarify s/will clarify/clarifies/ existing requirements. Based on the requirements of DMARC [RFC7489], DMARC should function above the organizational level for exact domain matches (i.e. if a DMARC record were published for 'example', then mail from example@example should be subject to DMARC processing). Testing had revealed that this is not consistently applied in different implementations. PSD DMARC will help clarify that DMARC is s/will help clarify/clarifies/ ...and saying it twice in the same paragraph is probably not necessary. not limited to organizational domains and their sub-domains. There are two types of Public Suffix Operators (PSOs) for which this extension would be useful and appropriate: o Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in DMARC [RFC7489]. They control all subdomains of the tree. These are effectively private domains, but listed in the Public Suffix List. They are treated as Public for DMARC [RFC7489] purposes. They require the same protections as DMARC [RFC7489] Organizational Domains, but are currently excluded. How are they current excluded? Is this because they're on the PSL, so DMARC treats them differently? o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): Because existing Organizational Domains using this PSD have their own DMARC policy, the applicability of this extension is for non- existent domains. The extension allows the brand protection benefits of DMARC [RFC7489] to extend to the entire PSD, including cousin domains of registered organizations. An example would be useful here. Due to the design of DMARC [RFC7489] and the nature of the Internet email architecture [RFC5598], there are interoperability issues associated with DMARC [RFC7489] deployment. These are discussed in Interoperability Issues between DMARC and Indirect Email Flows [RFC7960]. These issues are not applicable to PSDs, since they (e.g., the ".gov.example" used above) do not send mail. DMARC doesn't need to be followed by its RFC number every time. 2.2. Public Suffix Domain (PSD) The global Internet Domain Name System (DNS) is documented in numerous Requests for Comment (RFC). It defines a tree of names starting with root, ".", immediately below which are Top Level Domain names such as ".com" and ".us". They are not available for private registration. In many cases the public portion of the DNS tree is more than one level deep. PSD DMARC includes all public domains above the organizational level in the tree, e.g., ".gov.uk". I don't know what that last sentence means. PSD DMARC is an extension; how does it include domains? 2.4. Public Suffix Operator (PSO) A Public Suffix Operator manages operations within their PSD. s/their/its/; "operator" is singular. 2.6. Non-existent Domains For DMARC [RFC7489] purposes, a non-existent domain is a domain name that publishes none of A, AAAA, or MX records that the receiver is willing to accept. This is a broader definition than that in NXDOMAIN [RFC8020]. Is there any discussion that could be referenced about DNS RRs that one is not willing to accept? 3.2. Section 6.1 DMARC Policy Record PSD DMARC records are published as a subdomain of the PSD. For the PSD ".example", the PSO would post DMARC policy in a TXT record at "_dmarc.example". Don't you mean the PSD DMARC record is a record in the zone of the PSD? It's not a subdomain. 3.3. Section 6.5. Domain Owner Actions In addition to the DMARC [RFC7489] domain owner actions, PSOs that require use of DMARC ought to make that information available to receivers. By what mechanism? 3.4. Section 6.6.3. Policy Discovery A new step between step 3 and 4 is added: 3A. If the set is now empty and the longest PSD (Section 2.3) of the Organizational Domain is one that the receiver has determined is acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the longest PSD (Section 2.3) in place of the RFC5322.From domain in the message (if different). A possibly empty set of records is returned. Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I don't know what "acceptable for PSD DMARC" might mean. Section numbers in the prose of this section should make clear which document they're referencing. 3.5. Section 7. DMARC Feedback Operational note for PSD DMARC: For PSOs, feedback for non-existent domains is desired and useful. See Section 4 for discussion of Privacy Considerations. Section 4 of which document? 4. Privacy Considerations These privacy considerations are developed based on the requiremetns typo of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this document. 4.1. Feedback leakage Providing feedback reporting to PSOs can, in some cases, create leakage of information outside of an organization to the PSO. This leakage could be potentially be utilized as part of a program of Remove one of the "be"s. pervasive surveillance (See [RFC7624]). There are roughly three cases to consider: o Single Organization PSDs (e.g., ".google"), RUA and RUF reports based on PSD DMARC have the potential to contain information about emails related to entities managed by the organization. Since both the PSO and the Organizational Domain owners are common, there is no additional privacy risk for either normal or non- existent Domain reporting due to PSD DMARC. o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): PSD DMARC based reports will only be generated for domains that do not publish a DMARC policy at the organizational or host level. For domains that do publish the required DMARC policy records, the feedback reporting addresses (RUA and RUF) of the organization (or hosts) will be used. The only direct feedback leakage risk for these PSDs are for Organizational Domains that are out of compliance with PSD policy. Data on non-existent cousin domains would be sent to the PSO. This is the second use of "cousin domain". An example here or at the first use might be a good idea. o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the Organizational Domain level) vice opt-in, which would be the more desirable characteristic. This means that any non-DMARC organizational domain would have it's feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive. PSOs will receive feedback on non-existent domains, which may be similar to existing Organizational Domains. Feedback related to such cousin domains have a small risk of carrying information related to an actual Organizational Domain. To minimize this potential concern, PSD DMARC feedback is best limited to Aggregate Reports. Feedback Reports carry more detailed information and present a greater risk. Due to the inherent Privacy and Security risks associated with PSD DMARC for Organizational Domains in multi-organization PSDs that do not particpate in DMARC, any Feedback Reporting related to multi- organizational PSDs ought to be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. 5. Security Considerations This document does not change the Security Considerations of [RFC7489] and [RFC7960]. The risks of the issues identified in [RFC7489], Section 12.5, External Reporting Addresses, are amplified by PSD DMARC. By design, PSD DMARC causes unrequested reporting of feedback to entities external to the Organizational Domain. This is discussed in more detail in Section 4. Kitterman Expires November 28, 2019 [Page 7] =0C Internet-Draft PSD DMARC May 2019 6. IANA Considerations This document does not require any IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [psddmarc.org] multiple, "PSD DMARC Web Site", April 2019, . [PSL] multiple, "Public Suffix List", April 2019, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . Kitterman Expires November 28, 2019 [Page 8] =0C Internet-Draft PSD DMARC May 2019 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, . [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, . [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, . Appendix A. The Experiment To mitigate the privacy concerns associated with Multi-organization PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to indicate which PSDs do not present this privacy risk is appropriate. There are multiple approaches that are possible. The experiment is to evaluate different possible approaches. The experiment will be complete when there is rough consensus on a technical approach that is demonstrated to be operationally usable and effective at mitigating the privacy concern. The mechanism needs the following attributes: o Be reliably, publicly accessible o Be under configuration control based on a public set of criteria o List PSDs that either mandate DMARC for their registrants or for which all lower level domains are controlled by the PSO and that the relevant PSO has indicated a desire for the PSD to participate in PSD DMARC o Have a small operational footprint (e.g. provide a documented, lightweight mechanism for developers and operators to retrieve the list of PSD DMARC participants) o Not allow PSO to add PSDs to the PSD DMARC participants list without third party review Kitterman Expires November 28, 2019 [Page 9] =0C Internet-Draft PSD DMARC May 2019 As of this writing, three approaches have been proposed. None of them are ideal: o An extension to the Public Suffix List at [PSL] o A dedicated registry queried via DNS - an example of such a service is described in Appendix B.1 below o An IANA registry Appendix B. DMARC PSD Registry Examples To faciliate experimentation around data leakage mitigation, samples of the DNS based and IANA like registries are available at [psddmarc.org]. B.1. DMARC PSD DNS Query Service A sample stand-alone DNS query service is available at [psddmarc.org]. It was developed based on the contents suggested for an IANA registry in an earlier revision of this draft. Usage of the service is described on the web site. B.2. DMARC Public Suffix Domain (PSD) Registry [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) Registry as a stand-alone DNS query service. It follows the contents and structure described below. There is a Comma Separated Value (CSV) version of the listed PSD domains which is suitable for use in build updates for PSD DMARC capable software. Names of PSDs participating in PSD DMARC must be registered this new registry. New entries are assigned only for PSDs that require use of DMARC. The requirement has to be documented in a manner that satisfies the terms of Expert Review,per [RFC5226]. The Designated Expert needs to confirm that provided documentation adequately describes PSD policy to require domain owners to use DMARC or that all domain owners are part of a single organization with the PSO. The initial set of entries in this registry is as follows: Kitterman Expires November 28, 2019 [Page 10] =0C Internet-Draft PSD DMARC May 2019 +-------------+---------------+ | PSD | Status | +-------------+---------------+ | .bank | current | +-------------+---------------+ | .insurance | current | +-------------+---------------+ | .gov.uk | current | +-------------+---------------+ Appendix C. Implementation There is one known implementation of PSD DMARC available for testing. C.1. Authheaders Module The authheaders Python module and command line tool is available for download or installation from Pypi (Python Packaging Index). It supports both use of the DNS based query service and download of the CSV registry file from [psddmarc.org]. Acknowledgements Thanks to the following individuals for their contributions (both public and private) to improving this document. Special shout out to Dave Crocker for naming the beast. Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig Schwartz, Alessandro Vesely, and Tim Wicinski Author's Address Scott Kitterman fTLD Registry Services 600 13th Street, NW, Suite 400 Washington, DC 20005 United States of America Phone: +1 301 325-5475 Email: scott@kitterman.com Kitterman Expires November 28, 2019 [Page 11] --00000000000003df6d058e477fa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewing as the document shepherd:
Abstract

[...]
  =C2=A0organization can use to improve mail handling.  DMARC poli=
cies can be
   applied at the individual domain level or for a set of domains at the
   organizational level.

I think the abstract is a bit too abstract.  Which set of domains?

=C2=A0  The design of DMARC precludes grouping
   policies for a set of domains above the organizational level, such as
   TLDs (Top Level Domains).

Is that the same set?

   These types of domains (which =
are not all
   at the top level of the DNS tree) can be collectively referred to as
   Public Suffix Domains (PSDs).

What "types" are there?

  =C2=A0For the s=
ubset of PSDs that require
   DMARC usage, this memo describes an extension to DMARC to enable
   DMARC functionality for such domains.

What's the requirement?

1.  Introductio=
n

   DMARC [RFC7489] provides a mechanism for publishing organizational
   policy information to email receivers.  DMARC [RFC7489] allows policy
   to be specified for both individual domains and sets of domains

<=
/pre>
Which sets?

  =C2=A0within a single organization.  For domains above t=
he organizational
   level in the DNS tree, policy can only be published for the exact
   domain.  There is no method available to such domains to express
   lower level policy or receive feedback reporting for sets of domains.
Still too abstract.  I do=
n't know what sort of set groupings you might be after here.
=

  =C2=A0This prevents policy application to non-existent domains and
   identification of domain abuse in email, which can be important for
   brand and consumer protection.

   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (.gov.example and
   .com.example).  Within the .gov.example public suffix, use of DMARC
   [RFC7489] has been mandated and .gov.example has published its own
   DMARC [RFC7489] record:

   "v=3DDMARC1;p=3Dreject;rua=3Dmailto:dmarc@dmarc.service.gov.example"

Can we add spaces after the semicolo=
ns? I know this is legal format but it would be more readable.

   This memo provides a simple extension to DMARC [RFC7489] to allow
s/memo/document/g
<=
br>  =C2=A0operators of Public Suffix Domains (PSDs) to express policy for
   groups of subdomains, extends the DMARC [RFC7489] policy query
=

"groups of subdomain=
s" suggests the capability of creating a policy that applies to parts =
of the subtree only, or different policies for different parts of the subtr=
ee.  If that's not what we're actually defining here, this should b=
e reworded.

  =C2=A0As an additional benefit, the PSD DMARC e=
xtension will clarify

s/will clarify/clarifies/

  =C2=A0existing requirem=
ents.  Based on the requirements of DMARC [RFC7489],
   DMARC should function above the organizational level for exact domain
   matches (i.e. if a DMARC record were published for 'example', th=
en
   mail from example@example should be subject to DMARC processing).
   Testing had revealed that this is not consistently applied in
   different implementations.  PSD DMARC will help clarify that DMARC is
s/will help clarify/clari=
fies/
...=
and saying it twice in the same paragraph is probably not necessary.

  =C2=A0not limited to organizational domains and their =
sub-domains.

   There are two types of Public Suffix Operators (PSOs) for which this
   extension would be useful and appropriate:

   o  Branded PSDs (e.g., ".google"): These domains are effective=
ly
      Organizational Domains as discussed in DMARC [RFC7489].  They
      control all subdomains of the tree.  These are effectively private
      domains, but listed in the Public Suffix List.  They are treated
      as Public for DMARC [RFC7489] purposes.  They require the same
      protections as DMARC [RFC7489] Organizational Domains, but are
      currently excluded.

How are they current excluded?  Is this because they're on the PSL, =
so DMARC treats them differently?

  =C2=A0o  Multi-organizati=
on PSDs that require DMARC usage (e.g., ".bank"):
      Because existing Organizational Domains using this PSD have their
      own DMARC policy, the applicability of this extension is for non-
      existent domains.  The extension allows the brand protection
      benefits of DMARC [RFC7489] to extend to the entire PSD, including
      cousin domains of registered organizations.
An example would be useful here.
   Due to the design of DMARC [RFC7489] and the nature of the Interne=
t
   email architecture [RFC5598], there are interoperability issues
   associated with DMARC [RFC7489] deployment.  These are discussed in
   Interoperability Issues between DMARC and Indirect Email Flows
   [RFC7960].  These issues are not applicable to PSDs, since they
   (e.g., the ".gov.example" used above) do not send mail.
DMARC doesn't need to be =
followed by its RFC number every time.

2.2.  Public Suffix Domain (PSD)

   The global Internet Domain Name System (DNS) is documented in
   numerous Requests for Comment (RFC).  It defines a tree of names
   starting with root, ".", immediately below which are Top Level=
 Domain
   names such as ".com" and ".us".  They are not availa=
ble for private
   registration.  In many cases the public portion of the DNS tree is
   more than one level deep.  PSD DMARC includes all public domains
   above the organizational level in the tree, e.g., ".gov.uk".
I don't know what that last sentence means.  PSD DMARC is =
an extension; how does it include domains?
=C2=A0
2.4.  Public Suffix Operator (PSO)

   A Public Suffix Operator manages operations within their PSD.

s/their/its/; "operator"=
; is singular.

2.6.  Non-existent Domains

   For DMARC [RFC7489] purposes, a non-existent domain is a domain name
   that publishes none of A, AAAA, or MX records that the receiver is
   willing to accept.  This is a broader definition than that in
   NXDOMAIN [RFC8020].

=
Is there any discussion that could be referenced about DNS RRs that one is =
not willing to accept?

3.2.  Section 6.1 DMARC Policy Record

   PSD DMARC records are published as a subdomain of the PSD.  For the
   PSD ".example", the PSO would post DMARC policy in a TXT recor=
d at
   "_dmarc.example".

Don't you mean the PSD DMARC record is a record in the zone of =
the PSD?  It's not a subdomain.

3.3.  Section 6.5.  Domai=
n Owner Actions

   In addition to the DMARC [RFC7489] domain owner actions, PSOs that
   require use of DMARC ought to make that information available to
   receivers.

By what mechanism?

3.4.  Section 6.6.3.  Policy Discovery

   A new step between step 3 and 4 is added:

   3A.  If the set is now empty and the longest PSD (Section 2.3) of the
      Organizational Domain is one that the receiver has determined is
      acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
      a DMARC TXT record at the DNS domain matching the longest PSD
      (Section 2.3) in place of the RFC5322.From domain in the message
      (if different).  A possibly empty set of records is returned.
Section 6.6.3 of DMARC =
doesn't talk about "acceptable for DMARC", so I don't kno=
w what "acceptable for PSD DMARC" might mean.

Section numb=
ers in the prose of this section should make clear which document they'=
re referencing.

3.5.  Section 7.  DMARC Feedback

   Operational note for PSD DMARC: For PSOs, feedback for non-existent
   domains is desired and useful.  See Section 4 for discussion of
   Privacy Considerations.

Section 4 of which document?

4.  Privacy Considerations

   These privacy considerations are developed based on the requiremetns
=

typo

  =C2=
=A0of [RFC6973].  The Privacy Considerations of [RFC7489] apply to this
   document.

4.1.  Feedback leakage

   Providing feedback reporting to PSOs can, in some cases, create
   leakage of information outside of an organization to the PSO.  This
   leakage could be potentially be utilized as part of a program of

=
Remove one of the "be&quo=
t;s.

  =C2=A0pervasive surveillance (See [RFC7624]).  There a=
re roughly three
   cases to consider:

   o  Single Organization PSDs (e.g., ".google"), RUA and RUF rep=
orts
      based on PSD DMARC have the potential to contain information about
      emails related to entities managed by the organization.  Since
      both the PSO and the Organizational Domain owners are common,
      there is no additional privacy risk for either normal or non-
      existent Domain reporting due to PSD DMARC.

   o  Multi-organization PSDs that require DMARC usage (e.g., ".bank&q=
uot;):
      PSD DMARC based reports will only be generated for domains that do
      not publish a DMARC policy at the organizational or host level.
      For domains that do publish the required DMARC policy records, the
      feedback reporting addresses (RUA and RUF) of the organization (or
      hosts) will be used.  The only direct feedback leakage risk for
      these PSDs are for Organizational Domains that are out of
      compliance with PSD policy.  Data on non-existent cousin domains
      would be sent to the PSO.
This is the second use of &qu=
ot;cousin domain".  An example here or at the first use might be a goo=
d idea.

  =C2=A0o  Multi-organization PSDs (e.g., ".com") =
that do not mandate DMARC
      usage: Privacy risks for Organizational Domains that have not
      deployed DMARC within such PSDs are significant.  For non-DMARC
      Organizational Domains, all DMARC feedback will be directed to the
      PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
      Organizational Domain level) vice opt-in, which would be the more
      desirable characteristic.  This means that any non-DMARC
      organizational domain would have it's feedback reports redirected
      to the PSO.  The content of such reports, particularly for
      existing domains, is privacy sensitive.

   PSOs will receive feedback on non-existent domains, which may be
   similar to existing Organizational Domains.  Feedback related to such
   cousin domains have a small risk of carrying information related to
   an actual Organizational Domain.  To minimize this potential concern,
   PSD DMARC feedback is best limited to Aggregate Reports.  Feedback
   Reports carry more detailed information and present a greater risk.

   Due to the inherent Privacy and Security risks associated with PSD
   DMARC for Organizational Domains in multi-organization PSDs that do
   not particpate in DMARC, any Feedback Reporting related to multi-
   organizational PSDs ought to be limited to non-existent domains
   except in cases where the reporter knows that PSO requires use of
   DMARC.

5.  Security Considerations

   This document does not change the Security Considerations of
   [RFC7489] and [RFC7960].

   The risks of the issues identified in [RFC7489], Section 12.5,
   External Reporting Addresses, are amplified by PSD DMARC.  By design,
   PSD DMARC causes unrequested reporting of feedback to entities
   external to the Organizational Domain.  This is discussed in more
   detail in Section 4.



Kitterman               Expires November 28, 2019               [Page 7]
=0C
Internet-Draft                  PSD DMARC                       May 2019


6.  IANA Considerations

   This document does not require any IANA actions.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https=
://www.rfc-editor.org/info/rfc2119>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https=
://www.rfc-editor.org/info/rfc7489>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [psddmarc.org]
              multiple, "PSD DMARC Web Site", April 2019,
              <https://psddmarc.org/>.

   [PSL]      multiple, "Public Suffix List", April 2019,
              <https://publicsuffi=
x.org/>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https=
://www.rfc-editor.org/info/rfc5226>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598=
,
              DOI 10.17487/RFC5598, July 2009,
              <https=
://www.rfc-editor.org/info/rfc5598>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https=
://www.rfc-editor.org/info/rfc6973>.






Kitterman               Expires November 28, 2019               [Page 8]
=0C
Internet-Draft                  PSD DMARC                       May 2019


   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: =
A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <https=
://www.rfc-editor.org/info/rfc7624>.

   [RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky,
              E., Ed., and K. Andersen, Ed., "Interoperability Issues
              between Domain-based Message Authentication, Reporting,
              and Conformance (DMARC) and Indirect Email Flows",
              RFC 7960, DOI 10.17487/RFC7960, September 2016,
              <https=
://www.rfc-editor.org/info/rfc7960>.

   [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
              Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
              November 2016, <https://www.rfc-editor.org/info/rfc8020>.

Appendix A.  The Experiment

   To mitigate the privacy concerns associated with Multi-organization
   PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to
   indicate which PSDs do not present this privacy risk is appropriate.
   There are multiple approaches that are possible.

   The experiment is to evaluate different possible approaches.  The
   experiment will be complete when there is rough consensus on a
   technical approach that is demonstrated to be operationally usable
   and effective at mitigating the privacy concern.

   The mechanism needs the following attributes:

   o  Be reliably, publicly accessible

   o  Be under configuration control based on a public set of criteria

   o  List PSDs that either mandate DMARC for their registrants or for
      which all lower level domains are controlled by the PSO and that
      the relevant PSO has indicated a desire for the PSD to participate
      in PSD DMARC

   o  Have a small operational footprint (e.g. provide a documented,
      lightweight mechanism for developers and operators to retrieve the
      list of PSD DMARC participants)

   o  Not allow PSO to add PSDs to the PSD DMARC participants list
      without third party review




Kitterman               Expires November 28, 2019               [Page 9]
=0C
Internet-Draft                  PSD DMARC                       May 2019


   As of this writing, three approaches have been proposed.  None of
   them are ideal:

   o  An extension to the Public Suffix List at [PSL]

   o  A dedicated registry queried via DNS - an example of such a
      service is described in Appendix B.1 below

   o  An IANA registry

Appendix B.  DMARC PSD Registry Examples

   To faciliate experimentation around data leakage mitigation, samples
   of the DNS based and IANA like registries are available at
   [psddmarc.org].

B.1.  DMARC PSD DNS Query Service

   A sample stand-alone DNS query service is available at
   [psddmarc.org].  It was developed ba=
sed on the contents suggested for
   an IANA registry in an earlier revision of this draft.  Usage of the
   service is described on the web site.

B.2.  DMARC Public Suffix Domain (PSD) Registry

   [psddmarc.org] provides an IANA like=
 DMARC Public Suffix Domain (PSD)
   Registry as a stand-alone DNS query service.  It follows the contents
   and structure described below.  There is a Comma Separated Value
   (CSV) version of the listed PSD domains which is suitable for use in
   build updates for PSD DMARC capable software.

   Names of PSDs participating in PSD DMARC must be registered this new
   registry.  New entries are assigned only for PSDs that require use of
   DMARC.  The requirement has to be documented in a manner that
   satisfies the terms of Expert Review,per [RFC5226].  The Designated
   Expert needs to confirm that provided documentation adequately
   describes PSD policy to require domain owners to use DMARC or that
   all domain owners are part of a single organization with the PSO.

   The initial set of entries in this registry is as follows:











Kitterman               Expires November 28, 2019              [Page 10]
=0C
Internet-Draft                  PSD DMARC                       May 2019


   +-------------+---------------+
   |    PSD      | Status        |
   +-------------+---------------+
   | .bank       | current       |
   +-------------+---------------+
   | .insurance  | current       |
   +-------------+---------------+
   | .gov.uk     | current       |
   +-------------+---------------+

Appendix C.  Implementation

   There is one known implementation of PSD DMARC available for testing.

C.1.  Authheaders Module

   The authheaders Python module and command line tool is available for
   download or installation from Pypi (Python Packaging Index).

   It supports both use of the DNS based query service and download of
   the CSV registry file from [psddmarc.org=
].

Acknowledgements

   Thanks to the following individuals for their contributions (both
   public and private) to improving this document.  Special shout out to
   Dave Crocker for naming the beast.

   Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,
   Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig
   Schwartz, Alessandro Vesely, and Tim Wicinski

Author's Address

   Scott Kitterman
   fTLD Registry Services
   600 13th Street, NW, Suite 400
   Washington, DC  20005
   United States of America

   Phone: +1 301 325-5475
   Email: scott@kitterman.com









Kitterman               Expires November 28, 2019              [Page 11]
--00000000000003df6d058e477fa0-- From nobody Mon Jul 22 09:30:01 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 4B280120179 for ; Mon, 22 Jul 2019 09:29:59 -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 E6RhBDE32qwl for ; Mon, 22 Jul 2019 09:29:57 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4FA120168 for ; Mon, 22 Jul 2019 09:29:57 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id t28so38227211lje.9 for ; Mon, 22 Jul 2019 09:29:57 -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; bh=iwl+F6DP5FGBB3ia76b7XcZwmsVY+NL1dWD+ox3LSXc=; b=saQ+8Fsc+EyVEf1DbCqVZhJXxX4mVRx6TdYcxXnEFFnUCBK18EPOsaHJJkdNDl5tJq F27EfR1vJqReBDLEZMHXhitxIG3hm1PLXr4wMenYpLXIdrdoWl83aeZ0F3cnsrhdDNHk qpV5RhI8srPXvvKBBGUbLmrnOlyBJCWXEf3+oAlecXtiZy7JN54O9UMPt1drUJF43fRz sBaJ9t1BMeXAONdGwnUZLT1xoKGX2XjxitYuDKZGve+sqAInBJ9iukC5jInx4OjeNuxM yQs4C15UPlToXhFQL9BZmBXhbpMob+0lHXd4OEY2oi7o0SttQtnL5NJMWUXu81lO4cwm oQkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iwl+F6DP5FGBB3ia76b7XcZwmsVY+NL1dWD+ox3LSXc=; b=DImmiI3/CWKhJez+3VDcgAsY42srK99K5yzro+Z7qO3qr05uISOmVcTvjAvAUR+608 XIQNFf41ZZTY/VqaAVZFuHNU4NlhRNvsL1nNUAt8da161aLfJeI8EvLyjEX0VEz4KfmS FaVQOwLjMBSRtsV8GZqxeHzDzIzAjyeF0ikBL6c2Fwmd3hMY2oDU5GMpwZsab4nhCwzJ PPxgalhRpvRQsZhyrnMt13BpFmWwIgoiKbhTm9AfpgzGVD72AOyvw2BDBtSjnhTO92wr rMslIcNbtyjDSlEJ+g/a7Kjy014r7fk7HinmFNwnveUOl+4RT12xGP09uAt9XTut3QiW P9ug== X-Gm-Message-State: APjAAAUDpyuBMeNXcI/XVTEQsTMDNhGM3G3QXyHqWqTPelQI/pxWT+ik nRbQIm3bnxf4+/jQ/IdGihR7U2faU4OFarIlPvhidLG4hP0= X-Google-Smtp-Source: APXvYqzeXAD9bRRAckbQDQGsz2gQHZ1RAUjH7QhvIo10wkjvfPgdPCAd5c5nSUTAtDaWfqTHdfw+Au24nNe74MBLGwk= X-Received: by 2002:a2e:870f:: with SMTP id m15mr37030585lji.223.1563812994510; Mon, 22 Jul 2019 09:29:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 22 Jul 2019 09:29:43 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000008740b058e4796b9" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 22 Jul 2019 16:29:59 -0000 --00000000000008740b058e4796b9 Content-Type: text/plain; charset="UTF-8" Sorry, I hit "send" when I didn't mean to. Finishing up: On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy wrote: > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > PSD DMARC based reports will only be generated for domains that do > not publish a DMARC policy at the organizational or host level. > For domains that do publish the required DMARC policy records, the > feedback reporting addresses (RUA and RUF) of the organization (or > hosts) will be used. The only direct feedback leakage risk for > these PSDs are for Organizational Domains that are out of > compliance with PSD policy. Data on non-existent cousin domains > would be sent to the PSO. > > This is the second use of "cousin domain". An example here or at the first use might be a good idea. > > o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC > usage: Privacy risks for Organizational Domains that have not > deployed DMARC within such PSDs are significant. For non-DMARC > Organizational Domains, all DMARC feedback will be directed to the > PSO. PSD DMARC is opt-out (by publishing a DMARC record at the > Organizational Domain level) vice opt-in, which would be the more > > "vice" should be "versus"? Due to the inherent Privacy and Security risks associated with PSD > DMARC for Organizational Domains in multi-organization PSDs that do > not particpate in DMARC, any Feedback Reporting related to multi- > organizational PSDs ought to be limited to non-existent domains > except in cases where the reporter knows that PSO requires use of > DMARC. > > Feedback about non-existent domains is generated by virtue of the fact that such mail never passes SPF or bears a valid signature, correct? If so, that should probably be stated explicitly somewhere. 5. Security Considerations > > This document does not change the Security Considerations of > [RFC7489] and [RFC7960]. > > s/and/or/ > Appendix B. DMARC PSD Registry Examples > > To faciliate experimentation around data leakage mitigation, samples > > typo B.2. DMARC Public Suffix Domain (PSD) Registry > > [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) > Registry as a stand-alone DNS query service. It follows the contents > and structure described below. There is a Comma Separated Value > (CSV) version of the listed PSD domains which is suitable for use in > build updates for PSD DMARC capable software. > > Names of PSDs participating in PSD DMARC must be registered this new > registry. New entries are assigned only for PSDs that require use of > > Missing verb in the first sentence. -MSK --00000000000008740b058e4796b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I hit "send" when I didn= 't mean to.=C2=A0 Finishing up:

On Mon, Jul 22, 2019 at 9:23 AM Murr= ay S. Kucherawy <superuser@gmail.= com> wrote:

   o  Multi-organization PSDs that require DMA=
RC usage (e.g., ".bank"):
      PSD DMARC based reports will only be generated for domains that do
      not publish a DMARC policy at the organizational or host level.
      For domains that do publish the required DMARC policy records, the
      feedback reporting addresses (RUA and RUF) of the organization (or
      hosts) will be used.  The only direct feedback leakage risk for
      these PSDs are for Organizational Domains that are out of
      compliance with PSD policy.  Data on non-existent cousin domains
      would be sent to the PSO.

=C2=A0This is the second use of "cousin domain". An example her= e or at the first use might be a good idea.

  =C2=A0o  Multi-orga=
nization PSDs (e.g., ".com") that do not mandate DMARC
      usage: Privacy risks for Organizational Domains that have not
      deployed DMARC within such PSDs are significant.  For non-DMARC
      Organizational Domains, all DMARC feedback will be directed to the
      PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
      Organizational Domain level) vice opt-in, which would be the more
"vice" should be "versus"?

   Due to the inherent Privacy and Security risks associate=
d with PSD
   DMARC for Organizational Domains in multi-organization PSDs that do
   not particpate in DMARC, any Feedback Reporting related to multi-
   organizational PSDs ought to be limited to non-existent domains
   except in cases where the reporter knows that PSO requires use of
   DMARC.

Feedback about non-ex= istent domains is generated by virtue of the fact that such mail never pass= es SPF or bears a valid signature, correct?=C2=A0 If so, that should probab= ly be stated explicitly somewhere.

5.  Security Considerat=
ions

   This document does not change the Security Considerations of
   [RFC7489] and [RFC7960].

s/a= nd/or/

  =20
Appendix B.  DMARC PSD Registry Examples

   To faciliate experimentation around data leakage mitigation, samples

typo

B.2.  DMARC=
 Public Suffix Domain (PSD) Registry

   [psddmarc.org] pro=
vides an IANA like DMARC Public Suffix Domain (PSD)
   Registry as a stand-alone DNS query service.  It follows the contents
   and structure described below.  There is a Comma Separated Value
   (CSV) version of the listed PSD domains which is suitable for use in
   build updates for PSD DMARC capable software.

   Names of PSDs participating in PSD DMARC must be registered this new
   registry.  New entries are assigned only for PSDs that require use of

Missing verb in the first sentenc= e.

-MSK
--00000000000008740b058e4796b9-- From nobody Mon Jul 22 09:42: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 EE17312032B for ; Mon, 22 Jul 2019 09:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BnUjxqvtxix for ; Mon, 22 Jul 2019 09:42:21 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E10E12036B for ; Mon, 22 Jul 2019 09:42:21 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id b17so27148877lff.7 for ; Mon, 22 Jul 2019 09:42:21 -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; bh=DNLBqgNAQmhfmRVXN7/Wxt0JbdiTrXLDjJwHCFe4R2c=; b=WXq/E3SDkdh3Q3t/fNGXF9/arpXdCChSKhqaXgHxswO2LEyf7LxuPLzBo/RGO2ndpC 2eFuIklefqfA45nRTn84CzwbS7ZGtL1FDM3tX/z7D6p4GnhtJNIJ9+EKElrhVsKBjaDR rMjI9LF83QY06CCDCvLik7c/6FbhrEa7ab62BNaiv7PNuRhTDGZoGAMnxolG13U8DQ5K nIDDPfUN7DH+RDoRTF9ku/xX9yGdbShBQvTlvZHLAz0Zh5mFOU8htusqI9NQrbvuZ3TD CVUrMMPqqUiiJ/qVqpi/joymsFKduifoWaV2GOgFxDR6JOd3/d8GJePnIT6Oeg0iytYL xQQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DNLBqgNAQmhfmRVXN7/Wxt0JbdiTrXLDjJwHCFe4R2c=; b=oqsi4GFLGWUSQ22fl7mWpIABEQ9KA/rUxe9vTWMWLhlPHIA39rerhy2zNO7mrxqO9G RenAfsZCgu+Q0GWCXwrbAoO8JO9s8TncQ5z8c8ITltJbCcUJ+0+yf1nHhdeimCPux38l mHKF61pWEpRWyLnKKjKm33G8zCHveSnh8oy3V3wXS+ZFCkGJauBUA+wl3CLDfKl8zcez Md/T0Pcy2cGAnlWf0K6CWxiUWjhEtFpx4b1PTI+u2Hipj9ImmMcLzizprIQ70+/BfDQJ B1ig14YRcZ79jIsLglGJqHGSDriBr+qyOeDkZV5YmrtHVIfijoqc1M/s0PTisU/9Dwos E5lA== X-Gm-Message-State: APjAAAX2rHH+IoqSznDuNz2N71FZfFHzNiVyZPV5PezbBdsXyM2iRad6 2ZE9KklB0jUCSkS6LtRjsgpeatHcqDt2AkniRQFQ5fT4BW0= X-Google-Smtp-Source: APXvYqzoOdbZ/gM3oAUz5Zrm40RrjX647Hs23J26zXHx6ixnA+aHfDnmqO5ZMnymRhFbaOw426rNzjf0kpNLN0Mdtmc= X-Received: by 2002:ac2:546a:: with SMTP id e10mr32938963lfn.75.1563813739021; Mon, 22 Jul 2019 09:42:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 22 Jul 2019 09:42:07 -0700 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000068c9bc058e47c235" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 22 Jul 2019 16:42:27 -0000 --00000000000068c9bc058e47c235 Content-Type: text/plain; charset="UTF-8" One (hopefully) last thing: On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy wrote: > > 3.4. Section 6.6.3. Policy Discovery > > A new step between step 3 and 4 is added: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > Organizational Domain is one that the receiver has determined is > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > a DMARC TXT record at the DNS domain matching the longest PSD > (Section 2.3) in place of the RFC5322.From domain in the message > (if different). A possibly empty set of records is returned. > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I don't know what "acceptable for PSD DMARC" might mean. > > Section numbers in the prose of this section should make clear which document they're referencing. > > I think an example in an appendix that shows an evaluation without PSD and then with PSD, and then some prose about what it enables (i.e., what the benefit is), would be extremely helpful. -MSK --00000000000068c9bc058e47c235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One (hopefully) last thing:

=
On Mon, Ju= l 22, 2019 at 9:23 AM Murray S. Kucherawy <superuser@gmail.com> wrote:

3.4.  Section 6.6.3.=
  Policy Discovery

   A new step between step 3 and 4 is added:

   3A.  If the set is now empty and the longest PSD (Section 2.3) of the
      Organizational Domain is one that the receiver has determined is
      acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for
      a DMARC TXT record at the DNS domain matching the longest PSD
      (Section 2.3) in place of the RFC5322.From domain in the message
      (if different).  A possibly empty set of records is returned.
Section 6.6.3 of DMARC =
doesn't talk about "acceptable for DMARC", so I don't kno=
w what "acceptable for PSD DMARC" might mean.

Section numb=
ers in the prose of this section should make clear which document they'=
re referencing.

I th= ink an example in an appendix that shows an evaluation without PSD and then= with PSD, and then some prose about what it enables (i.e., what the benefi= t is), would be extremely helpful.

-MSK
--00000000000068c9bc058e47c235-- From nobody Wed Jul 24 08:27: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 59BCC120361 for ; Wed, 24 Jul 2019 08:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNptYx0C46OH for ; Wed, 24 Jul 2019 08:27:34 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EE61203CB for ; Wed, 24 Jul 2019 08:27:27 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id t28so44913278lje.9 for ; Wed, 24 Jul 2019 08:27:27 -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=xwESM25LVu82mztfmFiYvDSG7FVPPXeUpKnRfi2Bl/s=; b=ZXS7MNj3ZQC+8gHCiv0b8wHN8HVdx7SgUUU2sUfqijOvZmWh1FUIC/qb6cBIB9SSuF Z+FTFe7OqhACk6A7MvBn9GpFwFJXJSJbZiuCZukV3EgwQcITKU9nTRyUupyfpTaW6IZG zPYhMdd4oh7iCVTrtj77FzACHkL0sN/FLHq9k7AY0RudX4zEVm5yiC+/0mYz/wb0uoGS Bnkfx1PML4c/nfJEr6/UAgKAyvNCiNEIQdjZXsuQjacUvR7XCc6U0uHSAJEIiHDvr5hA n4WeGOga1QOw73/X+u8pAnlXPtcaLlfueOwbbRe+/8+2LkYipXpPVuYBqIH1a2PcC2oe iz4Q== 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=xwESM25LVu82mztfmFiYvDSG7FVPPXeUpKnRfi2Bl/s=; b=HLDxdhsgUvjCGMB3gcZBiZ4Lb5ciDiSA+l/EI03LD16iNc+WXuONeIyYpTeasQDhW1 pKZp+X3KuaIoh+5Y00/6CPWeqntTzoJiWaLQ6b1UGmMeUHvQYwA0jlfbQO/U3cl+QADb 9AeQbWd98bvn5UYx2P+TUA/REW5rKob8XsFNAO9gKU/w+mMtiHb/dB/rcq2RmTlm21tP g7k1Ic7Hv/mq8BGVpEny3LGySGSvf+/eDgYl/ReNZqRbDgtZkXSD7XedmWMDvu9CRKxw aAiuc1oGTUhybVve/MtkE4lCJXbJM94EwcTsRMxEoxQxhMIt3TZiK/D//RlDCXob4bDl tKKA== X-Gm-Message-State: APjAAAXt+8VRRKSgpqZ/EdX64+hVOcQlQ+KHqkrY8py6qYcP7BtVtnjG imSENXB2Fdb5ge9Y9LmSei7UUUAWzTkUCuUC07Q= X-Google-Smtp-Source: APXvYqzG4OUhKG8x+hhlQAsf+KfoQT9Fv3FN8Xg59Sz/OFbzwBhj3dqnXlwNfx7ke/zlkzSlnEq3ICD6XFiNQ106bQE= X-Received: by 2002:a2e:9a19:: with SMTP id o25mr43561940lji.63.1563982045422; Wed, 24 Jul 2019 08:27:25 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> In-Reply-To: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> From: "Murray S. Kucherawy" Date: Wed, 24 Jul 2019 11:27:13 -0400 Message-ID: To: Vladimir Dubrovin Cc: Dotzero , IETF DMARC WG , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Content-Type: multipart/alternative; boundary="00000000000040a8d7058e6ef290" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 15:27:35 -0000 --00000000000040a8d7058e6ef290 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin wrote: > Nope, I mean 2 different things. > > 1. Why quarantine is useful (with pct=0). > > For example this mailing list (dmarc@ietf.org) performs From rewrite (aka > From munging), e.g. dubrovin@corp.mail.ru is replaced with > dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a > strict DMARC policy (reject). dotzero@gmail.com is not overwritten, > because gmail.com has p=none and ietf.org only overwrites From only for > domains with "quarantine" and "reject" policies. It's quite common behavior. > > If you are implementing DMARC for a new domain (let's say example.org), > you usually start with "p=none". With p=none you receive reports for failed > DMARC for different lists, like ietf.org. Before switching to stronger > policy (p=reject), you may want to know which mailing list will still fail > DMARC, and which lists perform From munging and, as a result, do not fail > DMARC. For this purpose, before switching to "p=reject" it's useful to > switch to "p=quarantine;pct=0". After this, you will only see mailing lists > without From munging in DMARC reports. > I'm confused; is this claiming that those rewrites happen by virtue of the fact that "p=quarantine" is the published policy? Seems to me that rewriting will happen irrespective of what the published policy is for the >From domain. Or is it the case that this changes the content of the aggregate reports in a way you find meaningful? -MSK --00000000000040a8d7058e6ef290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 14, 2019 at 12:25 PM Vladimir= Dubrovin <dubrovin=3D4= 0corp.mail.ru@dmarc.ietf.org> wrote:
=20 =20 =20
Nope, I mean = 2 different things.
=20

1. Why quaran= tine is useful (with pct=3D0).=C2=A0

For example t= his mailing list (dmarc@ietf.org) performs = >From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubr= ovin=3D40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because g= mail.com has p=3Dnone and ietf.org only overwrites From only for domains with "quarantine" and &quo= t;reject" policies. It's quite common behavior.

If you are im= plementing DMARC for a new domain (let's say example.org), you usually start with "p=3Dnone". With p=3Dnone you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=3Dreject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=3Dreject" it's useful to switch to "p=3Dquarant= ine;pct=3D0". After this, you will only see mailing lists without From munging in DMARC reports.



-MSK
--00000000000040a8d7058e6ef290-- From nobody Wed Jul 24 09:37:06 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 42A6F12047F for ; Wed, 24 Jul 2019 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJWC2FqC7Cc8 for ; Wed, 24 Jul 2019 09:37:01 -0700 (PDT) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 B29F812025F for ; Wed, 24 Jul 2019 09:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=NOoPmjdr7XEqpTJSZqI5fUjl0B0fKH+BqzpU9nOF83Y=; b=bxFUGSPMVh2ffIT5RafUPkHg7J/pS3xvBrEht/z6MdNcG2HNGtxnkAABq5R9VvUjRxWUGuyBE3VNQvDYikPScJ3jbvxcxU734Mq7auLMultllxT++TjDIcM5XzU60QFXj1zlS+5/qT3QN0n8tH4OLhhWWvStbbp1PaQH1era1AM=; Received: by smtp29.i.mail.ru with esmtpa (envelope-from ) id 1hqKG9-0007oW-Uh; Wed, 24 Jul 2019 19:36:58 +0300 To: "Murray S. Kucherawy" , Vladimir Dubrovin Cc: IETF DMARC WG , Dotzero , =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> From: Vladimir Dubrovin Openpgp: preference=signencrypt Autocrypt: addr=dubrovin@corp.mail.ru; prefer-encrypt=mutual; keydata= mQINBFkuo0YBEADhYgaiCbZjws9eRBKJAYMIeuo9x6cArdmG5lcDgyVrtIPz/7MGL/HJua0v xKJtfhk77fb2YKcJvIdCf6HMoJfU412Y/5Bjq7eLmXTBsf7KmpQ9Z6auYujrzLCEb6gHC4gp gauesj6+igIyd8YULbbbCieIht7FVEIQv1Hn6F3eIok6wC3UJi2gEUiRbN4p5fw1RI5IB8yJ /4iFTtZi2iKUvSxZt/6eMAGNYm+OrFFGSfCP6l3uD93ZO3M9x8TluMXXrUQM6J190LOUUeh7 jGklgyUxrJXi44pRLFMbirrBcCQwEcY/lpUb1tvq2Ohb9nhBFBWLoJ1Kplxpi9ueXAsNJ7zw K1R15EElpIYQEmXM7t3dvC+zRIwZOiYTEI+cTqi3+fe/89lVQB15R43lrALl3+GEOj2F9/HP eCJtTzn+ie8+p0lSIWhNb2ozRPaKv1vxEGqkA+1wcgF2EOh3melRKGnf5VKJ4ZL5LZi+55nV NV/MiHv6WuA6QEB08qxgkF1vmpy3olQmpxzRHGnLcKClAnkfgn3Gp4Kkf/cKZ/jmgycf3QiZ OX9pJmChkp7florVmb31gXnZwiwa3AM5j063+JE6r0Uwt5R4TZsOx109U9a0ta4eS6fE22+O pEPKddpaOPnCTB/RDcxFbyXWJw8J5FW6EUbNSaBQTIjZn6jUnQARAQABtClWbGFkaW1pciBE dWJyb3ZpbiA8ZHVicm92aW5AY29ycC5tYWlsLnJ1PokCPwQTAQgAKQUCWS6jRgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKxNqiqt3SqHr3kQAInNgkXiRv61Zs4g B2mxrPtTRij+iDF+UOJVA/A5SjHaMWPVbT0PblbwWkxQvaxBDEPN4NRp+5mLkxD6ETmJJFZx gfmB3N9vhqFjHVb9K6AqGc7qlhlGwoIj6x27F07lmNkYHXMqqdt9Nbk+FvjukDU4WMZYFtXu 4c43hclKCg2i+bgZ5rXNJFsLioaY2Z/6Yml4COwvhDSg+IXF8oZtnf0Y8EP9qPeC3DHpL5n1 IgcB5mpzcBdsQchIVVCYCljVf0g5wslfs0tKvyrOsSF1gX8NK6gY3mZb44f5M2yviL/DFCS2 lmZDX2HqCmgyI0GwLTEW9zuZKE0WT6FF2KbWv3QbkwplygCQYlwCeEDOiemIsGiM11ubvDNe Iotvv06IsC5+6VYb63GBqRty+wEOjBNgz8AsHdljGxZjavQRBHa24+lYASMfLUqqoGPPM9wj mgiyOfS9p+VZumNzjk11mHrTe+Y7HujHVCjC74Ue+QHeyuIjk0bxDQSISh+w1jw9v/nyN8wh /tugEC4DO9LhyJPprZcduHQtlIFXEeZbmvapXqLjgMIz1WUB7hGcUMUkZZWqlkGyLhOdFpJL DkTMxqmazRL/jWLHSIRKWx1tmTn0GXLpXitP8ud8P67jY8mI2A04seuFNZLmtQLxP9qIIdrd f7WYPo19e+0b83BiC7rGuQINBFkuo0YBEADmrX6Ho18GYRk2GJZ3sy4g61oVuwAED+zGSsFt pYGGsOo/3rp9HRRcWR9qQ0osO14oB7swEhWnv4BMpab2WQ2BXM10W6B94yJsRMcZK4VJVSrP o/IEBrXe4roug+iG60wh4Cmi6Ojoi9OCarl+JVZCSclDy6cEv/MQRgwlNV+jvEqxVokdAwTY HrXpYpISnwCGcR6/eA+CHFvLQOkR+oHFqNuJsdx9e+OXP9MA5YLgi1atyHfkhGdDraLLTyGD aAqOaiOt7LdRL5xlaFejlHydkWEXbxSmIro7hHAFmyreslQ63V1vpLa6czylRqQ/us6iOidu rc+zsNAd7dbKVuOW/YEbiTrKwX7xjOa7lxYkOCBc+xa0Jj57FUoNQQdr678olgF5zqKvgZKa qiYSH6WR/wnKVmB8KQItyGZneq2f3Tqkc/S9Z45Olz7uYnN32uJAgn6awezkcK4iGSjQMzzg onP28LuLGoJVX92HWcYNBRW5T0Jqdro3i+XWLKWNsRSe8ifguH87CPfAtIsUJRUDvdR+XKF8 /TeXZfpdeU5tzOnRXPrST8L3Yw3Hpa//JtCmAXo02uer+fZm0e2+rB0cjn2P65fb5sb0jJNy mp1dwUEs+u0xHN3gHVBtPixCqnPVzFBygBtaPZF+6B6fhFLABNokIyii5NHYNS/NqEGTzwAR AQABiQIlBBgBCAAPBQJZLqNGAhsMBQkJZgGAAAoJEKxNqiqt3SqHOMQQAIojVofS2i1fAmML cnqhJVjB7nNZNTYGPGuqaSOk+P3nViihhkA+dhbntDRAipIzIoCOzBYQ69mY0LQAA1cAxC0T tqoDidp96OoGZfp1zWJu2pQrubfY8iR8+fxWPfQnPakVItp4Rexzg5oWsy070ysMhWemqRps DaozbJJU0dPCxIRCO28H20DLYF9LzK0BUQBJUcrGT7pLwyI2UXT8UdKBkyzezh53en+mnV2W a1U/syFstNBv5Y+XTemh882butmbBqGU4V47FK8BeBZdfrbqyz9fJMPQuV8esA3ucRP5gwDY S4z8QiofEfkPZ0V3ldGnpjJyCXdeYzMFgA/+cTmTO0lAA96+zB0Z/gcNwL/Nq1bX6P31mPsC PrBjlOUUCCBgek4D//oUKzoBF2YPQeMsqt7PKboHtTVeE0279vRifbIRF295X4nKVA4sWHpx V/HrSdpNQraWw7Sq4/iTbcqETNY48oWQBSeilGD+ZXKxtdUte8plVPDFoUxQZ6iQp3YqrEgi eNAwkMkiWb5zQ3YKd3JfsTOd1wd9Cc2jKaSE7fj3moAkSxQNZsgiQzMFThK7S/wcESpJfRxH hicIfJtLXgoQZOjH1zePjmdHxidhD65P8cfey++AYYSYWPyRrN5BW1Aam8FDOBpzU8pvNjWL NXdphurqQpFSRlvcRvXY Message-ID: <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> Date: Wed, 24 Jul 2019 19:36:56 +0300 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: multipart/alternative; boundary="------------4EC62A31F2B6C4B15D5A6EBB" Content-Language: en-US Authentication-Results: smtp29.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-618D5548: ACEA26129A20ABBD820D0EDADA0713521841ADDC522C019E6540E05ADAEC12CE X-Mras: Ok Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 16:37:04 -0000 This is a multi-part message in MIME format. --------------4EC62A31F2B6C4B15D5A6EBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Murray, Yes, rewriting depends on policy. Look at From: headers for this mailing list (dmarc@ietf.org), you can see it only munges From address for domain with strict DMARC policy (if RFC5322.From domain publishes "quarantine" or "reject" policy). This is very common behavior, it can also be seen in Google Groups. But, as it was correctly pointed by Dilyan Palauzov, there should be no difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid DMARC Mail Receiver implementation, so "p=reject;pct=0" can probably be used instead. 24.07.2019 18:27, Murray S. Kucherawy пишет: > On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin > > wrote: > > Nope, I mean 2 different things. > > 1. Why quarantine is useful (with pct=0).  > > For example this mailing list (dmarc@ietf.org > ) performs >From rewrite (aka From > munging), e.g. dubrovin@corp.mail.ru > is replaced with > dubrovin=40corp.mail.ru@dmarc.ietf.org > . It's because > corp.mail.ru has a strict DMARC policy > (reject). dotzero@gmail.com is not > overwritten, because gmail.com has p=none and > ietf.org only overwrites From only for domains > with "quarantine" and "reject" policies. It's quite common behavior. > > If you are implementing DMARC for a new domain (let's say > example.org ), you usually start with > "p=none". With p=none you receive reports for failed DMARC for > different lists, like ietf.org . Before switching > to stronger policy (p=reject), you may want to know which mailing > list will still fail DMARC, and which lists perform From munging > and, as a result, do not fail DMARC. For this purpose, before > switching to "p=reject" it's useful to switch to > "p=quarantine;pct=0". After this, you will only see mailing lists > without From munging in DMARC reports. > > > I'm confused; is this claiming that those rewrites happen by virtue of > the fact that "p=quarantine" is the published policy?  Seems to me > that rewriting will happen irrespective of what the published policy > is for the From domain. > > Or is it the case that this changes the content of the aggregate > reports in a way you find meaningful? > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @ mail.ru --------------4EC62A31F2B6C4B15D5A6EBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Murray,

Yes, rewriting depends on policy. Look at From: headers for this mailing list (dmarc@ietf.org), you can see it only munges From address for domain with strict DMARC policy (if RFC5322.From domain publishes "quarantine" or "reject" policy). This is very common behavior, it can also be seen in Google Groups.

But, as it was correctly pointed by Dilyan Palauzov, there should be no difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid DMARC Mail Receiver implementation, so "p=reject;pct=0" can probably be used instead.

24.07.2019 18:27, Murray S. Kucherawy пишет:
On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin <dubrovin=40corp.mail.ru@dmarc.ietf.org> wrote:
Nope, I mean 2 different things.

1. Why quarantine is useful (with pct=0). 

For example this mailing list (dmarc@ietf.org) performs >From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior.

If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports.

I'm confused; is this claiming that those rewrites happen by virtue of the fact that "p=quarantine" is the published policy?  Seems to me that rewriting will happen irrespective of what the published policy is for the From domain.

Or is it the case that this changes the content of the aggregate reports in a way you find meaningful?

-MSK

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


--
Vladimir Dubrovin
@ mail.ru
--------------4EC62A31F2B6C4B15D5A6EBB-- From nobody Wed Jul 24 09:52:40 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 CE4A7120372 for ; Wed, 24 Jul 2019 09:52:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia-eKzipx_8a for ; Wed, 24 Jul 2019 09:52:37 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 4AF7B120112 for ; Wed, 24 Jul 2019 09:52:37 -0700 (PDT) Authentication-Results: mail.aegee.org/x6OGqRgh008351; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1563987149; i=dkim+MSA-tls@aegee.org; r=y; bh=g+bn90KlycKkZRSitrVqIpEMFvLdR6X0SwHZYlFGpTE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=RhxsuC+QKscUi+TjWOt/gL8m29aFbIF3L3Gmh+vBrGA5JCqpnCGcpqW8FqtbBzdDI paAup+8KyJu4W+u0LLoBT8EDJgbOPtyugmevs0XoknHabvT11mUdak8li1aJEOrUD4 ZbZxEVolMcj6ZAlYed1sL50TKUyvY6OZtuqZQ5YlICh+NgD4uV7nxcFxHj9rz8F1z2 ofkChAvlszRDG+RhRPGEQMVaSiF88Qvd9uyPhBOcN6yJMT833kBw76mbcY6rnVYlcm FB29YEV2/dGCG2B+VmieLbXn/hLQfkZrc4S7s4l9kpWuVI73Kksub/8zM1tHyBvK2M IlbGhm09sZaf0DGHIEvI6vL7GqwMIAQu0ABmO5gb9qHMatNOHBOva5CLvQEPicqn57 1NV1tTReUXt/HMANlXBhHZJTzjHM1TLrVwrYzs68qkhIlmkBgj16WARyjCDqJ1ud+2 J0PaEEM7hwfuRu7rSt1uuje8WO/1juzUF+O7Bb0QpeKguaoXjGYkZEmKfBdiQzl5uN Sd6zX89Bn5ADbB/SM21v5JSbutpPodgJ+vqeWNs9e9S9j0ur/6Cj1sT8nd8/MGTWVO xKeX7QrjK4i2KPHwGXcxThicDH5ukbebbo4tnsaowuD8HMFH0AI/9uvYl2DETQtwaA fwUsnG05V7AVLm4O4LpASpdM= Authentication-Results: mail.aegee.org/x6OGqRgh008351; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6OGqRgh008351 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 24 Jul 2019 16:52:28 GMT Message-ID: <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Vladimir Dubrovin , "Murray S. Kucherawy" , Vladimir Dubrovin Cc: IETF DMARC WG , Dotzero Date: Wed, 24 Jul 2019 16:52:27 +0000 In-Reply-To: <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 16:52:39 -0000 Hello, (I repeat what was said here, just in case) As it was pointed out, p=quarantine; pct=0; is the same as p=none; and p=reject; ptc=0; is the same as p=quarantine; pct=100, therefore p=quarantine; pct=0 is not the same as p=reject; pct=0 currently, per https://tools.ietf.org/html/rfc7489#section-6.6.4 (RFC DMARC, Section Message Sampling) And then, for p=none or any equivalent form of it, there is no need or established practice for mungling, while for p=reject; pct=0, or any equivalent form of it, there is mungling. This is the current specification. I proposed on this regard in fact two things: - specifying that p=quarantine; pct=0 (email from 10th May to dmarc@ietf) the MLM does mungling - abolishing policy quarantine That is: p=reject; pct=0 gets almost the same as p=none, except that there is recommendatiton for MLM to mungle From:. Regards Дилян On Wed, 2019-07-24 at 19:36 +0300, Vladimir Dubrovin wrote: > > Hello Murray, > > Yes, rewriting depends on policy. Look at From: headers for this mailing list (dmarc@ietf.org), you can see it only munges From address for domain with strict DMARC policy (if RFC5322.From domain publishes "quarantine" or "reject" policy). This is very common behavior, it can also be seen in Google Groups. > > But, as it was correctly pointed by Dilyan Palauzov, there should be no difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid DMARC Mail Receiver implementation, so "p=reject;pct=0" can probably be used instead. > > 24.07.2019 18:27, Murray S. Kucherawy пишет: > > On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin wrote: > > > Nope, I mean 2 different things. > > > > > > 1. Why quarantine is useful (with pct=0). > > > > > > For example this mailing list (dmarc@ietf.org) performs >From rewrite (aka From munging), e.g. dubrovin@corp.mail.ru is replaced with dubrovin=40corp.mail.ru@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotzero@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior. > > > > > > If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports. > > > > > > > I'm confused; is this claiming that those rewrites happen by virtue of the fact that "p=quarantine" is the published policy? Seems to me that rewriting will happen irrespective of what the published policy is for the From domain. > > > > Or is it the case that this changes the content of the aggregate reports in a way you find meaningful? > > > > -MSK > > > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > -- > Vladimir Dubrovin > @ mail.ru From nobody Wed Jul 24 13:07: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 AEC5A120674 for ; Wed, 24 Jul 2019 13:07:44 -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 S_PUmklilOYZ for ; Wed, 24 Jul 2019 13:07:42 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AE412066B for ; Wed, 24 Jul 2019 13:07:42 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id m23so45631882lje.12 for ; Wed, 24 Jul 2019 13:07:42 -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=bG5gRQ0MxolJh5HG4GbM/jAMJ81ozWGZmwuOdS/aJ/0=; b=uirAWFkRkobaoxJ8CRw3rVPzdSQLF6uP5QuoKy38lhjVbfI9M64CaqClfbtnLAIeex H4klcx/alzuVvktzSFJvod9EJ7K1d51GtlBazoMSiV84sHA00ddcuauHpGZ4qw7ius7M PpRANTynR/qY28Sncz2pab2gCdbv/w6eOmbutyEBMvVZW7okRKsKBdjYjFcuon2vzeIs e0BWr/2ruy1WBS6/s/H9BXL5enRuL8Fb9DRBuCLyadJkUkWLg9LVM4SZ7UmGfNKhulwV Y5Xdq+zH/xQBEL4otVk/2k/b06q8pjQWfRhs5SCSYcYJR3vXBAC/C1BUmRGH4Sf5tOyd 6A5g== 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=bG5gRQ0MxolJh5HG4GbM/jAMJ81ozWGZmwuOdS/aJ/0=; b=S/OFKWXpweaAxNrLwmyJNSi9GD53TeL8+HY+nPr6MMK7qPvY98A16IF6MMaH0GKWbu /5BO10eEQB1eXixpDT7MFXMmURtie/mHzfaa9kgyn2FDQyG+cybwsYBpNbCxPJQzxiW4 kOX3EID09vRq4XwOt2UJy8ELScewso8oYhDKlO7UsjZe8t5lQ5rbVJzyDYSh1q6cQ9Nv 0YlacEYwrUTJparReBAdsS7foVGnOkEFIW83Ol1gT19jeJUf9HCtsXZKypuTTxKFujwX pglIHZUyUh8ToM/hMlQ9q2GhFZUp3T067Fd3om1+0zjxqdnRKHgvkN9fA1lRGkHqYU0z hCoA== X-Gm-Message-State: APjAAAWlP3stnqnbbbBVs9mh01J5Y2r+D9j5FjXx/NoZlQJKYzNoaXM1 AZ0TZsZKPg+GGbZE14tFTdDy/7c1Sam23R8IL5Y= X-Google-Smtp-Source: APXvYqxjys5433aef0+5EdHNojLsnveJpPlWP+ah5DM2k9OKmPnQ/YllC/MAID94BaBqr7fJt00iLkUDF1KRNzD19fg= X-Received: by 2002:a2e:870f:: with SMTP id m15mr44204049lji.223.1563998860407; Wed, 24 Jul 2019 13:07:40 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> In-Reply-To: <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> From: "Murray S. Kucherawy" Date: Wed, 24 Jul 2019 16:07:27 -0400 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: Vladimir Dubrovin , Vladimir Dubrovin , IETF DMARC WG , Dotzero Content-Type: multipart/alternative; boundary="00000000000080f801058e72dc43" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 20:07:49 -0000 --00000000000080f801058e72dc43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, I see what you're getting at. It's interesting that the industry has decided to interpret "p=3Dreject; pct=3D0" the way we intended "p=3Dquarantine; pct=3D100". As for your proposal: On Wed, Jul 24, 2019 at 12:52 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0= =B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > And then, for p=3Dnone or any equivalent form of it, there is no need or > established practice for mungling, while for > p=3Dreject; pct=3D0, or any equivalent form of it, there is mungling. > > This is the current specification. I proposed on this regard in fact two > things: > - specifying that p=3Dquarantine; pct=3D0 (email from 10th May to dmarc@i= etf) > the MLM does mungling > - abolishing policy quarantine > > That is: p=3Dreject; pct=3D0 gets almost the same as p=3Dnone, except tha= t there > is recommendatiton for MLM to mungle From:. > I'm a little worried about this, but maybe it's just The Way Of Things. We had intended the publication of a DMARC policy to be a message from the ADMD owning a domain name to any ADMD receiving mail from it about how to handle unauthenticated or unaligned messages. It's actually morphed on its own into also being a message to any MLM that might be in the way to take particular rewriting actions. I wonder if the standards track version of DMARC should explicitly take this into account. -MSK --00000000000080f801058e72dc43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I see what you're getting at= .

It's interesting that the industry has decid= ed to interpret "p=3Dreject; pct=3D0" the way we intended "p= =3Dquarantine; pct=3D100".

As for your pr= oposal:

On Wed, Jul 24, 2019 at 12:52 PM =D0=94=D0=B8=D0=BB=D1= =8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <dilyan.palauzov@aegee.org> wrote:
And then, for p=3Dnone or any equivalent form of it, there is no= need or established practice for mungling, while for
p=3Dreject; pct=3D0, or any equivalent form of it, there is mungling.

This is the current specification.=C2=A0 I proposed on this regard in fact = two things:
- specifying that p=3Dquarantine; pct=3D0 (email from 10th May to dmarc@iet= f) the MLM does mungling
- abolishing policy quarantine

That is: p=3Dreject; pct=3D0 gets almost the same as p=3Dnone, except that = there is recommendatiton for MLM to mungle From:.

=
I'm a little worried about this, but maybe it's just The Way = Of Things.=C2=A0 We had intended the publication of a DMARC policy to be a = message from the ADMD owning a domain name to any ADMD receiving mail from = it about how to handle unauthenticated or unaligned messages.=C2=A0 It'= s actually morphed on its own into also being a message to any MLM that mig= ht be in the way to take particular rewriting actions.=C2=A0 I wonder if th= e standards track version of DMARC should explicitly take this into account= .

-MSK=

--00000000000080f801058e72dc43-- From nobody Wed Jul 24 13:45:49 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 067F4120623 for ; Wed, 24 Jul 2019 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=wordtothewise.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 E8MABSBJPKtT for ; Wed, 24 Jul 2019 13:45:45 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id C67FD12060C for ; Wed, 24 Jul 2019 13:45:45 -0700 (PDT) Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id E021A9F146 for ; Wed, 24 Jul 2019 13:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1564001145; bh=eCkRRzr+IcQMjy5mxWYaXj3hpZdfJzoLX9oq9jXiOuw=; h=From:Subject:Date:References:To:In-Reply-To:From; b=MSD6mbuZpSzHiZ+sn8xTgz2IyiPRJ33TTkxjN21ZM5QM3ziiRGScf+HxOsiPj9bnw YGVo5A6lr+NngV7tC/WDCHDY/0DERNn0A/zxGyLPNAFMEUQa7L6zfFFtTHgsCtOuBI mFR2FYzl31HdVeJ1Vwj3qBVFDfNLPdNnvBRBTy9M= From: Steve Atkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 24 Jul 2019 21:45:42 +0100 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> To: IETF DMARC WG In-Reply-To: Message-Id: <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 20:45:48 -0000 > On Jul 24, 2019, at 9:07 PM, Murray S. Kucherawy = wrote: >=20 > OK, I see what you're getting at.. >=20 > It's interesting that the industry has decided to interpret "p=3Dreject;= pct=3D0" the way we intended "p=3Dquarantine; pct=3D100". It's semi-explicitly defined that way in the RFC, isn't it? Cheers, Steve >=20 > As for your proposal: >=20 > On Wed, Jul 24, 2019 at 12:52 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD = =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 = wrote: > And then, for p=3Dnone or any equivalent form of it, there is no need = or established practice for mungling, while for > p=3Dreject; pct=3D0, or any equivalent form of it, there is mungling. >=20 > This is the current specification. I proposed on this regard in fact = two things: > - specifying that p=3Dquarantine; pct=3D0 (email from 10th May to = dmarc@ietf) the MLM does mungling > - abolishing policy quarantine >=20 > That is: p=3Dreject; pct=3D0 gets almost the same as p=3Dnone, except = that there is recommendatiton for MLM to mungle From:. >=20 > I'm a little worried about this, but maybe it's just The Way Of = Things. We had intended the publication of a DMARC policy to be a = message from the ADMD owning a domain name to any ADMD receiving mail = from it about how to handle unauthenticated or unaligned messages. It's = actually morphed on its own into also being a message to any MLM that = might be in the way to take particular rewriting actions. I wonder if = the standards track version of DMARC should explicitly take this into = account.. >=20 > -MSK >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Jul 24 16:07:01 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 4E6F3120103 for ; Wed, 24 Jul 2019 16:07:00 -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 qFTd7ozTgYwW for ; Wed, 24 Jul 2019 16:06:59 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D181B12006E for ; Wed, 24 Jul 2019 16:06:58 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id z15so28817943lfh.13 for ; Wed, 24 Jul 2019 16:06:58 -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=e3lcNhRvJC1DJ3phl414aEJSsBC7dv0e93gG17Jzy0k=; b=ZknPnP3jO6SCQTssycVR4I7Y7Dos2m22eQxGwRiU1Zb2DgcKVDVVl5VIK0fHaOqH3E A3kkRWef+MJcqUjzlWHU1Ey0st0n98SwWbqSeexTo1/j1ywjYOYOz1Thz0yegd/ISEwl 4AEjsDG8QorlApOWUHh+Y5GPd1BuvcXlU92w7qCgU/AYeKGDshrf2hu21CgOnyjPJ20D 6djOxWSZdx0YuABhLAv/dGE924r3DxSLdxaQECUvPhZtnS49ADHT7IlyzBdOBychQeEV R3QIL3AjXr/PKy7zZHQZ0EyxrMVSMuzcEFbodMxkwHowmaZGmBBkQtFeLeQ61sXy9meb 5D9g== 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=e3lcNhRvJC1DJ3phl414aEJSsBC7dv0e93gG17Jzy0k=; b=iDvLpO0H4sAdnqHVGPjnZ7W9SE4BfUthVTxPuP9IGYiQZ+NcqWOf6LsSx4jH3COVE5 b94re3BaqmRg2g2KoPHfEQGndBE1hlCU2gWcXxFQKu9so8UZDNZYzdk0553LaKIFCcHN 7Xby0bwatSFfk9LOOmZMz4L4EaXg68Uc9b0KyvxAfEhG/dQ2hTWVXey2bXzmFb7ZWNUQ 8a4p121/GJ7/RWcW3OcFFjRupCUfeT1IOqnH45JrHN6wCguMXNtYnQ0eHZ5UX8eN2LTG WCHxbDFDl80ujGkm2pOigSnnLJ9n5aNzFqmLZRcByO4J01toUH2yo1vuSs/67SvtbKyl Ydgw== X-Gm-Message-State: APjAAAXLl5rGx51Ov/qap0y6F34qTvF6J6uMik8uRAVjM5hzgqSzkpVl 6sfkWtibILcB4VtDwUhuvRK4DDjestMEmWeY4oOoWV3I+FI= X-Google-Smtp-Source: APXvYqxHFHsfT9EY7c5aOWuh6FNqIprXi8xu5Ljpu17DLQcg641gQYPHgS03THlACHwimK23ct2pyJm3mgjdi/KBX+o= X-Received: by 2002:a19:7006:: with SMTP id h6mr38958873lfc.5.1564009616964; Wed, 24 Jul 2019 16:06:56 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> In-Reply-To: <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> From: "Murray S. Kucherawy" Date: Wed, 24 Jul 2019 19:06:44 -0400 Message-ID: To: Steve Atkins Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a50c6b058e755de3" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 23:07:00 -0000 --000000000000a50c6b058e755de3 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins wrote: > > It's interesting that the industry has decided to interpret "p=reject; > pct=0" the way we intended "p=quarantine; pct=100". > > It's semi-explicitly defined that way in the RFC, isn't it? > If so, we should fix it because (a) I don't think that's how we intended it, and (b) in any case, nothing in there should be only semi-explicit. -MSK --000000000000a50c6b058e755de3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000a50c6b058e755de3-- From nobody Wed Jul 24 16:27:26 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 74C541202B9 for ; Wed, 24 Jul 2019 16:27:25 -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 GimxrYy44mpE for ; Wed, 24 Jul 2019 16:27:23 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 4DA8E12006E for ; Wed, 24 Jul 2019 16:27:23 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id p13so48648755wru.10 for ; Wed, 24 Jul 2019 16:27:23 -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=cZ9vxupbeY/s2iQcGaFBsOwyLPfauycTORRXYw/XNCk=; b=Lv2NlLvSmzN/E+G98U1hGsmvJDBzMD2A0WdUUlfZ4Dk/+JbbCXo/cAT9k3ai3jHfLK MK82EmGXVbv+6ueFGt/jSpmLmshg+oA2Y0fpps9P//1irJNjZofYWyUQDj6Ro2s7pby4 yRspfUtDa2H67hyfUupIumx+aPuJ8mjz/D+fTnjoKbUls5w/6n66wi8h4zj9fpLkyvF/ P/HRgCm1dJFknks9jqkHSpqxio9cQ2U5uIp5yfsvt995g0a+xzv8kUuXOBOHFgBajH1u oc2aCGXbXcq7MKI/PRpjTXrms6dKrVaJ2S+DEr5rx2ZC0J0Inn5d8MiYebsKcFHm3Ds2 2qqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cZ9vxupbeY/s2iQcGaFBsOwyLPfauycTORRXYw/XNCk=; b=dqidxmR16sLGaBHoNYBbFfjw59IfkimWBxIVAeWNeSgOwtXnEarVSyomeM9in587Bv D/8VjvnoLF+elAuT5L1QSNu9HQxD2l4ZfKGBYSsP5fe44oj3DtrDkVdBSjmy9P5BM5Ik UIY1/I2Tf9M41Gob4zx5T9LYKHbe8gh2J4QsEtyJqDSmN1/sEGNiG4x+bX3ZGnE8Wzot /obUsnu7i/jJKkYklMGXTBU4KzJag0w0hqLabQ4hoUawE4+kqccslRk1zsPgavCh7MOH 4j2CP9y8V+kC+22OdxZl54lvGkPcSFS/Rma63crZ3BCH/ihDEmwI74sRJ/4BwI8KIFB2 /fdQ== X-Gm-Message-State: APjAAAWjfY6yBx6zOVO3wOCLjkz4WIInO8P945GRsonplooGaIp1S0uU sM0nelIrBNxB3TrkGwwbIPIzHwgGC3Uth2xaO4w= X-Google-Smtp-Source: APXvYqx6DlZbfXyn63tnOj6pllafTD4dPFOQimUK2ZcLCKbDHmwmbd7lt6hzYAvkLY2yAvd5K4wyf+lvZfCb739BLfQ= X-Received: by 2002:a5d:4484:: with SMTP id j4mr89997806wrq.143.1564010841821; Wed, 24 Jul 2019 16:27:21 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> In-Reply-To: From: Dotzero Date: Wed, 24 Jul 2019 19:27:11 -0400 Message-ID: To: "Murray S. Kucherawy" Cc: Steve Atkins , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a6d54e058e75a611" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 24 Jul 2019 23:27:26 -0000 --000000000000a6d54e058e75a611 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 24, 2019 at 7:07 PM Murray S. Kucherawy wrote: > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins > wrote: > >> > It's interesting that the industry has decided to interpret "p=reject; >> pct=0" the way we intended "p=quarantine; pct=100". >> >> It's semi-explicitly defined that way in the RFC, isn't it? >> > > If so, we should fix it because (a) I don't think that's how we intended > it, and (b) in any case, nothing in there should be only semi-explicit. > > -MSK > _______________________________________________ > My recollection is that we definitely did not intend that. Michael Hammer --000000000000a6d54e058e75a611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 24, 2019 at 7:07 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins <steve@wordtothewise.com> wrote= :
> It's intere= sting that the industry has decided to interpret "p=3Dreject; pct=3D0&= quot; the way we intended "p=3Dquarantine; pct=3D100".

It's semi-explicitly defined that way in the RFC, isn't it?

If so, we should fix it because (a) I don&= #39;t think that's how we intended it, and (b) in any case, nothing in = there should be only semi-explicit.

-MSK
=
_______________________________________________

My recollection is that we definitely did not intend that.=C2=A0

Michael Hammer
--000000000000a6d54e058e75a611-- From nobody Thu Jul 25 05:54:02 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 7D05F12015F for ; Thu, 25 Jul 2019 05:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=wordtothewise.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 9Rjavrzjm7Av for ; Thu, 25 Jul 2019 05:53:58 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id BD38A12002E for ; Thu, 25 Jul 2019 05:53:58 -0700 (PDT) Received: from [192.168.0.88] (unknown [37.228.251.105]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 9C0049F146; Thu, 25 Jul 2019 05:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1564059238; bh=7QlRqdBKGjtA7QvqBvIO9yz7Y7juKUrJG7V0AHL1Egs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=lQRBL0kB8jPSLoDARpi18cK6ZPjaIS2kv4LfKr1kmGLH4uWOwP1FZmh0dMnFYMdjp wHGUejGZW09F54CsYLvk87ECda/9SqNWLISAtLc07VVneULbfct4+PdeWf/LTA7UR0 EojEBRji1WCSTsmYtDVPz4PGvGIojYNoj5qvQqv8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Steve Atkins In-Reply-To: Date: Thu, 25 Jul 2019 13:53:55 +0100 Cc: IETF DMARC WG Content-Transfer-Encoding: quoted-printable Message-Id: <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 25 Jul 2019 12:54:01 -0000 > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy = wrote: >=20 > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins = wrote: > > It's interesting that the industry has decided to interpret = "p=3Dreject; pct=3D0" the way we intended "p=3Dquarantine; pct=3D100". >=20 > It's semi-explicitly defined that way in the RFC, isn't it? >=20 > If so, we should fix it because (a) I don't think that's how we = intended it, and (b) in any case, nothing in there should be only = semi-explicit. rfc 7489 6.6.4 "If email is subject to the DMARC policy of "reject", the Mail Receiver SHOULD reject the message (see Section 10.3). If the email is not subject to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies. This behavior allows Domain Owners to experiment with progressively stronger policies without relaxing existing policy." It's pretty clear and well-defined; the case we're talking about, = "p=3Dreject; pct=3D0", is just a special case of this general rule. All emails will not be subject to the "reject" policy due to the pct=3D0 = tag, so the mail receiver should treat all emails as though the policy "quarantine" = applies (which is the same as "p=3Dquarantine; pct=3D100"). Cheers, Steve= From nobody Fri Jul 26 07:30:44 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 904F61200CE for ; Fri, 26 Jul 2019 07:30:42 -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 vKtOztD2RPAn for ; Fri, 26 Jul 2019 07:30:40 -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 8FAA71200B9 for ; Fri, 26 Jul 2019 07:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564151436; bh=CmOWQlCSHRtm8gEpHopdDkYX0inS2jMy9UDFBswjFw4=; l=2923; h=To:References:From:Date:In-Reply-To; b=DfSndzUC2TENubqweW3wEqsaAFZ6XFgvJV6teaCNpJdfiP5f+4yix5thRf7y5mNAW Eck7tNtlwQF6pXrPiv0YV2zYMOykz8PtBsQaBNaEG6Jn5M2feotA5bZ/dPohhF2JrS UzkQBFspWT60ZOGFcWjnSMNrt7Picfgiw+yLwgtn1e29eNjkUnxQ4k5YHBsnj 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 00000000005DC064.000000005D3B0E8C.0000679F; Fri, 26 Jul 2019 16:30:36 +0200 To: dmarc@ietf.org References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> Date: Fri, 26 Jul 2019 16:30:36 +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: <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 26 Jul 2019 14:30:43 -0000 On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote: >> On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy wrote: >> >> On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins wrote: >> > It's interesting that the industry has decided to interpret "p=reject; pct=0" the way we intended "p=quarantine; pct=100". >> >> It's semi-explicitly defined that way in the RFC, isn't it? >> >> If so, we should fix it because (a) I don't think that's how we intended it, and (b) in any case, nothing in there should be only semi-explicit. > > rfc 7489 6.6.4 > > "If email is subject to the DMARC policy of "reject", the Mail > Receiver SHOULD reject the message (see Section 10.3). If the email > is not subject to the "reject" policy (due to the "pct" tag), the > Mail Receiver SHOULD treat the email as though the "quarantine" > policy applies. This behavior allows Domain Owners to experiment > with progressively stronger policies without relaxing existing > policy." > > It's pretty clear and well-defined; the case we're talking about, "p=reject; pct=0", is > just a special case of this general rule. > > All emails will not be subject to the "reject" policy due to the pct=0 tag, so the mail > receiver should treat all emails as though the policy "quarantine" applies (which > is the same as "p=quarantine; pct=100"). I, for one, had missed that point. Thanks for clarifying it. It seems to mean that the resulting steps are, for example: "p=quarantine; pct=0" (check From: rewriting) "p=quarantine; pct=10" (some messages go to the spam folder) "p=quarantine; pct=20" ... "p=quarantine; pct=100" "p=reject; pct=0" (same as the previous step) "p=reject; pct=10" (some messages bounce back) "p=reject; pct=20" ... Is that what we want to suggest? In that case, we should be clearer. Perhaps by adding an example in a new appendix. However, I hardly see the above sequence as progressive. I had always considered quarantine and reject to be two more or less similar alternatives. Each has its merits and shortcomings, and can be chosen according to a sender's needs. An advantage of reject is that one gets NDNs, which are much more universally adopted than failure reports. Perhaps a bank or similar transactional sender would rather prefer reject, because they can timely resend bounced transactions or notices thereof in order to have their duties accomplished. OTOH, quarantine lets one forget about delivery, perhaps with a backhanded thought of recipients rummaging through their spam folders in search of a missing message. That style seems to me to better suit ESPs, whose duty is rather to have a lot of mails sent than to make sure that each message is acknowledged, albeit they try and maximize the ratio. IMHO, by abolishing quarantine, we make the protocol less flexible than it is. Best Ale -- From nobody Fri Jul 26 10:15:05 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 2DEE4120071 for ; Fri, 26 Jul 2019 10:15:03 -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=iBaMWW8x; dkim=pass (2048-bit key) header.d=kitterman.com header.b=hQiAq5oI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWv2LLarf4LZ for ; Fri, 26 Jul 2019 10:15:01 -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 88BDF120041 for ; Fri, 26 Jul 2019 10:15:01 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 9C7ABF80779 for ; Fri, 26 Jul 2019 13:14:30 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564161270; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eW7sg4ohCn2Ddb4hg+gHfhbiP6eLp3c3mkrhk7XSTOk=; b=iBaMWW8xdbU7Wc1k4q5P4JQ4TiIZGKOoAFqxxm+88CUGOTTI/rSKD97W 4t97grh8Uc9XwMtUH1WywCLppdDbAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564161270; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eW7sg4ohCn2Ddb4hg+gHfhbiP6eLp3c3mkrhk7XSTOk=; b=hQiAq5oIS6A0aVTFMt1iFgQMfLKthiyrXhhJ+GrTszFX5acfLTWWLUBw NTVCwWmc79ubTqHWzVmNGxOXS5LR71gaP0fZbDo/bGb5iaed0t/xPI9B3j agunIWfUcYxxAiyaI8NccdeMbD4Jz3Hh5ldaDopq++rAXWrHFxXnkCGeOz SmA72ptIDJT4qDqMytxtIN4w2ncheDISf+jKVX06BM6h83qmzugYN04rBX s01qRIELo36urx4yv1BPZf39l4EHviqEVUj2Ghul+58ZJ/Qz2y379Wy6// kCMK7EgxKwON00hXpzyo3vZREXpFsBk9znL43CsLSk9lEkAt/GQxRw== 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 680C7F80777 for ; Fri, 26 Jul 2019 13:14:30 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 26 Jul 2019 13:14:30 -0400 Message-ID: <1797094.jKfzk300iR@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 26 Jul 2019 17:15:03 -0000 On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote: > Reviewing as the document shepherd: Thanks. I've been working on document updates based on the last call discussion as I have time (xml is in the WG github repo). I think some of these comments will be OBE to those changes, so my plan is to finish LC based updates, review your comments, make additional changes as needed, and then ask for further discussion/clarification if I'm unsure how to proceed. I expect to have that done today. Scott K From nobody Fri Jul 26 13:09:28 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 E435112019F for ; Fri, 26 Jul 2019 13:09:17 -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=FHmV2CW/; dkim=pass (2048-bit key) header.d=kitterman.com header.b=jyGXccsn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zxj7ovBeR02 for ; Fri, 26 Jul 2019 13:09:14 -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 D5FDB1201CB for ; Fri, 26 Jul 2019 13:09:13 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id D27FFF80758 for ; Fri, 26 Jul 2019 16:09:12 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564171752; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=mTgk4sUSmeFfFGbOsLuoaIMqrb0p8pg0WqkA97XCHr0=; b=FHmV2CW/zkiMNn2YiY67IZjkITjFcEtXFNKg5umtWIXmozy0WcE3b/WT xdX2YKjzluB9mIwSP6GlUx7XFVhBAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564171752; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=mTgk4sUSmeFfFGbOsLuoaIMqrb0p8pg0WqkA97XCHr0=; b=jyGXccsnL7NsXm4XlnV8yVMwE4AZ2lnSb681RPsNu11uU0iFpqTJRlho LjoVIGkkqYe9mulHGQWnDZxXoO77mA/Pg8UKDd9i0kmYMR4qQSAopedFJf vC1cjKAyGH1uUpWNUU9zH5WQg1qJpc9eo3nRcx+0tnhVropSfudesjZvRR gZXoPCJ+HxkGCRgOvmVMEYkOuFVJ92quGyrdlpoWsY3YRzPnl8QHOZRy+5 mW+QZLMHMW7bwGBJsM7TCvNEsKuHglWyP5wJ4k/pCzWDBBmLBZmQ6BqcOB P6pwF+mY4+hHNP+7HTKSREEm10dXUM4MUBL94uJ+7+OmtTVjWgE2hA== 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 8FB63F80096 for ; Fri, 26 Jul 2019 16:09:12 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 26 Jul 2019 16:09:12 -0400 Message-ID: <2041955.pyEi75ef7K@l5580> In-Reply-To: <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> References: <155899759708.543.16777184314234317178@ietfa.amsl.com> <2350589.KE7Alnpban@l5580> <9BEE40D3-738E-49F2-B882-74905A7B5368@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-04.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 20:09:26 -0000 On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote: > > On May 27, 2019, at 6:59 PM, Scott Kitterman wrote: > > > > On Monday, May 27, 2019 6:53:17 PM EDT internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Domain-based Message > >> Authentication, Reporting & Conformance WG of the IETF. > >> > >> Title : DMARC (Domain-based Message Authentication, > >> > >> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) > >> Author : Scott Kitterman > >> > >> Filename : draft-ietf-dmarc-psd-04.txt > >> Pages : 11 > >> Date : 2019-05-27 > > > > There isn't much to this update. It corrects one typo and reverts the RUF > > MUST NOT as discussed on the list. As far as I'm aware there are no other > > pending issues in the WG with the draft. > > Hi Scott, I've reviewed the doc and have made some comments. Feel free to > dispose of them as you will. > > I had a hard time with the introduction. "sets of domains within a single > organization" and "lower level policy" left me not knowing what I was > reading. I'm unhappy just complaining, so I took a stab at this admittedly > difficult section. The original: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and sets of domains > within a single organization. For domains above the organizational > level in the DNS tree, policy can only be published for the exact > domain. There is no method available to such domains to express > lower level policy or receive feedback reporting for sets of domains. > This prevents policy application to non-existent domains and > identification of domain abuse in email, which can be important for > brand and consumer protection. > > My stab: > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and for organizational > domains and their sub-domains > within a single organization. For TLDs and domains that exist between > TLDs and organization level domains, policy can only be published for the > exact domain. No method is available for such domains to express > policy or receive feedback reporting for sub-domains. > This missing method allows for the abuse of non-existent > organizational-level domains and prevents identification of domain abuse in > email. Incorporated. > > The example section doesn't read like the rest of the draft and was hard for > me to read through. Original: > > This would provide policy and feedback for mail sent from > @gov.example, but not @tax.gov.example and there is no way to publish > an organizational level policy that would do so. While, in theory, > receivers could reject mail from non-existent domains, not all > receivers do so. Non-existence of the sending domain can be a factor > in a mail delivery decision, but is not generally treated as > definitive on its own. > > Again my stab: > > This DMARC record provides policy and a reporting destination for mail > sent from @gov.example. However, due to DMARC's current method of > discovering and applying policy at the organizational domain level, the > non-existent organizational domain of @tax.gov.example does not and cannot > fall under a DMARC policy. Incorporated. > > I don't have too much more, I just got just caught up in the initial read. > This paragraph contains a construct that was confusing to me: > > This memo provides a simple extension to DMARC [RFC7489] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > ^^^ why "groups of subdomains" and not just "subdomains"? One step further, > why not "express policy at the level of the PSD that covers all > organizational domains that do not explicitly publish DMARC records"? Incorporated. > > OK, two more things: > > 2.3. Longest PSD > > Organizational Domain (DMARC [RFC7489] Section 3.2) with one label > removed. > > ^^^ "one left-most label removed"? Incorporated. > > Last thing: Security considerations might call out DNS cache poisoning as a > way to get reports for a PSD. Applies to vanilla DMARC too, but the scope > and potential breadth of information with PSD-DMARC is really interesting. > I imagine an attack that gets .COM listed into the PSD Registry for a > specific report generator.. combined with cache poisoning and the poor > report generator would probably explode at best. I added this to security considerations (and the new informational reference): The risks of the issues identified in [RFC7489], Section 12.3, DNS Security, are amplified by PSD DMARC. In particular, DNS cache poisoning (or Name Chaining), see [RFC3833] for details, consequences are increased because a sucessful attack would potentially have a much wider scope. Thanks, Scott K From nobody Fri Jul 26 13:27:40 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 89DA6120071 for ; Fri, 26 Jul 2019 13:27:39 -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=PvQ+2q3t; dkim=pass (2048-bit key) header.d=kitterman.com header.b=XfgCtsVb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zlcE0uPW5wz for ; Fri, 26 Jul 2019 13:27:37 -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 75A18120047 for ; Fri, 26 Jul 2019 13:27:37 -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 5B83DF80758 for ; Fri, 26 Jul 2019 16:27:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=PvQ+2q3t7C6FCFVmuWOUFpYkoPNTOITVCV0J4D2PkpI6KtwzTrUu/mcm IgjJng9jSzmVPMT0x/TEHyvwWKI4Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564172856; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=5STRWSK1maI/fIBdLmyKEnLHPvL60JVuysly+zx1acM=; b=XfgCtsVbVs1jj5ircyjv8+XHE8Umgs7Aut7ouNMeyGnvk7OayFqcm0Yk RZsFp6Q3MsFKuydIOTcTze18LveA8fRCgZD+DET37HrAi5H+WPE+jACckY 7AZcmGAsIdZcT2HzjukOhXSyKswRoWs5Vp3Txvw0q46YlcNGuGMh5boK0N tiiURG5OeTw2D2xgdjjGY7pKtpPWR151KmtPJygHmE3rjwDrJsvZ6w0yj4 tb0Q8il5ZfU/5uyhIrB+1AmZ5fDJl10g/2yVvLX+NZbg5mYIVoTY+I8Z69 BpzJ9XinqYTyk41n85k8y2g5XbX0hqml32k1XaW6c96wfxhA6MxHCw== 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 29279F80096 for ; Fri, 26 Jul 2019 16:27:36 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 26 Jul 2019 16:27:35 -0400 Message-ID: <2236077.6bFe0TRX2e@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] LC feedback on draft-ietf-dmarc-psd-04 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, 26 Jul 2019 20:27:40 -0000 On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote: > Please note that I did not review Tim's comments in detail so some of the > following points may have been covered by him previously. > > *Page 2 contains the following paragraph:* > > This memo provides a simple extension to DMARC [RFC7489 > ] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489 > ] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > This extension does not really allow PSDs to express policy for > "groups of subdomains" unless you take the perspective that "all or > none" are groups. Perhaps altering the language to say "...to express > policy that would apply to subdomains..."? I think the changes I just pushed in response to Tim's comments address this. > *The very end of section 1 says:* > > DMARC [RFC7489 ], by design, > does not support usage by PSOs. For PSDs > that require use of DMARC [RFC7489 > ], an extension of DMARC > reporting > and enforcement capability is needed for PSO to effectively manage > and monitor implementation of PSD requirements. > > I still fail to see how this proposal is necessary (or, potentially > even useful) for the PSO to perform enforcement of their policies. I'd > recommend either deleting the entire paragraph or refocusing the > second sentence around the brand protective role that this proposal > brings for abuse of non-existent subdomains below the PSD. Agreed. Deleted. > *Section 2.2* "PSD DMARC includes all public domains..." --> suggest > "PSD DMARC applies to all public domains..." Incorporated. > *Section 2.6* "...that a receiver is willing to accept" seems like it > opens up a wide area if one applies considerations like > DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this > topic so I'll defer to that thread. This went away due to that discussion. > *Section 3* should include the new "np" keyword as an update to the DMARC > spec. Added based on the no existent domain sub-thread. > *Section 3.5* This call-out makes it seem like information about > non-existent domains is not desirable and useful for org-level DMARC. > Can we modify the language to remove that implication? Perhaps "...is > desirable and useful, just as it is for org-level DMARC operators." Incorporated. > *Section 4* Neglects the privacy implications of broken "receiver is > willing to accept" conditions that may lead to additional leakage. > Also in the third bullet point, "it's feedback" should not have an > apostrophe. OBE, related text is removed. Typo got fixed somewhere along the way. Thanks, Scott K From nobody Sat Jul 27 13:45:35 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 7C6B5120096 for ; Sat, 27 Jul 2019 13:45:33 -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=nQ09FXpb; dkim=pass (2048-bit key) header.d=kitterman.com header.b=o06TAzWN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRgkJWfLfr0M for ; Sat, 27 Jul 2019 13:45:30 -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 D812D120075 for ; Sat, 27 Jul 2019 13:45:29 -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 CCD52F8071A for ; Sat, 27 Jul 2019 16:44:58 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564260298; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0WQ7yBiKhI1PGDC7nNuB3yFDW3ZMxI5y4lMUIEDIrq4=; b=nQ09FXpbuYLAUYHerw4bQEAuvQqShApGccXo5V/KIAwixy4RvncD2VD+ a+0KSkTSNhziyU7Q6p9CVTpOXFe+CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564260298; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=0WQ7yBiKhI1PGDC7nNuB3yFDW3ZMxI5y4lMUIEDIrq4=; b=o06TAzWNw+kOoWQBU0EnWsNKIcOq+EZh/ine8GX/XMP0L5TTQ+aWaPGl e7r4U0pSFXHj0pwV0LvgpUPJVePRAX+GnbCeBOnZ4nFCUEVjfc1fkOkJ6W rkhGwBv9MQWQpOaov2Z2yGxdT3v/+17321SPBrRlmNRJAXWxUdIKTPHY2e NL+v6/vfrNaWGIV0nMK6b1pJ8ItICdeb3jI6QSNSpu6oshWT3VxUIySxTR KIh/8pv8A6Vq86DiKYFuDDYameM0rBBzblGFTMKqMT5cuvDio2i0S6wqzW 6emkL887gk7SwlMuzQRp/HaMl+1CCr/Ken1nhfK1s0SYmi+VYqTLLg== 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 8FE0FF80096 for ; Sat, 27 Jul 2019 16:44:58 -0400 (EDT) From: Scott Kitterman To: IETF DMARC WG Date: Sat, 27 Jul 2019 16:44:58 -0400 Message-ID: <4195597.6UoUMpgHb9@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 27 Jul 2019 20:45:34 -0000 On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote: > Reviewing as the document shepherd: > > Abstract > > [...] > organization can use to improve mail handling. DMARC policies can be > applied at the individual domain level or for a set of domains at the > organizational level. > > I think the abstract is a bit too abstract. Which set of domains? > > > The design of DMARC precludes grouping > policies for a set of domains above the organizational level, such as > TLDs (Top Level Domains). > > Is that the same set? I updated the paragraph to start: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied to individual domains or to all domains within an organization. The design of DMARC precludes grouping policies for domains based on policy published above the organizational level, such as TLDs (Top Level Domains). Does that clear those comments up? > These types of domains (which are not all > at the top level of the DNS tree) can be collectively referred to as > Public Suffix Domains (PSDs). > > What "types" are there? Changed to: organization. The design of DMARC precludes grouping policies for domains based on policy published above the organizational level, such as TLDs (Top Level Domains). Domains at this higher level of the DNS tree (but not necessarily at the top of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). > For the subset of PSDs that require > DMARC usage, this memo describes an extension to DMARC to enable > DMARC functionality for such domains. > > What's the requirement? Given that the document no longer contains such a constraint, I've updated my working copy to say: This memo describes an extension to DMARC to enable DMARC functionality PSDs. > 1. Introduction > > DMARC [RFC7489] provides a mechanism for publishing organizational > policy information to email receivers. DMARC [RFC7489] allows policy > to be specified for both individual domains and sets of domains > > Which sets? > Comment is OBE based on previous changes. > within a single organization. For domains above the organizational > level in the DNS tree, policy can only be published for the exact > domain. There is no method available to such domains to express > lower level policy or receive feedback reporting for sets of domains. > > Still too abstract. I don't know what sort of set groupings you might > be after here. I think the new text is better. Please check and let me know if it's there yet or not. > This prevents policy application to non-existent domains and > identification of domain abuse in email, which can be important for > brand and consumer protection. > > As an example, imagine a country code TLD (ccTLD) which has public > subdomains for government and commercial use (.gov.example and > .com.example). Within the .gov.example public suffix, use of DMARC > [RFC7489] has been mandated and .gov.example has published its own > DMARC [RFC7489] record: > > "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" > > Can we add spaces after the semicolons? I know this is legal format > but it would be more readable. Changed. > This memo provides a simple extension to DMARC [RFC7489] to allow > > s/memo/document/g Changed throughout. > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489] policy query > > "groups of subdomains" suggests the capability of creating a policy > that applies to parts of the subtree only, or different policies for > different parts of the subtree. If that's not what we're actually > defining here, this should be reworded. OBE to previous comments. > As an additional benefit, the PSD DMARC extension will clarify > > s/will clarify/clarifies/ Changed. > existing requirements. Based on the requirements of DMARC [RFC7489], > DMARC should function above the organizational level for exact domain > matches (i.e. if a DMARC record were published for 'example', then > mail from example@example should be subject to DMARC processing). > Testing had revealed that this is not consistently applied in > different implementations. PSD DMARC will help clarify that DMARC is > > s/will help clarify/clarifies/ Changed. > ....and saying it twice in the same paragraph is probably not necessary. And then deleted the sentence. > > not limited to organizational domains and their sub-domains. > > There are two types of Public Suffix Operators (PSOs) for which this > extension would be useful and appropriate: > > o Branded PSDs (e.g., ".google"): These domains are effectively > Organizational Domains as discussed in DMARC [RFC7489]. They > control all subdomains of the tree. These are effectively private > domains, but listed in the Public Suffix List. They are treated > as Public for DMARC [RFC7489] purposes. They require the same > protections as DMARC [RFC7489] Organizational Domains, but are > currently excluded. > > How are they current excluded? Is this because they're on the PSL, so > DMARC treats them differently? Yes. Per the DMARC definition, they are not organizational domains. > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > Because existing Organizational Domains using this PSD have their > own DMARC policy, the applicability of this extension is for non- > existent domains. The extension allows the brand protection > benefits of DMARC [RFC7489] to extend to the entire PSD, including > cousin domains of registered organizations. > > An example would be useful here. I've added this: As an example, take the ".gov.example" described above and add that for this entity emails about tax returns are sent from tax.gov.example. It would not be surprising if fraudulent emails were sent purporting to be from taxes.gov.example (taxes is a cousin of tax - different enough to evade DMARC protection, but similar enough to potentially confuse users). As defined in DMARC [RFC7489], a DMARC record could be published for tax.gov.example, but there is no general solution to publishing a DMARC policy to defend against abuse of non-existent cousins such as taxes.gov.example. While an explicit record could be published for this one domain, the universe of possible cousins is such that this approach does not scale. How's that? > Due to the design of DMARC [RFC7489] and the nature of the Internet > email architecture [RFC5598], there are interoperability issues > associated with DMARC [RFC7489] deployment. These are discussed in > Interoperability Issues between DMARC and Indirect Email Flows > [RFC7960]. These issues are not applicable to PSDs, since they > (e.g., the ".gov.example" used above) do not send mail. > > DMARC doesn't need to be followed by its RFC number every time. I went through and removed most of these. I tried to remove them so that it's mostly there when talking about DMARC the RFC, not DMARC the protocol. > 2.2. Public Suffix Domain (PSD) > > The global Internet Domain Name System (DNS) is documented in > numerous Requests for Comment (RFC). It defines a tree of names > starting with root, ".", immediately below which are Top Level Domain > names such as ".com" and ".us". They are not available for private > registration. In many cases the public portion of the DNS tree is > more than one level deep. PSD DMARC includes all public domains > above the organizational level in the tree, e.g., ".gov.uk". > > I don't know what that last sentence means. PSD DMARC is an > extension; how does it include domains? Deleted the sentence. I don't think it is necessary for the definition, so let's not confuse things. > 2.4. Public Suffix Operator (PSO) > > A Public Suffix Operator manages operations within their PSD. > > s/their/its/; "operator" is singular. Changed. > 2.6. Non-existent Domains > > For DMARC [RFC7489] purposes, a non-existent domain is a domain name > that publishes none of A, AAAA, or MX records that the receiver is > willing to accept. This is a broader definition than that in > NXDOMAIN [RFC8020]. > > Is there any discussion that could be referenced about DNS RRs that > one is not willing to accept? OBE. Removed that from the definition based on the WGLC discussion about the definition. > 3.2. Section 6.1 DMARC Policy Record > > PSD DMARC records are published as a subdomain of the PSD. For the > PSD ".example", the PSO would post DMARC policy in a TXT record at > "_dmarc.example". > > Don't you mean the PSD DMARC record is a record in the zone of the > PSD? It's not a subdomain. Here's what's in RFC 7489 about DMARC record publishing: 6.1. DMARC Policy Record Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". I think our 3.2 is equivalent and adequate given this section is a modification to RFC 7489 Section 6.1. I did not make a change. > 3.3. Section 6.5. Domain Owner Actions > > In addition to the DMARC [RFC7489] domain owner actions, PSOs that > require use of DMARC ought to make that information available to > receivers. > By what mechanism? Changed to: In addition to the DMARC domain owner actions, PSOs that require use of DMARC and participate in PSD DMARC ought to make that information available to receivers. The mechanism for doing so is one of the experimental elements of this document. See the experiment description (Appendix A). > 3.4. Section 6.6.3. Policy Discovery > > A new step between step 3 and 4 is added: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > Organizational Domain is one that the receiver has determined is > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > a DMARC TXT record at the DNS domain matching the longest PSD > (Section 2.3) in place of the RFC5322.From domain in the message > (if different). A possibly empty set of records is returned. > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I > don't know what "acceptable for PSD DMARC" might mean. Changed to: 3A. If the set is now empty and the longest PSD (Section 2.3) of the Organizational Domain is one that the receiver has determined is acceptable for PSD DMARC (discussed in the experiment description (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the longest PSD (Section 2.3) in place of the RFC5322.From domain in the message (if different). A possibly empty set of records is returned. > Section numbers in the prose of this section should make clear which > document they're referencing. I checked and any reference to an RFC7489 paragraph number that's in the text is labeled as such. > > 3.5. Section 7. DMARC Feedback > > Operational note for PSD DMARC: For PSOs, feedback for non-existent > domains is desired and useful. See Section 4 for discussion of > Privacy Considerations. > > Section 4 of which document? Added 'of this document'. > 4. Privacy Considerations > > These privacy considerations are developed based on the requiremetns > > typo > > of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this > document. > > 4.1. Feedback leakage > > Providing feedback reporting to PSOs can, in some cases, create > leakage of information outside of an organization to the PSO. This > leakage could be potentially be utilized as part of a program of > > Remove one of the "be"s. Fixed. > pervasive surveillance (See [RFC7624]). There are roughly three > cases to consider: > > o Single Organization PSDs (e.g., ".google"), RUA and RUF reports > based on PSD DMARC have the potential to contain information about > emails related to entities managed by the organization. Since > both the PSO and the Organizational Domain owners are common, > there is no additional privacy risk for either normal or non- > existent Domain reporting due to PSD DMARC. > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > PSD DMARC based reports will only be generated for domains that do > not publish a DMARC policy at the organizational or host level. > For domains that do publish the required DMARC policy records, the > feedback reporting addresses (RUA and RUF) of the organization (or > hosts) will be used. The only direct feedback leakage risk for > these PSDs are for Organizational Domains that are out of > compliance with PSD policy. Data on non-existent cousin domains > would be sent to the PSO. > > This is the second use of "cousin domain". An example here or at the > first use might be a good idea. Added at first use. And that's the last comment. I intend to post a revision shortly so the group can more easily review my proposed changes based on WGLC. Scott K From nobody Sat Jul 27 13:53:08 2019 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFE3120182; Sat, 27 Jul 2019 13:52:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <156426077328.27951.7009843288904292537@ietfa.amsl.com> Date: Sat, 27 Jul 2019 13:52:53 -0700 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-05.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 20:52:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) Author : Scott Kitterman Filename : draft-ietf-dmarc-psd-05.txt Pages : 14 Date : 2019-07-27 Abstract: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. DMARC policies can be applied to individual domains or to all domains within an organization. The design of DMARC precludes grouping policies for domains based on policy published above the organizational level, such as TLDs (Top Level Domains). Domains at this higher level of the DNS tree (but not necessarily at the top of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality PSDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-psd-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 27 15:00: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 6B6CC12008C for ; Sat, 27 Jul 2019 15:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=JdSU0m7a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NeBQ5lC+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g15u6oQ7nobo for ; Sat, 27 Jul 2019 15:00:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F7B12007A for ; Sat, 27 Jul 2019 15:00:37 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CBB5621B1B for ; Sat, 27 Jul 2019 18:00:36 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Sat, 27 Jul 2019 18:00:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=gOYazr+ea+2q0+bHi6hkrSSufd6LLMn gSVDov/2wEIE=; b=JdSU0m7aYjF+3ScQ7xxwNSH6zaZppiuaZIQmJYK+CKvXF41 T4ydjTIju1peBX9fLk7my00OVFIF1FvzqEDB3sM+IkUNaqP2e9eJoDJhYv8YA/uU 34ma25ZA1CHK6P6bsLTZghmgwiU04ifkBcyluhoA58cGE7VpeXQB72K1TzrLxvXi aMTrlYuLIcclcmZ9eUx2bK8hTUX4gKuY+scDk5pQ/u33xxbj2TDA6RfRxi9sfPK7 Sn0eBIxCoaP1GCl41EJEneQ23ojUkNk4/0QLINN6pjuKctJEUJg9WwysCSvlceYO 41s+BGUVRnm/GJ+RpYeU/RaxLU/HhoWfx1slfXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gOYazr +ea+2q0+bHi6hkrSSufd6LLMngSVDov/2wEIE=; b=NeBQ5lC+aoQpN/elH33e7g mHH8Ndtlfkh+NBsdB7RtwDS819tfJQSO2/a742JfWdgJrAhChC0ao+bM1xHxd9b6 oDzM4S8MTnsO87iTzdgV8sFA7T8Z4/CwGOnUQRKPuDLSHdtwM/hZWY8TsDwikuT1 mkpC2lEi/bWvtrTNxnA2raNdUUPjD81T2WGrtj/LC5yPcCAjMSKZmj4uUCrFvh50 cHLTSP6qJmYLjHdswv4RnbT26szX2oG1IIbhwD9mPqU3WuMDc5NOfrSa0e5mDgia TmDNV4O+FmHDw0kjMMBg6ZshYEM7BYFHgdLGo9IV5aetjhHNs4rx1KBJ46V/+XDQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrkeeigddujeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucffohhmrghinhepihgvthhfrd horhhgpdgrnhgurdgtohhmpdgvgigrmhhplhgvrdgtohhmpdgvgigrmhhplhgvrdhithen ucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgrihhlfh horhgtvgdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 57B91140169; Sat, 27 Jul 2019 18:00:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: <9c3e075d-1a01-4b97-9626-231508104335@www.fastmail.com> In-Reply-To: <4195597.6UoUMpgHb9@l5580> References: <4195597.6UoUMpgHb9@l5580> Date: Sat, 27 Jul 2019 18:00:30 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=aa803c8efbd44b13a2153b92c1e8743a Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 27 Jul 2019 22:00:42 -0000 --aa803c8efbd44b13a2153b92c1e8743a Content-Type: text/plain Scott, I have two editorial nits that account for a grand total of three characters. It seemed less complicated to just send a PR in Github, so I did. Stan On Sat, Jul 27, 2019, at 4:45 PM, Scott Kitterman wrote: > On Monday, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote: > > Reviewing as the document shepherd: > > > > Abstract > > > > [...] > > organization can use to improve mail handling. DMARC policies can be > > applied at the individual domain level or for a set of domains at the > > organizational level. > > > > I think the abstract is a bit too abstract. Which set of domains? > > > > > > The design of DMARC precludes grouping > > policies for a set of domains above the organizational level, such as > > TLDs (Top Level Domains). > > > > Is that the same set? > > I updated the paragraph to start: > > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. DMARC policies can be > applied to individual domains or to all domains within an > organization. The design of DMARC precludes grouping policies for > domains based on policy published above the organizational level, > such as TLDs (Top Level Domains). > > Does that clear those comments up? > > > > These types of domains (which are not all > > at the top level of the DNS tree) can be collectively referred to as > > Public Suffix Domains (PSDs). > > > > What "types" are there? > > Changed to: > > organization. The design of DMARC precludes grouping policies for > domains based on policy published above the organizational level, > such as TLDs (Top Level Domains). Domains at this higher level of > the DNS tree (but not necessarily at the top of the DNS tree) can be > collectively referred to as Public Suffix Domains (PSDs). > > > For the subset of PSDs that require > > DMARC usage, this memo describes an extension to DMARC to enable > > DMARC functionality for such domains. > > > > What's the requirement? > > Given that the document no longer contains such a constraint, I've updated my > working copy to say: > > This memo describes an extension to DMARC to enable DMARC functionality PSDs. > > > 1. Introduction > > > > DMARC [RFC7489] provides a mechanism for publishing organizational > > policy information to email receivers. DMARC [RFC7489] allows policy > > to be specified for both individual domains and sets of domains > > > > Which sets? > > > Comment is OBE based on previous changes. > > > within a single organization. For domains above the organizational > > level in the DNS tree, policy can only be published for the exact > > domain. There is no method available to such domains to express > > lower level policy or receive feedback reporting for sets of domains. > > > > Still too abstract. I don't know what sort of set groupings you might > > be after here. > > I think the new text is better. Please check and let me know if it's there > yet or not. > > > This prevents policy application to non-existent domains and > > identification of domain abuse in email, which can be important for > > brand and consumer protection. > > > > As an example, imagine a country code TLD (ccTLD) which has public > > subdomains for government and commercial use (.gov.example and > > .com.example). Within the .gov.example public suffix, use of DMARC > > [RFC7489] has been mandated and .gov.example has published its own > > DMARC [RFC7489] record: > > > > "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" > > > > Can we add spaces after the semicolons? I know this is legal format > > but it would be more readable. > > Changed. > > > This memo provides a simple extension to DMARC [RFC7489] to allow > > > > s/memo/document/g > > Changed throughout. > > > operators of Public Suffix Domains (PSDs) to express policy for > > groups of subdomains, extends the DMARC [RFC7489] policy query > > > > "groups of subdomains" suggests the capability of creating a policy > > that applies to parts of the subtree only, or different policies for > > different parts of the subtree. If that's not what we're actually > > defining here, this should be reworded. > > OBE to previous comments. > > > As an additional benefit, the PSD DMARC extension will clarify > > > > s/will clarify/clarifies/ > > Changed. > > > existing requirements. Based on the requirements of DMARC [RFC7489], > > DMARC should function above the organizational level for exact domain > > matches (i.e. if a DMARC record were published for 'example', then > > mail from example@example should be subject to DMARC processing). > > Testing had revealed that this is not consistently applied in > > different implementations. PSD DMARC will help clarify that DMARC is > > > > s/will help clarify/clarifies/ > > Changed. > > > ....and saying it twice in the same paragraph is probably not necessary. > > And then deleted the sentence. > > > > not limited to organizational domains and their sub-domains. > > > > There are two types of Public Suffix Operators (PSOs) for which this > > extension would be useful and appropriate: > > > > o Branded PSDs (e.g., ".google"): These domains are effectively > > Organizational Domains as discussed in DMARC [RFC7489]. They > > control all subdomains of the tree. These are effectively private > > domains, but listed in the Public Suffix List. They are treated > > as Public for DMARC [RFC7489] purposes. They require the same > > protections as DMARC [RFC7489] Organizational Domains, but are > > currently excluded. > > > > How are they current excluded? Is this because they're on the PSL, so > > DMARC treats them differently? > > Yes. Per the DMARC definition, they are not organizational domains. > > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > Because existing Organizational Domains using this PSD have their > > own DMARC policy, the applicability of this extension is for non- > > existent domains. The extension allows the brand protection > > benefits of DMARC [RFC7489] to extend to the entire PSD, including > > cousin domains of registered organizations. > > > > An example would be useful here. > > I've added this: > > As an example, take the ".gov.example" described above and add that > for this entity emails about tax returns are sent from > tax.gov.example. It would not be surprising if fraudulent emails > were sent purporting to be from taxes.gov.example (taxes is a cousin > of tax - different enough to evade DMARC protection, but similar > enough to potentially confuse users). As defined in DMARC [RFC7489], > a DMARC record could be published for tax.gov.example, but there is > no general solution to publishing a DMARC policy to defend against > abuse of non-existent cousins such as taxes.gov.example. While an > explicit record could be published for this one domain, the universe > of possible cousins is such that this approach does not scale. > > How's that? > > > Due to the design of DMARC [RFC7489] and the nature of the Internet > > email architecture [RFC5598], there are interoperability issues > > associated with DMARC [RFC7489] deployment. These are discussed in > > Interoperability Issues between DMARC and Indirect Email Flows > > [RFC7960]. These issues are not applicable to PSDs, since they > > (e.g., the ".gov.example" used above) do not send mail. > > > > DMARC doesn't need to be followed by its RFC number every time. > > I went through and removed most of these. I tried to remove them so that it's > mostly there when talking about DMARC the RFC, not DMARC the protocol. > > > 2.2. Public Suffix Domain (PSD) > > > > The global Internet Domain Name System (DNS) is documented in > > numerous Requests for Comment (RFC). It defines a tree of names > > starting with root, ".", immediately below which are Top Level Domain > > names such as ".com" and ".us". They are not available for private > > registration. In many cases the public portion of the DNS tree is > > more than one level deep. PSD DMARC includes all public domains > > above the organizational level in the tree, e.g., ".gov.uk". > > > > I don't know what that last sentence means. PSD DMARC is an > > extension; how does it include domains? > > Deleted the sentence. I don't think it is necessary for the definition, so > let's not confuse things. > > > 2.4. Public Suffix Operator (PSO) > > > > A Public Suffix Operator manages operations within their PSD. > > > > s/their/its/; "operator" is singular. > > Changed. > > > 2.6. Non-existent Domains > > > > For DMARC [RFC7489] purposes, a non-existent domain is a domain name > > that publishes none of A, AAAA, or MX records that the receiver is > > willing to accept. This is a broader definition than that in > > NXDOMAIN [RFC8020]. > > > > Is there any discussion that could be referenced about DNS RRs that > > one is not willing to accept? > > OBE. Removed that from the definition based on the WGLC discussion about the > definition. > > > 3.2. Section 6.1 DMARC Policy Record > > > > PSD DMARC records are published as a subdomain of the PSD. For the > > PSD ".example", the PSO would post DMARC policy in a TXT record at > > "_dmarc.example". > > > > Don't you mean the PSD DMARC record is a record in the zone of the > > PSD? It's not a subdomain. > > Here's what's in RFC 7489 about DMARC record publishing: > > 6.1. DMARC Policy Record > > Domain Owner DMARC preferences are stored as DNS TXT records in > subdomains named "_dmarc". For example, the Domain Owner of > "example.com" would post DMARC preferences in a TXT record at > "_dmarc.example.com". > > I think our 3.2 is equivalent and adequate given this section is a modification > to RFC 7489 Section 6.1. I did not make a change. > > > 3.3. Section 6.5. Domain Owner Actions > > > > In addition to the DMARC [RFC7489] domain owner actions, PSOs that > > require use of DMARC ought to make that information available to > > receivers. > > By what mechanism? > > Changed to: > > In addition to the DMARC domain owner actions, PSOs that require use > of DMARC and participate in PSD DMARC ought to make that information > available to receivers. The mechanism for doing so is one of the > experimental elements of this document. See the experiment > description (Appendix A). > > > 3.4. Section 6.6.3. Policy Discovery > > > > A new step between step 3 and 4 is added: > > > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > > Organizational Domain is one that the receiver has determined is > > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > > a DMARC TXT record at the DNS domain matching the longest PSD > > (Section 2.3) in place of the RFC5322.From domain in the message > > (if different). A possibly empty set of records is returned. > > > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I > > don't know what "acceptable for PSD DMARC" might mean. > > Changed to: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > Organizational Domain is one that the receiver has determined is > acceptable for PSD DMARC (discussed in the experiment description > (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC > TXT record at the DNS domain matching the longest PSD > (Section 2.3) in place of the RFC5322.From domain in the message > (if different). A possibly empty set of records is returned. > > > Section numbers in the prose of this section should make clear which > > document they're referencing. > > I checked and any reference to an RFC7489 paragraph number that's in the text > is labeled as such. > > > > 3.5. Section 7. DMARC Feedback > > > > Operational note for PSD DMARC: For PSOs, feedback for non-existent > > domains is desired and useful. See Section 4 for discussion of > > Privacy Considerations. > > > > Section 4 of which document? > > Added 'of this document'. > > > 4. Privacy Considerations > > > > These privacy considerations are developed based on the requiremetns > > > > typo > > > > of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this > > document. > > > > 4.1. Feedback leakage > > > > Providing feedback reporting to PSOs can, in some cases, create > > leakage of information outside of an organization to the PSO. This > > leakage could be potentially be utilized as part of a program of > > > > Remove one of the "be"s. > > Fixed. > > > pervasive surveillance (See [RFC7624]). There are roughly three > > cases to consider: > > > > o Single Organization PSDs (e.g., ".google"), RUA and RUF reports > > based on PSD DMARC have the potential to contain information about > > emails related to entities managed by the organization. Since > > both the PSO and the Organizational Domain owners are common, > > there is no additional privacy risk for either normal or non- > > existent Domain reporting due to PSD DMARC. > > > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > PSD DMARC based reports will only be generated for domains that do > > not publish a DMARC policy at the organizational or host level. > > For domains that do publish the required DMARC policy records, the > > feedback reporting addresses (RUA and RUF) of the organization (or > > hosts) will be used. The only direct feedback leakage risk for > > these PSDs are for Organizational Domains that are out of > > compliance with PSD policy. Data on non-existent cousin domains > > would be sent to the PSO. > > > > This is the second use of "cousin domain". An example here or at the > > first use might be a good idea. > > Added at first use. > > And that's the last comment. > > I intend to post a revision shortly so the group can more easily review my > proposed changes based on WGLC. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --aa803c8efbd44b13a2153b92c1e8743a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Scott, I have two editorial nits that account for a grand = total of three characters.  It seemed less complicated to just send= a PR in Github, so I did.

Stan

On Sat, Jul 27, 2019, at 4:45 PM, Scott Kitterman wrote:
On Mond= ay, July 22, 2019 12:23:15 PM EDT Murray S. Kucherawy wrote:
> Reviewing as the document shepherd:=
> 
> Abstract
> 
> [.= ..]
>    or= ganization can use to improve mail handling.  DMARC policies can be=
>    appli= ed at the individual domain level or for a set of domains at the
>    organizationa= l level.
> 
=
> I think the abstract is a bit too= abstract.  Which set of domains?
> 
>&nbs= p;
>    The= design of DMARC precludes grouping
>    policies for a set of domains above the or= ganizational level, such as
&= gt;    TLDs (Top Level Domains).
> 
> Is that the same set?
<= br>
I updated the paragraph to st= art:

   DMARC (Domain-based Message Authenticat= ion, Reporting, and
 &nb= sp; Conformance) is a scalable mechanism by which a mail-originating
=
   organization can ex= press domain-level policies and preferences for
   message validation, disposition, and rep= orting, that a mail-receiving
   organization can use to improve mail handling.  DMARC= policies can be
  = applied to individual domains or to all domains within an
   organization.  The desig= n of DMARC precludes grouping policies for
   domains based on policy published above the o= rganizational level,
 &n= bsp; such as TLDs (Top Level Domains).  

Does th= at clear those comments up?
<= br>

>    These types of domains (which are = not all
>   = ; at the top level of the DNS tree) can be collectively referred to as
>    Public = Suffix Domains (PSDs).
>&n= bsp;
> What "types" are th= ere?

Changed to:

   organization= .  The design of DMARC precludes grouping policies for
   domains based on policy publ= ished above the organizational level,
   such as TLDs (Top Level Domains).  Domains at= this higher level of
 &= nbsp; the DNS tree (but not necessarily at the top of the DNS tree) can = be
   collectively = referred to as Public Suffix Domains (PSDs). 

>&nb= sp;   For the subset of PSDs that require
>    DMARC usage, this memo descr= ibes an extension to DMARC to enable
>    DMARC functionality for such domains.
=
>
> What's the requirement? 

Given t= hat the document no longer contains such a constraint, I've updated my&n= bsp;
working copy to say:
=

This memo describes an extension to DMARC to enable DMARC fu= nctionality PSDs.

<= div style=3D"font-family:Arial;">> 1.  Introduction
> 
>    DMARC [RFC7489] provides a mechanism= for publishing organizational
>    policy information to email receivers.  DM= ARC [RFC7489] allows policy
&= gt;    to be specified for both individual domains and se= ts of domains
> 
<= /div>
> Which sets?
> 
Comment is OBE based on previous changes.

>&nb= sp;   within a single organization.  For domains above th= e organizational
> &n= bsp;  level in the DNS tree, policy can only be published for the e= xact
>    d= omain.  There is no method available to such domains to express
=
>    lower lev= el policy or receive feedback reporting for sets of domains.
> 
> Still too abstract.  I don't know what sort of s= et groupings you might
> b= e after here.

I think the new text is better.  Pleas= e check and let me know if it's there 
yet or not.
>    This pr= events policy application to non-existent domains and
>    identification of domain= abuse in email, which can be important for
>    brand and consumer protection.
=
> 
>    As an example, imagine a cou= ntry code TLD (ccTLD) which has public
>    subdomains for government and commercia= l use (.gov.example and
>&= nbsp;   .com.example).  Within the .gov.example public su= ffix, use of DMARC
> =    [RFC7489] has been mandated and .gov.example has published = its own
>   = ; DMARC [RFC7489] record:
>= ; 
>   = ; "v=3DDMARC1;p=3Dreject;rua=3Dmailto:dmarc@dmarc.service.gov.example"
> 
> Can we add spaces after the semicolons? I k= now this is legal format
>= but it would be more readable.

Changed.

&= gt;    This memo provides a simple extension to DMARC [RF= C7489] to allow
> 
> s/memo/document/g

Changed throughout.
>    operato= rs of Public Suffix Domains (PSDs) to express policy for
>    groups of subdomains,= extends the DMARC [RFC7489] policy query
> 
> = "groups of subdomains" suggests the capability of creating a policy
<= /div>
> that applies to parts of the= subtree only, or different policies for
> different parts of the subtree.  If that's not wha= t we're actually
> definin= g here, this should be reworded.

OBE to previous comments= .

>    As an additional benefit, the PS= D DMARC extension will clarify
> 
> s/will clar= ify/clarifies/

Changed.

>  &n= bsp; existing requirements.  Based on the requirements of DMARC [RF= C7489],
>   = ; DMARC should function above the organizational level for exact domain<= br>
>    matche= s (i.e. if a DMARC record were published for 'example', then
>    mail from example= @example should be subject to DMARC processing).
>    Testing had revealed that thi= s is not consistently applied in
>    different implementations.  PSD DMARC wi= ll help clarify that DMARC is
> 
> s/will help = clarify/clarifies/

=
Changed.

> ....and s= aying it twice in the same paragraph is probably not necessary.

And then deleted the sentence.
> 
> = ;   not limited to organizational domains and their sub-domain= s.
> 
>    There are two types o= f Public Suffix Operators (PSOs) for which this
>    extension would be useful and = appropriate:
> 
>    o  Bra= nded PSDs (e.g., ".google"): These domains are effectively
>       O= rganizational Domains as discussed in DMARC [RFC7489].  They
>     &= nbsp; control all subdomains of the tree.  These are effectively pr= ivate
>   &= nbsp;   domains, but listed in the Public Suffix List.  T= hey are treated
> &nb= sp;     as Public for DMARC [RFC7489] purposes. = ; They require the same
>&= nbsp;      protections as DMARC [RFC7489] Organ= izational Domains, but are
&g= t;       currently excluded.
> 
> How are they current excluded?  Is this because th= ey're on the PSL, so
> DMA= RC treats them differently?
<= br>
Yes.  Per the DMARC defi= nition, they are not organizational domains.

> &n= bsp;  o  Multi-organization PSDs that require DMARC usage (e.g= ., ".bank"):
>  =      Because existing Organizational Domains using t= his PSD have their
> =       own DMARC policy, the applicability of th= is extension is for non-
>=        existent domains.  The extensi= on allows the brand protection
>       benefits of DMARC [RFC7489] t= o extend to the entire PSD, including
>       cousin domains of regi= stered organizations.
>&nb= sp;
> An example would be = useful here.

I've added this:

  = As an example, take the ".gov.example" described above and add that
=
   for this entity ema= ils about tax returns are sent from
   tax.gov.example.  It would not be surprising if= fraudulent emails
 &nbs= p; were sent purporting to be from taxes.gov.example (taxes is a cousin<= br>
   of tax - differe= nt enough to evade DMARC protection, but similar
   enough to potentially confuse users).&n= bsp; As defined in DMARC [RFC7489],
   a DMARC record could be published for tax.gov.exampl= e, but there is
   = no general solution to publishing a DMARC policy to defend against
   abuse of non-existent= cousins such as taxes.gov.example.  While an
   explicit record could be published for= this one domain, the universe
   of possible cousins is such that this approach does not s= cale.

How's that?

>    D= ue to the design of DMARC [RFC7489] and the nature of the Internet
>    email archi= tecture [RFC5598], there are interoperability issues
>    associated with DMARC [RF= C7489] deployment.  These are discussed in
>    Interoperability Issues betwee= n DMARC and Indirect Email Flows
>    [RFC7960].  These issues are not applica= ble to PSDs, since they
>&= nbsp;   (e.g., the ".gov.example" used above) do not send mail= .
> 
> DMARC doesn't need to be followed by its= RFC number every time.

<= /div>
I went through and removed most o= f these.  I tried to remove them so that it's 
mostly there when talking about DMARC the RF= C, not DMARC the protocol.
> 2.2.  Public Suffix = Domain (PSD)
> 
>    The global = Internet Domain Name System (DNS) is documented in
>    numerous Requests for Commen= t (RFC).  It defines a tree of names
>    starting with root, ".", immediately= below which are Top Level Domain
>    names such as ".com" and ".us".  They a= re not available for private
= >    registration.  In many cases the public port= ion of the DNS tree is
>&n= bsp;   more than one level deep.  PSD DMARC includes all = public domains
> &nbs= p;  above the organizational level in the tree, e.g., ".gov.uk".
> 
> I don't know what that last sentence means.&nb= sp; PSD DMARC is an
> exte= nsion; how does it include domains?

Deleted the sentence.=   I don't think it is necessary for the definition, so 
let's not confuse things.
=

> 2.4.  Public Suffix Operator (PSO)
> 
>    A Public Suffix Operator manages operations wi= thin their PSD.
> 
> s/their/its/; "operator" i= s singular.

Changed.

> 2.6.  Non-e= xistent Domains
> 
>    For DMAR= C [RFC7489] purposes, a non-existent domain is a domain name
>    that publishes no= ne of A, AAAA, or MX records that the receiver is
>    willing to accept.  Thi= s is a broader definition than that in
>    NXDOMAIN [RFC8020].
> 
> Is there any discussion that could be referenced about DNS RR= s that
> one is not willin= g to accept?

OBE.  Removed that from the definition = based on the WGLC discussion about the 
definition.
<= br>
> 3.2.  Section 6.1 D= MARC Policy Record
> =
>    PSD D= MARC records are published as a subdomain of the PSD.  For the
<= /div>
>    PSD ".exam= ple", the PSO would post DMARC policy in a TXT record at
>    "_dmarc.example".
=
> 
> Don't you mean the PSD DMARC record is a recor= d in the zone of the
> PSD= ?  It's not a subdomain.

Here's what's in RFC 7489 a= bout DMARC record publishing:

6.1.  DMARC Policy Rec= ord

   Domain Owner DMARC preferences are store= d as DNS TXT records in
 = ;  subdomains named "_dmarc".  For example, the Domain Owner o= f
   "example.com" = would post DMARC preferences in a TXT record at
   "_dmarc.example.com".

I t= hink our 3.2 is equivalent and adequate given this section is a modifica= tion 
to RFC 7489 Sectio= n 6.1.  I did not make a change.

> 3.3.  Sec= tion 6.5.  Domain Owner Actions
> 
> =    In addition to the DMARC [RFC7489] domain owner actions, PS= Os that
>   = ; require use of DMARC ought to make that information available to
>    receivers.<= br>
> By what mechanism?

Changed to:

   In addition to the DMA= RC domain owner actions, PSOs that require use
   of DMARC and participate in PSD DMARC oug= ht to make that information
&= nbsp;  available to receivers.  The mechanism for doing so is = one of the
   exper= imental elements of this document.  See the experiment
   description (Appendix A).

> 3.4.  Section 6.6.3.  Policy Discovery
> 
>    A new step between step 3 and= 4 is added:
> 
>    3A.  I= f the set is now empty and the longest PSD (Section 2.3) of the
>     &nb= sp; Organizational Domain is one that the receiver has determined is
=
>    &nbs= p;  acceptable for PSD DMARC, the Mail Receiver MUST query the DNS = for
>   &nb= sp;   a DMARC TXT record at the DNS domain matching the longes= t PSD
>   &= nbsp;   (Section 2.3) in place of the RFC5322.From domain in t= he message
>  &n= bsp;    (if different).  A possibly empty set of rec= ords is returned.
> <= br>
> Section 6.6.3 of DMARC d= oesn't talk about "acceptable for DMARC", so I
> don't know what "acceptable for PSD DMARC" might = mean.

Changed to:

   3A.  I= f the set is now empty and the longest PSD (Section 2.3) of the
      Organi= zational Domain is one that the receiver has determined is
      acceptable = for PSD DMARC (discussed in the experiment description
      (Appendix A)), = the Mail Receiver MUST query the DNS for a DMARC
      TXT record at the DNS= domain matching the longest PSD
      (Section 2.3) in place of the RFC5322= .From domain in the message
&= nbsp;     (if different).  A possibly empty set= of records is returned.

=
> Section numbers in the pros= e of this section should make clear which
> document they're referencing.

I checked= and any reference to an RFC7489 paragraph number that's in the text&nbs= p;
is labeled as such.
> 
> 3.5.  Section 7.  DMARC Feedback
> 
>    Operational note for PSD DMAR= C: For PSOs, feedback for non-existent
>    domains is desired and useful.  Se= e Section 4 for discussion of
>    Privacy Considerations.
> 
> Section 4 of which document?

Added 'of this documen= t'.

> 4.  Privacy Considerations
> 
>    These privacy considerations are develop= ed based on the requiremetns
= > 
> typo
> 
>    of [RFC6973].  The Privacy = Considerations of [RFC7489] apply to this
>    document.
> 
&= gt; 4.1.  Feedback leakage
> 
>  = ;  Providing feedback reporting to PSOs can, in some cases, create<= br>
>    leakag= e of information outside of an organization to the PSO.  This
>    leakage cou= ld be potentially be utilized as part of a program of
> 
> Remove one of the "be"s.

Fixed.

>    pervasive surveillance (See [RFC7624]).  T= here are roughly three
>&n= bsp;   cases to consider:
> 
> &= nbsp;  o  Single Organization PSDs (e.g., ".google"), RUA and = RUF reports
>  &= nbsp;    based on PSD DMARC have the potential to contain= information about
> =       emails related to entities managed by the= organization.  Since
&g= t;       both the PSO and the Organization= al Domain owners are common,
= >       there is no additional privacy = risk for either normal or non-
>       existent Domain reporting due= to PSD DMARC.
> 
=
>    o  M= ulti-organization PSDs that require DMARC usage (e.g., ".bank"):
>     &n= bsp; PSD DMARC based reports will only be generated for domains that do<= br>
>    &= nbsp;  not publish a DMARC policy at the organizational or host lev= el.
>   &nb= sp;   For domains that do publish the required DMARC policy re= cords, the
>  &n= bsp;    feedback reporting addresses (RUA and RUF) of the= organization (or
> &= nbsp;     hosts) will be used.  The only direct= feedback leakage risk for
&g= t;       these PSDs are for Organizational= Domains that are out of
>=        compliance with PSD policy.  D= ata on non-existent cousin domains
>       would be sent to the PSO.=
> 
> This is the second use of "cousin domain"= .  An example here or at the
> first use might be a good idea.

Added at first = use.

And that's the last comment.

I intend= to post a revision shortly so the group can more easily review my =
proposed changes based on WG= LC.

Scott K

_______________________________________________
<= div style=3D"font-family:Arial;">dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--aa803c8efbd44b13a2153b92c1e8743a-- From nobody Sat Jul 27 18:03: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 91F211200CD for ; Sat, 27 Jul 2019 18:03:09 -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=TbyeGsVj; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Yy0v77jP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob5YBwhZ6qFk for ; Sat, 27 Jul 2019 18:03:08 -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 317AE120047 for ; Sat, 27 Jul 2019 18:03:08 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 41149F8071A; Sat, 27 Jul 2019 21:02:36 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564275756; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=GhZDtdfWIuY+LiTl4NEaV2KF9+6P1ZStzyEYwjTahkQ=; b=TbyeGsVjmufqA9TZcmLOskqlUba1AgSAydCYBr6pRLPcPywxm5K466sc NT+c26SUvBnR/uJKIKKjk2jkLDRjAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564275756; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=GhZDtdfWIuY+LiTl4NEaV2KF9+6P1ZStzyEYwjTahkQ=; b=Yy0v77jP8tB5w1JTYBIumVwwSPm6cxCHxeCFIdzI29X857qwXvV0N0Xa 3QOCWmm3nG/eSvN6LTec0Lo4zM2Ly6sd68UeHwI2LAJFRyJKvILgMwSi4S uoG0hqXnKbWpHmRDFaQwws2Z3gTDWQQdsnyhQrJBk4wb4OSRnIhfj+5M6w 5bLxC4FFzdCu2Du1jsi3AIXxewjMST9LQq1GnHwTs+XU0Zc19p47+NdCU2 meqj24XuZwrO2GiRMLsYOMEUwikP4SvjkV+RrOdkxfpxiIAnaBxJdgSdI+ PDZ0bCleDCRZnFWxReq/KVB3rQY+F9I7J/n1Xm441XIGs5ciC/Q8fw== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id DAC58F804AA; Sat, 27 Jul 2019 21:02:35 -0400 (EDT) Date: Sun, 28 Jul 2019 01:02:34 +0000 In-Reply-To: <9c3e075d-1a01-4b97-9626-231508104335@www.fastmail.com> References: <4195597.6UoUMpgHb9@l5580> <9c3e075d-1a01-4b97-9626-231508104335@www.fastmail.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: <8041A338-7D2B-41D5-A23B-B663EEC6C0B6@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review 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, 28 Jul 2019 01:03:10 -0000 On July 27, 2019 10:00:30 PM UTC, Stan Kalisch wrote: >Scott, I have two editorial nits that account for a grand total of >three characters=2E It seemed less complicated to just send a PR in >Github, so I did=2E > Thanks=2E That looks correct=2E Scott K From nobody Sun Jul 28 05:48:17 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 8B6EC12010C for ; Sun, 28 Jul 2019 05:48:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQJnjRp3pSg6 for ; Sun, 28 Jul 2019 05:48:14 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 EAAE8120144 for ; Sun, 28 Jul 2019 05:48:13 -0700 (PDT) Authentication-Results: mail.aegee.org/x6SClwEP027080; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564318083; i=dkim+MSA-tls@aegee.org; r=y; bh=mKE2GMWtMdRORCfU0qE6Gp7q+55qPB1ZBS484+kLjSY=; h=Subject:From:To:In-Reply-To:References:Date; b=AnDXErbv4twax20PozIAxiJo0MDpVjiXTEOytFeqvhkrcVLaLlY1Xk9TpfiwS7M7O sOiFXvt74Fr0oeAvfTsdyrW+qjMiqrZaBjcmIp4Btpz1iJMrGl5ZQKkQdgSFK9l4uO uRHsADSRsJS5hIT8k4JuvxBrz80Tdu50tsm+6WjEU2On6d3oG87jHbie6WV9S4AKA8 EbkLN7N1ibeJQJJynbChoVxhJIK4pTBRDh5YCZRRxlMNJrrBxSfOCMNlPhe/vNBb3h 8p3UOMhVPP9n+M+/9a/GADOzO1sTJBVLzpwE/qnLZmK2DtofTMOKZii1wZudlWFC1o r3XuDhUYRUdSjgdSVRLN7ectdcyA6/18bA6JLMw6UUc264R+D6bK6sh3ezg8gBfp3y kAd9Vfyqt4lwSm9WNHDM6rGXF/lGsTILpEmW1ZVz0rX/Yq57qDhDSkr1ufI12bEoaT kOY/5kxsn0NerG6BgB/N0P51WXrt7xE/D/oBoNz8u+JXOA+ft7+MQoXCHTE1h3qrw8 h84xSrupChLeS219XPg5rUDcKEMlU3LmrGJ0JMbsyeHYzcWwmpFAptrQ4zUzVOuAVg o6kOjsok5SlqYeVx4NreQ9ZMAYqndCiDgk/5CUglkuOBKf1Yj46y60jW/9mYGLhWG9 lrFKmmcmEo8FRsyQP7g8AIxw= Authentication-Results: mail.aegee.org/x6SClwEP027080; dkim=none Received: from Tylan ([88.203.199.243]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6SClwEP027080 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Jul 2019 12:47:59 GMT Message-ID: <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Alessandro Vesely , dmarc@ietf.org In-Reply-To: <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> Content-Type: text/plain; charset="UTF-8" Date: Sun, 28 Jul 2019 10:49:12 +0000 MIME-Version: 1.0 User-Agent: Evolution 3.33.90 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 28 Jul 2019 12:48:16 -0000 Hello Alessandro, abolishing policy quarantine means with p=reject that for failed messages there should be some penalty and the receiving site decides on the form of the penalty, e.g. quarantine or reject. In fact I see the DMARC specification updated to use consistently some neutral word, like penalty or punishment attached to p=reject, once p=quarantine is abolished. This word is then dissected into “quarantine or reject” at the place where it elaborates on the possible penalties, or how to do reject right. The penalty could be implemented with reply 550 Message failed DMARC validation and was delivered in the Junk folder of the recipient This form has the advantage over either quarantine or reject, that for lost messages, the sender can call the recipient and the recipient can dig for the message. So the message does not have to be resent and no surprizes happen. I do not see how could this reply mess anything, except in the cases where the sender does not speak English. > OTOH, quarantine lets one forget about delivery, perhaps with a backhanded > thought of recipients rummaging through their spam folders in search of a > missing message. That style seems to me to better suit ESPs, whose duty is > rather to have a lot of mails sent than to make sure that each message is > acknowledged, albeit they try and maximize the ratio. > > IMHO, by abolishing quarantine, we make the protocol less flexible than it is. If an ESP wants to forget about delivery, the ESP likely does not care whether it has implemented DMARC correctly and then it does not need quarantine mode. The penalty is applied to messages that are either sent by spammers or by the domain owner. If messages are from spammers, for the domain owner it is irrelevant, what kind of penalty is applied, but for users doing reject means having to scan less messages in the Junk mailbox. If messages are from the domain owner and fail DKIM/DMARC validation, the only way to fix DKIM/DMARC is to use policy reject. There is no other way to find out which messages fail DKIM/DMARC, as single message faiulure reports are rarely sent, and without knowing which messages fail DMARC fixing the problem is unnecessary complicated. So here, p=quarantine is in fact an option for providers, who do not care, whether they have implemented DMARC correctly. All that said: • Is there a consensus on abolishing policy quarantine? • If policy quarantine will be kept, will the none>quarantine>reject order be abolished, meaning “quarantine” will not be handled as softer variant of “reject”? Meaning with p=reject; pct=30 messages are either delivered or rejected, but the specification does state anything about quaratining 70% of the failed messages. The first argument in favour of keeping policy quarantine was exactly this order (quarantine is a softer variant of reject and before deploying reject one has to exercise with quarantine). Regards Дилян On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote: > On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote: > > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy wrote: > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins wrote: > > > > It's interesting that the industry has decided to interpret "p=reject; pct=0" the way we intended "p=quarantine; pct=100". > > > > > > It's semi-explicitly defined that way in the RFC, isn't it? > > > > > > If so, we should fix it because (a) I don't think that's how we intended it, and (b) in any case, nothing in there should be only semi-explicit. > > > > rfc 7489 6.6.4 > > > > "If email is subject to the DMARC policy of "reject", the Mail > > Receiver SHOULD reject the message (see Section 10.3). If the email > > is not subject to the "reject" policy (due to the "pct" tag), the > > Mail Receiver SHOULD treat the email as though the "quarantine" > > policy applies. This behavior allows Domain Owners to experiment > > with progressively stronger policies without relaxing existing > > policy." > > > > It's pretty clear and well-defined; the case we're talking about, "p=reject; pct=0", is > > just a special case of this general rule. > > > > All emails will not be subject to the "reject" policy due to the pct=0 tag, so the mail > > receiver should treat all emails as though the policy "quarantine" applies (which > > is the same as "p=quarantine; pct=100"). > > I, for one, had missed that point. Thanks for clarifying it. > > It seems to mean that the resulting steps are, for example: > > > "p=quarantine; pct=0" (check From: rewriting) > "p=quarantine; pct=10" (some messages go to the spam folder) > "p=quarantine; pct=20" > .... > "p=quarantine; pct=100" > "p=reject; pct=0" (same as the previous step) > "p=reject; pct=10" (some messages bounce back) > "p=reject; pct=20" > .... > > > Is that what we want to suggest? In that case, we should be clearer. Perhaps > by adding an example in a new appendix. However, I hardly see the above > sequence as progressive. > > I had always considered quarantine and reject to be two more or less similar > alternatives. Each has its merits and shortcomings, and can be chosen > according to a sender's needs. > > An advantage of reject is that one gets NDNs, which are much more universally > adopted than failure reports. Perhaps a bank or similar transactional sender > would rather prefer reject, because they can timely resend bounced transactions > or notices thereof in order to have their duties accomplished. > > OTOH, quarantine lets one forget about delivery, perhaps with a backhanded > thought of recipients rummaging through their spam folders in search of a > missing message. That style seems to me to better suit ESPs, whose duty is > rather to have a lot of mails sent than to make sure that each message is > acknowledged, albeit they try and maximize the ratio. > > IMHO, by abolishing quarantine, we make the protocol less flexible than it is. > > > Best > Ale From nobody Sun Jul 28 06:36: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 49E2F120136 for ; Sun, 28 Jul 2019 06:36:55 -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 F7HesxFD8XcI for ; Sun, 28 Jul 2019 06:36:52 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 47FDD120100 for ; Sun, 28 Jul 2019 06:36:52 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id z23so31626461ote.13 for ; Sun, 28 Jul 2019 06:36:52 -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=4rjrSMZTgewH5WjxCPEtTZ3v8YYTu/xeyX6ctKjJMmw=; b=FKQF8/ptQK6nxifSKK5tAkLChuoAH1K+PwnbWXNM0/vrG/sghTJvdTkYU3JoDTgcjK 3aUL45hstZo0OOvv+0QyxqWe2VPRA/H5egJcoWoRWvFQiRDF4eJMmUArrgLvg3ABjgZ0 Y40IIWwXgDw4nCYDBgVAeoD0YVsA62EF3djXFCz1x0tqMS8uQ6zcmGcBYGqAVMSK5Dvc MWwbTdtFbov+coFUAVJkf2XCK8jJs5xk0rvOYjQwjFvVEGmhByK2P0FjsLObDwACspYB StMq549UnwVvHHaEC5jk8b1eWH+gVQirN7HS3SKQ2lzQeWVpMkM/8UUOhGJSb6Xgbvbk ++Eg== 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=4rjrSMZTgewH5WjxCPEtTZ3v8YYTu/xeyX6ctKjJMmw=; b=dkFFz8X3vluC7qh1Vnt3Dl/oNMmvVbMJQInSPbAkY1PgdxCnOYKtitwdt4/bI8LotV df1sP22jGB/BIZU3O0PBuGdyxNJ4T+SHNvQSD7fy/E3wTWrWnfYvG5rJprkwfLTd3HAh jWAIb/KJtT5EN5w8whGEsCvStL/X0CUfnoTn0AfAYwHTERRekLV9cyX27Qe3kKRgkUy3 bA53bjDq7gjXea9cCnKzXCn98lvPKYxmEQUCIR06vq0MqAs08CmdADgbMFfRCozZk7CS ETsCSfncx2IbuVaO2+Udrs5VEwd0Lq4nh0yeCeqvoLLlOwDQ8EA1fYrdLXe6dmiiEAnM 6eIA== X-Gm-Message-State: APjAAAXJ80f03m+qi+8nqh9kb0o8M5Rsk/PjJOLzC1+UJWu+fASfMrnA aN5PStjGiav7LJHMmwKrCozth0jSv8utdu/PPfg= X-Google-Smtp-Source: APXvYqwRr4EoldZaE0Gl1LfD5fzQZw1ELv30sLEmetmnvBltyhF8E89wPdveFTDDZ9mvtcXiKSaRVMpA3UAzWf0tTws= X-Received: by 2002:a05:6830:13d9:: with SMTP id e25mr46729103otq.197.1564321011651; Sun, 28 Jul 2019 06:36:51 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> In-Reply-To: <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> From: Tim Wicinski Date: Sun, 28 Jul 2019 09:36:39 -0400 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: Alessandro Vesely , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000036d7a3058ebdded8" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 28 Jul 2019 13:36:55 -0000 --00000000000036d7a3058ebdded8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From our end user point of view, I'm against abolishing quarantine, even with its current shortcomings. Tim (no hat) On Sun, Jul 28, 2019 at 8:48 AM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0= =D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello Alessandro, > > abolishing policy quarantine means with p=3Dreject that for failed messag= es > there should be some penalty and the receiving > site decides on the form of the penalty, e.g. quarantine or reject. > > In fact I see the DMARC specification updated to use consistently some > neutral word, like penalty or punishment attached > to p=3Dreject, once p=3Dquarantine is abolished. This word is then disse= cted > into =E2=80=9Cquarantine or reject=E2=80=9D at the place where > it elaborates on the possible penalties, or how to do reject right. > > The penalty could be implemented with reply > 550 Message failed DMARC validation and was delivered in the Junk folder > of the recipient > > This form has the advantage over either quarantine or reject, that for > lost messages, the sender can call the recipient > and the recipient can dig for the message. So the message does not have > to be resent and no surprizes happen. I do not > see how could this reply mess anything, except in the cases where the > sender does not speak English. > > > OTOH, quarantine lets one forget about delivery, perhaps with a > backhanded > > thought of recipients rummaging through their spam folders in search of= a > > missing message. That style seems to me to better suit ESPs, whose dut= y > is > > rather to have a lot of mails sent than to make sure that each message = is > > acknowledged, albeit they try and maximize the ratio. > > > > IMHO, by abolishing quarantine, we make the protocol less flexible than > it is. > > If an ESP wants to forget about delivery, the ESP likely does not care > whether it has implemented DMARC correctly and > then it does not need quarantine mode. > > The penalty is applied to messages that are either sent by spammers or by > the domain owner. If messages are from > spammers, for the domain owner it is irrelevant, what kind of penalty is > applied, but for users doing reject means > having to scan less messages in the Junk mailbox. > > If messages are from the domain owner and fail DKIM/DMARC validation, the > only way to fix DKIM/DMARC is to use policy > reject. There is no other way to find out which messages fail DKIM/DMARC= , > as single message faiulure reports are rarely > sent, and without knowing which messages fail DMARC fixing the problem is > unnecessary complicated. > > So here, p=3Dquarantine is in fact an option for providers, who do not ca= re, > whether they have implemented DMARC > correctly. > > All that said: > > =E2=80=A2 Is there a consensus on abolishing policy quarantine? > =E2=80=A2 If policy quarantine will be kept, will the none>quarantine>rej= ect order > be abolished, meaning =E2=80=9Cquarantine=E2=80=9D will not > be handled as softer variant of =E2=80=9Creject=E2=80=9D? Meaning with p= =3Dreject; pct=3D30 > messages are either delivered or rejected, but > the specification does state anything about quaratining 70% of the failed > messages. > > The first argument in favour of keeping policy quarantine was exactly thi= s > order (quarantine is a softer variant of > reject and before deploying reject one has to exercise with quarantine). > > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote: > > On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote: > > > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy < > superuser@gmail.com> wrote: > > > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins < > steve@wordtothewise.com> wrote: > > > > > It's interesting that the industry has decided to interpret > "p=3Dreject; pct=3D0" the way we intended "p=3Dquarantine; pct=3D100". > > > > > > > > It's semi-explicitly defined that way in the RFC, isn't it? > > > > > > > > If so, we should fix it because (a) I don't think that's how we > intended it, and (b) in any case, nothing in there should be only > semi-explicit. > > > > > > rfc 7489 6.6.4 > > > > > > "If email is subject to the DMARC policy of "reject", the Mail > > > Receiver SHOULD reject the message (see Section 10.3). If the > email > > > is not subject to the "reject" policy (due to the "pct" tag), the > > > Mail Receiver SHOULD treat the email as though the "quarantine" > > > policy applies. This behavior allows Domain Owners to experiment > > > with progressively stronger policies without relaxing existing > > > policy." > > > > > > It's pretty clear and well-defined; the case we're talking about, > "p=3Dreject; pct=3D0", is > > > just a special case of this general rule. > > > > > > All emails will not be subject to the "reject" policy due to the pct= =3D0 > tag, so the mail > > > receiver should treat all emails as though the policy "quarantine" > applies (which > > > is the same as "p=3Dquarantine; pct=3D100"). > > > > I, for one, had missed that point. Thanks for clarifying it. > > > > It seems to mean that the resulting steps are, for example: > > > > > > "p=3Dquarantine; pct=3D0" (check From: rewriting) > > "p=3Dquarantine; pct=3D10" (some messages go to the spam folder) > > "p=3Dquarantine; pct=3D20" > > .... > > "p=3Dquarantine; pct=3D100" > > "p=3Dreject; pct=3D0" (same as the previous step) > > "p=3Dreject; pct=3D10" (some messages bounce back) > > "p=3Dreject; pct=3D20" > > .... > > > > > > Is that what we want to suggest? In that case, we should be clearer. > Perhaps > > by adding an example in a new appendix. However, I hardly see the abov= e > > sequence as progressive. > > > > I had always considered quarantine and reject to be two more or less > similar > > alternatives. Each has its merits and shortcomings, and can be chosen > > according to a sender's needs. > > > > An advantage of reject is that one gets NDNs, which are much more > universally > > adopted than failure reports. Perhaps a bank or similar transactional > sender > > would rather prefer reject, because they can timely resend bounced > transactions > > or notices thereof in order to have their duties accomplished. > > > > OTOH, quarantine lets one forget about delivery, perhaps with a > backhanded > > thought of recipients rummaging through their spam folders in search of= a > > missing message. That style seems to me to better suit ESPs, whose dut= y > is > > rather to have a lot of mails sent than to make sure that each message = is > > acknowledged, albeit they try and maximize the ratio. > > > > IMHO, by abolishing quarantine, we make the protocol less flexible than > it is. > > > > > > Best > > Ale > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000036d7a3058ebdded8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From our end user point of view, I'm against = abolishing quarantine, even with its current shortcomings.

Tim
(no hat)

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jul 28, 2019 at 8:48 AM =D0=94= =D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 &= lt;dilyan.pa= lauzov@aegee.org> wrote:
Hello Alessandro,=

abolishing policy quarantine means with p=3Dreject that for failed messages= there should be some penalty and the receiving
site decides on the form of the penalty, e.g. quarantine or reject.

In fact I see the DMARC specification updated to use consistently some neut= ral word, like penalty or punishment attached
to p=3Dreject, once p=3Dquarantine is abolished.=C2=A0 This word is then di= ssected into =E2=80=9Cquarantine or reject=E2=80=9D at the place where
it elaborates on the possible penalties, or how to do reject right.

The penalty could be implemented with reply
550 Message failed DMARC validation and was delivered in the Junk folder of= the recipient

This form has the advantage over either quarantine or reject, that for lost= messages, the sender can call the recipient
and the recipient can dig for the message.=C2=A0 So the message does not ha= ve to be resent and no surprizes happen.=C2=A0 I do not
see how could this reply mess anything, except in the cases where the sende= r does not speak English.

> OTOH, quarantine lets one forget about delivery, perhaps with a backha= nded
> thought of recipients rummaging through their spam folders in search o= f a
> missing message.=C2=A0 That style seems to me to better suit ESPs, who= se duty is
> rather to have a lot of mails sent than to make sure that each message= is
> acknowledged, albeit they try and maximize the ratio.
>
> IMHO, by abolishing quarantine, we make the protocol less flexible tha= n it is.

If an ESP wants to forget about delivery, the ESP likely does not care whet= her it has implemented DMARC correctly and
then it does not need quarantine mode.

The penalty is applied to messages that are either sent by spammers or by t= he domain owner.=C2=A0 If messages are from
spammers, for the domain owner it is irrelevant, what kind of penalty is ap= plied, but for users doing reject means
having to scan less messages in the Junk mailbox.

If messages are from the domain owner and fail DKIM/DMARC validation, the o= nly way to fix DKIM/DMARC is to use policy
reject.=C2=A0 There is no other way to find out which messages fail DKIM/DM= ARC, as single message faiulure reports are rarely
sent, and without knowing which messages fail DMARC fixing the problem is u= nnecessary complicated.

So here, p=3Dquarantine is in fact an option for providers, who do not care= , whether they have implemented DMARC
correctly.

All that said:

=E2=80=A2 Is there a consensus on abolishing policy quarantine?
=E2=80=A2 If policy quarantine will be kept, will the none>quarantine>= ;reject order be abolished, meaning =E2=80=9Cquarantine=E2=80=9D will not be handled as softer variant of =E2=80=9Creject=E2=80=9D?=C2=A0 Meaning wit= h p=3Dreject; pct=3D30 messages are either delivered or rejected, but
the specification does state anything about quaratining 70% of the failed m= essages.

The first argument in favour of keeping policy quarantine was exactly this = order (quarantine is a softer variant of
reject and before deploying reject one has to exercise with quarantine).
Regards
=C2=A0 =D0=94=D0=B8=D0=BB=D1=8F=D0=BD


On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote:
> On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote:
> > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy <superuser@gmail.com&= gt; wrote:
> > >
> > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins <steve@wordtothewise.com> wrote:
> > > > It's interesting that the industry has decided to i= nterpret "p=3Dreject; pct=3D0" the way we intended "p=3Dquar= antine; pct=3D100".
> > >
> > > It's semi-explicitly defined that way in the RFC, isn= 9;t it?
> > >
> > > If so, we should fix it because (a) I don't think that&#= 39;s how we intended it, and (b) in any case, nothing in there should be on= ly semi-explicit.
> >
> > rfc 7489 6.6.4
> >
> > "If email is subject to the DMARC policy of "reject&quo= t;, the Mail
> >=C2=A0 =C2=A0 Receiver SHOULD reject the message (see=C2=A0 Sectio= n 10.3).=C2=A0 If the email
> >=C2=A0 =C2=A0 is not subject to the "reject" policy (due= to the "pct" tag), the
> >=C2=A0 =C2=A0 Mail Receiver SHOULD treat the email as though the &= quot;quarantine"
> >=C2=A0 =C2=A0 policy applies.=C2=A0 This behavior allows Domain Ow= ners to experiment
> >=C2=A0 =C2=A0 with progressively stronger policies without relaxin= g existing
> >=C2=A0 =C2=A0 policy."
> >
> > It's pretty clear and well-defined; the case we're talkin= g about, "p=3Dreject; pct=3D0", is
> > just a special case of this general rule.
> >
> > All emails will not be subject to the "reject" policy d= ue to the pct=3D0 tag, so the mail
> > receiver should treat all emails as though the policy "quara= ntine" applies (which
> > is the same as "p=3Dquarantine; pct=3D100").
>
> I, for one, had missed that point.=C2=A0 Thanks for clarifying it.
>
> It seems to mean that the resulting steps are, for example:
>
>
> "p=3Dquarantine; pct=3D0"=C2=A0 (check From: rewriting)
> "p=3Dquarantine; pct=3D10" (some messages go to the spam fol= der)
> "p=3Dquarantine; pct=3D20"
> ....
> "p=3Dquarantine; pct=3D100"
> "p=3Dreject; pct=3D0"=C2=A0 =C2=A0 =C2=A0 (same as the previ= ous step)
> "p=3Dreject; pct=3D10"=C2=A0 =C2=A0 =C2=A0(some messages bou= nce back)
> "p=3Dreject; pct=3D20"
> ....
>
>
> Is that what we want to suggest?=C2=A0 In that case, we should be clea= rer.=C2=A0 Perhaps
> by adding an example in a new appendix.=C2=A0 However, I hardly see th= e above
> sequence as progressive.
>
> I had always considered quarantine and reject to be two more or less s= imilar
> alternatives.=C2=A0 Each has its merits and shortcomings, and can be c= hosen
> according to a sender's needs.
>
> An advantage of reject is that one gets NDNs, which are much more univ= ersally
> adopted than failure reports.=C2=A0 Perhaps a bank or similar transact= ional sender
> would rather prefer reject, because they can timely resend bounced tra= nsactions
> or notices thereof in order to have their duties accomplished.
>
> OTOH, quarantine lets one forget about delivery, perhaps with a backha= nded
> thought of recipients rummaging through their spam folders in search o= f a
> missing message.=C2=A0 That style seems to me to better suit ESPs, who= se duty is
> rather to have a lot of mails sent than to make sure that each message= is
> acknowledged, albeit they try and maximize the ratio.
>
> IMHO, by abolishing quarantine, we make the protocol less flexible tha= n it is.
>
>
> Best
> Ale

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000036d7a3058ebdded8-- From nobody Mon Jul 29 12:38:02 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 912B812002E for ; Mon, 29 Jul 2019 12:37:59 -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=XE5kflf9; dkim=pass (2048-bit key) header.d=kitterman.com header.b=B7+DdLvi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H5Pd_y9esDt for ; Mon, 29 Jul 2019 12:37:57 -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 4B808120025 for ; Mon, 29 Jul 2019 12:37:57 -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 2AACFF806F7 for ; Mon, 29 Jul 2019 15:37:56 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564429076; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=kqi2AhMn6F2lQAErhOZ3Jd87XhlE2AKz0HpnqrH8Fx0=; b=XE5kflf91WkJ8Mn8B1tPUQaA/SmZi6VYP8gqL0MZbLabGbaDm5hZlJB6 zmjlo03twFNAkJqkkQeI0b60YZzbDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564429076; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=kqi2AhMn6F2lQAErhOZ3Jd87XhlE2AKz0HpnqrH8Fx0=; b=B7+DdLviKfBUjKC/2Zm9SMCBslJAUzAQNslyvPzY6DxaMHnbIpBEeL33 KlRJeZ+I8HCwHLwzKyzAnldTzy1qjXDYzNUsaVYGkFGRCLViXEOMCsaAbY 0LZ/0n4A1u9Hy40ScTxI3KUFXh2pFjxjtTEvI9PHbwpTdcUIEG0EDAl+Fb CpgMZUE6G128oLIlNEUKBfN/QfPJIqVncTwiR19O1MT9o2w8D8HUauUnu2 2hKikQ7Z34Lu0jlUrUP/db16VY051DyGv3yIeYn+JtWhmDiTCTxJxsgNgx 5Jikd+o7JO36tXHJy9d5qUY4PWsXzQwqRWrUccOxQ5K4cHB9tTYl5Q== 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 F147EF80096 for ; Mon, 29 Jul 2019 15:37:55 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 29 Jul 2019 15:37:55 -0400 Message-ID: <2577720.3ZthdXZjm2@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 29 Jul 2019 19:38:00 -0000 I'd like to add the option to record DMARC results in an A-R header field for consumption by a downstream processor. I think it would be something like this: Authentication-Results: mail-router.example.net; dmarc=pass header.from=example.com policy.dmarc=none That would take adding an entry in the Email Authentication Methods registry for: method: dmarc ptype: policy value: dmarc Does that make sense as a way to do it? Does anyone have alternative suggestions? Scott K From nobody Mon Jul 29 12:50:42 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 E417912002F for ; Mon, 29 Jul 2019 12:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLuRuJRjoARQ for ; Mon, 29 Jul 2019 12:50:38 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 8FA91120026 for ; Mon, 29 Jul 2019 12:50:38 -0700 (PDT) Authentication-Results: mail.aegee.org/x6TJoYu2015540; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564429836; i=dkim+MSA-tls@aegee.org; r=y; bh=vNguDgAhT/xPgSUGduZdgKPu1OqtEgJ/QAi/VdPCfYs=; h=Subject:From:To:Date:In-Reply-To:References; b=WUhmrEWiRPMvum+JStOao7/Ea3tjL3kxASeGcg9XWh/kYIvxc2tg54IV2wYf78Ovp KAyzy/jmoipNFETVRMpQbq5gCifbb9INT1LlPWF799HKzGavY4pjF8ZMeHKQ0kbGG3 5XssRMoQrqxyyB/tuc06DNW5dnYoISvFzBTOJN+/0SG3cd2/Pt9nqJKSgX/Tmi3oiJ o6QLNV3Fhveg786pbBuOVvqbmaUWs4Y0M2zq7aY7h7fb9T+uKJXrbCpNzm8Fw7DhyT TG7gfZNRRgQpUl2uQMav44Y/KoYXRmf5ssCodl7H2av0pQzL4vnT4Qz+XWmsJfsa+m 92QiHec2NxNhzt8/v6Zw1ePxAHEiOs49F6AutmgkaTs47iPIcxoVX6nBox0JRePf4T mgL7UtP8aWQUuRhr6CCaO4oO8umaNt/jlYbPaO9D6THhu6DEgN7OHSfQ60jAveWVw0 zL+6NwEYSubAyh5ynw5cVRDIeziFqu1dsUDdKHC5f3ump6b9Fq0OE7Kn5Ga7wlSijg FCVf3ZmoCFVfWYpkQrtI7rU0C+OMDnprcDfIeeVIsTYf73zmzgG/L5WW+mKb7dorHD sEqcdTlO02kdnGPgVPG0GOB4KrkHR6faBtsLX+1v9JrAoOzWYJEwG+dsJdEybqze1U xLFSS8gMZZ9VnbOtgQq2dlqc= Authentication-Results: mail.aegee.org/x6TJoYu2015540; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6TJoYu2015540 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 29 Jul 2019 19:50:35 GMT Message-ID: <9ef6b312a93d2b5542194539bd99e31e8451d7ba.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Scott Kitterman , dmarc@ietf.org Date: Mon, 29 Jul 2019 19:50:34 +0000 In-Reply-To: <2577720.3ZthdXZjm2@l5580> References: <2577720.3ZthdXZjm2@l5580> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 29 Jul 2019 19:50:41 -0000 Hello Scott, You want to add the option to record the DMARC policy in the A-R header. I add it as comment: Authentication-Results: mail.example.org/x551xr2q019874; dmarc=pass (p=quarantine dis=none) header.from=example.com; spf=pass smtp.mailfrom=uuuu@example.com with dis being the disposition. What will a downstream processor do with the information? Regards Dilyan On Mon, 2019-07-29 at 15:37 -0400, Scott Kitterman wrote: > I'd like to add the option to record DMARC results in an A-R header field for > consumption by a downstream processor. I think it would be something like > this: > > Authentication-Results: mail-router.example.net; dmarc=pass > header.from=example.com policy.dmarc=none > > That would take adding an entry in the Email Authentication Methods registry > for: > > method: dmarc > ptype: policy > value: dmarc > > Does that make sense as a way to do it? Does anyone have alternative > suggestions? > > Scott K > From nobody Mon Jul 29 12:59:35 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 0BCF712004D for ; Mon, 29 Jul 2019 12:59:34 -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=8JXHwK+5; dkim=pass (2048-bit key) header.d=kitterman.com header.b=SCu8i8Ba Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwEU0Q8Aod3h for ; Mon, 29 Jul 2019 12:59:32 -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 3F628120045 for ; Mon, 29 Jul 2019 12:59:32 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 47F64F806FC for ; Mon, 29 Jul 2019 15:59:31 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564430371; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ecwbqBhVYp71GMVXYrK4mKc5gtuViP4q5ISdHZcRQEw=; b=8JXHwK+5jn3gGgZX4O+IpurdUopExHIOubK+TDAj73ZTlpX9wge8OrvQ Pu37XC15FCvQIBDLh+7QBeryIK+9BA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564430371; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=ecwbqBhVYp71GMVXYrK4mKc5gtuViP4q5ISdHZcRQEw=; b=SCu8i8Bavm+FZ6Kg7+1rOEEn58YJoOcguZ/Ag+riLqVODM5IgFZRk2tx wdJWyn/cLX2Nz3cFJpsKndI7FgKmfckM58/qu1Htww8FmrFgNqxnNwEPAb 5w1/Mx+oCWFxgHicPXYkERunpsmIkogDLZbcNzO+WSY6jd1CAJmWHyvmqH FZi/hfCJvZaDYi11N7a/kGLP+NSszsW9okrtk5CQbBxfT2nL9Ko0C/HHfw RG3Sd6U34YdzGLaCtI/kFd8Khkrvi4s7rV105ZQgnaV18wwYXZMQ75T+75 3dC/vSw1rKdWQlJ83iXukn7Hw3eJ9+ZDfNWkYYWilE6HWnJGWBPP3g== 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 155C1F80096 for ; Mon, 29 Jul 2019 15:59:31 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 29 Jul 2019 15:59:30 -0400 Message-ID: <2267305.yL6gokGGJv@l5580> In-Reply-To: <9ef6b312a93d2b5542194539bd99e31e8451d7ba.camel@aegee.org> References: <2577720.3ZthdXZjm2@l5580> <9ef6b312a93d2b5542194539bd99e31e8451d7ba.camel@aegee.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 29 Jul 2019 19:59:34 -0000 On Monday, July 29, 2019 3:50:34 PM EDT =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0= =9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello Scott, >=20 > You want to add the option to record the DMARC policy in the A-R header. = I > add it as comment: >=20 > Authentication-Results: mail.example.org/x551xr2q019874; dmarc=3Dpass > (p=3Dquarantine dis=3Dnone) header.from=3Dexample.com; spf=3Dpass > smtp.mailfrom=3Duuuu@example.com >=20 > with dis being the disposition. >=20 > What will a downstream processor do with the information? It would execute the policy (e.g. reject or quarantine). I would rather=20 enforce reject in the MTA and leave quarantine to the MDA since that's just= a=20 question of which folder the mail lands in, not really an MTA function. If= =20 you don't do all the policy enforcement in the MTA, then there needs to be= =20 some way to record it. Scott K > On Mon, 2019-07-29 at 15:37 -0400, Scott Kitterman wrote: > > I'd like to add the option to record DMARC results in an A-R header fie= ld > > for consumption by a downstream processor. I think it would be somethi= ng > > like this: > >=20 > > Authentication-Results: mail-router.example.net; dmarc=3Dpass > > header.from=3Dexample.com policy.dmarc=3Dnone > >=20 > > That would take adding an entry in the Email Authentication Methods > > registry for: > >=20 > > method: dmarc > > ptype: policy > > value: dmarc > >=20 > > Does that make sense as a way to do it? Does anyone have alternative > > suggestions? > >=20 > > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Jul 29 21:55:32 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 7412D12004F for ; Mon, 29 Jul 2019 21:55:30 -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=0rMSLKQd; dkim=pass (2048-bit key) header.d=kitterman.com header.b=SsYfWE17 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPyEqjK7_ID3 for ; Mon, 29 Jul 2019 21:55:28 -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 CCF99120047 for ; Mon, 29 Jul 2019 21:55:28 -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 1C171F80706 for ; Tue, 30 Jul 2019 00:54:58 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564462497; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Dz0YQRW2ie5CDUh1EmSb+4UK4m/FHbmFitMqzw8eO3w=; b=0rMSLKQdhP2XtUjy16jdD9qwdjlDKqVymgmxB/92SHoHW39iR1HCsRhi 287587P/Ta3CZ5IAPlUPJXIJKiXxBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564462497; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=Dz0YQRW2ie5CDUh1EmSb+4UK4m/FHbmFitMqzw8eO3w=; b=SsYfWE17TLx+QTIWJbcvdsRnv2f1kwWpwN6vEiFkRPtoJ5oGm+qG8cwr GGmyaIY0I01ZF/rmP5mFPLYJs5aPSNWMmR0lH+fILsSLuNtdplkK8zcl25 /Xv0EnUrMqSpePKQm3r+A5VuaXELSbmbGBptk/LZupLGQeGtp7hXU0Hm4w nuyUAr+Sppp/otvapYkularoQifEjFIApr0i9kImb682oWq3ir0xTKVncy cjfONhoNmnwxM4fovTzOw4B/iJG7Fj2+qLtLoiJLt8h0Y0onem/+IBHKdM /QD/baHAh3A5Yx5oH2hiPnqsW3zhGQLEY1fsHo4dpY0kRpywTBK/Ng== 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 DC5C9F806FC for ; Tue, 30 Jul 2019 00:54:57 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 30 Jul 2019 00:54:57 -0400 Message-ID: <4600949.rz9u5RyGOV@l5580> In-Reply-To: <2577720.3ZthdXZjm2@l5580> References: <2577720.3ZthdXZjm2@l5580> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 30 Jul 2019 04:55:31 -0000 On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote: > I'd like to add the option to record DMARC results in an A-R header field > for consumption by a downstream processor. I think it would be something > like this: > > Authentication-Results: mail-router.example.net; dmarc=pass > header.from=example.com policy.dmarc=none > > That would take adding an entry in the Email Authentication Methods registry > for: > > method: dmarc > ptype: policy > value: dmarc > > Does that make sense as a way to do it? Does anyone have alternative > suggestions? I think comments should be free-form. If we want data that can be machine parsed, we should specify it. I think the above works in ABNF terms. It's: Authentication-Results:" authserv-id; method=result ptype.property=value ptype.property=value According to the ABNF, there can be more than one propspec (ptype.property=value) per methodspec in resinfo, so I think it's legal. It would just need the new registry values for dmarc. Scott K From nobody Tue Jul 30 01:27:31 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 C59E912012A for ; Tue, 30 Jul 2019 01:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=2.65, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no 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 sNve7Ij0Q_Bp for ; Tue, 30 Jul 2019 01:27:28 -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 A74831200EF for ; Tue, 30 Jul 2019 01:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564475246; bh=eFyyr4K3DUL1sqmeEDhwGpXI9H5RI80y2WCzBJyNsnM=; l=2280; h=To:References:From:Date:In-Reply-To; b=DVg4gk2bFcV0q584nUVHK1IUR3mUEJYSSMIU1j3Xye+1ZdfotTl7MQccPQn/oVkl0 Mk/1CYZURjSvhvdJYdWAATsn107yU39qGD+LpSTKib5+/IU4u78K2Qk2d7ZkmEbdGF KGvYgl4Yqc2S8lXmz+ds/ksP5t5+ze8zO0xAFQTQzqxfRM4OTWFojzqwIDsMT 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 00000000005DC07B.000000005D3FFF6E.00000536; Tue, 30 Jul 2019 10:27:26 +0200 To: dmarc@ietf.org References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <3b3e4f30-7060-b534-e5d7-46981d84e821@tana.it> Date: Tue, 30 Jul 2019 10:27:26 +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: <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine 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, 30 Jul 2019 08:27:30 -0000 On Sun 28/Jul/2019 12:49:12 +0200 Дилян Палаузов wrote: > The penalty could be implemented with reply > 550 Message failed DMARC validation and was delivered in the Junk folder of the recipient > Usually, receiving MTAs drop the message after replying 5xx. > If an ESP wants to forget about delivery, the ESP likely does not care > whether it has implemented DMARC correctly and then it does not need > quarantine mode. They may want to protect their brand, avoiding that more spam be attributed to them than what they actually generated. > • If policy quarantine will be kept, will the none>quarantine>reject order > be abolished, meaning “quarantine” will not be handled as softer variant of > “reject”? Meaning with p=reject; pct=30 messages are either delivered or > rejected, but the specification does state anything about quaratining 70% of > the failed messages. I can hardly corroborate my analysis by looking at what I received. My DB of sending domains has: 96260 domain names, of which 55110 are organizational domains; 3887 have DMARC records, of which 3046 have policy 'none', 418 have policy 'reject', 271 have policy 'quarantine', 73 have both 'none' and 'reject', 45 have both 'none' and 'quarantine', 34 have both 'quarantine' and 'reject'. 393 of those DMARC domains are not organizational domains, yet 79 of them also specify sp=. There is some confusion about how to setup DMARC; some easy howto seems to be missing. On multiple policies, only 4 of the latter 34 have p=quarantine; sp=reject; the other 30 have p=reject; sp=quarantine. By comparison, the previous 73 + 45 have about the same ratio of p=hard/p=none; 45/28 for reject and 29/16 for quarantine, so some 63% of those have p=hard; sp=none. Can one infer from here the intent of the 30 p=reject; sp=quarantine? My feeling while looking at that data is that 'reject' is sometimes considered /better/ than 'quarantine', which I don't think is true. This confusion can originate from the sequential order implied by that passage of Section 6.6.4 that Steve quoted. I agree that that Section needs to be amended. In particular, the effect of pct=0 on From: rewriting should be mentioned. Best Ale -- From nobody Tue Jul 30 06:34:54 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 A155C12019F for ; Tue, 30 Jul 2019 06:34:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU0XN-cEXPjo for ; Tue, 30 Jul 2019 06:34:50 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 405CA1201EE for ; Tue, 30 Jul 2019 06:34:49 -0700 (PDT) Authentication-Results: mail.aegee.org/x6UDYkTF017367; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564493687; i=dkim+MSA-tls@aegee.org; r=y; bh=KhCeJuK5eM5Xj9nGUc7d/5+Sa6bSSEuBquY5JmjJl2A=; h=Subject:From:To:Date:In-Reply-To:References; b=Txkh431rqr7kC60UUOU18eRK9H4Xk2ehUSeXbB1IFY0yelEeDzN5s9dYedEnbwSEf ir4UQsjQOSij7N+dWBO7Yl+8qqRXfCRCe/q5cX8Mr6YroDkW+3Pwg2YTMgSmxn5uA7 GBGNw7qMy9hIC97pKS7u16SnaW0ObyfWsDNwyeRUivE1TodmF2n8NnRPAhhfVt+W6N GmrA8aovoKGgW0xmqlTp3N69qxttNvyd/10uUCxQFBPUmuuv9MgbH0fI6ap9GZeuCT 1xMXjigkw58FqiUrePLGLPwIz0wuj3IDWC0aikDsWYJk7tAh8n/zbC9l2YnC0LByFt JjvOw3EwUaGHEBxlgWe6/xF67WSbCdhnme2d0KA/Ak14rHLp4asU89TLClvCzVQkQY 5hrm6Y4ppMjxhksTD7uCQCO0l28c+dBEtZIRdQhjzDz9i8LmE8xEIa1EejclTjAx/h NERLCGFvJKggMxtgquBiPJP2BXFbVVlwifCT1ANA2DCWAlHn0MGUTqpkTBSWm8V6lm OWtPkYCOPq7/de3lNFDZV7l2p2IVNVx/yG4g8UW5T4JjYfxwo6I9l5ozSsamyNFZ79 GccoYRguA9kZbIJF0Ir5BinXgCuQZLxlX2jId1GE+msKj40OPwmjuRmJI5fjoBmXI0 rrC2/zBciOSsdfNtSg/y0Fuc= Authentication-Results: mail.aegee.org/x6UDYkTF017367; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6UDYkTF017367 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 30 Jul 2019 13:34:47 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Scott Kitterman , dmarc@ietf.org Date: Tue, 30 Jul 2019 13:34:46 +0000 In-Reply-To: <4600949.rz9u5RyGOV@l5580> References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 30 Jul 2019 13:34:53 -0000 Hello Scott, do you want to include in the A-R header the published policy, as obtained from DNS (my first interpretation of your proposal), or the disposition of the message after applying DKIM/SPF/DMARC validation, pct sampling, and the ominous reject→quarantine sampling conversions? With disposition I mean what is called at https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result. For the disposition on p=reject only the MTA can make the decision based on pct to reject, so it makes sense if the result of disposition is included in the A-R header by the MTA and consumed by the MDA. In turn, including pct and published DMARC policy in the A-R header, so that the MDA can do the sampling, does not make sense. If you want to call the new parameter “policy”, then it shall be articulated that it means disposition, and not published policy. I am in favour of the proposal. It allows for forwarded emails/aliases to indicate in the A-R header, that sampling was already performed by the aliasing server, and the final server that accepts the email can skip performing the sampling again. Performing the sampling again has the disadvantage, that the pct= parameter is misinterpreted, as the parameter is supposed to be applied only once. On the other side, skipping of the second sampling by whatever server is pure theory, and has no practical impact. Greetings Дилян On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: > On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote: > > I'd like to add the option to record DMARC results in an A-R header field > > for consumption by a downstream processor. I think it would be something > > like this: > > > > Authentication-Results: mail-router.example.net; dmarc=pass > > header.from=example.com policy.dmarc=none > > > > That would take adding an entry in the Email Authentication Methods registry > > for: > > > > method: dmarc > > ptype: policy > > value: dmarc > > > > Does that make sense as a way to do it? Does anyone have alternative > > suggestions? > > I think comments should be free-form. If we want data that can be machine > parsed, we should specify it. > > I think the above works in ABNF terms. It's: > > Authentication-Results:" authserv-id; method=result ptype.property=value > ptype.property=value > > According to the ABNF, there can be more than one propspec > (ptype.property=value) per methodspec in resinfo, so I think it's legal. It > would just need the new registry values for dmarc. > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jul 30 06:57: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 B90781201F8 for ; Tue, 30 Jul 2019 06:56:51 -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=XHRJN4q1; dkim=pass (2048-bit key) header.d=kitterman.com header.b=kqyhQDOI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMOHVP2FwjIS for ; Tue, 30 Jul 2019 06:56:49 -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 218D412022C for ; Tue, 30 Jul 2019 06:56:49 -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 2BB83F805B5; Tue, 30 Jul 2019 09:56:18 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564494978; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=UAWDkQDRQzID7+IoPqBOpPR3ykFefezdRROC63U+q64=; b=XHRJN4q16kA3JhkxEbUWPRqeVe3Ol7XUpOKcJVgh7f0Uw9ECGFk+iboo rDyAXcmj/B1z2r7/8tO9mBAMCbrwCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564494978; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=UAWDkQDRQzID7+IoPqBOpPR3ykFefezdRROC63U+q64=; b=kqyhQDOI143Ccd5jidIKXAGS8v/B4ctVR8JsFdaqhIDe/QoAJy/MzO5A FxOHidr+Cqj37ud59tOGH0dzLQOuXhyLz+iV7X4uxc8FNdxN8hEiazMbfR R7Qpt2Y21heQtwQBRTBjM4XUD+hitv4G6rhUcgm2gLh2EKjvgT/3uhfYU0 BHGBFEKnSToE+Pbmw3nq92EXZ09PP1PiXOP24+GQbCgwLxjl+GdPTXkvYw FGemgAdYv+WhDbD3bwWFC5Nzca8KL9krhHDY5LC3kMDNkGZ4nuP4IStt2Z 4uXDQHtMFhRMn4rXtivHSY3jbdpe2YJ0iJFetnQov4sFVgEN+Dl84g== Received: from [10.228.214.248] (mobile-166-171-59-242.mycingular.net [166.171.59.242]) by interserver.kitterman.com (Postfix) with ESMTPSA id D56FBF80096; Tue, 30 Jul 2019 09:56:17 -0400 (EDT) Date: Tue, 30 Jul 2019 13:56:16 +0000 In-Reply-To: References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> 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: <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 30 Jul 2019 13:56:58 -0000 The published policy (that's why I suggest dmarc=2Epolicy)=2E I'm not sure= if disposition belongs in A-R=2E If it does, it'd be a local policy overr= ide, probably policy=2Edmarc as described now in RFC 8616=2E Scott K On July 30, 2019 1:34:46 PM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0= =B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2" wr= ote: >Hello Scott, > >do you want to include in the A-R header the published policy, as >obtained from DNS (my first interpretation of your >proposal), or the disposition of the message after applying >DKIM/SPF/DMARC validation, pct sampling, and the ominous >reject=E2=86=92quarantine sampling conversions? > >With disposition I mean what is called at >https://tools=2Eietf=2Eorg/html/rfc6591#section-3=2E2=2E2 Delivery-Result= =2E > >For the disposition on p=3Dreject only the MTA can make the decision >based on pct to reject, so it makes sense if the >result of disposition is included in the A-R header by the MTA and >consumed by the MDA=2E In turn, including pct and >published DMARC policy in the A-R header, so that the MDA can do the >sampling, does not make sense=2E > >If you want to call the new parameter =E2=80=9Cpolicy=E2=80=9D, then it s= hall be >articulated that it means disposition, and not >published policy=2E > >I am in favour of the proposal=2E > >It allows for forwarded emails/aliases to indicate in the A-R header, >that sampling was already performed by the >aliasing server, and the final server that accepts the email can skip >performing the sampling again=2E Performing the >sampling again has the disadvantage, that the pct=3D parameter is >misinterpreted, as the parameter is supposed to be >applied only once=2E > >On the other side, skipping of the second sampling by whatever server >is pure theory, and has no practical impact=2E > >Greetings > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > >On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: >> On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote: >> > I'd like to add the option to record DMARC results in an A-R header >field >> > for consumption by a downstream processor=2E I think it would be >something >> > like this: >> >=20 >> > Authentication-Results: mail-router=2Eexample=2Enet; dmarc=3Dpass >> > header=2Efrom=3Dexample=2Ecom policy=2Edmarc=3Dnone >> >=20 >> > That would take adding an entry in the Email Authentication Methods >registry >> > for: >> >=20 >> > method: dmarc >> > ptype: policy >> > value: dmarc >> >=20 >> > Does that make sense as a way to do it? Does anyone have >alternative >> > suggestions? >>=20 >> I think comments should be free-form=2E If we want data that can be >machine=20 >> parsed, we should specify it=2E >>=20 >> I think the above works in ABNF terms=2E It's: >>=20 >> Authentication-Results:" authserv-id; method=3Dresult >ptype=2Eproperty=3Dvalue=20 >> ptype=2Eproperty=3Dvalue >>=20 >> According to the ABNF, there can be more than one propspec=20 >> (ptype=2Eproperty=3Dvalue) per methodspec in resinfo, so I think it's >legal=2E It=20 >> would just need the new registry values for dmarc=2E >>=20 >> Scott K >>=20 >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dmarc > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc From nobody Tue Jul 30 07:29: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 2ED4C1201E7 for ; Tue, 30 Jul 2019 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIVZLOUA3pNL for ; Tue, 30 Jul 2019 07:29:29 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 7DF151201B3 for ; Tue, 30 Jul 2019 07:29:29 -0700 (PDT) Authentication-Results: mail.aegee.org/x6UETQeU030615; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564496967; i=dkim+MSA-tls@aegee.org; r=y; bh=HL7sQ8mZxJWEVP7g6Ai7WtS3mkxt1/WvEQGVXi96kg0=; h=Subject:From:To:Date; b=iQ6Ad2v7qPfJOUU0WXM+Chqv1/g4lcfwDou1XJ6ex2e1nSQUi5dZBnPekeJ/7vn9D VD1USk86nUv6DPupuzuiEuBQgSPxjwfoHh3AXUZMVR1qlp6pWX7X43rA7eQvhhlzvy lpRjdi/lbUmUGkmwnvF/gBTHQgVpKVOIrxmTG0UkcDviIQNpgyh1DrDo6Z5+0ahwiD xLVOudpNcJtHUnd2jcQwLxgimBsl8cmZzHiuCAcIxDpBS+bSR9h1B13mKRB49zvZUi bwvUxCnu9mkpan9M+2G2bcT6Eb6muu8H0z0bv8m3sbfmBbgiZESx5iwXyvA7Bd5jIa 2vyJRnUCiRh/jN6h+zAfQeoTNznTF5/ZD3j0RXpGABQk8kAnQfqlz8rqEdOWhb8WWj ALdmc7xIu3pOzAZqDa6zhwh49HSfcqz/6mgjE63tlDvJk/x6eV7SgXv+SyqSzx7yyF My546/XmFeQK7+BgmelQWOp4TT3xq1JN5GRHn5tKezQsIIiK7hozyKmpS7eEPUdHNG Ljh8ouAvc3vK6FVqMh2a1B6Kr3d41Aw9vmMcrml2J4adJVTcE86HXIiiYoexS/5w5h JrSFOkO2ScDerdR8j7Sy18iZhfEuXuIgs/Xy8YAZ7PkegqeIMDZ70P6mS/SaoyeGDs w+UAh6PU8PZPlmj/kghuhua4= Authentication-Results: mail.aegee.org/x6UETQeU030615; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6UETQeU030615 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 30 Jul 2019 14:29:27 GMT Message-ID: <187a4f8129f624d5590b553aff40489c8d24fb97.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: dmarc@ietf.org Date: Tue, 30 Jul 2019 14:29:26 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [dmarc-ietf] if policy quarantine will be kept 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, 30 Jul 2019 14:29:33 -0000 Hello, if policy quarantine will be kept, I propose including this text in the specification: Messages, subject to the quarantine policy, directed to a single recipient that does not support the concept of quarantining, can be either accepted and delivered, accepted and discarded, or rejected. Messages, subject to the quarantine policy, directed to many recipients, some of which support the concept of quarantining, and the others not supporting this concept, can be either: * accepted, quarantined for the first group of recipients and discarded for the other recipients, * accepted, quarantined for the first group of recipients and delivered to the other recipients, * segmented or * rejected as whole Discarding is to be avoided. Accepting and delivering the message ignores completely the DMARC policy. Segmentation imposes delivery delays. This specification recommends in both cases overriding the policy and rejecting the message. Regards Дилян From nobody Tue Jul 30 14:22: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 63D0E1201C9 for ; Tue, 30 Jul 2019 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=Cvce4CpL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TLLKf3S5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw23FP-VOlIE for ; Tue, 30 Jul 2019 14:22:12 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F9012015B for ; Tue, 30 Jul 2019 14:22:11 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 344E421F57 for ; Tue, 30 Jul 2019 17:22:11 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Tue, 30 Jul 2019 17:22:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=7uV6aXA5qz+1+Eub1ABNEovRqQS4H8g cgUpiuqiKqvM=; b=Cvce4CpLnsFECeGjXwG3fGoj5HGXsdQSkaITb7EuTVUB5EJ FF3UQs3cdypFByYhbEq/227iK46zGbEPr/W6NW/qDdQ4RTiw6Kjfl7Q7hQVncRem AiiqV5yDmleE32b6nmoaSa+h+Qmx+EZy0vdqmnnb5Qtdk9m/EPuGpBM3dOmEox/T LE3lJHBw2irFHVZIxOIbkP4uNh6Ef4+EHI5yV2eoMy8/zqOsd4ArNaGRk7ldj1f5 8evwWKf8ZP/FReVDpERd/4LeBNUoXsOBZNBVudcefe3f8qSKbGCeodPL5qeK3WkG Yg9oivZHCEH5x4305n9Xa1taTIDzZDUzIFozhqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7uV6aX A5qz+1+Eub1ABNEovRqQS4H8gcgUpiuqiKqvM=; b=TLLKf3S5pFMsKDONGLLUya lXqzIWQJqOOrB0bYWUN8zmbv5CxoCw9xrYeMuIOp5t1wGj+6cmH3FnJ/WVTKjIag WBOzs2SiLCLlyPwe4N5Vr7BIPBY/H3wqCXD7bVFoHjdoYSbLUb5q6f8q0fEHt6Q7 rckzeKOZuvrJo0jg+TRDfcAsKyULkvrdPUUcH0R0EIgpcomaDNXcM2dw8cDXIPTy Y+rM61niqUy6aSUheJ3bET/hrMCX0tIBl0lReWGBQH1T/3awFeS60FQfPV4BdVuQ bCrs/Ia0dye7acl4zWXqZBOqyxM9Ggqdjp8XOS+f9GaOo96eaCYhuWAxctWQApAg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleefgdduheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfufhtrghnucfmrghlihhstghhfdcuoehsthgrnhesghhl hihphhgvihhnrdhmrghilhhfohhrtggvrdhnvghtqeenucffohhmrghinhepvgigrghmph hlvgdrnhgvthdpihgvthhfrdhorhhgpdhpohhlihgthidrihhmpdgvgigrmhhplhgvrdgt ohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgrnhesghhlhihphhgvihhnrdhmrg hilhhfohhrtggvrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD80E1400FE; Tue, 30 Jul 2019 17:22:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1 Mime-Version: 1.0 Message-Id: <2b36f1da-581d-4fbf-928d-d9ae1e1b2ba4@www.fastmail.com> In-Reply-To: <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> Date: Tue, 30 Jul 2019 17:21:28 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=9d6598e4bce74139ba773d0d02d050a2 Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 30 Jul 2019 21:22:14 -0000 --9d6598e4bce74139ba773d0d02d050a2 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2019, at 9:57 AM, Scott Kitterman wrote: > The published policy (that's why I suggest dmarc.policy). I'm not sure= if disposition belongs in A-R. If it does, it'd be a local policy overr= ide, probably policy.dmarc as described now in RFC 8616. In that case, if the downstream were to make use of the upstream's dispo= sition, it's extrapolating a meaning from the disposition, but not actua= lly deriving meaning from the authentication results themselves, so I'm = inclined to agree. Thanks, Stan > Scott K >=20 > On July 30, 2019 1:34:46 PM UTC, "=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F= =D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2" = wrote: > >Hello Scott, > > > >do you want to include in the A-R header the published policy, as > >obtained from DNS (my first interpretation of your > >proposal), or the disposition of the message after applying > >DKIM/SPF/DMARC validation, pct sampling, and the ominous > >reject=E2=86=92quarantine sampling conversions? > > > >With disposition I mean what is called at > >https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result. > > > >For the disposition on p=3Dreject only the MTA can make the decision > >based on pct to reject, so it makes sense if the > >result of disposition is included in the A-R header by the MTA and > >consumed by the MDA. In turn, including pct and > >published DMARC policy in the A-R header, so that the MDA can do the > >sampling, does not make sense. > > > >If you want to call the new parameter =E2=80=9Cpolicy=E2=80=9D, then = it shall be > >articulated that it means disposition, and not > >published policy. > > > >I am in favour of the proposal. > > > >It allows for forwarded emails/aliases to indicate in the A-R header,= > >that sampling was already performed by the > >aliasing server, and the final server that accepts the email can skip= > >performing the sampling again. Performing the > >sampling again has the disadvantage, that the pct=3D parameter is > >misinterpreted, as the parameter is supposed to be > >applied only once. > > > >On the other side, skipping of the second sampling by whatever server= > >is pure theory, and has no practical impact. > > > >Greetings > > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > >On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: > >> On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote: > >> > I'd like to add the option to record DMARC results in an A-R head= er > >field > >> > for consumption by a downstream processor. I think it would be > >something > >> > like this: > >> >=20 > >> > Authentication-Results: mail-router.example.net; dmarc=3Dpass > >> > header.from=3Dexample.com policy.dmarc=3Dnone > >> >=20 > >> > That would take adding an entry in the Email Authentication Metho= ds > >registry > >> > for: > >> >=20 > >> > method: dmarc > >> > ptype: policy > >> > value: dmarc > >> >=20 > >> > Does that make sense as a way to do it? Does anyone have > >alternative > >> > suggestions? > >>=20 > >> I think comments should be free-form. If we want data that can be > >machine=20 > >> parsed, we should specify it. > >>=20 > >> I think the above works in ABNF terms. It's: > >>=20 > >> Authentication-Results:" authserv-id; method=3Dresult > >ptype.property=3Dvalue=20 > >> ptype.property=3Dvalue > >>=20 > >> According to the ABNF, there can be more than one propspec=20 > >> (ptype.property=3Dvalue) per methodspec in resinfo, so I think it's= > >legal. It=20 > >> would just need the new registry values for dmarc. > >>=20 > >> Scott K > >>=20 > >>=20 > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > > > >_______________________________________________ > >dmarc mailing list > >dmarc@ietf.org > >https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 --9d6598e4bce74139ba773d0d02d050a2 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2019, at 9:57 AM, Scott Kitterman wrote:
The published policy (that's why I suggest dmarc.policy).  I'= m not sure if disposition belongs in A-R.  If it does, it'd be a lo= cal policy override, probably policy.dmarc as described now in RFC 8616.=

In that case, if the = downstream were to make use of the upstream's disposition, it's extrapol= ating a meaning from the disposition, but not actually deriving meaning = from the authentication results themselves, so I'm inclined to agree.

Thanks,
Stan

<= /div>
Scott K

On July 30, 2019 1:34:46 PM UTC, "=D0=94=D0=B8= =D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2" <= ;dilyan.palauzov@aegee.org> wrote:
>Hello Scott,
>= ;
>do you want to include = in the A-R header the published policy, as
>obtained from DNS (my first interpretation of your
=
>proposal), or the dispositio= n of the message after applying
>DKIM/SPF/DMARC validation, pct sampling, and the ominous
>reject=E2=86=92quarantine samplin= g conversions?
>
=
>With disposition I mean what is ca= lled at
>https://tools.iet= f.org/html/rfc6591#section-3.2.2 Delivery-Result.
>
>= ;For the disposition on p=3Dreject only the MTA can make the decision
>based on pct to reject, so = it makes sense if the
>res= ult of disposition is included in the A-R header by the MTA and
>consumed by the MDA.  In tur= n, including pct and
>publ= ished DMARC policy in the A-R header, so that the MDA can do the
>sampling, does not make sense.
>
>If you want to call the new parameter =E2=80=9Cpol= icy=E2=80=9D, then it shall be
>articulated that it means disposition, and not
>published policy.
>
>I a= m in favour of the proposal.
= >
>It allows for forwar= ded emails/aliases to indicate in the A-R header,
>that sampling was already performed by the
<= /div>
>aliasing server, and the fina= l server that accepts the email can skip
>performing the sampling again.  Performing the
<= /div>
>sampling again has the disadv= antage, that the pct=3D parameter is
>misinterpreted, as the parameter is supposed to be
=
>applied only once.
>
>On the other side, skipping of the second sampling by whatever s= erver
>is pure theory, and= has no practical impact.
>= ;
>Greetings
>  =D0=94=D0=B8=D0=BB=D1=8F=D0=BD<= br>
>
>On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterma= n wrote:
>> On Monday, = July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote:
>> > I'd like to add the option to record = DMARC results in an A-R header
>field
>> > for= consumption by a downstream processor.  I think it would be
>something
>> > like this:
>> > 
>> > Authentication-Results: mail-router.example.net; d= marc=3Dpass
>> > hea= der.from=3Dexample.com policy.dmarc=3Dnone
>> > 
>> > That would take adding an entry in the Email Authenti= cation Methods
>registry
>> > for:
>> > 
>> > method: dmarc
>> > ptype: policy
>> > value: dmarc
>> > 
>> > Does that make sense as a way to do it?  Does= anyone have
>alternative<= br>
>> > suggestions?
>> 
>> I think comments should be free-form= .  If we want data that can be
>machine 
>= > parsed, we should specify it.
>> 
>>= I think the above works in ABNF terms.  It's:
>> 
>> Authentication-Results:" authserv-id; method=3Dresult
>ptype.property=3Dvalue = ;
>> ptype.property=3Dv= alue
>> 
=
>> According to the ABNF, there = can be more than one propspec 
>> (ptype.property=3Dvalue) per methodspec in resinfo, so I= think it's
>legal.  = It 
>> would just = need the new registry values for dmarc.
>> 
>= ;> Scott K
>> <= br>
>> 
>> __________________________________= _____________
>> dmarc = mailing list
>> dmarc@i= etf.org
>> https://www.= ietf.org/mailman/listinfo/dmarc
>
>_________________= ______________________________
>dmarc mailing list
>= dmarc@ietf.org
>https://ww= w.ietf.org/mailman/listinfo/dmarc

_______________________= ________________________
dmar= c mailing list
dmarc@ietf.org=
https://www.ietf.org/mailman= /listinfo/dmarc


--9d6598e4bce74139ba773d0d02d050a2-- From nobody Wed Jul 31 00:11:55 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 3A8F412008F for ; Wed, 31 Jul 2019 00:11:54 -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 wyfDy6PpvwD3 for ; Wed, 31 Jul 2019 00:11:52 -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 6271212009E for ; Wed, 31 Jul 2019 00:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1564557110; bh=qWv7wrtDwzv/j+P/yREguzI/sA3SYJ3Fl/kBI76fK5A=; l=1342; h=To:References:From:Date:In-Reply-To; b=C46YW0cOC1CF6c4QEoEB2TF/ZXcKqL2SpZvurW35Hd1hzSg2aOebzpzU18WOh5S/O Pnw1BQOIII81S0sxdVAR5wf4WmnYAlHro6TIVRxNNiPydLfu9GQwqTpCuS2cObjzk5 cDnHZx/3MS3Os0Uk41JA75j0BF8VDu8xhgdYLyFSlaFZXOYEbEwEXlHPd3XTc 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 00000000005DC082.000000005D413F36.00003055; Wed, 31 Jul 2019 09:11:50 +0200 To: dmarc@ietf.org References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: Date: Wed, 31 Jul 2019 09:11:49 +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: <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 31 Jul 2019 07:11:54 -0000 On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote: > The published policy (that's why I suggest dmarc.policy). Published policy can be ambiguous. Say you have p=quarantine; sp=none. The MTA chooses which to apply based on the domains (publishing and From:). So it makes sense to write the /applied/ published policy. I'm not good at designing A-R stanzas, as you know. However, since dmarc is already the policy method, why not write dns.policy, since that is where it comes from? > I'm not sure if disposition belongs in A-R. If it does, it'd be a local > policy override, probably policy.dmarc as described now in RFC 8616. You mean RFC 7489, don't you? I see nothing about A-R in RFC 8616. Would it be possible to add a result of "quarantine"? Having dmarc=fail and dns.policy=quarantine leaves a good deal of interpretation to the MDA. If one could write dmarc=quarantine, a simple string search or regular expression would do. Currently, I use a comment too. Since we're at it, besides the spam folder, is it fine if the MDA sets IMAP keyword $Junk[*] or $Phishing[†] or would we dare registering a new one? Best Ale -- [*] https://www.iana.org/assignments/imap-jmap-keywords/junk/junk-template [†] https://www.iana.org/assignments/imap-jmap-keywords/phishing/phishing-template From nobody Wed Jul 31 02:47: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 6C9DA12003F for ; Wed, 31 Jul 2019 02:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTvc6EjaFvwu for ; Wed, 31 Jul 2019 02:47:32 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 DBC9E120033 for ; Wed, 31 Jul 2019 02:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gjyMH81qITkCkFO0D9PIPVHPEqdhH9jq1GYGkyig1x8=; b=HoVA5fgDMn5Ngw3cdsEwG3risg JOGdoZ2ncVbf+Xs6xJH/edsQP6L5SjQwTG8LDCgytFTf99asSUF/KGB3t3AOSfWqcFMezqrWzxnOf GArgOPqYmLXEp7a3/IqcRnApt7x9Zi3ZQe/BVeoNjhNF0W1ZKQDYlWvT115BY3HbFF5VKQbq9Bfw0 ph/F7rY5KC/yfZuf/mb6N1DWhtqEo/p/Bv0GGyQPpVTD7NDeCMDObqiWdtOQVc7Oml7bql7ChTmI4 d3AlGbtIeG2weHi4tmdrMolrn3hXRTO6fPLm5/uGpGQNml2h4ZVw2GQMfZKgtq6qpWIdigOWcQm5d eeXVFzXA==; Received: from 83-83-140-171.cable.dynamic.v4.ziggo.nl ([83.83.140.171] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hslCj-0006jw-B0 for dmarc@ietf.org; Wed, 31 Jul 2019 11:47:29 +0200 From: "Freddie Leeman" To: Date: Wed, 31 Jul 2019 11:47:29 +0200 Message-ID: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01D54795.BBB99AA0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVHd+Tnb/OcO6SJQ6ewR7XrEBdXOw== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 31 Jul 2019 09:47:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0085_01D54795.BBB99AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've been processing millions of DMARC aggregate reports from a lot of different organizations, and have been trying to make sense of them for quite some time now. I've noticed that most of them, even those from large parties like Google and Yahoo!, fail to follow the DMARC RFC guidelines (Appendix C. DMARC XML Schema). I've written a blog about this that can be found here: https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/ The bottom line is that the RFC 7489 Appendix C is a mess and contradicts itself numerous times in both schema and comments. I think it's important to be clearer and stricter about the xml elements and their values. Too much of this section is open to interpretation. Some examples: The report has an element with the name "policy_published". This name would indicate that the elements within, contain the domain's published policy. The comments however, mention "applied" and "apply". Most organizations that send aggregate reports do not send failure reports and thus do not "apply" the "fo" (Failure reporting options) element. This is why parties like Google leave this element out of their reports. This particular element's comment ("failure reporting options in effect") also implies that it is optional. On the other hand, this element has a default "minOccurs" value of 1, so it should not be omitted. It should also be clearer about what to do with policy elements that are unspecified in the domain's DNS record. I think it is best to fill these elements in the report with their respected default values. So when 'pct' is not specified in the domain's policy, the report should state '100'. When 'sp' is not specified it should have the value of the 'p' element. I've also noticed that most parties do not specify the PolicyOverrideType, even when both SPF and DKIM alignment fails. So this element should be made mandatory whenever alignment fails and the disposition doesn't follow the domain's DMARC policy. The RFC guidelines for aggregate reports should also state that empty elements with a minOccurs of 0 should be omitted and not be left blank. It should also be specified that if a message is not signed with DKIM the 'DKIMAuthResultType' should be omitted. And thus the 'DKIMResultType' 'none' would never be used. Because when a message has no signatures, then it also doesn't have a specified 'domain' (d=) (minOccurs 1) and 'selector' (s=) (minOccurs 0). What happens now is that some organizations report non-signed messages with the 'dkim' element and fill the 'domain' and 'selector' with a bogus 'none' value. There are also multiple mentions of MinOccurs="1", even though the document specifies that unless otherwise specified in the schema, the minOccurs and maxOccurs values for each element are set to 1. This adds to the confusion. DMARC reporting capabilities are a valuable aspect of the DMARC mechanism. It can help domain owners in setting up and hardening their DKIM/SPF/DMARC policy. But unless these reports follow strict guidelines they just pile up to a lot of inconsistent data open to interpretation and guesswork. Domain owners should be able to understand the data without the need for a spiritual voodoo DMARC guru (trademark pending) to make sense of it all. Kind regards, Freddie Leeman ------=_NextPart_000_0085_01D54795.BBB99AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been processing millions = of DMARC aggregate reports from a lot of different organizations, and = have been trying to make sense of them for quite some time now. = I’ve noticed that most of them, even those from large parties like = Google and Yahoo!, fail to follow the DMARC RFC guidelines (Appendix = C.  DMARC XML Schema). I’ve written a blog about this that = can be found here: https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

 

The bottom line is that the RFC 7489 Appendix C is a mess = and contradicts itself numerous times in both schema and comments. I = think it’s important to be clearer and stricter about the xml = elements and their values. Too much of this section is open to = interpretation.

 

Some examples:

 

The report has an element with the = name "policy_published". This name would indicate that the = elements within, contain the domain's published policy. The comments = however, mention "applied” and “apply”. Most = organizations that send aggregate reports do not send failure reports = and thus do not "apply" the "fo" (Failure reporting = options) element. This is why parties like Google leave this element out = of their reports. This particular element's comment ("failure = reporting options in effect") also implies that it is optional. On = the other hand, this element has a default "minOccurs" value = of 1, so it should not be omitted.

 

It should also be clearer about = what to do with policy elements that are unspecified in the = domain’s DNS record. I think it is best to fill these elements in = the report with their respected default values. So when = ‘pct’ is not specified in the domain’s policy, the = report should state ‘100’. When ‘sp’ is not = specified it should have the value of the ‘p’ = element.

 

I’ve also noticed that most parties do not specify = the PolicyOverrideType, even when both SPF and DKIM alignment fails. So = this element should be made mandatory whenever alignment fails and the = disposition doesn’t follow the domain’s DMARC = policy.

 

The RFC guidelines for aggregate reports should also state = that empty elements with a minOccurs of 0 should be omitted and not be = left blank.

 

It should also be specified that if a message is not signed = with DKIM the ‘DKIMAuthResultType’ should be omitted. And = thus the ‘DKIMResultType’ ‘none’ would never be = used. Because when a message has no signatures, then it also = doesn’t have a specified ‘domain’ (d=3D) (minOccurs 1) = and ‘selector’ (s=3D) (minOccurs 0). What happens now is = that some organizations report non-signed messages with the = ‘dkim’ element and fill the ‘domain’ and = ‘selector’ with a bogus ‘none’ = value.

 

There are also multiple mentions of = MinOccurs=3D”1”, even though the document specifies that = unless otherwise specified in the schema, the minOccurs and maxOccurs = values for each element are set to 1. This adds to the = confusion.

 

DMARC reporting capabilities are a valuable aspect of the = DMARC mechanism. It can help domain owners in setting up and hardening = their DKIM/SPF/DMARC policy. But unless these reports follow strict = guidelines they just pile up to a lot of inconsistent data open to = interpretation and guesswork. Domain owners should be able to understand = the data without the need for a spiritual voodoo DMARC guru (trademark = pending) to make sense of it all.

 

Kind = regards,

Freddie Leeman

------=_NextPart_000_0085_01D54795.BBB99AA0-- From nobody Wed Jul 31 03:46:35 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 6C1741200CD for ; Wed, 31 Jul 2019 03:46:34 -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=IjXjonN5; dkim=pass (2048-bit key) header.d=kitterman.com header.b=O6+4jwNE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsE8WMnWQqIk for ; Wed, 31 Jul 2019 03:46:32 -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 BCF4C1200F6 for ; Wed, 31 Jul 2019 03:46:32 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id BE339F805F8; Wed, 31 Jul 2019 06:46:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564569961; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=qSMdl3UWAGecUUgJinYhGv01az15MmHx7AmnBUGqI0g=; b=IjXjonN5xtf6yxIdP3p78BGAVZTIitvjMDP27o+iJoMcZB7NMD/0n25t 3A7Lp05fECZ2Fx4MDP9tKsw+fEKrCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564569961; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=qSMdl3UWAGecUUgJinYhGv01az15MmHx7AmnBUGqI0g=; b=O6+4jwNEGt2Y9Va5lGOGzxDQFZQHrotKmbSZ8VqCiLnyTRUpptHntyEa pJYPEpgk1wExchVOlHsdirQHhSAbIdicEdESQMFXFe9y4nvkNQ24pwUALQ siiRTTk3bWggDD7d1bhQDanYzXkEALnhfVY0u4jmJKrE2jcJCcAFxOsWXt OyZHDYkVgMmcHVeVS072lH2oIibOd5ROA8v64EgKZz8kpLwfNu15MvzDTt 7DDNuz+4hCrsVqaQquUy9zHCWpZhhkkTMWNfvhwtzgW+yd+6DsKijTr0CL iuWq3VsePxqJbnAeq9ypxPpS2uIbMu3EqeO2b4Gz0TATBP4RIzqUSg== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 87DBAF80208; Wed, 31 Jul 2019 06:46:01 -0400 (EDT) Date: Wed, 31 Jul 2019 10:46:00 +0000 In-Reply-To: References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 31 Jul 2019 10:46:34 -0000 On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely wrote= : >On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote: > >> The published policy (that's why I suggest dmarc=2Epolicy)=2E > > >Published policy can be ambiguous=2E Say you have p=3Dquarantine; sp=3Dn= one=2E > The >MTA chooses which to apply based on the domains (publishing and From:)=2E > So it >makes sense to write the /applied/ published policy=2E > >I'm not good at designing A-R stanzas, as you know=2E However, since >dmarc is >already the policy method, why not write dns=2Epolicy, since that is >where it >comes from? The problem with dns as a ptype is that virtually all this is from DNS=2E = I haven't had a chance to study your proposal in detail or coordinate with= the other designated experts, but speaking for myself my initial thought i= s that dns is not a good ptype name=2E This is specific to DMARC, so I think it's appropriate to say so=2E >> I'm not sure if disposition belongs in A-R=2E If it does, it'd be a >local >> policy override, probably policy=2Edmarc as described now in RFC 8616= =2E > >You mean RFC 7489, don't you? I see nothing about A-R in RFC 8616=2E Sorry=2E I meant RFC 8601=2E >Would it be possible to add a result of "quarantine"? Having >dmarc=3Dfail and >dns=2Epolicy=3Dquarantine leaves a good deal of interpretation to the MDA= =2E=20 >If one >could write dmarc=3Dquarantine, a simple string search or regular >expression >would do=2E That's a great example of why dns=2Epolicy=3D isn't the way to go=2E It's= too generic=2E If it's dmarc=2Epolicy=3Dquarantine, there's no ambiguity= =2E You can't put quarantine as the DMARC result, because that's not what = it is=2E The DMARC result is pass/fail/none=2E >Currently, I use a comment too=2E > >Since we're at it, besides the spam folder, is it fine if the MDA sets >IMAP >keyword $Junk[*] or $Phishing[=E2=80=A0] or would we dare registering a n= ew >one? It's outside my area of expertise, so I don't have a strong opinion, but I= 'd be inclined not to register a new one=2E I think the average user can b= e confused by too many terms for things that to them are the same=2E Scott K From nobody Wed Jul 31 05:31:07 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 9B16A120275 for ; Wed, 31 Jul 2019 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=xQShdXpi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ARmON5B1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1n9hQsfktms for ; Wed, 31 Jul 2019 05:30:52 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F54A120247 for ; Wed, 31 Jul 2019 05:30:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EFB002240F for ; Wed, 31 Jul 2019 08:30:50 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Wed, 31 Jul 2019 08:30:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=N+mucvINx96kdFHiXH+cs7ro5uqm0kv nLmZjZTcQHdE=; b=xQShdXpiBSYHR7psm5fWyVt59jKqfJShpR1IJ9Llvad2wJx vNwj5aRS7Aw1105/pIoOKey/sqqJ9qjaQUJbpWiFHZ30XZJXHcPx8PAths0hUt1I pwom2yCN/8h3T+SKT6Tk0zcPeFQE45GyqbelKKclTdRhKJlWGEt6UWInBUFkgYaF 2X9Vr7LPNk1rpSy2/jH5jikh+s2lBD4lKV9JQXyVwOfFV4Y1RvBR1doXwitRnI3Z JtxiiVExTv9EOnbTHEGQYwhX/lu81XvBoYTdSkuYeDjOGx9s706WAdVFWoSQSrgg Kd4VJlht2Zs/GW/lVw4n2XQVGb4YWw/gJAowJ5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=N+mucv INx96kdFHiXH+cs7ro5uqm0kvnLmZjZTcQHdE=; b=ARmON5B1XQUTafIdZOenmU 1E/gUBEgsQcDEh2Ys4daTVqs0/tkzv4Y+qCz0aj3mGzEXeKYOY8kxlVjOU8VY2iX 3E0QkOXt6tJzIG18KxfXgik8nTPk+ZONIH/g5NvaN1QB1lbu2UBpzcXS8yYNQ178 1Oi4oOH9dier2E5dTQ5jjFZYfcl6WqbatYJ1lbsjKfoCTTLgDzr2KGNxr85Dfm2z q1PS//5g6rvEMs1Likz/9AQ6oTcMDBwSu9MlfF2WhQO3NBpH9ioRpnLbgw/FwSDC GmuAVqW5oe1rmi/t1BsRIvK4ANcocvVb8B9BK6RX8A+dV5rXkoSmJXFor9L7sDsg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrleehgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfuthgrnhcumfgrlhhishgthhdfuceoshhtrghnsehglhih phhhvghinhdrmhgrihhlfhhorhgtvgdrnhgvtheqnecuffhomhgrihhnpehivghtfhdroh hrghenucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgr ihhlfhhorhgtvgdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 601F41400EE; Wed, 31 Jul 2019 08:30:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-799-g925e343-fmstable-20190729v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> Date: Wed, 31 Jul 2019 08:30:25 -0400 From: "Stan Kalisch" To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=a03e49a802fd4f0a859487b1bbba4cfe Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 31 Jul 2019 12:31:06 -0000 --a03e49a802fd4f0a859487b1bbba4cfe Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019, at 6:46 AM, Scott Kitterman wrote: > On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely wr= ote: > >On Tue 30/Jul/2019 15:56:16 +0200 Scott Kitterman wrote: > > > >> The published policy (that's why I suggest dmarc.policy). > > > > > >Published policy can be ambiguous. Say you have p=3Dquarantine; sp=3D= none. > > The > >MTA chooses which to apply based on the domains (publishing and From:= ). > > So it > >makes sense to write the /applied/ published policy. > > > >I'm not good at designing A-R stanzas, as you know. However, since > >dmarc is > >already the policy method, why not write dns.policy, since that is > >where it > >comes from? >=20 > The problem with dns as a ptype is that virtually all this is from DNS= . I haven't had a chance to study your proposal in detail or coordinate = with the other designated experts, but speaking for myself my initial th= ought is that dns is not a good ptype name. Moreover, given the D in DMARC literally means "Domain-Based", I think t= his nomenclature would be potentially confusing and unfortunate. > This is specific to DMARC, so I think it's appropriate to say so. There is that too. Stan > >> I'm not sure if disposition belongs in A-R. If it does, it'd be a > >local > >> policy override, probably policy.dmarc as described now in RFC 8616= . > > > >You mean RFC 7489, don't you? I see nothing about A-R in RFC 8616. >=20 > Sorry. I meant RFC 8601. >=20 > >Would it be possible to add a result of "quarantine"? Having > >dmarc=3Dfail and > >dns.policy=3Dquarantine leaves a good deal of interpretation to the M= DA.=20 > >If one > >could write dmarc=3Dquarantine, a simple string search or regular > >expression > >would do. >=20 > That's a great example of why dns.policy=3D isn't the way to go. It's = too generic. If it's dmarc.policy=3Dquarantine, there's no ambiguity. Yo= u can't put quarantine as the DMARC result, because that's not what it i= s. The DMARC result is pass/fail/none. >=20 > >Currently, I use a comment too. > > > >Since we're at it, besides the spam folder, is it fine if the MDA set= s > >IMAP > >keyword $Junk[*] or $Phishing[=E2=80=A0] or would we dare registering= a new > >one? >=20 > It's outside my area of expertise, so I don't have a strong opinion, b= ut I'd be inclined not to register a new one. I think the average user c= an be confused by too many terms for things that to them are the same. >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 --a03e49a802fd4f0a859487b1bbba4cfe Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019, at 6:46 AM, Scott Kitterman wrote:
On July 31, 2019 7:11:49 AM UTC, Alessandro Vesely <vesely@tana= .it> wrote:
>On Tue 30/= Jul/2019 15:56:16 +0200 Scott Kitterman wrote:
>
>&g= t; The published policy (that's why I suggest dmarc.policy).
>
>
>Published po= licy can be ambiguous.  Say you have p=3Dquarantine; sp=3Dnone.
=
> The
>MTA chooses which to apply based on the domains = (publishing and From:).
> = So it
>makes sense to writ= e the /applied/ published policy.
>
>I'm not good at= designing A-R stanzas, as you know.  However, since
>dmarc is
>already the policy method, why not write dns.policy, si= nce that is
>where it
<= /div>
>comes from?

Th= e problem with dns as a ptype is that virtually all this is from DNS.&nb= sp; I haven't had a chance to study your proposal in detail or coordinat= e with the other designated experts, but speaking for myself my initial = thought is that dns is not a good ptype name.

Moreover, given the D in DMARC literally means "Domain-Based", I think= this nomenclature would be potentially confusing and unfortunate.

This is specific to DMARC,= so I think it's appropriate to say so.

Ther= e is that too.


Stan

>> I'm not s= ure if disposition belongs in A-R.  If it does, it'd be a
=
>local
>> policy override, probably policy.dmarc as descri= bed now in RFC 8616.
>
=
>You mean RFC 7489, don't you= ?  I see nothing about A-R in RFC 8616.

Sorry. = I meant RFC 8601.

=
>Would it be possible to add a resu= lt of "quarantine"?  Having
>dmarc=3Dfail and
>= dns.policy=3Dquarantine leaves a good deal of interpretation to the MDA.=  
>If one
>could write dmarc=3Dquarantine, a si= mple string search or regular
>expression
>would do.=

That's a great example of why dns.policy=3D isn't the wa= y to go.  It's too generic.  If it's dmarc.policy=3Dquarantine= , there's no ambiguity.  You can't put quarantine as the DMARC resu= lt, because that's not what it is.  The DMARC result is pass/fail/n= one.

>Currently, I use a comment too.
>
>Since we're at it, besides the spam folder, is it fine if the MDA= sets
>IMAP
>keyword $Junk[*] or $Phishing[=E2=80=A0= ] or would we dare registering a new
>one?

It's outside my area of expertise, so I = don't have a strong opinion, but I'd be inclined not to register a new o= ne.  I think the average user can be confused by too many terms for= things that to them are the same.

Scott K

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


=
--a03e49a802fd4f0a859487b1bbba4cfe-- From nobody Wed Jul 31 07:58:25 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 A8AA312004F for ; Wed, 31 Jul 2019 07:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tb23NifMfap for ; Wed, 31 Jul 2019 07:58:20 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 6C221120170 for ; Wed, 31 Jul 2019 07:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N9/BNmAv86ZBQxDGc+4QpnzibJu9HsvIu1oXnJLHhiE=; b=RZRei6r2hcQt603YYVX2btg/+4 SVTp2KKxmi39QHJ7RxRF09l05l1mPfUyoQuNobxazXlWruDuhACK+qhlwP56rd+JT/P3Rvn7P95Vp ChljkSgPCcRcUyLjVh5I6mAql31j2A2Ap6tJe+TKx92wiWyGyRTwy1S0lW5L+v3K4E23b23WbEKZa buErlCA9zbfWixnD9W9yY2sKrthlkz3GAX5eccYrO+xiVT0f1o+G6RFZq4dQ4cQIY4ZykCZx0BQF8 dsv3v6xf1icsAA2tVEJjUd+4jcqXLEtuj2qQbMsY4+nw78j27Vn/lo0FTtbz9L6f1NLJ/w63eiXA5 /Ez3T+Qg==; Received: from 83-83-140-171.cable.dynamic.v4.ziggo.nl ([83.83.140.171] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hsq3W-0005xm-1Q for dmarc@ietf.org; Wed, 31 Jul 2019 16:58:18 +0200 From: "Freddie Leeman" To: Date: Wed, 31 Jul 2019 16:58:18 +0200 Message-ID: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01D547C1.27454910" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVHqrg4GLMYKDGbSvOvMop+gTZZAQ== Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 31 Jul 2019 14:58:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0101_01D547C1.27454910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Would it be useful to add an 'ao' tag name for aggregate reporting options? Something like: ao: Aggregate reporting options (plain-text; OPTIONAL; default is "0"). Provides requested options for generation of aggregate reports. This tag's content MUST be ignored if a "rua" tag is not specified. The value of this tag is a colon-separated list of characters that indicate aggregate reporting options as follows: 0: Generate a DMARC aggregate report for every message, regardless of its alignment. 1: Generate a DMARC aggregate report if any underlying authentication mechanism produced something other than an aligned "pass" result. d: Generate a DMARC aggregate report if the message had a signature that failed evaluation, regardless of its alignment. s: Generate a DMARC aggregate report if the message failed SPF evaluation, regardless of its alignment. This would allow domain owners to save on tons of reports to be handled and processing that are useless in most scenarios. For instance, when I've deployed my SPF/DKIM/DMARC policy and I'm pleased with my policie's results, I would still want to use the reporting to detect and fix changes in my email environment. If a million mails a day are nicely processed with DKIM and SPF aligned, I do not need those entries in my aggregate reports. I'm only interested in the reports where either DKIM or SPF fails. In most scenario's this will cut data transfer and report processing with more than 99 percent. Whenever there is a bump in the number of reports received, I can detect that something is wrong and I might need to add a host to my SPF policy or need to fix my DKIM signing. I was amazed that these options weren't in the current RFC, as these do exist for failure reports. Am I missing something? Is there a reason why this would be a bad idea? Kind regards, Freddie ------=_NextPart_000_0101_01D547C1.27454910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would it be useful to add an = ‘ao’ tag name for aggregate reporting options? Something = like:

 

ao:         = Aggregate reporting options (plain-text; OPTIONAL; default is = "0").

Provides requested options for generation of aggregate = reports. This tag's content MUST be ignored if a "rua" tag is = not specified. The value of this tag is a colon-separated list of = characters that indicate aggregate reporting options as = follows:

 

0: Generate a DMARC aggregate report for every message, = regardless of its alignment.

1: Generate a DMARC aggregate = report if any underlying authentication mechanism produced something = other than an aligned "pass" result.

d: Generate a DMARC aggregate = report if the message had a signature that failed evaluation, regardless = of its alignment.

s: Generate a DMARC aggregate report if the message failed = SPF evaluation, regardless of its alignment.

 

This would allow domain owners to = save on tons of reports to be handled and processing that are useless in = most scenarios. For instance, when I’ve deployed my SPF/DKIM/DMARC = policy and I’m pleased with my policie’s results, I would = still want to use the reporting to detect and fix changes in my email = environment. If a million mails a day are nicely processed with DKIM and = SPF aligned, I do not need those entries in my aggregate reports. = I’m only interested in the reports where either DKIM or SPF fails. = In most scenario’s this will cut data transfer and report = processing with more than 99 percent. Whenever there is a bump in the = number of reports received, I can detect that something is wrong and I = might need to add a host to my SPF policy or need to fix my DKIM = signing.

 

I was amazed that these options weren’t in the = current RFC, as these do exist for failure reports. Am I missing = something? Is there a reason why this would be a bad = idea?

 

Kind regards,

Freddie

------=_NextPart_000_0101_01D547C1.27454910-- From nobody Wed Jul 31 08:00:34 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 162FA12004F for ; Wed, 31 Jul 2019 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_eSfuGTGE1U for ; Wed, 31 Jul 2019 08:00:31 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 DF0B112006D for ; Wed, 31 Jul 2019 08:00:30 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id j6so17143272ioa.5 for ; Wed, 31 Jul 2019 08:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h+KIMHwOYb7tC2EvUHbdkl1+nHGCS5GwA3wrrKDOTzg=; b=VyG0mO6PBD8yDHXW0pz8ky4iZs1vEIeORoFIt/GIBkdSjyu7xZ4m7XBThrqG3oyekS uXSSZBTxgwlegsN4WKIOuKptxHR/zY8WAguzoKFfxl+LaXjwnW8SSFI7hDNvPTRfb4rD 0RbpZ6Gfq9d0IShJISWVP3/bNlrjWXl4c+IQs= 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=h+KIMHwOYb7tC2EvUHbdkl1+nHGCS5GwA3wrrKDOTzg=; b=eoPrObbSWtUOzLX8BX7xU09NRmyUnRNQx3HtpuDwJK021h89wRw2zIEc7qja0JkqZi ++YD3IemX1hbxOPC6GReG65JRtEhYNvAVJP91fbjiqC/6IdWfB4Oix9ArUN9qqIjdAMq HOIqYWyyAzuC8RaED9erUrOxzimTr4UGDa3OgSb3t8z3rE033BH9mOi1iWyXMlJ1sLq7 q+isIX11S3wHcpkpO6wjIJ5E5JJjDtssGmPFl1iMaYqn+UAGKczBAadhcINpkHyJn+bg gtl0wQzznJC9a1nPpk7pAm4fURjk1GFcVzcAEV7ge4xU/N7QefcII9J5Ns7facN0vPzz ErQQ== X-Gm-Message-State: APjAAAUD/2hhWZfHlXSEmGTl8UDQP7f3EKe5x0+UqAtfwVi8Kej/37zA t/SlU70t9D3/hJYT8TPccJF7HxCzhLur/CiRW3Y= X-Google-Smtp-Source: APXvYqyhN59c3+ewJQtJtduSos/DAWkj9zrifznqZ7TiIFk0y0EiP7e9R+6vLPy8IzUMKVTaSDA9Pwny8L7bgDoT/Rs= X-Received: by 2002:a6b:f607:: with SMTP id n7mr76852104ioh.263.1564585229953; Wed, 31 Jul 2019 08:00:29 -0700 (PDT) MIME-Version: 1.0 References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> In-Reply-To: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> From: "Kurt Andersen (b)" Date: Wed, 31 Jul 2019 08:00:17 -0700 Message-ID: To: Freddie Leeman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000da44d2058efb62fa" Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 31 Jul 2019 15:00:33 -0000 --000000000000da44d2058efb62fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman wrote: > I=E2=80=99ve been processing millions of DMARC aggregate reports from a l= ot of > different organizations, and have been trying to make sense of them for > quite some time now. I=E2=80=99ve noticed that most of them, even those f= rom large > parties like Google and Yahoo!, fail to follow the DMARC RFC guidelines > (Appendix C. DMARC XML Schema). I=E2=80=99ve written a blog about this t= hat can be > found here: > https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/ > > > > The bottom line is that the RFC 7489 Appendix C is a mess and contradicts > itself numerous times in both schema and comments. I think it=E2=80=99s i= mportant > to be clearer and stricter about the xml elements and their values. Too > much of this section is open to interpretation. > Freddie, Thanks for your observations - would you mind proposing concrete language to replace Appendix C? Speaking from experience, it can be helpful to be able to do in-place comments/markup so I've posted http://bit.ly/dmarc-rpt-schema - please make any adjustments in "Suggest" mode or comments you feel appropriate. The invitation extends to all members of this group. --Kurt Andersen --000000000000da44d2058efb62fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019 at 2:47 AM Freddie L= eeman <freddie=3D40l= eemankuiper.nl@dmarc.ietf.org> wrote:

I=E2=80=99ve been processing millions of DMARC aggre= gate reports from a lot of different organizations, and have been trying to= make sense of them for quite some time now. I=E2=80=99ve noticed that most= of them, even those from large parties like Google and Yahoo!, fail to fol= low the DMARC RFC guidelines (Appendix C.=C2=A0 DMARC XML Schema). I=E2=80= =99ve written a blog about this that can be found here: https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

=C2= =A0

The bottom= line is that the RFC 7489 Appendix C is a mess and contradicts itself nume= rous times in both schema and comments. I think it=E2=80=99s important to b= e clearer and stricter about the xml elements and their values. Too much of= this section is open to interpretation.


Freddie,

Thanks for your obse= rvations - would you mind proposing concrete language to replace Appendix C= ? Speaking from experience, it can be helpful to be able to do in-place com= ments/markup so I've posted=C2=A0http://bit.ly/dmarc-rpt-schema - please make any adjustments in &q= uot;Suggest" mode or comments you feel appropriate. The invitation ext= ends to all members of this group.=C2=A0

--Kurt An= dersen=C2=A0
--000000000000da44d2058efb62fa-- From nobody Wed Jul 31 08:06:21 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 69B0F1200D7 for ; Wed, 31 Jul 2019 08:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14hBVW0wZb1t for ; Wed, 31 Jul 2019 08:06:17 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 4D7D312004F for ; Wed, 31 Jul 2019 08:06:17 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id o9so33387975iom.3 for ; Wed, 31 Jul 2019 08:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LrTJ7RNuHTVj40eNd8DrjWVLlUtbm1g7I0F496pvTOs=; b=GiDkCl0quCZBaBLAoMpg24DA0PlyZ9eoUFLHLATnu2HiiB4ocmpfmu75vCwZZXNPhZ BzCljK2UKDfBWqDvhMxSbI8UX650ZuE2cIzhRxOstD/U9c/37QrFp/fY4JDmUv13BCZZ g3KbMe7SW5z/pS4HBXxM5TsFmIeq6Ax5F7GGI= 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=LrTJ7RNuHTVj40eNd8DrjWVLlUtbm1g7I0F496pvTOs=; b=BqKblsBph6DwAA/nFVGaHSxwGrjXJfMg+N/vjIwSlPuf/jGoHxZqHhO5TMq0yGdhrF XbBbjNo/2l3dKvHT8qp9E7BFggM1n8OGKErMNDuEm2LViyhJX78Ro3S9gyQ3twqHexKE DtVDUkf2JbepIBOz6Z/cCPudRQIFvsLhlqJckjavCjlZIa01rxsE6LKE/qwfqFDU610p h0UAw1WkQroqQdK2iuwoi2hHCGvPeb4l88KKm6gx8hc8jwRJs4QzI+sG91uimmeNjRTs wLfq7c5ObFwpDL2p+Zuk1CdGp8HgDN3RDGExu8lQCD1E8DLifTr6jzwvmenIw5sAoN/c EKCA== X-Gm-Message-State: APjAAAV0d9EqjQnLzeQuY3gKi8uAivMj8vCeFPnUPcf/425xQCLDtWtj uOT7hg5/5TucZbXxn2VPUscjiH9NTWHIyPgjyFFS8r6E X-Google-Smtp-Source: APXvYqxQk1sDPx1Ko1nur1VF7NaVJHNliwGqJtls9N4w51UhzKMvbS3ZQQJXzZAKf6J2TPb6FLcejdQLlMQIfrCQCtM= X-Received: by 2002:a6b:5b01:: with SMTP id v1mr7944226ioh.120.1564585576364; Wed, 31 Jul 2019 08:06:16 -0700 (PDT) MIME-Version: 1.0 References: <2577720.3ZthdXZjm2@l5580> <4600949.rz9u5RyGOV@l5580> <60001A26-503E-4DB0-B164-2AADD47CFE06@kitterman.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Wed, 31 Jul 2019 08:06:03 -0700 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000801899058efb778d" Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields 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, 31 Jul 2019 15:06:20 -0000 --000000000000801899058efb778d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019 at 12:12 AM Alessandro Vesely wrote: > > Since we're at it, besides the spam folder, is it fine if the MDA sets IM= AP > keyword $Junk[*] or $Phishing[=E2=80=A0] or would we dare registering a n= ew one? > I think that's part of the discussion in the JMAP/EXTRA WGs. --Kurt --000000000000801899058efb778d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019 at 12:12 AM Alessand= ro Vesely <vesely@tana.it> wrot= e:

Since we're at it, besides the spam folder, is it fine if the MDA sets = IMAP
keyword $Junk[*] or $Phishing[=E2=80=A0] or would we dare registering a new= one?

I think that's part of the di= scussion in the JMAP/EXTRA WGs.

--Kurt=C2=A0
=
--000000000000801899058efb778d-- From nobody Wed Jul 31 08:29: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 2A20C1201E3 for ; Wed, 31 Jul 2019 08:29:47 -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, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CylcHGTMF4LI for ; Wed, 31 Jul 2019 08:29:44 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 BA1D51202F5 for ; Wed, 31 Jul 2019 08:29:39 -0700 (PDT) Authentication-Results: mail.aegee.org/x6VFTYPP031006; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564586977; i=dkim+MSA-tls@aegee.org; r=y; bh=WIudU7nCe1rR4HIrv9BVF7453KW8lXEcTlIpnXp8MUc=; h=Date:In-Reply-To:References:Subject:To:From; b=CMHppFFbaEI7+fSSRK0C+HZ5P0wwIBFVIjlgb1vVznYZd1zivHRloup9Qc/Mj4i6+ VKJoMe3wa81/aceoTTkAGIax2gNBiMQ1EIjmAg/Ll66Kq3CpFkR7KmK4K6rvl2o5X6 ZJhqFAj7EX/b9cR2wmV3cMHvdWcsXxlD1zb22rT0uGGZtFmPinrihE5HoC5tLkQuEV TDjtq7k3xeWxlEN/naaltGQCN17oNkqedfGppNcOD9Vyugv+n751TK5qcKhXIAFsg8 gu2cgNdNdvuyWh9dyfDdbnCFBgO8O8DRn3easVmqREmO3vVFfMOxNZLd5WetHigI5p T74iQ3Jq638+H2KI19vYihf7KO/ZMYz/CVoAg2+2XOf/MIiPxWzsAK2deqsbfBMOyD S7iVvwTiWn7MMjAhBenUdPO1Eyq33J5OGK/TM2d0TEiqCpLi1q3YAp6YjiNmvY78Aq qOXkx9amrdlahgCcxnaNMIPMofn05y++gsOyBoLhznV0i2laEnRKzMxJ6P8wio/Lha O1ZSBUboi0MKLsS7nEYqj1dKgtGf5gA7DkefBTAXR8GDe5kK3CfklOVLwMRsdp+Wix tb1vfQM51n+0J/nn4Yt1Wd+xCc9mDTUITBRWVpUzw1OAcTuEj7YZn1vsorGMvmkE8G 0cr9e6SM7w/+3IxX1Gp6EKh8= Authentication-Results: mail.aegee.org/x6VFTYPP031006; dkim=none Received: from [10.43.253.208] (208.121.113.82.net.de.o2.com [82.113.121.208]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6VFTYPP031006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 31 Jul 2019 15:29:36 GMT Date: Wed, 31 Jul 2019 18:29:28 +0300 User-Agent: K-9 Mail for Android In-Reply-To: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WZW52Z90RIN7X7ZVCFWPH93C3Q7FYB" Content-Transfer-Encoding: 7bit To: dmarc@ietf.org From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Message-ID: X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 31 Jul 2019 15:29:47 -0000 ------WZW52Z90RIN7X7ZVCFWPH93C3Q7FYB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Freddie, if a message has 5 DKIM-Signatures, some of them fail DKIM validation and = some of them do not align, irrespective of validation status, you want to r= eceive a report for the failed DKIM signatures=2E The proposed option d is= in the DKIM domain=2E DMARC without alignment is DKIM or SPF=2E To get a= report for failed DKIM signature you put in the DKIM-Signature header r=3D= y=2E After the mail passes over a mailing list, the signature is invalidate= d and you get a useless report=2E Your intension is to limit the amount of= useless reports, but this particular option goes in the opposite direction= =2E If you remove the SPF records and ensure that each leaving message is sign= ed, you do not need the ao=3D1 option, as each report on failure will be ab= out DKIM=2E With ao=3Ds whenever a mail is sent to an alias and redirected to another = server, you will get a useless report=2E I am not exactly sure, but I thin= k SPF contained some reporting mechanisms, so this option might duplicate t= hem=2E Perhaps you want to propose a mechanism, that hides the successful deliver= ies (useless report) and only reports problematic cases? Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman wrote: >Would it be useful to add an 'ao' tag name for aggregate reporting >options? >Something like: > >=20 > >ao: Aggregate reporting options (plain-text; OPTIONAL; default >is >"0")=2E=20 > >Provides requested options for generation of aggregate reports=2E This >tag's >content MUST be ignored if a "rua" tag is not specified=2E The value of >this >tag is a colon-separated list of characters that indicate aggregate >reporting options as follows: > >=20 > >0: Generate a DMARC aggregate report for every message, regardless of >its >alignment=2E > >1: Generate a DMARC aggregate report if any underlying authentication >mechanism produced something other than an aligned "pass" result=2E > >d: Generate a DMARC aggregate report if the message had a signature >that >failed evaluation, regardless of its alignment=2E=20 > >s: Generate a DMARC aggregate report if the message failed SPF >evaluation, >regardless of its alignment=2E > >=20 > >This would allow domain owners to save on tons of reports to be handled >and >processing that are useless in most scenarios=2E For instance, when I've >deployed my SPF/DKIM/DMARC policy and I'm pleased with my policie's >results, >I would still want to use the reporting to detect and fix changes in my >email environment=2E If a million mails a day are nicely processed with >DKIM >and SPF aligned, I do not need those entries in my aggregate reports=2E >I'm >only interested in the reports where either DKIM or SPF fails=2E In most >scenario's this will cut data transfer and report processing with more >than >99 percent=2E Whenever there is a bump in the number of reports received, >I >can detect that something is wrong and I might need to add a host to my >SPF >policy or need to fix my DKIM signing=2E > >=20 > >I was amazed that these options weren't in the current RFC, as these do >exist for failure reports=2E Am I missing something? Is there a reason >why >this would be a bad idea? > >=20 > >Kind regards, > >Freddie ------WZW52Z90RIN7X7ZVCFWPH93C3Q7FYB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Freddie,

if a message has 5 DKIM-Signature= s, some of them fail DKIM validation and some of them do not align, irrespe= ctive of validation status, you want to receive a report for the failed DKI= M signatures=2E The proposed option d is in the DKIM domain=2E DMARC with= out alignment is DKIM or SPF=2E To get a report for failed DKIM signature = you put in the DKIM-Signature header r=3Dy=2E After the mail passes over a = mailing list, the signature is invalidated and you get a useless report=2E = Your intension is to limit the amount of useless reports, but this particu= lar option goes in the opposite direction=2E

If you remove the SPF r= ecords and ensure that each leaving message is signed, you do not need the = ao=3D1 option, as each report on failure will be about DKIM=2E

With = ao=3Ds whenever a mail is sent to an alias and redirected to another server= , you will get a useless report=2E I am not exactly sure, but I think SPF = contained some reporting mechanisms, so this option might duplicate them=2E=

Perhaps you want to propose a mechanism, that hides the successful = deliveries (useless report) and only reports problematic cases?

Rega= rds
=D0=94=D0=B8=D0=BB=D1=8F=D0=BD


On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman <freddie=3D40le= emankuiper=2Enl@dmarc=2Eietf=2Eorg> wrote:

Wo= uld it be useful to add an =E2=80=98ao=E2=80=99 tag name for aggregate repo= rting options? Something like:

=  

ao:         Aggre= gate reporting options (plain-text; OPTIONAL; default is "0")=2E

Provides requested = options for generation of aggregate reports=2E This tag's content MUST be i= gnored if a "rua" tag is not specified=2E The value of this tag is a colon-= separated list of characters that indicate aggregate reporting options as f= ollows:

 

0: Ge= nerate a DMARC aggregate report for every message, regardless of its alignm= ent=2E

1: = Generate a DMARC aggregate report if any underlying authentication mechanis= m produced something other than an aligned "pass" result=2E

d: Generate a DMARC aggre= gate report if the message had a signature that failed evaluation, regardle= ss of its alignment=2E

s: Generate a DMARC aggregate report if the message failed SP= F evaluation, regardless of its alignment=2E

 

This would allow domain owners to save on = tons of reports to be handled and processing that are useless in most scena= rios=2E For instance, when I=E2=80=99ve deployed my SPF/DKIM/DMARC policy a= nd I=E2=80=99m pleased with my policie=E2=80=99s results, I would still wan= t to use the reporting to detect and fix changes in my email environment=2E= If a million mails a day are nicely processed with DKIM and SPF aligned, I= do not need those entries in my aggregate reports=2E I=E2=80=99m only inte= rested in the reports where either DKIM or SPF fails=2E In most scenario=E2= =80=99s this will cut data transfer and report processing with more than 99= percent=2E Whenever there is a bump in the number of reports received, I c= an detect that something is wrong and I might need to add a host to my SPF = policy or need to fix my DKIM signing=2E

 

I was amazed that these options weren=E2=80=99t= in the current RFC, as these do exist for failure reports=2E Am I missing = something? Is there a reason why this would be a bad idea?

 

Kind regards,

Freddie=

------WZW52Z90RIN7X7ZVCFWPH93C3Q7FYB-- From nobody Wed Jul 31 08:42:20 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 8EA21120297 for ; Wed, 31 Jul 2019 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo-acmH0mboC for ; Wed, 31 Jul 2019 08:42:14 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 37181120227 for ; Wed, 31 Jul 2019 08:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=C9RPYKL+UY1M+1VhcuFkFoGfkGepV84RQ8gvxRa/H6I=; b=KYO8IdOeEOSQ7OCdy8FCttuW2 pQNFnSixO7fHheE7ELu+ofkWQo2jJ+w5+InEZ96l5v8UhGv29hjWjX/hTe/bFfdyyLRToe0McWnUC bq8MF/yMGprHir8YV6kw5NNDH5frvdIxAFSN8lfMagbXhvqW2IirWBvYrIhXa57m98MiXFuWDacLT esqn0iqhMZdRiDwvzQ0p29pj93lWIwWJLQw+XCUFeLjI7dhdjaG5MUtE1kXr9troouEy3uU5P+169 CGpFa/Q6c0n4QUndjbFCT+XoeI6rYd29Y/FdmsaV9kQ++iaNj9mVMsEoVWr3CeCIl4zdrsfVC1Ahi +6wUTPNWA==; Received: from 83-83-140-171.cable.dynamic.v4.ziggo.nl ([83.83.140.171] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hsqk0-0006r3-2x for dmarc@ietf.org; Wed, 31 Jul 2019 17:42:12 +0200 From: "Freddie Leeman" To: References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> In-Reply-To: Date: Wed, 31 Jul 2019 17:42:12 +0200 Message-ID: <014c01d547b6$85c30c30$91492490$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01D547C7.494C9F80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEwMtDJj/TREh0OevgSswABly9FJAHSL2GIqCB13dA= Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies 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, 31 Jul 2019 15:42:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014D_01D547C7.494C9F80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Kurt, I=E2=80=99ve made the adjustments to the document. =20 --Freddie Leeman =20 Van: Kurt Andersen (b) [mailto:kboth@drkurt.com]=20 Verzonden: woensdag 31 juli 2019 17:00 Aan: Freddie Leeman CC: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] DMARC aggregate reports XML Schema = inconsistencies =20 On Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman = > wrote: I=E2=80=99ve been processing millions of DMARC aggregate reports from a = lot of different organizations, and have been trying to make sense of = them for quite some time now. I=E2=80=99ve noticed that most of them, = even those from large parties like Google and Yahoo!, fail to follow the = DMARC RFC guidelines (Appendix C. DMARC XML Schema). I=E2=80=99ve = written a blog about this that can be found here: = https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/ =20 The bottom line is that the RFC 7489 Appendix C is a mess and = contradicts itself numerous times in both schema and comments. I think = it=E2=80=99s important to be clearer and stricter about the xml elements = and their values. Too much of this section is open to interpretation. =20 Freddie, =20 Thanks for your observations - would you mind proposing concrete = language to replace Appendix C? Speaking from experience, it can be = helpful to be able to do in-place comments/markup so I've posted = http://bit.ly/dmarc-rpt-schema - please make any adjustments in = "Suggest" mode or comments you feel appropriate. The invitation extends = to all members of this group.=20 =20 --Kurt Andersen=20 ------=_NextPart_000_014D_01D547C7.494C9F80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Kurt, I=E2=80=99ve made the = adjustments to the document.

 

--Freddie Leeman

 

Van: = Kurt Andersen (b) [mailto:kboth@drkurt.com]
Verzonden: = woensdag 31 juli 2019 17:00
Aan: Freddie Leeman = <freddie@leemankuiper.nl>
CC: = dmarc@ietf.org
Onderwerp: Re: [dmarc-ietf] DMARC aggregate = reports XML Schema inconsistencies

 

On = Wed, Jul 31, 2019 at 2:47 AM Freddie Leeman <freddie=3D40leemankuiper.nl@dmarc.= ietf.org> wrote:

I=E2=80=99ve been processing millions of DMARC aggregate = reports from a lot of different organizations, and have been trying to = make sense of them for quite some time now. I=E2=80=99ve noticed that = most of them, even those from large parties like Google and Yahoo!, fail = to follow the DMARC RFC guidelines (Appendix C.  DMARC XML Schema). = I=E2=80=99ve written a blog about this that can be found here: https://www.uriports.com/blog/dmarc-reports-ietf-rfc-co= mpliance/

 

The bottom line is that the RFC 7489 Appendix C is a mess = and contradicts itself numerous times in both schema and comments. I = think it=E2=80=99s important to be clearer and stricter about the xml = elements and their values. Too much of this section is open to = interpretation.

 

Freddie,

 

Thanks for your observations - would you mind = proposing concrete language to replace Appendix C? Speaking from = experience, it can be helpful to be able to do in-place comments/markup = so I've posted http://bit.ly/dmarc-rpt-schema - please make any adjustments in "Suggest" mode or comments = you feel appropriate. The invitation extends to all members of this = group. 

------=_NextPart_000_014D_01D547C7.494C9F80-- From nobody Wed Jul 31 10:31:54 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 A733B12016F for ; Wed, 31 Jul 2019 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCvX7CoybY95 for ; Wed, 31 Jul 2019 10:31:49 -0700 (PDT) Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 9499C1204D1 for ; Wed, 31 Jul 2019 10:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vnWFqvHawW5tWmoK1HABzXhHR3WG4phCrTZud8OZnvA=; b=DuZgPRRY6VZl8cylhs6n3X/Po VpsqSvycNWXVFPIvENVlmcCqlDBktt/d6JiQgLbY8dzoLWvT6tuXoCznoJ/kkHG4iwcHp8wkA2XAA jTOzJHEaZ2gNTgv3To1tCvL4fPEAJy8JfBOIMOBembpUVEDHSs8LpLB9z37JJjFO11lAF+M4kCSW6 Tfbc4QEAAeiTaQmp7bB89d5wMjOtYxWDBa64JoTix1nUPtwECVCZFgVlu32Uz5t1luM4cqSX6IOKA bqGRzVEM+DvSFPkLAbuTL4IQ4EVKFPYFxH8EaP3taFWsFNJpNACOk22wPerk5Z2sYL02s3AF3tPDJ wRDTgW3eQ==; Received: from 83-83-140-171.cable.dynamic.v4.ziggo.nl ([83.83.140.171] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hssS3-0000NB-8R; Wed, 31 Jul 2019 19:31:47 +0200 From: "Freddie Leeman" To: =?UTF-8?B?J9CU0LjQu9GP0L0g0J/QsNC70LDRg9C30L7Qsic=?= , References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> In-Reply-To: Date: Wed, 31 Jul 2019 19:31:47 +0200 Message-ID: <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01D547D6.986DE510" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJIu0T9j5Gm574QYreI9/dffuh59gHbOLplpe833gA= Content-Language: nl X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Authenticated-Id: info@leemankuiper.nl Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 31 Jul 2019 17:31:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016F_01D547D6.986DE510 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD, =20 Thanks for your input and feedback. Maybe a single tag, that allows the = domain owner to avoid receiving aggregate reports for messages that = align, would be enough? I personally have little experience with mailing = lists which, I understand, can be a real pain when it comes to SPF/DKIM. = So would a tag that instructs the receiving party to only send an = aggregate report whenever the DMARC policies is applied be a better = option? =20 Kind regards, Freddie =20 Van: =D0=94=D0=B8=D0=BB=D1=8F=D0=BD = =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 = [mailto:dilyan.palauzov@aegee.org]=20 Verzonden: woensdag 31 juli 2019 17:29 Aan: dmarc@ietf.org Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' =20 Hello Freddie, if a message has 5 DKIM-Signatures, some of them fail DKIM validation = and some of them do not align, irrespective of validation status, you = want to receive a report for the failed DKIM signatures. The proposed = option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. = To get a report for failed DKIM signature you put in the DKIM-Signature = header r=3Dy. After the mail passes over a mailing list, the signature = is invalidated and you get a useless report. Your intension is to limit = the amount of useless reports, but this particular option goes in the = opposite direction. If you remove the SPF records and ensure that each leaving message is = signed, you do not need the ao=3D1 option, as each report on failure = will be about DKIM. With ao=3Ds whenever a mail is sent to an alias and redirected to = another server, you will get a useless report. I am not exactly sure, = but I think SPF contained some reporting mechanisms, so this option = might duplicate them. Perhaps you want to propose a mechanism, that hides the successful = deliveries (useless report) and only reports problematic cases? Regards =D0=94=D0=B8=D0=BB=D1=8F=D0=BD On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman = > wrote: Would it be useful to add an =E2=80=98ao=E2=80=99 tag name for aggregate = reporting options? Something like: =20 ao: Aggregate reporting options (plain-text; OPTIONAL; default = is "0").=20 Provides requested options for generation of aggregate reports. This = tag's content MUST be ignored if a "rua" tag is not specified. The value = of this tag is a colon-separated list of characters that indicate = aggregate reporting options as follows: =20 0: Generate a DMARC aggregate report for every message, regardless of = its alignment. 1: Generate a DMARC aggregate report if any underlying authentication = mechanism produced something other than an aligned "pass" result. d: Generate a DMARC aggregate report if the message had a signature that = failed evaluation, regardless of its alignment.=20 s: Generate a DMARC aggregate report if the message failed SPF = evaluation, regardless of its alignment. =20 This would allow domain owners to save on tons of reports to be handled = and processing that are useless in most scenarios. For instance, when = I=E2=80=99ve deployed my SPF/DKIM/DMARC policy and I=E2=80=99m pleased = with my policie=E2=80=99s results, I would still want to use the = reporting to detect and fix changes in my email environment. If a = million mails a day are nicely processed with DKIM and SPF aligned, I do = not need those entries in my aggregate reports. I=E2=80=99m only = interested in the reports where either DKIM or SPF fails. In most = scenario=E2=80=99s this will cut data transfer and report processing = with more than 99 percent. Whenever there is a bump in the number of = reports received, I can detect that something is wrong and I might need = to add a host to my SPF policy or need to fix my DKIM signing. =20 I was amazed that these options weren=E2=80=99t in the current RFC, as = these do exist for failure reports. Am I missing something? Is there a = reason why this would be a bad idea? =20 Kind regards, Freddie ------=_NextPart_000_016F_01D547D6.986DE510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = =D0=94=D0=B8=D0=BB=D1=8F=D0=BD,

 

Thanks for = your input and feedback. Maybe a single tag, that allows the domain = owner to avoid receiving aggregate reports for messages that align, = would be enough? I personally have little experience with mailing lists = which, I understand, can be a real pain when it comes to SPF/DKIM. So = would a tag that instructs the receiving party to only send an aggregate = report whenever the DMARC policies is applied be a better = option?

 

Kind = regards,
Freddie

 

Van: =D0=94=D0=B8=D0=BB=D1=8F=D0=BD = =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 = [mailto:dilyan.palauzov@aegee.org]
Verzonden: woensdag 31 = juli 2019 17:29
Aan: dmarc@ietf.org
Onderwerp: Re: = [dmarc-ietf] Aggregate reporting options tag name = 'ao'

 

Hello Freddie,

if a message = has 5 DKIM-Signatures, some of them fail DKIM validation and some of = them do not align, irrespective of validation status, you want to = receive a report for the failed DKIM signatures. The proposed option d = is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a = report for failed DKIM signature you put in the DKIM-Signature header = r=3Dy. After the mail passes over a mailing list, the signature is = invalidated and you get a useless report. Your intension is to limit the = amount of useless reports, but this particular option goes in the = opposite direction.

If you remove the SPF records and ensure that = each leaving message is signed, you do not need the ao=3D1 option, as = each report on failure will be about DKIM.

With ao=3Ds whenever a = mail is sent to an alias and redirected to another server, you will get = a useless report. I am not exactly sure, but I think SPF contained some = reporting mechanisms, so this option might duplicate = them.

Perhaps you want to propose a mechanism, that hides the = successful deliveries (useless report) and only reports problematic = cases?

Regards
=D0=94=D0=B8=D0=BB=D1=8F=D0=BD

On July 31, 2019 5:58:18 PM = GMT+03:00, Freddie Leeman <freddie=3D40le= emankuiper.nl@dmarc.ietf.org> = wrote:

Would it be useful to add an =E2=80=98ao=E2=80=99 tag name = for aggregate reporting options? Something like:

 

ao:         = Aggregate reporting options (plain-text; OPTIONAL; default is = "0").

Provides requested options for generation of aggregate = reports. This tag's content MUST be ignored if a "rua" tag is = not specified. The value of this tag is a colon-separated list of = characters that indicate aggregate reporting options as = follows:

 

0: Generate a DMARC aggregate report for every message, = regardless of its alignment.

1: Generate a DMARC aggregate = report if any underlying authentication mechanism produced something = other than an aligned "pass" result.

d: Generate a DMARC aggregate = report if the message had a signature that failed evaluation, regardless = of its alignment.

s: Generate a DMARC aggregate report if the message failed = SPF evaluation, regardless of its alignment.

 

This would allow domain owners to = save on tons of reports to be handled and processing that are useless in = most scenarios. For instance, when I=E2=80=99ve deployed my = SPF/DKIM/DMARC policy and I=E2=80=99m pleased with my policie=E2=80=99s = results, I would still want to use the reporting to detect and fix = changes in my email environment. If a million mails a day are nicely = processed with DKIM and SPF aligned, I do not need those entries in my = aggregate reports. I=E2=80=99m only interested in the reports where = either DKIM or SPF fails. In most scenario=E2=80=99s this will cut data = transfer and report processing with more than 99 percent. Whenever there = is a bump in the number of reports received, I can detect that something = is wrong and I might need to add a host to my SPF policy or need to fix = my DKIM signing.

 

I was amazed that these options weren=E2=80=99t in the = current RFC, as these do exist for failure reports. Am I missing = something? Is there a reason why this would be a bad = idea?

 

Kind regards,

Freddie

------=_NextPart_000_016F_01D547D6.986DE510-- From nobody Wed Jul 31 14:24:33 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 E958812006D for ; Wed, 31 Jul 2019 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYkNe22j-ujf for ; Wed, 31 Jul 2019 14:24:30 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 A57AE1200B7 for ; Wed, 31 Jul 2019 14:24:29 -0700 (PDT) Authentication-Results: mail.aegee.org/x6VLOLqe030146; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564608263; i=dkim+MSA-tls@aegee.org; r=y; bh=2bCBlcdj/uU3ATiwsuwlmYM+OjdbpfOlEGCqrSEv13A=; h=Subject:From:To:Date:In-Reply-To:References; b=J9Et3YKUXi7hZ/a0UgkoNHnq7t18ye2TQP1NnJnV6O7Qd6Wp7MiXcDG8DAbyacQnv 7LdUivZ5OLvRoiZ6cdm208lnptEuqZZzEqWqqDKQKAd/FNKrmSxzOZO6KElPmKxjBT IhWWEQ6p8qhKm0iaWyjzsdP/FOnKG4HcWiuGIQTt+ihs6FJR9isF5lURvxbGwauxXq eajt7XwXlUQNtxGDyglQgGk6NtB1EhojNE1EnTbysVsrZOJkGggQ3BsX2uJbzYq2Zs JxqG0L94qtgRXEVh3JW3PybWrH3KFzZBICxiRZl3nwlH2xnzL32u6TFTuK2+o0jpwG lQigluLwj++C0jc0VVuU3QwsOd5vXVtQdUiWgL0NVQ0Z+/roWpoSjX8P5Ds/rBTeXh PHB7eo7hP1lIaobtx5u4rAs1rICEyV17sDXQRgugPNU8MH2zAgNQvdV9vOb8mryvvd bTXjckhqdZ0I/FVP+k7rIn5bEXVCOhfdDZWP3kqwUQAc+U6QbV1ptIolPa2FwCm2Xq wpGykJKWbLhTNK27boqJj4NV0vlkKmPDjyQkNVqzBVmMqWbM41NIcGQlblngk3u62U iXvgxdxughKGmAq1oFuhvaLPTNEW5+kWVYiMkeFawoeKInz530SWu0/iPQjArmLVrE ug0KC2HqQ7cKzant//kBURqU= Authentication-Results: mail.aegee.org/x6VLOLqe030146; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6VLOLqe030146 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 31 Jul 2019 21:24:22 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Freddie Leeman , dmarc@ietf.org Date: Wed, 31 Jul 2019 21:24:21 +0000 In-Reply-To: <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 31 Jul 2019 21:24:31 -0000 Hello Fredie, DMARC limits the amount of servers that can generate emails for a particular domain. The aggregate reports show to which extend DMARC does work correctly and when it fails for a domain. The aggregate reports to not tell you how to fix your DKIM implementation, so that sender and receiver agree on the DKIM signature. The per message failure reports tell you which messages were not signed correctly, so that you can check the DKIM implementation. I thought some hours ago it could be useful to reduce the amount of reports, by not sending a report when things are 100% correct, but now I am not so sure. The aggregate reports contain information, if something is not working correctly, but they also prove, if everything is running correctly. If there is an option to reduce the reports to contain only information about failures, you don’t have a prove, that everything is working correctly. Let’s say if you write a message to site S and don’t get an aggregate report back, this can mean, that DMARC passed, but it can also mean, that S does not evaluate DMARC or that DMARC failed and S does not send aggregate reports. Is the lack of success-reports a prove of correctness or not? I am inclined. What do you want to do with the information about failures from the DMARC aggregate reports? Regards Дилян On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: > Hi Дилян, > > Thanks for your input and feedback. Maybe a single tag, that allows the domain owner to avoid receiving aggregate reports for messages that align, would be enough? I personally have little experience with mailing lists which, I understand, can be a real pain when it comes to SPF/DKIM. So would a tag that instructs the receiving party to only send an aggregate report whenever the DMARC policies is applied be a better option? > > Kind regards, > Freddie > > Van: Дилян Палаузов [mailto:dilyan.palauzov@aegee.org] > Verzonden: woensdag 31 juli 2019 17:29 > Aan: dmarc@ietf.org > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' > > Hello Freddie, > > if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some of them do not align, irrespective of validation status, you want to receive a report for the failed DKIM signatures. The proposed option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a report for failed DKIM signature you put in the DKIM-Signature header r=y. After the mail passes over a mailing list, the signature is invalidated and you get a useless report. Your intension is to limit the amount of useless reports, but this particular option goes in the opposite direction. > > If you remove the SPF records and ensure that each leaving message is signed, you do not need the ao=1 option, as each report on failure will be about DKIM. > > With ao=s whenever a mail is sent to an alias and redirected to another server, you will get a useless report. I am not exactly sure, but I think SPF contained some reporting mechanisms, so this option might duplicate them. > > Perhaps you want to propose a mechanism, that hides the successful deliveries (useless report) and only reports problematic cases? > > Regards > Дилян > > > On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman wrote: > > Would it be useful to add an ‘ao’ tag name for aggregate reporting options? Something like: > > > > ao: Aggregate reporting options (plain-text; OPTIONAL; default is "0"). > > Provides requested options for generation of aggregate reports. This tag's content MUST be ignored if a "rua" tag is not specified. The value of this tag is a colon-separated list of characters that indicate aggregate reporting options as follows: > > > > 0: Generate a DMARC aggregate report for every message, regardless of its alignment. > > 1: Generate a DMARC aggregate report if any underlying authentication mechanism produced something other than an aligned "pass" result. > > d: Generate a DMARC aggregate report if the message had a signature that failed evaluation, regardless of its alignment. > > s: Generate a DMARC aggregate report if the message failed SPF evaluation, regardless of its alignment. > > > > This would allow domain owners to save on tons of reports to be handled and processing that are useless in most scenarios. For instance, when I’ve deployed my SPF/DKIM/DMARC policy and I’m pleased with my policie’s results, I would still want to use the reporting to detect and fix changes in my email environment. If a million mails a day are nicely processed with DKIM and SPF aligned, I do not need those entries in my aggregate reports. I’m only interested in the reports where either DKIM or SPF fails. In most scenario’s this will cut data transfer and report processing with more than 99 percent. Whenever there is a bump in the number of reports received, I can detect that something is wrong and I might need to add a host to my SPF policy or need to fix my DKIM signing. > > > > I was amazed that these options weren’t in the current RFC, as these do exist for failure reports. Am I missing something? Is there a reason why this would be a bad idea? > > > > Kind regards, > > Freddie > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Jul 31 15:22:45 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 1008A120089 for ; Wed, 31 Jul 2019 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 cWaVRtwYvX56 for ; Wed, 31 Jul 2019 15:22:40 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 7CDDC120046 for ; Wed, 31 Jul 2019 15:22:40 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id p17so71349665wrf.11 for ; Wed, 31 Jul 2019 15:22:40 -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=OROM3Ae9kZE7Th09J14z7aXDyixcVTV2P4BtMh7K3+U=; b=Af1TyteggSo7L49Mp56F5CucIZITFc/dO045Ek5BHivYLNp0jZS9BwPucV3zSqbS8K Aml666Uon6JHgSh8ukY/Y2NzYpP8KA5+uWVU08Z8MKme8CBKRnDpOTPA1HkLkK00UOhK GpJtQDMdoVfaXCxf9GeC+v1UY5xAElOrx9j1Dg7kmkYBKY/Bph3BZbJSA5TM2eDtipuj C4N4VHpxHxaIzRgMX6uZwSp4GrF0kBRffkhHlzg2QvGC0mBU5RGNjvAwMvygK/7qPNd3 6FnCseXfxTfdxNxOuruNk2FGN0+HnhMW5TelWzQoLzgEzHuNM+DvOe2A1ML8KA2QGIpF CgPA== 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=OROM3Ae9kZE7Th09J14z7aXDyixcVTV2P4BtMh7K3+U=; b=S5QG7FZ9waDAdmN2bMcb9tIEunRw9ub/BPVOMRBIwEUcztB64mNgIetgJuIasUHcX7 Bc7uQf3eXhz6mDW9eGZXFSen5UmDRBhrgsy1S9ktDphBtvxLHGGrAfyzqU2pwinvkbmY 6KzMdvtxqStjKZqkCXUCVQhbDbpsPL1MIlSNR5pz5Q31uMrJ8E4K5QN2LvfrrbYEjoSc lETN81EYg3dBU1WPvCezuL8Ff0BSCzeOA1+n8tziY2sqGYpwxOp1A9nA6CYFFd5rGR5Q f0RXoWbAoJ6+VkUOyXINjirMYWKVApQfI09zNISgqQmChO5jOqPYGtEaoYEPAC1Mhnrv AsrA== X-Gm-Message-State: APjAAAVhjHzW5okRx9gvLPt96HwLpvqlsYiVmNSmgkFbRMXgXXYbA2hW NeCA+KUrU+lVUSWSsOw5lWhcuV45t+Hpu89fbOo= X-Google-Smtp-Source: APXvYqzBO12Nb2kXyZlEoKNQxM2XLywRPyAX9aDiL1f1rhKxFwqtCfEWVYV4ZYR2/GpfsDmMderPB8HLJWJ9z3dA0VM= X-Received: by 2002:a5d:4484:: with SMTP id j4mr136207823wrq.143.1564611758904; Wed, 31 Jul 2019 15:22:38 -0700 (PDT) MIME-Version: 1.0 References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> In-Reply-To: From: Dotzero Date: Wed, 31 Jul 2019 18:22:29 -0400 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: Freddie Leeman , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000019dbfd058f0190b3" Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' 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, 31 Jul 2019 22:22:44 -0000 --00000000000019dbfd058f0190b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems. An increase in the failure rate is generally either 1) someone trying to abuse your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization has started sending mail from somewhere without appropriate SPF or DKIM. Michael Hammer On Wed, Jul 31, 2019 at 5:24 PM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0= =D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello Fredie, > > DMARC limits the amount of servers that can generate emails for a > particular domain. The aggregate reports show to > which extend DMARC does work correctly and when it fails for a domain. > The aggregate reports to not tell you how to fix > your DKIM implementation, so that sender and receiver agree on the DKIM > signature. The per message failure reports tell > you which messages were not signed correctly, so that you can check the > DKIM implementation. > > I thought some hours ago it could be useful to reduce the amount of > reports, by not sending a report when things are > 100% correct, but now I am not so sure. > > The aggregate reports contain information, if something is not working > correctly, but they also prove, if everything is > running correctly. If there is an option to reduce the reports to contai= n > only information about failures, you don=E2=80=99t > have a prove, that everything is working correctly. Let=E2=80=99s say if= you > write a message to site S and don=E2=80=99t get an > aggregate report back, this can mean, that DMARC passed, but it can also > mean, that S does not evaluate DMARC or that > DMARC failed and S does not send aggregate reports. Is the lack of > success-reports a prove of correctness or not? I am > inclined. > > What do you want to do with the information about failures from the DMARC > aggregate reports? > > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: > > Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD, > > > > Thanks for your input and feedback. Maybe a single tag, that allows the > domain owner to avoid receiving aggregate reports for messages that align= , > would be enough? I personally have little experience with mailing lists > which, I understand, can be a real pain when it comes to SPF/DKIM. So wou= ld > a tag that instructs the receiving party to only send an aggregate report > whenever the DMARC policies is applied be a better option? > > > > Kind regards, > > Freddie > > > > Van: =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0= =B7=D0=BE=D0=B2 [mailto:dilyan.palauzov@aegee.org] > > Verzonden: woensdag 31 juli 2019 17:29 > > Aan: dmarc@ietf.org > > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' > > > > Hello Freddie, > > > > if a message has 5 DKIM-Signatures, some of them fail DKIM validation > and some of them do not align, irrespective of validation status, you wan= t > to receive a report for the failed DKIM signatures. The proposed option d > is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a > report for failed DKIM signature you put in the DKIM-Signature header r= =3Dy. > After the mail passes over a mailing list, the signature is invalidated a= nd > you get a useless report. Your intension is to limit the amount of useles= s > reports, but this particular option goes in the opposite direction. > > > > If you remove the SPF records and ensure that each leaving message is > signed, you do not need the ao=3D1 option, as each report on failure will= be > about DKIM. > > > > With ao=3Ds whenever a mail is sent to an alias and redirected to anoth= er > server, you will get a useless report. I am not exactly sure, but I think > SPF contained some reporting mechanisms, so this option might duplicate > them. > > > > Perhaps you want to propose a mechanism, that hides the successful > deliveries (useless report) and only reports problematic cases? > > > > Regards > > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD > > > > > > On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman 40leemankuiper.nl@dmarc.ietf.org> wrote: > > > Would it be useful to add an =E2=80=98ao=E2=80=99 tag name for aggreg= ate reporting > options? Something like: > > > > > > ao: Aggregate reporting options (plain-text; OPTIONAL; defaul= t > is "0"). > > > Provides requested options for generation of aggregate reports. This > tag's content MUST be ignored if a "rua" tag is not specified. The value = of > this tag is a colon-separated list of characters that indicate aggregate > reporting options as follows: > > > > > > 0: Generate a DMARC aggregate report for every message, regardless of > its alignment. > > > 1: Generate a DMARC aggregate report if any underlying authentication > mechanism produced something other than an aligned "pass" result. > > > d: Generate a DMARC aggregate report if the message had a signature > that failed evaluation, regardless of its alignment. > > > s: Generate a DMARC aggregate report if the message failed SPF > evaluation, regardless of its alignment. > > > > > > This would allow domain owners to save on tons of reports to be > handled and processing that are useless in most scenarios. For instance, > when I=E2=80=99ve deployed my SPF/DKIM/DMARC policy and I=E2=80=99m pleas= ed with my > policie=E2=80=99s results, I would still want to use the reporting to det= ect and > fix changes in my email environment. If a million mails a day are nicely > processed with DKIM and SPF aligned, I do not need those entries in my > aggregate reports. I=E2=80=99m only interested in the reports where eithe= r DKIM or > SPF fails. In most scenario=E2=80=99s this will cut data transfer and rep= ort > processing with more than 99 percent. Whenever there is a bump in the > number of reports received, I can detect that something is wrong and I > might need to add a host to my SPF policy or need to fix my DKIM signing. > > > > > > I was amazed that these options weren=E2=80=99t in the current RFC, a= s these > do exist for failure reports. Am I missing something? Is there a reason w= hy > this would be a bad idea? > > > > > > Kind regards, > > > Freddie > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000019dbfd058f0190b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having both passes and failures is incredibly useful.= The percentage of failures is very useful. Any set of mail streams will al= ways have some failures. Once you know what the baseline rate for a (sub)do= main is, simply seeing changes in that rate will help you identify problems= . An increase in the failure rate is generally either 1) someone trying to = abuse your domain name; or 2) something has gone wrong with DKIM signing or= someone associated with the domain organization has started sending mail f= rom somewhere without appropriate SPF or DKIM.

Mic= hael Hammer

On Wed, Jul 31, 2019 at 5:24 PM =D0=94=D0=B8=D0=BB=D1=8F= =D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <dilyan.palauzov@aegee.org> wrote:
<= /div>
Hello Fredie,

DMARC limits the amount of servers that can generate emails for a particula= r domain.=C2=A0 The aggregate reports show to
which extend DMARC does work correctly and when it fails for a domain.=C2= =A0 The aggregate reports to not tell you how to fix
your DKIM implementation, so that sender and receiver agree on the DKIM sig= nature.=C2=A0 The per message failure reports tell
you which messages were not signed correctly, so that you can check the DKI= M implementation.

I thought some hours ago it could be useful to reduce the amount of reports= , by not sending a report when things are
100% correct, but now I am not so sure.

The aggregate reports contain information, if something is not working corr= ectly, but they also prove, if everything is
running correctly.=C2=A0 If there is an option to reduce the reports to con= tain only information about failures, you don=E2=80=99t
have a prove, that everything is working correctly.=C2=A0 Let=E2=80=99s say= if you write a message to site S and don=E2=80=99t get an
aggregate report back, this can mean, that DMARC passed, but it can also me= an, that S does not evaluate DMARC or that
DMARC failed and S does not send aggregate reports.=C2=A0 Is the lack of su= ccess-reports a prove of correctness or not?=C2=A0 I am
inclined.

What do you want to do with the information about failures from the DMARC a= ggregate reports?

Regards
=C2=A0 =D0=94=D0=B8=D0=BB=D1=8F=D0=BD

On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote:
> Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD,
>=C2=A0
> Thanks for your input and feedback. Maybe a single tag, that allows th= e domain owner to avoid receiving aggregate reports for messages that align= , would be enough? I personally have little experience with mailing lists w= hich, I understand, can be a real pain when it comes to SPF/DKIM. So would = a tag that instructs the receiving party to only send an aggregate report w= henever the DMARC policies is applied be a better option?
>=C2=A0
> Kind regards,
> Freddie
>=C2=A0
> Van: =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0= =B7=D0=BE=D0=B2 [mailto:dilyan.palauzov@aegee.org]
> Verzonden: woensdag 31 juli 2019 17:29
> Aan: dmarc@ietf.or= g
> Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name '= ao'
>=C2=A0
> Hello Freddie,
>
> if a message has 5 DKIM-Signatures, some of them fail DKIM validation = and some of them do not align, irrespective of validation status, you want = to receive a report for the failed DKIM signatures. The proposed option d i= s in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a repo= rt for failed DKIM signature you put in the DKIM-Signature header r=3Dy. Af= ter the mail passes over a mailing list, the signature is invalidated and y= ou get a useless report. Your intension is to limit the amount of useless r= eports, but this particular option goes in the opposite direction.
>
> If you remove the SPF records and ensure that each leaving message is = signed, you do not need the ao=3D1 option, as each report on failure will b= e about DKIM.
>
> With ao=3Ds whenever a mail is sent to an alias and redirected to anot= her server, you will get a useless report. I am not exactly sure, but I thi= nk SPF contained some reporting mechanisms, so this option might duplicate = them.
>
> Perhaps you want to propose a mechanism, that hides the successful del= iveries (useless report) and only reports problematic cases?
>
> Regards
> =D0=94=D0=B8=D0=BB=D1=8F=D0=BD
>
>
> On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman <freddie=3D40leema= nkuiper.nl@dmarc.ietf.org> wrote:
> > Would it be useful to add an =E2=80=98ao=E2=80=99 tag name for ag= gregate reporting options? Something like:
> >=C2=A0
> > ao:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aggregate reporting options = (plain-text; OPTIONAL; default is "0").
> > Provides requested options for generation of aggregate reports. T= his tag's content MUST be ignored if a "rua" tag is not speci= fied. The value of this tag is a colon-separated list of characters that in= dicate aggregate reporting options as follows:
> >=C2=A0
> > 0: Generate a DMARC aggregate report for every message, regardles= s of its alignment.
> > 1: Generate a DMARC aggregate report if any underlying authentica= tion mechanism produced something other than an aligned "pass" re= sult.
> > d: Generate a DMARC aggregate report if the message had a signatu= re that failed evaluation, regardless of its alignment.
> > s: Generate a DMARC aggregate report if the message failed SPF ev= aluation, regardless of its alignment.
> >=C2=A0
> > This would allow domain owners to save on tons of reports to be h= andled and processing that are useless in most scenarios. For instance, whe= n I=E2=80=99ve deployed my SPF/DKIM/DMARC policy and I=E2=80=99m pleased wi= th my policie=E2=80=99s results, I would still want to use the reporting to= detect and fix changes in my email environment. If a million mails a day a= re nicely processed with DKIM and SPF aligned, I do not need those entries = in my aggregate reports. I=E2=80=99m only interested in the reports where e= ither DKIM or SPF fails. In most scenario=E2=80=99s this will cut data tran= sfer and report processing with more than 99 percent. Whenever there is a b= ump in the number of reports received, I can detect that something is wrong= and I might need to add a host to my SPF policy or need to fix my DKIM sig= ning.
> >=C2=A0
> > I was amazed that these options weren=E2=80=99t in the current RF= C, as these do exist for failure reports. Am I missing something? Is there = a reason why this would be a bad idea?
> >=C2=A0
> > Kind regards,
> > Freddie
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org=
> https://www.ietf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000019dbfd058f0190b3-- From nobody Wed Jul 31 17:28:37 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 554EB120043 for ; Wed, 31 Jul 2019 17:28:35 -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 tO9AqwkjXumi for ; Wed, 31 Jul 2019 17:28:32 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC32120123 for ; Wed, 31 Jul 2019 17:28:31 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id r15so31800833lfm.11 for ; Wed, 31 Jul 2019 17:28:31 -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=1RegWOBdJxgVCQCFBi+xpNhJ0AGOF8wnVnFml8gekas=; b=NbsYyPoTlt+cUw+BfTUzfvCccTgB8bIH+JOJH/P/TsmR3p2EagMbIDn6382uCW9qVy s8jINOSxyvQCTNij8YsStMg6P0KhkyXeUBb2khw67i21sBBhxPR0/3CAwoiHBMHp6AYI A5Kz1F6sx81FbjIgEtBgaNY/Re0Wzaj2JMxosR96G+naktJ8IY6yotFyvez4j/XNiyhL AA8yKSiGoUsOdj1UjuJA6QlzN1qwJipVygmaFEVk0CuRisiiQ0uhC5w8vkIZGAiuW+fd GDVyiGk+Yc2CMZXdDetPNJRliVswPrlE+n6oyAawMkbNwJa4alM4bNRjt/tRILG6EbZQ SBfQ== 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=1RegWOBdJxgVCQCFBi+xpNhJ0AGOF8wnVnFml8gekas=; b=Bn45DcJmOPeaV3F4WetP+FQm5DiJ+WVDdRTLcCSm5SVKQDvqRu0tDv9ZOqhsGFJL7p YDw6JVu2qIAR7MPkkOXXiMhPnZ/+H4pCJzz0tDQku5oiXgfx5hOIiD+ZTHTUTheFMZ12 nkhZAQHxOsDuXMEIJXI6fouetZpGWlxbH1UhtWGwmIoaIVSNT1/F5gpj8fqOeP6Pl84Q EO/0MxKUYsVDzvG8tQpEVToiGh0kvd0uR0S3uNWNKEkBZq4s+x+15plNnxjdnRjWsl3O guaDyCeW9kmEf82YVSZqLRjVWtrOxvIwDUPx5e/m4B4+8QCXgAcYMA1SN9FwndhXWHXw ZX2w== X-Gm-Message-State: APjAAAUfhohqQar0wdicfM8HUeYvDdTG5q8PDZfOTu+aKOUORwUZW3Ng z//Ug6LGYrQlu+fDxcVv9d0+gFQKUVR9JH9AdYoEM+CxHwc= X-Google-Smtp-Source: APXvYqweiHTyCOMO/HYb2a+eI4ZyL+CZ5+Nt3X5248e9mKKCNwh3bDAyQDcGf30XErFr+8voNsVt8YHjUAMtPQ+OOO0= X-Received: by 2002:ac2:4a78:: with SMTP id q24mr16205923lfp.59.1564619309106; Wed, 31 Jul 2019 17:28:29 -0700 (PDT) MIME-Version: 1.0 References: <4195597.6UoUMpgHb9@l5580> In-Reply-To: <4195597.6UoUMpgHb9@l5580> From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 17:28:17 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000020c920058f0352bf" Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-psd review X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 00:28:35 -0000 --00000000000020c920058f0352bf Content-Type: text/plain; charset="UTF-8" Thanks for this, much better. Some additional feedback. Please note (everyone) that I'm offering these as clarifying contributions to text; I'm not prescribing or proscribing anything. If the text I'm proposing isn't worthy of consensus, please speak up. On Sat, Jul 27, 2019 at 1:45 PM Scott Kitterman wrote: > > I updated the paragraph to start: > > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. DMARC policies can be > applied to individual domains or to all domains within an > organization. The design of DMARC precludes grouping policies for > domains based on policy published above the organizational level, > such as TLDs (Top Level Domains). > > Does that clear those comments up? > That last sentence still puzzles me, and I think it's the term "grouping" that gives me trouble. How's this? DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. This document also seeks to address implementations that consider a domain on the Public Suffix List (PSL) to be ineligible for DMARC enforcement. If we like this, I suggest it or language like it can also be used to rework the first paragraph of the Introduction section in -05. To import DMARC definitions into the introduction, you could say that DMARC presumes that a domain is either on the PSL or is an OD, and never both,. > > As an example, imagine a country code TLD (ccTLD) which has public > > subdomains for government and commercial use (.gov.example and > > .com.example). Within the .gov.example public suffix, use of DMARC > > [RFC7489] has been mandated and .gov.example has published its own > > DMARC [RFC7489] record: > > > > "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" > > > > Can we add spaces after the semicolons? I know this is legal format > > but it would be more readable. > > Changed. > Thanks. Now for the text right before the example; I suggest: As an example, ... Suppose there exists a registered domain "tax.gov.example" that is responsible for taxation in this imagined country. However, by exploiting the typically unauthenticated nature of email, there are regular malicious campaigns to impersonate this organization that use similar-looking ("cousin") domains such as "t4x.gov.example". These domains are not registered. Within the ".gov.example" public suffix, use of DMARC has been mandated, so "gov.example" publishes the following DMARC record: ... Defensively registering all variants of "tax" is obviously not a scalable strategy. The intent of this specification, therefore, is to enhance the DMARC algorithm by enabling an agent receiving such a message to be able to determine that a relevant policy is present at "gov.example", which is precluded by the current DMARC algorithm. > > There are two types of Public Suffix Operators (PSOs) for which this > > extension would be useful and appropriate: > > > > o Branded PSDs (e.g., ".google"): These domains are effectively > > Organizational Domains as discussed in DMARC [RFC7489]. They > > control all subdomains of the tree. These are effectively private > > domains, but listed in the Public Suffix List. They are treated > > as Public for DMARC [RFC7489] purposes. They require the same > > protections as DMARC [RFC7489] Organizational Domains, but are > > currently excluded. > > > > How are they current excluded? Is this because they're on the PSL, so > > DMARC treats them differently? > > Yes. Per the DMARC definition, they are not organizational domains. > I suggest "unable to benefit from DMARC" rather than "excluded". "Excluded" makes me think DMARC specifically targeted them as not worthy of or appropriate for inclusion, which isn't the case. > > o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): > > Because existing Organizational Domains using this PSD have their > > own DMARC policy, the applicability of this extension is for non- > > existent domains. The extension allows the brand protection > > benefits of DMARC [RFC7489] to extend to the entire PSD, including > > cousin domains of registered organizations. > > > > An example would be useful here. > > I've added this: > > As an example, take the ".gov.example" described above and add that > for this entity emails about tax returns are sent from > tax.gov.example. It would not be surprising if fraudulent emails > were sent purporting to be from taxes.gov.example (taxes is a cousin > of tax - different enough to evade DMARC protection, but similar > enough to potentially confuse users). As defined in DMARC [RFC7489], > a DMARC record could be published for tax.gov.example, but there is > no general solution to publishing a DMARC policy to defend against > abuse of non-existent cousins such as taxes.gov.example. While an > explicit record could be published for this one domain, the universe > of possible cousins is such that this approach does not scale. > > How's that? > Great, and it's also pretty much what I proposed above. (Apologies; my read-ahead failed.) I suggest picking one or the other, but I think it's of benefit to put this higher up where my suggestion is to set context. > Due to the design of DMARC [RFC7489] and the nature of the Internet > > email architecture [RFC5598], there are interoperability issues > > associated with DMARC [RFC7489] deployment. These are discussed in > > Interoperability Issues between DMARC and Indirect Email Flows > > [RFC7960]. These issues are not applicable to PSDs, since they > > (e.g., the ".gov.example" used above) do not send mail. > > > > DMARC doesn't need to be followed by its RFC number every time. > > I went through and removed most of these. I tried to remove them so that > it's > mostly there when talking about DMARC the RFC, not DMARC the protocol. > Yeah I think you got most of them but there are a few I would still reduce. Not a big deal unless others concur; the RFC Editor will probably chime in as well. > 2.2. Public Suffix Domain (PSD) > > > > The global Internet Domain Name System (DNS) is documented in > > numerous Requests for Comment (RFC). It defines a tree of names > > starting with root, ".", immediately below which are Top Level Domain > > names such as ".com" and ".us". They are not available for private > > registration. In many cases the public portion of the DNS tree is > > more than one level deep. PSD DMARC includes all public domains > > above the organizational level in the tree, e.g., ".gov.uk". > > > > I don't know what that last sentence means. PSD DMARC is an > > extension; how does it include domains? > > Deleted the sentence. I don't think it is necessary for the definition, > so > let's not confuse things. > The text present now for 2.2 defines the name/label structure of the DNS, but doesn't actually say what a PSD is. This is an interesting problem, because we are attempting to describe (or ascribe) semantics of the DNS that simply do not exist. The DNS is a hierarchical naming structure and related database, plain and simple; we are attempting to ascribe to it boundaries that are not there in DNS-land. But we happen to do lookups in it using DNS APIs. So let's try removing the DNS from the definition: The domain name structure consists of a tree of names, each of which is made of a sequence of words ("labels") separated by period characters. The root of the tree is simply called ".". The Internet community at large, through processes and policies external to this work, selects points in this tree at which to register domain names "owned" by independent organizations. Real-world examples are ".com", ".org", ".us", and ".gov.uk". Names at which such registrations occur are called Public Suffix Domains (PSDs), and a registration consists of a label selected by the registrant to which a desirable PSD is appended. For example, "ietf.org" is a registered domain name, and ".org" is its PSD. While I'm here, I suggest 2.3 is a little terse. Maybe: The longest PSD is the PSD matching more labels in the domain name under evaluation than any other PSL entry. > 3.2. Section 6.1 DMARC Policy Record > > > > PSD DMARC records are published as a subdomain of the PSD. For the > > PSD ".example", the PSO would post DMARC policy in a TXT record at > > "_dmarc.example". > > > > Don't you mean the PSD DMARC record is a record in the zone of the > > PSD? It's not a subdomain. > > Here's what's in RFC 7489 about DMARC record publishing: > > 6.1. DMARC Policy Record > > Domain Owner DMARC preferences are stored as DNS TXT records in > subdomains named "_dmarc". For example, the Domain Owner of > "example.com" would post DMARC preferences in a TXT record at > "_dmarc.example.com". > > I think our 3.2 is equivalent and adequate given this section is a > modification > to RFC 7489 Section 6.1. I did not make a change. > Embarrassing. RFC7489 6.1's text you cited is unfortunate. I would change "in subdomains named" to "at labels named". But also, why do we need this section? The PSD DMARC record is in the same place as one would expect it having read only RFC7489, correct? > 3.4. Section 6.6.3. Policy Discovery > > > > A new step between step 3 and 4 is added: > > > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > > Organizational Domain is one that the receiver has determined is > > acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for > > a DMARC TXT record at the DNS domain matching the longest PSD > > (Section 2.3) in place of the RFC5322.From domain in the message > > (if different). A possibly empty set of records is returned. > > > > Section 6.6.3 of DMARC doesn't talk about "acceptable for DMARC", so I > > don't know what "acceptable for PSD DMARC" might mean. > > Changed to: > > 3A. If the set is now empty and the longest PSD (Section 2.3) of the > Organizational Domain is one that the receiver has determined is > acceptable for PSD DMARC (discussed in the experiment description > (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC > TXT record at the DNS domain matching the longest PSD > (Section 2.3) in place of the RFC5322.From domain in the message > (if different). A possibly empty set of records is returned. > > > Section numbers in the prose of this section should make clear which > > document they're referencing. > > I checked and any reference to an RFC7489 paragraph number that's in the > text > is labeled as such. I'm talking about the "Section 2.3" here, and the "Section x.y" strings in the section headings in Section 3. Since you are pointing back to RFC7489 frequently, I thought it might be best to say "Section 2.3 of this document", or "Section x.y of RFC7489", as appropriate. Also in the example in the paragraph below here in the document, you're using ".cctld"; should that be ".example" or ".cctld.example"? One final thing: I added a sentence at the end of my proposed Abstract that tries to highlight that domains on the PSL also need to be checked and not special-cased when one receives mail from a PSL. In order to tie it to the experiment, I suggest this (as a new section at the end; reorder at your discretion): 3.7. PSDs Are Eligible For DMARC Experience with DMARC has shown that some implementations short-circuit messages, bypassing DMARC policy application, when the domain name extracted by the receiver (from the RFC5322.From) is on the PSL. This prevents the capability being created by this specification. Therefore, the following paragraph is appended to Section 6.6.1 of RFC7489: Note that domain names that appear on the Public Suffix List are not exempt from DMARC policy application and reporting. -MSK --00000000000020c920058f0352bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this, much better.=C2=A0 Some = additional feedback.

Please note (ever= yone) that I'm offering these as clarifying contributions to text; I= 9;m not prescribing or proscribing anything.=C2=A0 If the text I'm prop= osing isn't worthy of consensus, please speak up.

On Sat, Jul 27, 2019 at 1:45 PM Scott Kitte= rman <sklist@kitterman.com&g= t; wrote:

I updated the paragraph to start:

=C2=A0 =C2=A0DMARC (Domain-based Message Authentication, Reporting, and
=C2=A0 =C2=A0Conformance) is a scalable mechanism by which a mail-originati= ng
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.=C2=A0 DMARC pol= icies can be
=C2=A0 =C2=A0applied to individual domains or to all domains within an
=C2=A0 =C2=A0organization.=C2=A0 The design of DMARC precludes grouping pol= icies for
=C2=A0 =C2=A0domains based on policy published above the organizational lev= el,
=C2=A0 =C2=A0such as TLDs (Top Level Domains).=C2=A0

Does that clear those comments up?

That= last sentence still puzzles me, and I think it's the term "groupi= ng" that gives me trouble.

How's this?
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
 =
  presumes that domain names represent either nodes in the tree below
  =
 which registrations occur, or nodes where registrations have occurred;
=
   it does not permit a domain name to have both of these properties
   =
simultaneously.  Since its deployment in 2015, use of DMARC has shown
    a clear need for the ability to express policy for these domai=
ns as well.

   Domains at which registrations can occur a=
re referred to as Public
   Suffix Domains (PSDs).  This document descri=
bes an extension to DMARC
  =C2=A0to enable DMARC functionality for PSDs=
.

   This document also seeks to address implementations =
that consider a domain
   on the Public Suffix List (PSL) to =
be ineligible for DMARC enforcement.

If we like this, I suggest it or language like it ca=
n also be used to rework the first paragraph of the Introduction section in=
 -05.  To import DMARC definitions into the introduction, you could say tha=
t DMARC presumes that a domain is either on the PSL or is an OD, and never =
both,.

>=C2=A0 =C2=A0 As an example, imagine a country code TLD (ccTLD) which h= as public
>=C2=A0 =C2=A0 subdomains for government and commercial use (.gov.exampl= e and
>=C2=A0 =C2=A0 .com.example).=C2=A0 Within the .gov.example public suffi= x, use of DMARC
>=C2=A0 =C2=A0 [RFC7489] has been mandated and .gov.example has publishe= d its own
>=C2=A0 =C2=A0 DMARC [RFC7489] record:
>
>=C2=A0 =C2=A0 "v=3DDMARC1;p=3Dreject;rua=3Dmailto:dmarc@dmarc.service.go= v.example"
>
> Can we add spaces after the semicolons? I know this is legal format > but it would be more readable.

Changed.

Thanks.=C2=A0 Now for the text= right before the example; I suggest:

As an exampl= e, ...=C2=A0 Suppose there exists a registered domain "tax.gov.example= " that is responsible for taxation in this imagined country.=C2=A0 How= ever, by exploiting the typically unauthenticated nature of email, there ar= e regular malicious campaigns to impersonate this organization that use sim= ilar-looking ("cousin") domains such as "t4x.gov.example&quo= t;.=C2=A0 These domains are not registered.=C2=A0 Within the ".gov.exa= mple" public suffix, use of DMARC has been mandated, so "gov.exam= ple" publishes the following DMARC record:

...

Defensively registering all variants of &quo= t;tax" is obviously not a scalable strategy.=C2=A0 The intent of this = specification, therefore, is to enhance the DMARC algorithm by enabling an = agent receiving such a message to be able to determine that a relevant poli= cy is present at "gov.example", which is precluded by the current= DMARC algorithm.


>=C2=A0 =C2=A0 There are two types of Public Suffix Operators (PSOs)= for which this
>=C2=A0 =C2=A0 extension would be useful and appropriate:
>
>=C2=A0 =C2=A0 o=C2=A0 Branded PSDs (e.g., ".google"): These d= omains are effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Organizational Domains as discussed in DMARC= [RFC7489].=C2=A0 They
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control all subdomains of the tree.=C2=A0 Th= ese are effectively private
>=C2=A0 =C2=A0 =C2=A0 =C2=A0domains, but listed in the Public Suffix Lis= t.=C2=A0 They are treated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as Public for DMARC [RFC7489] purposes.=C2= =A0 They require the same
>=C2=A0 =C2=A0 =C2=A0 =C2=A0protections as DMARC [RFC7489] Organizationa= l Domains, but are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0currently excluded.
>
> How are they current excluded?=C2=A0 Is this because they're on th= e PSL, so
> DMARC treats them differently?

Yes.=C2=A0 Per the DMARC definition, they are not organizational domains.

I suggest "unable to benefit from D= MARC" rather than "excluded".=C2=A0 "Excluded" mak= es me think DMARC specifically targeted them as not worthy of or appropriat= e for inclusion, which isn't the case.


>=C2=A0 =C2=A0 o=C2=A0 Multi-organization PSDs that require DMARC usage = (e.g., ".bank"):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Because existing Organizational Domains usin= g this PSD have their
>=C2=A0 =C2=A0 =C2=A0 =C2=A0own DMARC policy, the applicability of this = extension is for non-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0existent domains.=C2=A0 The extension allows= the brand protection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0benefits of DMARC [RFC7489] to extend to the= entire PSD, including
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cousin domains of registered organizations.<= br> >
> An example would be useful here.

I've added this:

=C2=A0 =C2=A0As an example, take the ".gov.example" described abo= ve and add that
=C2=A0 =C2=A0for this entity emails about tax returns are sent from
=C2=A0 =C2=A0tax.gov.example.=C2=A0 It would not be surprising if fraudulen= t emails
=C2=A0 =C2=A0were sent purporting to be from taxes.gov.example (taxes is a = cousin
=C2=A0 =C2=A0of tax - different enough to evade DMARC protection, but simil= ar
=C2=A0 =C2=A0enough to potentially confuse users).=C2=A0 As defined in DMAR= C [RFC7489],
=C2=A0 =C2=A0a DMARC record could be published for tax.gov.example, but the= re is
=C2=A0 =C2=A0no general solution to publishing a DMARC policy to defend aga= inst
=C2=A0 =C2=A0abuse of non-existent cousins such as taxes.gov.example.=C2=A0= While an
=C2=A0 =C2=A0explicit record could be published for this one domain, the un= iverse
=C2=A0 =C2=A0of possible cousins is such that this approach does not scale.=

How's that?

Great, and it's als= o pretty much what I proposed above.=C2=A0 (Apologies; my read-ahead failed= .)=C2=A0 I suggest picking one or the other, but I think it's of benefi= t to put this higher up where my suggestion is to set context.

>=C2=A0 =C2=A0 Due to the design of DMARC [RFC7489] and the nature of th= e Internet
>=C2=A0 =C2=A0 email architecture [RFC5598], there are interoperability = issues
>=C2=A0 =C2=A0 associated with DMARC [RFC7489] deployment.=C2=A0 These a= re discussed in
>=C2=A0 =C2=A0 Interoperability Issues between DMARC and Indirect Email = Flows
>=C2=A0 =C2=A0 [RFC7960].=C2=A0 These issues are not applicable to PSDs,= since they
>=C2=A0 =C2=A0 (e.g., the ".gov.example" used above) do not se= nd mail.
>
> DMARC doesn't need to be followed by its RFC number every time.
I went through and removed most of these.=C2=A0 I tried to remove them so t= hat it's
mostly there when talking about DMARC the RFC, not DMARC the protocol.
<= /blockquote>

Yeah I think you got most of them but there= are a few I would still reduce.=C2=A0 Not a big deal unless others concur;= the RFC Editor will probably chime in as well.

> 2.2.=C2=A0 Public Suffix Domain (PSD)
>
>=C2=A0 =C2=A0 The global Internet Domain Name System (DNS) is documente= d in
>=C2=A0 =C2=A0 numerous Requests for Comment (RFC).=C2=A0 It defines a t= ree of names
>=C2=A0 =C2=A0 starting with root, ".", immediately below whic= h are Top Level Domain
>=C2=A0 =C2=A0 names such as ".com" and ".us".=C2=A0= They are not available for private
>=C2=A0 =C2=A0 registration.=C2=A0 In many cases the public portion of t= he DNS tree is
>=C2=A0 =C2=A0 more than one level deep.=C2=A0 PSD DMARC includes all pu= blic domains
>=C2=A0 =C2=A0 above the organizational level in the tree, e.g., ".= gov.uk&q= uot;.
>
> I don't know what that last sentence means.=C2=A0 PSD DMARC is an<= br> > extension; how does it include domains?

Deleted the sentence.=C2=A0 I don't think it is necessary for the defin= ition, so
let's not confuse things.

The text = present now for 2.2 defines the name/label structure of the DNS, but doesn&= #39;t actually say what a PSD is.

This is an inter= esting problem, because we are attempting to describe (or ascribe) semantic= s of the DNS that simply do not exist.=C2=A0 The DNS is a hierarchical nami= ng structure and related database, plain and simple; we are attempting to a= scribe to it boundaries that are not there in DNS-land.=C2=A0 But we happen= to do lookups in it using DNS APIs.

So let's = try removing the DNS from the definition:

The domai= n name structure consists of a tree of names, each of which is made of a se= quence of words ("labels") separated by period characters.=C2=A0 = The root of the tree is simply called ".".=C2=A0 The Internet com= munity at large, through processes and policies external to this work, sele= cts points in this tree at which to register domain names "owned"= by independent organizations.=C2=A0 Real-world examples are ".com&quo= t;, ".org", ".us", and ".gov.uk".=C2=A0 Names at which such registrations occur are called= Public Suffix Domains (PSDs), and a registration consists of a label selec= ted by the registrant to which a desirable PSD is appended.=C2=A0 For examp= le, "ietf.org" is a registered do= main name, and ".org" is its PSD.

While I'm here, I suggest 2.3 is = a little terse.=C2=A0 Maybe:

The longest PSD is the PSD matching more labels in t= he domain name under evaluation than any other PSL entry.

> 3.2.=C2=A0 Section 6.1 DMARC Policy Recor= d
>
>=C2=A0 =C2=A0 PSD DMARC records are published as a subdomain of the PSD= .=C2=A0 For the
>=C2=A0 =C2=A0 PSD ".example", the PSO would post DMARC policy= in a TXT record at
>=C2=A0 =C2=A0 "_dmarc.example".
>
> Don't you mean the PSD DMARC record is a record in the zone of the=
> PSD?=C2=A0 It's not a subdomain.

Here's what's in RFC 7489 about DMARC record publishing:

6.1.=C2=A0 DMARC Policy Record

=C2=A0 =C2=A0Domain Owner DMARC preferences are stored as DNS TXT records i= n
=C2=A0 =C2=A0subdomains named "_dmarc".=C2=A0 For example, the Do= main Owner of
=C2=A0 =C2=A0"example.com" would post DMARC preferences in a TXT rec= ord at
=C2=A0 =C2=A0"_dmarc.example.com".

I think our 3.2 is equivalent and adequate given this section is a modifica= tion
to RFC 7489 Section 6.1.=C2=A0 I did not make a change.

Embarrassing.=C2=A0 RFC7489 6.1's text you cited is un= fortunate.=C2=A0 I would change "in subdomains named" to "at= labels named".

But also, why do we need this sect= ion?=C2=A0 The PSD DMARC record is in the same place as one would expect it= having read only RFC7489, correct?

> 3.4.=C2=A0 Section 6.6.3.=C2=A0 Policy Discovery
>
>=C2=A0 =C2=A0 A new step between step 3 and 4 is added:
>
>=C2=A0 =C2=A0 3A.=C2=A0 If the set is now empty and the longest PSD (Se= ction 2.3) of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Organizational Domain is one that the receiv= er has determined is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable for PSD DMARC, the Mail Receiver = MUST query the DNS for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a DMARC TXT record at the DNS domain matchin= g the longest PSD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 2.3) in place of the RFC5322.From d= omain in the message
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(if different).=C2=A0 A possibly empty set o= f records is returned.
>
> Section 6.6.3 of DMARC doesn't talk about "acceptable for DMA= RC", so I
> don't know what "acceptable for PSD DMARC" might mean.
Changed to:

=C2=A0 =C2=A03A.=C2=A0 If the set is now empty and the longest PSD (Section= 2.3) of the
=C2=A0 =C2=A0 =C2=A0 Organizational Domain is one that the receiver has det= ermined is
=C2=A0 =C2=A0 =C2=A0 acceptable for PSD DMARC (discussed in the experiment = description
=C2=A0 =C2=A0 =C2=A0 (Appendix A)), the Mail Receiver MUST query the DNS fo= r a DMARC
=C2=A0 =C2=A0 =C2=A0 TXT record at the DNS domain matching the longest PSD<= br> =C2=A0 =C2=A0 =C2=A0 (Section 2.3) in place of the RFC5322.From domain in t= he message
=C2=A0 =C2=A0 =C2=A0 (if different).=C2=A0 A possibly empty set of records = is returned.

> Section numbers in the prose of this section should make clear which > document they're referencing.

I checked and any reference to an RFC7489 paragraph number that's in th= e text
is labeled as such.

I'm talking about t= he "Section 2.3" here, and the "Section x.y" strings in= the section headings in Section 3.=C2=A0 Since you are pointing back to RF= C7489 frequently, I thought it might be best to say "Section 2.3 of th= is document", or "Section x.y of RFC7489", as appropriate.

Also in the example in the paragraph below here= in the document, you're using ".cctld"; should that be "= ;.example" or ".cctld.example"?

One= final thing: I added a sentence at the end of my proposed Abstract that tr= ies to highlight that domains on the PSL also need to be checked and not sp= ecial-cased when one receives mail from a PSL.=C2=A0 In order to tie it to = the experiment, I suggest this (as a new section at the end; reorder at you= r discretion):

3.7.=C2=A0 PSDs Are Eligible For DMARC

Experience with DMARC has shown that some implementat= ions short-circuit messages, bypassing DMARC policy application, when the d= omain name extracted by the receiver (from the RFC5322.From) is on the PSL.= =C2=A0 This prevents the capability being created by this specification.=C2= =A0 Therefore, the following paragraph is appended to Section 6.6.1 of RFC7= 489:

Note that domain names that appear on the Public Suf= fix List are not exempt from DMARC policy application and reporting.

-MSK
--00000000000020c920058f0352bf-- From nobody Wed Jul 31 20:32:33 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 D9ECD120135 for ; Wed, 31 Jul 2019 20:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh4eW2vlM6yI for ; Wed, 31 Jul 2019 20:32:30 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EAC120131 for ; Wed, 31 Jul 2019 20:32:30 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id c9so49007946lfh.4 for ; Wed, 31 Jul 2019 20:32:30 -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=3mBNLy1Y9uCKKq+I3kmlXcThIsdjuNa79xMrojHpBmc=; b=I2TwVdKZjjVa9yI0uTQB2vcUe5OKT8lz1nhTKr4Mu8dLpkjHH/lrHhY8hWNeUrOVC0 2NqW/is1VhlKvYoevSIKRBk+bFB/Zlz/B4A60603Lp7lvP1RMAQSRsLuhjVoX6jna9qu FGLTK+2+kCN3iuTxJmbn/3WExM+Zp9lJLjcotSXV/u6mk0r+FSDE9UkxAhePaOrTXGqQ ixlSOgFSWo79+QGzuL1oFHq9sIbz7GEeODT58IqrC7MOVBG4zqKhabHuaTSZ0jrh8d/n CHagzztyGO2jQ6OEQIQEOyZV9L5Y5YDT4+/w5LZplM09zJM61WgL30GNHWULAAc/mVRu T/iQ== 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=3mBNLy1Y9uCKKq+I3kmlXcThIsdjuNa79xMrojHpBmc=; b=AiABRyQgnxiweb0Ahm1yHAYoGytPkGCkcu+1Q2KXkvk3So8QHCNeAI3rZ05wTdb67O IUD3y2SeRA96kCpITbytPYP9oZqoPiNd9Sksx8v/UQe/FXEpyRsgIos6CYTKQHehz4Lx ycGUxz2sEYPPBTfAFy9hvBWXQSCVS8+I0PRf8UyTDnP2Kz1W7EfSJtvPL5tDEO+VQZIP e4+Dmc9kSzHvnjc5DGcADHIt9esJ00/SRn0mPvy3aJUXusR6660RXXF8Ewq4BVhuZ7he AxNUTpTS2q2TV4kDPZO3sexWmrfUbv4TiOm2qTFoQ70mv2QbrP42/QM7YSjjXInavsD4 bevA== X-Gm-Message-State: APjAAAWqFB1+uuFKpC7jv+Etn4/0pPWl1E2K7Ex6IZHj1kdvz9i3x4LR qSBwOzUAwz7B1TkXsXHzLOrw1sc4HajdChxy26A= X-Google-Smtp-Source: APXvYqz9DWis5FDtUyIxlLctrycILLjuSDBOYve1nCDX0KiDGoeDZxym69jGbfVPtVjDrzhl4ZvJ6VE69kqSgCNfJzg= X-Received: by 2002:a19:7006:: with SMTP id h6mr58903657lfc.5.1564630348295; Wed, 31 Jul 2019 20:32:28 -0700 (PDT) MIME-Version: 1.0 References: <0295aa1e-733a-b3ae-14cb-edcb2050d6af@corp.mail.ru> <36cba315-e738-ddec-0f6c-2e6086b69d11@corp.mail.ru> <70da228a75b94c28097ce0c25bc407d93e86c4c2.camel@aegee.org> <1951EFA7-0695-4B98-9CB1-3ECCEFEBF321@wordtothewise.com> <7DFCE75A-4D31-4DEF-BD12-F161EE8D2CA9@wordtothewise.com> <92880e84-be6d-302c-dd6e-0768638ee54a@tana.it> <88795b092c9d32bcaf49a4c02ead802dc3c22753.camel@aegee.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 20:32:14 -0700 Message-ID: To: Tim Wicinski Cc: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , IETF DMARC WG , Alessandro Vesely Content-Type: multipart/alternative; boundary="0000000000001d7185058f05e4fb" Archived-At: Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:32:32 -0000 --0000000000001d7185058f05e4fb Content-Type: text/plain; charset="UTF-8" On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski wrote: > From our end user point of view, I'm against abolishing quarantine, even > with its current shortcomings. > Why's that? -MSK, also hatless --0000000000001d7185058f05e4fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 28, 2019 at 6:37 AM Tim Wicin= ski <tjw.ietf@gmail.com> wr= ote:
From our end user point of view, I'm a= gainst abolishing quarantine, even with its current shortcomings.
=

Why's that?

-MSK, al= so hatless
--0000000000001d7185058f05e4fb-- From nobody Wed Jul 31 20:34:46 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 72F28120136 for ; Wed, 31 Jul 2019 20:34:44 -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 2MfmyTRA_5dp for ; Wed, 31 Jul 2019 20:34:41 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6568A120131 for ; Wed, 31 Jul 2019 20:34:41 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id c9so49010904lfh.4 for ; Wed, 31 Jul 2019 20:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4hiEqBriTgOmYWgDCDO7VgvdFDViFuy2FXY5r/5eCHM=; b=nnZg8P5Ur1lklGvLSiSO8cVeC8JvlOIYWNZHPDphw4RGjqWJshPW7Ldh+njZ2Yt6QK 8cK+5MlhrwgzwrZLDybrPjTfnlUKD+cj9p7BvYdo3lE/lHBKU3HluV1SRRrhmSdQ9qEM CMWjZ4kLIhy1mcjKUJLc68Y+lbYv90yt1WCvQhIzatmt9BUywMFqYD3p/Zk6BkXpyEez vQK5YzG3w5M10YQcpLfBXI7sJC4iExHioguK4uz+InZyekDt+ChcF5nDumCgZkMCGX9P edo6h2Jzuyau7XysSBf+Rit012gDYqhppsZKoPi+hIQMmqfKXgGUckzOT2g9+Pwx1x6j Gm4A== 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=4hiEqBriTgOmYWgDCDO7VgvdFDViFuy2FXY5r/5eCHM=; b=PdEgrf21rbuXAs8JS5xFeS8uw7tkfHcniPSs+nkalrXh/RFs9wGhYfmhaGs5QyvdUF pWwXHgME8LpMz+A6c+eZysE7+YrKEGDQF7EcWp39e5U1w8ezKas8CANHLzyT3/KF1LAk qiKayRIScmhIKFQ2cNm+V0Sbx5C+X4jROYNKUxapeBLfk35vY2/4uoa2HX53Aol2IEzz /6Q4nlUUf/nIOmz0eKWthKwufoSzNI0rzfMLNUmJoQmOaKNevQMVJNfYZ89ilK7xCbmK Lqh+g9p1KE7fQG3/Snzqq7YIBiyNUqfBeAKELpJcXNOTJsFERzh/qwJeUEZRZ3p9xzSM mvrg== X-Gm-Message-State: APjAAAVmMCMqev4nSJEH/04DZ1ut2k6BGAclUYEZVO6zN4+aTjNBpG2z FTGrSYulQUL9c9Kf17zbcAySSSrgZTtPDJcp83RqAA== X-Google-Smtp-Source: APXvYqwXiiWJf/m3G03hVumDeIwxP45edA+2Hpe9E8L/AvoGHE6v8mLUuO59hpOrH4ymlU59CugrBdk0KLg43TvIcXI= X-Received: by 2002:ac2:4a78:: with SMTP id q24mr16483573lfp.59.1564630479572; Wed, 31 Jul 2019 20:34:39 -0700 (PDT) MIME-Version: 1.0 References: <187a4f8129f624d5590b553aff40489c8d24fb97.camel@aegee.org> In-Reply-To: <187a4f8129f624d5590b553aff40489c8d24fb97.camel@aegee.org> From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 20:34:25 -0700 Message-ID: To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f09255058f05eb43" Archived-At: Subject: Re: [dmarc-ietf] if policy quarantine will be kept X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:34:45 -0000 --000000000000f09255058f05eb43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2019 at 7:29 AM =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0= =D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > if policy quarantine will be kept, I propose including this text in the > specification: > > Messages, subject to the quarantine policy, directed to a single recipien= t > that does not support the concept of > quarantining, can be either accepted and delivered, accepted and > discarded, or rejected. > > Messages, subject to the quarantine policy, directed to many recipients, > some of which support the concept of > quarantining, and the others not supporting this concept, can be either: > * accepted, quarantined for the first group of recipients and discarded > for the other recipients, > * accepted, quarantined for the first group of recipients and delivered t= o > the other recipients, > * segmented or > * rejected as whole > Doesn't this, as proposed, require different receivers to know each other's capabilities? -MSK --000000000000f09255058f05eb43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2019 at 7:29 AM =D0=94=D0= =B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 <= dilyan.palauzov@aegee.org&= gt; wrote:
if policy quarantine will be kept, I propose includin= g this text in the specification:

Messages, subject to the quarantine policy, directed to a single recipient = that does not support the concept of
quarantining, can be either accepted and delivered, accepted and discarded,= or rejected.

Messages, subject to the quarantine policy, directed to many recipients, so= me of which support the concept of
quarantining, and the others not supporting this concept, can be either: * accepted, quarantined for the first group of recipients and discarded for= the other recipients,
* accepted, quarantined for the first group of recipients and delivered to = the other recipients,
* segmented or
* rejected as whole

Doesn't this, a= s proposed, require different receivers to know each other's capabiliti= es?

-MSK
--000000000000f09255058f05eb43-- From nobody Wed Jul 31 20:37:08 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 0E3A6120135 for ; Wed, 31 Jul 2019 20:37:07 -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 OB9fRLTogvmv for ; Wed, 31 Jul 2019 20:37:05 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26457120131 for ; Wed, 31 Jul 2019 20:37:05 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v18so67786424ljh.6 for ; Wed, 31 Jul 2019 20:37:05 -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=RoIKyNpWEvm5OSialk1POqef3I67rBQOfKjXXSpuEEQ=; b=lEu0OCJuT0aimHGfXszG/j8wHlp+ZlUgfSUf6Fq8cjhmUOSm+73xIrOyoIwdjhfRUh MPKzP8kSS3wJC3vIz67zVEx6vzMEbSCOwazAlp3py+mRtYHQnCGu2F0s+CS/gXqoKxJi p6jtRG4IDu6zotBe1ii8TIQYYaN/f7ePGR3V1BjD660ZTd20b9TOjDbRDx1vQA2BSEF4 qHQV/DvFBV6KBExOGI7lls82kOZnUNqd/+pihBbBtA4/V0m4v4mBn/XMIKj7rLS9AajS 0R2wTLruRgCE3FEVFzpH9Q7hr0RRY7QG9qEmPRwNVrDBxA8bnbz2iR4kwgDjeFFE5xOw d1mg== 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=RoIKyNpWEvm5OSialk1POqef3I67rBQOfKjXXSpuEEQ=; b=tVdruy4F6AU29Vy7v7JqI64B90DnZwt6vyi1VvO+V0h/gFsyRJRmwBD/irW8XoHcZY ExKkMhBcCk6/xg80iUQGqF9gEWRymiAQ3bj5CSE5y6BlX5grE33IbDZkmRGT2zDA5ZMp rLRyQp4yBQs4lMYXQ7p02xEbpqH1VQY/CjCpISiKpcwhg5Tbx8N4hp1+XXM7vLSTeZKV 3EWKVfAui1D5mY1e+MMyXGcJwTZulIDTC3YOx5bg2P2ZCMeyPiS60lduzFg2x/Kb+NcE vGH/Abw663gXl8KsJxL9Tyxi0LFXFAPLyopleE1T1OujIxb5vVsThKWlCv5fvJ+ZgOmt Wasw== X-Gm-Message-State: APjAAAWSXY58z/I8YXmnqpUVNKSYiJvuu7y8jJbtGGB1/A2I1eL2fCp7 dNX0YA/ZoYWVRhcVlxtKsmKYC1pIvnBi+rDvad/chg== X-Google-Smtp-Source: APXvYqzQLH6/9QVoZ85mfgHSRGAwhgL7JRGnKJzjjVVVnDtOU02M2FmUTZYPGin1IbZradqFOHbV2cPrfG/JYkRJBZw= X-Received: by 2002:a2e:988b:: with SMTP id b11mr65500612ljj.110.1564630623256; Wed, 31 Jul 2019 20:37:03 -0700 (PDT) MIME-Version: 1.0 References: <2577720.3ZthdXZjm2@l5580> In-Reply-To: <2577720.3ZthdXZjm2@l5580> From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 20:36:49 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000810629058f05f4d7" Archived-At: Subject: Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:37:07 -0000 --000000000000810629058f05f4d7 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 29, 2019 at 12:38 PM Scott Kitterman wrote: > I'd like to add the option to record DMARC results in an A-R header field > for > consumption by a downstream processor. I think it would be something like > this: > > Authentication-Results: mail-router.example.net; dmarc=pass > header.from=example.com policy.dmarc=none > > That would take adding an entry in the Email Authentication Methods > registry > for: > > method: dmarc > ptype: policy > value: dmarc > > Does that make sense as a way to do it? Does anyone have alternative > suggestions? > This seems sane to me, or at least neither an objection nor a better idea came to mind. :-) I concur with whoever disagreed with doing it in comments as a normative thing meant for downstream processing. IMO, comments in header fields are meant for debugging done by things in meat-space. -MSK, hatless --000000000000810629058f05f4d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 29, 2019 at 12:38 PM Scott Ki= tterman <sklist@kitterman.com> wrote:
I'd like to add the option to record DMARC resu= lts in an A-R header field for
consumption by a downstream processor.=C2=A0 I think it would be something = like
this:

Authentication-Results: mail-router.example.net; dmarc=3Dpass
header.from=3Dexample.com policy.dmarc=3Dnone

That would take adding an entry in the Email Authentication Methods registr= y
for:

method: dmarc
ptype: policy
value: dmarc

Does that make sense as a way to do it?=C2=A0 Does anyone have alternative =
suggestions?

This seems sane to me, or = at least neither an objection nor a better idea came to mind.=C2=A0 :-)
=

I concur with whoever disagreed with doing it in = comments as a normative thing meant for downstream processing.=C2=A0 IMO, c= omments in header fields are meant for debugging done by things in meat-spa= ce.

-MSK, hatless
--000000000000810629058f05f4d7-- From nobody Wed Jul 31 20:47:44 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 7456B120136 for ; Wed, 31 Jul 2019 20:47:43 -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 6Pzv1Sc1ignA for ; Wed, 31 Jul 2019 20:47:41 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F9012003E for ; Wed, 31 Jul 2019 20:47:41 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y17so43290876ljk.10 for ; Wed, 31 Jul 2019 20:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iiD7XnweQ9E7z2jzpjHuC1gQ9X2Bafixx/Gxb2vetGo=; b=lTDcjGDciaZuupg2elkVYf/twVo41ttdrNRzY97yNwaOtxAXFkjJx8e6/IyHgod3+w Mmy9IjttprNIo8iIOfIj8DP62Qrv2K6FIbFwZIFIaD2lf31mmoSLourS0cGu2TCT2/vv TaY4RqcvvVDw2t+frwm6CF6oE/zJarKUmB/jJL8f3aj7Nyx50Lvj/BSjDWoQb3i4vbUB XuvGQE9YIZBQf2oXQI7gd33jYuNAaAbXrJqpq9YiwqQJKslG8eoH0oOE1nnyTcCNCle3 3H+/Ga47YxcwGt5bsY0Sr9fYNscrFdq3P4shMDE75LSHwKmFPzdkrkJMmUkIeNzsvYbX XQiQ== 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=iiD7XnweQ9E7z2jzpjHuC1gQ9X2Bafixx/Gxb2vetGo=; b=CnrOxUg2x4F/+vwObRViZpbAKRdjmBjr6SL7Hj4wp1NXUQddpXz8/DtosJNq0+02RR Lnb7nxi52Dp5gZSpMC5QUO3Y8dtBmAWYFnXnfxbnqAv+1SLwj179CzdvMCczM/1jfDIf JMg+edcT3w2YMmq34TC45CzK3Et7Oc8XjHTmlvnzOz9iOZK7L83psiNCmwJ4oHI+ZM5e ho6MqhQ41j7hkNe98e4zv72NIhuC73X/15XqkECWy3wxdCC3LR+JvdQ7jOBpdy50J3VC jjhqGx/aiiOgPisHSh5yZPdVSryX6DVuRhZGIBC8QvAXo/q6NQEIyRHWKk81lrc1Vr24 MOow== X-Gm-Message-State: APjAAAU+FkLNL1RNYUymqI0rSjZU270OkVFOplDaUM/MMS94kRHFMgyO h+4AV7mi6vd0CdKu/hRcAFa8y7QiQ3nkGeTnurv26Q== X-Google-Smtp-Source: APXvYqx+RVP1fWYSwU3p55yg6qdrzsXPvT7REmE/TRXfXak7wVfAgH5lD2aexP/o2wBYnhqwYUHQ/3Ag81yAYzpNiRc= X-Received: by 2002:a2e:9250:: with SMTP id v16mr65742199ljg.89.1564631259606; Wed, 31 Jul 2019 20:47:39 -0700 (PDT) MIME-Version: 1.0 References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> In-Reply-To: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 20:47:25 -0700 Message-ID: To: Freddie Leeman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000006ef238058f061a61" Archived-At: Subject: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:47:44 -0000 --0000000000006ef238058f061a61 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 7:58 AM Freddie Leeman wrote: > 0: Generate a DMARC aggregate report for every message, regardless of its > alignment. > 1: Generate a DMARC aggregate report if any underlying authentication > mechanism produced something other than an aligned "pass" result. > > d: Generate a DMARC aggregate report if the message had a signature that > failed evaluation, regardless of its alignment. > > s: Generate a DMARC aggregate report if the message failed SPF evaluation, > regardless of its alignment. > Do you want to include an option for selecting based on the ARC result? You called out DKIM and SPF individually, so I wonder if this is something worth including. -MSK --0000000000006ef238058f061a61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019 at 7:58 AM Freddie L= eeman <freddie=3D40l= eemankuiper.nl@dmarc.ietf.org> wrote:
0= : Generate a DMARC aggregate report for every message, regardless of its al= ignment.

1: Generate a DMARC= aggregate report if any underlying authentication mechanism produced somet= hing other than an aligned "pass" result.

d: Generate a DMARC aggregate = report if the message had a signature that failed evaluation, regardless of= its alignment.

s: Generate a DMARC aggregate report if the message failed SPF e= valuation, regardless of its alignment.

=

Do you want to include an option for selecting based on= the ARC result?=C2=A0 You called out DKIM and SPF individually, so I wonde= r if this is something worth including.

-MSK
<= /div>
--0000000000006ef238058f061a61-- From nobody Wed Jul 31 21:40:23 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 338D1120137 for ; Wed, 31 Jul 2019 21:40:22 -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=yhte9MgZ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=DUIIx0co Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtF6q4PQb1IS for ; Wed, 31 Jul 2019 21:40:20 -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 7CE4512003E for ; Wed, 31 Jul 2019 21:40:20 -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 5F698F805F8 for ; Thu, 1 Aug 2019 00:40:19 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1564634419; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eYByPcGN5DXAKlQyaEN1VcdJovaZ8bDOZptdYDOtIDk=; b=yhte9MgZ6tI8PmliM9paxEAfiGnXjx1xtYzrO5NdHo9rKt0Je09lnjP6 3NfUO9WzqVJs5yjWUz1PS5jSRheGAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1564634419; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=eYByPcGN5DXAKlQyaEN1VcdJovaZ8bDOZptdYDOtIDk=; b=DUIIx0co7boJ8t2WL48bVrAO1RKCTcufvCZIkpVzk7OrO/ke6mBxcdLm QYTxOQNtGsAv/sm2UigFohWhJtyRCjr+L2J1PuFCJmvVA/vGZlSLPKWkwh 2pzKf2Bs5mQxqvB6NERZLsADJbVVP7aRApKOvPQASm6+pHaKyW0Opvq6UC 7Us2nCPG59+oooRxdnZLdjsu4KjnFW+OON/xtgJ+B9KlJCWKKImPBpYuR7 nA1FPslEl5PGQAljFPMXgj5EE57cCzIne1Ufnk9umeWDtDAsusXJ8mwoLG 2LJm7Ovg9XSGRWt6IxKf3lt4LWCtAr+Ws7LQfYSVFr7vIs2O19XqNw== 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 23669F80208 for ; Thu, 1 Aug 2019 00:40:19 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 01 Aug 2019 00:40:18 -0400 Message-ID: <4783309.BXR8ZdE9c3@l5580> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 04:40:22 -0000 On Thursday, June 27, 2019 5:10:39 AM EDT Alessandro Vesely wrote: > On Wed 26/Jun/2019 22:27:46 +0200 Murray S. Kucherawy wrote: > > On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely wrote: > >> Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's > >> reject-on-fail. The score attributed to the sender by a trusted DNSWL is > >> also useful after DATA, thence the need to store that value for > >> downstream filters.>> > >> However, as an authentication method, a DNSWL TXT response can provide a > >> domain name, which is possibly aligned with From:. In that sense, this > >> method might be of interest for this WG. Probably not, but I felt > >> compelled to make sure before trying independent submission. (Already > >> tried ART.) The I-D is here:>> > >> https://tools.ietf.org/html/draft-vesely-authmethod-dnswl> > > With my Designated Expert hat on and co-chair hat off, a procedural point > > here: > > > > The IANA registry for these is Expert Review, which means you don't have > > to > > publish an RFC to get it registered. You can, but it's not necessary if > > your registration request can sufficiently describe what you're doing. > > See > > RFC8601 Section 6.2, fourth paragraph. > > I just submitted the form attached. This path seems to be quicker. Thanks. > > > Let me paste the parameters, for list readers, and point out that dnswl can > yield a domain name like, e.g., policy.txt=example.com. Whether the domain > name alignment can be meaningful or not is the reason why this topic appears > on this list. ... > > | ptype | Definition | Description | > > +-------+------------+----------------------------------------------+ > > | dns | [this doc] | The property being reported belongs to the | > | > | | | Domain Name System | Can we discuss this choice? I know this has been implemented already, so I'm at least slightly reluctant to do the semi-standard lets rename existing stuff dance that the IETF often does, but I really don't like this. There isn't an email authentication system out there that doesn't rely on DNS. I think DNS as a ptype is way too broad. Also, if I rsync a copy of the list and process it locally, is it still OK to use the dns ptype when there is no DNS involved? What about something like extpolicy: The property reported relates to an external policy input? Would you be willing to do something like that? If so, I think we could also register dns, but with status of decprecated since it's in use and documenting in use stuff is good. Then Courier can change at some point when it's convenient, but still be using a registered paramet. Scott K From nobody Wed Jul 31 22:27:31 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 01B9A120026 for ; Wed, 31 Jul 2019 22:27:31 -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 9Kt1c1ipw4OQ for ; Wed, 31 Jul 2019 22:27:27 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6711412000F for ; Wed, 31 Jul 2019 22:27:27 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id i21so68042389ljj.3 for ; Wed, 31 Jul 2019 22:27:27 -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=NJI3DgqvOmPoMeAUTmMSHqKBui0sCh3MtDixQwOuP1o=; b=BRYfO4ZuqUKnaUtcH2w5x3mqEG6IC2oRjrMNRppzBmpXaiWyYhmkPuTWToMnzBLaZe CuCg/cCbpvJOWspJHYfeB3PR9b+iQBV+zLHK9qxcOB/54oqfjOV6h70soLxk3Uf0pWzl f2+DCZuiuqkfYVL46N/neT9TAKCHw9WjscK/NOjw/eTRfrKm4oLbuJVKG28B7KqMKus9 CcWiyziWdF0F66ledVpoKwGt5K0wQQD2ftt4PkttDCdmD6GUhwyqq++FkdwG9gGHo01R r+FHs/8d9u5/ds0wD4K023Ke6WOLy2hhmOEpxjQCqSacBzQyWrOoetIMXcFWXxtvzb++ 1ZmQ== 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=NJI3DgqvOmPoMeAUTmMSHqKBui0sCh3MtDixQwOuP1o=; b=qlibXeZWdA/oObHefXHj2leYhIzp8qcfE6y9MlqUxILNXUZSRm9shod7yprV54AuxX B19Qi4ck8hvpCNJigQUCxluCQvHpv9xNoJc1MghQHwBhGFXJcFFfsn2Ns3VZfgZ4mZGG TGvpbRQu9WbgCL64PhURIftwfYYSYftDn7n/rhEJdPwpXgae1nZo9pMmM83QJTp9Ng98 sM2l29187iXga68k2daMEzDyYNpIgmQ/FXTDrVfXEMkkwyeHhK+IJ8rrUBvllP5zjvWR eVDmveZuz7wLlOoFga8FEyHphrEGqTiHl8QdSc8w3PrNU0wIaQnqS1uoGHQep6rP9Gw6 E5xA== X-Gm-Message-State: APjAAAWmwYIwn9mKnLM36l7N2/fiIH75BsGCG8mO4/hsJ6DV1hakndsZ uH7LwZs3pJG+STBvk4JEqQx9/VPU+qikYfMhZBg= X-Google-Smtp-Source: APXvYqyKPgo5oJRiddwJyt/IkBQJZFJ+ySL6FsRwklzZ16K0v8Tg8ewpYjlQ/2V0hnPMOnlyzrTjHrJUHTswVDnUL08= X-Received: by 2002:a2e:870f:: with SMTP id m15mr66737820lji.223.1564637245586; Wed, 31 Jul 2019 22:27:25 -0700 (PDT) MIME-Version: 1.0 References: <4783309.BXR8ZdE9c3@l5580> In-Reply-To: <4783309.BXR8ZdE9c3@l5580> From: "Murray S. Kucherawy" Date: Wed, 31 Jul 2019 22:27:10 -0700 Message-ID: To: Scott Kitterman Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000039c0a2058f077fc8" Archived-At: Subject: Re: [dmarc-ietf] New authentication method, DNSWL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 05:27:31 -0000 --00000000000039c0a2058f077fc8 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman wrote: > Can we discuss this choice? I know this has been implemented already, so > I'm > at least slightly reluctant to do the semi-standard lets rename existing > stuff > dance that the IETF often does, but I really don't like this. There isn't > an > email authentication system out there that doesn't rely on DNS. I think > DNS > as a ptype is way too broad. > > Also, if I rsync a copy of the list and process it locally, is it still OK > to > use the dns ptype when there is no DNS involved? > > What about something like extpolicy: The property reported relates to an > external policy input? > > Would you be willing to do something like that? If so, I think we could > also > register dns, but with status of decprecated since it's in use and > documenting > in use stuff is good. Then Courier can change at some point when it's > convenient, but still be using a registered paramet. > Thanks for commenting on this. I'm overdue to provide a review and feedback. I rejected this application prior to RFC8601 primarily because the language used then to restrict what goes in the registry didn't allow for registrations of stuff that wasn't actually part of the message, and a DNS whitelist or blacklist result is not (nor for example is the client IP address, or the result of any query entirely external to the message body, header, or even envelope). The good news is that the language of RFC8601 is more relaxed, in particular in Section 2.3 it allows for a property/ptype that covers "some other aspect of the message's handling", so that's no longer a blocking factor. To counter Scott's point, "dns" is a ptype that would exist within the method of "dnswl", so I think it's hard to see how it could be misinterpreted. But I'd like to see how this discussion plays out. I can see his point about "dns" being a rather broad ptype. Appendix C of RFC8601 goes to some length to discourage the practice of including all the details that were inputs to the evaluation, specifically because the result of the evaluation at the border MTA is the only thing that should matter. I thus have some trouble understanding why "policy.ip" and "policy.txt" are desirable things to include. And even if that were not true, I'm concerned that "policy.ip" could be interpreted as an IP address even though that's manifestly not what this is. Nevertheless, Scott's point about documenting current use is well taken and I like his idea in principle. The only concern I have is that allowing this directly into a "deprecated" status still reserves the name "dns" should anyone later devise a use for it that's appropriate in breadth. I suspect though we could just ask IANA to register both, one deprecated and one current, should that somehow ever come to pass. Alessandro, others: Comments? -MSK --00000000000039c0a2058f077fc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019 at 9:40 PM Scott Kit= terman <sklist@kitterman.com= > wrote:
Can we discuss this choice?=C2=A0 I know this has be= en implemented already, so I'm
at least slightly reluctant to do the semi-standard lets rename existing st= uff
dance that the IETF often does, but I really don't like this.=C2=A0 The= re isn't an
email authentication system out there that doesn't rely on DNS.=C2=A0 I= think DNS
as a ptype is way too broad.

Also, if I rsync a copy of the list and process it locally, is it still OK = to
use the dns ptype when there is no DNS involved?

What about something like extpolicy: The property reported relates to an external policy input?

Would you be willing to do something like that?=C2=A0 If so, I think we cou= ld also
register dns, but with status of decprecated since it's in use and docu= menting
in use stuff is good.=C2=A0 Then Courier can change at some point when it&#= 39;s
convenient, but still be using a registered paramet.
<= br>
<designated expert hat on>

Tha= nks for commenting on this.=C2=A0 I'm overdue to provide a review and f= eedback.

I rejected this application prior to RFC8= 601 primarily because the language used then to restrict what goes in the r= egistry didn't allow for registrations of stuff that wasn't actuall= y part of the message, and a DNS whitelist or blacklist result is not (nor = for example is the client IP address, or the result of any query entirely e= xternal to the message body, header, or even envelope).=C2=A0 The good news= is that the language of RFC8601 is more relaxed, in particular in Section = 2.3 it allows for a property/ptype that covers "some other aspect of t= he message's handling", so that's no longer a blocking factor.=

To counter Scott's point, "dns"= is a ptype that would exist within the method of "dnswl", so I t= hink it's hard to see how it could be misinterpreted.=C2=A0 But I'd= like to see how this discussion plays out.=C2=A0 I can see his point about= "dns" being a rather broad ptype.

A= ppendix C of RFC8601 goes to some length to discourage the practice of incl= uding all the details that were inputs to the evaluation, specifically beca= use the result of the evaluation at the border MTA is the only thing that s= hould matter.=C2=A0 I thus have some trouble understanding why "policy= .ip" and "policy.txt" are desirable things to include.=C2=A0= And even if that were not true, I'm concerned that "policy.ip&quo= t; could be interpreted as an IP address even though that's manifestly = not what this is.

Nevertheless, Scott's point = about documenting current use is well taken and I like his idea in principl= e.=C2=A0 The only concern I have is that allowing this directly into a &quo= t;deprecated" status still reserves the name "dns" should an= yone later devise a use for it that's appropriate in breadth.=C2=A0 I s= uspect though we could just ask IANA to register both, one deprecated and o= ne current, should that somehow ever come to pass.

Alessandro, others: Comments?

-MSK
--00000000000039c0a2058f077fc8--