From nobody Thu Dec 6 09:40:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA768130ECF for ; Thu, 6 Dec 2018 09:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIrY2X4Ydh_Z for ; Thu, 6 Dec 2018 09:39:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B120130E86 for ; Thu, 6 Dec 2018 09:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1544117996; bh=CMj/5B5k2zLiQcCv06DLX4k0USamjozvIegfrr5ZGjo=; l=552; h=To:References:From:Date:In-Reply-To; b=AJ41fB6MuPYy9+s4A8D+IeUsSqTBezOtf3kHXIbokGYehemFRDY18c4idV8weOkai Vq8YoOrLYvQDJHX2VTp3npdTBHgOcLpwNMq8C4TOFtd80E9jfQRFqIU8+BvhC7nbhs 9a50EAral/ogH10J1GUNnnvLPbRDbPcmBGXFGZ61na4Mbd/T2Y7Dju4S7ARJj Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 06 Dec 2018 18:39:56 +0100 id 00000000005DC008.000000005C095EEC.0000768D To: dmarc@ietf.org References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Autocrypt: addr=vesely@tana.it; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bub Message-ID: <3e304d8f-ffd1-296c-c327-32f8e6b3ee6e@tana.it> Date: Thu, 6 Dec 2018 18:39:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 17:40:00 -0000 On Sat 01/Dec/2018 02:27:54 +0100 Scott Kitterman wrote: > > Perhaps we need to step back and see if there is consensus that the privacy > considerations in the draft are substantially correct and if risk mitigation > is needed as described. How about expanding on this: On Sat 01/Dec/2018 00:37:24 +0100 Scott Kitterman wrote: > > I don't think wide open TLDs like .com ought to be stimulating feedback on > any lower level elements of the DNS tree. IMHO, statistics derived thereof would be an interesting read. Best Ale -- From nobody Thu Dec 6 09:48:11 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3711D130E6A for ; Thu, 6 Dec 2018 09:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=S3iQVWEY; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NFLLzVAa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvtvZqrtoyQ5 for ; Thu, 6 Dec 2018 09:48:07 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDDD12870E for ; Thu, 6 Dec 2018 09:48:07 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1544118486; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=uf0h/f8Rk5t/WhEsINs5y+yKkRNcH1ne76mS2A9Bogs=; b=S3iQVWEYGtDugbvFi7AOiuKAzFjNFM1RTcHHeA55yFdHwLEuEWxX7+ZD Zbym2eZ4A0JlCdrJCWImLMFU5ypADA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1544118486; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=uf0h/f8Rk5t/WhEsINs5y+yKkRNcH1ne76mS2A9Bogs=; b=NFLLzVAaGdgoKqYMfZvSONvz8k1lUV0UMqm3En44Q09iMumJ+XfAlIYi tSM8BYQD1IlAZ8w36NwmlJl4lAdame/Fc4saZvIUcD/piQyyMgwj2rQpxU 9ncdaCxoUd/W5Zog5t8H+AFRkiq2IA4BUuyeaQbfz+NGBnNL7YmR64v86+ 3nA+04NFSCPyr2D9CUUwYuJRoyd2a0uJRhs0i7rTccPIE/JwG/mJ9LAipp ckB1qw5y1E68qT9pUkWhUAH+NtvP0wxABws3MsTPKelaId+C/jtfSgx5j0 p2X8VkFuUah062cXwUhue+6f0hCvlMuW+uVA5rM77RbOYVgHXJ4iqw== Received: from [10.231.76.228] (mobile-166-170-34-81.mycingular.net [166.170.34.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 062F8C400F8; Thu, 6 Dec 2018 11:48:05 -0600 (CST) Date: Thu, 06 Dec 2018 17:48:00 +0000 In-Reply-To: <3e304d8f-ffd1-296c-c327-32f8e6b3ee6e@tana.it> References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> <3e304d8f-ffd1-296c-c327-32f8e6b3ee6e@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: <1E1748C7-2208-412F-9511-2468F9476376@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 17:48:09 -0000 On December 6, 2018 5:39:56 PM UTC, Alessandro Vesely w= rote: >On Sat 01/Dec/2018 02:27:54 +0100 Scott Kitterman wrote: >>=20 >> Perhaps we need to step back and see if there is consensus that the >privacy >> considerations in the draft are substantially correct and if risk >mitigation >> is needed as described=2E > > >How about expanding on this: > >On Sat 01/Dec/2018 00:37:24 +0100 Scott Kitterman wrote: >>=20 >> I don't think wide open TLDs like =2Ecom ought to be stimulating >feedback on >> any lower level elements of the DNS tree=2E > >IMHO, statistics derived thereof would be an interesting read=2E I'm not sure I understand? How much would be okay? Scott K From nobody Thu Dec 6 10:45:31 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DD5130F15 for ; Thu, 6 Dec 2018 10:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYRYBzLQiu-A for ; Thu, 6 Dec 2018 10:45:12 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577241200D7 for ; Thu, 6 Dec 2018 10:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1544121910; bh=pBpVYYsdTtInzXNVnDWVrP5itILpL99cZ/7Um8Jb26Q=; l=2330; h=To:References:From:Date:In-Reply-To; b=BltaiazfdmlTl4oDfWHRceHUX7CJvrhQ5o1IN/Uu83GGaN8yErFUzXbMcC33Xhd9z 3j/9UWVOJM0sCxfPS6dl1kRI5m2caqHQC9dzRLO8wz0eAzkCg+ZtXnrSrZORGdYFb7 lacsoFmcDFQY29R8FhkDmMz99MxHfJzYRH2wj9PkPn1CDMOlUdOt96ydEkpvS Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 06 Dec 2018 19:45:10 +0100 id 00000000005DC013.000000005C096E36.000004C8 To: dmarc@ietf.org References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> <3e304d8f-ffd1-296c-c327-32f8e6b3ee6e@tana.it> <1E1748C7-2208-412F-9511-2468F9476376@kitterman.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Autocrypt: addr=vesely@tana.it; prefer-encrypt=mutual; keydata= mQGiBERgr1sRBACwT8eXxGVWwVO+TvHEcvIe2nNlefi05FabcYoPkiVouDtbErExjoCK7FdM BRz+KjZcC8flOJmFR6rn48jcvgIZoCo0V5JuhgYFI2pWO17e6vECutHK09mnt5kLG/RwbiTZ cP8gjZtstH//Ff5x7hfQ9gSl7E/8flSV1Z0VOrJOBwCg7UPuSxYYPeHisH2L81LzR2gHUxME AKotfy9AoW5L1O9OSoIrBHzfevpA/fiuWWyV+6M887vfPCV6amZi2D5qaib89nce2H8g+9xP dppfccNlgekp0Qh3j7HKUy5WLCfz7b8Gpl5VYu2C7qhltiKBcK79gQnUDjB5zBHXgS0qLhJK YWEooQdIfFeNMYWPIp82J6i+QvsRBACG0eycR4HCRHQvw3vEnwSbRKs5YQlZjJJRSy9lA6U/ uF0bHXw9hrZervYZ25KSI5iFFNczwPkE3gKiTKabErSeBGqDS3q1QgZ1wKhQIGEgWuPRih0J KRdgFBVCWnfZ2UZY1ZpQ01raurYY/nYX4dquh8vA/PuFr/Y3dnbeHdvC0bQiQWxlc3NhbmRy byBWZXNlbHkgPHZlc2VseUB0YW5hLml0PohZBBMRAgAZBQJEYK9cBAsHAwIDFQIDAxYCAQIe AQIXgAAKCRC2rPREkNF8ABRIAJ9hqzo3j2eP4DCkkQa/BViMvvyQLQCeJnHZBThL90if5HmP trzr/BTXoIG5AQ0ERGCvbxAEAI0puriz27jNGsUhWuOyv7M6jChanXFIhMHKXR/3Bfi1YMj5 I2ki4V24k+PIAUXs7K8Yro5KTRcyZyJFaeFjsNwruPlgGCu7ZYvmsGDOgH6vjFv8aDgvujCn 3OQdBSygtylihlQUHFyQkRCjBp0EM2DE96+ulSitqzuZCaDl6e1HAAMFA/wIWsRwIE5kh4zE LlxNfa+fSirrQcniW95XSBAcUymS9GLlqcp2GqoJSYXTmspaVa27rMqrthtytvAEdY2D9KYt GtjajcQhYJQ612sVLwrVnqITeyg+L7b2s4m73gVx+X824dDEsoJldirH9LaZNRulTnUD1wcW Ey5G7kj0LykDLIhGBBgRAgAGBQJEYK9vAAoJELas9ESQ0XwAqgIAnjK+fFoGeBqyh6nuGqho obid1JbfAKCC5mETnzHYaw/Xk4rCcthv7AC5JLkBDQRYw+3UAQgA7M19L6F7IawBKQaxIx/f akrp1++lrbo54xFc4y2aHbGfhNkVGdMyKCZVkbZbAacW9j8As4g1xpqkOGeZ9/mDzATyEVew HKJtxkgZSUwkoVjcPIC/564NLJrAihZ2tPQdlsakIOPRy7NCVlNt3ziZojKLyPTHzh22jcdv Bv6PbPuVw3MbrfJbV1Hd7AQz8aPGSgs+Tit8EeGpXhZotd27ieSzM8FnHNu+skf5GrXSe8kZ keQdG3587E2n2BvSdGlSjtsQKmuUgAvrPVkIb9iPAzM23T0mj3k6t3iU57TcwIqdolTOUaB8 WjU2nTs+Jm+4d2UmP0fYLAoBHyxzV2PU/wARAQABiQFoBBgRAgAJBQJYw+3UAhsCASkJELas 9ESQ0XwAwF0gBBkBAgAGBQJYw+3UAAoJEA4nko8kG00g474H/204JJD4Ohqvs9Vdv8SLkesr ShXqqYsEhPcsjNwMIY23HXuIxpZbn2/BPOjpHAYprJPmS+tYwlc4C18WEeuDRllabAV8a02y xsCOzq7GUBjx7ee13xZkcKBZHBhyW/U3WH47LIuHQfGKaAPoLN0OGoJV4Y0jug3Pz9ZeIPf9 O70trFvZqMCoaQRH5dPrzrtHYPlv76AR9ctk5WuVg2mjsIgLoV2CVzIDyoVBrb8TPzl9S8Nl KAhuczvxvUoZnvfqzv/BhnSqxGXeGfE+FNQKp6Rt+Cztca2O4LGvRmAcIxV4obF9Qd2N1xb3 nKX9PvlAK7sl6LVqwqHzuA8/686oNqRotwCfcbWzsJDmzEA0kHBHTh7OwRis/XEAn1NChbfo u3F+/Ipg/XHiA/WV4bub Message-ID: Date: Thu, 6 Dec 2018 19:45:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <1E1748C7-2208-412F-9511-2468F9476376@kitterman.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 18:45:30 -0000 On Thu 06/Dec/2018 18:48:00 +0100 Scott Kitterman wrote: > On December 6, 2018 5:39:56 PM UTC, Alessandro Vesely wrote: >> On Sat 01/Dec/2018 02:27:54 +0100 Scott Kitterman wrote: >>> >>> Perhaps we need to step back and see if there is consensus that the privacy >>> considerations in the draft are substantially correct and if risk mitigation >>> is needed as described. >> >> >> How about expanding on this: >> >> On Sat 01/Dec/2018 00:37:24 +0100 Scott Kitterman wrote: >>> >>> I don't think wide open TLDs like .com ought to be stimulating feedback on >>> any lower level elements of the DNS tree. >> >> IMHO, statistics derived thereof would be an interesting read. > > I'm not sure I understand? How much would be okay? Eh? How much of what? I meant, let's consider average.com which doesn't have a DMARC record. I receive a message from Joe@average.com, so I lookup _dmarc.average.com and get NXDOMAIN, then let's say I lookup _dmarc.com and find a record there. In the end of day I'll mail an aggregate record saying I received 1 message from 192.0.2.1 using From: domain average.com, valid spf average.com, no dkim. That way, Verisign will get to know how many messages, from which mailouts, featuring what auth methods average.com send each day. Ditto for any other domains which don't bother publishing their own DMARC records. For ESPs, those numbers reveal something about their business volumes. Ditto for e-commerce businesses or similar, which send e-mail transactions. How much of a risk is that, compared to, say, their ISPs' data, or their accountants'? On Sat 05/May/2018 15:55:37 +0200 John Levine via dmarc-discuss wrote: > My feedback goes into a database where I do occasional summary > queries. I don't recall any particular problems doing the analysis > and it is kind of fun to extract numbers like how many NANOG > subscribers get their mail at Gmail. By the time From:-rewriting takes hold, even such amusing diversions won't be possible. I think John was among the first to store reports in a DB. The above quote is about the only finding I happened to hear from him on this subject. I may be dumb, but I have difficulty in getting useful data from aggregate records. And still don't see the risk. Best Ale -- From nobody Thu Dec 6 12:23:59 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84283131182 for ; Thu, 6 Dec 2018 12:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_rCrNgySNJ6 for ; Thu, 6 Dec 2018 12:23:56 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 A70EF130F62 for ; Thu, 6 Dec 2018 12:23:56 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id c73so708297pfe.13 for ; Thu, 06 Dec 2018 12:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:mime-version; bh=KlLx0CZX9vQZsNR0KQPo2VVYm4C7xJGWlCjT6BW8dgc=; b=LQv0ANQQLBBL30SB7FQ7Lcoeky6JWsZFPnTtIhb7xM/MixR/JnA95jXPeDYZHnihNH pIZslwG0Eiba8RJ47bCe/ZFDCUMFIsItDGhlciuuX1kEdJrrsT5xGm4YAKQYmMVHzjv1 C1mr1ETJV78LB+GMrUIIZDWO0cZ9mMTORT+DelrBiqmPhtXW7d1YLorJ2/O8d2S4Xvq3 tKz1nL60/pLY4avyjf043UQyhSi2ghxIXYKuuC56eXcqofTJb5RanjlXH+AKioL5kZ0v AuI04jnQw5fY+DiL0XKFdb3vjgpEMc2aTH7h83KgO+Cf/PLDGAeaB323VhBMxhdQVxK1 PxXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:mime-version; bh=KlLx0CZX9vQZsNR0KQPo2VVYm4C7xJGWlCjT6BW8dgc=; b=kC67EzYw4kDzMv0oayQ93PIxW0Y3QSHdHv/siR+ALedxeibARBoV7UE8KSoJV4RN7D 9QTblIUzTPQJ2V98uxzDDwv7Q0aWT3yytthQZW5vb9gDxTrRnn/kn4bsc3KVP4wvX+h9 NTdeiLNH9G2yIuClpGuPK5p64a9caJpDdsSM+ZdtL2kaxJf21VyjPkCfqgDJB6SK/4db ACcBuF1gkrYec7AeJq3C/vmeSQcPtEUr5MsMHm6/SQOmiCsOUKBSa7FG2/4CAA5F66d8 YUVDWPzYC4DzoZUajd/WbkeBg7QnuJUK8UvDDTFOgAO+qv7zybUiM0TIh7ijeHwcEcEq gRBA== X-Gm-Message-State: AA+aEWZz/7W1jadgApYSP4Hkh4R5fcJaoAr03lofkdC2g9CRqAqVcTUn PUL1w48LLy+HiFE30/MJW/U= X-Google-Smtp-Source: AFSGD/VvnkxiUP/jZW7evbENTn7crxTDsnB1IJ1erujLicGN8RbaSPcZkjXR7Os8nyWPuRF/FComkw== X-Received: by 2002:a62:1541:: with SMTP id 62mr30142429pfv.230.1544127836239; Thu, 06 Dec 2018 12:23:56 -0800 (PST) Received: from DM6PR04MB5017.namprd04.prod.outlook.com ([52.96.7.61]) by smtp.gmail.com with ESMTPSA id j6sm2055860pfg.126.2018.12.06.12.23.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 12:23:55 -0800 (PST) From: Michael Martinez To: Dropbox Research , Quora Digest , "dmarc@ietf.org" , James Williams , "dustywbr@gmail.com" , "Whalen, Scott" , Design-Build Institute of America , XT808 Tactical Special , Dell Thread-Topic: I'd like your support Thread-Index: AQHUjaGaReUfM4OX5k+AEIWw3eeo6g== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Thu, 6 Dec 2018 20:23:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DM6PR04MB5017EC538E7A6FEB396CC3E8FEA90DM6PR04MB5017namp_" MIME-Version: 1.0 Archived-At: Subject: [dmarc-ietf] I'd like your support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:23:59 -0000 --_000_DM6PR04MB5017EC538E7A6FEB396CC3E8FEA90DM6PR04MB5017namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd love it if you took a moment to check out my GoFundMe campaign: https://www.gofundme.com/affiant-vs-giant?sharetype=3Dteams&member=3D117715= 6&pc=3Dem_db_co2876_v1&rcid=3D863c1db06d944d3099ed01e99df47ded Your support would mean a lot to me. Thank you so much! Michael Get Outlook for Android --_000_DM6PR04MB5017EC538E7A6FEB396CC3E8FEA90DM6PR04MB5017namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I'd love it if you took a moment to check out my GoFundMe campaign:

Your support would mean a lot to me. Thank you so much!

Michael

--_000_DM6PR04MB5017EC538E7A6FEB396CC3E8FEA90DM6PR04MB5017namp_-- From nobody Thu Dec 6 14:22:53 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA0E1311D9 for ; Thu, 6 Dec 2018 14:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=vaCpqxie; dkim=pass (2048-bit key) header.d=kitterman.com header.b=m39ksYp0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRQWtGH_CXpd for ; Thu, 6 Dec 2018 14:22:49 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85648130F4D for ; Thu, 6 Dec 2018 14:22:49 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1544134967; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=F0FDItuxlWYYjgTHo4sTqqaSWW337spRUnPw/ul9V14=; b=vaCpqxieK/oitvPl029qvmFbZ9oZzd4fVSBg9UFooOL7sJdAkfcXgx/N Q7LEPiWmhtv0X+cvPmlAJjIa3RaxBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1544134967; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=F0FDItuxlWYYjgTHo4sTqqaSWW337spRUnPw/ul9V14=; b=m39ksYp0UQq73xFf6OQXTUTUoQBgl0tySrXTb6QkSdNtGBeIJboI5d54 UjtKl3wJuKEw4Bj5rzDZKBrOBvlOqPXj8GPoPwTihJFbHFtcOpOZ9mJ0pb NuL4IKUurdzBbUf2PC8T/uIMkQAfmMla9YbIm4BFvJTDogROve2KT9M5Bg Iv43v9I563/Yf//0xDvUu7uiMitK0qR4d0uBTY+R0N3yLxyAJBIbCUlu1+ qAiIUKXAK6bKfWnGUOuCwv44P2Urr14nUThLieHv1flFW+o48ACfcvQd4c 2Deg7lrsaadPaULkSs6IXWHfvne9EtvEJhRHDIpQH+WeCVm2GvcGYg== Received: from [10.231.76.228] (mobile-166-170-34-81.mycingular.net [166.170.34.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 03E3EC401B6; Thu, 6 Dec 2018 16:22:46 -0600 (CST) Date: Thu, 06 Dec 2018 22:22:37 +0000 In-Reply-To: References: <20181201003301.1DFFA200915FC3@ary.qy> <6368515.cyHHj4lf58@kitterma-e6430> <6D01ADF1-A11F-4FB1-9978-A50FEA5E2B0E@kitterman.com> <3e304d8f-ffd1-296c-c327-32f8e6b3ee6e@tana.it> <1E1748C7-2208-412F-9511-2468F9476376@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] Lookup Limitations For Public Suffix Domains X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:22:52 -0000 On December 6, 2018 6:45:10 PM UTC, Alessandro Vesely w= rote: >On Thu 06/Dec/2018 18:48:00 +0100 Scott Kitterman wrote: >> On December 6, 2018 5:39:56 PM UTC, Alessandro Vesely > wrote: >>> On Sat 01/Dec/2018 02:27:54 +0100 Scott Kitterman wrote: >>>>=20 >>>> Perhaps we need to step back and see if there is consensus that the >privacy >>>> considerations in the draft are substantially correct and if risk >mitigation >>>> is needed as described=2E >>> >>> >>> How about expanding on this: >>> >>> On Sat 01/Dec/2018 00:37:24 +0100 Scott Kitterman wrote: >>>>=20 >>>> I don't think wide open TLDs like =2Ecom ought to be stimulating >feedback on >>>> any lower level elements of the DNS tree=2E >>> >>> IMHO, statistics derived thereof would be an interesting read=2E >>=20 >> I'm not sure I understand? How much would be okay? > > >Eh? How much of what? > > >I meant, let's consider average=2Ecom which doesn't have a DMARC record= =2E=20 >I >receive a message from Joe@average=2Ecom, so I lookup _dmarc=2Eaverage=2E= com >and get >NXDOMAIN, then let's say I lookup _dmarc=2Ecom and find a record there=2E= =20 >In the >end of day I'll mail an aggregate record saying I received 1 message >from >192=2E0=2E2=2E1 using From: domain average=2Ecom, valid spf average=2Ecom= , no >dkim=2E > >That way, Verisign will get to know how many messages, from which >mailouts, >featuring what auth methods average=2Ecom send each day=2E Ditto for any >other >domains which don't bother publishing their own DMARC records=2E > >For ESPs, those numbers reveal something about their business volumes=2E= =20 >Ditto >for e-commerce businesses or similar, which send e-mail transactions=2E= =20 >How much >of a risk is that, compared to, say, their ISPs' data, or their >accountants'? > > >On Sat 05/May/2018 15:55:37 +0200 John Levine via dmarc-discuss wrote: >> My feedback goes into a database where I do occasional summary >> queries=2E I don't recall any particular problems doing the analysis >> and it is kind of fun to extract numbers like how many NANOG >> subscribers get their mail at Gmail=2E > > >By the time From:-rewriting takes hold, even such amusing diversions >won't be >possible=2E I think John was among the first to store reports in a DB=2E= =20 >The >above quote is about the only finding I happened to hear from him on >this subject=2E > > >I may be dumb, but I have difficulty in getting useful data from >aggregate >records=2E And still don't see the risk=2E Okay=2E RFC 7489 already says there is some privacy sensitivity to the reports=2E = I didn't think we needed to re-debate that=2E See section 9 and 12=2E5=2E Without some kind of applicability constraint= , we would essentially be creating the situation that 12=2E5 warns about=2E Instead of rehaving an argument about DMARC, would you be willing to accep= t that they knew what they were doing when they wrote those parts of 7489, = even if you don't quite see it? Scott K From nobody Fri Dec 7 11:58:34 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE47130FCA; Fri, 7 Dec 2018 11:58:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dmarc@ietf.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154421270056.20241.9948320899934069450.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2018 11:58:20 -0800 Archived-At: Subject: [dmarc-ietf] WG Action: Rechartered Domain-based Message Authentication, Reporting & Conformance (dmarc) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 19:58:21 -0000 The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Domain-based Message Authentication, Reporting & Conformance (dmarc) ----------------------------------------------------------------------- Current status: Active WG Chairs: Barry Leiba Ned Freed Tim Draegen Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: Address: dmarc@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Group page: https://datatracker.ietf.org/group/dmarc/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification is published as Informational RFC 7489 in the Independent Stream. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue four tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document desirable uses of existing authentication technologies. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options 4. Related work Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC Working Group after consultation with the responsible AD. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. Any such work needs to carefully consider interoperability implications. Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. Phase II: Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol (ARC). Draft Guide on DMARC Usage. Phase III: Review and refinement of the DMARC specification. Completion of Guide on DMARC and ARC Usage. References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Milestones: Done - Complete Authenticated Received Chain (ARC) protocol spec Jan 2019 - Complete EAI update to SPF/DKIM/DMARC Feb 2019 - Complete Authenticated Received Chain (ARC) usage recommendations From nobody Mon Dec 10 07:50:19 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEB2130F58 for ; Mon, 10 Dec 2018 07:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTwuFe3zXMZz for ; Mon, 10 Dec 2018 07:50:16 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0: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 08A1A130F56 for ; Mon, 10 Dec 2018 07:50:15 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id z7so18033187iti.0 for ; Mon, 10 Dec 2018 07:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=e40H/VbEMt3hAFlYF6WlNKmZ5p+2vabIrGiDi3+OzEE=; b=Tg66OWh/J24bnTvp3i/+xR/pYBJR3GUmu/sa9et9UjCeQJJ1/L0JoBnvNpvX22SIBr srY6X1N+NoLpZ9jBCJAE23Zxq4RAj4ZhOTrbBjcwaOTDHCR+dubGT4Hsofa2zQ1Opsth 5c9oG3h3/3qVjzAnin5H8FWKcx43f5YIZHlmM= 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=e40H/VbEMt3hAFlYF6WlNKmZ5p+2vabIrGiDi3+OzEE=; b=Nx0BPHQXn4MhPdRPSoHwaOduAGcoIanBeUSxDFdRws57RRSYhIm0Slrl65oU6T5AfZ Xa/fag6xizbRFdcS/E5joOpTEKbfvdZnWicrHLvd19hEErBcGUny9qxp9JheFxZexdFn PnYHS1TA7QJwgzq2W50w2uvNbePxeVzmwZewVRDPsa/dbEnjnFkGYeDl4QK73Y6kHZZv vVVw3pRokFAyco9ClGSpad+KwRTpH1a8IMvlQtnDE3oEFhT4lg96XRi1H+Xv2QPRgq4q RM2366oDSpM8SXpws4w3aBMTuv0FJ5w1I1YqKnA/nSYTE47vxTdGRfr3s7sHxq1a+hGt g8aw== X-Gm-Message-State: AA+aEWbwAu34UtepGUY9WoUdCGQwXB4idHYl10IVDlDYRnwQZO1cag7+ 2k1qKdulthFWpUs6Aks+Ztq/StaZpnWWFQlUcN52TDGR9dJ53w== X-Google-Smtp-Source: AFSGD/WW1uSL4U+yQh3GoqLZIlxtAkO6MEtSUpxyVdRMPQM1JTOUmJp0hHL5LLcH/IMaMISz0dPX5IWPUx+2J9OPAk8= X-Received: by 2002:a02:987:: with SMTP id 7mr11809533jam.108.1544457014657; Mon, 10 Dec 2018 07:50:14 -0800 (PST) MIME-Version: 1.0 From: Kurt Andersen Date: Mon, 10 Dec 2018 07:50:00 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bae1c1057caceb9b" Archived-At: Subject: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 15:50:18 -0000 --000000000000bae1c1057caceb9b Content-Type: text/plain; charset="UTF-8" Now that the charter update has gone through the necessary processing, I'd like to ask the WG to adopt John Levine's https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item. This doc is a normative reference in both the ARC protocol doc and 7601bis. --Kurt Andersen --000000000000bae1c1057caceb9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now that the charter update has gone thro= ugh the necessary processing, I'd like to ask the WG to adopt John Levi= ne's=C2=A0https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item.

--000000000000bae1c1057caceb9b-- From nobody Mon Dec 10 07:53:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9012130FA8 for ; Mon, 10 Dec 2018 07:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69oDhBUaMjX5 for ; Mon, 10 Dec 2018 07:53:05 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8432130F58 for ; Mon, 10 Dec 2018 07:53:05 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id p197so18899473itp.0 for ; Mon, 10 Dec 2018 07:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mAhMmegilOtZfF9qhkv+Xe835xeH1bAUm1bcSO0Dqvo=; b=L4QoM3lY1Fra+oHNmk0Cgi4dT7ZPo4F6KKyoVQw6eby3y57cMkiNDy/H3z4ti4GGfL 75IzR7+8vFRuYMlSIuZC5Mie3ZCoR5V1r/zmcq+kDW+trr9ZuXSvZn8pPUWQBZqA/3Lp Yh9aAvSLyRlDoanbAVY6pePSqWvUn1k7ra4FBkuNMn/FsOOkGFmI4oznLHa9iaw4ebhm g9XlaTCTzbNaTdiWGtjwDmlPnYVXoEpycsDl7V5BksKi5q45rDHpfeZEFffb5a6aC+m9 3Y6Kzcn310Mp46xfCl2oqyJrYJ9JnWbZxehJ8dbiLORrvC18+gnOUBhvCDoYnysllKFJ gRhw== 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=mAhMmegilOtZfF9qhkv+Xe835xeH1bAUm1bcSO0Dqvo=; b=MZq8N807j2gfm6syMODwFgzfC9ymYBjgZbT60U3mXYnh4QEqjVQV7+xMjS+/fk8Nit vkuU99zUJAVXHqzAdtkVzqYfJOSO9CzevO38qTQxVsD6bSFcIbFSRgj6jjDEHEir4GVb ORy2wzPISKGt60w74mSRV9l42CsM0rmrnHCCkkiOzpXz+BUSsVBucrRA1815zwqPr+oe vq50EQHmEkbXm96GdX9CV+YVOu8B7A4m6jk5J9BEts6nKz6CedKCnl4ecTyqAyyXro6j DpnFG7kpIUVHZhizSzNIyx5UGrdEvfyK12NOrM3RDch93K5x7K9dFxGN6wwjxcfVtAQa R8cw== X-Gm-Message-State: AA+aEWbDbL1N3InA2YhAkpP5Q9Fv7qrE3lLbkD3nLShnAkZapQ05SRR7 ZeqN46m+G7mCHMkXhm6HvrF2henWhuPmtSY7RcGZJA== X-Google-Smtp-Source: AFSGD/Upou224l64o3YozJ7Ao9DSazDVS3rQjg4LOJURIKVKMaODB1iHv30nRkZSnWE+tPM/f/7nGMEGSUOpzsRzOWU= X-Received: by 2002:a05:660c:452:: with SMTP id d18mr11257435itl.124.1544457185098; Mon, 10 Dec 2018 07:53:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 10 Dec 2018 10:52:51 -0500 Message-ID: To: Kurt Andersen Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000e38168057cacf5c0" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 15:53:08 -0000 --000000000000e38168057cacf5c0 Content-Type: text/plain; charset="UTF-8" +1 on adopting this. I will sign up for review, etc. Tim On Mon, Dec 10, 2018 at 10:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000e38168057cacf5c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on adopting this. I will sign up for review, etc.=C2=A0=

Tim


On Mon, Dec 10, 2018 at 10:50 AM Kurt Andersen &= lt;kurta@drkurt.com> wrote:
<= /div>
Now that the charte= r update has gone through the necessary processing, I'd like to ask the= WG to adopt John Levine's=C2=A0https://tools.ietf.org/= html/draft-levine-appsarea-eaiauth-05 document as an official WG item.<= /div>

This doc is a normative reference in b= oth the ARC protocol doc and 7601bis.

--Kurt Ander= sen
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000e38168057cacf5c0-- From nobody Mon Dec 10 08:00:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39FB130FB7 for ; Mon, 10 Dec 2018 08:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=etL4YRDq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=vFoJy8A/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ137WH2N4ot for ; Mon, 10 Dec 2018 08:00:21 -0800 (PST) Received: from mail.winserver.com (mail.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F2130FBA for ; Mon, 10 Dec 2018 08:00:21 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=540; t=1544457613; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=NDMlvo388ZcCZ0uNpWWO00KjDRQ=; b=etL4YRDqt2vVctny2HRjDMiq5fKRmzUy/ui4xnSkGbMFY/d+QgpKZTq2aVd4XO f5Y5tLP1fk0OmEKv7ZgJFCM1NqcB2ZG1JT2zn9KKqbRxBmDd1AG1TK+FyOFMD9co J+Dq1Gbx0jpl3aJaEMmk6ZDCt5Y7ljVvO2j2BERjBSbvI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 10 Dec 2018 11:00:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3454533205.22869.3400; Mon, 10 Dec 2018 11:00:13 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=540; t=1544457458; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TntCosF Ni2S1qMa7Usn/9bPjkIJ66AOYP2EhlXRqWPs=; b=vFoJy8A/ehGc0CFeb1rBiN7 /QZv/UTFCwejzRncuec+FyGsXDRnGYwivirMUxlryWNS4P9gfFWIgR3gcpf9lFbO MDRybvx7aYt+fUXvFh3sQF5Mq5/QZkaRZ0z997y9EDKT37vw7tth+EncYsI8VOyZ F80U/DZGXZgsx87yNVUQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Mon, 10 Dec 2018 10:57:38 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 4002503110.9.106684; Mon, 10 Dec 2018 10:57:37 -0500 Message-ID: <5C0E8D89.7010800@isdg.net> Date: Mon, 10 Dec 2018 11:00:09 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:00:24 -0000 +1 On 12/10/2018 10:50 AM, Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, > I'd like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document > as an official WG item. > > This doc is a normative reference in both the ARC protocol doc and > 7601bis. > > --Kurt Andersen > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- HLS From nobody Mon Dec 10 08:11:26 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF7130F79 for ; Mon, 10 Dec 2018 08:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FsY24vJmGgA for ; Mon, 10 Dec 2018 08:11:22 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891DA1277BB for ; Mon, 10 Dec 2018 08:11:22 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id s14so11573477wmh.1 for ; Mon, 10 Dec 2018 08:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYrk/9sSrE1Gb7Z6OdRVVtKK1dawENCS4iP7b4xuq3M=; b=NQ0kUnH2pQySZ98biU2oVX37Zx0gIrTHo5VxkGPcKzGiDLPfPSCjskUNK35zqEhapF mEWxKIqunIswd0034F6dh6IU3lIvpO/ZBmYtCnxVT34J4HtY1Sw1kxefmw9I6Gc/HmQl hMkuBm28PHuEyp4evz4v+VdPfLu0z5TAyx/EcGlsrqGrk6F27MlqPfXluDSdRgLGZuj1 aeg7rD0SEyn6FNuR6OZFdxjE2EOfDhFJ9jLKsJ1eYaZ4jk5Vx5DUHrS+/TCxblISWLq3 hShdSpoHe9mOKh4S9mH32ydkseJTjtJDiL7M7r04b3nlhjNnysro0+TP3y6QLqLBU6V+ GJNw== 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=XYrk/9sSrE1Gb7Z6OdRVVtKK1dawENCS4iP7b4xuq3M=; b=sYgRyWveO23XvAGxodTd44yaE6Qqv15xnjQ26LHyyeU5ZVUCha76jvUuIJw9W3ygh9 oYrETbyKPORelBHYQq9oetD1ZZ2VSE7CS1u9wKdqaOZVZ4RqOZcpczeT0mJKh//z0Wp6 iwTu8QWiy10+Ni1qcpyGQp4mAlzVx6dTS9v+lQLnBLRnPviXOzVxOvDEGJVFrvz6uaqq sxjieyu5Vp06Y8YsveQS6q7zF1uxDQad+tCCUnm3Kc+/XonNIO/xG5CjWlaG8foqgKLt 5bdujlf6X6HPdCwBha/iKOCx4TKWXF+tcrfZ5MCAIP0itRok0kuLrGkZlvG1h5V0n8y9 41/Q== X-Gm-Message-State: AA+aEWaeckJEEQQOWS8ACXC8+ASiuAdY3orRK2mtTPSooY7fMNN98WbK Q8Z0pcJMP1wtqL3DHBISuch7x36NU1r+zpHJKFiRbw== X-Google-Smtp-Source: AFSGD/UCjFNYEZQv73geA7s/VZ6h4CpjTHypQCe5Wp1pPcfuzetMrnC/3uAnZ9izLeDMGTtubmWMPfTQfKGEdA1Wr08= X-Received: by 2002:a1c:1a90:: with SMTP id a138mr11678730wma.109.1544458280892; Mon, 10 Dec 2018 08:11:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Mon, 10 Dec 2018 11:11:10 -0500 Message-ID: To: Kurt Andersen Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000033fd39057cad371c" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:11:24 -0000 --00000000000033fd39057cad371c Content-Type: text/plain; charset="UTF-8" +1 Michael Hammer On Mon, Dec 10, 2018 at 10:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000033fd39057cad371c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Michael Hammer

On Mon, Dec 10, 2018 at 10:50 AM = Kurt Andersen <kurta@drkurt.com&= gt; wrote:
Now that the charter update has gone through the necessary proces= sing, I'd like to ask the WG to adopt John Levine's=C2=A0https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 docu= ment as an official WG item.

This doc = is a normative reference in both the ARC protocol doc and 7601bis.

--Kurt Andersen
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000033fd39057cad371c-- From nobody Mon Dec 10 08:28:12 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7713102B for ; Mon, 10 Dec 2018 08:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=xpGjvFbv; dkim=pass (2048-bit key) header.d=kitterman.com header.b=RhrxEpG6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-4ng-9kjrD2 for ; Mon, 10 Dec 2018 08:28:08 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B71A131036 for ; Mon, 10 Dec 2018 08:28:07 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544459283; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ADlzwVwF5SE/t4MYN+xSIvLOg6t3wmGAR575MEjtrjw=; b=xpGjvFbvGAdMVLPTXqqmpprO3EWtJYNAGCMzvODKpuaDRZ0gnTWtgIZ9 eSqK8YSlJ+ozaQA1DYbV+aeSsoVdDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544459283; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=ADlzwVwF5SE/t4MYN+xSIvLOg6t3wmGAR575MEjtrjw=; b=RhrxEpG6aZojY1/Rn1soPGvkyd3U3OyIbDO7gQbLD2W5tuhljVgvAIeU Dc8GoUAf5sSKVXMwvRLj+Ltn4MKt103t4qKP4Lhq8c3A03bgb8F6itTEbV RlGziZOnpz4xPnyhvlq2lvBhIGlVhtL8Po/JOPK+m/fA8OKvmvPsZYNcLF dkWyvR1wzAbZhk9Pe1XwB+KUFJWKvGg9Dq/yFpPgJE3ha5nIqDJVc2bS4P WZSeBD53sXdrRWSnu218JPcrQi9A45PCzDyC36SOEO/TzBLgGM6D7ALG3Z Ro9AgyrYPRym33qXKn36IQ1IXL+BdNpDWO939bwxNz/QdtroLY/x4Q== Received: from [10.125.68.230] (mobile-166-170-33-176.mycingular.net [166.170.33.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 33A402D40480; Mon, 10 Dec 2018 10:28:03 -0600 (CST) Date: Mon, 10 Dec 2018 16:26:09 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:28:11 -0000 On December 10, 2018 3:50:00 PM UTC, Kurt Andersen wr= ote: >Now that the charter update has gone through the necessary processing, >I'd >like to ask the WG to adopt John Levine's >https://tools=2Eietf=2Eorg/html/draft-levine-appsarea-eaiauth-05 document >as an >official WG item=2E > >This doc is a normative reference in both the ARC protocol doc and >7601bis=2E +1 I do think it needs to be tightened up to make it clearer what the updates= are=2E Since I'm most familiar with RFC 7208, I took a more detailed look at the = SPF updates=2E Much of the current text is a restatement of what RFC 7208 = says=2E I don't know that we need that=2E The difference is to make expli= cit what was already implicit; s and l macros will never match if the loca= l part of the email address contains non-ascii characters=2E I think explicit is better than implicit, so I'm in favor of the update=2E Scott K From nobody Mon Dec 10 08:31:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968113100F for ; Mon, 10 Dec 2018 08:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 yMA6iSP88Ynm for ; Mon, 10 Dec 2018 08:31:10 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0: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 42D5E13104A for ; Mon, 10 Dec 2018 08:31:10 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id m6so9423961oig.11 for ; Mon, 10 Dec 2018 08:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uruRFA6Vki3xadft3l+3BVfexY0+YUVWX974xaqZv5k=; b=S9yF5oNxjPlOo1RBF/lmILVMF2VdFN3agYqGcJhGRnwkdk8BevWvZ7rzfZwaFxInwe KQIArN2WQ5KiO1yiu71PmWk5/43KD20FwMlgN6gYRyKgViP7XjP1OTVZX6M242KPYK84 i95FJiS5TLfVJBkGh9XzlOabdI21w7piFQtw1cm19+X12c6mZmf2/z9G59/mQ5eiLq2c 6K1acX7FFsBE6hdnvMoBs1yX9klHT6KVCxOzGu0xByhNc2AyQrXamvXo0VgLsw7A5dA9 GWqOLzrsVt+zS0XSMbfq3YpUlrHqryvRbKrq6vSLIg2u6nuXH2/6Y91GL9zriw3HmMSV 8vqA== 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=uruRFA6Vki3xadft3l+3BVfexY0+YUVWX974xaqZv5k=; b=hBs7S+Ftv0icIe23isDpNdKV/zSyZMzdYgVwyFscyEAXOyzBYWaPyy+zr5wq9ffg/T RahWhh+aVQseoB+CTeDRLvhEc/RisC9+EVeOFHc9U06K9KxRyFZY74Ci8dWNBWQ4quU0 dSvXj0oq93Yr0tEHFPyH5uWqnmJHLVlk6t6mwLMT2frZmTwfyxo9E6WmOAX/97DHb310 m2GMRN9/vzwC14uvbXRn4+gTzBaxXVWvQcX5UJnIiVR/chd2kSjX+V2mGyKrnVsF9Oft gy/k24ShWOrB+9bP+Sm1//p1KSUnb4TKEETf74Oe82h/rpQYQ5bH0ndul4Mi/Kg1E/2D RGXA== X-Gm-Message-State: AA+aEWbAcu5yY2n0MFtQyVX9ABkutHNmJoTHbNAK+b6Pp64vsSay5om/ wGAQpRG5A6BfssDbAKFKqYof/C88d+sBC9wtQcShDjbM X-Google-Smtp-Source: AFSGD/WL4+R7POM4B1dwoTbHl62H7w+KTr/ddSB6+AVRf9DrCyZOo2msfhXZewDoZ/Ci2AFLT6AFHCI3KPJqTtjw4uE= X-Received: by 2002:aca:844:: with SMTP id 65mr7520375oii.333.1544459468920; Mon, 10 Dec 2018 08:31:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Seth Blank Date: Mon, 10 Dec 2018 08:30:56 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000003f88d057cad7e18" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:31:13 -0000 --00000000000003f88d057cad7e18 Content-Type: text/plain; charset="UTF-8" +1 On Mon, Dec 10, 2018 at 08:28 Scott Kitterman wrote: > > > On December 10, 2018 3:50:00 PM UTC, Kurt Andersen > wrote: > >Now that the charter update has gone through the necessary processing, > >I'd > >like to ask the WG to adopt John Levine's > >https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document > >as an > >official WG item. > > > >This doc is a normative reference in both the ARC protocol doc and > >7601bis. > > +1 > > I do think it needs to be tightened up to make it clearer what the updates > are. > > Since I'm most familiar with RFC 7208, I took a more detailed look at the > SPF updates. Much of the current text is a restatement of what RFC 7208 > says. I don't know that we need that. The difference is to make explicit > what was already implicit; s and l macros will never match if the local > part of the email address contains non-ascii characters. > > I think explicit is better than implicit, so I'm in favor of the update. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000003f88d057cad7e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Mon, Dec 10, 2018 at 08:28 Scott Kitterman <sklist@kitterman.com> wrote:


On December 10, 2018 3:50:00 PM UTC, Kurt Andersen <kurta@drkurt.com> wrote:
>Now that the charter update has gone through the necessary processing,<= br> >I'd
>like to ask the WG to adopt John Levine's
>https://tools.ietf.org/html/draft-le= vine-appsarea-eaiauth-05 document
>as an
>official WG item.
>
>This doc is a normative reference in both the ARC protocol doc and
>7601bis.

+1

I do think it needs to be tightened up to make it clearer what the updates = are.

Since I'm most familiar with RFC 7208, I took a more detailed look at t= he SPF updates.=C2=A0 Much of the current text is a restatement of what RFC= 7208 says.=C2=A0 I don't know that we need that.=C2=A0 The difference = is to make explicit what was=C2=A0 already implicit; s and l macros will ne= ver match if the local part of the email address contains non-ascii charact= ers.

I think explicit is better than implicit, so I'm in favor of the update= .

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000003f88d057cad7e18-- From nobody Mon Dec 10 08:31:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320113106D for ; Mon, 10 Dec 2018 08:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78t82Xv9Gf4U for ; Mon, 10 Dec 2018 08:31:18 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A68A131062 for ; Mon, 10 Dec 2018 08:31:18 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id a6so19096918itl.4 for ; Mon, 10 Dec 2018 08:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q6YPv9xtLBIyhtOwN7KNBAm7AIAYLaIPWxq2/WHgj7A=; b=E2SL8vcAvO3ODzvG9lu7ODTjII0DD/RXAAFqCdWo0O2SPrZbtmY6mLm2PkJWVe7CkJ O9h1IVC8LqpjrC5ZuCC/FOs1cgyO3/ixzXQX/cH9hPlwcn1Kn85c/XTLXsd5rE1cw+gl +jKWrAVq8luGhKH2CESqRySOIO94TQjUp34Fs= 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=q6YPv9xtLBIyhtOwN7KNBAm7AIAYLaIPWxq2/WHgj7A=; b=SaIRIwHcPA7OQb4ouR8g4HRgmX5Kl9dyGhUV+jxSSczDwCS35vT1ID0jrsUV3GqDlE BwAdg6d5kCos+mFFHCW490SdG+1nppD6FMMkHOEiYZ0etWjHq4hqg/r/J2GPX/b99AAd dLftmxsQr9yyXVfLG+NaQOh5ttiECW05oHcVphlAMGBKSnUPsOlFZOBqkEB5awlnjUbz q9A7BqLlbetEC3UOw9cCqgLqBZqqwrp8a9xXi/f0+vRGmBg9lT0kzYYOFlvG83Sib11n Wgs9EJyQxsbn7s6pm0KT/Uzi9/ToH61PUAGZ5RqyrmFzN/c+a9AK7aX2Bo0oNkz0288K D+1w== X-Gm-Message-State: AA+aEWYlLaURjvgrF77+Y0J8f45E5RId5pucp7zJDW7iSwaFYg1uB+2G 1FHMRKnZbx1JX0wSQVR+OqKlHZzlbHGLe5JcLxeIzA== X-Google-Smtp-Source: AFSGD/XZQkMsHF0bFVENwvdrDoJRjgM2XIXojYYcdIwS+g2+kU3hDqp70LYMFJiiN2SbL6qkP0fyi7lEdyIPHkBCp+U= X-Received: by 2002:a24:3282:: with SMTP id j124mr11617490ita.173.1544459477286; Mon, 10 Dec 2018 08:31:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Mon, 10 Dec 2018 08:31:03 -0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000083b0f2057cad7e1b" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:31:24 -0000 --00000000000083b0f2057cad7e1b Content-Type: text/plain; charset="UTF-8" On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman wrote: > > Since I'm most familiar with RFC 7208, I took a more detailed look at the > SPF updates. Much of the current text is a restatement of what RFC 7208 > says. I don't know that we need that. The difference is to make explicit > what was already implicit; s and l macros will never match if the local > part of the email address contains non-ascii characters. > Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it seems like they should be able to match without any problems. --Kurt --00000000000083b0f2057cad7e1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 10= , 2018 at 8:28 AM Scott Kitterman <sklist@kitterman.com> wrote:

Since I'm most familiar with RFC 7208, I took a more detailed look at t= he SPF updates.=C2=A0 Much of the current text is a restatement of what RFC= 7208 says.=C2=A0 I don't know that we need that.=C2=A0 The difference = is to make explicit what was=C2=A0 already implicit; s and l macros will ne= ver match if the local part of the email address contains non-ascii charact= ers.

Why not? If the non-ASCII (or non-= 7bit) characters are puny-coded, it seems like they should be able to match= without any problems.

--Kurt=C2=A0
--00000000000083b0f2057cad7e1b-- From nobody Mon Dec 10 08:58:13 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D45131084 for ; Mon, 10 Dec 2018 08:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=QFs3FR/U; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ko661Yav Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOc_va4pEyzD for ; Mon, 10 Dec 2018 08:58:11 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B85F13107F for ; Mon, 10 Dec 2018 08:58:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544461087; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=DDN1523e6wweZ2E29JLS7vBuTzRJjhvEuSsg+OKU2tM=; b=QFs3FR/U3yaR/cDNr8PWhsJQA5mfjCfjqSL7FNxKZOGWgeFIv8rtaTgA tudM2CJTd2QucNHJAjU+wBLF9bcpCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544461087; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=DDN1523e6wweZ2E29JLS7vBuTzRJjhvEuSsg+OKU2tM=; b=ko661Yav27CU9QjsuNBQrsZ0ga0UdEgydU/ENeaaWaT9B+h33TacSWMt ITYb/wwWujiBKeJoRroCyKASTj/uAwBjo8ohJfcdtBvv5TPD/eGSHGzGDz Au+jMFRMqTkzX/1KZ/DqWO/yc3B9oVXMNdP9lgMk6Q/b/e9R8IXxqDBDqi K1BNhD6OQV/fWDVVAuhU1gvuTSeD7MKGn0l72NXusTtsAlpuUk9Km8ux9S zATcJ68SgnAzjma07fZuTXc1HWnECnPY4Q21b0lDT8x+leHQD5EM/sU/tl Zn2qMJcS9Si4/RCkDSW26R7p5ClASH214cQGVlSvvs7tZU4/yLZkog== Received: from [10.125.68.230] (mobile-166-170-33-176.mycingular.net [166.170.33.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id A9AC82D40480; Mon, 10 Dec 2018 10:58:06 -0600 (CST) Date: Mon, 10 Dec 2018 16:58:01 +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: <5A5FC552-4CEC-42E9-B40B-6CFED1D86885@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 16:58:13 -0000 On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman >wrote: > >> >> Since I'm most familiar with RFC 7208, I took a more detailed look at >the >> SPF updates=2E Much of the current text is a restatement of what RFC >7208 >> says=2E I don't know that we need that=2E The difference is to make >explicit >> what was already implicit; s and l macros will never match if the >local >> part of the email address contains non-ascii characters=2E >> > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it >seems >like they should be able to match without any problems=2E > AIUI, local parts don't get puny-coded=2E Scott K From nobody Mon Dec 10 09:02:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC41130934 for ; Mon, 10 Dec 2018 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGV3tx8N5kLf for ; Mon, 10 Dec 2018 09:02:45 -0800 (PST) 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 7FC6A13109A for ; Mon, 10 Dec 2018 09:02:45 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id l14so9313179ioj.5 for ; Mon, 10 Dec 2018 09:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rJyy5N/DsXMPNzu4aGdk4HvuO/Tra9bdD6vGge60w5M=; b=I6V93pu0Yv0pqsVeKzYSlSJyZ0V6YzeaHuz3C9ksgYokRjHqvPtiTDL3wqMg+xwlEb /kDZZG+4hwBZgyR9qQ0Ctme9ky+t7lciGXEiq5OwFJJzCbPTig+dg8STIZdqsgSJbbrO PvQXibTSSOzHt86naIQ3Xz8ZIHSLDXWFa6ssQ= 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=rJyy5N/DsXMPNzu4aGdk4HvuO/Tra9bdD6vGge60w5M=; b=BlYxu5gFnBLwNguzUxNB6v4oDjmsjQGwk3EJZ6obqEjw75OFlnT/Si6KPgwfUWzeZ5 YfHmWWetxyGhwcaBQXLbICXSZpxNTPHXl2spMuYp/9t7azCYTBa76/EIpHjyy/ZTivUA OhZZcAcNR+5Z+miB0eZqQSEfbBfyghy82qdHP69loL96+ft/P4kF4kFMC5qn3nCdfjXM R91TKdcCOuF4iC/Unm+9pi2u7vHuc8VMCX22k/qpC0PTPyAa+lpduAyERdd+elZYpoMI vQcD7HnUrSSDktd2Uar5LNOKoFUVdwhQqYEp1kQ8j1lOq/AfEgDylwQrp2WsN+JvXV+O B0hg== X-Gm-Message-State: AA+aEWb2VfHbqjq0veWxfrq2YLHYe4jAzxe2JL7Ens6Px1xLDneiNnQC 3hMQrUkHJtL5PIS5y4OuhpoND4QIT4CWRhzWMzPJ92zp5Bc= X-Google-Smtp-Source: AFSGD/U06Fa80Wd4i0IyDPWqAVNWDFRa2w7HH4Q8DdfetsiZD2ff/uUZdV8YnVyh8wABBmFYTXetKOIEsVzAA8d103A= X-Received: by 2002:a5e:940c:: with SMTP id q12mr9302851ioj.228.1544461364723; Mon, 10 Dec 2018 09:02:44 -0800 (PST) MIME-Version: 1.0 References: <5A5FC552-4CEC-42E9-B40B-6CFED1D86885@kitterman.com> In-Reply-To: <5A5FC552-4CEC-42E9-B40B-6CFED1D86885@kitterman.com> From: "Kurt Andersen (b)" Date: Mon, 10 Dec 2018 09:02:30 -0800 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000039f43057cadef92" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 17:02:47 -0000 --000000000000039f43057cadef92 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman wrote: > > > On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman > >wrote: > > > >> > >> Since I'm most familiar with RFC 7208, I took a more detailed look at > >the > >> SPF updates. Much of the current text is a restatement of what RFC > >7208 > >> says. I don't know that we need that. The difference is to make > >explicit > >> what was already implicit; s and l macros will never match if the > >local > >> part of the email address contains non-ascii characters. > >> > > > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it > >seems > >like they should be able to match without any problems. > > > AIUI, local parts don't get puny-coded. > Even when attempting to look them up via the macro mechanism? It seems like that encoding should be a part of the macro processing. --Kurt --000000000000039f43057cadef92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 10= , 2018 at 8:58 AM Scott Kitterman <sklist@kitterman.com> wrote:


On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> = wrote:
>On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>>
>> Since I'm most familiar with RFC 7208, I took a more detailed = look at
>the
>> SPF updates.=C2=A0 Much of the current text is a restatement of wh= at RFC
>7208
>> says.=C2=A0 I don't know that we need that.=C2=A0 The differen= ce is to make
>explicit
>> what was=C2=A0 already implicit; s and l macros will never match i= f the
>local
>> part of the email address contains non-ascii characters.
>>
>
>Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it >seems
>like they should be able to match without any problems.
>
AIUI, local parts don't get puny-coded.

=
Even when attempting to look them up via the macro mechanism? It seems= like that encoding should be a part of the macro processing.
--Kurt=C2=A0
--000000000000039f43057cadef92-- From nobody Mon Dec 10 14:08:35 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23618131280 for ; Mon, 10 Dec 2018 14:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=kXBFt7ly; dkim=pass (2048-bit key) header.d=kitterman.com header.b=g6Cv+E6d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZP7RwwiPzm6 for ; Mon, 10 Dec 2018 14:08:33 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541B013123B for ; Mon, 10 Dec 2018 14:08:33 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544479710; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=11SFalTb/Nhsm7ufzJ+vRVYayUpI2KR/LQZ1/vPNlGo=; b=kXBFt7lySh1TGVXhlFIuJQpiDKvj6ZgwkMUXjKq5qAZXY/xYr4mNv6DQ C1tyMv5iZ8pODb0ZQbUvvil282B2Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544479710; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=11SFalTb/Nhsm7ufzJ+vRVYayUpI2KR/LQZ1/vPNlGo=; b=g6Cv+E6dAfWtemCp5c4+VnA8UHViO/HEk7M7J44tM1IhlaQWWQT0GFh/ z7JM5QJrjDaoKDUA4xvPTjwDMfMd2UEoqaEWzZv6m9NYRd9eTpmnYK8MGk VfVZ3um/cF67BBuPGTOOkSXseu9LCqwUxaEuNnChUtuSiGiNZB1B/h7NO4 zINoCK86n3Cj3ejNZl52QcpsANK1nmbXBhxiow1qqBgrXTfbnZk980A6i2 Eo3xodRv9H1iG7D8+O8KJ2IrO6VBqZRifn0NofBxmAZ+sLgDFIYeadcNC3 RzAcziWC8kBF6Lej7Zo7G16Yn9Q/FmBHZZ9KYHP2yE0ram/AEGfu+A== Received: from [10.125.68.230] (mobile-166-170-33-176.mycingular.net [166.170.33.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id B1A262D4062B; Mon, 10 Dec 2018 16:08:30 -0600 (CST) Date: Mon, 10 Dec 2018 22:08:27 +0000 In-Reply-To: References: <5A5FC552-4CEC-42E9-B40B-6CFED1D86885@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] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 22:08:35 -0000 On December 10, 2018 5:02:30 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman >wrote: > >> >> >> On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" > >> wrote: >> >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman > >> >wrote: >> > >> >> >> >> Since I'm most familiar with RFC 7208, I took a more detailed look >at >> >the >> >> SPF updates=2E Much of the current text is a restatement of what >RFC >> >7208 >> >> says=2E I don't know that we need that=2E The difference is to mak= e >> >explicit >> >> what was already implicit; s and l macros will never match if the >> >local >> >> part of the email address contains non-ascii characters=2E >> >> >> > >> >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, >it >> >seems >> >like they should be able to match without any problems=2E >> > >> AIUI, local parts don't get puny-coded=2E >> > >Even when attempting to look them up via the macro mechanism? It seems >like >that encoding should be a part of the macro processing=2E We discussed this during spfbis and concluded this was enough of a corner = case not to make an incompatible protocol change over it=2E Almost no one uses SPF macros and even fewer use use the 'l' and 's' macro= s=2E If such a change were introduced, every SPF library would need an upd= ate to help approximately no one=2E I don't we should relitigate this here= =2E Between non-ascii local parts and SPF records using with the 'l' or 's' ma= cros, you get to pick one=2E Documenting this clearly is a good idea=2E Scott K From nobody Mon Dec 10 16:42:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5E13133D for ; Mon, 10 Dec 2018 16:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=54eo4MKr; dkim=pass (1536-bit key) header.d=taugh.com header.b=BKlbk6/S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1Psjsr1AaqD for ; Mon, 10 Dec 2018 16:42:42 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C47D12DD85 for ; Mon, 10 Dec 2018 16:42:42 -0800 (PST) Received: (qmail 35017 invoked from network); 11 Dec 2018 00:42:40 -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=88c7.5c0f0800.k1812; bh=3Zg7pO6heB4cRdeeOhbDMVj0Y6auXB+drMZ+cbyIanE=; b=54eo4MKrK0qlKwiSlI0opfiK3ib6tlmh1Y2orvDe3yZ37xS8YiDWTchXtPPjCmVuzAGO/jHiYidP3foJBmg2vu/MkdlsKw5zJf2y9ZTAvd7MU8LUEq7mSegtvYnL/mzmjAB9LRaUKsdZWAjntIe+98odWbshJJ5NRxES13u/M+jfvmSYOKfnsIifyeqdiS5y+sr4qjh9dYa9kpUqFgmZ6Wb+ABk9MQJw2nfyG7LDbhzfRs+LUc0Feh1ukfz5comy 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=88c7.5c0f0800.k1812; bh=3Zg7pO6heB4cRdeeOhbDMVj0Y6auXB+drMZ+cbyIanE=; b=BKlbk6/Src6HSwEz/AAY8bjPEWiPrMS15jEJzjy6dYDmIzIo/AVDLFOz3kmeVnwdNI49QrCn271gR2pMSy3qphgkfpEF1xWgDLMxUsXf/jtDoS6E5uH9A3FYkY8osgcPGGxwsX7hNjssUgd1JzaCdv+wNEHSK3mqj9Z1L12gQBzEZN+mQu86DoYkg+BGb7to3WuKOiuPCxp1TJjhmjkF0LbamsM52HrzPthtIeyo0yQhvraAEqC9GSwa1iF9r70B Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 11 Dec 2018 00:42:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 52F9F200B3823D; Mon, 10 Dec 2018 19:42:39 -0500 (EST) Date: 10 Dec 2018 19:42:39 -0500 Message-Id: <20181211004240.52F9F200B3823D@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] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2018 00:42:44 -0000 In article you write: >> what was already implicit; s and l macros will never match if the local >> part of the email address contains non-ascii characters. >> > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it seems >like they should be able to match without any problems. No. No, no, no, no. In EAI mail, e-mail address local parts are UTF-8. You cannot translate them into anything else and you very specifically cannot "punycode" them. Using the term punycode in IDNA2003, which is obsolete, was a serious mistake, since it led people to all sorts of bogus conclusions. In IDNA2008 domain names, and only in domain names, there are U-labels which contain a large subset of UTF-8 encoded Unicode, and there are A-labels which consist of ASCII starting with XN--. There is a two-way algorithm to convert between U-labels and A-labels. There is no punycode. R's, John From nobody Mon Dec 10 16:45:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD2C13133D for ; Mon, 10 Dec 2018 16:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Db0Eaz1+; dkim=pass (1536-bit key) header.d=taugh.com header.b=g0dprOi+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZJ1M-hFTy_J for ; Mon, 10 Dec 2018 16:45:06 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E136F13133B for ; Mon, 10 Dec 2018 16:45:05 -0800 (PST) Received: (qmail 35607 invoked from network); 11 Dec 2018 00:45:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=8b15.5c0f088e.k1812; bh=0yVluhjxgYo1SpDX9KzzVoipDtf1MT/IzWLKiJtozLo=; b=Db0Eaz1+lXiHgGWKAbxMyDizgnM+TlKtJL5AcbHAtLIXI/xUIJ5nciM5MqapnQDYEJ9zzXGDBCTYjbPTTJS8yLmOqngbUrjk5OpAO65jwQVAQEn0zn4rKaOoBFYZ5dprEObWlTg74CMq7nZtBAWxSjq+XgftO8eeggLvSOrPtWZIdYWejPbC3sKvU8CKFe3Q07ApeurwUsTmwfXXiLkCiIZZDBXjFwbXf0q4Opr4KVcTvxXEG4OTnVjp1DKWV4MH 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=8b15.5c0f088e.k1812; bh=0yVluhjxgYo1SpDX9KzzVoipDtf1MT/IzWLKiJtozLo=; b=g0dprOi+jtg8FwSAc17STsnRdAwWBmX/oRn+pMS6u2wjsQs/d266W6sft1POa7SI4fVSuvDHpMOaiAir97WwQ1zeSy/LRwDht86OzxJJWg4I+kgbsE8IiZJClwSSX6L/Ub622uo/RXT0QeP1SUnkBmVPB0Weup904PA5iL7YuAn3QCtvD3bnLo8qeN63BdfBek/bRwkKKMYrg7W5m9p3oYZW/Wchb77dP4pXYarTmXDk7h636hJfbkwqI515kplr Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 11 Dec 2018 00:45:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 81025200B3827D; Mon, 10 Dec 2018 19:45:00 -0500 (EST) Date: 10 Dec 2018 19:45:00 -0500 Message-Id: <20181211004501.81025200B3827D@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] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2018 00:45:07 -0000 In article you write: >> AIUI, local parts don't get puny-coded. > >Even when attempting to look them up via the macro mechanism? No, never. There is no way to re-code a UTF-8 local part. Don't even ask. If it sounds like I've had this argument before, I have and I really don't want to have it again. R's, John PS: even if we were to invent some crock like turning UTF-8 into hex, it would not work because there are a vast number of ways to encode strings in UTF-8 that look identical, and there is no plausible way to normalize them all. It's not like ASCII case folding. From nobody Mon Dec 10 16:54:09 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2989C12DD85 for ; Mon, 10 Dec 2018 16:54:07 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GpPK9LbaFqP9 for ; Mon, 10 Dec 2018 16:54:04 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 07B61130FB5 for ; Mon, 10 Dec 2018 16:54:01 -0800 (PST) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMLijCg9c9NkLAA--.7541S2; Tue, 11 Dec 2018 08:53:55 +0800 (CST) Date: Tue, 11 Dec 2018 08:53:53 +0800 From: "Jiankang Yao" To: "Kurt Andersen" , "dmarc@ietf.org" Reply-To: yaojk References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20181211085338573964123@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart366441435116_=----" X-CM-TRANSID: AQAAf0ApMLijCg9c9NkLAA--.7541S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYD7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr 1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY 62kv0487Mc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67 AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAx ZF0Ew4CEw7xC0wCY02Avz4vE14v_twCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1l IxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2 IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jrR67UUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2018 00:54:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart366441435116_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpzdXBwb3J0ICsxDQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBLdXJ0IEFuZGVyc2Vu DQpEYXRlOiAyMDE4LTEyLTEwIDIzOjUwDQpUbzogZG1hcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtk bWFyYy1pZXRmXSBSZWNvbW1lbmQgYWRvcHRpb24gb2YgZHJhZnQtbGV2aW5lLWFwcHNhcmVhLWVh aWF1dGggYXMgV0cgd29yaw0KTm93IHRoYXQgdGhlIGNoYXJ0ZXIgdXBkYXRlIGhhcyBnb25lIHRo cm91Z2ggdGhlIG5lY2Vzc2FyeSBwcm9jZXNzaW5nLCBJJ2QgbGlrZSB0byBhc2sgdGhlIFdHIHRv IGFkb3B0IEpvaG4gTGV2aW5lJ3MgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxl dmluZS1hcHBzYXJlYS1lYWlhdXRoLTA1IGRvY3VtZW50IGFzIGFuIG9mZmljaWFsIFdHIGl0ZW0u DQoNCg0KVGhpcyBkb2MgaXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGluIGJvdGggdGhlIEFSQyBw cm90b2NvbCBkb2MgYW5kIDc2MDFiaXMuDQoNCg0KLS1LdXJ0IEFuZGVyc2Vu ------=_001_NextPart366441435116_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
support +1
 
Jiankang Yao
 
Date: 2018-12-10 23:50
To: dmarc@ietf.org<= /DIV>
Subject: [dmarc-ietf] Recommend adoption of=20 draft-levine-appsarea-eaiauth as WG work
Now that the charter update has gone through the necessary=20 processing, I'd like to ask the WG to adopt John Levine's http= s://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05=20 document as an official WG item.

This doc is a normative reference in both the ARC protocol doc and=20 7601bis.

--Kurt Andersen
------=_001_NextPart366441435116_=------ From nobody Mon Dec 10 21:19:46 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1A1130DE7 for ; Mon, 10 Dec 2018 21:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcXfEVVFqHH4 for ; Mon, 10 Dec 2018 21:19:38 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1744130E39 for ; Mon, 10 Dec 2018 21:19:36 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id v15-v6so11748490ljh.13 for ; Mon, 10 Dec 2018 21:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jasJCUJN2EsGJ+war8cJkV5aBJcqKY31UsXhQZWHxvw=; b=TlqF9wbL/skqTZcFTvf9CxKGjFM41VS2OX3De/uvK7nJI6nveeynDIXyJs4y3FhoUR x82q6vIvl/tqslUaGjCFYbyZz0XHK7odRSyWxLQXd5f9galRV8vReMnCokk3TNY4Or9A 6adkNOQR2YG2BeIwJ/+uqIh/KQjRZMCjLsrBWqZ3H8l4wYyeD7NY3nUzkIt4GlHhbfjT 1CaM4x0mEgdJz3eu3rgOsxcK/gwqCkJg8tJReR2LJrhaydAPzJZXbWs2ldVLJzxWDUkB qgU1mN0sqeGeqXO5I6jxzDVTVZiu1HNKA3AbfItDEZ3+SzvT91O5gkrRw8AY6FFzSgDM xlig== 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=jasJCUJN2EsGJ+war8cJkV5aBJcqKY31UsXhQZWHxvw=; b=K0Dmsu60KQqqCKT9jH/uOtyGHyd+h/e8ii/UBRdzCgdbdLmnZuvxn6XsnqvkpQ8DyM WkVDek8WqXG2oV7iBQT1g3GbmNOdBeckDaCpv0c6FNURjCFd+oiBIHLISB1LCNzz+vry 0zaaEFc7idfOKW0c9YZ3xvZJB+/xKva2W2c32akG5KxnMSIsanAJuDvWKpT9Air8ILdg DtEyckKgZCyngvtKImUUI1hS9WsH3k8aldwCUpnY7VVd3n0tLyRPcEQwJiz8jzISrfhL Pv3gU0NDSlf2wqDd840wVpMMnPPmNY3r1pXk7vSyaEtOLiXA4y/sV/7FnSUWrVP8uU+u OBoA== X-Gm-Message-State: AA+aEWYSTE864NWjSGTGxyqS25COeTEfVU/xMBp1vJjGFNnY3wEXccRQ +JRaFYTgSpmK2MEDQo5VsPl3kfjvjjixTSFZ02VTyg== X-Google-Smtp-Source: AFSGD/XAQ4eiZPHBTa/DFBEWsP46J9xRbt/VSAEgbEfoD06lGRn1cICgqSGvNrPZQ3rQJh4L/SwE0h7zr+GSyEu9Osg= X-Received: by 2002:a2e:9655:: with SMTP id z21-v6mr9882409ljh.136.1544505574653; Mon, 10 Dec 2018 21:19:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Peter M. Goldstein" Date: Mon, 10 Dec 2018 21:19:22 -0800 Message-ID: To: dmarc Content-Type: multipart/alternative; boundary="0000000000002184a1057cb83a9c" Archived-At: Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Dec 2018 05:19:44 -0000 --0000000000002184a1057cb83a9c Content-Type: text/plain; charset="UTF-8" +1 on adopting On Mon, Dec 10, 2018 at 7:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000002184a1057cb83a9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on adopting

On Mon, Dec 10, 2018 at 7:50 AM Kurt Andersen <kurta@drkurt.com> wrote:
= Now that the charter update has gone through the necessary processing, I= 9;d like to ask the WG to adopt John Levine's=C2=A0http= s://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an= official WG item.

This doc is a norma= tive reference in both the ARC protocol doc and 7601bis.

--Kurt Andersen
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000002184a1057cb83a9c-- From nobody Tue Dec 11 20:17:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBE3130DC4 for ; Tue, 11 Dec 2018 20:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbtlpjCNh5M2 for ; Tue, 11 Dec 2018 20:17:45 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 39B8F12EB11 for ; Tue, 11 Dec 2018 20:17:45 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBC4Iajh015832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 11 Dec 2018 20:18:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544588317; bh=fuV56bBFnDH7P8Yg78FotjUF0iK3keXe+kWMuDsd+SE=; h=From:Subject:To:References:Reply-To:Date:In-Reply-To:From; b=geSBelmsx/Pac65t6FLHXU8cCFiVMe4GIhGVUEBHyolqfeaRwkjzbN8bCs90nrtSv hQheQwhjNJDxU+TYabLxqyfSEuotS7EWlNUBow8IJzyGVv+wBOLSDtvBEA/RFYXey2 m2Ux4v9DckhAegQGZYES0mBVxzkR1FC3qF+BnA4A= From: Dave Crocker To: IETF DMARC WG References: <611C4FF8-57C8-494A-9C98-EACB3FFD45A1@linkedin.com> <561bd8fd-ee96-a23f-c0a5-9da96e583607@gmail.com> <0d93f07c-824a-7ffc-2ec5-6b216442a456@gmail.com> <2407614A-21F6-403F-9259-92B361380EBB@linkedin.com> <9c0b00d6-8234-0009-97e5-9bbbe89e1c9c@gmail.com> <32A8F41D-978D-46AB-A2C2-741AC20DCEB3@linkedin.com> <9131ae2e-4fa1-90c3-f9ed-912a3fe7ee09@gmail.com> <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> Date: Tue, 11 Dec 2018 20:17:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 04:17:47 -0000 Folks, Howdy. This note is the result of some offline discussions, patiently helping me to work through the purpose of the kitterman-dmarc-psd. After some false starts, here's where I landed: I believe the registry created by kitterman-dmarc-psd is not needed. More generally I believe the proposal spec can be considerably abbreviated. 1. If the registry is to constrain which public suffix operators are constrained to assert a default record, then I'll claim that's a false sense of security, given the range of unrelated and even more serious powers a parent domain can exert over a subordinate one. 2. If it is to avoid wasting a DNS a query to a record that won't be there, that's false economy. Most queries to the registry will fail. And most queries to both the From: domain name and its organizational domain already fail. The incremental cost of a wasted query to the organizational domain's parent is pretty small. And the cost of creating and running a query-able database that is kept current is high and error-prone (as the existing PSL demonstrates.) So I think that the functional goal of kitterman-dmarc-psd is fully satisfied by merely doing a version of the 3A update to DMARC, directing the client to query the immediate parent of the organizational domain, if the OD has been queried and no DMARC record has been found. That is, making DMARC have a 3-level lookup sequence rather than two, where the additional one is the same as for the organizational domain, except one level higher. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 11 21:02:01 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24D21310AB for ; Tue, 11 Dec 2018 21:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Q8nchoXc; dkim=pass (2048-bit key) header.d=kitterman.com header.b=gsuq8uV+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szfv8IBu0sxH for ; Tue, 11 Dec 2018 21:01:58 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE5212875B for ; Tue, 11 Dec 2018 21:01:58 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544590913; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=koKCqSKWm+CFZUkQhVgjXPJugEMpdbO84GBNhPC2n+o=; b=Q8nchoXcmVGAxqiWm8ZzNoDKpUJYmErxPfqLtNRu7ID78iCrv5Qgl4M+ h/Bdf9UUw6ARYglawec2q1gbD3IVAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544590913; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=koKCqSKWm+CFZUkQhVgjXPJugEMpdbO84GBNhPC2n+o=; b=gsuq8uV+ftRMGJ4UibFnroLROVYHzIlkivC0HukJzaYyoREK7iQReKoy 9UTZsEGbGQFwjnYwBhR4KOTjr8/WbTrORVrkPvVob/bUP3UCYDBK/WM2vZ WwR2KFt6DN1R+St5pMk42lJaWYkiVcj5hiexQVI0R8ebCMfwVkW0WIme5q VhJtIPpjF+JfQVWN2EEHEuJkjU2aBR9C8cgGLeSHKVKf02ifl1+Eh2uy6F fdZt76//z0h3E73KD/g1AeesDBximTVtkZpJ6YZ7ZO+rghSFpDtd7LyPHy s/IM6QnRjzgudMUAX9UKa1DDATiMbeVOIpfSEVpdO5ZQ+Tn+7KVPcQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 1C1592D4062B for ; Tue, 11 Dec 2018 23:01:53 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 12 Dec 2018 00:01:47 -0500 Message-ID: <8090288.RMFQGzStmc@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> References: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 05:02:01 -0000 On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote: > Folks, > > Howdy. > > This note is the result of some offline discussions, patiently helping > me to work through the purpose of the kitterman-dmarc-psd. After some > false starts, here's where I landed: > > > I believe the registry created by kitterman-dmarc-psd is not needed. > More generally I believe the proposal spec can be considerably abbreviated. > > > 1. If the registry is to constrain which public suffix operators > are constrained to assert a default record, then I'll claim that's a > false sense of security, given the range of unrelated and even more > serious powers a parent domain can exert over a subordinate one. > > 2. If it is to avoid wasting a DNS a query to a record that won't > be there, that's false economy. Most queries to the registry will fail. > And most queries to both the From: domain name and its organizational > domain already fail. The incremental cost of a wasted query to the > organizational domain's parent is pretty small. > > And the cost of creating and running a query-able database that is kept > current is high and error-prone (as the existing PSL demonstrates.) > > > So I think that the functional goal of kitterman-dmarc-psd is fully > satisfied by merely doing a version of the 3A update to DMARC, directing > the client to query the immediate parent of the organizational domain, > if the OD has been queried and no DMARC record has been found. > > That is, making DMARC have a 3-level lookup sequence rather than two, > where the additional one is the same as for the organizational domain, > except one level higher. > > Thoughts? I think your analysis is essentially correct, but I think point 1 is backwards. Since (in the current draft), based on the registry entries, the third level queries will usually not take place. It's not that the PSOs are constrained not to publish records (they aren't), it's that no one will (should) query for them based on the third level test if they aren't in the registry. This may seem like a small thing, but I believe it makes all the difference. You are certainly correct that nothing in an RFC can prevent a PSO from publishing such records. What we can do is give guidance on when not to look at them. I believe avoiding the privacy implications of the related feedback are worth the transactional costs of the registry (but then I would, wouldn't I). I don't think a bad situation justifies making it worse. Scott K From nobody Wed Dec 12 07:30:33 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB82130934 for ; Wed, 12 Dec 2018 07:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnYGjgOQK4eU for ; Wed, 12 Dec 2018 07:30:29 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 E3164130DC9 for ; Wed, 12 Dec 2018 07:30:27 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCFVKEq031843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 07:31:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544628680; bh=+iQAAxPnBx5HV/ryGEZWGWdiO1LNI1vfZ06wB4Rmu8c=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=PAYzLLQPQwexQaSThFQjBzdfFL0/J8hCDW7JHMkNwAZY8vvPaWX+sKDQUe5cVPZht 2V3BCmOkXPigwbJ0L7FM9QzGWFkCUsArsCKXngJsKghjYqoYbqFGADa+J9oAZtKbid eb8CfvV6lTOJ1CjxLDwAkgjMc5grHJFsKNHcRBrg= To: Scott Kitterman , dmarc@ietf.org References: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> <8090288.RMFQGzStmc@kitterma-e6430> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net> Date: Wed, 12 Dec 2018 07:30:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <8090288.RMFQGzStmc@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 15:30:32 -0000 On 12/11/2018 9:01 PM, Scott Kitterman wrote: > On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote: >> 1. If the registry is to constrain which public suffix operators >> are constrained to assert a default record, then I'll claim that's >> a false sense of security, given the range of unrelated and even >> more serious powers a parent domain can exert over a subordinate >> one. >> >> 2. If it is to avoid wasting a DNS a query to a record that won't >> be there, that's false economy. Most queries to the registry will >> fail. And most queries to both the From: domain name and its >> organizational domain already fail. The incremental cost of a >> wasted query to the organizational domain's parent is pretty >> small. >> >> And the cost of creating and running a query-able database that is >> kept current is high and error-prone (as the existing PSL >> demonstrates.) ... > I think your analysis is essentially correct, but I think point 1 is > backwards. Since (in the current draft), based on the registry > entries, the third level queries will usually not take place. It's > not that the PSOs are constrained not to publish records (they > aren't), it's that no one will (should) query for them based on the > third level test if they aren't in the registry. > > This may seem like a small thing, but I believe it makes all the difference. > You are certainly correct that nothing in an RFC can prevent a PSO from > publishing such records. What we can do is give guidance on when not to look > at them. That's a cost-saving line of concern. My point is that the existing mechanism already has quite a bit operational inefficiency from queries that fail, so that adding one more is a minor issue, especially as against the considerable administrative and operational cost of creating and running a registry. > I believe avoiding the privacy implications of the related feedback > are worth the transactional costs of the registry (but then I would, > wouldn't I). I don't think a bad situation justifies making it > worse. Sorry but I don't know what privacy implications you are referring to. I don't even have a guess. And the draft makes no reference to privacy issues. Or rather, the Privacy Considerations section says the draft doesn't introduce any. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 12 08:59:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6820126DBF for ; Wed, 12 Dec 2018 08:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=pU1QsZDo; dkim=pass (1536-bit key) header.d=taugh.com header.b=0SG1y1tk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq3a8_1oxgR8 for ; Wed, 12 Dec 2018 08:59:16 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F18C130EE7 for ; Wed, 12 Dec 2018 08:59:16 -0800 (PST) Received: (qmail 41506 invoked from network); 12 Dec 2018 16:59:14 -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=a220.5c113e62.k1812; bh=ugLaXtInsDJqdcMwWUy2lbL0SRiWBHVivAPK3BBz+iw=; b=pU1QsZDoA4HsfP8EJeeTVi6XD2WPaPq7xuVJhHntSixBkuLBr1rT9I1fFWiaxU+FK2DAiNnPoxfkTP7nHRK/yAm+fPbyjPWekX6liOBgEY/JC70RAlI7DPxhRs9jQe+G6PLH4P7Uu79wYOSu8vvwFqdzBCDBtIuQlW9+YQNg+1Zij1nluIgSRhonye6w6h3phBdl2e0WQkElboNx6wYsVNU4JYGjGYPa2LkziwOvKxr2bqi8u7iybfiWhtZFhKey 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=a220.5c113e62.k1812; bh=ugLaXtInsDJqdcMwWUy2lbL0SRiWBHVivAPK3BBz+iw=; b=0SG1y1tk5lQXppOkpp6E9sX+SZza5jdD59JSO3L/9zYPyohPpFLf5qnTUVIZDdop5AvNQfWXkiMASBXAprXQtM8IwR+7aIe7+HqLCLecPNMvzLVfljTbIMwA31+SKAXEpeHS7oJFIKALd/caTefSWrDt7VLZkT+6iXcbG3dDnDM79Z7z/ufEROhl3NCTK9VQrcSfO5TMrjcf1/YqxpM1x2VV6WuNanuDSeyieyct5pn1zCTp1CUFeAE1Zw3kqzW5 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 12 Dec 2018 16:59:14 -0000 Received: by ary.qy (Postfix, from userid 501) id 36A76200B6363D; Wed, 12 Dec 2018 11:59:13 -0500 (EST) Date: 12 Dec 2018 11:59:13 -0500 Message-Id: <20181212165914.36A76200B6363D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> 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] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 16:59:19 -0000 In article <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> you write: >So I think that the functional goal of kitterman-dmarc-psd is fully >satisfied by merely doing a version of the 3A update to DMARC, directing >the client to query the immediate parent of the organizational domain, >if the OD has been queried and no DMARC record has been found. Given that anything we do to handle public suffix defaults will need some code changes, this seems about the simplest change that would do the trick. I am aware of two security or privacy issues that might come up. If we used a DNS scheme like my DBOUND one, whoever runs the DNS policy server can see all the queries and will have some idea of the mail traffic from various names. This approach doesn't have that problem. The DNS operator can tell that someone is asking about a subdomain, but not which subdomain. The other is that the DMARC record might have rua= and ruf= and get detailed reports about subdomains. This is not an unreasonable concern -- I am the legacy registrar for various .ny.us domains and my DMARC reports tell me a lot about one of my registrants who sends a lot of mail. (Real mail, they're the county govermnent.) This is easily addressed by clients ignoring the report advice in the OD parent record. One issue that is not our problem but might be Scott's is that in ICANN contracted TLDs, they're not allowed to publish TXT records at _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special permission to do so. I happen to know the people who evaluate the applications (as do many other people here) and I'm sure they would say yes for those two TLDs, but it would involve some time and money. This might actually be a feature, since a similar appplication for _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more scepticism. R's, John From nobody Wed Dec 12 09:38:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAA7130E4F for ; Wed, 12 Dec 2018 09:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snmiK1N65LzD for ; Wed, 12 Dec 2018 09:38:18 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 B59D912DDA3 for ; Wed, 12 Dec 2018 09:38:17 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCHd9Gu008440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 09:39:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544636350; bh=6fxFLtdGaPPyq6MGHQrgvjlT8jrEax/SaSKvxVGSe1g=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=lRcKQTAKqzlDz/i3O8BFk8RG7XUmjeoUlPAYkqjUsvZLXEmSbf5rHYnHFXe4ddrCv hUfjMckN2EYDnMzrcujyav/VpDRRQgudfWSSku7bUY4rH9PGjdw075zqDhW4TAwnTe kHePHZZUYZm++QpjH18FrTs9Wm711wLN1mgdd12Q= To: John Levine , dmarc@ietf.org References: <20181212165914.36A76200B6363D@ary.qy> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net> Date: Wed, 12 Dec 2018 09:38:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20181212165914.36A76200B6363D@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 17:38:20 -0000 On 12/12/2018 8:59 AM, John Levine wrote: > In article <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> you write: >> So I think that the functional goal of kitterman-dmarc-psd is fully >> satisfied by merely doing a version of the 3A update to DMARC, directing >> the client to query the immediate parent of the organizational domain, >> if the OD has been queried and no DMARC record has been found. > > Given that anything we do to handle public suffix defaults will need > some code changes, this seems about the simplest change that would do > the trick. > > I am aware of two security or privacy issues that might come up. If > we used a DNS scheme like my DBOUND one, whoever runs the DNS policy > server can see all the queries and will have some idea of the mail > traffic from various names. This approach doesn't have that problem. 1. Doesn't the query to the registry suffer the same risk? 2. I'm not sure what a "DNS policy server" is. I'm guessing it's meant as a DNS server that contains the dbound-ish records? 3. Given queries for MX record, don't we already have massive exposure of this privacy-related info in DNS activity? How would this be so much more (and/or worse)? > The DNS operator can tell that someone is asking about a subdomain, > but not which subdomain. Sorry but I don't understand this. A bout of densitude has enveloped me. Please explain, pedantically. > The other is that the DMARC record might have rua= and ruf= and get > detailed reports about subdomains. This is not an unreasonable concern -- > I am the legacy registrar for various .ny.us domains and > my DMARC reports tell me a lot about one of my registrants who sends > a lot of mail. (Real mail, they're the county govermnent.) This is > easily addressed by clients ignoring the report advice in the OD > parent record. What does it mean for a /client/ to ignore the advice in the OD parent record? I thought that record was for servers. I'm now guessing that your note is primarily (or completely) about the basic, potential dangers of having a default DMARC record in a public registry, rather than being about the refinements to the PSD spec I've suggested? > One issue that is not our problem but might be Scott's is that in > ICANN contracted TLDs, they're not allowed to publish TXT records at > _dmarc.BANK or _dmarc.INSURANCE unless they apply to get special > permission to do so. I happen to know the people who evaluate the > applications (as do many other people here) and I'm sure they would > say yes for those two TLDs, but it would involve some time and money. > This might actually be a feature, since a similar appplication for > _dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more > scepticism. This invites an exercise at writing a policy directive to characterize the types of TLDs that are good candidates for saying yes and those that are good candidates for saying no. The most useful part of such a document would be charactizing 'types' of registries... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 12 09:47:25 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF291288EB for ; Wed, 12 Dec 2018 09:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=JahHMRLx; dkim=pass (1536-bit key) header.d=taugh.com header.b=wVZDAfkA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZVNUdxgQqHA for ; Wed, 12 Dec 2018 09:47:19 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD031277BB for ; Wed, 12 Dec 2018 09:47:19 -0800 (PST) Received: (qmail 58319 invoked from network); 12 Dec 2018 17:47:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e3cb.5c1149a4.k1812; bh=I0BQvEzsM6P/GEGrO+Fk/H7vdAA/OhO9MnbohL35s6s=; b=JahHMRLxmppVGFjIMtlNMcJG23VT3xOOMVEi/XcGUUq9Xd9bSA3CNaC3EfmzgFr2vex7nEcssRSCPV1H9rlfO0LgOAgIJFIFET3TkNh9bIXrtsFLBxgouz/wcti309jwp4LadqMlMONb+XTC496b23qLys1mHWOOKgwnVTQt3AcDg3eP81f5TBOcSvlhH/Qh+i/fv2OFWClmhS2jTM/6tB7x4fdj2CtkPhKXPj8Hx5fMuVk1lI++4lrwgL6PLmgp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e3cb.5c1149a4.k1812; bh=I0BQvEzsM6P/GEGrO+Fk/H7vdAA/OhO9MnbohL35s6s=; b=wVZDAfkA+PYdQ1RMRs1jErna9C/nzcHCh3kNwQYDhxU98AnGydszIKZa2GaQQCLEIIfj2nLfrpZDcbmuE8azyw91LE3UtS8laR5VM64AM2M/Nz+Vy4H/51p0jCTvz0CfYq3Hli9ralXBeiu+glFH0pXxKrSoAxewRoskEIWH1nA+NwxpCG0uI1j2GdEIrGwOEdXS1CM0l6ix6/cG3Ayk6Jc4ycIsqe4/JIT9HmQppAfb4ztYWN5plpraL2TVyVN3 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Dec 2018 17:47:16 -0000 Date: 12 Dec 2018 12:47:16 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org In-Reply-To: <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net> References: <20181212165914.36A76200B6363D@ary.qy> <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 17:47:22 -0000 On Wed, 12 Dec 2018, Dave Crocker wrote: >> we used a DNS scheme like my DBOUND one, whoever runs the DNS policy >> server can see all the queries and will have some idea of the mail >> traffic from various names. This approach doesn't have that problem. > > 1. Doesn't the query to the registry suffer the same risk? > > 2. I'm not sure what a "DNS policy server" is. I'm guessing it's meant as a > DNS server that contains the dbound-ish records? For #2, that's right. For #1, my DBOUND scheme does a lookup which includes the full name, e,g, if you're checking the boundary for foo.bar.com it looks up foo.bar._dbound.com. It will likely be matched by a wildcard *._dbound.com, but the query's in the logs. With your scheme it just looks up _dmarc.com. > 3. Given queries for MX record, don't we already have massive exposure of > this privacy-related info in DNS activity? How would this be so much more > (and/or worse)? Particularly with large passive DNS databases, you're right. I believe that Scott's point was that we can try not to make it worse. >> a lot of mail. (Real mail, they're the county govermnent.) This is >> easily addressed by clients ignoring the report advice in the OD >> parent record. > > What does it mean for a /client/ to ignore the advice in the OD parent > record? I thought that record was for servers. I meant the DNS client, which is likely to be the mail server receiving a message. > This invites an exercise at writing a policy directive to characterize the > types of TLDs that are good candidates for saying yes and those that are good > candidates for saying no. The most useful part of such a document would be > charactizing 'types' of registries... That's already done. Some limit registrations to identified members of a community, some don't. You can argue how well those limits are enforced (what am I doing with names in .aero and .travel?) but the principle is clear enough. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 12 10:00:10 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559BD131195 for ; Wed, 12 Dec 2018 10:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=dcrocker.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYoxrxZpGyQ1 for ; Wed, 12 Dec 2018 10:00:06 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 2241013119D for ; Wed, 12 Dec 2018 10:00:06 -0800 (PST) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBCI0w0Y009460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Dec 2018 10:00:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544637658; bh=5u/We6+Dfca00hVxBXf3hFP1UgLJWFSgVZiMNcEjkO8=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=RF5AUjlGzxEV4U+yJ0+ZAB5z53QpHK9V3205edRehjDJpKxeSHA1aC736rRImfD8h QrdUc/kLrNqESaZdLiGUxZEaBW30dUXPums8aUZtn3RjYxbp4dU8r5lXLOXk/7UrWY GSXS3Dqkp2g9ptyBRiuCjXZ65plQL/pP9WsVMGMM= To: John R Levine Cc: dmarc@ietf.org References: <20181212165914.36A76200B6363D@ary.qy> <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net> From: Dave Crocker Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: <34f1d56b-d6c4-6fec-1a94-0355c9404c92@dcrocker.net> Date: Wed, 12 Dec 2018 09:59:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 18:00:08 -0000 On 12/12/2018 9:47 AM, John R Levine wrote: > On Wed, 12 Dec 2018, Dave Crocker wrote: >> 3. Given queries for MX record, don't we already have massive exposure >> of this privacy-related info in DNS activity?  How would this be so >> much more (and/or worse)? > > Particularly with large passive DNS databases, you're right.  I believe > that Scott's point was that we can try not to make it worse. This is a point worth pressing on. Hard. The source of the pressure is that the cost of a queriable registry is high. Very, very high. So creating one needs to have a very compelling justification. I don't see how this one comes close. >>>  a lot of mail.  (Real mail, they're the county govermnent.)  This is >>>  easily addressed by clients ignoring the report advice in the OD >>>  parent record. >> >> What does it mean for a /client/ to ignore the advice in the OD parent >> record?  I thought that record was for servers. > > I meant the DNS client, which is likely to be the mail server receiving > a message. Besides retrieving information and passing it up to its caller, the DNS client has nothing at all to do with using advice in an OD parent record. Hence my confusion about your text. So I think you meant "This is easily addressed by receivers ignoring the report adivce in the OD parent record." Contrary to many other occasions, I'm not being this picky just for fun. These topics seem to engender confusion in lots of folk and lots of discussions, and so I think it important to be very careful about terminology and references. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 12 10:45:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACD131213 for ; Wed, 12 Dec 2018 10:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=5mAoaV7l; dkim=pass (1536-bit key) header.d=taugh.com header.b=TVP83nas Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-ZNTpGWIbOu for ; Wed, 12 Dec 2018 10:45:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE4313120C for ; Wed, 12 Dec 2018 10:45:50 -0800 (PST) Received: (qmail 77881 invoked from network); 12 Dec 2018 18:45: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:references:mime-version:content-type:content-id:user-agent; s=13037.5c11575d.k1812; bh=PyaF+Jp4UWruFXekyMwu/mEMjUGdnahvWkE0TccSWMM=; b=5mAoaV7lp16QXQcSCvTsyKjIeGqo7UtPjxaqDlDs5xAf7CmWSB8JjmMHCdDqae/Fgo0BoHUquRusQfbVcCDRNWNrWrimWMEfl87bu1inZinlnx3FCe5sW2AmhH+fMQ2HvRo/htjdg4qeqirWOWGf1nAMNQDOmf0qQTn6iLC6xB8JivW3S6QQZcrjP8oHO9dTss7IjjdqEUyiWgphc+9mhuTt5MKtvc15h538ZLTWi23qZy08EykjUPaMoMwdMZZU DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:content-id:user-agent; s=13037.5c11575d.k1812; bh=PyaF+Jp4UWruFXekyMwu/mEMjUGdnahvWkE0TccSWMM=; b=TVP83nasgqffEEe2zsUYXV0Cb48crzhJPL88xKX/2/+9hZDnUmqqXU8BT4gSRf6NjuXCf8IjnRFwI+1f9AX9m/Q9NN7lfjBJh5UlC854CxJf+xnn4UoVrhVzxSIMSBFlsq3hYbedtli74NrTELwIme9qvl/edtlpuuOeuNX8UHeeA97dLCY0HXKopDdimF5kJ/yWCg4ypZinPVsYXW0nYHMqUjoOG33Ix6U4rk9vQgltNQsyJCikKPe6X6dhZEGL Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Dec 2018 18:45:49 -0000 Date: 12 Dec 2018 13:45:48 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net Cc: dmarc@ietf.org In-Reply-To: <34f1d56b-d6c4-6fec-1a94-0355c9404c92@dcrocker.net> References: <20181212165914.36A76200B6363D@ary.qy> <67d0e491-9e87-0219-cb94-e8e897daeff9@dcrocker.net> <34f1d56b-d6c4-6fec-1a94-0355c9404c92@dcrocker.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-ID: Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Dec 2018 18:45:54 -0000 On Wed, 12 Dec 2018, Dave Crocker wrote: > The source of the pressure is that the cost of a queriable registry is high. > Very, very high. So creating one needs to have a very compelling > justification. I don't see how this one comes close. Seems that way to me. Even if it's distributed by DNS, perhaps under blah.psd.arpa, so it uses existing infrastructure, it's still significant work to manage. > Besides retrieving information and passing it up to its caller, the DNS > client has nothing at all to do with using advice in an OD parent record. > Hence my confusion about your text. So I think you meant "This is easily > addressed by receivers ignoring the report adivce in the OD parent record." Yup. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Dec 12 14:51:53 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 955D61312B9; Wed, 12 Dec 2018 14:51:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154465510557.21229.15229103569531343457@ietfa.amsl.com> Date: Wed, 12 Dec 2018 14:51:45 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-22.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 22:51:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-22.txt Pages : 39 Date : 2018-12-12 Abstract: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 12 15:00:55 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566F6131310 for ; Wed, 12 Dec 2018 15:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2XTb77pqQRm for ; Wed, 12 Dec 2018 15:00:51 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 35D76130F29 for ; Wed, 12 Dec 2018 15:00:51 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id n9so81078ioh.7 for ; Wed, 12 Dec 2018 15:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=MIm90kNA8w8xQBXZml3I1CpUj1v0Ir8p4khUleSikVM=; b=flWTtIHH1LAT5W2kL3C6m6Yk6FMdsOuLw4uQnpxyiRFQqqQWJf7s+9MUTUnavxjwqs IaoWReJr6ZmWjIXuTXj/mpcgY/zx/YrpFvYZbuUisF6NueD3QiKUM0RW/6i4yE5xppRh 1ON+VHRrnyBjys7t31JBi79jDbgTWoDcLaElY= 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=MIm90kNA8w8xQBXZml3I1CpUj1v0Ir8p4khUleSikVM=; b=Bq/ldEAqFnKly/K6k2Gzzc3Yhg6nR5f747PwbnOHJC6TLglHcl3vYSLTiQyc4rodMj DA4uhddNO/ttRyevifRCmkQVTTNeexFoMgImH1hR0Pk6Oodf8Po8KWHISAos7mDdLE8+ JiLgifltzNYg8yZ/FsUfk8LjzO28NNH6FzDKGoEeo2zOtZiK33qLbQVIIdeXzI0QpNAu gLLt/1+gJirZEe33dUn645mE1YNi5J4Rr103g97w34Hs1AKJjtOOX8uE/uOL7U7LM7pM uDvNN6huR2wYvyntCL5qoott03kdhxghhx61E/ecjOW+G23tELmsODbAUL7KWBNOvAob NhgA== X-Gm-Message-State: AA+aEWapBs0osooFFY3PTIhY0j9fxBvGAD//QzjtBckcCxpzCKR3dXKa 1k45tiurVHqR5sXAFwcUWMtYYDovNhCbUt9LUFAjnfX7AKQGWw== X-Google-Smtp-Source: AFSGD/X1Kb+GNS0cNuPIouHGIM4TZ42FHcgpUlsMuvYZ1zqKdbRJILdbtDl0/ywcbjafpspHPWSE089F63QDMyFa6H0= X-Received: by 2002:a5d:8597:: with SMTP id f23mr19378468ioj.238.1544655649836; Wed, 12 Dec 2018 15:00:49 -0800 (PST) MIME-Version: 1.0 From: "Kurt Andersen (IETF)" Date: Wed, 12 Dec 2018 15:00:38 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004f2a27057cdb2b70" Archived-At: Subject: [dmarc-ietf] Final nits fixes after IESG review for ARC 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, 12 Dec 2018 23:00:54 -0000 --0000000000004f2a27057cdb2b70 Content-Type: text/plain; charset="UTF-8" This new version fixes a handful of minor points raised in the IESG reviews. It should be good to hand off to the editors... Name: draft-ietf-dmarc-arc-protocol Revision: 22 Title: Authenticated Received Chain (ARC) Protocol Document date: 2018-12-12 Group: dmarc Pages: 39 URL: https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-22.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ Htmlized: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-22 --Kurt --0000000000004f2a27057cdb2b70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This new version fixes a handful of minor points raised in= the IESG reviews. It should be good to hand off to the editors...

= Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dmarc-arc-protocol=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A022
Title:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Authenticated Received Chain (ARC) Protocol
Document date:= =C2=A0 2018-12-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dmarc
Page= s:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 39
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0https://= www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-22.txt
St= atus:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
Ht= mlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-22
Htmlized:=C2= =A0 =C2=A0 =C2=A0 =C2=A0https://d= atatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol
Diff:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-protocol-22<= /a>

--0000000000004f2a27057cdb2b70-- From nobody Wed Dec 12 17:27:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19722129BBF for ; Wed, 12 Dec 2018 17:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=CmYUmpjs; dkim=pass (2048-bit key) header.d=kitterman.com header.b=yn7B9JG+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OImprTzK9C7l for ; Wed, 12 Dec 2018 17:27:12 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5F9128B14 for ; Wed, 12 Dec 2018 17:27:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=CmYUmpjso0Ca0mDdgwSYrj5q9WR0uRIGjdGwGEEiHYbDwYeHAIUKHvDi Erbd+CBX+KfPj+CGJTEy1viN6zuhCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544664429; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=Ad81SD0Vvwv6EbglQBn4evn8ZY11/aCqVY1+irfGhmo=; b=yn7B9JG+Yzn+RezOD4C+LX9Lq5mcu5ZqxJ0RC3iWSNf5cFfeMSqfGeDI iuvqeDo6Muho5qlfYJeuClvPBBQs3ity/2QwnEXhQ1K+8BCKXUNwZ8MMZ2 HfRYFJRfrEngSzr5xOFCKR2CpT4t97JQL4lWfy7UzU1SfEZGhAn7FD6bfx yjfegEi+eg9eYP/MHRn+uisjXcBJ36xCnK6mvRwKmpSHldUrEjebvw980k KiowJEsoY9STg5thXexKSnymKUoECHlRm+s5GrWUkH7WVoJo7IrVnTiUnR phFKVr6CiSlddCFHal2FztbheIqHZCYMM5rTvoTrdzm6z7g1lRQkrA== Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id EE1992D4062B; Wed, 12 Dec 2018 19:27:08 -0600 (CST) Date: Thu, 13 Dec 2018 01:27:03 +0000 In-Reply-To: <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net> References: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> <8090288.RMFQGzStmc@kitterma-e6430> <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net> 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] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 01:27:14 -0000 On December 12, 2018 3:30:20 PM UTC, Dave Crocker wro= te: >On 12/11/2018 9:01 PM, Scott Kitterman wrote: >> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote: > >>> 1=2E If the registry is to constrain which public suffix operators=20 >>> are constrained to assert a default record, then I'll claim that's >>> a false sense of security, given the range of unrelated and even >>> more serious powers a parent domain can exert over a subordinate >>> one=2E >>>=20 >>> 2=2E If it is to avoid wasting a DNS a query to a record that won't= =20 >>> be there, that's false economy=2E Most queries to the registry will >>> fail=2E And most queries to both the From: domain name and its >>> organizational domain already fail=2E The incremental cost of a >>> wasted query to the organizational domain's parent is pretty >>> small=2E >>>=20 >>> And the cost of creating and running a query-able database that is >>> kept current is high and error-prone (as the existing PSL >>> demonstrates=2E) >=2E=2E=2E=2E > >> I think your analysis is essentially correct, but I think point 1 is=20 >> backwards=2E Since (in the current draft), based on the registry >> entries, the third level queries will usually not take place=2E It's >> not that the PSOs are constrained not to publish records (they >> aren't), it's that no one will (should) query for them based on the >> third level test if they aren't in the registry=2E >>=20 >> This may seem like a small thing, but I believe it makes all the >difference=2E =20 >> You are certainly correct that nothing in an RFC can prevent a PSO >from=20 >> publishing such records=2E What we can do is give guidance on when not >to look=20 >> at them=2E > >That's a cost-saving line of concern=2E My point is that the existing >mechanism already has quite a bit operational inefficiency from queries >that fail, so that adding one more is a minor issue, especially as >against the considerable administrative and operational cost of >creating >and running a registry=2E > > >> I believe avoiding the privacy implications of the related feedback >> are worth the transactional costs of the registry (but then I would, >> wouldn't I)=2E I don't think a bad situation justifies making it >> worse=2E > >Sorry but I don't know what privacy implications you are referring to=2E >I don't even have a guess=2E > >And the draft makes no reference to privacy issues=2E Or rather, the=20 >Privacy Considerations section says the draft doesn't introduce any=2E As written, it doesn't=2E If you change it the way you propose, it will= =2E Scott K From nobody Wed Dec 12 17:46:14 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2394A129A87 for ; Wed, 12 Dec 2018 17:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpd2Jz8HURx3 for ; Wed, 12 Dec 2018 17:46:11 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0: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 89C811293FB for ; Wed, 12 Dec 2018 17:46:11 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id x202so334043oif.13 for ; Wed, 12 Dec 2018 17:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6Gg4/8P60I0Ewnltjl/3RkN3ttlOVdZ6/DnhiWrdvew=; b=qLs5jSU3GdjU3/lyFNtLG9qwbxiSNRF3j5UHwwvJv8G0Ljaocb31UtYnCBAnkZPvAJ g5/Ux6c3ywiTRi6MAUKA7G+3wo5iCXVnky3zA0YrxA4RC2X+10ThUhg1q9/BCJU/CjpM wgyVb+Ec46dykkCVeZrNuv4gd4sAre6qJ7LWTXP8ipq6c7XeSGthz33HvZz9CSmWq71H rPlK3Ap6CL9ri8DxEe5wIl+W+YxBVXxeL+bZfHCFjMUjthTKj69G9/1bqTLTjoGmeQg0 F0fbHS5Exkw8cJSluGDGn/IXcnNzWhi55zs9NBs1tMhkZjPdDMRbfTCWsBACIVoO/EjF VVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6Gg4/8P60I0Ewnltjl/3RkN3ttlOVdZ6/DnhiWrdvew=; b=kBiJX8nU6T0IwmeUMTgpQNXZPc59L63piWGAOe3dtxfojv7ml76Q4iFotZZV65UaAp PjDXBjmeiVmTwrflS2Erm4OFgV5tHCt+ihEKUp7YTd6zSywqAlsmaWmiYmqOaeTeyWjC 5I2EVuB6Gm+XOsvqgPQpvmwEvMTu75gOqEBOdtkOb7QfkPk7+HcAGIQFhuvyMxkEkFJ/ eT4qQDIz6++teE75oC67QcN1tUvyvNYGTPuj/wf86x1zsYICvQECpy++HPCXH9nu/pd9 IGBALcDJMjJULlM8qt/CXp8XHCO2HMZVcCzYTw3LxbjVQ6LGbShm8xLxe6BhwBK8oaCV bs2w== X-Gm-Message-State: AA+aEWZ5xXkiKlsn+ZovCi7Go+M6FCQAFVlrIWbK3yGp+0hQR2Xd2xCG 2tJHKYzytxkjyj4rZGf32g/6IF2oTVM= X-Google-Smtp-Source: AFSGD/UOc7LApt8dnpKoBZgq2cOwmBm5iiVyIoIeHbg4e84gnN6uy/sq+kOcWCNOGNuKPwbTaZzP+Q== X-Received: by 2002:aca:4489:: with SMTP id r131mr1883350oia.296.1544665570237; Wed, 12 Dec 2018 17:46:10 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:5527:8627:e51:455e? ([2600:1700:a3a0:870:5527:8627:e51:455e]) by smtp.gmail.com with ESMTPSA id s66sm275486oia.55.2018.12.12.17.46.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 17:46:09 -0800 (PST) To: Scott Kitterman , dmarc@ietf.org References: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com> <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net> <8090288.RMFQGzStmc@kitterma-e6430> <3003562c-e2df-2ab0-e34b-8bda4f881d40@dcrocker.net> From: Dave Crocker Message-ID: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> Date: Wed, 12 Dec 2018 17:46:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 01:46:13 -0000 On 12/12/2018 5:27 PM, Scott Kitterman wrote: >> And the draft makes no reference to privacy issues. Or rather, the >> Privacy Considerations section says the draft doesn't introduce any. > As written, it doesn't. If you change it the way you propose, it will. Please elucidate. I don't have a guess as to what those issues are. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 12 20:21:20 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C42128CFD for ; Wed, 12 Dec 2018 20:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=WGo7yGPS; dkim=pass (2048-bit key) header.d=kitterman.com header.b=wuBl9UA1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YGIzDRRr0HT for ; Wed, 12 Dec 2018 20:21:16 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3C3129A87 for ; Wed, 12 Dec 2018 20:21:16 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544674874; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=JdN2/RoLZ+Calt3S2D5Jvdpsh+/QUiZhQEYg7En613o=; b=WGo7yGPS7jtQryKY3muCuU2IPjapProRnZybRUUrsFE0v+2T+++tkL01 uJli06v1NfHV1HGnO5FNHry4KqxdBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544674874; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=JdN2/RoLZ+Calt3S2D5Jvdpsh+/QUiZhQEYg7En613o=; b=wuBl9UA1C237vSbIHnPGdflqrQYCK6wXZ9DVN8Xa1Mi4jQBvyFFUoueV qdYAvMUH2B0O+mZyJHyTT8XcxzL4hvhe5BWpRAO+guDcDx2qEyz5VR2DJQ 97PxX3pcdS6d/elohT/2d44mN9XNCqc+fjabwaAYFzMQHY+Gc3tSb/RmYW 989Xkc5p/hEqNCtiHfqCYaOLMqk4A983dBo984GBX40974+k3Q6r3yvUCg h7aAVCBO5vc8ek76wY/TCKeH80DFzvRjiHFyTZTCv+R/XfcQOQAsAX8W5o c5up5rcOwhHHJJGwhW9bqGmtP6IjrJ1Fn0rl7ALPh3JCdrRHiavxfg== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id E25D92D4062B for ; Wed, 12 Dec 2018 22:21:14 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 12 Dec 2018 23:21:14 -0500 Message-ID: <2657505.cCtalkmY2s@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> References: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 04:21:18 -0000 On Wednesday, December 12, 2018 05:46:08 PM Dave Crocker wrote: > On 12/12/2018 5:27 PM, Scott Kitterman wrote: > >> And the draft makes no reference to privacy issues. Or rather, the > >> Privacy Considerations section says the draft doesn't introduce any. > > > > As written, it doesn't. If you change it the way you propose, it will. > > Please elucidate. I don't have a guess as to what those issues are. RFC 7489, Section 9.1 describes the data exposure considerations associated with DMARC. If we extend DMARC with PSD and no limitations on PSO participation, then those considerations will apply to every domain that does not participate in DMARC (because the PSO can now get the data - publishing a DMARC record will prevent that, but let's not make DMARC participating more coercive than it already is). I think it would be interesting to get more details from John Levine on his experience with this as he has (in a later message in the thread) mentioned he's getting this kind of data now for odd architectural reasons. Back to this draft, without the registry or some equivalent mechanism, we'd have to look at the part of Section 4.1 on Multi-organization PSDs and give a detailed explanation of the privacy risks to non-DMARC participants. It's not relevant as the draft is currently scoped because as currently defined it's only for PSDs where every domain is required to participate in DMARC, so no issue. Scott K From nobody Thu Dec 13 08:08:57 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9C12D4E9 for ; Thu, 13 Dec 2018 08:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_PH_BODY_META_ALL=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 LBf0an62MgQv for ; Thu, 13 Dec 2018 08:08:52 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEC71277CC for ; Thu, 13 Dec 2018 08:08:52 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id v6so2056038oif.2 for ; Thu, 13 Dec 2018 08:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dMmqDY90n/V6uMif8nlsd+R7JbNlc/IDOE9s8Bs1+vQ=; b=MFWlv3tLmUzsqlaWzFOD+Lfu+NdLgiPtczev4f7nVSJht5XFt963OHtVmEg3YPDsFV il4vrLcq+thQz/mpPrZj7eFgXMvD6uwxxKwWFWMkJxUKvl/demf2qdqT/xwXKZENnky3 onX9+o/yG8rly2ixusBdKvan7r7HzHNhwfL3XVvD47FlBOkIgqkXb3nRJ2pf5xc/JUFV h+Hg2ok6r/i/8mysIdTaSX3f6fpsxwM+J8PpTu2SZCZXUSlzVfrmhKm/pN/qd+nxAic4 mAJaOV88uX9REN1oDbEBJ5i39QqxzJZdcBYIPOiN/sjIabXwTMc68EmOjGHsbu+wEoFx 0t+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dMmqDY90n/V6uMif8nlsd+R7JbNlc/IDOE9s8Bs1+vQ=; b=I18zB4uL2lZMoG+Q550HnUpGU1iqYz9zsDIOStLwx6zTZ+sG/l1yPi/Lor1vlpLS1/ yN1G4HG6fGl7pq2z9iYegVmM7HI09NbACAXCxSd+/VUB1IPMKilsbr/kqzL+bKsAaJQu EqWFuZ3ONU/oqKfGVFjuXydRTamHlibk1oLszEuI0rANrcMU2a9MX1MYXTjIyYkNdpcn jsKMoV3vWm0diPKwnyDAwie3iYKn0jPWsXun9ccuZuz6oETqCHkmSHwCSUsqxEbr50L/ FrEBZW2IHzaDGms4Lx3MPug9M6RGpcYMgEtox/0wV93jhtR5zUe483av1rpu+j1pFVIk vWKQ== X-Gm-Message-State: AA+aEWY2R2J/ZPvV1PLeh06Pzfa46g41EMozfkHrmkvAIP+ZmA/CM+cS gmMHbMgroyBvdsByFUA+I/aNJ+DZ6W4= X-Google-Smtp-Source: AFSGD/WpFSmi+Hsp1vqEWv1Eq408J6cYLGZ3PMG3RF3mWNEDNgu998U51e/Hp16n8XABJGjgeK7+zg== X-Received: by 2002:aca:195:: with SMTP id 143mr3012274oib.322.1544717331511; Thu, 13 Dec 2018 08:08:51 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:d167:e3f8:4e3c:c340? ([2600:1700:a3a0:870:d167:e3f8:4e3c:c340]) by smtp.gmail.com with ESMTPSA id g64sm1009312otb.77.2018.12.13.08.08.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 08:08:50 -0800 (PST) To: Scott Kitterman , dmarc@ietf.org References: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> <2657505.cCtalkmY2s@kitterma-e6430> From: Dave Crocker Message-ID: <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> Date: Thu, 13 Dec 2018 08:08:46 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <2657505.cCtalkmY2s@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 16:08:55 -0000 On 12/12/2018 8:21 PM, Scott Kitterman wrote: > If we extend DMARC with PSD and no limitations on PSO > participation, then those considerations will apply to every domain that does > not participate in DMARC (because the PSO can now get the data Scott, Thanks for the clarification. Now I understand the nature of the privacy concern: (Public) registries that publish a DMARC record will get email traffic reports of their customers who do not publish DMARC records. This does indeed seem a new attack surface, since the other powers of the registry mostly fall under denial of service rather than traffic analysis. So the provisions of Section 6.1 in the -psd draft are meant to ensure that entries in the PSD registry are limited to any registry that: > 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. I suspect that this will have cases that prove rather more challenging to the Expert Reviewer than one might expect -- definition of 'single organization' can get sticky in some cases -- but still, the nature of the requirement is clear: ensure that registry policy is documented and targets DMARC usage explicitly. (Small point: Given this purpose for the registry, it's probably important for the registry's policy document to be publicly available, but that's not stated as required.) Hmmm... Let me suggest a much easier hack, which differs in utility mostly by being post hoc rather than the current draft's pre-hoc mechanism: Require the registry to publish another DNS record, in its _dmarc node, which a) asserts either than DMARC is required or that the subtree is part of a single organization, and b) contain a URL to the documentation for this. A query for the DMARC record of the registry will also deliver this information record. (This might be the first case in which the problem of getting 'other' TXT records is actually a feature and not a problem...) That makes the information public, while avoiding the considerable overhead and problems of a new registry -- nevermind one that needs real-time querying. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 13 08:21:08 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F012870E for ; Thu, 13 Dec 2018 08:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecb6mlRQlALG for ; Thu, 13 Dec 2018 08:21:05 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C18E126BED for ; Thu, 13 Dec 2018 08:21:05 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id h193so4651838ita.5 for ; Thu, 13 Dec 2018 08:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xOI3VEFR3k1oqWVSAWWjvbQ7y1uYfG1IJ5YZiIVIA7M=; b=CVMnp4zUUp/4RcoYhQ1x9pm7xV6QTccKVojN73RUHY6ZrzMnaAKH46ZgvJMnHrkc3s /HodqAkvuZfJaMWXNxaZ+Ebtd2xzDilFBXgXF7kX3ltd5l7tFlrOdqj/m4SY8eokPeAU qU8Ec5fyZBTXmn1sbZipxQQuqXA23Tqk8rCvQ= 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=xOI3VEFR3k1oqWVSAWWjvbQ7y1uYfG1IJ5YZiIVIA7M=; b=OIGAQHK8uVPwn6TWgSndQdAg4fRNwWcIgY6LNLLoxLUiHZlvJPWAzeMhTeQ/Lt+hg0 61ElgDPPWaFnbooXn/Y5QlF8yQr8nyqNb5dZzgOmLl1zdcxyunx2GeohDVyk0JYtWLwz XNG/NxRdM/xm+jWBW50zXeUXtvj6tVgSo35QbJ6pDUYgBHzkYj85DrFYDn2gSlmYgoZf Gq8MIAR46zFILSdu4mTBieWHvinA4Hv96WR3/J4c/DZI5y20+TwuoXPqIKjFsteXQPKE 8NS5phHAsjqujwz/yP8i7jp8s5Rin0KQ+FzCcDZNjBrgvIJMFoVIt/SXucTJAlCVhA+I 7lfA== X-Gm-Message-State: AA+aEWbiMOGYm0HzXuM8UcqlbRoBz6+yizDbTuKpkEDh+cYvqweq9CKE oMgJjU1ZyIaTZoEMOw0SOFL+FjzeDaP+hbMxMzGcWA== X-Google-Smtp-Source: AFSGD/XoiJ0gHH0tni8Dp7zOPu28g9Aa1WrGWwVQCfyIq7ZBAuO0qjZDqyi5HdBMZ8YJlFYggOPyD6sguxu2ONHH6sw= X-Received: by 2002:a24:3282:: with SMTP id j124mr10238120ita.173.1544718064130; Thu, 13 Dec 2018 08:21:04 -0800 (PST) MIME-Version: 1.0 References: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> <2657505.cCtalkmY2s@kitterma-e6430> <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> In-Reply-To: <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> From: "Kurt Andersen (b)" Date: Thu, 13 Dec 2018 08:20:51 -0800 Message-ID: To: Dave Crocker Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007db546057ce9b3f7" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 16:21:07 -0000 --0000000000007db546057ce9b3f7 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 13, 2018 at 8:09 AM Dave Crocker wrote: > > Let me suggest a much easier hack... > > Require the registry to publish another DNS record, in its _dmarc > node, which a) asserts either than DMARC is required or that the subtree > is part of a single organization, and b) contain a URL to the > documentation for this. > > That makes the information public, while avoiding the considerable > overhead and problems of a new registry -- nevermind one that needs > real-time querying. > A link to inscrutable legalese, potentially in a non-interpretable format (consider, for example, a PDF consisting of images of a foreign alphabet - perhaps Klingon) doesn't seem to really achieve the intent. And neither does the bald assertion - "trust me, I require people to do the right thing" :-) --Kurt --0000000000007db546057ce9b3f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Let me suggest a much easier hack...
=C2=A0
=C2=A0 =C2=A0 =C2=A0 Require the registry to publish another DNS record, in= its _dmarc
node, which a) asserts either than DMARC is required or that the subtree is part of a single organization, and b) contain a URL to the
documentation for this.

That makes the information public, while avoiding the considerable
overhead and problems of a new registry -- nevermind one that needs
real-time querying.

A link to inscrutab= le legalese, potentially in a non-interpretable format (consider, for examp= le, a PDF consisting of images of a foreign alphabet - perhaps Klingon) doe= sn't seem to really achieve the intent. And neither does the bald asser= tion - "trust me, I require people to do the right thing" :-)

--Kurt
--0000000000007db546057ce9b3f7-- From nobody Thu Dec 13 08:24:46 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859C2126BED for ; Thu, 13 Dec 2018 08:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6BYwL-leH5J for ; Thu, 13 Dec 2018 08:24:42 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8368D127B4C for ; Thu, 13 Dec 2018 08:24:42 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id x23so2103726oix.3 for ; Thu, 13 Dec 2018 08:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h7FH3Sy68mdWum/syai5ZVYjjZCE5S9xLKikmkGPLso=; b=Js6Lmm1O7YV3/e4Po5aHncJMwMX5z6XQxpYrLBkaip5ihh4QtEa3UaY6JD7gEMMFMI AXiZPBB9LfUVLctcbK23q3T972x27xU7cKZlnU7nsYyZS4Ch2EQafa4ZYyqiaDy98zEq V3QCcpeZrL1rQKnG7c00kJ08ksmToRC8O5+Lsj6kiDD+yFuPBQnXiL8SdDA+rde3ZPIY W8hdZz9BX4vex8iNoXBqPI56QVf7aJ88diq8hgtuFg4T4g/8Q5Chc/KlzlDfRh6lda/F NOZcclD5WUcYPiyiIfcFpzsbkp7a7F647Xo4oqXVzX2mdlReoB+QqmZebnZGqW5jScin KA3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h7FH3Sy68mdWum/syai5ZVYjjZCE5S9xLKikmkGPLso=; b=BVlMLsNXf2+FQg41WrMaaB7cJLC/owDBcOVKvdaQkdOHT51CLJuDwZ4U3IZUpgpwmx vKx+WNZc45kFJK95gmqRhXkZ3eR+1w92GtiXBAbMdD4JsqRikAgK0sRnXQ6DSYMfPYmG mpRt2Q3ncIlUHtF/cZ1+QjftqQ5AGQlZUG36vDL68I3B+scW/ovYIZJwsNTCTAaEgKDv zPX8vaa2JuRPyR5R2w43IE79Vspmy2/7mQ9FfcMlv5/nZlkdnZ147/W/nROlKFfTyyqS m8T6dmA950F8PueBOBULN80qI7jPUEeIbC6Li+XCOSjCrCW9HbXXpaLAYg77Y2KaamEj Y0TA== X-Gm-Message-State: AA+aEWacHiyujVQ1WQe84+4u2ff5Ezb6t37ts2lukrpocDUFhbTbgZJ0 B1d2XS+giPiTyaY8tVsuNmIzm/u8Xi4= X-Google-Smtp-Source: AFSGD/U7S1XyJtzxml9uwnestDz/ltadmASbHHeldresxBvMyzb6GEI+S6h+jo3U5KJfe7OAb+iMLQ== X-Received: by 2002:aca:3345:: with SMTP id z66mr3490572oiz.91.1544718281532; Thu, 13 Dec 2018 08:24:41 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:d167:e3f8:4e3c:c340? ([2600:1700:a3a0:870:d167:e3f8:4e3c:c340]) by smtp.gmail.com with ESMTPSA id h25sm988883otj.27.2018.12.13.08.24.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 08:24:40 -0800 (PST) To: "Kurt Andersen (b)" Cc: Scott Kitterman , "dmarc@ietf.org" References: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> <2657505.cCtalkmY2s@kitterma-e6430> <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> From: Dave Crocker Message-ID: Date: Thu, 13 Dec 2018 08:24:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 16:24:45 -0000 On 12/13/2018 8:20 AM, Kurt Andersen (b) wrote: > A link to inscrutable legalese, potentially in a non-interpretable > format (consider, for example, a PDF consisting of images of a foreign > alphabet - perhaps Klingon) doesn't seem to really achieve the intent. > And neither does the bald assertion - "trust me, I require people to do > the right thing" :-) And yet the current draft relies on a single 'expert' to be able to achieve a productive outcome with exactly the same material. And it produces only a single review at the time of registration. The benefit of the approach I'm suggesting is that it surfaces these documents much more openly and makes it likely they will be reviewed much more widely and on a continuing basis. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Dec 13 10:27:15 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF2130E12 for ; Thu, 13 Dec 2018 10:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=rwq9EX3u; dkim=pass (1536-bit key) header.d=taugh.com header.b=nGfX36bj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUs-adJ48fVP for ; Thu, 13 Dec 2018 10:27:11 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952DC130E14 for ; Thu, 13 Dec 2018 10:27:11 -0800 (PST) Received: (qmail 80398 invoked from network); 13 Dec 2018 18:27:08 -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=13a0c.5c12a47c.k1812; bh=VNz5eNBAkLLge739n5jXZ7IxMityx+7dBg7hs+ala5c=; b=rwq9EX3uPx/BbVKu5wQ0+UDtXSXJlYC7wvyThRR1wAJ5sDn3G9sTEnqJaLQEQXupw0+Ly58Nmr2AZTQtpjO3w8ky6Cit5x8JFQQ0VNhBtcsveKMvCXD61TnVdd9mE5oyhuPgCsh469X4+T9b0ouZgPTk9iO6qtSCR/yyYpWqoVZGtH1hYCvXrxOi2mnccA1uu2hLTI31S9DgUuyhW8jPzevkFzmMgaKODDzb8YTXmlUSSKe9kBc7royb7BxPUSGf 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=13a0c.5c12a47c.k1812; bh=VNz5eNBAkLLge739n5jXZ7IxMityx+7dBg7hs+ala5c=; b=nGfX36bj+jtXXAZk8u3E0VDaufLWtRjQq6ft2LJ5z9nX8S6w8Nk/L0hAft5W51IgmE1JSXeUpuKAImhQ4n44vW/HuD0nVzqIvswtcbRV2pBzsjMLj65xx9fmRhwyK+jdV9Z2n/JYo5QfyNztgpG/FTTsKy28mANSCipj8Joh8Dba3m3YA249TyKJ8dheQ+L60P6QPh9Huy9LJAlQGRKx3zBDdd8Pf7A7nfhLIAW4uBEjUJolShDPQhgXXLyQcjGq Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Dec 2018 18:27:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 5AD73200B6C4F5; Thu, 13 Dec 2018 13:27:08 -0500 (EST) Date: 13 Dec 2018 13:27:08 -0500 Message-Id: <20181213182708.5AD73200B6C4F5@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2657505.cCtalkmY2s@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 18:27:14 -0000 >I think it would be interesting to get more details from John Levine on his >experience with this as he has (in a later message in the thread) mentioned >he's getting this kind of data now for odd architectural reasons. I'm the legacy registry for seneca.ny.us, a rural county just north of here. One of my registrants is the county government, at co.seneca.ny.us. I have an MX on seneca.ny.us so people can write to me at hostmaster@seneca.ny.us if someone in the county wants to registers a name. They have lots of people at @co.seneca.ny.us. I have my usual dmarc record at _dmarc.seneca.ny.us, and I've noticed that since they don't publish a dmarc record (or much of anything else, since their mail is outsourced to O365 and they're not very sophisticated), I get all of their dmarc reports. In this case it's not a big deal, they know who I am, I know who they are, local governments aren't supposed to keep secrets, and the reports don't show anything surprising, but one can imagine situations where it could be an issue. I suppose in principle it might be a problem if some of their mail showed up in failure reports, although since my policy is p=none and as far as I can tell nobody there sends mail to mailing lists, there aren't many of those. R's, John From nobody Thu Dec 13 16:25:29 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29D4130EC2 for ; Thu, 13 Dec 2018 16:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=P9NpVPlR; dkim=pass (2048-bit key) header.d=kitterman.com header.b=BAh8Qe1I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9uN0GWs_Q1S for ; Thu, 13 Dec 2018 16:25:27 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF611286E7 for ; Thu, 13 Dec 2018 16:25:26 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544747124; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=vELgs3M+Ongx0skFnXJByUovF04atl4s8KrBvxBzvnA=; b=P9NpVPlRjJt8I0ZORzWMd19eKJ/aegHaM00MqVDCtbh0GSjRwJtdjIuD cHxwXXs2xxb/m33LswyCzVjRegAnCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544747123; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=vELgs3M+Ongx0skFnXJByUovF04atl4s8KrBvxBzvnA=; b=BAh8Qe1IH6YEXlph5/V0CmYwfO+Gq6tH7nFqWXs2cfP0/xfSsG0ZK64G 1Rn+xStimu6Si0d6dARviCdkqIf38ljhmzqfjxWialIIAOB4eX5db4vVgB HAUfz1Xtaadu1qolu9pN4lBu4KqOPgvwAvBON/HuYTCYYfgakabcPfH3+Y of64W81Qo7qxOQwVemXk6DWrV/k/aqrINi+RoPcx9H3j/OZmfj70v263Bh sZIFR6RDgYl4UTnIRo71DO/aeoOn/Sxa3mwjUMh7fVWxQi2JK6LsbpgBci dsViNrwaiKR8qTumdod2rEsC3pp5mFOTYDyzR449NOYTsaJ+LJtKFw== Received: from kitterma-e6430.localnet (mobile-166-170-29-190.mycingular.net [166.170.29.190]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id E3A682D4062B for ; Thu, 13 Dec 2018 18:25:23 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 13 Dec 2018 19:25:22 -0500 Message-ID: <2046741.GJeexbxHFF@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2018 00:25:29 -0000 On Thursday, December 13, 2018 08:24:38 AM Dave Crocker wrote: > On 12/13/2018 8:20 AM, Kurt Andersen (b) wrote: > > A link to inscrutable legalese, potentially in a non-interpretable > > format (consider, for example, a PDF consisting of images of a foreign > > alphabet - perhaps Klingon) doesn't seem to really achieve the intent. > > And neither does the bald assertion - "trust me, I require people to do > > the right thing" :-) > > And yet the current draft relies on a single 'expert' to be able to > achieve a productive outcome with exactly the same material. And it > produces only a single review at the time of registration. > > The benefit of the approach I'm suggesting is that it surfaces these > documents much more openly and makes it likely they will be reviewed > much more widely and on a continuing basis. It suffers from what is, in my opinion, a fatal flaw: it relies entirely on assertions that any PSO can publish with no external review. Without some kind of third-party check on this, I don't believe there's any privacy mitigation at all. In previous examples, this has been analogized to the Verisign sitefinder debacle. Personally, I think it's worse. Without an external check, this is a tool for enhancing the surveillance capacity of authoritarian regimes. I don't find making the documents public so people can complain at all useful. The entities that will most want to use this will tend to be the ones that care least about complaints. I'm not claiming an IANA registry is an essential part of the solution, I'm sure their are better ideas, it's just the one I thought of. What we need is some location of information about domains that is neutrally managed in accordance with open processes. That sounded like IANA to me, but I'm open to suggestions. Scott K From nobody Thu Dec 13 17:55:00 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22F0130F55 for ; Thu, 13 Dec 2018 17:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=rywj0D/O; dkim=pass (1536-bit key) header.d=taugh.com header.b=Vq+8xtwr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGBuFFdNVeAG for ; Thu, 13 Dec 2018 17:54:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48D5130F4D for ; Thu, 13 Dec 2018 17:54:56 -0800 (PST) Received: (qmail 54550 invoked from network); 14 Dec 2018 01:54:54 -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=d514.5c130d6e.k1812; bh=I+Jio1XcghuCPq4JT4JeB5P6ygGuEfi6+wVCHG3sa+w=; b=rywj0D/OEzz4twLmcT5KemORYeDpJX2pWLDpN7c94eBHkaUinl737NiaKHWbc+FMpS/IzbFzz8xJbNwInpjoHJUCW2EP5E2ThALEO7wRiw5cwFCliE+MQlujE3AIwVqs4ViBi+BD2KnGv06pD16kynkrJ9goLDjPCO8beF/rbYXKX7ZztdP6UMRbhMMsz51bmNcXUqcyoFl98Kd9NHtfkMmpFt9iGW+DvfazYeG0cPPbAG5Qvc9xkjeTOvbHtoSY 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=d514.5c130d6e.k1812; bh=I+Jio1XcghuCPq4JT4JeB5P6ygGuEfi6+wVCHG3sa+w=; b=Vq+8xtwr13HxxQxVKKNvjqYeS/PZ+1rnA+BVrhnHePc04KK2slhFOoVBxNnUVIShy+F95ESdml9EuEicy+OWyCwcMjM3zKu6L6BWgwPj64LpxZcKpMq36IH3usrLEs6EQ4iTPPl/FuY/DlSxMIjIHY+Q8zpBIbWmcgmGw/M9czJKYpOlxRmL+eT2XfwV7V4SSmNu0CAJtflbFQIygePBzuA5WXb91EPVwvWYkJm3GSdqdR0GM3IDy3pH6NGR6cEp Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 14 Dec 2018 01:54:53 -0000 Received: by ary.qy (Postfix, from userid 501) id A1E38200B6F99D; Thu, 13 Dec 2018 20:54:53 -0500 (EST) Date: 13 Dec 2018 20:54:53 -0500 Message-Id: <20181214015453.A1E38200B6F99D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2046741.GJeexbxHFF@kitterma-e6430> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2018 01:54:59 -0000 In article <2046741.GJeexbxHFF@kitterma-e6430> you write: >In previous examples, this has been analogized to the Verisign sitefinder >debacle. Personally, I think it's worse. Without an external check, this is >a tool for enhancing the surveillance capacity of authoritarian regimes. This is starting to sound like the drunk looking for his keys by the streetlight. I grant the hypothetical point you're making, but if I were a cruel government, funky DMARC records would not be near the top of my list of intrusive techniques. R's, John From nobody Thu Dec 13 20:18:00 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DFF13102D for ; Thu, 13 Dec 2018 20:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=rq2ZcRVN; dkim=pass (2048-bit key) header.d=kitterman.com header.b=PiAmAqdN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95JrY1tIepqu for ; Thu, 13 Dec 2018 20:17:56 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [169.62.11.132]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F284131000 for ; Thu, 13 Dec 2018 20:17:56 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544761073; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=GCXMiEf7NIUyNpymgFJCM167gbKWRImJqTAnqAkVhhE=; b=rq2ZcRVNgBz67VwqsW+L8W6nYY+MLd0LfHKHSrR4aq59v9NL0iedLpMQ Eok1OrPUCX885r697awj8wBnHVYsDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544761073; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=GCXMiEf7NIUyNpymgFJCM167gbKWRImJqTAnqAkVhhE=; b=PiAmAqdNyIu/IzhiopbWkwVHxnMNSMfRAPXuqbTHlYyxin9/LsL5y/Lb WojtpOjR12VV4i4XGxXvmd6lOgOKRKySoI+Un6mg1l70MM0P5Z26+JXE3q CA/lg/+HrjpU0/Q0VtCeviWHhJrY65lTs1hb7cmVgYa1P+wjhumtmKgoCI 0mLajnEr1q1Rvnq0LO3eTW8zZs1B4NJVqytcV79xZMLpO6WbTMz8ijWCuL +FnHU5hnZ3E+azNEiUN2UAQ2Lh5pa0EtU0re4gD7jSpY5FTvePt3IayCjP xOCQtNi7vL5eOAM9tSvqRb7vGUg6S9hEtDXHbVFlrUGiIRbUrAU4eQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 0104A2D409A1 for ; Thu, 13 Dec 2018 22:17:53 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 13 Dec 2018 23:17:52 -0500 Message-ID: <5481301.0rrDFdmT3s@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20181214015453.A1E38200B6F99D@ary.qy> References: <20181214015453.A1E38200B6F99D@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2018 04:17:58 -0000 On Thursday, December 13, 2018 08:54:53 PM John Levine wrote: > In article <2046741.GJeexbxHFF@kitterma-e6430> you write: > >In previous examples, this has been analogized to the Verisign sitefinder > >debacle. Personally, I think it's worse. Without an external check, this > >is a tool for enhancing the surveillance capacity of authoritarian > >regimes. > This is starting to sound like the drunk looking for his keys by the > streetlight. > > I grant the hypothetical point you're making, but if I were a cruel > government, funky DMARC records would not be near the top of my list > of intrusive techniques. Possible, but I come back to as bad as it is, let's not make it worse. I don't think that domains should have to opt-out (by publishing a DMARC record) of having their data sent to the registrar of their TLD/PSD. If it's open season for PSD, then that's the situation we've created. Scott K From nobody Thu Dec 13 20:34:43 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545CA1277D2 for ; Thu, 13 Dec 2018 20:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ0Imh7XJEra for ; Thu, 13 Dec 2018 20:34:39 -0800 (PST) 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 3B7B212008A for ; Thu, 13 Dec 2018 20:34:39 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id u16so4224090otk.8 for ; Thu, 13 Dec 2018 20:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VyMctYHje2Kf4w7F49XynLXFBdx4Vs/RBylA5jxYbuQ=; b=IIFhOg+X4pSi/D9wercKiG0TxlQjmCDtd9gxi30Hoo3UE9GQoUb6i2XApT9K8BPDB4 yYnjGl78msg+D0VuOOwoZbciTrnJWA/l7TYICY+2pPj2xFhDwVzT7gwE7xyudh1u3vo/ bvaIgu9yXdyTSsDFG+g0hw4wPFohnQAb8e3aRvbrxWCqZPGy3MakqK1yjXyDhEf7Nv8U lWqXb5rDyBYBIxcyWbOHAkLyAgp7rzEOJ3TU3F1V7NRVRO5IGdDhUXOrr4m9gx5zcGpX JKAuHRdy6Ylfv03qQ16OZynjASPbo92jvjfGgODRLjaqu63EDtaXkPvXpt1p3AgYP2n/ aezQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VyMctYHje2Kf4w7F49XynLXFBdx4Vs/RBylA5jxYbuQ=; b=NiAtVE8vOB6RBzeQFDmuL0zMxN3d0yicfNQ6VND0F/0JD1oHqtpR4Ttw127i26UFSB oCjqohhVe7NOYObjwxwF+YgtLdMRYmKnm1IIYwL/i6bM3Q4lWf31fDygNa1ZGnE6GY3H rrCv1Ytjm9qws9XSqgsPRtU2y4/6W8wQNdVW17OWe8vI8+WR+Cc7MUb6NaWnY+w7VrDJ t8DftQsNO4L7rbMajiSXV+sZsZWAvgA4q2OnVDkIfmr7Rd6ocJQ/LO7VuxGDQGYMt27w W20j0DFd7kWrY/xITOPF5/h/kh5rWSKZZ17pZEFlsN1emVhULOmNuAAOWwUvO5lB2n0+ aWyQ== X-Gm-Message-State: AA+aEWYmnADZ2t2ftCNqd9QTfn7ZLankjvPMyTARKdcPXStplaDSKoFy ZYq//zvpXsZb4M7IK/9ABX3d3uCsmUE= X-Google-Smtp-Source: AFSGD/UFt+f/1yzNi6FJWp8QtsbzNt5VrRE1JDodi6+ax+x6qw8NEaqGm9GyBf3Qcsl9AmTmWx2Bcg== X-Received: by 2002:a9d:172e:: with SMTP id i46mr1031061ota.322.1544762077947; Thu, 13 Dec 2018 20:34:37 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:870:d167:e3f8:4e3c:c340? ([2600:1700:a3a0:870:d167:e3f8:4e3c:c340]) by smtp.gmail.com with ESMTPSA id m2sm2152976otp.34.2018.12.13.20.34.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 20:34:37 -0800 (PST) To: Scott Kitterman , dmarc@ietf.org References: <2046741.GJeexbxHFF@kitterma-e6430> From: Dave Crocker Message-ID: Date: Thu, 13 Dec 2018 20:34:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <2046741.GJeexbxHFF@kitterma-e6430> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2018 04:34:41 -0000 On 12/13/2018 4:25 PM, Scott Kitterman wrote: > It suffers from what is, in my opinion, a fatal flaw: it relies entirely on > assertions that any PSO can publish with no external review. Without some > kind of third-party check on this, I don't believe there's any privacy > mitigation at all. I think that assessment is misses an essential point. Let me back up and say that my suggested alternative is intended to take the basic concern you are raising seriously. (I'm not stating a personal opinion about the seriousness of this as a threat vector, but merely looking for a simpler way to satisfy the concern.) The alternative requires that the registry's dmarc record be accompanied by a record that points to the terms and conditions the registry publishes to indicate why their record is acceptable. (Your draft's specification of those conditions looked to me like a reasonable starting point; there should be a separate wg discussion for the precise details and wording; I don't have a personal opinion about those words.) As for the benefits I see in the alternative I've proposed, I'll class them as simplification and robustness. First, a new, query-able registry is expensive to run; and difficult to ensure quality control for, over the long run. Second, the vetting method your draft proposes for the registry relies on a technical expert to make what is frankly a legal assessment of the terms and conditions that the registry publishes. And that assessment is made only one time, when the registry entry is first created. The registry might change its T&C text and we'd be unaware of it. So while you are technically correct that the alternative means that the registry gets to /publish/ with no external review, it is not true that their dmarc record will automatically be used without review. In fact what I'm proposing will make widespread and ongoing review likely, IMO, probably in the spirit of ongoing reputation assessment that the email industry already does, although for dmarc default record rather than spam. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Dec 14 07:22:23 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB512896A for ; Fri, 14 Dec 2018 07:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_META_ALL=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 8l8TwwGrtISF for ; Fri, 14 Dec 2018 07:22:20 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79262124BF6 for ; Fri, 14 Dec 2018 07:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1544800938; bh=B46yUHycGYgjQPB6/nMc2bw9MOMiG5uX3lc2XQv9yKs=; l=1018; h=To:References:From:Date:In-Reply-To; b=AVsU4Ss35AVrI7ZlXJn92+a5xS2Ne/0DhGhtRTpIM33PDau2E7Ns7uTlIDXlb6ClU BdmGhTL+Z3nBSPiPVmO7KzssN4sLiNLStaViB9PexKWanTR518YanXYFwUZ9r5vBRK Wa8IV5iZ2pdpZWJX5sc6+F/TIJfL/8UVOA+o0MMXEe/x+nhd3X0CcJVqnJqdH Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 14 Dec 2018 16:22:17 +0100 id 00000000005DC082.000000005C13CAA9.0000179D To: dmarc@ietf.org References: <4e253157-3397-b901-4c1d-132c709b996e@gmail.com> <2657505.cCtalkmY2s@kitterma-e6430> <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> From: Alessandro Vesely Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00 Message-ID: <3b6a99a6-b45c-303f-aa4d-b2588b930ab0@tana.it> Date: Fri, 14 Dec 2018 16:22:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <2981238b-1e41-294c-0c04-0b8183c7234e@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Dec 2018 15:22:22 -0000 On Thu 13/Dec/2018 17:08:46 +0100 Dave Crocker wrote: > Let me suggest a much easier hack, which differs in utility mostly by being > post hoc rather than the current draft's pre-hoc mechanism: > >      Require the registry to publish another DNS record, in its _dmarc node, > which a) asserts either than DMARC is required or that the subtree is part of a > single organization, and b) contain a URL to the documentation for this. > > A query for the DMARC record of the registry will also deliver this information > record.  (This might be the first case in which the problem of getting 'other' > TXT records is actually a feature and not a problem...) > > That makes the information public, while avoiding the considerable overhead and > problems of a new registry -- nevermind one that needs real-time querying. +1. The documentation is going to be consumed by MTA admins who decide whether to honor the rua= request or not. A community reviewed distributed registry. Best Ale -- From nobody Fri Dec 14 17:23:45 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F07130EBA for ; Fri, 14 Dec 2018 17:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=qY5lYeNt; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ARqhrzdL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcysmNtfA3Ip for ; Fri, 14 Dec 2018 17:23:41 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B77F12E036 for ; Fri, 14 Dec 2018 17:23:41 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=qY5lYeNtwIyyB22jR7zzKsgPSziYropblQvC0qjTdneQYBYJ8YP+jT6x tCb5EQNr4zGHLWwyfgNtnPhi/A3VDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=ARqhrzdLLh6g6EjfCOMAoyUvRw6CVgkAmyWf7hrgK3wd4+j1r2kHfwaC 45aEc6hi2rfKRY4Vzfx3ZkSEo5OUFccC9qLdkBqjvhuBKlzXJfOAgMdJI7 ozXmSkr1v8I5DQrFA+YyPWMA5scnyaLS2P6AUjtS1yY4N52shzlENsZQtV igJitf5Zm20+sfBgDNkn2a8/8JSBbraQC1ErtBxnX4OsrDnTCot1QyyJDF HbX858d4jLvAjBpJ0VNBTIZTqgDI4XpJ45r5d2zd4hH1mgwghWOxkeGp6P vAUjxZOiOp8B1KvhbLqnlrY4nV8Gd95GgP1OqEbDzqDl9r5N40FraA== Received: from [10.5.165.47] (mobile-166-171-56-58.mycingular.net [166.171.56.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 531992D409A1; Fri, 14 Dec 2018 19:23:39 -0600 (CST) Date: Sat, 15 Dec 2018 01:23:32 +0000 In-Reply-To: References: <2046741.GJeexbxHFF@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dmarc@ietf.org From: Scott Kitterman Message-ID: <31F9BE79-4DE2-4A8B-BFAE-E5660419C279@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Dec 2018 01:23:44 -0000 On December 14, 2018 4:34:35 AM UTC, Dave Crocker w= rote: >On 12/13/2018 4:25 PM, Scott Kitterman wrote: >> It suffers from what is, in my opinion, a fatal flaw: it relies >entirely on >> assertions that any PSO can publish with no external review=2E Without >some >> kind of third-party check on this, I don't believe there's any >privacy >> mitigation at all=2E > > >I think that assessment is misses an essential point=2E > >Let me back up and say that my suggested alternative is intended to >take=20 >the basic concern you are raising seriously=2E (I'm not stating a=20 >personal opinion about the seriousness of this as a threat vector, but=20 >merely looking for a simpler way to satisfy the concern=2E) > >The alternative requires that the registry's dmarc record be >accompanied=20 >by a record that points to the terms and conditions the registry=20 >publishes to indicate why their record is acceptable=2E (Your draft's=20 >specification of those conditions looked to me like a reasonable=20 >starting point; there should be a separate wg discussion for the >precise=20 >details and wording; I don't have a personal opinion about those >words=2E) > >As for the benefits I see in the alternative I've proposed, I'll class=20 >them as simplification and robustness=2E > >First, a new, query-able registry is expensive to run; and difficult to > >ensure quality control for, over the long run=2E > >Second, the vetting method your draft proposes for the registry relies=20 >on a technical expert to make what is frankly a legal assessment of the > >terms and conditions that the registry publishes=2E And that assessment= =20 >is made only one time, when the registry entry is first created=2E The= =20 >registry might change its T&C text and we'd be unaware of it=2E > >So while you are technically correct that the alternative means that >the=20 >registry gets to /publish/ with no external review, it is not true that >their dmarc record will automatically be used without review=2E > >In fact what I'm proposing will make widespread and ongoing review=20 >likely, IMO, probably in the spirit of ongoing reputation assessment=20 >that the email industry already does, although for dmarc default record >rather than spam=2E I see your point=2E In addition to complexity, tohe issue that there is n= o mechanism for removing bad actors from the registry does present a proble= m=2E Let me think it over and see if I can come up with text that both addresse= s your concerns and also provides guidance that I'd be comfortable with in = lieu of the registry=2E Scott K From nobody Mon Dec 17 12:03:48 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F403F130F40 for ; Mon, 17 Dec 2018 12:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=9ZEP3ll7; dkim=pass (2048-bit key) header.d=kitterman.com header.b=W+elPI7C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3i6h0mtvU4u for ; Mon, 17 Dec 2018 12:03:44 -0800 (PST) Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3770129AB8 for ; Mon, 17 Dec 2018 12:03:43 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1545077017; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=squ1CTHihWsihymndGniWOGlbIRdGxndwW39duHgUXg=; b=9ZEP3ll7VeH6wXfD2tym60NlRr1Azw54cD6YeAxQH/xUjuXqX4IX4lE7 hn19OE6gH70aIPya67XvmquatRIdDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1545077017; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=squ1CTHihWsihymndGniWOGlbIRdGxndwW39duHgUXg=; b=W+elPI7CF5fqmgm7ENmMAyjd+6chvD9BXmxWz28XMvYstQraICAJ9vUI AxXPW+43TvxoSaRbLgCYLXZ4iC57gNWIvvF7AQInRRQ3R2Y9rg3oPZAhli WiJryEhekKSI4BRPgvIF9Hky7tfnH1geSUfP5plX8V6KvgW3iOpfSknJCq AQJEd/qTs6juUkg0P9geKCc0Jfbihu4Ia4fD12Smh6p+W5I+ImFNaMqldd UckD7z49XJvOdit1k/j9hyKtNj9G2ABKRWCedS1eEIRx4djqVb9Oyv0Ix0 DnPMrrIXwAXfvp/1tlccq/prOZxg0AZ1iFTL4fQdXBn41aysmwhkAQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id 821282D407D2 for ; Mon, 17 Dec 2018 14:03:37 -0600 (CST) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 17 Dec 2018 15:03:36 -0500 Message-ID: <2188823.MQKRFllneH@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-163-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <31F9BE79-4DE2-4A8B-BFAE-E5660419C279@kitterman.com> References: <31F9BE79-4DE2-4A8B-BFAE-E5660419C279@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] PSD simplification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Dec 2018 20:03:46 -0000 On Saturday, December 15, 2018 01:23:32 AM Scott Kitterman wrote: > On December 14, 2018 4:34:35 AM UTC, Dave Crocker wrote: > >On 12/13/2018 4:25 PM, Scott Kitterman wrote: > >> It suffers from what is, in my opinion, a fatal flaw: it relies > > > >entirely on > > > >> assertions that any PSO can publish with no external review. Without > > > >some > > > >> kind of third-party check on this, I don't believe there's any > > > >privacy > > > >> mitigation at all. > > > >I think that assessment is misses an essential point. > > > >Let me back up and say that my suggested alternative is intended to > >take > >the basic concern you are raising seriously. (I'm not stating a > >personal opinion about the seriousness of this as a threat vector, but > >merely looking for a simpler way to satisfy the concern.) > > > >The alternative requires that the registry's dmarc record be > >accompanied > >by a record that points to the terms and conditions the registry > >publishes to indicate why their record is acceptable. (Your draft's > >specification of those conditions looked to me like a reasonable > >starting point; there should be a separate wg discussion for the > >precise > >details and wording; I don't have a personal opinion about those > >words.) > > > >As for the benefits I see in the alternative I've proposed, I'll class > >them as simplification and robustness. > > > >First, a new, query-able registry is expensive to run; and difficult to > > > >ensure quality control for, over the long run. > > > >Second, the vetting method your draft proposes for the registry relies > >on a technical expert to make what is frankly a legal assessment of the > > > >terms and conditions that the registry publishes. And that assessment > >is made only one time, when the registry entry is first created. The > >registry might change its T&C text and we'd be unaware of it. > > > >So while you are technically correct that the alternative means that > >the > >registry gets to /publish/ with no external review, it is not true that > >their dmarc record will automatically be used without review. > > > >In fact what I'm proposing will make widespread and ongoing review > >likely, IMO, probably in the spirit of ongoing reputation assessment > >that the email industry already does, although for dmarc default record > >rather than spam. > > I see your point. In addition to complexity, tohe issue that there is no > mechanism for removing bad actors from the registry does present a problem. > > Let me think it over and see if I can come up with text that both addresses > your concerns and also provides guidance that I'd be comfortable with in > lieu of the registry. I thought about it over the weekend, and I didn't come up with anything I was really happy with that also addresses your concerns. Still thinking about it. It is clear though, based on this discussion, that the privacy concerns section needs to be beefed up. My plan is to focus first on that. It has two advantages: One; I think I know what to write and two; I don't think it will be very controversial. In any case, having agreed text in the draft that describes what privacy issues we want to mitigate seems like a good next step towards figuring out how best to do that. Scott K From nobody Tue Dec 18 13:12:28 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6551130F29; Tue, 18 Dec 2018 13:12:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <154516754591.5209.1681211635216329499@ietfa.amsl.com> Date: Tue, 18 Dec 2018 13:12:25 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-23.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 21:12:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : Authenticated Received Chain (ARC) Protocol Authors : Kurt Andersen Brandon Long Seth Blank Murray Kucherawy Filename : draft-ietf-dmarc-arc-protocol-23.txt Pages : 40 Date : 2018-12-18 Abstract: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 18 13:23:40 2018 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13A130F63 for ; Tue, 18 Dec 2018 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGkMfcmN1C3v for ; Tue, 18 Dec 2018 13:23:36 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 0B8FC1292F1 for ; Tue, 18 Dec 2018 13:23:36 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id x124so9255843itd.1 for ; Tue, 18 Dec 2018 13:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yvHUhzH6BeeDILLiAi4aKPt0C/7+kupO7k7+FA5oqvg=; b=QRrUlLPfL4ivf3yjUt02KxrfUUF+bY1KClEXOf64DpgZz+Awx+uiWr01Zon6jh3rAb 6/BscqkkLNs7hO1i/ieXds5ZW9f0BvHYJjjrNWX7eMoFIbIdypkXrgxSpIc9ECvyAfa2 WzB9tG2xRj6GZ5oRTjLAlDmWIK5Pr8zakPuBg= 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=yvHUhzH6BeeDILLiAi4aKPt0C/7+kupO7k7+FA5oqvg=; b=Q1YKy7aqPTfzWHhwVirv86VfjM8l0C/8zKBWlKsTIzubphdXrqMtwxoc1zOrErtwug J+/rNg93YKHmj7txdtKbGTyXRQicwu3Yj8tMkHosSBmZIql21SmrUniOvP8XJrPvLn1c /Z5KYY+NBWHIegDDtVk7mDlhlrjkz7v0DjFbWWJmxPzTBvodDjdktTwcnrRk/rW7YoeJ BLOXFzQVjcg1iDYBF2Q/vY6RaGktAK08CZ6QYOwpb7LRRcj0Qwj7XSM7jCfoyGJH80I+ 1YfOtsZNy5/PH6psMg/rqDGV6uLJX8pZNSMupmGH0SA6c6PF5XcC2YlTialMcqccYleu uleA== X-Gm-Message-State: AA+aEWbFATknTB3PCSi6Wu5YIWIdVMhrlUTSdKckJvfE6w1ZPUPHxmly nYE598Ce5hdWZNjwJHtFME6SuclqnQBkNYmdTc+7I2imOaM= X-Google-Smtp-Source: AFSGD/Vn/hSMg9RUzmJk29166rsHrb98tKnanAqyLV6db4Mka6rWQIajnhBBfBsVijWtJLx84kdW2qyG3deEuyOJYE0= X-Received: by 2002:a24:1c04:: with SMTP id c4mr4490660itc.79.1545168214663; Tue, 18 Dec 2018 13:23:34 -0800 (PST) MIME-Version: 1.0 References: <154516754611.5209.10172798907589977010.idtracker@ietfa.amsl.com> In-Reply-To: From: "Kurt Andersen (IETF)" Date: Tue, 18 Dec 2018 13:23:23 -0800 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008dc9ea057d5282a8" Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-23.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: Tue, 18 Dec 2018 21:23:38 -0000 --0000000000008dc9ea057d5282a8 Content-Type: text/plain; charset="UTF-8" Meant to send this to the list... On Tue, Dec 18, 2018 at 1:16 PM Kurt Andersen wrote: > This version incorporates some slightly clarified wording in response to > Eric Rescorla's last call comments (section 9) and updates the > Implementation Status (section 12) with the latest information as of the > October 2018 interop. > > --Kurt > > On Tue, Dec 18, 2018 at 1:12 PM wrote: > >> >> A new version of I-D, draft-ietf-dmarc-arc-protocol-23.txt >> has been successfully submitted by Kurt Andersen and posted to the >> IETF repository. >> >> Name: draft-ietf-dmarc-arc-protocol >> Revision: 23 >> Title: Authenticated Received Chain (ARC) Protocol >> Document date: 2018-12-18 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-23.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-23 >> > --0000000000008dc9ea057d5282a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Meant to send this to the list...

On Tue, Dec 18, 2018 at 1:16 PM Kurt Ande= rsen <kurta@drkurt.com> wrote= :
This version incorporates some slightly clarified wording in respon= se to Eric Rescorla's last call comments (section 9) and updates the Im= plementation Status (section 12) with the latest information as of the Octo= ber 2018 interop.

--Kurt

On Tue, Dec 18, 2018 at 1:12 PM <internet-drafts@ietf.org> wrote:<= br>

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

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dmarc-arc-protocol=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A023
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticated Received Chain (ARC)= Protocol
Document date:=C2=A0 2018-12-18
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-dmarc-ar= c-protocol-23.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol<= br> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmarc-arc-prot= ocol-23
--0000000000008dc9ea057d5282a8-- From nobody Wed Dec 19 06:31:20 2018 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1D129508; Wed, 19 Dec 2018 05:54:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Cc: tjw.ietf@gmail.com, The IESG , Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , dmarc@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org, dmarc-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154522768686.14742.4145455082471661360.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2018 05:54:46 -0800 Archived-At: X-Mailman-Approved-At: Wed, 19 Dec 2018 06:31:19 -0800 Subject: [dmarc-ietf] Document Action: 'Authenticated Received Chain (ARC) Protocol' to Experimental RFC (draft-ietf-dmarc-arc-protocol-23.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:55:00 -0000 The IESG has approved the following document: - 'Authenticated Received Chain (ARC) Protocol' (draft-ietf-dmarc-arc-protocol-23.txt) as Experimental RFC This document is the product of the Domain-based Message Authentication, Reporting & Conformance Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ Technical Summary: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles a message to see what entities have handled it before, and to see what the message's authentication assessment was at each step in the handling. This allows to convey original authentication assessments across trust boundaries. Working Group Summary: The working group process was quite involved, and because this document is Experimental, there was active discussions on implementations and experiments that are detailed in the document. Document Quality: The document lists the existing implementations of the protocol, and appears to cover a broad spectrum of both purchased software as well as open source. Personnel: Document Shepherd: Tim Wicinski Area Director: Alexey Melnikov